OOAD Analysis and Design Fundamentals

Unit I -OOAD
Dr.S.Gunasundari
ASSOCIATE PROF
VELAMMAL ENGINEERING COLLEGE

Analysis
• Analysis emphasizes an investigation of the
problem and requirements, rather than a
solution.
• In software development, we are primarily
concerned with two forms of analysis.
– Requirements Analysis is discovering the
requirements that a system must meet in order to
be successful.
– Object-Oriented Analysis is investigating the
objects in a domain to discover information
important to meet the requirements.
3/9/2022 Dr.S.Gunasundari/CSE/VEC 2

Use Cases
• Writing Use Cases is not a specifically OO
artifact – they are simply written stories.
• However, they are a best practice for
elaborating and understanding
requirements.

Use Case 1
Use Case 1 Do laundry
Actor Housekeeper
Basic Flow
On Wednesdays, the housekeeper reports to the
laundry room. She sorts the laundry that is
there. Then she washes each load. She dries
each load. She folds the items that need
folding. She irons and hangs the items that are
wrinkled. She throws away any laundry item that
is irrevocably shrunken, soiled or scorched.

Use Case Name: Place Order
Actors:
• Shopper
• Fulfillment System
• Billing System
Use Case Description: After the user has selected items
to purchase and then order the items. The user will
provide payment and shipping information. The system
will respond with confirmation of the order and a tracking
number that the user can use to check on order status in
the future. The system will also provide the user with an
estimated delivery date for the order, which will include
all selected items. The user may already have an
account with the company with billing and shipping
information

Design
• Design emphasizes a conceptual solution
that fulfills the requirements, rather than its
implementation.
– Design ideas often exclude low-level or
obvious details – obvious to the intended
consumers.
– There are subsets of design, including
• architectural design,
• object design,
• database design.

Object-Oriented Analysis and
Design (OOAD)
• During OOA, the emphasis is on finding and
describing the objects (or concepts) in the problem
domain, i.e., domain objects.
• During OOD (or simply object design), the emphasis
is on defining software objects and how they
collaborate to fulfill the requirements.
• During OOP (OO Programming) or Implementation,
design objects are implemented in a programming
language.
– Implementation is also known as Coding or
Construction.

Plane
tailNumber
public class Plane
{
private String tailNumber;
public List getFlightHistory() {...}
}
domain concept
visualization of
domain concept
representation in an
object-oriented
programming language
Fig. 1.2 Object-orientation emphasizes representation of objects

A Short Example
Problem Statement: a "dice game" in which
software simulates a player rolling two dice. If
the total is seven, they win; otherwise, they lose.
OOAD steps of a small “Dice Game”:
– Define Use Cases
– Define a Domain Model
– Define Interaction Diagrams
– Define Design Class Diagrams

Use Case: Play a Dice Game
• Requirements analysis may include stories
or scenarios of how people use the
application; these can be written as use
cases
• Use cases are not an object-oriented
• UseCase:
– Player requests to roll the 2 dice. System
presents results. If the dice face value totals
seven, player wins; otherwise, player loses.
Define Use Cases

Partial Domain Model
• Object-oriented analysis is concerned with
creating a description of the domain from
the perspective of objects.
• There is an identification of the concepts,
attributes, and associations that are
considered noteworthy.
• The result can be expressed in a domain
model that shows the noteworthy domain
concepts or objects.

Player
name
DiceGame
Die
faceValue
Rolls
Plays
Includes
2
2
1
1
1
1
Fig. 1.3 Partial domain model (conceptual object model) of the dice game
Define a Domain Model
Domain model shows the noteworthy domain concepts as objects, their
attributes, and associations.
Domain model is not a description of software objects; it is a visualization of the
concepts
Thus, it has also been called a conceptual object model.

• Object-oriented design is concerned with
defining software objects their responsibilities
and collaborations.
• A common notation to illustrate these
collaborations is the sequence diagram (a kind of
UML interaction diagram).
• It shows the flow of messages between software
objects, and thus the invocation of methods
• sending messages to instances of the DiceGame
and Die classes
• UML Sketching on whiteboard
Interaction Diagrams

:DiceGame
play()
die1 : Die
fv1 := getFaceValue()
die2 : Die
roll()
roll()
fv2 := getFaceValue()
Fig. 1.4 Sequence diagram illustrating messages between software objects
A sequence diagram (a kind of UML interaction diagram) shows the flow of messages
between software objects and thus the invocation of objects.

2
Die
faceValue : int
getFaceValue() : int
roll()
DiceGame
die1 : Die
die2 : Die
play()
1
Fig. 1.5 Partial design class diagram (software classes)
Define Design Class Diagrams
A static view of the class (including its attributes and methods) definitions is usefully
shown with a UML class diagram.

Unified Modeling Language
(UML)
• UML is the de facto standard diagramming
notation for drawing or presenting pictures
related to OO software.
• UML is a visual language for specifying,
constructing and documenting the artifacts
of OO systems.
– Knowing UML helps you communicate with
others in creating software.

Three ways people apply UML are
...
• UML as sketch
• Informal and incomplete diagrams (often hand sketched on whiteboards) created to explore
difficult parts of the problem or solution space
• UML as blueprint
– relatively detailed design diagrams
– used either for reverse engineering to visualize and better understand
existing code,
• If reverse engineering, a UML tool reads the source or binaries and generates (typically)
UML package, class, and sequence diagrams
– or for forward engineering to guide for code generation, either manually
or automatically with a tool.
• UML as a programming language
– Complete executable specification of a software system in UML.
– Executable code will be automatically generated, but is not normally
seen or modified by developer

Three perspectives to apply UML
are ...
• Conceptual perspective – the diagrams are
interpreted as describing things in a situation of
the real world or domain of interest.
• Specification (software) perspective – the
diagrams describe sw abstractions or components
with specifications and interfaces, but no
commitment to a particular language
implementation.
• Implementation perspective – the diagrams
describe sw implementations in a particular
technology.

The meaning of “class” in different
perspectives
• Conceptual class – real-world concept or thing. A
conceptual or essential perspective.
– The UP Domain Model contains conceptual classes.
• Software class – a class representing a
specification or implementation perspective of a
sw development, regardless of the process or
method.
• Implementation class – a class implemented in a
specific OO language such as Java.

Conceptual Perspective
(domain model)
Raw UML class diagram
notation used to visualize
real-world concepts.
Specification or
Implementation
Perspective
(design class diagram)
Raw UML class diagram
notation used to visualize
software elements.
2
Die
faceValue : int
getFaceValue() : int
roll()
DiceGame
die1 : Die
die2 : Die
play()
DiceGame Die
faceValue
Includes 2
1
Fig. 1.6 Different perspectives with UML
In practice, most software-oriented UML diagramming assumes an implementation
perspective and the specification perspective is seldom used for design.

Iterative development and UP
• Iterative development is a skillful approach to
software development
• The Unified Process is an example
iterative process for projects using OOAD
• software development process describes
an approach to building,deploying, and
possibly maintaining software.
• The Unified Process has emerged as a
popular software development process for
building object-oriented systems.

Iterative Development
• In this approach, development is organized into a series
of short, fixed-length (for example, four week) mini-
projects called iterations;
• The outcome of each is a tested, integrated, and
executable system.
• Each iteration includes its own requirements analysis,
design, implementation, and testing activities.
• The iterative lifecycle is based on the successive
enlargement and refinement of a system through
multiple iterations, with cyclic feedback and adaptation
as core drivers to converge upon a suitable system.
• The system grows incrementally over time, iteration by
iteration, and thus this approach is also known as
iterative and incremental development

Requirements
Design
Implementation&
Test&Integration
&More Design
Final Integration
& System Test
3weeks
(for example)
The system
grows
incrementally
.
Time
Fig. 2.1 Iterative and Evolutionary Development (also known as iterative and inceremental
development; spiral development and evolutionary development)
Requirements
Design
Implementation&
Test&Integration
&More Design
Final Integration
& System Test
Each iteration is an executable
but incomplete system;
A subset of the final system
(but not a throw-away prototype!)
Iterations are fixed in
length or timeboxed.
Feedback from iteration N
Leads to refinement and
adaptation of
The requirements and
design in
İteration N+1

Example
As an example, in a two-week iteration half-way through a project, perhaps Monday
is spent primarily on distributing and clarifying the tasks and requirements of the
iteration.
Tuesday is spent at whiteboards doing pair design work drawing rough UML
diagrams captured on digital cameras, and writing some pseudocode and design
notes.
The remaining eight days are spent on implementation, testing (unit, acceptance,
usability, ...), further design, integration, daily builds, system testing, and
stabilization of the partial system.
Other activities include demonstrations and evaluations with stakeholders, and
planning for the next iteration.
• The result of each iteration is an executable but incomplete system;
• it is not ready to deliver into production.
• The system may not be eligible for production deployment until after many
iterations;
• for example, 10 or 15 iterations.

Feedback and Adaptation
• Each iteration involves choosing a small subset of the
requirements, and quickly designing, implementing, and testing.
• In early iterations the choice of requirements and design may
not be exactly what is ultimately desired.
• But the act of swiftly taking a small step, before all requirements
are finalized, or the entire design is speculatively defined, leads
to rapid feedback—feedback from the users, developers, and
tests (such as load and usability tests).
• This early feedback is worth its weight in gold
• Feedback provides an opportunity to modify or adapt
understanding of the requirements or design

Build-Feedback-Adapt Cycles
In complex changing systems, feedback and
adaptation are key ingredients for success:
– Feedback from early development, programmers
• to refine the requirements.
– Feedback from tests and developers
• to refine the design and models.
– Feedback from the progress of the team tackling
early features
• to refine the schedule and estimates.
– Feedback from the client and marketplace to re-
prioritize the features
• to tackle in the next iteration.

• End-users have a chance to quickly see a
partial system and say, "Yes, that's what I
asked for, but now that I try it, what I really
want is something slightly different."
• This "yes...but" process is not a sign of
failure; rather, early and frequent structured
cycles of "yes...buts" are a skillful way to
make progress and discover what is of real
value to the stakeholders.

Fig. 2.2 Iterative feedback and evolution leads towards the desired system. The
requirements and design instability lowers over time.
Early iterations are farther from the "true
path" of the system. Via feedback and
adaptation, the system converges towards
the most appropriate requirements and
design.
In late iterations, a significant change in
requirements is rare, but can occur. Such
late changes may give an organization a
competitive business advantage.
one iteration of design,
implement, integrate, and test

Benefits of Iterative Development
• early rather than late mitigation of high risks (technical,
requirements, objectives, usability, and so forth)
• early visible progress
• early feedback, user engagement, and adaptation,
leading to a refined system that more closely meets the
real needs of the stakeholders
• managed complexity; the team is not overwhelmed by
"analysis paralysis" or very long and complex steps
• the learning within an iteration can be methodically
used to improve the development process itself, iteration
by iteration

Timeboxing
• A key idea is that iterations are timeboxed,
or fixed in length.
– Most iterative methods recommend in
iteration length bw 2 – 6 weeks.
– If it seems that it will be difficult to meet the
deadline, the recommended response is to
de-scope
• De-scoping: removing tasks or requirements from the iteration, and
including them in a future iteration, rather than slipping the
completion date.

Fig. 2.4 Evolutionary analysis and design – the majority in early iterations.
Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5
20 %
2%
requirements
software
30 %
5%
requirements
software
50 %
8%
90 % 90 %
20 %
10 %
requirements workshops
Imagine this will
ultimately be a 20 -
iteration project .
In evolutionary iterative
development , the
requirements evolve
over a set of the early
iterations , through a
series of requirements
workshops (for
example ). Perhaps
after four iterations and
workshops , 90 % of the
requirements are
defined and refined .
Nevertheless , only
10 % of the software is
built .
1 2 3 4 5 ... 20
week 1
M
T W Th F
week 2
M T W Th F
week 3
M T W Th F
kickoff meeting
clarifying iteration
goals with the team
.
1 hour
team agile
modeling&
design
,
UML
whiteboard
sketching
.
5 hours
start
coding&
testing
a 3-week iteration
de-scope
iteration
goals if
too much
work
final check
-in
and code
-
freeze for the
iteration
baseline
demo and
2-day
requirements
workshop
next
iteration
planning
meeting
;
2 hours
Most OOA/D and
applying UML during
this period
Use-case modeling
during the workshop

The Unified Process (UP)
• A software development process describes
an approach to building, deploying, and
possibly maintaining software.
• UP has emerged as a popular and effective
iterative software development process for
building OO systems.
– In particular, the Rational Unified Process, as
modified at Rational Software, is widely practiced
and adopted by industry.

Unified Process
• Unified Process is based on the
enlargement and refinement of a system
through multiple iterations, with cyclic
feedback and adaptation.
• The system is developed incrementally
over time, iteration by iteration, and thus
this approach is also known as iterative
and incremental software development.

• A UP project organizes the work and
iterations across four major phases:
– Inception approximate vision, business case,
scope, vague estimates.
– Elaboration refined vision, iterative
implementation of the core architecture, resolution
of high risks, identification of most requirements
and scope, more realistic estimates.
– Construction iterative implementation of the
remaining lower risk and easier elements, and
preparation for deployment.
– Transition beta tests, deployment.

• This is not the old "waterfall" or sequential lifecycle
of first defining all the requirements, and then
doing all or most of the design.
• Inception is not a requirements phase; rather, it is
a kind of feasibility phase, where just enough
investigation is done to support a decision to
continue or stop.
• Similarly, elaboration is not the requirements or
design phase; rather, it is a phase where the core
architecture is iteratively implemented, and high
risk issues are mitigated.

Fig. 2.6 Schedule-oriented terms in the UP
inc. elaboration construction transition
iteration phase
development cycle
release
A stable executable
subset of the final
product. The end of
each iteration is a
minor release.
increment
The difference
(delta) between the
releases of 2
subsequent
iterations.
final production
release
At this point, the
system is released
for production use.
milestone
An iteration end-
point when some
significant decision
or evaluation
occurs.

UP Phases
1 Inception
 Inception is not a requirements phase; rather a feasibility phase, where
just enough investigation is done to support a decision to continue or
stop.
 The life-cycle objectives of the project are stated, so that the needs of
every stakeholder are considered. Scope and boundary conditions,
acceptance criteria and some requirements are established.
 Approximate vision, business case, scope, vague estimates.
2 Elaboration
 An analysis is done to determine the risks, stability of vision of what the
product is to become, stability of architecture and expenditure of
resources.
 Refined vision, iterative implementation of core architecture, resolution
of high risks, identification of most requirements and scope, more
realistic estimates.

UP Phases (2)
3 Construction
– The Construction phase is a manufacturing process. It emphasizes
managing resources and controlling operations to optimize costs,
schedules and quality. This phase is broken into several iterations.
– Iterative implementation of the remaining lower risk and easier
elements, and preparation for deployment.
4 Transition
– The transition phase is the phase where the product is put in the hands
of its end users. It involves issues of marketing, packaging, installing,
configuring, supporting the user-community, making corrections, etc.
– Beta tests, deployment.

Inception
The Inception Phase includes such activities as:
• Defining the business case
• Creating a vision document with core requirements, features, and
constraints
• Creating an initial risk assessment
• Creating early use cases (10-20% complete, mostly use-case models)
• Creating a initial project plan
• And the creation of one or more prototypes (especially architectural
prototypes)
The milestones that how completion of the Inception phase are:
• Stakeholder agreement on business case, scope, and project cost and
schedule estimates
• Agreement that the content of the primary use cases is an accurate
representation of what the software will deliver (at a high level)
• That the final prototypes are sufficient indications of the correct future
development goals

Elaboration Phase
The specific activities of this phase include:
• The identification of all actors and use cases, with most use cases having been defined to at least
80% completion (use-case descriptions rather than models)
• Supplementary requirements detailing the non-functional requirements and any requirements not
related to a use case are completed
• A Software Architecture Description has been completed
• The business case and risk lists have been updated with higher-confidence information
• The project and development plans have been defined to at least a level that shows all iterations
and the evaluation criteria for each iteration
• An executable architecture prototype has been created and approved for use (this may involve
creating more than one)
• A preliminary user manual has been created (optional)
The milestones that show completion of the Elaboration phase are:
• The product vision is stable and approved
• The product architecture is stable and approved
• The executable architecture prototype shows that the major risk elements have been identified
and credibly resolved
• The project and development plans sufficiently detailed, accurate, and credible
• All stakeholders agree that the vision can be achieved is the project and development plans are
executed with the architecture specified

Construction Phase
• The software is built, integrated, and tested
• The user manuals have been created (or updated)
• The details of the software developed are documented
and ready to be provided to end users or support staff
(including changes, etc.)
The milestones that show completion of the Construction
phase are:
• The software product is stable and mature enough to
be deployed to end users
• All stakeholders are ready to transition to the new /
updated software
• Actual versus planned expenditures are still acceptable
enough to move forward with the project

Transition Phase
• beta testing or user acceptance testing by end users
to validate the new software against user expectations
• Parallel operation with legacy systems (if in existence)
that will be replaced
• Operational databases are converted (if necessary)
• Users and maintainers of the software are fully trained
• The software is fully rolled-out
The milestones that show completion of the Transition
phase are:
• Users are satisfied with the software
• Actual versus planned expenditures are still
acceptable enough to move forward with the project

UP Disciplines (Workflows)
• In the UP, an artifact is the general term for any work product: code,
Web graphics, database schema, text documents, diagrams, models, and
so on.
• There are several disciplines in the UP;
Business Modeling
 When developing a single application, this includes domain object
modeling.
 When engaged in large-scale business analysis this includes dynamic
modeling of the business processes across the entire enterprise.
• Activities include the development of:
– A context model showing how the system fits into its overall
environment
– A high-level business requirements model eg. use case model
– A domain model e.g. class diagram or data diagram depicting
major business classes or entities
– A business process model

Requirements
The main deliverable of this discipline is the Software
Requirements Specification (SRS), also referred to as
the Requirements Model, which encompasses the
captured requirements
Design
All aspects of design, including the overall architecture,
objects,databases, networking, etc
Implementation means programming and building the
system, not deployment.
Test—involves testing activities such as test planning,
development of test scenarios, alpha and beta
testing, regression testing, acceptance testing, and
Deployment—the deployment activities of developed
system

The Environment discipline refers to establishing the tools and
customizing the process for the project—that is, setting up the tool
and process environment.
During one iteration work goes on in most or all disciplines.
However, the relative effort across these disciplines changes over
time.
Early iterations naturally tend to apply greater relative emphasis to
requirements and design, and later ones less so, as the
requirements and core design stabilize through a process of
feedback and adaptation

Fig. 2.7 UP disciplines
Iterations
Sample
UP Disciplines
Business Modeling
Requirements
Design
Implementation
Test
Deployment
Configuration & Change
Management
Project Management
Environment
Focus
of this
book
Note that
although an
iteration includes
work in most
disciplines, the
relative effort and
emphasis change
over time.
This example is
suggestive, not
literal.
A four-week iteration (for example).
A mini-project that includes work in most
disciplines, ending in a stable executable.

changing relative effort with respect to the phases
During construction, the emphasis is heavier on
implementation and lighter on requirements analysis

s-start, r-revise
Development Case
short document
describing the
artifacts for the
"NextGen
Project" case
study

CASE STUDY: THE NEXTGEN POS SYSTEM /NextGen point-of-sale (POS) system
 A POS system is a computerized application used (in part) to record sales and
handle payments; it is typically used in a retail store.
 It includes hardware components such as a computer and bar code scanner,
and software to run the system.
 It interfaces to various service applications, such as a third-party tax calculator
and inventory control.
 These systems must be relatively fault-tolerant;
 that is, even if remote services are temporarily unavailable (such as the
inventory system), they must still be capable of capturing sales and
handling at least cash payments (so that the business is not crippled).
 A POS system increasingly must support multiple and varied client-side
terminals and interfaces.
 These include a thin-client Web browser terminal, a regular
 personal computer with something like a Java Swing graphical user interface,
 touch screen input, wireless PDAs, and so forth.
 Furthermore, we are creating a commercial POS system that we will sell to
different clients with disparate needs in terms of business rule processing.
 Each client will desire a unique set of logic to execute at certain
predictable points in scenarios of using the system, such as when a new
sale is initiated or when a new line item is added.
 Therefore, we will need a mechanism to provide this flexibility and
customization.

subsystems
User Interface—graphical interface; windows.
Application Logic and Domain Objects—software
objects representing
• domain concepts (for example, a software class
named Sale) that fulfill application requirements.
Technical Services—general purpose objects and
subsystems that provide
• supporting technical services, such as interfacing
with a database or error
• logging. These services are usually application-
independent and reusable across several systems.

• The NextGen case study primarily
emphasizes the problem domain objects,
allocating responsibilities to them to fulfill
the requirements of the application.
• Object-oriented design is also applied to
create a technical service subsystem for
interfacing with a database
• UI layer has very little responsibility; it is
said to be thin.

SAMPLE LAYERS

• OOAD is applied to the NextGen POS
system in multiple iterations
• The first iteration is for some core
functions.
• Later iterations expand the functionality
of the system
• In conjunction with iterative
development, the presentation of
analysis and design topics, UML
notation, and patterns are introduced
iteratively and incrementally.
• In the first iteration, a core set of analysis
and design topics and notation is
presented.
• The second iteration expands into new
ideas, UML notation, and patterns.
• And likewise in the third iteration

Inception
• Most projects require a short initial step
– What is the vision and business case for this project?
– Feasible?
– Buy and/or build?
– Rough estimate of cost: Is it $10K-100K or in the
millions?
– Should we proceed or stop?
• Inception in one sentence:
– Envision the product scope, vision, and business case.
• Do the stakeholders have basic agreement on the
vision of the project, and is it worth investing in
serious investigation?

Purpose of Inception
• Establish vision, scope and business case
– Vision: What do we want?
– Scope: What do we include and not include?
– Business case: Who wants it and why?
• Determine primary scenarios as Use Cases
– Completeness not necessary, maybe just 10%
• Estimate feasibility and risks
• Start defining terms in a glossary. Why?
• Creation of a development environment
How long does it take?
Can be as short as a day or two, as long as a few
weeks

What it isn’t
• Defining precise requirements
• Getting good estimates
• Purpose of the inception step is not to
define all the requirements, or generate a
believable estimate or project plan

What gets defined?
• Business case
• Some of the use cases
• Other (usually non-functional) requirements
• Key domain terminology
• List of risks (business, resource, technical,
schedule) and risk management plan
• Prototypes
• Iteration plan
• Phase plan
• Development case

Analogy from oil business
1. Decide if there is evidence (business case) to
justify exploratory drilling
2. If so, do measurements and exploratory
drilling
3. Provide estimates …
• Inception is like step 1: a feasibility study to
decide if it is even worth investing in
exploratory drilling
Another analogy: consulting with a doctor to
do exploratory surgery
In the oil business, when a new field is being considered,
some of the steps include:

Example vision & business case
Introduction
We envision a next generation fault-tolerant point-of-sale
(POS) application, NextGen POS, with the flexibility to
support varying customer business rules, multiple terminal
and user interface mechanisms, and integration with multiple
third-party supporting systems.
Business Case
Existing POS products are not adaptable to the customer's
business, in terms of varying business rules and varying
network designs (for example, thin client or not; 2, 3, or 4-tier
architectures). In addition, they do not scale well as terminals
and business increase. None can work in either on-line or
off-line mode, dynamically adapting depending on failures.
None easily integrate with many third-party systems. None
allow for new terminal technologies such as mobile PDAs.
There is marketplace dissatisfaction with this inflexible state
of affairs, and demand for a POS that rectifies this.

Brief format Use Case
• A story of an actor using a system to meet a goal
Process Sale: A customer arrives at a checkout
with items to purchase. The cashier uses the POS
system to record each purchased item.
The system presents a running total and
line-item details. The customer enters payment
information, which the system validates and
records. The system updates inventory.
The customer receives a receipt from the system
and then leaves with the items.

Glossary
Term Definition Format Aliases
item A product or service for sale
Payment
authorization
Validation by an external
payment authorization service
that they will make or guarantee
the payment to the seller.
UPC Numeric code that identifies a
product. Usually symbolized
with a bar code placed on
products.
12-digit
code of
several
subparts
Universal
Product Code

Sample inception
artifacts
These artifacts are only partially completed
in this phase. They will be iteratively
refined in subsequent iterations

Requirements
• Capabilities and conditions to which the
system must conform
• A systematic approach to finding,
documenting, organizing the changing
requirements of a system.
• prime challenge of requirements work is to
find, communicate, and remember (that
usually means record) what is really needed,
in a form that clearly speaks to the client and
development team members.

Factors on challenged projects
• one study of factors on challenged
projects revealed that 37% of factors
related to problems with requirements,
making requirements issues the largest
single contributor to problems
• Incomplete requirements
• Changing requirements

• 25% of the requirements change on a
project
• Attempting to define all requirements was
the main problem in 82% of projects
• When attempting to specify all features in
advance, 45% of such features were never
used

FURPS+ model
(Grady 1992)
FURPS is a checklist for requirements:
• Functional (features, capabilities, security)
• Usability (human factors, help, documentation)
• Reliability (frequency of failure, recoverability,
predictability)
• Performance (response time, throughput,
accuracy, availability, resource usage)
• Supportability (adaptability, maintainability,
internationalization, configurability)

• "+" in FURPS+ indicates ancillary and sub-
factors, such as:
• Implementation—resource limitations,
languages and tools, hardware, ...
• Interface—constraints imposed by
interfacing with external systems.
• Operations—system management in its
operational setting.
• Packaging
• Legal—licensing and so forth.

quality attributes,
quality requirements
• Usability
• Reliability
• Performance
• supportability
functional (behavioral)
non-functional (everything else)
Types of requirements

Functional and non-functional
• Functional requirements describe system behaviors
– Priority: rank order the features wanted in importance
– Criticality: how essential is each requirement to the
overall system?
– Risks: when might a requirement not be satisfied?
What can be done to reduce this risk?
• Non-functional requirements describe other desired
attributes of overall system
– Product cost (how do measure cost?)
– Performance (efficiency, response time? startup time?)
– Portability (target platforms?), binary or byte-code
compatibility?
– Availability (how much down time is acceptable?)
– Security (can it prevent intrusion?)
– Safety (can it avoid damage to people or environment?)
– Maintainability (in OO context: extensibility, reusability)

• Functional requirements are explored and recorded in the
Use-Case Model
• Other requirements can be recorded in the use cases they
relate to, or in the Supplementary Specifications artifact.
• The Vision artifact summarizes high-level requirements that
are elaborated in these other documents.
• The Glossary records and clarifies terms used in the
requirements. The Glossary in the UP also encompasses the
concept of the data dictionary, which records requirements
related to data, such as validation rules, acceptable values,
and so forth.
• Prototypes are a mechanism to clarify what is wanted or
possible.

Requirements Organization in the
UP
• Use-case model
• Supplementary specification
• Glossary
• Vision
• Business rules. Policies that apply to all
software projects. E.g. Tax laws, data
security, etc.

Use Case
• Use cases are text stories (not diagrams!) used to discover and
record requirements
• Excellent technique to understand and describe requirements.
• Use cases are functional requirements that indicate what the
system will do
• The UP defines the Use-Case Model within the Requirements
discipline
– set of all use cases; it is a model of the system's functionality and
environment
• Use cases are text documents, not diagrams, and use-case
modeling is primarily an act of writing text, not drawing.
• However, the UML defines a use case diagram to illustrate the
names of use cases and actors, and their relationships
72
Dr.S.Gunasundari/CSE/VEC

• Use case plays a significant role in the distinct
phases of the Software Development Life Cycle.
• Use Case depends on ‘User Actions’ and ‘Response
of System’ to the User Actions
• It is the documentation of the ‘Actions’ performed by
the Actor/User and the corresponding ‘Behaviour’ of
the System to the User ‘Actions’
Uses of the Documents:
• Developers use the documents for implementing the
code and designing it.
• Testers use them for creating the test cases.
• Business stakeholders use the document for
understanding the software requirements.
Dr.S.Gunasundari/CSE/VEC 73

Definitions/ Elements in Use Cases
• Brief description
– A brief description explaining the case.
• Actor
– something with a behavior, such as a person, an input
device, etc.
– Users that are involved in Use Cases Actions
– eg cashier
• Scenario – Specific sequence of actions and interactions
between actors. (also called a use-case instance)
– Successfully purchasing items with cash
– scenario of failing to purchase items because of a credit card
transaction denial
• Use Case is a collection of related success and failure
scenarios that describe an actor using a system to support
a goal
74

Primary Actor
• The person (or sometimes object) that
calls upon system services to fulfill a goal
• Supporting actors : provide services to the system under
design.
stakeholders
• The stakeholders are people who have a
reason to want this system. The Interests
are their reasons for wanting it and what
they expect from it.

Preconditions:
• Conditions to be Satisfied before the case
begins
• Cashier is identified and authenticated.
Success Guarantee (Postconditions):
The conditions that need to be checked after
the case is completed.
• Sale is saved. Tax is correctly calculated.
• Accounting and Inventory are updated.
Commissions recorded. Receipt is generated.
• Payment authorization approvals are
recorded.
.

Example 1
Use Case Name Login
Use case Description A user login to System to access the
functionality of the system.
Actors Parents, Students, Teacher, Admin
Pre-Condition System must be connected to the
network.
Post -Condition After a successful login a notification mail
is sent to the User mail id

Basic Flow:
• ‘Basic Flow’ or ‘Main Scenario’ is the normal
workflow in the system. It is the flow of
transactions done by the Actors on accomplishing
their goals.
• When the actors interact with the system, as it’s
the normal workflow, there won’t be any error and
the Actors will get the expected output.
Alternate flow:
• Apart from the normal workflow, a system can
also have an ‘Alternate workflow’.
• This is the less common interaction done by a
user with the system.

Main Scenarios Serial No Steps
Actors/Users 1 Enter username
Enter Password
2 Validate Username and Password
3 Allow access to System
Extensions 1a Invalid Username
System shows an error message
2b Invalid Password
System shows an error message
3c Invalid Password for 4 times
Application closed

Three Formats
• Brief – Concise, one-paragraph summary, usually the
main success scenario. Create during early
requirements phase.
• Casual – Informal paragraph format. Can cover various
scenarios in multiple paragraphs.
• Fully-dressed – All steps and variations written in detail.
Has supporting sections, success guarantees, main
scenario, alternate scenarios, etc.

brief format use case
Process Sale: A customer arrives at a checkout with items to
purchase. The cashier uses the POS system to record each
purchased item. The system presents a running total and
line-item details. The customer enters payment information,
which the system validates and records. The system updates
inventory. The customer receives a receipt from the system
and leaves with the items.
(OR)
Use case: Buy Items •
Actors: Customer, Cashier •
Primary •
Description: A customer arrives at checkout with items
to purchase. The Cashier records the purchase items and
collects payment, On completion, the Customer leaves with
the items.
82

Use Case Example
Handlereturn
Main Success Scenario: A customer arrives at a checkout
with items to return. The cashier uses the POS system to
record each returned item ...
Alternate Scenarios:
• If the credit authorization is reject, inform the customer and
ask for an alternate payment method.
• If the item identifier is not found in the system, notify the
Cashier and suggest manual entry of the identifier code
(perhaps it is corrupted).
• If the system detects failure to communicate with the
external tax calculator system
83

Write Black-Box Use Cases
• Don’t describe internal workings
• Describe responsibilities
• “The system records the sale” – Correct One
• “The System writes the sale record to a
database” –Wrong
• By defining system responsibilities with black-
box use cases, it is possible to specify what
the system must do (the functional
requirements) without deciding how it will do it

CASE STUDY: THE NEXTGEN POS SYSTEM /NextGen point-of-sale (POS)
system
 A POS system is a computerized application used (in part) to record sales and
handle payments; it is typically used in a retail store.
 It includes hardware components such as a computer and bar code scanner, and
software to run the system.
 It interfaces to various service applications, such as a third-party tax calculator and
inventory control.
 These systems must be relatively fault-tolerant;
 that is, even if remote services are temporarily unavailable (such as the
inventory system), they must still be capable of capturing sales and handling at
least cash payments (so that the business is not crippled).
 A POS system increasingly must support multiple and varied client-side terminals
and interfaces.
 These include a thin-client Web browser terminal, a regular personal computer
with something like a Java Swing graphical user interface, touch screen input,
wireless PDAs, and so forth.
 creating a commercial POS system that we will sell to different clients with
disparate needs in terms of business rule processing.
 Each client will desire a unique set of logic to execute at certain predictable
points in scenarios of using the system, such as when a new sale is initiated or
when a new line item is added.
 Therefore, we will need a mechanism to provide this flexibility and
customization.

Fully Dressed Example: Process Sale
Use Case UC1: Process Sale
Primary Actor: Cashier
Stakeholders and Interests:
- Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer short
ages are deducted from his/her salary.
- Salesperson: Wants sales commissions updated.
- Customer: Wants purchase and fast service with minimal effort. Wants proof of pur
chase to support returns.
- Company: Wants to accurately record transactions and satisfy customer interests.
Wants to ensure that Payment Authorization Service payment receivables are
recorded. Wants some fault tolerance to allow sales capture even if server compo
nents (e.g., remote credit validation) are unavailable. Wants automatic and fast
update of accounting and inventory.
- Government Tax Agencies: Want to collect tax from every sale. May be multiple agen
cies, such as national, state, and county.
- Payment Authorization Service: Wants to receive digital authorization requests in the
correct format and protocol. Wants to accurately account for their payables to the
store

Main Success Scenario (or Basic
Flow):
1. Customer arrives at POS checkout with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price, and
running total.
Price calculated from a set of price rules.
Cashier repeats steps 3-4 until indicates done
System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.
8. System logs completed sale and sends sale and payment information to the
external Accounting system (for accounting and commissions) and Inventory
system (to update inventory).
9. System presents receipt.
10.Customer leaves with receipt and goods (if any).

Extensions (or Alternative Flows):
*a. At any time, System fails:
To support recovery and correct accounting,
ensure all transaction sensitive state and
events can be recovered from any step of the
scenario.
1. Cashier restarts System, logs in, and requests recovery
of prior state.
2. System reconstructs prior state.
2a. System detects anomalies preventing recovery:
1. System signals error to the Cashier, records
the error, and enters a clean state.
2. Cashier starts a new sale.

3a. Invalid identifier:
1. System signals error and rejects entry.
3b. There are multiple of same item category and tracking unique item identity not
important (e.g., 5 packages of veggie-burgers):
1. Cashier can enter item category identifier and the quantity.
3-6a: Customer asks Cashier to remove an item from the purchase:
1. Cashier enters item identifier for removal from sale.
2. System displays updated running total.
3-6b. Customer tells Cashier to cancel sale:
1. Cashier cancels sale on System.
3-6c. Cashier suspends the sale:
1. System records sale so that it is available for retrieval on any POS
terminal.
4a.The system generated item price is not wanted (e.g., Customer complained
about something and is offered a lower price):
1. Cashier enters override price.
2. System presents new price

5a. System detects failure to communicate with external tax calculation system
service:
1. System restarts the service on the POS node, and continues.
1a. System detects that the service does not restart.
1. System signals error.
2. Cashier may manually calculate and enter the tax, or cancel
the sale.
5b. Customer says they are eligible for a discount (e.g., employee, preferred
customer):
1. Cashier signals discount request.
2. Cashier enters Customer identification.
3. System presents discount total, based on discount rules.
5c. Customer says they have credit in their account, to apply to the sale:
1. Cashier signals credit request.
2. Cashier enters Customer identification.
3. Systems applies credit up to price=0, and reduces remaining credit.

6a. Customer says they intended to pay by
cash but don’t have enough cash:
1a. Customer uses an alternate payment method.
1b. Customer tells Cashier to cancel sale. Cashier
cancels sale on system
7a. Paying by cash:
1. Cashier enters the cash amount tendered.
2. System presents the balance due, and releases the cash
drawer.
3. Cashier deposits cash tendered and returns balance in
cash to Customer.
4. System records the cash payment.

7b. Paying by credit:
1. Customer enters their credit account information.
2. System sends payment authorization request to an external Payment
Authorization Service System, and requests payment approval.
2a. System detects failure to collaborate with external system:
1. System signals error to Cashier.
2. Cashier asks Customer for alternate payment.
3. System receives payment approval and signals approval to Cashier.
3a. System receives payment denial:
1. System signals denial to Cashier.
2. Cashier asks Customer for alternate payment.
4. System records the credit payment, which includes the payment
approval.
5. System presents credit payment signature input mechanism.
6. Cashier asks Customer for a credit payment signature. Customer
enters signature.

7c. Paying by cheque...
7d. Paying by debit...
7e. Customer presents coupons:
1. Before handling payment, Cashier records each coupon and System
reduces price as appropriate. System records the used coupons for
accounting reasons.
1a. Coupon entered is not for any purchased item:
1. System signals error to Cashier.
9a.There are product rebates:
1. System presents the rebate forms and rebate receipts for each item
with a rebate.
9b. Customer requests gift receipt (no prices visible):
1.Cashier requests gift receipt and System presents it.

Special Requirements
• If a non-functional requirement, quality attribute, or
constraint relates specifically to a use case, record it
with the use case.
• These include qualities such as performance,
reliability, and usability, and design constraints (often
in I/O devices)
Special Requirements
• Touch screen Ul on a large flat panel monitor. Text
must be visible from 1 meter.
• Credit authorization response within 30 seconds
• Robust recovery when access to remote services such
the inventory system is failing.
• Language internationalization on the text displayed.
• Pluggable business rules to be insertable at steps 3
and 7.

Technology and Data Variations
List
• Technical constraint imposed by a stakeholder regarding input
or output technologies
• For example, a stakeholder might say, "The POS system must
support credit account input using a card reader and the
keyboard
Technology and Data Variations List
• Item identifier entered by bar code laser scanner (if bar code
is present) or keyboard.
• 3b. Item identifier may be any UPC (universal product code),
EAN (European Article Number), or SKU (stock keeping
unit)coding scheme.
• 7a. Credit account information entered by card reader or
keyboard.
• 7b. Credit payment signature captured on paper receipt. But
within two years, we predict many customers will want digital
signature capture.

Frequency of Occurrence: Could be nearly
continuous.
Open Issues:
• What are the tax law variations?
• Explore the remote service recovery issue.
• What customization is needed for different
businesses?
• Must a cashier take their cash drawer when they
log out?
• Can the customer directly use the card reader, or
does the cashier have to do it?

Two-Column Variation
9. Logs the completed sale and sends
information to the external accounting
(for all accounting and commissions)
and inventory systems (to
update inventory). System presents
receipt.

Goals and Scope of a Use Case
• How should use cases be discovered?
• Tasks can be grouped at many levels of granularity,
from one or a few small steps, up to enterprise-level
activities.
• At what level and scope should use cases be
expressed?
• What is a valid use case?
• Relevant Question: What is a useful level to
express use cases for application requirements
analysis
• Elementary business processes and goals as a
framework for identifying the use cases for an
application.

Guideline: The EBP Use Case
• For requirements analysis for a computer
application, focus on use cases at the level
of elementary business processes
(EBPs).
• EBP: A task performed by one person in
one place at one time, in response to a
business event, which adds measurable
business value and leaves the data in a
consistent state. e.g., Approve Credit
• A common use case mistake is defining
many use cases at too low a level

Reasonable Violations of the
EBP Guideline
• Although the "base" use cases for an application
should satisfy the EBP guideline, it is frequently
useful to create separate "sub" use cases
representing sub-tasks or steps within a base use
case
• The guideline is only used to find the dominant
level of use cases in requirements analysis for an
application
• paying by credit" may be repeated in several base
use cases.
– It is desirable to separate this into its own use case
– link it to several base use cases, to avoid duplication
of the text.

Finding Use Cases
1. Choose the system boundary
• For this case study, the POS system itself is the system under
design
• everything outside of it is outside the system boundary, including
the cashier, payment authorization service, and so on.
• If the definition of the boundary of the system under design is
not clear, it can be clarified by further definition of what is
outside the external primary and supporting actors.
• Once the external actors are identified, the boundary becomes
clearer
2. Identify the primary actors
3. Identify the goals for each primary actor
4. Define use cases that satisfy these goals

Questions to Find Actors and Goals
• Who starts and stops the system?
• Who does user and security management?
• Who does system administration?
• Is “time” an actor because the system does
something in response to a time event?
• How are software updates handled?
• Who gets notified of problems?

Actor-Goal List
Actor Goal
Cashier Process Sales
Process rentals
Handle returns
Cash in
Cash out
Manager Start up
Shut down
System administrator Add/Modify/Delete users
Manage security
Manage System tables
… …

Primary Actor and User Goals
Depend on System Boundary
• Why is the cashier, and not the customer, the primary
actor in the use case Process Sale? Why doesn’t the
customer appear in the actor-goal list?
Solution
• The answer depends on the system boundary of the
system under design.
• If viewing the enterprise or checkout service as an
aggregate system, the customer is a primary actor,
with the goal of getting goods or services and leaving.
• However, from the viewpoint of just the POS system it
services the goal of the cashier (and the store) to
process the customer’s sale.

Actors and Goals via Event
Analysis
• Another approach to aid in finding actors, goals,
and use cases is to identify external events
• What are they, where from, and why?
• Often, a group of events belong to the same EBP-
level goal or use case.

Define Use Cases
• Define one EBP-level use case for each user goal.
• Name the use case similar to the user goal.
• for example, Goal: process a sale; Use Case:
ProcessSale
• name use cases starting with a verb
• A common exception to one use case per goal is
to collapse CRUD (create,retrieve, update, delete)
separate goals into one CRUD use case,
idiomatically called Manage <X>.
– For example, the goals "edit user," "delete user," and
so forth are all satisfied by the Manage Users use
case.

Write Use Cases in an Essential Ill-
Free Style
• the cashier may say one of his goals is to "log in."
– The cashier was probably thinking of a GUI, dialog box, user
ID,and password.
– If the goal is "identification and authentication"
• make it easy and fast, using a biometric reader on the
keyboard?
Essential Style Writing
• keep the user interface out; focus on actor intent

Concrete Style.Avoid During
Early Requirements Work
concrete use case style
• user interface decisions are embedded in the use case text.
• The text may even show window screen shots, discuss
window navigation, GUI widget manipulation

Actors
• An actor is anything with behavior, including the system under discussion
(SuD) itself when it calls upon the services of other systems.
• Primary and supporting actors will appear in the action steps of the use
case text.
• Actors are not only roles played by people, but organizations, software, and
machines.
• There are three kinds of external actors in relation to the SuD:
Primary actor
• has user goals fulfilled through using services of the SuD.
• For example, the cashier.
Supporting actor
• provides a service (for example, information) to the SuD.
• The automated payment authorization service is an example.
Offstage actor.
• has an interest in the behavior of the use case, but is not primary or
supporting
• for example, a government tax agency.

Applying UML: Use Case Diagrams
• The UML provides use case diagram
notation to illustrate the names of use
cases and actors, and the relationships
between them

Actor
• Actor in a use case diagram is any
entity that performs a role in one
given system
Custom icons that convey the kind of
actor may also be used to denote an actor,
such as using a separate icon(s) for non-
human actors.
An actor may also be shown as
a class rectangle with the
keyword «actor», having usual notation for
class compartments, if needed.

Use Case
• A use case represents a function or an action within the
system. It’s drawn as an oval and named with the function.

System
• The system is used to define the scope of
the use case and drawn as a rectangle.
• This an optional element but useful when
you’re visualizing large systems.

How to Create a Use Case Diagram
• Identifying Actors
– It can be a person, another system or an
organization
– In a banking system, the most obvious actor is
the customer. Other actors can be bank
employee or cashier depending on the role
– external organization can be the tax authority or
the central bank
• Identifying Use Cases
– identify what the actors need from the system.
– In a banking system, a customer will need to
open accounts, deposit and withdraw funds,
request check books and similar functions.

• Look for Common Functionality to use
Include
– If you find two or more use cases that share
common functionality you can extract the
common functions and add it to a separate use
case.
– Then you can connect it via the include
relationship to show that it’s always called when
the original use case is executed.
• Is it Possible to Generalize Actors and Use
Cases
• Optional Functions or Additional Functions

RELATING USE CASES &
INCLUDE, EXTEND AND
GENERALIZATION
There can be 5 relationship types in a use
case diagram.
• Association between actor and use case
• Generalization of an actor
• Extend between two use cases
• Include between two use cases
• Generalization of a use case

Association Between Actor and
Use Case
• An actor must be associated with at least one use case.
• An actor can be associated with multiple use cases.
• Multiple actors can be associated with a single use case.

Generalization of an Actor
• Generalization of an actor means that one actor can inherit the role of an other
actor.
• The descendant inherits all the use cases of the ancestor.
• The descendant have one or more use cases that are specific to that role.
• Generalization between actors is rendered as a solid directed line with a large
arrowhead

Web Client actor is abstract superclass for
Administrator, Editor and Customer.

Generalization of a Use Case
• This is similar to the generalization of an actor.
• The behavior of the ancestor is inherited by the
descendant.
• This is used when there are common behavior
between two use cases and also specialized
behavior specific to each use case.
• For example in the previous banking example
there might be an use case called “Pay Bills”.
– This can be generalized to “Pay by Credit Card”,
“Pay by Bank Balance” etc.
• It is rendered as a solid directed line with a
large arrowhead, the same as
for generalization between classifiers

Extend Relationship Between Two
Use Cases
• As the name implies it extends the base use case
and adds more functionality to the system
• The extending use case is dependent on the
extended (base) use case.
• “Calculate Bonus” use case doesn’t make much
sense without the “Deposit Funds” use case.
• The extending use case is usually optional and
can be triggered conditionally.
• Extending use case is triggered only for deposits
over 10,000 or when the age is over 55.
• The extended (base) use case must be
meaningful on its own.
– This means it should be independent and must not
rely on the behavior of the extending use case

Extend relationship between use cases is shown by a dashed arrow with
an open arrowhead from the extending use case to the extended
(base) use case. The arrow is labeled with the keyword «extend».

Registration use case is complete and meaningful on its
own. It could be extended with optional Get Help On
Registration use case

Include Relationship Between Two
Use Cases
• Include relationship show that the behavior of the
included use case is part of the including (base)
use case.
• Reuse the common actions across multiple use
cases.
• Simplify complex behaviors.
• The base use case is incomplete without the
included use case.
• The included use case is mandatory and not
optional
• An include relationship between use cases is
shown by a dashed arrow with an open arrowhead
from the base use case to the included use case.
The arrow is labeled with the keyword «include».

When two or more use cases have some common behavior, this
common part could be extracted into a separate use case to be included
back by the use cases with the UML include relationship
Use case C is extracted
from use cases A and B to
be reused by both use
cases using UML include
relationship

Concrete, Abstract, Base, and
Addition Use
Cases
• A concrete use case
– It is initiated by an actor and performs the
entire behavior desired by the actor
– Process Sale
• An abstract use case
– It is never instantiated by itself; it is a subfunction use
case that is part of another use case.
– Handle Credit Payment is abstract; it doesn't stand on
its own, but is always part of another story, such as
Process Sale

• base use case
– use case that includes another use case, or
that is extended or specialized by another use
case is called a base use case
– Process Sale is a base use case with respect
to the included Handle Credit Payment
subfunction use case.
• addition use case
– use case that is an inclusion, extension, or
specialization is called an addition use case.
– Handle Credit Payment is the addition use case in the
include relationship to Process Sale.

Generalization Extend Include
Base use case could
be abstract use
case (incomplete) or
concrete (complete).
Base use case is complete
(concrete) by itself, defined
independently.
Base use case is
incomplete (abstract use
case).
Specialized use case
is required, not
optional, if base use
case is abstract.
Extending use case is
optional, supplementary.
Included use case required,
not optional.
No explicit condition
to use specialization.
Could have optional
extension condition.
No explicit inclusion
condition.

Registration use case with extension points
Registration Help and User Agreement

NEXTGEN POS

A simple diagram can add clarity

OOAD Analysis and Design Fundamentals

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to OOAD Analysis and Design Fundamentals

Similar to OOAD Analysis and Design Fundamentals (20)

More from GunasundariSelvaraj

More from GunasundariSelvaraj (6)

Recently uploaded

Recently uploaded (20)

OOAD Analysis and Design Fundamentals