Software Engineering A Practitioner's Approach - Roger S. Pressman

Chapter 1
 Software & Software Engineering

Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman
Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman
For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.
All copyright information MUST appear if these slides are posted on a website for student
use.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 1
What is Software?
Software is: (1) instructions (computer programs)
that when executed provide desired features,
function, and performance; (2) data structures
that enable the programs to adequately manipulate
information and (3) documentation that describes
the operation and use of the programs.
What is Software?
 Software is developed or engineered, it is not
manufactured in the classical sense.
 Software doesn't "wear out."
 Although the industry is moving toward
component-based construction, most software
continues to be custom-built.
Wear vs. Deterioration
increased failure
rate due to side effects
Failure
rate
change
actual curve
idealized curve
Time
Software Applications
 system software
 application software
 engineering/scientific
software
 embedded software
 product-line software
 WebApps (Web
applications)
 AI software
Software—New Categories
 Open world computing—pervasive, distributed
computing
 Ubiquitous computing—wireless networks
 Netsourcing—the Web as a computing engine
 Open source—”free” source code open to the computing
community (a blessing, but also a potential curse!)
 Also … (see Chapter 31)
 Data mining
 Grid computing
 Cognitive machines
 Software for nanotechnologies
Legacy Software
Why must it change?
 software must be adapted to meet the needs
of new computing environments or
technology.
 software must be enhanced to implement new
business requirements.
 software must be extended to make it
interoperable with other more modern
systems or databases.
 software must be re-architected to make it
viable within a network environment.
Characteristics of WebApps - I
 Network intensiveness. A WebApp resides on a network and
must serve the needs of a diverse community of clients.
 Concurrency. A large number of users may access the
WebApp at one time.
 Unpredictable load. The number of users of the WebApp may
vary by orders of magnitude from day to day.
 Performance. If a WebApp user must wait too long (for
access, for server-side processing, for client-side formatting
and display), he or she may decide to go elsewhere.
 Availability. Although expectation of 100 percent availability is
unreasonable, users of popular WebApps often demand
access on a “24/7/365” basis.
Characteristics of WebApps - II
 Data driven. The primary function of many WebApps is to use
hypermedia to present text, graphics, audio, and video content to the
end-user.
 Content sensitive. The quality and aesthetic nature of content remains
an important determinant of the quality of a WebApp.
 Continuous evolution. Unlike conventional application software that
evolves over a series of planned, chronologically-spaced releases, Web
applications evolve continuously.
 Immediacy. Although immediacy—the compelling need to get software
to market quickly—is a characteristic of many application domains,
WebApps often exhibit a time to market that can be a matter of a few
days or weeks.
 Security. Because WebApps are available via network access, it is
difficult, if not impossible, to limit the population of end-users who may
access the application.
 Aesthetics. An undeniable part of the appeal of a WebApp is its look
and feel.
Software Engineering
 Some realities:
 a concerted effort should be made to understand the
problem before a software solution is developed
 design becomes a pivotal activity
 software should exhibit high quality
 software should be maintainable
 The seminal definition:
 [Software engineering is] the establishment and use of
sound engineering principles in order to obtain
economically software that is reliable and works efficiently
on real machines.
 The IEEE definition:
 Software Engineering: (1) The application of a systematic,
disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the
application of engineering to software. (2) The study of
approaches as in (1).
A Layered Technology
tools
methods
process model
a “quality” focus
A Process Framework
Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities
Framework Activities
 Communication
 Planning
 Modeling
 Analysis of requirements
 Design
 Construction
 Code generation
 Testing
 Deployment
Umbrella Activities
 Software project management
 Formal technical reviews
 Software quality assurance
 Software configuration management
 Work product preparation and production
 Reusability management
 Measurement
 Risk management
Adapting a Process Model
 the overall flow of activities, actions, and tasks and the
interdependencies among them
 the degree to which actions and tasks are defined within each
framework activity
 the degree to which work products are identified and required
 the manner which quality assurance activities are applied
 the manner in which project tracking and control activities are
applied
 the overall degree of detail and rigor with which the process is
described
 the degree to which the customer and other stakeholders are
involved with the project
 the level of autonomy given to the software team
 the degree to which team organization and roles are prescribed
The Essence of Practice
 Polya suggests:
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality
assurance).
Understand the Problem
 Who has a stake in the solution to the problem?
That is, who are the stakeholders?
 What are the unknowns? What data, functions,
and features are required to properly solve the
problem?
 Can the problem be compartmentalized? Is it
possible to represent smaller problems that
may be easier to understand?
 Can the problem be represented graphically? Can
an analysis model be created?
Plan the Solution
 Have you seen similar problems before? Are there patterns
that are recognizable in a potential solution? Is there
existing software that implements the data, functions,
and features that are required?
 Has a similar problem been solved? If so, are elements of the
solution reusable?
 Can subproblems be defined? If so, are solutions readily
apparent for the subproblems?
 Can you represent a solution in a manner that leads to
effective implementation? Can a design model be created?
Carry Out the Plan
 Does the solution conform to the plan? Is source
code traceable to the design model?
 Is each component part of the solution provably
correct? Has the design and code been
reviewed, or better, have correctness proofs
been applied to algorithm?
Examine the Result
 Is it possible to test each component part of the
solution? Has a reasonable testing strategy been
implemented?
 Does the solution produce results that conform to
the data, functions, and features that are required?
Has the software been validated against all
stakeholder requirements?
Hooker’s General Principles
 1: The Reason It All Exists
 2: KISS (Keep It Simple, Stupid!)
 3: Maintain the Vision
 4: What You Produce, Others Will Consume
 5: Be Open to the Future
 6: Plan Ahead for Reuse
 7: Think!
Software Myths
 Affect managers, customers (and
other non-technical stakeholders)
and practitioners
 Are believable because they often
have elements of truth,
but …
 Invariably lead to bad decisions,
therefore …
 Insist on reality as you navigate your
way through software engineering
How It all Starts
 SafeHome:
 Every software project is precipitated by some
business need—
• the need to correct a defect in an existing application;
• the need to the need to adapt a ‘legacy system’ to a
changing business environment;
• the need to extend the functions and features of an
existing application, or
• the need to create a new product, service, or system.
Chapter 2
 Process Models

use.
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 25
A Generic Process Model
Process Flow
Identifying a Task Set
 A task set defines the actual work to be done to
accomplish the objectives of a software
engineering action.
 A list of the task to be accomplished
 A list of the work products to be produced
 A list of the quality assurance filters to be applied
Process Patterns
 A process pattern
 describes a process-related problem that is
encountered during software engineering work,
 identifies the environment in which the problem has
been encountered, and
 suggests one or more proven solutions to the
problem.
 Stated in more general terms, a process pattern
provides you with a template [Amb98]—a
consistent method for describing problem
solutions within the context of the software
process.
Process Pattern Types
 Stage patterns—defines a problem associated
with a framework activity for the process.
 Task patterns—defines a problem associated
with a software engineering action or work
task and relevant to successful software
engineering practice
 Phase patterns—define the sequence of
framework activities that occur with the
process, even when the overall flow of
activities is iterative in nature.
Process Assessment and Improvement
 Standard CMMI Assessment Method for Process Improvement
(SCAMPI) — provides a five step process assessment model that incorporates
five phases: initiating, diagnosing, establishing, acting and learning.
 CMM-Based Appraisal for Internal Process Improvement (CBA IPI)
—provides a diagnostic technique for assessing the relative maturity of
a software organization; uses the SEI CMM as the basis for the
assessment [Dun01]
 SPICE—The SPICE (ISO/IEC15504) standard defines a set of
requirements for software process assessment. The intent of the
standard is to assist organizations in developing an objective
evaluation of the efficacy of any defined software process. [ISO08]
 ISO 9001:2000 for Software—a generic standard that applies to any
organization that wants to improve the overall quality of the products,
systems, or services that it provides. Therefore, the standard is directly
applicable to software organizations and companies. [Ant06]
Prescriptive Models
 Prescriptive process models advocate an orderly
approach to software engineering
That leads to a few questions …
 If prescriptive process models strive for structure and
order, are they inappropriate for a software world that
thrives on change?
 Yet, if we reject traditional process models (and the
order they imply) and replace them with something less
structured, do we make it impossible to achieve
coordination and coherence in software work?
The Waterfall Model
Co m m unic a t io n
p ro je c t init ia t io n Planning
re q uire m e n t g a t he rin g estimating Mo d e ling
scheduling
ana lys is Co ns t ru c t io n
tracking
des ign De plo y m e nt
c ode
t es t de liv e ry
s u p po rt
f e e dba c k
The V-Model
The Incremental Model
incre me nt # n
Co m m u n ic a t i o n
Pla n n in g
Mo d e lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n
code De p l o y m e n t
t est d e l i v e ry
fe e db a c k
d e liv e ry o f
incre me nt # 2 n t h in cre me n t
Co m m u n ic a t i o n
Pla n n in g
Mo d e lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n code De p l o y m e n t
t est d e l i v e ry
fe e d b a c k
d e liv e ry o f
incre m e nt # 1 2 n d in cre me n t
Co m m u n i c a t io n
Pla n nin g
Mo d e ling
a n a ly s is C o n s t ru c t i o n
d e s ig n c od e
d e liv e ry o f
De p lo y m e n t
t es t d e l i v e ry
fe e d b a c k
1 st in cre me n t
project calendar t ime

Evolutionary Models: Prototyping
Quick
Q u i c k p la n
Co m m u n ic a t io n plan
communication
Mo d e l in g
Modeling
Qu ic k d e s ig n
Quick design
De p lo ym e n t
Deployment Construction
De liv e ry
delivery
& Fe e d b & ac k
of Co
prototype
n s t ru c t io n
feedback Construction
of
of
p roprototype
t o t ype
Evolutionary Models: The Spiral
planning
estimation
scheduling
risk analysis
communication
modeling
analysis
design
start
deployment
construction
delivery code
feedback test
Evolutionary Models: Concurrent
none
Modeling a ct ivit y
rep res ents the state

Under o f a s oftware eng ineering
activity o r tas k
de ve lopm e nt
Awa it ing
c hange s
Under review
Unde r
re vis ion
Ba s e line d
Done
Still Other Process Models
 Component based development—the process to
apply when reuse is a development objective
 Formal methods—emphasizes the mathematical
specification of requirements
 AOSD—provides a process and methodological
approach for defining, specifying, designing, and
constructing aspects
 Unified Process—a “use-case driven, architecture-
centric, iterative and incremental” software process
closely aligned with the Unified Modeling Language
(UML)
The Unified Process (UP)
Ela b o ra t io n
elaboration
Inc e p t io n
inception
c o ns t ruc t io n
Releas e
t ra ns it io n
s oft ware increm e nt
p ro d uc t io n
UP Phases
UP Phases
Ince pt ion Elaborat ion Const ruct ion Trans it ion Product ion
Workflows
Requirements
Analysis
Design
Implementation
Test
Support
Iterations #1 #2 #n-1 #n
UP Work Products
Ince pt ion phase
Elaborat ion phase

Vis io n d o cu me n t
In it ial u se -case mo d e l
In it ial p ro je ct g lo ssary
Const ruct ion phase
Us e -case mo d e l
In it ial b u sin e ss cas e Su p p le me n t ary re q u ire me n t s
In it ial risk as se ssme n t . in clu d in g n o n -fu n ct io n al De sig n mo d e l
Transit ion phase
Pro je ct p lan , An aly sis mo d e l So ft ware co mp o n e n t s
p h ase s an d it e rat io n s . So ft ware arch it e ct u re In t e g rat e d so ft ware De liv e re d s o ft ware in cre me n t
Bu sin e s s mo d e l, De scrip t io n . in cre me n t Be t a t e s t re p o rt s
if n e ce s sary . Exe cu t ab le arch it e ct u ral Ge n e ral u se r fe e d b ack
Te s t p lan an d p ro ce d u re
On e o r mo re p ro t o t y p e s p ro t o t y p e .
In c e p t i o Te s t case s
n Pre limin ary d e sig n mo d e l Su p p o rt d o cu me n t at io n
Re v ise d risk list u se r man u als
Pro je ct p lan in clu d in g in st allat io n man u als
it e rat io n p lan d e scrip t io n o f cu rre n t
ad ap t e d wo rkflo ws in cre me n t
mile st o n e s
t e ch n ical wo rk p ro d u ct s
Pre limin ary u se r man u al
Personal Software Process (PSP)
 Planning. This activity isolates requirements and develops both size and
resource estimates. In addition, a defect estimate (the number of defects
projected for the work) is made. All metrics are recorded on worksheets or
templates. Finally, development tasks are identified and a project schedule is
created.
 High-level design. External specifications for each component to be constructed
are developed and a component design is created. Prototypes are built when
uncertainty exists. All issues are recorded and tracked.
 High-level design review. Formal verification methods (Chapter 21) are applied
to uncover errors in the design. Metrics are maintained for all important tasks
and work results.
 Development. The component level design is refined and reviewed. Code is
generated, reviewed, compiled, and tested. Metrics are maintained for all
important tasks and work results.
 Postmortem. Using the measures and metrics collected (this is a substantial
amount of data that should be analyzed statistically), the effectiveness of the
process is determined. Measures and metrics should provide guidance for
modifying the process to improve its effectiveness.
Team Software Process (TSP)
 Build self-directed teams that plan and track their work,
establish goals, and own their processes and plans.
These can be pure software teams or integrated product
teams (IPT) of three to about 20 engineers.
 Show managers how to coach and motivate their teams
and how to help them sustain peak performance.
 Accelerate software process improvement by making
CMM Level 5 behavior normal and expected.
 The Capability Maturity Model (CMM), a measure of the
effectiveness of a software process, is discussed in Chapter 30.
 Provide improvement guidance to high-maturity
organizations.
 Facilitate university teaching of industrial-grade team
skills.
Chapter 3
 Agile Development

use.
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman. 45
The Manifesto for
Agile Software Development
“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
•Individuals and interactions over processes
and tools
•Working software over comprehensive
documentation
•Customer collaboration over contract
negotiation
•Responding to change over following a plan
That is, while there is value in the items on the
right, we value the items on the left more.”
Kent Beck et al
What is “Agility”?
 Effective (rapid and adaptive) response to
change
 Effective communication among all stakeholders
 Drawing the customer onto the team
 Organizing a team so that it is in control of the
work performed
Yielding …
 Rapid, incremental delivery of software
Agility and the Cost of Change
An Agile Process
 Is driven by customer descriptions of what is
required (scenarios)
 Recognizes that plans are short-lived
 Develops software iteratively with a heavy
emphasis on construction activities
 Delivers multiple ‘software increments’
 Adapts as changes occur
Agility Principles - I
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive
advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
6. The most efficient and effective method of conveying information
to and within a development team is face–to–face conversation.
Agility Principles - II
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good
design enhances agility.
10. Simplicity – the art of maximizing the amount of work
not done – is essential.
11. The best architectures, requirements, and designs
emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly.
Human Factors
 the process molds to the needs of the people and
team, not the other way around
 key traits must exist among the people on an
agile team and the team itself:
 Competence.
 Common focus.
 Collaboration.
 Decision-making ability.
 Fuzzy problem-solving ability.
 Mutual trust and respect.
 Self-organization.
Extreme Programming (XP)
 The most widely used agile process, originally
proposed by Kent Beck
 XP Planning
 Begins with the creation of “user stories” by listening
 Customer assigns a value to the story.
 Agile team assesses each story and assigns a cost
 Stories are grouped to for a deliverable increment
 A commitment is made on delivery date
 After the first increment “project velocity” is used to
help define subsequent delivery dates for other
increments
 XP Design
 Follows the KIS principle
 Encourage the use of CRC cards (see Chapter 8)
 For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
 Encourages “refactoring”—an iterative refinement of the internal
program design
 XP Coding
 Recommends the construction of a unit test for a story before
coding commences
 Encourages “pair programming”
 XP Testing
 All unit tests are executed daily (whenever code is modified)
 “Acceptance tests” are defined by the customer and executed to
assess customer visible functionality
spike so lut io ns
simp le d esig n
pro t ot yp es
CRC cards
user st ories
values
accep t ance t est crit eria
it erat io n p lan
refact o ring
p air
p rog ramming
Release
soft wa re incre m e nt unit t est
proje ct v e locit y com put e d cont inuous int eg rat io n
accep t ance t est ing

Adaptive Software Development
 Originally proposed by Jim Highsmith
 ASD — distinguishing features
 Mission-driven planning
 Component-based focus
 Uses “time-boxing” (See Chapter 24)
 Explicit consideration of risks
 Emphasizes collaboration for requirements gathering
 Emphasizes “learning” throughout the process
Adaptive Software Development
ad apt ive cycle planning Req uirement s gat hering
uses m issio n st at em ent JAD
pro ject co nst raint s m ini-specs
b asic requirem ent s
t ime-bo xed release p lan
Release
soft wa re incre m e nt
adjus tm e nt s f or subse que nt cy cle s
co mp o nent s imp lement ed / t est ed
focus g roups fo r feedb ack
form al t echnical reviews
po st mo rt ems
Dynamic Systems Development Method
 Promoted by the DSDM Consortium (www.dsdm.org)
 DSDM—distinguishing features
 Similar in most respects to XP and/or ASD
 Nine guiding principles
• Active user involvement is imperative.
• DSDM teams must be empowered to make decisions.
• The focus is on frequent delivery of products.
• Fitness for business purpose is the essential criterion for acceptance of
deliverables.
• Iterative and incremental development is necessary to converge on an accurate
business solution.
• All changes during development are reversible.
• Requirements are baselined at a high level
• Testing is integrated throughout the life-cycle.
Dynamic Systems Development Method
DSDM Life Cycle (with permission of the DSDM consortium)

Scrum
 Originally proposed by Schwaber and Beedle
 Scrum—distinguishing features
 Development work is partitioned into “packets”
 Testing and documentation are on-going as the
product is constructed
 Work occurs in “sprints” and is derived from a
“backlog” of existing requirements
 Meetings are very short and sometimes conducted
without chairs
 “Demos” are delivered to the customer with the time-
box allocated
Scrum
Scrum Proce ss Flow (use d wit h pe rm ission)
Crystal
 Proposed by Cockburn and Highsmith
 Crystal—distinguishing features
 Actually a family of process models that allow
“maneuverability” based on problem characteristics
 Face-to-face communication is emphasized
 Suggests the use of “reflection workshops” to
review the work habits of the team
Feature Driven Development
 Originally proposed by Peter Coad et al
 FDD—distinguishing features
 Emphasis is on defining “features”
• a feature “is a client-valued function that can be
implemented in two weeks or less.”
 Uses a feature template
• <action> the <result> <by | for | of | to> a(n) <object>
 A features list is created and “plan by feature” is
conducted
 Design and construction merge in FDD
Feature Driven Development
Reprinted with permission of Peter Coad
Agile Modeling
 Originally proposed by Scott Ambler
 Suggests a set of agile modeling principles
 Model with a purpose
 Use multiple models
 Travel light
 Content is more important than representation
 Know the models and the tools you use to create them
 Adapt locally
Chapter 4
 Principles that Guide Practice

use.
Software Engineering Knowledge
 You often hear people say that software development
knowledge has a 3-year half-life: half of what you need to
know today will be obsolete within 3 years. In the domain of
technology-related knowledge, that’s probably about right.
But there is another kind of software development knowledge
—a kind that I think of as "software engineering principles"—
that does not have a three-year half-life. These software
engineering principles are likely to serve a professional
programmer throughout his or her career.
Steve McConnell
Principles that Guide Process - I
 Principle #1. Be agile. Whether the process model you choose
is prescriptive or agile, the basic tenets of agile development
should govern your approach.
 Principle #2. Focus on quality at every step. The exit condition
for every process activity, action, and task should focus on the
quality of the work product that has been produced.
 Principle #3. Be ready to adapt. Process is not a religious
experience and dogma has no place in it. When necessary,
adapt your approach to constraints imposed by the problem,
the people, and the project itself.
 Principle #4. Build an effective team. Software engineering
process and practice are important, but the bottom line is
people. Build a self-organizing team that has mutual trust and
respect.
Principles that Guide
Process - II
 Principle #5. Establish mechanisms for communication and
coordination. Projects fail because important information falls
into the cracks and/or stakeholders fail to coordinate their
efforts to create a successful end product.
 Principle #6. Manage change. The approach may be either
formal or informal, but mechanisms must be established to
manage the way changes are requested, assessed, approved
and implemented.
 Principle #7. Assess risk. Lots of things can go wrong as
software is being developed. It’s essential that you establish
contingency plans.
 Principle #8. Create work products that provide value for
others. Create only those work products that provide value for
other process activities, actions or tasks.
Principles that Guide Practice
 Principle #1. Divide and conquer. Stated in a more
technical manner, analysis and design should always
emphasize separation of concerns (SoC).
 Principle #2. Understand the use of abstraction. At it
core, an abstraction is a simplification of some complex
element of a system used to communication meaning in
a single phrase.
 Principle #3. Strive for consistency. A familiar context
makes software easier to use.
 Principle #4. Focus on the transfer of information. Pay
special attention to the analysis, design, construction,
and testing of interfaces.
Principles that Guide Practice
 Principle #5. Build software that exhibits effective
modularity. Separation of concerns (Principle #1)
establishes a philosophy for software. Modularity
provides a mechanism for realizing the philosophy.
 Principle #6. Look for patterns. Brad Appleton [App00]
suggests that: “The goal of patterns within the software
community is to create a body of literature to help
software developers resolve recurring problems
encountered throughout all of software development.
 Principle #7. When possible, represent the problem and
its solution from a number of different perspectives.
 Principle #8. Remember that someone will maintain the
software.
Communication Principles
 Principle #1. Listen. Try to focus on the speaker’s words,
rather than formulating your response to those words.
 Principle # 2. Prepare before you communicate. Spend
the time to understand the problem before you meet with
others.
 Principle # 3. Someone should facilitate the activity.
Every communication meeting should have a leader (a
facilitator) to keep the conversation moving in a
productive direction; (2) to mediate any conflict that does
occur, and (3) to ensure than other principles are followed.
 Principle #4. Face-to-face communication is best. But it
usually works better when some other representation of
the relevant information is present.
Communication Principles
 Principle # 5. Take notes and document decisions. Someone
participating in the communication should serve as a “recorder” and
write down all important points and decisions.
 Principle # 6. Strive for collaboration. Collaboration and consensus
occur when the collective knowledge of members of the team is
combined …
 Principle # 7. Stay focused, modularize your discussion. The more
people involved in any communication, the more likely that discussion
will bounce from one topic to the next.
 Principle # 8. If something is unclear, draw a picture.
 Principle # 9. (a) Once you agree to something, move on; (b) If you
can’t agree to something, move on; (c) If a feature or function is unclear
and cannot be clarified at the moment, move on.
 Principle # 10. Negotiation is not a contest or a game. It works best
when both parties win.
Planning Principles
 Principle #1. Understand the scope of the project. It’s
impossible to use a roadmap if you don’t know where
you’re going. Scope provides the software team with a
destination.
 Principle #2. Involve the customer in the planning
activity. The customer defines priorities and establishes
project constraints.
 Principle #3. Recognize that planning is iterative. A
project plan is never engraved in stone. As work begins,
it very likely that things will change.
 Principle #4. Estimate based on what you know. The
intent of estimation is to provide an indication of effort,
cost, and task duration, based on the team’s current
understanding of the work to be done.
Planning Principles
 Principle #5. Consider risk as you define the plan. If you have
identified risks that have high impact and high probability,
contingency planning is necessary.
 Principle #6. Be realistic. People don’t work 100 percent of every
day.
 Principle #7. Adjust granularity as you define the plan.
Granularity refers to the level of detail that is introduced as a
project plan is developed.
 Principle #8. Define how you intend to ensure quality. The plan
should identify how the software team intends to ensure quality.
 Principle #9. Describe how you intend to accommodate change.
Even the best planning can be obviated by uncontrolled change.
 Principle #10. Track the plan frequently and make adjustments as
required. Software projects fall behind schedule one day at a time.
Modeling Principles
 In software engineering work, two classes of
models can be created:
 Requirements models (also called analysis models)
represent the customer requirements by depicting
the software in three different domains: the
information domain, the functional domain, and the
behavioral domain.
 Design models represent characteristics of the
software that help practitioners to construct it
effectively: the architecture, the user interface, and
component-level detail.
Requirements Modeling Principles
 Principle #1. The information domain of a problem
must be represented and understood.
 Principle #2. The functions that the software performs
must be defined.
 Principle #3. The behavior of the software (as a
consequence of external events) must be represented.
 Principle #4. The models that depict information,
function, and behavior must be partitioned in a manner
that uncovers detail in a layered (or hierarchical)
fashion.
 Principle #5. The analysis task should move from
essential information toward implementation detail.
Design Modeling Principles
 Principle #1. Design should be traceable to the requirements model.
 Principle #2. Always consider the architecture of the system to be
built.
 Principle #3. Design of data is as important as design of processing
functions.
 Principle #5. User interface design should be tuned to the needs of
the end-user. However, in every case, it should stress ease of use.
 Principle #6. Component-level design should be functionally
independent.
 Principle #7. Components should be loosely coupled to one another
and to the external environment.
 Principle #8. Design representations (models) should be easily
understandable.
 Principle #9. The design should be developed iteratively. With each
iteration, the designer should strive for greater simplicity.
Agile Modeling Principles
 Principle #1. The primary goal of the software team is to build software, not
create models.
 Principle #2. Travel light—don’t create more models than you need.
 Principle #3. Strive to produce the simplest model that will describe the problem
or the software.
 Principle #4. Build models in a way that makes them amenable to change.
 Principle #5. Be able to state an explicit purpose for each model that is created.
 Principle #6. Adapt the models you develop to the system at hand.
 Principle #7. Try to build useful models, but forget about building perfect
models.
 Principle #8. Don’t become dogmatic about the syntax of the model. If it
communicates content successfully, representation is secondary.
 Principle #9. If your instincts tell you a model isn’t right even though it seems
okay on paper, you probably have reason to be concerned.
 Principle #10. Get feedback as soon as you can.
Construction Principles
 The construction activity encompasses a set of
coding and testing tasks that lead to
operational software that is ready for delivery
to the customer or end-user.
 Coding principles and concepts are closely
aligned programming style, programming
languages, and programming methods.
 Testing principles and concepts lead to the
design of tests that systematically uncover
different classes of errors and to do so with a
minimum amount of time and effort.
Preparation Principles
 Before you write one line of code, be sure you:
• Understand the problem you’re trying to solve.
• Understand basic design principles and concepts.
• Pick a programming language that meets the needs of
the software to be built and the environment in which
it will operate.
• Select a programming environment that provides tools
that will make your work easier.
• Create a set of unit tests that will be applied once the
component you code is completed.
Coding Principles
 As you begin writing code, be sure you:
• Constrain your algorithms by following structured
programming [Boh00] practice.
• Consider the use of pair programming
• Select data structures that will meet the needs of the design.
• Understand the software architecture and create interfaces
that are consistent with it.
• Keep conditional logic as simple as possible.
• Create nested loops in a way that makes them easily testable.
• Select meaningful variable names and follow other local
coding standards.
• Write code that is self-documenting.
• Create a visual layout (e.g., indentation and blank lines) that
aids understanding.
Validation Principles
 After you’ve completed your first coding pass,
be sure you:
• Conduct a code walkthrough when appropriate.
• Perform unit tests and correct errors you’ve
uncovered.
• Refactor the code.
Testing Principles
 Al Davis [Dav95] suggests the following:
 Principle #1. All tests should be traceable to
customer requirements.
 Principle #2. Tests should be planned long before
testing begins.
 Principle #3. The Pareto principle applies to
software testing.
 Principle #4. Testing should begin “in the small” and
progress toward testing “in the large.”
 Principle #5. Exhaustive testing is not possible.
Deployment Principles
 Principle #1. Customer expectations for the software
must be managed. Too often, the customer expects more
than the team has promised to deliver, and
disappointment occurs immediately.
 Principle #2. A complete delivery package should be
assembled and tested.
 Principle #3. A support regime must be established
before the software is delivered. An end-user expects
responsiveness and accurate information when a
question or problem arises.
 Principle #4. Appropriate instructional materials must
be provided to end-users.
 Principle #5. Buggy software should be fixed first,
delivered later.
Chapter 5
 Understanding Requirements

use.
Requirements Engineering-I
 Inception—ask a set of questions that establish …
 basic understanding of the problem
 the people who want a solution
 the nature of the solution that is desired, and
 the effectiveness of preliminary communication and collaboration
between the customer and the developer
 Elicitation—elicit requirements from all stakeholders
 Elaboration—create an analysis model that identifies data,
function and behavioral requirements
 Negotiation—agree on a deliverable system that is realistic for
developers and customers
Requirements Engineering-II
 Specification—can be any one (or more) of the following:
 A written document
 A set of models
 A formal mathematical
 A collection of user scenarios (use-cases)
 A prototype
 Validation—a review mechanism that looks for
 errors in content or interpretation
 areas where clarification may be required
 missing information
 inconsistencies (a major problem when large products or systems
are engineered)
 conflicting or unrealistic (unachievable) requirements.
 Requirements management
Inception
 Identify stakeholders
 “who else do you think I should talk to?”
 Recognize multiple points of view
 Work toward collaboration
 The first questions
 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful
solution
 Is there another source for the solution that you
need?
Eliciting Requirements
 meetings are conducted and attended by both software engineers
and customers
 rules for preparation and participation are established
 an agenda is suggested
 a "facilitator" (can be a customer, a developer, or an outsider)
controls the meeting
 a "definition mechanism" (can be work sheets, flip charts, or wall
stickers or an electronic bulletin board, chat room or virtual forum)
is used
 the goal is
 to identify the problem
 propose elements of the solution
 negotiate different approaches, and
 specify a preliminary set of solution requirements
Eliciting Requirements
Conduc t FAST
m e e t ings
Ma ke lis t s of
func t ions , c la s s e s
Ma ke lis t s o f
c ons t ra int s , e t c .
form a l priorit iz a t ion?

Elic it re q u ire m e n t s
ye s no
Us e QFD t o inform a lly de fine a c t ors

prio rit iz e priorit iz e
re quire m e nt s re quire m e nt s
dra w us e -c a s e
writ e s c e na rio
dia gra m
Cre a t e Us e -c a s e s
c om ple t e t e m pla t e
Quality Function Deployment
 Function deployment determines the “value”
(as perceived by the customer) of each
function required of the system
 Information deployment identifies data objects
and events
 Task deployment examines the behavior of the
system
 Value analysis determines the relative priority
of requirements
Elicitation Work Products
 a statement of need and feasibility.
 a bounded statement of scope for the system or product.
 a list of customers, users, and other stakeholders who
participated in requirements elicitation
 a description of the system’s technical environment.
 a list of requirements (preferably organized by function)
and the domain constraints that apply to each.
 a set of usage scenarios that provide insight into the use of
the system or product under different operating conditions.
 any prototypes developed to better define requirements.
Building the Analysis Model
 Elements of the analysis model
 Scenario-based elements
• Functional—processing narratives for software functions
• Use-case—descriptions of the interaction between an
“actor” and the system
 Class-based elements
• Implied by scenarios
 Behavioral elements
• State diagram
 Flow-oriented elements
• Data flow diagram
Use-Cases
 A collection of user scenarios that describe the thread of usage of a
system
 Each scenario is described from the point-of-view of an “actor”—a
person or device that interacts with the software in some way
 Each scenario answers the following questions:
 Who is the primary actor, the secondary actor (s)?
 What are the actor’s goals?
 What preconditions should exist before the story begins?
 What main tasks or functions are performed by the actor?
 What extensions might be considered as the story is described?
 What variations in the actor’s interaction are possible?
 What system information will the actor acquire, produce, or change?
 Will the actor have to inform the system about changes in the external
environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected changes?
Use-Case Diagram
Arms / dis a rms
s ys t e m
Ac c e s s e s s ys t e m s e ns ors
via Int e rne t
home ow ne r
Re s ponds t o
a la rm e ve nt
Enc ount e rs a n
e rror c ondit ion
s ys t e m Re c onfigure s s e ns ors
a dminis t ra t or a nd re la t e d
s ys t e m fe a t ure s
Class Diagram
From the SafeHome system …
Sensor
name/id
type
location
area
characteristics
identify()
enable()
disable()
reconfigure ()
State Diagram
Reading
Commands
State name
System status = “ready”
Display msg = “enter cmd”
Display status = steady
State variables
Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input State activities
Analysis Patterns
Pattern name: A descriptor that captures the essence of the pattern.
Intent: Describes what the pattern accomplishes or represents
Motivation: A scenario that illustrates how the pattern can be used to address the problem.
Forces and context: A description of external issues (forces) that can affect how the pattern
is used and also the external issues that will be resolved when the pattern is applied.
Solution: A description of how the pattern is applied to solve the problem with an emphasis
on structural and behavioral issues.
Consequences: Addresses what happens when the pattern is applied and what trade-offs
exist during its application.
Design: Discusses how the analysis pattern can be achieved through the use of known design
patterns.
Known uses: Examples of uses within actual systems.
Related patterns: On e or more analysis patterns that are related to the named pattern
because (1) it is commonly used with the named pattern; (2) it is structurally similar to the
named pattern; (3) it is a variation of the named pattern.
Negotiating Requirements
 Identify the key stakeholders
 These are the people who will be involved in the
negotiation
 Determine each of the stakeholders “win
conditions”
 Win conditions are not always obvious
 Negotiate
 Work toward a set of requirements that lead to “win-
win”
Validating Requirements - I
 Is each requirement consistent with the overall objective for the
system/product?
 Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?
 Is the requirement really necessary or does it represent an add-
on feature that may not be essential to the objective of the
system?
 Is each requirement bounded and unambiguous?
 Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?
 Do any requirements conflict with other requirements?
Validating Requirements - II
 Is each requirement achievable in the technical environment
that will house the system or product?
 Is each requirement testable, once implemented?
 Does the requirements model properly reflect the information,
function and behavior of the system to be built.
 Has the requirements model been “partitioned” in a way that
exposes progressively more detailed information about the
system.
 Have requirements patterns been used to simplify the
requirements model. Have all patterns been properly
validated? Are all patterns consistent with customer
requirements?
Chapter 6
 Requirements Modeling: Scenarios, Information,
and Analysis Classes

use.
Requirements Analysis
 Requirements analysis
 specifies software’s operational characteristics
 indicates software's interface with other system elements
 establishes constraints that software must meet
 Requirements analysis allows the software engineer
(called an analyst or modeler in this role) to:
 elaborate on basic requirements established during earlier
requirement engineering tasks
 build models that depict user scenarios, functional
activities, problem classes and their relationships, system
and class behavior, and the flow of data as it is
transformed.
A Bridge
system
description
analysis
model
design
model
Rules of Thumb
 The model should focus on requirements that are visible
within the problem or business domain. The level of
abstraction should be relatively high.
 Each element of the analysis model should add to an overall
understanding of software requirements and provide insight
into the information domain, function and behavior of the
system.
 Delay consideration of infrastructure and other non-functional
models until design.
 Minimize coupling throughout the system.
 Be certain that the analysis model provides value to all
stakeholders.
 Keep the model as simple as it can be.
Domain Analysis
Software domain analysis is the identification, analysis,
and specification of common requirements from a
specific application domain, typically for reuse on
multiple projects within that application domain . . .
[Object-oriented domain analysis is] the identification,
analysis, and specification of common, reusable
capabilities within a specific application domain, in
terms of common objects, classes, subassemblies, and
frameworks . . .
Donald Firesmith
Domain Analysis
 Define the domain to be investigated.
 Collect a representative sample of applications
in the domain.
 Analyze each application in the sample.
 Develop an analysis model for the objects.
Elements of Requirements Analysis
Scenario-Based Modeling
“[Use-cases] are simply an aid to defining what exists
outside the system (actors) and what should be
performed by the system (use-cases).” Ivar Jacobson
(1) What should we write about?
(2) How much should we write about it?
(3) How detailed should we make our description?
(4) How should we organize the description?
What to Write About?
 Inception and elicitation—provide you with the
information you’ll need to begin writing use cases.
 Requirements gathering meetings, QFD, and other
requirements engineering mechanisms are used to
 identify stakeholders
 define the scope of the problem
 specify overall operational goals
 establish priorities
 outline all known functional requirements, and
 describe the things (objects) that will be manipulated by the
system.
 To begin developing a set of use cases, list the functions
or activities performed by a specific actor.
How Much to Write About?
 As further conversations with the stakeholders
progress, the requirements gathering team
develops use cases for each of the functions
noted.
 In general, use cases are written first in an
informal narrative fashion.
 If more formality is required, the same use
case is rewritten using a structured format
similar to the one proposed.
Use-Cases
 a scenario that describes a “thread of usage” for
a system
 actors represent roles people or devices play as
the system functions
 users can play a number of different roles for a
given scenario
Developing a Use-Case
 What are the main tasks or functions that are performed by
the actor?
 What system information will the the actor acquire,
produce or change?
 Will the actor have to inform the system about changes in
the external environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected
changes?
Use-Case Diagram
Saf e Hom e
Acce s s cam e ra
surve illance via t he cam e ras
Int e rne t
Configure Safe Hom e

s ys t e m param e t e rs
hom e owne r
Se t alarm
Activity Diagram
Supplements the use e nt e r pa ssword
a nd use r ID
case by providing a
graphical valid pass wor ds / ID invalid pas s wor ds / ID
representation of the se le c t ma jor func t ion prompt for re e n try
flow of interaction
ot her f unct ions
m ay als o be
select ed
input t r ies r em ain
within a specific
se le c t surve illa nc e
no input
t r ies r em ain
scenario t hum bnail views s elect a specif ic cam er a
se le c t spe c ific
se le c t c a me ra ic on
c a me ra - t humbna ils
vie w c a me ra out put

in la be lle d window
prompt for
a not he r vie w
exit t his f unct ion s ee anot her cam er a
Swimlane Diagrams
home owne r c a m e ra i n t e rf a c e
Allows the modeler to

represent the flow of e nt e r pa s s word
activities described by the a nd us e r ID
use-case and at the same

time indicate which actor valid p as s wo r d s / ID
(if there are multiple

in valid
p as s wo r d s/ ID
s e le c t m a jor fu nc t ion
actors involved in a o t h er f u n ct io n s prom pt fo r re e nt ry
specific use-case) or
m ay als o b e
s elect ed
analysis class has

in p u t t r ies
s e le c t s urve illa nc e r em ain
responsibility for the n o in p u t

t r ies r em ain
action described by an
activity rectangle t h u m b n ail views s elect a s p ecif ic cam er a
s e le c t s pe c ific
s e le c t c a m e ra ic on
c a m e ra - t h um b na ils
ge ne ra t e vide o
ou tpu t
vie w c a m e ra ou t put p rom p t for

in la be lle d wind ow a not he r vie w
exit t h is
f u n ct io n
see
an o t h er
cam er a
Data Modeling
 examines data objects independently of
processing
 focuses attention on the data domain
 creates a model at the customer’s level
of abstraction
 indicates how data objects relate to one
another
What is a Data Object?
 a representation of almost any composite information that
must be understood by software.
 composite information—something that has a number of
different properties or attributes
 can be an external entity (e.g., anything that produces or
consumes information), a thing (e.g., a report or a display),
an occurrence (e.g., a telephone call) or event (e.g., an
alarm), a role (e.g., salesperson), an organizational unit
(e.g., accounting department), a place (e.g., a warehouse),
or a structure (e.g., a file).
 The description of the data object incorporates the data
object and all of its attributes.
 A data object encapsulates data only—there is no reference
within a data object to operations that act on the data.
Data Objects and Attributes
A data object contains a set of attributes that
act as an aspect, quality, characteristic, or
descriptor of the object
object: automobile
attributes:
make
model
body type
price
options code
What is a Relationship?
 Data objects are connected to one another in
different ways.
 A connection is established between person and car
because the two objects are related.
• A person owns a car
• A person is insured to drive a car
 The relationships owns and insured to drive
define the relevant connections between
person and car.
 Several instances of a relationship can exist
 Objects can be related in many different ways
ERD Notation
One common form:
(0, m)
object1 relationship object 2
(1, 1)
attribute
Another common form:
object1 relationship
object 2
(0, m) (1, 1)
Building an ERD
 Level 1—model all data objects (entities)
and their “connections” to one another
 Level 2—model all entities and
relationships
 Level 3—model all entities, relationships,
and the attributes that provide further depth
The ERD: An Example
request
Customer places
for service
(1,1) (1,m)
(1,1)
standard (1,n) work
task table generates
order
(1,1) (1,1) (1,1)
selected work (1,w)
consists
from
(1,w) tasks of
(1,i)
materials lists
Class-Based Modeling
 Class-based modeling represents:
 objects that the system will manipulate
 operations (also called methods or services) that will
be applied to the objects to effect the manipulation
 relationships (some hierarchical) between the objects
 collaborations that occur between the classes that are
defined.
 The elements of a class-based model include
classes and objects, attributes, operations, CRC
models, collaboration diagrams and packages.
Identifying Analysis Classes
 Examining the usage scenarios developed as
part of the requirements model and perform a
"grammatical parse" [Abb83]
 Classes are determined by underlining each noun or
noun phrase and entering it into a simple table.
 Synonyms should be noted.
 If the class (noun) is required to implement a
solution, then it is part of the solution space;
otherwise, if a class is necessary only to describe a
solution, it is part of the problem space.
 But what should we look for once all of the
nouns have been isolated?
Manifestations of Analysis Classes
 Analysis classes manifest themselves in one of the following
ways:
• External entities (e.g., other systems, devices, people) that produce
or consume information
• Things (e.g, reports, displays, letters, signals) that are part of the
information domain for the problem
• Occurrences or events (e.g., a property transfer or the completion
of a series of robot movements) that occur within the context of
system operation
• Roles (e.g., manager, engineer, salesperson) played by people
who interact with the system
• Organizational units (e.g., division, group, team) that are relevant
to an application
• Places (e.g., manufacturing floor or loading dock) that establish
the context of the problem and the overall function
• Structures (e.g., sensors, four-wheeled vehicles, or computers)
that define a class of objects or related classes of objects
Potential Classes
 Retained information. The potential class will be useful during analysis
only if information about it must be remembered so that the system can
function.
 Needed services. The potential class must have a set of identifiable
operations that can change the value of its attributes in some way.
 Multiple attributes. During requirement analysis, the focus should be on
"major" information; a class with a single attribute may, in fact, be
useful during design, but is probably better represented as an attribute
of another class during the analysis activity.
 Common attributes. A set of attributes can be defined for the potential
class and these attributes apply to all instances of the class.
 Common operations. A set of operations can be defined for the potential
class and these operations apply to all instances of the class.
 Essential requirements. External entities that appear in the problem
space and produce or consume information essential to the operation
of any solution for the system will almost always be defined as classes
in the requirements model.
Defining Attributes
 Attributes describe a class that has been selected
for inclusion in the analysis model.
 build two different classes for professional baseball
players
• For Playing Statistics software: name, position, batting
average, fielding percentage, years played, and games
played might be relevant
• For Pension Fund software: average salary, credit
toward full vesting, pension plan options chosen,
mailing address, and the like.
Defining Operations
 Do a grammatical parse of a processing
narrative and look at the verbs
 Operations can be divided into four broad
categories:
 (1) operations that manipulate data in some way
(e.g., adding, deleting, reformatting, selecting)
 (2) operations that perform a computation
 (3) operations that inquire about the state of an
object, and
 (4) operations that monitor an object for the
occurrence of a controlling event.
CRC Models
 Class-responsibility-collaborator (CRC) modeling
[Wir90] provides a simple means for
identifying and organizing the classes that are
relevant to system or product requirements.
Ambler [Amb95] describes CRC modeling in
the following way:
 A CRC model is really a collection of standard index
cards that represent classes. The cards are divided
into three sections. Along the top of the card you
write the name of the class. In the body of the card
you list the class responsibilities on the left and the
collaborators on the right.
CRC Modeling
Class:
Class:
Description:
Class:
Description:
Class: FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows Wall
shows position of video cameras Camera
Class Types
 Entity classes, also called model or business classes, are
extracted directly from the statement of the problem (e.g.,
FloorPlan and Sensor).
 Boundary classes are used to create the interface (e.g.,
interactive screen or printed reports) that the user sees and
interacts with as the software is used.
 Controller classes manage a “unit of work” [UML03] from start to
finish. That is, controller classes can be designed to manage
 the creation or update of entity objects;
 the instantiation of boundary objects as they obtain information from
entity objects;
 complex communication between sets of objects;
 validation of data communicated between objects or between the
user and the application.
Responsibilities
 System intelligence should be distributed across classes
to best address the needs of the problem
 Each responsibility should be stated as generally as
possible
 Information and the behavior related to it should reside
within the same class
 Information about one thing should be localized with a
single class, not distributed across multiple classes.
 Responsibilities should be shared among related
classes, when appropriate.
Collaborations
 Classes fulfill their responsibilities in one of two ways:
 A class can use its own operations to manipulate its own
attributes, thereby fulfilling a particular responsibility, or
 a class can collaborate with other classes.
 Collaborations identify relationships between classes
 Collaborations are identified by determining whether a class
can fulfill each responsibility itself
 three different generic relationships between classes [WIR90]:
 the is-part-of relationship
 the has-knowledge-of relationship
 the depends-upon relationship
Composite Aggregate Class
Player
PlayerHead PlayerBody PlayerArms PlayerLegs
Associations and Dependencies
 Two analysis classes are often related to one
another in some fashion
 In UML these relationships are called associations
 Associations can be refined by indicating multiplicity
(the term cardinality is used in data modeling
 In many instances, a client-server relationship
exists between two analysis classes.
 In such cases, a client-class depends on the server-
class in some way and a dependency relationship is
established
Multiplicity
Wa ll
1 1 1
is used to build is used to build
1..* 0..* is used to build 0..*
Wa llSe g m e n t Win d o w Do o r
Dependencies
DisplayWindow Camera
<<access>>
{password}
Analysis Packages
 Various elements of the analysis model (e.g., use-cases,
analysis classes) are categorized in a manner that
packages them as a grouping
 The plus sign preceding the analysis class name in each
package indicates that the classes have public visibility
and are therefore accessible from other packages.
 Other symbols can precede an element within a
package. A minus sign indicates that an element is
hidden from all other packages and a # symbol indicates
that an element is accessible only to packages
contained within a given package.
Analysis Packages
p ackag e n ame
Environme nt
+Tree
+Landscape
+Road
+Wall
+Bridge
+Building Rule s OfThe Gam e
+VisualEffect
+Scene +RulesOfMovement
+ConstraintsOnAction
Charact e rs
+Player
+Protagonist
+Antagonist
+SupportingRole
Reviewing the CRC Model
 All participants in the review (of the CRC model) are given a subset of the CRC model
index cards.
 Cards that collaborate should be separated (i.e., no reviewer should have two
cards that collaborate).
 All use-case scenarios (and corresponding use-case diagrams) should be organized
into categories.
 The review leader reads the use-case deliberately.
 As the review leader comes to a named object, she passes a token to the person
holding the corresponding class index card.
 When the token is passed, the holder of the class card is asked to describe the
responsibilities noted on the card.
 The group determines whether one (or more) of the responsibilities satisfies the
use-case requirement.
 If the responsibilities and collaborations noted on the index cards cannot accommodate
the use-case, modifications are made to the cards.
 This may include the definition of new classes (and corresponding CRC index
cards) or the specification of new or revised responsibilities or collaborations on
existing cards.
Chapter 7
 Requirements Modeling: Flow, Behavior,
Patterns, and WebApps

use.
Requirements Modeling Strategies
 One view of requirements modeling, called structured
analysis, considers data and the processes that transform
the data as separate entities.
 Data objects are modeled in a way that defines their
attributes and relationships.
 Processes that manipulate data objects are modeled in a
manner that shows how they transform data as data
objects flow through the system.
 A second approach to analysis modeled, called object-
oriented analysis, focuses on
 the definition of classes and
 the manner in which they collaborate with one another to
effect customer requirements.
Flow-Oriented Modeling
 Represents how data objects are transformed at they

move through the system
 data flow diagram (DFD) is the diagrammatic form that
is used
 Considered by many to be an “old school” approach,
but continues to provide a view of the system that is
unique—it should be used to supplement other analysis
model elements
The Flow Model
Every computer-based system is an
information transform ....
computer
input based output
system
Flow Modeling Notation
external entity
process
data flow
data store
External Entity
A producer or consumer of data
Examples: a person, a device, a sensor
Another example: computer-based

system
Data must always originate somewhere

and must always be sent to something
Process
A data transformer (changes input
to output)
Examples: compute taxes, determine area,

format report, display graph
Data must always be processed in some

way to achieve system function
Data Flow
Data flows through a system, beginning

as input and transformed into output.
base
compute
triangle area
height area
Data Stores
Data is often stored for later use.
sensor #
sensor #, type,
look-up location, age
sensor
report required data
type,
location, age
sensor number
sensor data
Data Flow Diagramming: Guidelines
 all icons must be labeled with meaningful
names
 the DFD evolves through a number of levels
of detail
 always begin with a context level diagram
(also called level 0)
 always show external entities at level 0
 always label data flow arrows
 do not represent procedural logic
Constructing a DFD—I
 review user scenarios and/or the data
model to isolate data objects and use a
grammatical parse to determine
“operations”
 determine external entities (producers
and consumers of data)
 create a level 0 DFD
Level 0 DFD Example
processing
user request requested
video
digital signal
video monitor
processor
video
source NTSC
video signal
Constructing a DFD—II
 write a narrative describing the transform
 parse to determine next level transforms
 “balance” the flow to maintain data flow
continuity
 develop a level 1 DFD
 use a 1:5 (approx.) expansion ratio
The Data Flow Hierarchy
a b
x P y level 0
a c p2
p1
f
p4 b
d 5
p3 e g
level 1
Flow Modeling Notes
 each bubble is refined until it does just
one thing
 the expansion ratio decreases as the
number of levels increase
 most systems require between 3 and 7
levels for an adequate flow model
 a single data flow item (arrow) may be
expanded as levels increase (data
dictionary provides information)
Process Specification (PSPEC)
bubble
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
DFDs: A Look Ahead
analysis model
Maps into
design model
Control Flow Modeling
 Represents “events” and the processes that
manage events
 An “event” is a Boolean condition that can be
ascertained by:
• listing all sensors that are "read" by the software.
• listing all interrupt conditions.
• listing all "switches" that are actuated by an operator.
• listing all data conditions.
• recalling the noun/verb parse that was applied to the
processing narrative, review all "control items" as
possible CSPEC inputs/outputs.
Control Specification (CSPEC)
The CSPEC can be:
state diagram
(sequential spec)
state transition table

combinatorial spec
decision tables
activation tables
Behavioral Modeling
 The behavioral model indicates how software will
respond to external events or stimuli. To create the
model, the analyst must perform the following steps:
• Evaluate all use-cases to fully understand the sequence of
interaction within the system.
• Identify events that drive the interaction sequence and
understand how these events relate to specific objects.
• Create a sequence for each use-case.
• Build a state diagram for the system.
• Review the behavioral model to verify accuracy and
consistency.
State Representations
 In the context of behavioral modeling, two different
characterizations of states must be considered:
 the state of each class as the system performs its function
and
 the state of the system as observed from the outside as the
system performs its function
 The state of a class takes on both passive and active
characteristics [CHA93].
 A passive state is simply the current status of all of an
object’s attributes.
 The active state of an object indicates the current status of
the object as it undergoes a continuing transformation or
processing.
State Diagram for the ControlPanel Class
t ime r < lo cke d Time
t ime r > lo cke d Time locke d
p as s wo rd = in co rre ct
& n u mb e rOfTrie s < maxTrie s
re ad in g comparin g n u mb e rOfTrie s > maxTrie s

ke y h it
p as swo rd
e n t e re d do: va lida t e Pa s s w ord
p ass wo rd = co rre ct
s e le ct in g
act iv at io n s u cce s sfu l
The States of a System
 state—a set of observable circum-
stances that characterizes the behavior
of a system at a given time
 state transition—the movement from one
state to another
 event—an occurrence that causes the
system to exhibit some predictable form
of behavior
 action—process that occurs as a
consequence of making a transition
Behavioral Modeling
 make a list of the different states of a system
(How does the system behave?)
 indicate how the system makes a transition
from one state to another (How does the
system change state?)
 indicate event
 indicate action
 draw a state diagram or a sequence diagram
Sequence Diagram
h o meo wn er co n t ro l p an el syst em sen

s enso
sorsrs
syst em read in g
A
read y
p asswo rd en t ered
req u est lo o ku p
co mp arin g
resu lt
pa s s word = c orre c t
num be rOfTrie s > m a xTrie s req u es t act ivat io n
lo cked
t imer > lo cked Time

A
select in g
act ivat io n su ccessfu l act ivat io n su ccessfu l
Figure 8 .2 7 Se que nc e dia gra m (part ia l) for Saf e Hom e s e c urit y func t ion
Writing the Software Specification
Everyone knew exactly
what had to be done
until someone wrote it
down!
Patterns for Requirements Modeling
 Software patterns are a mechanism for capturing
domain knowledge in a way that allows it to be
reapplied when a new problem is encountered
 domain knowledge can be applied to a new problem
within the same application domain
 the domain knowledge captured by a pattern can be
applied by analogy to a completely different application
domain.
 The original author of an analysis pattern does not
“create” the pattern, but rather, discovers it as
requirements engineering work is being conducted.
 Once the pattern has been discovered, it is documented
Discovering Analysis Patterns
 The most basic element in the description of a
requirements model is the use case.
 A coherent set of use cases may serve as the
basis for discovering one or more analysis
patterns.
 A semantic analysis pattern (SAP) “is a pattern that
describes a small set of coherent use cases that
together describe a basic generic application.”
[Fer00]
Requirements Modeling for WebApps
Content Analysis. The full spectrum of content to be provided by
the WebApp is identified, including text, graphics and images,
video, and audio data. Data modeling can be used to identify
and describe each of the data objects.
Interaction Analysis. The manner in which the user interacts with
the WebApp is described in detail. Use-cases can be
developed to provide detailed descriptions of this interaction.
Functional Analysis. The usage scenarios (use-cases) created as
part of interaction analysis define the operations that will be
applied to WebApp content and imply other processing
functions. All operations and functions are described in detail.
Configuration Analysis. The environment and infrastructure in
which the WebApp resides are described in detail.
When Do We Perform Analysis?
 In some WebE situations, analysis and design
merge. However, an explicit analysis activity
occurs when …
 the WebApp to be built is large and/or complex
 the number of stakeholders is large
 the number of Web engineers and other contributors
is large
 the goals and objectives (determined during
formulation) for the WebApp will effect the business’
bottom line
 the success of the WebApp will have a strong
bearing on the success of the business
The Content Model
 Content objects are extracted from use-cases
 examine the scenario description for direct and
indirect references to content
 Attributes of each content object are identified
 The relationships among content objects
and/or the hierarchy of content maintained by a
WebApp
 Relationships—entity-relationship diagram or UML
 Hierarchy—data tree or UML
Data Tree
Ma rke t ingDe s c ript ion
Phot ograph
pa rt Numbe r
Te c hDe s c ript ion

pa rt Na me
c ompone nt Sc he ma t ic
pa rt Type
Vide o
de s c ript ion
pric e
Whole s a le Pric e
Ret a ilPric e
Fig u re 1 8 . 3 Da t a t re e fo r aS a fe Ho m e c o m p o n e n t
The Interaction Model
 Composed of four elements:
use-cases
 sequence diagrams
 state diagrams
 a user interface prototype
 Each of these is an important UML notation

and is described in Appendix I
Sequence Diagram
:Produc t :Billof FloorPla n BoM
:Room :FloorPla n
Compone nt Ma t e ria ls Re pos it ory Re pos it ory
new cust o mer
d e sc rib e s
ro o m *
p la c e s ro o m
in f lo o r p la n
sa v e f lo o r p la n c o n f ig u ra t io n
se le c t s p ro d u c t c o m p o n e n t *
a d d t o Bo M
sa v e b ill o f m a t e ria ls
Figure 18.5 Se que nce diagram for use -case :se le ct Saf e Hom e com pone nt s
State Diagram
Va lida t ing use r Se le ct ing use r a ct ion
use rid se le c t ot he r func t ions
syst e m st a t us=“input re a dy” va lida t e d syst e m st a t us=“link re a dy”
se le ct “log-in” displa y msg = “e nt e ruse rid” displa y: na viga t ion choice s”
displa y msg =“e nt e r pswd”
pa ssword va lida t e d
e nt ry/ va lida t e d use r
e nt ry/ log-in re que st e d
n e w cu st o m e r do: link a s re quire d
do: run use r va lida t ion
e xit / use r a ct ion se le ct e d
e xit / se t use r a cce ss swit ch
c ust omiz a t ion c omple t e

se le c t e -c omme rc e (purc ha se ) func t iona lit y
se le c t c ust omiz a t ion func t iona lit y
ne xt se le ct ion
Sa ving floor pla n
Cust omiz ing se le ct de script ive
cont e nt sy st e m st a t us=“input re a d y”
syst e m st a t us=“input re a dy” De fining room se le ct de script ive displa y: st ora ge indica t or
displa y: ba sic inst ruct ions cont e nt
room be ing de fine d syst e m st a t us=“input re a dy” e nt ry/ flo or pla n sa ve se le cte d
displa y: roomde f. window do: st ore flo or pla n
e nt ry/ va lida t e d use r e xit / sa v e comple t e d
do: proce ss use r se le ct ion
e nt ry/ roomde f. se le ct e d
e xit / cust omiz a t ion t e rmina t e d a ll rooms do: run room que rie s
de fine d do: st ore room va ria ble s
e xit / room comple t e d
Building floor p la n se le ct de script iv e

se le ct sa ve floor pla n
cont e nt
syst e m st a t us=“input re a dy”
se le ct e nt e r room in floor pla n displa y: floor p la n window
e nt ry/ floor pla n se le cte d

do: inse rt room in pla ce
do: st ore floor pla n va ria ble s
e xit / room inse rtion comple t e d
room inse rt ion comple t e d
Figure 1 8 .6 Pa rt ia l s t a t e dia gra m for n e w c u s t o m eintr e ra c t ion
The Functional Model
 The functional model addresses two
processing elements of the WebApp
 user observable functionality that is delivered by the
WebApp to end-users
 the operations contained within analysis classes that
implement behaviors associated with the class.
 An activity diagram can be used to represent
processing flow
Activity Diagram
init ialize t ot alCos t
no c omp one nt s re ma in o nBoMList c omp one nt s re ma in o n Bo MList
invoke g et price and

calcShipping Cost quant it y
ret urns:
shipping Cost
lineCos t =
price x quant it y
invoke
det erm ineDiscount
ret urns : discount add lineCos t t o

t ot alCos t
d isc o unt >0

t ot alCost=
t ot alCost - discount
d isc oun t < = 0
t axTot al=
t ot alCost x t axrat e
priceTot al =
t ot alCost + t axTot al
+ shipping Cos t
Figure 1 8 .7 Ac t ivit y dia gra m for c o m p u t e Pr i (c )e o p e r a t i o n
The Configuration Model
 Server-side
 Server hardware and operating system environment
must be specified
 Interoperability considerations on the server-side
must be considered
 Appropriate interfaces, communication protocols and
related collaborative information must be specified
 Client-side
 Browser configuration issues must be identified
 Testing requirements should be defined
Navigation Modeling-I
 Should certain elements be easier to reach (require
fewer navigation steps) than others? What is the priority
for presentation?
 Should certain elements be emphasized to force users
to navigate in their direction?
 How should navigation errors be handled?
 Should navigation to related groups of elements be
given priority over navigation to a specific element.
 Should navigation be accomplished via links, via search-
based access, or by some other means?
 Should certain elements be presented to users based on
the context of previous navigation actions?
 Should a navigation log be maintained for users?
Navigation Modeling-II
 Should a full navigation map or menu (as opposed to a single
“back” link or directed pointer) be available at every point in a
user’s interaction?
 Should navigation design be driven by the most commonly
expected user behaviors or by the perceived importance of the
defined WebApp elements?
 Can a user “store” his previous navigation through the WebApp
to expedite future usage?
 For which user category should optimal navigation be
designed?
 How should links external to the WebApp be handled?
overlaying the existing browser window? as a new browser
window? as a separate frame?
Chapter 9
 Architectural Design

use.
Why Architecture?
The architecture is not the operational software. Rather,
it is a representation that enables a software engineer
to:
(1) analyze the effectiveness of the design in meeting its
stated requirements,
(2) consider architectural alternatives at a stage when
making design changes is still relatively easy, and
(3) reduce the risks associated with the construction of
the software.
Why is Architecture Important?
 Representations of software architecture are an enabler
for communication between all parties (stakeholders)
interested in the development of a computer-based
system.
 The architecture highlights early design decisions that
will have a profound impact on all software engineering
work that follows and, as important, on the ultimate
success of the system as an operational entity.
 Architecture “constitutes a relatively small, intellectually
graspable mode of how the system is structured and
how its components work together” [BAS03].
Architectural Descriptions
 The IEEE Computer Society has proposed IEEE-Std-
1471-2000, Recommended Practice for Architectural
Description of Software-Intensive System, [IEE00]
 to establish a conceptual framework and vocabulary for use
during the design of software architecture,
 to provide detailed guidelines for representing an architectural
description, and
 to encourage sound architectural design practices.
 The IEEE Standard defines an architectural description (AD)
as a “a collection of products to document an architecture.”
 The description itself is represented using multiple views, where
each view is “a representation of a whole system from the
perspective of a related set of [stakeholder] concerns.”
Architectural Genres
 Genre implies a specific category within the
overall software domain.
 Within each category, you encounter a number
of subcategories.
 For example, within the genre of buildings, you
would encounter the following general styles:
houses, condos, apartment buildings, office
buildings, industrial building, warehouses, and so
on.
 Within each general style, more specific styles might
apply. Each style would have a structure that can be
described using a set of predictable patterns.
Architectural Styles
Each style describes a system category that encompasses: (1) a
set of components (e.g., a database, computational modules)
that perform a function required by a system, (2) a set of
connectors that enable “communication, coordination and
cooperation” among components, (3) constraints that define
how components can be integrated to form the system, and
(4) semantic models that enable a designer to understand the
overall properties of a system by analyzing the known
properties of its constituent parts.
 Data-centered architectures
 Data flow architectures
 Call and return architectures
 Object-oriented architectures
 Layered architectures
Data-Centered Architecture
Data Flow Architecture
Call and Return Architecture
Layered Architecture
Architectural Patterns
 Concurrency—applications must handle multiple tasks in a
manner that simulates parallelism
 operating system process management pattern
 task scheduler pattern
 Persistence—Data persists if it survives past the execution of
the process that created it. Two patterns are common:
 a database management system pattern that applies the storage
and retrieval capability of a DBMS to the application architecture
 an application level persistence pattern that builds persistence
features into the application architecture
 Distribution— the manner in which systems or components
within systems communicate with one another in a distributed
environment
 A broker acts as a ‘middle-man’ between the client component and
a server component.
Architectural Design
 The software must be placed into context
 the design should define the external entities (other
systems, devices, people) that the software interacts
with and the nature of the interaction
 A set of architectural archetypes should be
identified
 An archetype is an abstraction (similar to a class)
that represents one element of system behavior
 The designer specifies the structure of the
system by defining and refining software
components that implement each archetype
Architectural Context
Safehome Internet-based
Product system
control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses
uses
sensors sensors
Archetypes
Cont ro lle r
com m unicat e s wit h
Node
De t e ct or Indicat or
These slides are designed toFigure

accompany
10.7 UML Software Engineering:
re lat ionships A ePractitioner’s
for Safe Hom Approach,
se curit y funct ion arche t ype 7/e
s
(McGraw-Hill, 2009). Slides copyright 2009
(adapt e d from by Roger Pressman.
[BOS00]) 196
Component Structure
Safe Hom e
Execut ive
Funct ion
sele ct ion
Ext e rn al
Co mmu n icat io n
Man ag e me n t
Securit y Surveillance Hom e

m anagem e nt
GUI Int e rnet

Int erfac e
Cont rol de t e c t or a larm

pa ne l ma na ge me nt proc es s ing
proc e s s ing
Refined Component Structure
SafeHo me
Executive
Ext e rna l
Communic a t ion
Ma na ge me nt
Security
GUI Internet
Interface
Co n t ro l d e t e ct o r alarm
p an e l m an ag e m e n t p ro ce ssin g
p ro ce ss in g
Ke y p ad
p ro ce ss in g phone
sch e d u le r
co m m u n icat io n
CP d isp lay
fu n ct io n s
alarm
ssse
se
nso
eennnsos orrr
so
r
sse
e nnsso o rr
s se
e nns so
orr
se n so r
Analyzing Architectural Design
1. Collect scenarios.
2. Elicit requirements, constraints, and environment description.
3. Describe the architectural styles/patterns that have been chosen
to address the scenarios and requirements:
• module view
• process view
• data flow view
4. Evaluate quality attributes by considered each attribute in
isolation.
5. Identify the sensitivity of quality attributes to various
architectural attributes for a specific architectural style.
6. Critique candidate architectures (developed in step 3) using the
sensitivity analysis conducted in step 5.
Architectural Complexity
 the overall complexity of a proposed
architecture is assessed by considering the
dependencies between components within the
architecture [Zha98]
 Sharing dependencies represent dependence
relationships among consumers who use the same
resource or producers who produce for the same
consumers.
 Flow dependencies represent dependence relationships
between producers and consumers of resources.
 Constrained dependencies represent constraints on the
relative flow of control among a set of activities.
ADL
 Architectural description language (ADL) provides
a semantics and syntax for describing a software
architecture
 Provide the designer with the ability to:
 decompose architectural components
 compose individual components into larger architectural
blocks and
 represent interfaces (connection mechanisms) between
components.
An Architectural Design Method
customer requirements
"four bedrooms, three baths,
lots of glass ..."
architectural design
Deriving Program Architecture
Program
Architecture
Partitioning the Architecture
 “horizontal” and “vertical” partitioning are
required
Horizontal Partitioning
 define separate branches of the module
hierarchy for each major function
 use control modules to coordinate
communication between functions
function 1 function 3
function 2
Vertical Partitioning: Factoring
 design so that decision making and work
are stratified
 decision making modules should reside at
the top of the architecture
decision-makers
workers
Why Partitioned Architecture?
 results in software that is easier to test
 leads to software that is easier to maintain
 results in propagation of fewer side effects
 results in software that is easier to extend
Structured Design
 objective: to derive a program
architecture that is partitioned
 approach:
 a DFD is mapped into a program
architecture
 the PSPEC and STD are used to
indicate the content of each module
 notation: structure chart
Flow Characteristics
Transform flow
This edition of
SEPA does not
cover transaction
mapping. For a
detailed
discussion see the
SEPA website
Transaction
flow
General Mapping Approach
isolate incoming and outgoing flow
boundaries; for transaction flows, isolate
the transaction center
working from the boundary outward, map

DFD transforms into corresponding modules
add control modules as required
refine the resultant program structure

using effective modularity concepts
General Mapping Approach
 Isolate the transform center by specifying incoming
and outgoing flow boundaries
 Perform "first-level factoring.”
 The program architecture derived using this mapping
results in a top-down distribution of control.
 Factoring leads to a program structure in which top-level
components perform decision-making and low-level
components perform most input, computation, and output
work.
 Middle-level components perform some control and do
moderate amounts of work.
 Perform "second-level factoring."
Transform Mapping
b g h
a e f
d
c i
j
data flow model
x1 "Transform" mapping
x2 x3 x4
b c d e f g i
a h j
Factoring
direction of increasing
decision making typical "decision
making" modules
typical "worker" modules
First Level Factoring
main
program
controller
input processing output

controller controller controller
Second Level Mapping
main
D
C
control
B A
A
B
C
mapping from the D

flow boundary outward
Chapter 10
 Component-Level Design

use.
What is a Component?
 OMG Unified Modeling Language Specification [OMG01]
defines a component as
 “… a modular, deployable, and replaceable part of a
system that encapsulates implementation and exposes a
set of interfaces.””
 OO view: a component contains a set of collaborating
classes
 Conventional view: a component contains processing
logic, the internal data structures that are required to
implement the processing logic, and an interface that
enables the component to be invoked and data to be
passed to it.
OO Component a n a ly sis c la ss
P rin t J o b
n u m b e rO f Pa g e s
n u m b e rO f Sid e s
p a p e rTy p e
m a g n if ic a t io n
p ro d u c t io n F e a t u re s
d e sig n c o m p o n e n t
c o m p u t e Jo b Co st( ) c o m p u t e Jo b
p a s sJ o b t o Prin t e r( )
P rin t J o b
in it ia t e Jo b
< < in t er f ace> >

e la bora te d de s ign c las s
co m p u t eJ o b
Print J ob
comput ePageCos t ( ) number Of Pages
comput ePaper Cos t ( ) number Of Sides
comput ePr odCos t ( ) paper Type
comput eTot alJ obCos t ( ) paper Weight
paper Size
paper Color
magnif icat ion
color Requir ement s
pr oduct ionFeat ur es
collat ionOpt ions
bindingOpt ions
cover St ock
< < in t er f ace> > bleed
in it iat eJ o b pr ior it y
t ot alJobCost
buildWor kOr der ( ) WOnumber
checkPr ior it y ( )
passJ obt o Pr oduct ion( )
comput ePageCos t ( )
comput ePaper Cost ( )
comput ePr odCos t ( )
comput eTot alJobCos t ( )
buildWor kOr der ( )
checkPr ior it y ( )
pas s J obt o Pr oduct ion( )
Conventional Component
d esig n co m p o nent
g etJo b Data
Co mp utePag eCo st
accessCo stsDB
elab o rated m o d ule
Pag eCo st
in: numberPages
in: numberDocs
in: s ides = 1 , 2
in: color=1 , 2 , 3 , 4
in: page s ize = A, B, C, B
out : page cos t
in: job s ize
in: color=1 , 2 , 3 , 4
in: pageSize = A, B, C, B
out : BPC
out : SF
g e t Jo b Dat a ( n u m b e rP ag e s, n u m b e rDo cs ,
s id e s , co lo r, p ag e Size , p ag e Co st ) jo b s ize ( J S) =
acce ss Co s t sDB (jo b Size , co lo r, p ag e Size , n u m b e rPag e s * n u m b e rDo cs;
BPC, SF) lo o ku p b as e p ag e co s t ( BPC) -->
co m p u t e Pag e Co s t( ) acce ssCo st sDB ( JS, co lo r) ;
lo o ku p size fact o r ( SF) -->
acce ssCo st DB ( J S, co lo r, s ize )
jo b co m p le xit y fact o r ( J CF) =
1 + [ ( sid e s -1 ) * s id e Co s t + SF]
p ag e co st = BPC * JCF
Basic Design Principles
 The Open-Closed Principle (OCP). “A module [component]
should be open for extension but closed for modification.
 The Liskov Substitution Principle (LSP). “Subclasses should be
substitutable for their base classes.
 Dependency Inversion Principle (DIP). “Depend on abstractions.
Do not depend on concretions.”
 The Interface Segregation Principle (ISP). “Many client-specific
interfaces are better than one general purpose interface.
 The Release Reuse Equivalency Principle (REP). “The granule of
reuse is the granule of release.”
 The Common Closure Principle (CCP). “Classes that change
together belong together.”
 The Common Reuse Principle (CRP). “Classes that aren’t reused
together should not be grouped together.”
Source: Martin, R., “Design Principles and Design Patterns,” downloaded from http:www.objectmentor.com, 2000.
Design Guidelines
 Components
 Naming conventions should be established for
components that are specified as part of the
architectural model and then refined and elaborated
as part of the component-level model
 Interfaces
 Interfaces provide important information about
communication and collaboration (as well as helping
us to achieve the OPC)
 Dependencies and Inheritance
 it is a good idea to model dependencies from left to
right and inheritance from bottom (derived classes)
to top (base classes).
Cohesion
 Conventional view:
 the “single-mindedness” of a module
 OO view:
 cohesion implies that a component or class encapsulates
only attributes and operations that are closely related to one
another and to the class or component itself
 Levels of cohesion
 Functional
 Layer
 Communicational
 Sequential
 Procedural
 Temporal
 utility
Coupling
 Conventional view:
 The degree to which a component is connected to other
components and to the external world
 OO view:
 a qualitative measure of the degree to which classes are
connected to one another
 Level of coupling
 Content
 Common
 Control
 Stamp
 Data
 Routine call
 Type use
 Inclusion or import
 External
Component Level Design-I
 Step 1. Identify all design classes that correspond to
the problem domain.
 Step 2. Identify all design classes that correspond to
the infrastructure domain.
 Step 3. Elaborate all design classes that are not
acquired as reusable components.
 Step 3a. Specify message details when classes or
component collaborate.
 Step 3b. Identify appropriate interfaces for each
component.
Component-Level Design-II
 Step 3c. Elaborate attributes and define data types
and data structures required to implement them.
 Step 3d. Describe processing flow within each
operation in detail.
 Step 4. Describe persistent data sources (databases
and files) and identify the classes required to manage
them.
 Step 5. Develop and elaborate behavioral
representations for a class or component.
 Step 6. Elaborate deployment diagrams to provide
additional implementation detail.
 Step 7. Factor every component-level design
representation and always consider alternatives.
Collaboration Diagram
:ProductionJob
1: buildJob ( WOnumber )
2: submitJob ( WOnumber )
:WorkOrder
:JobQueue
Refactoring
comp uteJo b
PrintJo b
initiateJo b
Wo rkOrd er
ap p ro p riat e at t rib u t e s <<interface>>

g etJo b Descriip tio n b uild Jo b initiateJo b
b uild Wo rkOrd er ()
p assJ o b To Pro d u ct io n ( )
Pro d uctio nJ ob
sub mitJo b
Jo b Queue
ap p ro p riat e at t rib u t e s
checkPrio rity ()
Activity Diagram va lida t e a t t ribut e s
input
a c c e s s Pa pe rDB (we ight )
re t urns ba s e C os t pe rPa ge
pa pe rC os t pe rPa ge =
ba s e C os t pe rPa ge
s iz e = B pa pe rC os t pe rPa ge =
pa pe rC os t pe rPa ge *1 . 2
s iz e = C pa pe rC os t pe rPa ge =
s iz e = D pa pe rC os t pe rPa ge =
c olor is c us t om
pa pe rC os t pe rPa ge =
pa pe rC os t pe rPa ge *1 . 1 4
c olor is s t a nda rd
re t urns
( pa pe rC os t pe rPa ge )
b eh avio r w it h in t h e
Statechart
st at e b u ild in g Jo b Dat a
d at aIn p u t In co mp let e
buildingJ obDa t a
e nt ry/ re a dJ obDa t a ()
e xit / dis pla yJ obDa t a ()
do/ c he c kCons is t e nc y()
inc lude / da t a Input
d at aIn p u t Co mp let ed [ all d at a

it ems co n sist en t ] / d isp layUserOp t io n s
c omput ingJ obCos t
e nt ry/ c omput e J ob
e xit / s a ve t ot a lJ obCos t
jo b Co st Accep t ed [ cu st o mer is au t h o rized ] /

g et Elect ro n icSig n at u re
formingJ ob
e nt ry/ buildJ ob
e xit / s a ve WOnumbe r
do/
s ubmit t ingJ ob
e nt ry/ s ubmit J ob
e xit / init ia t e J ob
do/ pla c e on J obQue ue
jo b S u b mit t ed[ all au t h o rizat io n s acq u ired ] /

p rin t Wo rkOrd er
Component Design for WebApps
 WebApp component is
 (1) a well-defined cohesive function that manipulates
content or provides computational or data
processing for an end-user, or
 (2) a cohesive package of content and functionality
that provides end-user with some required
capability.
 Therefore, component-level design for
WebApps often incorporates elements of
content design and functional design.
Content Design for WebApps
 focuses on content objects and the manner in which they
may be packaged for presentation to a WebApp end-
user
 consider a Web-based video surveillance capability
within SafeHomeAssured.com
 potential content components can be defined for the video
surveillance capability:
• (1) the content objects that represent the space layout (the
floor plan) with additional icons representing the location of
sensors and video cameras;
• (2) the collection of thumbnail video captures (each an
separate data object), and
• (3) the streaming video window for a specific camera.
 Each of these components can be separately named and
manipulated as a package.
Functional Design for WebApps
 Modern Web applications deliver increasingly
sophisticated processing functions that:
 (1) perform localized processing to generate content and
navigation capability in a dynamic fashion;
 (2) provide computation or data processing capability that
is appropriate for the WebApp’s business domain;
 (3) provide sophisticated database query and access, or
 (4) establish data interfaces with external corporate
systems.
 To achieve these (and many other) capabilities, you will
design and construct WebApp functional components
that are identical in form to software components for
conventional software.
Designing Conventional Components
 The design of processing logic is governed by
the basic principles of algorithm design and
structured programming
 The design of data structures is defined by the
data model developed for the system
 The design of interfaces is governed by the
collaborations that a component must effect
Algorithm Design
 the closest design activity to coding
 the approach:
 review the design description for the
component
 use stepwise refinement to develop algorithm
 use structured programming to implement
procedural logic
 use ‘formal methods’ to prove logic
Stepwise Refinement
open
walk to door;
reach for knob;
open door; repeat until door opens
turn knob clockwise;
walk through; if knob doesn't turn, then
close door. take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
Algorithm Design Model
 represents the algorithm at a level of detail
that can be reviewed for quality
 options:
 graphical (e.g. flowchart, box diagram)
 pseudocode (e.g., PDL) ... choice of many
 programming language
 decision table
Structured Programming
uses a limited set of logical constructs:
sequence
conditional — if-then-else, select-case
loops — do-while, repeat until
leads to more readable, testable code

can be used in conjunction with ‘proof of
correctness’
important for achieving high quality,
but not enough
A Structured Procedural Design
add a condition Z,
a if true, exit the program
x1
b x2 c
x3 d
f e
x4
x5
Decision Table
Ru le s
Co n d it io n s 1 2 3 4 5 6
re gular cust om e r T T
silve r cust om e r T T
gold cust om e r T T
spe cial discount F T F T F T
Ru le s
no discount
apply 8 pe rce nt discount
apply 15 pe rce nt discount
apply addit ional x pe rce nt discount
Program Design Language (PDL)
if condition x
then process a;
else process b;
endif
if-then-else PDL
easy to combine with source code
machine readable, no need for graphics input
graphics can be generated from PDL
enables declaration of data as well as procedure
easier to maintain
Why Design Language?
can be a derivative of the HOL of choice
e.g., Ada PDL
machine readable and processable
can be embedded with source code,

therefore easier to maintain
can be represented in great detail, if

designer and coder are different
easy to review
Component-Based Development
 When faced with the possibility of reuse, the
software team asks:
 Are commercial off-the-shelf (COTS) components
available to implement the requirement?
 Are internally-developed reusable components
available to implement the requirement?
 Are the interfaces for available components
compatible within the architecture of the system to be
built?
 At the same time, they are faced with the
following impediments to reuse ...
Impediments to Reuse
 Few companies and organizations have anything that even slightly
resembles a comprehensive software reusability plan.
 Although an increasing number of software vendors currently sell
tools or components that provide direct assistance for software
reuse, the majority of software developers do not use them.
 Relatively little training is available to help software engineers and
managers understand and apply reuse.
 Many software practitioners continue to believe that reuse is “more
trouble than it’s worth.”
 Many companies continue to encourage of software development
methodologies which do not facilitate reuse
 Few companies provide an incentives to produce reusable program
components.
The CBSE Process
Domain Engineering
Software Reusable
Domain
Analysis Architecture Artifact
Development Development
Repository
Domain Structural Reusable
model Model Artifacts/
Components
System Specification
Analysis & Construction
User Design
Requirements
Analysis
System Application
& Design
Spec Models Software
Domain Engineering
1. Define the domain to be investigated.
2. Categorize the items extracted from the
domain.
3. Collect a representative sample of
applications in the domain.
4. Analyze each application in the sample.
5. Develop an analysis model for the objects.
Identifying Reusable Components
• Is component functionality required on future implementations?
• How common is the component's function within the domain?
• Is there duplication of the component's function within the
domain?
• Is the component hardware-dependent?
• Does the hardware remain unchanged between implementations?
• Can the hardware specifics be removed to another component?
• Is the design optimized enough for the next implementation?
• Can we parameterize a non-reusable component so that it becomes
reusable?
• Is the component reusable in many implementations with only
minor changes?
• Is reuse through modification feasible?
• Can a non-reusable component be decomposed to yield reusable
components?
• How valid is component decomposition for reuse?
Component-Based SE
 a library of components must be available
 components should have a consistent
structure
 a standard should exist, e.g.,
 OMG/CORBA
 Microsoft COM
 Sun JavaBeans
CBSE Activities
 Component qualification
 Component adaptation
 Component composition
 Component update
Qualification
Before a component can be used, you must consider:
• application programming interface (API)

• development and integration tools required by the
component
• run-time requirements including resource usage (e.g.,
memory or storage), timing or speed, and network protocol
• service requirements including operating system interfaces
and support from other components
• security features including access controls and authentication
protocol
• embedded design assumptions including the use of specific
numerical or non-numerical algorithms
• exception handling
Adaptation
The implication of “easy integration” is:
(1) that consistent methods of resource
management have been implemented for all
components in the library;
(2) that common activities such as data
management exist for all components, and
(3) that interfaces within the architecture and
with the external environment have been
implemented in a consistent manner.
Composition
 An infrastructure must be established to bind
components together
 Architectural ingredients for composition include:
 Data exchange model
 Automation
 Structured storage
 Underlying object model
OMG/ CORBA
 The Object Management Group has published a common
object request broker architecture (OMG/CORBA).
 An object request broker (ORB) provides services that
enable reusable components (objects) to communicate with
other components, regardless of their location within a
system.
 Integration of CORBA components (without modification)
within a system is assured if an interface definition
language (IDL) interface is created for every component.
 Objects within the client application request one or more
services from the ORB server. Requests are made via an
IDL or dynamically at run time.
 An interface repository contains all necessary information
about the service’s request and response formats.
ORB Architecture
Interface Client
Repository
Client
Dynamic ORB
IDL
Invocation interface
Stubs
Server
LAN
Objects
ORB Core
ORB Server Object

interface IDL Adapter
Stubs Interface
Repository
Microsoft COM
 The component object model (COM) provides a
specification for using components produced by
various vendors within a single application running
under the Windows operating system.
 COM encompasses two elements:
 COM interfaces (implemented as COM objects)
 a set of mechanisms for registering and passing messages
between COM interfaces.
Sun JavaBeans
 The JavaBeans component system is a portable,
platform independent CBSE infrastructure
developed using the Java programming language.
 The JavaBeans component system encompasses a
set of tools, called the Bean Development Kit
(BDK), that allows developers to
 analyze how existing Beans (components) work
 customize their behavior and appearance
 establish mechanisms for coordination and
communication
 develop custom Beans for use in a specific application
 test and evaluate Bean behavior.
Classification
 Enumerated classification—components are
described by defining a hierarchical structure
in which classes and varying levels of
subclasses of software components are
defined
 Faceted classification—a domain area is
analyzed and a set of basic descriptive
features are identified
 Attribute-value classification—a set of
attributes are defined for all components in a
domain area
Indexing
The Reuse Environment
 A component database capable of storing software
components and the classification information
necessary to retrieve them.
 A library management system that provides access
to the database.
 A software component retrieval system (e.g., an
object request broker) that enables a client
application to retrieve components and services
from the library server.
 CBSE tools that support the integration of reused
components into a new design or implementation.
Chapter 11
 User Interface Design

use.
Interface Design
Easy to learn?
Easy to use?
Easy to understand?
Interface Design
Typical Design Errors
lack of consistency
too much memorization
no guidance / help
no context sensitivity
poor response
Arcane/unfriendly
Golden Rules
 Place the user in control

 Reduce the user’s memory load
 Make the interface consistent
Place the User in Control
Define interaction modes in a way that does not
force a user into unnecessary or undesired actions.
Provide for flexible interaction.
Allow user interaction to be interruptible and
undoable.
Streamline interaction as skill levels advance and
allow the interaction to be customized.
Hide technical internals from the casual user.
Design for direct interaction with objects that appear
on the screen.
Reduce the User’s Memory Load
Reduce demand on short-term memory.
Establish meaningful defaults.
Define shortcuts that are intuitive.
The visual layout of the interface should be based on a
real world metaphor.
Disclose information in a progressive fashion.
Make the Interface Consistent
Allow the user to put the current task into a
meaningful context.
Maintain consistency across a family of
applications.
If past interactive models have created user
expectations, do not make changes unless there is
a compelling reason to do so.
User Interface Design Models
 User model — a profile of all end users of
the system
 Design model — a design realization of the
user model
 Mental model (system perception) — the
user’s mental image of what the interface is
 Implementation model — the interface “look
and feel” coupled with supporting information
that describe interface syntax and semantics
User Interface Design Process
Interface Analysis
 Interface analysis means understanding
 (1) the people (end-users) who will interact with the
system through the interface;
 (2) the tasks that end-users must perform to do their
work,
 (3) the content that is presented as part of the
interface
 (4) the environment in which these tasks will be
conducted.
User Analysis
 Are users trained professionals, technician, clerical, or manufacturing workers?
 What level of formal education does the average user have?
 Are the users capable of learning from written materials or have they
expressed a desire for classroom training?
 Are users expert typists or keyboard phobic?
 What is the age range of the user community?
 Will the users be represented predominately by one gender?
 How are users compensated for the work they perform?
 Do users work normal office hours or do they work until the job is done?
 Is the software to be an integral part of the work users do or will it be used only
occasionally?
 What is the primary spoken language among users?
 What are the consequences if a user makes a mistake using the system?
 Are users experts in the subject matter that is addressed by the system?
 Do users want to know about the technology the sits behind the interface?
Task Analysis and Modeling
 Answers the following questions …
 What work will the user perform in specific circumstances?
 What tasks and subtasks will be performed as the user does
the work?
 What specific problem domain objects will the user manipulate
as work is performed?
 What is the sequence of work tasks—the workflow?
 What is the hierarchy of tasks?
 Use-cases define basic interaction
 Task elaboration refines interactive tasks
 Object elaboration identifies interface objects (classes)
 Workflow analysis defines how a work process is
completed when several people (and roles) are involved
Swimlane Diagram
p at ien t p h armacist p h ys ician
r e q u e s t s t h at a
d e t e r m in e s s t at u s o f
p r e scr ip t io n b e r e f ille d p r e scr ip t io n
no re fills ch e cks p at ie n t
re maining r e co r d s
re fills
re maining approve s re fill
re fill not
ch e cks in v e n t o r y f o r
allowe d
r e f ill o r alt e r n at iv e
e v alu at e s alt e r n at iv e
m e d icat io n
r e ce iv e s o u t o f st o ck ou t of stock
n o t if icat io n
a lt e rna t ive
a va ila ble
in stock
r e ce iv e s t im e / d at e
none
t o p ick u p
p icks u p f ills
p r e scr ip t io n p r e s cr ip t io n
r e ce iv e s r e q u e st t o
co n t act p h y s ician
Fig u re 1 2 .2 Sw imlan e d iag ram fo r p res crip t io n refill fu n ct io n
Analysis of Display Content
 Are different types of data assigned to consistent geographic
locations on the screen (e.g., photos always appear in the
upper right hand corner)?
 Can the user customize the screen location for content?
 Is proper on-screen identification assigned to all content?
 If a large report is to be presented, how should it be partitioned
for ease of understanding?
 Will mechanisms be available for moving directly to summary
information for large collections of data.
 Will graphical output be scaled to fit within the bounds of the
display device that is used?
 How will color to be used to enhance understanding?
 How will error messages and warning be presented to the
user?
Interface Design Steps
 Using information developed during interface
analysis, define interface objects and actions
(operations).
 Define events (user actions) that will cause the
state of the user interface to change. Model
this behavior.
 Depict each interface state as it will actually
look to the end-user.
 Indicate how the user interprets the state of the
system from information provided through the
interface.
Design Issues
 Response time
 Help facilities
 Error handling
 Menu and command
labeling
 Application accessibility
 Internationalization
WebApp Interface Design
 Where am I? The interface should
 provide an indication of the WebApp that has been accessed
 inform the user of her location in the content hierarchy.
 What can I do now? The interface should always help the user
understand his current options
 what functions are available?
 what links are live?
 what content is relevant?
 Where have I been, where am I going? The interface must
facilitate navigation.
 Provide a “map” (implemented in a way that is easy to understand)
of where the user has been and what paths may be taken to move
elsewhere within the WebApp.
Effective WebApp Interfaces
 Bruce Tognozzi [TOG01] suggests…
 Effective interfaces are visually apparent and
forgiving, instilling in their users a sense of control.
Users quickly see the breadth of their options, grasp
how to achieve their goals, and do their work.
 Effective interfaces do not concern the user with the
inner workings of the system. Work is carefully and
continuously saved, with full option for the user to
undo any activity at any time.
 Effective applications and services perform a
maximum of work, while requiring a minimum of
information from users.
Interface Design Principles-I
 Anticipation—A WebApp should be designed so that it
anticipates the use’s next move.
 Communication—The interface should communicate the status
of any activity initiated by the user
 Consistency—The use of navigation controls, menus, icons,
and aesthetics (e.g., color, shape, layout)
 Controlled autonomy—The interface should facilitate user
movement throughout the WebApp, but it should do so in a
manner that enforces navigation conventions that have been
established for the application.
 Efficiency—The design of the WebApp and its interface should
optimize the user’s work efficiency, not the efficiency of the
Web engineer who designs and builds it or the client-server
environment that executes it.
Interface Design Principles-II
 Focus—The WebApp interface (and the content it presents) should
stay focused on the user task(s) at hand.
 Fitt’s Law—“The time to acquire a target is a function of the distance to
and size of the target.”
 Human interface objects—A vast library of reusable human interface
objects has been developed for WebApps.
 Latency reduction—The WebApp should use multi-tasking in a way
that lets the user proceed with work as if the operation has been
completed.
 Learnability— A WebApp interface should be designed to minimize
learning time, and once learned, to minimize relearning required when
the WebApp is revisited.
Interface Design Principles-III
 Maintain work product integrity—A work product (e.g., a form
completed by the user, a user specified list) must be automatically
saved so that it will not be lost if an error occurs.
 Readability—All information presented through the interface should be
readable by young and old.
 Track state—When appropriate, the state of the user interaction should
be tracked and stored so that a user can logoff and return later to pick
up where she left off.
 Visible navigation—A well-designed WebApp interface provides “the
illusion that users are in the same place, with the work brought to
them.”
Interface Design Workflow-I
 Review information contained in the analysis model
and refine as required.
 Develop a rough sketch of the WebApp interface
layout.
 Map user objectives into specific interface actions.
 Define a set of user tasks that are associated with each
action.
 Storyboard screen images for each interface action.
 Refine interface layout and storyboards using input
from aesthetic design.
Mapping User Objectives Menu bar
major functions
List of use r obje ct ive s

graphic, logo, and company name
obje ct ive #1
obje ct ive #2
obje ct ive #3
obje ct ive #4
obje ct ive #5
graphic
obje ct ive #n
Home page text copy
Navigation
menu
Interface Design Workflow-II
 Identify user interface objects that are
required to implement the interface.
 Develop a procedural representation of the
user’s interaction with the interface.
 Develop a behavioral representation of the
interface.
 Describe the interface layout for each state.
 Refine and review the interface design
model.
Aesthetic Design
 Don’t be afraid of white space.
 Emphasize content.
 Organize layout elements from top-left to
bottom right.
 Group navigation, content, and function
geographically within the page.
 Don’t extend your real estate with the scrolling
bar.
 Consider resolution and browser window size
when designing layout.
Design Evaluation Cycle
preliminary
design
build
prototype #1
interface
build
prototype # n
interface
user
evaluate's
interface
design
modifications
are made
evaluation
is studied by
designer
Interface design
is complete
Chapter 12
 Pattern-Based Design

use.
Design Patterns
 Each of us has encountered a design problem
and silently thought: I wonder if anyone has
developed a solution to for this?
 What if there was a standard way of describing a
problem (so you could look it up), and an organized
method for representing the solution to the problem?
 Design patterns are a codified method for
describing problems and their solution allows
the software engineering community to
capture design knowledge in a way that
enables it to be reused.
Design Patterns
 Each pattern describes a problem that occurs over
and over again in our environment and then
describes the core of the solution to that problem in
such a way that you can use the solution a million
times over without ever doing it the same way
twice.
• Christopher Alexander, 1977
 “a three-part rule which expresses a relation
between a certain context, a problem, and a
solution.”
Basic Concepts
 Context allows the reader to understand the
environment in which the problem resides and
what solution might be appropriate within that
environment.
 A set of requirements, including limitations
and constraints, acts as a system of forces that
influences how
 the problem can be interpreted within its context and
 how the solution can be effectively applied.
Effective Patterns
 Coplien [Cop05] characterizes an effective design pattern in
the following way:
 It solves a problem: Patterns capture solutions, not just abstract
principles or strategies.
 It is a proven concept: Patterns capture solutions with a track record,
not theories or speculation.
 The solution isn't obvious: Many problem-solving techniques (such
as software design paradigms or methods) try to derive solutions
from first principles. The best patterns generate a solution to a
problem indirectly--a necessary approach for the most difficult
problems of design.
 It describes a relationship: Patterns don't just describe modules, but
describe deeper system structures and mechanisms.
 The pattern has a significant human component (minimize human
intervention). All software serves human comfort or quality of life;
the best patterns explicitly appeal to aesthetics and utility.
Generative Patterns
 Generative patterns describe an important and
repeatable aspect of a system and then provide
us with a way to build that aspect within a
system of forces that are unique to a given
context.
 A collection of generative design patterns
could be used to “generate” an application or
computer-based system whose architecture
enables it to adapt to change.
Kinds of Patterns
 Architectural patterns describe broad-based design problems
that are solved using a structural approach.
 Data patterns describe recurring data-oriented problems and
the data modeling solutions that can be used to solve them.
 Component patterns (also referred to as design patterns) address
problems associated with the development of subsystems and
components, the manner in which they communicate with one
another, and their placement within a larger architecture
 Interface design patterns describe common user interface
problems and their solution with a system of forces that
includes the specific characteristics of end-users.
 WebApp patterns address a problem set that is encountered
when building WebApps and often incorporates many of the
other patterns categories just mentioned.
Kinds of Patterns
 Creational patterns focus on the “creation, composition, and
representation of objects, e.g.,
 Abstract factory pattern: centralize decision of what factory to instantiate
 Factory method pattern: centralize creation of an object of a specific type choosing
one of several implementations
 Structural patterns focus on problems and solutions associated with
how classes and objects are organized and integrated to build a larger
structure, e.g.,
 Adapter pattern: 'adapts' one interface for a class into one that a client expects
 Aggregate pattern: a version of the Composite pattern with methods for
aggregation of children
 Behavioral patterns address problems associated with the assignment
of responsibility between objects and the manner in which
communication is effected between objects, e.g.,
 Chain of responsibility pattern: Command objects are handled or passed on to other
objects by logic-containing processing objects
 Command pattern: Command objects encapsulate an action and its parameters
Frameworks
 Patterns themselves may not be sufficient to develop a
complete design.
 In some cases it may be necessary to provide an
implementation-specific skeletal infrastructure, called a
framework, for design work.
 That is, you can select a “reusable mini-architecture that
provides the generic structure and behavior for a family of
software abstractions, along with a context … which specifies
their collaboration and use within a given domain.” [Amb98]
 A framework is not an architectural pattern, but rather a
skeleton with a collection of “plug points” (also called
hooks and slots) that enable it to be adapted to a specific
problem domain.
 The plug points enable you to integrate problem specific
classes or functionality within the skeleton.
Describing a Pattern
 Pattern name—describes the essence of the pattern in a short but expressive name
 Problem—describes the problem that the pattern addresses
 Motivation—provides an example of the problem
 Context—describes the environment in which the problem resides including
application domain
 Forces—lists the system of forces that affect the manner in which the problem
must be solved; includes a discussion of limitation and constraints that must be
considered
 Solution—provides a detailed description of the solution proposed for the
problem
 Intent—describes the pattern and what it does
 Collaborations—describes how other patterns contribute to the solution
 Consequences—describes the potential trade-offs that must be considered when
the pattern is implemented and the consequences of using the pattern
 Implementation—identifies special issues that should be considered when
implementing the pattern
 Known uses—provides examples of actual uses of the design pattern in real
applications
 Related patterns—cross-references related design patterns
Pattern Languages
 A pattern language encompasses a collection of patterns
 each described using a standardized template (Section
12.1.3) and
 interrelated to show how these patterns collaborate to
solve problems across an application domain.
 a pattern language is analogous to a hypertext
instruction manual for problem solving in a specific
application domain.
 The problem domain under consideration is first described
hierarchically, beginning with broad design problems
associated with the domain and then refining each of the
broad problems into lower levels of abstraction.
Pattern-Based Design
 A software designer begins with a
requirements model (either explicit or implied)
that presents an abstract representation of the
system.
 The requirements model describes the problem
set, establishes the context, and identifies the
system of forces that hold sway.
 Then …
Pattern-Based Design
Thinking in Patterns
 Shalloway and Trott [Sha05] suggest the following
approach that enables a designer to think in patterns:
 1. Be sure you understand the big picture—the context in
which the software to be built resides. The requirements
model should communicate this to you.
 2. Examining the big picture, extract the patterns that are
present at that level of abstraction.
 3. Begin your design with ‘big picture’ patterns that establish
a context or skeleton for further design work.
 4. “Work inward from the context” [Sha05] looking for
patterns at lower levels of abstraction that contribute to the
design solution.
 5. Repeat steps 1 to 4 until the complete design is fleshed
out.
 6. Refine the design by adapting each pattern to the specifics
of the software you’re trying to build.
Design Tasks—I
 Examine the requirements model and develop a
problem hierarchy.
 Determine if a reliable pattern language has been
developed for the problem domain.
 Beginning with a broad problem, determine whether
one or more architectural patterns are available for it.
 Using the collaborations provided for the architectural
pattern, examine subsystem or component level
problems and search for appropriate patterns to address
them.
 Repeat steps 2 through 5 until all broad problems have
been addressed.
Design Tasks—II
 If user interface design problems have been
isolated (this is almost always the case), search
the many user interface design pattern
repositories for appropriate patterns.
 Regardless of its level of abstraction, if a pattern
language and/or patterns repository or
individual pattern shows promise, compare the
problem to be solved against the existing
pattern(s) presented.
 Be certain to refine the design as it is derived
from patterns using design quality criteria as a
guide.
Pattern Organizing Table
Common Design Mistakes
 Not enough time has been spent to understand the
underlying problem, its context and forces, and as a
consequence, you select a pattern that looks right, but is
inappropriate for the solution required.
 Once the wrong pattern is selected, you refuse to see
your error and force fit the pattern.
 In other cases, the problem has forces that are not
considered by the pattern you’ve chosen, resulting in a
poor or erroneous fit.
 Sometimes a pattern is applied too literally and the
required adaptations for your problem space are not
implemented.
Chapter 13
 WebApp Design

use.
Design & WebApps
“There are essentially two basic approaches to
design: the artistic ideal of expressing yourself
and the engineering ideal of solving a problem
for a customer.”
Jakob Nielsen
 When should we emphasize WebApp design?
 when content and function are complex
 when the size of the WebApp encompasses
hundreds of content objects, functions, and analysis
classes
 when the success of the WebApp will have a direct
impact on the success of the business
Design & WebApp Quality
 Security
 Rebuff external attacks
 Exclude unauthorized access
 Ensure the privacy of users/customers
 Availability
 the measure of the percentage of time that a
WebApp is available for use
 Scalability
 Can the WebApp and the systems with which it is
interfaced handle significant variation in user or
transaction volume
 Time to Market
Quality Dimensions for End-Users
 Time
 How much has a Web site changed since the last upgrade?
 How do you highlight the parts that have changed?
 Structural
 How well do all of the parts of the Web site hold together.
 Are all links inside and outside the Web site working?
 Do all of the images work?
 Are there parts of the Web site that are not connected?
 Content
 Does the content of critical pages match what is supposed to be
there?
 Do key phrases exist continually in highly-changeable pages?
 Do critical pages maintain quality content from version to version?
 What about dynamically generated HTML pages?
Quality Dimensions for End-Users
 Accuracy and Consistency
 Are today's copies of the pages downloaded the same as
yesterday's? Close enough?
 Is the data presented accurate enough? How do you know?
 Response Time and Latency
 Does the Web site server respond to a browser request
within certain parameters?
 In an E-commerce context, how is the end to end response
time after a SUBMIT?
 Are there parts of a site that are so slow the user declines to
continue working on it?
 Performance
 Is the Browser-Web-Web site-Web-Browser connection quick
enough?
 How does the performance vary by time of day, by load and
usage?
 Is performance adequate for E-commerce applications?
WebApp Design Goals
 Consistency
 Content should be constructed consistently
 Graphic design (aesthetics) should present a consistent
look across all parts of the WebApp
 Architectural design should establish templates that lead to
a consistent hypermedia structure
 Interface design should define consistent modes of
interaction, navigation and content display
 Navigation mechanisms should be used consistently
across all WebApp elements
WebApp Design Goals
 Identity
 Establish an “identity” that is appropriate for the business
purpose
 Robustness
 The user expects robust content and functions that are relevant to
the user’s needs
 Navigability
 designed in a manner that is intuitive and predictable
 Visual appeal
 the look and feel of content, interface layout, color
coordination, the balance of text, graphics and other media,
navigation mechanisms must appeal to end-users
 Compatibility
 With all appropriate environments and configurations
WebE Design Pyramid
user
Interface
design
Aesthetic design
Content design
Navigation design
Architecture design
Component design
technology
WebApp Interface Design
 Where am I? The interface should
 provide an indication of the WebApp that has been accessed
 inform the user of her location in the content hierarchy.
 What can I do now? The interface should always help the user
understand his current options
 what functions are available?
 what links are live?
 what content is relevant?
 Where have I been, where am I going? The interface must
facilitate navigation.
 Provide a “map” (implemented in a way that is easy to understand)
of where the user has been and what paths may be taken to move
elsewhere within the WebApp.
Effective WebApp Interfaces
 Bruce Tognozzi [TOG01] suggests…
 Effective interfaces are visually apparent and
forgiving, instilling in their users a sense of control.
Users quickly see the breadth of their options, grasp
how to achieve their goals, and do their work.
 Effective interfaces do not concern the user with the
inner workings of the system. Work is carefully and
continuously saved, with full option for the user to
undo any activity at any time.
 Effective applications and services perform a
maximum of work, while requiring a minimum of
information from users.
Interface Design Principles-I
 Anticipation—A WebApp should be designed so that it
anticipates the use’s next move.
 Communication—The interface should communicate the status
of any activity initiated by the user
 Consistency—The use of navigation controls, menus, icons,
and aesthetics (e.g., color, shape, layout)
 Controlled autonomy—The interface should facilitate user
movement throughout the WebApp, but it should do so in a
manner that enforces navigation conventions that have been
established for the application.
 Efficiency—The design of the WebApp and its interface should
optimize the user’s work efficiency, not the efficiency of the
Web engineer who designs and builds it or the client-server
environment that executes it.
Interface Design Principles-II
 Focus—The WebApp interface (and the content it presents) should
stay focused on the user task(s) at hand.
 Fitt’s Law—“The time to acquire a target is a function of the distance to
and size of the target.”
 Human interface objects—A vast library of reusable human interface
objects has been developed for WebApps.
 Latency reduction—The WebApp should use multi-tasking in a way
that lets the user proceed with work as if the operation has been
completed.
 Learnability— A WebApp interface should be designed to minimize
learning time, and once learned, to minimize relearning required when
the WebApp is revisited.
Interface Design Principles-III
 Maintain work product integrity—A work product (e.g., a form
completed by the user, a user specified list) must be automatically
saved so that it will not be lost if an error occurs.
 Readability—All information presented through the interface should be
readable by young and old.
 Track state—When appropriate, the state of the user interaction should
be tracked and stored so that a user can logoff and return later to pick
up where she left off.
 Visible navigation—A well-designed WebApp interface provides “the
illusion that users are in the same place, with the work brought to
them.”
Aesthetic Design
 Don’t be afraid of white space.
 Emphasize content.
 Organize layout elements from top-left to
bottom right.
 Group navigation, content, and function
geographically within the page.
 Don’t extend your real estate with the scrolling
bar.
 Consider resolution and browser window size
when designing layout.
Content Design
 Develops a design representation for content
objects
 For WebApps, a content object is more closely aligned
with a data object for conventional software
 Represents the mechanisms required to
instantiate their relationships to one another.
 analogous to the relationship between analysis classes and
design components described in Chapter 11
 A content object has attributes that include content-
specific information and implementation-specific
attributes that are specified as part of design
Design of Content Objects
ProductComponent
partNumber
partName
partType
1 is p art o f
description
price
createNewItem ( ) 1
dis playDes cription ( ) Co mp De s crip t io n
dis play TechSpec
Sensor Camera ControlPanel SoftFeature
1 1 ..* 0 ..1 0 ..1 1
Marke t in g De s crip t io n Ph o t o g rap h Sch e mat ic Vid e o Te ch De scrip t io n
t e xt c olor horiz ont a l dime ns ion horiz ont a l dime ns ion horiz ont a l dime ns ion t e xt c olor
font s t yle ve rt ic a l dime ns ion ve rt ic a l dime ns ion ve rt ic a l dime ns ion font s t yle
font s iz e borde r s t yle borde r s t yle borde r s t yle font s iz e
line s pa c ing a udio volume line s pa c ing
t e xt ima ge s iz e t e xt ima ge s iz e
ba c kground c olor ba c kground c olor
Architecture Design
 Content architecture focuses on the manner in which content objects
(or composite objects such as Web pages) are structured for
presentation and navigation.
 The term information architecture is also used to connote structures that
lead to better organization, labeling, navigation, and searching of content
objects.
 WebApp architecture addresses the manner in which the application is
structured to manage user interaction, handle internal processing
tasks, effect navigation, and present content.
 Architecture design is conducted in parallel with interface design,
aesthetic design and content design.
Content Architecture
Linear
structure Grid
structure
Network
structure Hierarchical
structure
Navigation Design
 Begins with a consideration of the user
hierarchy and related use-cases
 Each actor may use the WebApp somewhat
differently and therefore have different navigation
requirements
 As each user interacts with the WebApp, she
encounters a series of navigation semantic
units (NSUs)
 NSU—“a set of information and related navigation
structures that collaborate in the fulfillment of a
subset of related user requirements”
Navigation Semantic Units
 Navigation semantic unit
 Ways of navigation (WoN)—represents the best navigation
way or path for users with certain profiles to achieve their
desired goal or sub-goal. Composed of …
• Navigation nodes (NN) connected by Navigation links
link12 link24
NN2
NN1
NN4 NSU
link13 NN3 link34
Navigation Syntax
 Individual navigation link—text-based links, icons, buttons
and switches, and graphical metaphors..
 Horizontal navigation bar—lists major content or functional
categories in a bar containing appropriate links. In general,
between 4 and 7 categories are listed.
 Vertical navigation column
 lists major content or functional categories
 lists virtually all major content objects within the WebApp.
 Tabs—a metaphor that is nothing more than a variation of the
navigation bar or column, representing content or functional
categories as tab sheets that are selected when a link is
required.
 Site maps—provide an all-inclusive tab of contents for
navigation to all content objects and functionality contained
within the WebApp.
Component-Level Design
 WebApp components implement the following
functionality
 perform localized processing to generate content and
navigation capability in a dynamic fashion
 provide computation or data processing capability
that are appropriate for the WebApp’s business
domain
 provide sophisticated database query and access
 establish data interfaces with external corporate
systems.
Chapter 14
 Quality Concepts

use.
Software Quality
 In 2005, ComputerWorld [Hil05] lamented that
 “bad software plagues nearly every organization that uses
computers, causing lost work hours during computer downtime,
lost or corrupted data, missed sales opportunities, high IT support
and maintenance costs, and low customer satisfaction.
 A year later, InfoWorld [Fos06] wrote about the
 “the sorry state of software quality” reporting that the quality
problem had not gotten any better.
 Today, software quality remains an issue, but who is to blame?
 Customers blame developers, arguing that sloppy practices lead to
low-quality software.
 Developers blame customers (and other stakeholders), arguing
that irrational delivery dates and a continuing stream of changes
force them to deliver software before it has been fully validated.
Quality
 The American Heritage Dictionary defines
quality as
 “a characteristic or attribute of something.”
 For software, two kinds of quality may be
encountered:
 Quality of design encompasses requirements,
specifications, and the design of the system.
 Quality of conformance is an issue focused primarily
on implementation.
 User satisfaction = compliant product + good quality
+ delivery within budget and schedule
Quality—A Philosophical View
 Robert Persig [Per74] commented on the thing we call
quality:
 Quality . . . you know what it is, yet you don't know what it is.
But that's self-contradictory. But some things are better than
others, that is, they have more quality. But when you try to say
what the quality is, apart from the things that have it, it all goes
poof! There's nothing to talk about. But if you can't say what
Quality is, how do you know what it is, or how do you know that
it even exists? If no one knows what it is, then for all practical
purposes it doesn't exist at all. But for all practical purposes it
really does exist. What else are the grades based on? Why else
would people pay fortunes for some things and throw others in
the trash pile? Obviously some things are better than others . . .
but what's the betterness? . . . So round and round you go,
spinning mental wheels and nowhere finding anyplace to get
traction. What the hell is Quality? What is it?
Quality—A Pragmatic View
 The transcendental view argues (like Persig) that quality is
something that you immediately recognize, but cannot
explicitly define.
 The user view sees quality in terms of an end-user’s specific
goals. If a product meets those goals, it exhibits quality.
 The manufacturer’s view defines quality in terms of the
original specification of the product. If the product
conforms to the spec, it exhibits quality.
 The product view suggests that quality can be tied to
inherent characteristics (e.g., functions and features) of a
product.
 Finally, the value-based view measures quality based on how
much a customer is willing to pay for a product. In reality,
quality encompasses all of these views and more.
Software Quality
 Software quality can be defined as:
 An effective software process applied in a manner that
creates a useful product that provides measurable value for
those who produce it and those who use it.
 This definition has been adapted from [Bes04] and
replaces a more manufacturing-oriented view
presented in earlier editions of this book.
Effective Software Process
 An effective software process establishes the
infrastructure that supports any effort at building a high
quality software product.
 The management aspects of process create the checks
and balances that help avoid project chaos—a key
contributor to poor quality.
 Software engineering practices allow the developer to
analyze the problem and design a solid solution—both
critical to building high quality software.
 Finally, umbrella activities such as change management
and technical reviews have as much to do with quality
as any other part of software engineering practice.
Useful Product
 A useful product delivers the content, functions,
and features that the end-user desires
 But as important, it delivers these assets in a
reliable, error free way.
 A useful product always satisfies those
requirements that have been explicitly stated
by stakeholders.
 In addition, it satisfies a set of implicit
requirements (e.g., ease of use) that are
expected of all high quality software.
Adding Value
 By adding value for both the producer and user of a software
product, high quality software provides benefits for the
software organization and the end-user community.
 The software organization gains added value because high
quality software requires less maintenance effort, fewer bug
fixes, and reduced customer support.
 The user community gains added value because the
application provides a useful capability in a way that
expedites some business process.
 The end result is:
 (1) greater software product revenue,
 (2) better profitability when an application supports a business
process, and/or
 (3) improved availability of information that is crucial for the
business.
Quality Dimensions
 David Garvin [Gar87]:
 Performance Quality. Does the software deliver all
content, functions, and features that are specified as part of
the requirements model in a way that provides value to the
end-user?
 Feature quality. Does the software provide features that
surprise and delight first-time end-users?
 Reliability. Does the software deliver all features and
capability without failure? Is it available when it is
needed? Does it deliver functionality that is error free?
 Conformance. Does the software conform to local and
external software standards that are relevant to the
application? Does it conform to de facto design and coding
conventions? For example, does the user interface conform
to accepted design rules for menu selection or data input?
Quality Dimensions
 Durability. Can the software be maintained (changed) or
corrected (debugged) without the inadvertent generation
of unintended side effects? Will changes cause the error
rate or reliability to degrade with time?
 Serviceability. Can the software be maintained (changed)
or corrected (debugged) in an acceptably short time
period. Can support staff acquire all information they need
to make changes or correct defects?
 Aesthetics. Most of us would agree that an aesthetic entity
has a certain elegance, a unique flow, and an obvious
“presence” that are hard to quantify but evident
nonetheless.
 Perception. In some situations, you have a set of prejudices
that will influence your perception of quality.
The Software Quality Dilemma
 If you produce a software system that has terrible quality,
you lose because no one will want to buy it.
 If on the other hand you spend infinite time, extremely
large effort, and huge sums of money to build the
absolutely perfect piece of software, then it's going to take
so long to complete and it will be so expensive to produce
that you'll be out of business anyway.
 Either you missed the market window, or you simply
exhausted all your resources.
 So people in industry try to get to that magical middle
ground where the product is good enough not to be
rejected right away, such as during evaluation, but also not
the object of so much perfectionism and so much work that
it would take too long or cost too much to complete.
[Ven03]
“Good Enough” Software
 Good enough software delivers high quality functions and
features that end-users desire, but at the same time it delivers
other more obscure or specialized functions and features that
contain known bugs.
 Arguments against “good enough.”
 It is true that “good enough” may work in some application
domains and for a few major software companies. After all, if a
company has a large marketing budget and can convince enough
people to buy version 1.0, it has succeeded in locking them in.
 If you work for a small company be wary of this philosophy. If you
deliver a “good enough” (buggy) product, you risk permanent
damage to your company’s reputation.
 You may never get a chance to deliver version 2.0 because bad buzz
may cause your sales to plummet and your company to fold.
 If you work in certain application domains (e.g., real time embedded
software, application software that is integrated with hardware can
be negligent and open your company to expensive litigation.
Cost of Quality
 Prevention costs include
 quality planning
 formal technical reviews
 test equipment
 Training
 Internal failure costs include
 rework
 repair
 failure mode analysis
 External failure costs are
 complaint resolution
 product return and replacement
 help line support
 warranty work
Cost
 The relative costs to find and repair an error or defect
increase dramatically as we go from prevention to
detection to internal failure to external failure costs.
Quality and Risk
 “People bet their jobs, their comforts, their safety, their
entertainment, their decisions, and their very lives on
computer software. It better be right.” SEPA, Chapter 1
 Example:
 Throughout the month of November, 2000 at a hospital in
Panama, 28 patients received massive overdoses of gamma rays
during treatment for a variety of cancers. In the months that
followed, five of these patients died from radiation poisoning and
15 others developed serious complications. What caused this
tragedy? A software package, developed by a U.S. company, was
modified by hospital technicians to compute modified doses of
radiation for each patient.
Negligence and Liability
 The story is all too common. A governmental or corporate
entity hires a major software developer or consulting
company to analyze requirements and then design and
construct a software-based “system” to support some
major activity.
 The system might support a major corporate function (e.g.,
pension management) or some governmental function (e.g.,
healthcare administration or homeland security).
 Work begins with the best of intentions on both sides, but
by the time the system is delivered, things have gone bad.
 The system is late, fails to deliver desired features and
functions, is error-prone, and does not meet with
customer approval.
 Litigation ensues.
Quality and Security
 Gary McGraw comments [Wil05]:
 “Software security relates entirely and completely to
quality. You must think about security, reliability,
availability, dependability—at the beginning, in the
design, architecture, test, and coding phases, all through
the software life cycle [process]. Even people aware of
the software security problem have focused on late life-
cycle stuff. The earlier you find the software problem,
the better. And there are two kinds of software
problems. One is bugs, which are implementation
problems. The other is software flaws—architectural
problems in the design. People pay too much attention
to bugs and not enough on flaws.”
Achieving Software Quality
 Critical success factors:
 Software Engineering Methods
 Project Management Techniques
 Quality Control
 Quality Assurance
Chapter 15
 Review Techniques

use.
What Are Reviews?
 a meeting conducted by technical
people for technical people
 a technical assessment of a work
product created during the software
engineering process
 a software quality assurance
mechanism
 a training ground
What Reviews Are Not
 A project summary or progress

assessment
 A meeting intended solely to impart
information
 A mechanism for political or personal
reprisal!
What Do We Look For?
 Errors and defects
 Error—a quality problem found before the software is released
to end users
 Defect—a quality problem found only after the software has been
released to end-users
 We make this distinction because errors and defects have very
different economic, business, psychological, and human
impact
 However, the temporal distinction made between errors and
defects in this book is not mainstream thinking
Defect Amplification
 A defect amplification model [IBM81] can be used to illustrate
the generation and detection of errors during the design and
code generation actions of a software process.
Defects Detection
Errors from Errors passed through
Previous step Percent Errors passed
Amplified errors 1:x Efficiency To next step
Newly generated errors
Development step
Defect Amplification
 In the example provided in SEPA, Section
15.2,
 a software process that does NOT include reviews,
• yields 94 errors at the beginning of testing and
• Releases 12 latent defects to the field
 a software process that does include reviews,
• yields 24 errors at the beginning of testing and
• releases 3 latent defects to the field
 A cost analysis indicates that the process with NO
reviews costs approximately 3 times more than the
process with reviews, taking the cost of correcting
the latent defects into account
Metrics
 The total review effort and the total number of
errors discovered are defined as:
• Ereview = Ep + Ea + Er
• Errtot = Errminor + Errmajor
 Defect density represents the errors found per
unit of work product reviewed.
• Defect density = Errtot / WPS
 where …
Metrics
 Preparation effort, Ep—the effort (in person-hours) required to
review a work product prior to the actual review meeting
 Assessment effort, Ea— the effort (in person-hours) that is expending
during the actual review
 Rework effort, Er— the effort (in person-hours) that is dedicated to
the correction of those errors uncovered during the review
 Work product size, WPS—a measure of the size of the work product
that has been reviewed (e.g., the number of UML models, or the
number of document pages, or the number of lines of code)
 Minor errors found, Errminor—the number of errors found that can be
categorized as minor (requiring less than some pre-specified effort
to correct)
 Major errors found, Errmajor— the number of errors found that can be
categorized as major (requiring more than some pre-specified effort
to correct)
An Example—I
 If past history indicates that
 the average defect density for a requirements model
is 0.6 errors per page, and a new requirement model
is 32 pages long,
 a rough estimate suggests that your software team
will find about 19 or 20 errors during the review of
the document.
 If you find only 6 errors, you’ve done an extremely
good job in developing the requirements model or
your review approach was not thorough enough.
An Example—II
 The effort required to correct a minor model error (immediately after
the review) was found to require 4 person-hours.
 The effort required for a major requirement error was found to be 18
person-hours.
 Examining the review data collected, you find that minor errors occur
about 6 times more frequently than major errors. Therefore, you can
estimate that the average effort to find and correct a requirements error
during review is about 6 person-hours.
 Requirements related errors uncovered during testing require an
average of 45 person-hours to find and correct. Using the averages
noted, we get:
 Effort saved per error = Etesting – Ereviews
 45 – 6 = 30 person-hours/error
 Since 22 errors were found during the review of the requirements
model, a saving of about 660 person-hours of testing effort would be
achieved. And that’s just for requirements-related errors.
Overall
 Effort expended with and without reviews
with reviews
Informal Reviews
 Informal reviews include:
 a simple desk check of a software engineering work
product with a colleague
 a casual meeting (involving more than 2 people) for the
purpose of reviewing a work product, or
 the review-oriented aspects of pair programming
 pair programming encourages continuous review as
a work product (design or code) is created.
 The benefit is immediate discovery of errors and better
work product quality as a consequence.
Formal Technical Reviews
 The objectives of an FTR are:
 to uncover errors in function, logic, or implementation for
any representation of the software
 to verify that the software under review meets its
requirements
 to ensure that the software has been represented according
to predefined standards
 to achieve software that is developed in a uniform manner
 to make projects more manageable
 The FTR is actually a class of reviews that includes
walkthroughs and inspections.
The Review Meeting
 Between three and five people (typically)
should be involved in the review.
 Advance preparation should occur but should
require no more than two hours of work for
each person.
 The duration of the review meeting should be
less than two hours.
 Focus is on a work product (e.g., a portion of a
requirements model, a detailed component design,
source code for a component)
The Players
 Producer—the individual who has developed the work
product
 informs the project leader that the work product is
complete and that a review is required
 Review leader—evaluates the product for readiness,
generates copies of product materials, and distributes
them to two or three reviewers for advance preparation.
 Reviewer(s)—expected to spend between one and two
hours reviewing the product, making notes, and
otherwise becoming familiar with the work.
 Recorder—reviewer who records (in writing) all important
issues raised during the review.
Conducting the Review
 Review the product, not the producer.
 Set an agenda and maintain it.
 Limit debate and rebuttal.
 Enunciate problem areas, but don't attempt to solve every
problem noted.
 Take written notes.
 Limit the number of participants and insist upon advance
preparation.
 Develop a checklist for each product that is likely to be reviewed.
 Allocate resources and schedule time for FTRs.
 Conduct meaningful training for all reviewers.
 Review your early reviews.
Sample-Driven Reviews (SDRs)
 SDRs attempt to quantify those work products that are
primary targets for full FTRs.
To accomplish this …
 Inspect a fraction ai of each software work product, i.
Record the number of faults, fi found within ai.
 Develop a gross estimate of the number of faults within
work product i by multiplying fi by 1/ai.
 Sort the work products in descending order according to
the gross estimate of the number of faults in each.
 Focus available review resources on those work products
that have the highest estimated number of faults.
Chapter 16
 Software Quality Assurance

use.
Comment on Quality
 Phil Crosby once said:
 The problem of quality management is not what people
don't know about it. The problem is what they think they
do know . . .
 Everybody is for it. (Under certain conditions, of course.)
 Everyone feels they understand it. (Even though they
wouldn't want to explain it.)
 Everyone thinks execution is only a matter of following natural
inclinations. (After all, we do get along somehow.)
 And, of course, most people feel that problems in these areas are
caused by other people. (If only they would take the time to
do things right.)
Elements of SQA
 Standards
 Reviews and Audits
 Testing
 Error/defect collection and analysis
 Change management
 Education
 Vendor management
 Security management
 Safety
 Risk management
Role of the SQA Group-I
 Prepares an SQA plan for a project.
 The plan identifies
• evaluations to be performed
• audits and reviews to be performed
• standards that are applicable to the project
• procedures for error reporting and tracking
• documents to be produced by the SQA group
• amount of feedback provided to the software project team
 Participates in the development of the project’s software
process description.
 The SQA group reviews the process description for compliance
with organizational policy, internal software standards, externally
imposed standards (e.g., ISO-9001), and other parts of the
software project plan.
Role of the SQA Group-II
 Reviews software engineering activities to verify
compliance with the defined software process.
 identifies, documents, and tracks deviations from the process and
verifies that corrections have been made.
 Audits designated software work products to verify
compliance with those defined as part of the software
process.
 reviews selected work products; identifies, documents, and tracks
deviations; verifies that corrections have been made
 periodically reports the results of its work to the project manager.
 Ensures that deviations in software work and work
products are documented and handled according to a
documented procedure.
 Records any noncompliance and reports to senior
management.
 Noncompliance items are tracked until they are resolved.
SQA Goals (see Figure 16.1)
 Requirements quality. The correctness, completeness, and
consistency of the requirements model will have a strong
influence on the quality of all work products that follow.
 Design quality. Every element of the design model should
be assessed by the software team to ensure that it exhibits
high quality and that the design itself conforms to
requirements.
 Code quality. Source code and related work products (e.g.,
other descriptive information) must conform to local
coding standards and exhibit characteristics that will
facilitate maintainability.
 Quality control effectiveness. A software team should
apply limited resources in a way that has the highest
likelihood of achieving a high quality result.
Statistical SQA
Product Collect information on all defects
Find the causes of the defects
& Process Move to provide fixes for the process
measurement
... an understanding of how

to improve quality ...
Statistical SQA
 Information about software errors and defects is
collected and categorized.
 An attempt is made to trace each error and defect to its
underlying cause (e.g., non-conformance to
specifications, design error, violation of standards, poor
communication with the customer).
 Using the Pareto principle (80 percent of the defects can
be traced to 20 percent of all possible causes), isolate the
20 percent (the vital few).
 Once the vital few causes have been identified, move to
correct the problems that have caused the errors and
defects.
Six-Sigma for Software Engineering
 The term “six sigma” is derived from six standard deviations—
3.4 instances (defects) per million occurrences—implying an
extremely high quality standard.
 The Six Sigma methodology defines three core steps:
 Define customer requirements and deliverables and project goals
via well-defined methods of customer communication
 Measure the existing process and its output to determine current
quality performance (collect defect metrics)
 Analyze defect metrics and determine the vital few causes.
 Improve the process by eliminating the root causes of defects.
 Control the process to ensure that future work does not
reintroduce the causes of defects.
Software Reliability
 A simple measure of reliability is mean-time-
between-failure (MTBF), where
MTBF = MTTF + MTTR
 The acronyms MTTF and MTTR are mean-
time-to-failure and mean-time-to-repair,
respectively.
 Software availability is the probability that a
program is operating according to requirements
at a given point in time and is defined as
Availability = [MTTF/(MTTF + MTTR)] x 100%
Software Safety
 Software safety is a software quality assurance
activity that focuses on the identification and
assessment of potential hazards that may
affect software negatively and cause an entire
system to fail.
 If hazards can be identified early in the
software process, software design features can
be specified that will either eliminate or control
potential hazards.
ISO 9001:2000 Standard
 ISO 9001:2000 is the quality assurance standard that
applies to software engineering.
 The standard contains 20 requirements that must be
present for an effective quality assurance system.
 The requirements delineated by ISO 9001:2000 address
topics such as
 management responsibility, quality system, contract
review, design control, document and data control, product
identification and traceability, process control, inspection
and testing, corrective and preventive action, control of
quality records, internal quality audits, training, servicing,
and statistical techniques.
Chapter 17
 Software Testing Strategies

use.
Software Testing
Testing is the process of exercising

a program with the specific intent of
finding errors prior to delivery to the
end user.
What Testing Shows
errors
requirements conformance
performance
an indication
of quality
Strategic Approach
 To perform effective testing, you should conduct
effective technical reviews. By doing this, many errors
will be eliminated before testing commences.
 Testing begins at the component level and works
"outward" toward the integration of the entire
computer-based system.
 Different testing techniques are appropriate for different
software engineering approaches and at different points
in time.
 Testing is conducted by the developer of the software
and (for large projects) an independent test group.
 Testing and debugging are different activities, but
debugging must be accommodated in any testing
strategy.
V&V
 Verification refers to the set of tasks that ensure
that software correctly implements a specific
function.
 Validation refers to a different set of tasks that
ensure that the software that has been built is
traceable to customer requirements. Boehm
[Boe81] states this another way:
 Verification: "Are we building the product right?"
 Validation: "Are we building the right product?"
Who Tests the Software?
developer independent tester

Understands the system Must learn about the system,
but, will test "gently" but, will attempt to break it
and, is driven by "delivery" and, is driven by quality
Testing Strategy
System engineering
Analysis modeling
Design modeling
Code generation Unit test
Integration test
Validation test
System test
Testing Strategy
 We begin by ‘testing-in-the-small’ and move
toward ‘testing-in-the-large’
 For conventional software
 The module (component) is our initial focus
 Integration of modules follows
 For OO software
 our focus when “testing in the small” changes from
an individual module (the conventional view) to an
OO class that encompasses attributes and
operations and implies communication and
collaboration
Strategic Issues
 Specify product requirements in a quantifiable manner
long before testing commences.
 State testing objectives explicitly.
 Understand the users of the software and develop a
profile for each user category.
 Develop a testing plan that emphasizes “rapid cycle
testing.”
 Build “robust” software that is designed to test itself
 Use effective technical reviews as a filter prior to testing
 Conduct technical reviews to assess the test strategy
and test cases themselves.
 Develop a continuous improvement approach for the
testing process.
Unit Testing
module
to be
tested
results
software
engineer
test cases
Unit Testing
module
to be
tested
interface
local data structures
boundary conditions
independent paths
error handling paths
test cases
Unit Test Environment
driver
interface
local data structures
Module boundary conditions

independent paths
error handling paths
stub stub
test cases
RESULTS
Integration Testing Strategies
• Top down testing
• Bottom-up testing
• Sandwich testing
Top Down Integration
A
top module is tested with
stubs
B F G
stubs are replaced one at

a time, "depth first"
C
as new modules are integrated,
some subset of tests is re-run
D E
Bottom-Up Integration
A
B F G
drivers are replaced one at a

time, "depth first"
C
worker modules are grouped into

builds and integrated
D E
cluster
Sandwich Testing
A
Top modules are
tested with stubs
B F G
Worker modules are grouped into

builds and integrated
D E
cluster
Regression Testing
 Regression testing is the re-execution of some subset of
tests that have already been conducted to ensure that
changes have not propagated unintended side effects
 Whenever software is corrected, some aspect of the
software configuration (the program, its documentation,
or the data that support it) is changed.
 Regression testing helps to ensure that changes (due to
testing or for other reasons) do not introduce
unintended behavior or additional errors.
 Regression testing may be conducted manually, by re-
executing a subset of all test cases or using automated
capture/playback tools.
Smoke Testing
 A common approach for creating “daily builds” for product
software
 Smoke testing steps:
 Software components that have been translated into code are
integrated into a “build.”
• A build includes all data files, libraries, reusable modules, and engineered
components that are required to implement one or more product
functions.
 A series of tests is designed to expose errors that will keep the build
from properly performing its function.
• The intent should be to uncover “show stopper” errors that have the
highest likelihood of throwing the software project behind schedule.
 The build is integrated with other builds and the entire product (in its
current form) is smoke tested daily.
• The integration approach may be top down or bottom up.
Object-Oriented Testing
 begins by evaluating the correctness and
consistency of the analysis and design models
 testing strategy changes
 the concept of the ‘unit’ broadens due to
encapsulation
 integration focuses on classes and their execution
across a ‘thread’ or in the context of a usage
scenario
 validation uses conventional black box methods
 test case design draws on conventional
methods, but also encompasses special
features
Testing the CRC Model
1. Revisit the CRC model and the object-relationship model.
2. Inspect the description of each CRC index card to determine if a
delegated responsibility is part of the collaborator’s definition.
3. Invert the connection to ensure that each collaborator that is
asked for service is receiving requests from a reasonable source.
4. Using the inverted connections examined in step 3, determine
whether other classes might be required or whether responsibilities
are properly grouped among the classes.
5. Determine whether widely requested responsibilities might be
combined into a single responsibility.
6. Steps 1 to 5 are applied iteratively to each class and through
each evolution of the analysis model.
OO Testing Strategy
 class testing is the equivalent of unit testing
 operations within the class are tested
 the state behavior of the class is examined
 integration applied three different strategies
 thread-based testing—integrates the set of
classes required to respond to one input or event
 use-based testing—integrates the set of classes
required to respond to one use case
 cluster testing—integrates the set of classes
required to demonstrate one collaboration
High Order Testing
 Validation testing
 Focus is on software requirements
 System testing
 Focus is on system integration
 Alpha/Beta testing
 Focus is on customer usage
 Recovery testing
 forces the software to fail in a variety of ways and verifies that recovery is
properly performed
 Security testing
 verifies that protection mechanisms built into a system will, in fact, protect it
from improper penetration
 Stress testing
 executes a system in a manner that demands resources in abnormal quantity,
frequency, or volume
 Performance Testing
 test the run-time performance of software within the context of an integrated
system
Debugging: A Diagnostic Process
The Debugging Process
Debugging Effort
time required
to diagnose the
symptom and
time required determine the
to correct the error cause
and conduct
regression tests
Symptoms & Causes
symptom and cause may be
geographically separated
symptom may disappear when

another problem is fixed
cause may be due to a

combination of non-errors
cause may be due to a system

or compiler error
symptom cause may be due to

assumptions that everyone
cause believes
symptom may be intermittent

Consequences of Bugs
infectious
damage
catastrophic
extreme
serious
disturbing
annoying
mild
Bug Type
Bug Categories: function-related bugs,

system-related bugs, data bugs, coding bugs,
design bugs, documentation bugs, standards
violations, etc.
Correcting the Error
 Is the cause of the bug reproduced in another part of the program? In
many situations, a program defect is caused by an erroneous
pattern of logic that may be reproduced elsewhere.
 What "next bug" might be introduced by the fix I'm about to make?
Before the correction is made, the source code (or, better, the
design) should be evaluated to assess coupling of logic and
data structures.
 What could we have done to prevent this bug in the first place? This
question is the first step toward establishing a statistical
software quality assurance approach. If you correct the process
as well as the product, the bug will be removed from the
current program and may be eliminated from all future
programs.
Final Thoughts
 Think -- before you act to correct
 Use tools to gain additional insight
 If you’re at an impasse, get help from someone
else
 Once you correct the bug, use regression
testing to uncover any side effects
Chapter 18
 Testing Conventional Applications

use.
Testability
 Operability—it operates cleanly
 Observability—the results of each test case are readily
observed
 Controllability—the degree to which testing can be
automated and optimized
 Decomposability—testing can be targeted
 Simplicity—reduce complex architecture and logic to
simplify tests
 Stability—few changes are requested during testing
 Understandability—of the design
What is a “Good” Test?
 A good test has a high probability of
finding an error
 A good test is not redundant.
 A good test should be “best of breed”
 A good test should be neither too
simple nor too complex
Internal and External Views
 Any engineered product (and most other
things) can be tested in one of two ways:
 Knowing the specified function that a product has
been designed to perform, tests can be conducted
that demonstrate each function is fully operational
while at the same time searching for errors in each
function;
 Knowing the internal workings of a product, tests
can be conducted to ensure that "all gears mesh," that
is, internal operations are performed according to
specifications and all internal components have been
adequately exercised.
Test Case Design
"Bugs lurk in corners
and congregate at
boundaries ..."
Boris Beizer
OBJECTIVE to uncover errors
CRITERIA in a complete manner
CONSTRAINT with a minimum of effort and time

Exhaustive Testing
loop < 20 X
14
There are 10 possible paths! If we execute one
test per millisecond, it would take 3,170 years to
test this program!!
Selective Testing
Selected path
loop < 20 X
Software Testing
white-box black-box
methods methods
Methods
Strategies
White-Box Testing
... our goal is to ensure that all

statements and conditions have
been executed at least once ...
Why Cover?
logic errors and incorrect assumptions
are inversely proportional to a path's
execution probability
we often believe that a path is not

likely to be executed; in fact, reality is
often counter intuitive
typographical errors are random; it's

likely that untested paths will contain
some
Basis Path Testing
First, we compute the cyclomatic
complexity:
number of simple decisions + 1
or
number of enclosed areas + 1
In this case, V(G) = 4
Cyclomatic Complexity
A number of industry studies have indicated
that the higher V(G), the higher the probability
or errors.
modules
V(G)
modules in this range are

more error prone
Basis Path Testing
1
Next, we derive the
independent paths:
2 Since V(G) = 4,
there are four paths
3 Path 1: 1,2,3,6,7,8
4
5 6
Path 2: 1,2,3,5,7,8
Path 3: 1,2,4,7,8
Path 4: 1,2,4,7,2,4,...7,8
Finally, we derive test
7 cases to exercise these
paths.
8
Basis Path Testing Notes
you don't need a flow chart,
but the picture will help when
you trace program paths
count each simple logical test,

compound tests count as 2 or
more
basis path testing should be

applied to critical modules
Deriving Test Cases
 Summarizing:
 Using the design or code as a foundation, draw a
corresponding flow graph.
 Determine the cyclomatic complexity of the resultant
flow graph.
 Determine a basis set of linearly independent paths.
 Prepare test cases that will force execution of each
path in the basis set.
Loop Testing
Simple
loop
Nested
Loops
Concatenated
Loops Unstructured
Loops
Loop Testing: Simple Loops
Minimum conditions—Simple Loops
1. skip the loop entirely
2. only one pass through the loop
3. two passes through the loop
4. m passes through the loop m < n
5. (n-1), n, and (n+1) passes through
the loop
where n is the maximum number
of allowable passes
Loop Testing: Nested Loops
Nested Loops
Start at the innermost loop. Set all outer loops to their
minimum iteration parameter values.
Test the min+1, typical, max-1 and max for the
innermost loop, while holding the outer loops at their
minimum values.
Move out one loop and set it up as in step 2, holding all
other loops at typical values. Continue this step until
the outermost loop has been tested.
Concatenated Loops
If the loops are independent of one another
then treat each as a simple loop
else* treat as nested loops
endif*
for example, the final loop counter value of loop 1 is
used to initialize loop 2.
Black-Box Testing
requirements
output
input events
Black-Box Testing
 How is functional validity tested?
 How is system behavior and performance tested?
 What classes of input will make good test cases?
 Is the system particularly sensitive to certain input
values?
 How are the boundaries of a data class isolated?
 What data rates and data volume can the system
tolerate?
 What effect will specific combinations of data have on
system operation?
Graph-Based Methods
To understand the
objects that are object
#1
Directed link object
#2
(link weight)
modeled in software
and the relationships Undirected link
Node weight
(value
that connect these Parallel links
)
objects object
#
3
In this context, we consider (a)
the term “objects” in the

broadest possible context. It new menu select generates document
encompasses data objects, file (generation time  1.0 sec) window
traditional components
allows editing
(modules), and object- of Attributes:
is represented as
oriented elements of contains
computer software. document background color: white
tex text color: default color
t or preferences
(b)
Comparison Testing
 Used only in situations in which the reliability of
software is absolutely critical (e.g., human-
rated systems)
 Separate software engineering teams develop
independent versions of an application using the
same specification
 Each version can be tested with the same test data
to ensure that all provide identical output
 Then all versions are executed in parallel with real-
time comparison of results to ensure consistency
Orthogonal Array Testing
 Used when the number of input parameters is
small and the values that each of the
parameters may take are clearly bounded
Z Z
Y Y
X X
One input item at a time L9 orthogonal array
Model-Based Testing
 Analyze an existing behavioral model for the software or
create one.
 Recall that a behavioral model indicates how software will
respond to external events or stimuli.
 Traverse the behavioral model and specify the inputs that
will force the software to make the transition from state to
state.
 The inputs will trigger events that will cause the transition to
occur.
 Review the behavioral model and note the expected outputs
as the software makes the transition from state to state.
 Execute the test cases.
 Compare actual and expected results and take corrective
action as required.
Software Testing Patterns
 Testing patterns are described in much the
same way as design patterns (Chapter 12).
 Example:
• Pattern name: ScenarioTesting
• Abstract: Once unit and integration tests have been
conducted, there is a need to determine whether the
software will perform in a manner that satisfies users.
The ScenarioTesting pattern describes a technique for
exercising the software from the user’s point of view.
A failure at this level indicates that the software has
failed to meet a user visible requirement. [Kan01]
Chapter 19
 Testing Object-Oriented Applications

use.
OO Testing
 To adequately test OO systems, three things
must be done:
 the definition of testing must be broadened to
include error discovery techniques applied to object-
oriented analysis and design models
 the strategy for unit and integration testing must
change significantly, and
 the design of test cases must account for the unique
characteristics of OO software.
‘Testing’ OO Models
 The review of OO analysis and design models
is especially useful because the same semantic
constructs (e.g., classes, attributes, operations,
messages) appear at the analysis, design, and
code level
 Therefore, a problem in the definition of class
attributes that is uncovered during analysis
will circumvent side affects that might occur if
the problem were not discovered until design
or code (or even the next iteration of analysis).
Correctness of OO Models
 During analysis and design, semantic correctness can be
asesssed based on the model’s conformance to the real
world problem domain.
 If the model accurately reflects the real world (to a level
of detail that is appropriate to the stage of development
at which the model is reviewed) then it is semantically
correct.
 To determine whether the model does, in fact, reflect
real world requirements, it should be presented to
problem domain experts who will examine the class
definitions and hierarchy for omissions and ambiguity.
 Class relationships (instance connections) are evaluated
to determine whether they accurately reflect real-world
object connections.
Class Model Consistency
 Revisit the CRC model and the object-relationship
model.
 Inspect the description of each CRC index card to
determine if a delegated responsibility is part of the
collaborator’s definition.
 Invert the connection to ensure that each collaborator
that is asked for service is receiving requests from a
reasonable source.
 Using the inverted connections examined in the
preceding step, determine whether other classes might
be required or whether responsibilities are properly
grouped among the classes.
 Determine whether widely requested responsibilities
might be combined into a single responsibility.
OO Testing Strategies
 Unit testing
 the concept of the unit changes
 the smallest testable unit is the encapsulated class
 a single operation can no longer be tested in isolation (the
conventional view of unit testing) but rather, as part of a class
 Integration Testing
 Thread-based testing integrates the set of classes required to respond
to one input or event for the system
 Use-based testing begins the construction of the system by testing
those classes (called independent classes) that use very few (if any) of
server classes. After the independent classes are tested, the next layer
of classes, called dependent classes
 Cluster testing [McG94] defines a cluster of collaborating classes
(determined by examining the CRC and object-relationship model) is
exercised by designing test cases that attempt to uncover errors in
the collaborations.
OO Testing Strategies
 Validation Testing
 details of class connections disappear
 draw upon use cases (Chapters 5 and 6) that are part
of the requirements model
 Conventional black-box testing methods (Chapter
18) can be used to drive validation tests
OOT Methods
Berard [Ber93] proposes the following approach:
1. Each test case should be uniquely identified and should be explicitly

associated with the class to be tested,
2. The purpose of the test should be stated,
3. A list of testing steps should be developed for each test and should
contain [BER94]:
a. a list of specified states for the object that is to be tested
b. a list of messages and operations that will be exercised as
a consequence of the test
c. a list of exceptions that may occur as the object is tested
d. a list of external conditions (i.e., changes in the environment
external to the software that must exist in order to properly
conduct the test)
e. supplementary information that will aid in understanding or
implementing the test.
Testing Methods
 Fault-based testing
 The tester looks for plausible faults (i.e., aspects of the
implementation of the system that may result in defects). To
determine whether these faults exist, test cases are designed to
exercise the design or code.
 Class Testing and the Class Hierarchy
 Inheritance does not obviate the need for thorough testing of all
derived classes. In fact, it can actually complicate the testing
process.
 Scenario-Based Test Design
 Scenario-based testing concentrates on what the user does, not
what the product does. This means capturing the tasks (via use-
cases) that the user has to perform, then applying them and their
variants as tests.
OOT Methods: Random Testing
 Random testing
 identify operations applicable to a class
 define constraints on their use
 identify a minimum test sequence
• an operation sequence that defines the minimum life
history of the class (object)
 generate a variety of random (but valid) test sequences
• exercise other (more complex) class instance life
histories
OOT Methods: Partition Testing
 Partition Testing
 reduces the number of test cases required to test a class in
much the same way as equivalence partitioning for
conventional software
 state-based partitioning
• categorize and test operations based on their ability to change
the state of a class
 attribute-based partitioning
• categorize and test operations based on the attributes that they
use
 category-based partitioning
• categorize and test operations based on the generic function
each performs
OOT Methods: Inter-Class Testing
 Inter-class testing
 For each client class, use the list of class operators to
generate a series of random test sequences. The
operators will send messages to other server classes.
 For each message that is generated, determine the
collaborator class and the corresponding operator in the
server object.
 For each operator in the server object (that has been
invoked by messages sent from the client object),
determine the messages that it transmits.
 For each of the messages, determine the next level of
operators that are invoked and incorporate these into the
test sequence
OOT Methods: Behavior Testing
The tests to be empty set up
designed should open acct setup Accnt acct
achieve all state

deposit
coverage [KIR94]. (initial)
That is, the deposit
operation sequences
should cause the working
acct
Account class to balance
credit withdraw
make transition accntInfo
through all withdrawal
allowable states (final)
dead nonworking
acct close acct
Figure 1 4 .3 St a t e diagram for Ac count c las s (a dapt ed f rom [ KIR9 4 ])

Software Engineering A Practitioner's Approach - Roger S. Pressman

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering A Practitioner's Approach - Roger S. Pressman

Uploaded by

Copyright:

Available Formats

Chapter 1

 Software & Software Engineering

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

 Software for nanotechnologies

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

project calendar t ime

rep res ents the state

Elaborat ion phase

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

accep t ance t est ing

DSDM Life Cycle (with permission of the DSDM consortium)

Scrum Proce ss Flow (use d wit h pe rm ission)

Reprinted with permission of Peter Coad

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

form a l priorit iz a t ion?

Us e QFD t o inform a lly de fine a c t ors

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

Configure Safe Hom e

representation of the se le c t ma jor func t ion prompt for re e n try

scenario t hum bnail views s elect a specif ic cam er a

vie w c a me ra out put

exit t his f unct ion s ee anot her cam er a

Allows the modeler to

activities described by the a nd us e r ID

use-case and at the same

(if there are multiple

actors involved in a o t h er f u n ct io n s prom pt fo r re e nt ry

analysis class has

responsibility for the n o in p u t

vie w c a m e ra ou t put p rom p t for

PlayerHead PlayerBody PlayerArms PlayerLegs

is used to build is used to build

1..* 0..* is used to build 0..*

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

 Represents how data objects are transformed at they

Examples: a person, a device, a sensor

Another example: computer-based

Data must always originate somewhere

Examples: compute taxes, determine area,

Data must always be processed in some

Data flows through a system, beginning

state transition table

t ime r > lo cke d Time locke d

re ad in g comparin g n u mb e rOfTrie s > maxTrie s

act iv at io n s u cce s sfu l

h o meo wn er co n t ro l p an el syst em sen

t imer > lo cked Time

act ivat io n su ccessfu l act ivat io n su ccessfu l

Te c hDe s c ript ion

 a user interface prototype

 Each of these is an important UML notation

new cust o mer

c ust omiz a t ion c omple t e

se le c t c ust omiz a t ion func t iona lit y

Building floor p la n se le ct de script iv e