CS8592-OOAD Lecture Notes Unit-1 R-17

1. 1
CS8592
OBJECT ORIENTED ANALYSIS AND DESIGN
UNIT I - UNIFIED PROCESS AND USE CASE DIAGRAMS
Introduction to OOAD with OO Basics - Unified Process - UML
diagrams - Use Case - Case study- the Next Gen POS system,
Inception - Use case Modelling - Relating Use cases - include,
extend and generalization - When to use Use-cases.

2. 2
Introduction to OOAD
⚫ Why OO?
⚫ What is OOAD?
⚫ How to do OOAD?

3. What is an Object?

4. What is an Object?

5. What is an Object?

6. What is an Object?

7. 7
Why Object-Oriented?

8. 8
What is Object?
⚫ An "object" is anything to which a concept applies, in our awareness
⚫ Things drawn from the problem domain or solution space.
⚫ E.g., a living person in the problem domain, a software component in the solution space.
⚫ A structure that has identity and properties and behavior
⚫ It is an instance of a collective concept, i.e., a class.

9. 9
Encapsulation
Information hiding
Objects encapsulate:
property
behavior as a collection of methods invoked by
messages
…state as a collection of instance variables
Abstraction
Focus on the essential
Omits tremendous amount of details
…Focus on what an object “is and does”
What is Object-Orientation?
- Abstraction and Encapsulation

10. 10
What is Object-Orientation?
- Another Example of Abstraction and Encapsulation
Class Car
Attributes
❑ Model
❑ Location
❑ #Wheels = 4
Operations
❑ Start
❑ Accelerate
<<instanceOf>>
<<instanceOf>>
<<instanceOf>>

11. 11
What is Object-Orientation?
- Class
⚫ What is CLASS?
⚫ a collection of objects that share common properties, attributes, behavior and
semantics, in general.
⚫ A collection of objects with the same data structure (attributes, state variables)
and behavior (function/code/operations) in the solution space.
⚫ Classification
⚫ Grouping of common objects into a class
⚫ Instantiation.
⚫ The act of creating an instance.
Class Car
Attributes
❑ Model
❑ Location
❑ #Wheels = 4
Operations
❑ Start
❑ Accelerate
<<instanceOf>>
<<instanceOf>>
<<instanceOf>>

12. 12
What is Object-Orientation?
- Subclass vs. Superclass
• Specialization: The act of defining one class as a refinement of another.
• Subclass: A class defined in terms of a specialization of a superclass
using inheritance.
• Superclass: A class serving as a base for inheritance in a class hierarchy
• Inheritance: Automatic duplication of superclass attribute and behavior
definitions in subclass.
Person
name
SSN
Student
std-id
level
Employee
emp-id
age

13. 13
What is Object-Orientation?
- Polymorphism
Objects of different classes respond to the same message differently.
payTuition
Person
name
SSN
Student
std-id
level
Employee
emp-id
In-State
Student
state
payTuition payTuition
Out-of-State
Student
payTuition

14. 14
What is Object-Orientation?
- Interfaces
• Information hiding - all data should be hidden within a class, at least in principle.
• make all data attributes private
• provide public methods to get and set the data values (cf. Java design patterns)
• e.g. Grade information is usually confidential, hence it should be kept
private to the student. Access to the grade information should be
done through interfaces, such as setGrade and getGrade
payTuition
setGrade()
getGrade()
Student
std-id
level
getGrade
setGrade
grade

15. 15
What is Object-Orientation?
-State transition impossible?
tom: Actor
name = “Tom Cruise”
katie: Actor
name = “Katie Holmes”
tom: Actor
name = “Tom Holmes”
katie: Actor
name = “Katie Holmes”
married/changeLastName
tom: Actor
name = “Tom Holmes”
katie: Actor
name = “Katie Holmes”
suri: BabyActor
name = “Suri Holmes”
newArrival/getName

16. OOA to OOD

17. 17
What is OOAD?
⚫ Analysis — understanding, finding and describing concepts in
the problem domain.
⚫ Design — understanding and defining software solution/objects
that represent the analysis concepts and will eventually be
implemented in code.
⚫ OOAD — Analysis is object-oriented and design is object-
oriented. A software development approach that emphasizes a
logical solution based on objects.

18. 18
Systems Engineering
Requirements Analysis
Project Planning
Architectural Design
Detailed Design
Implementation
Release
Maintenance
Quality
Assurance
Software Lifecycle
How to Do OOAD
– Where to Use OO?

19. 19
Introduction to OOAD
OO Prog. Languages
(Smalltalk, C++)
just program!
OO Design
(Booch) design then
program
OO Analysis
(Rumbaugh, Jacobson)
Process Perspective
OO Technology
Analyze (use case) first,
then design,
T then program

20. 20
Knowledge
Representation (in A.I.)
Psychological Validity
Philosophical Validity
Computational Validity
Databases
Emphasis in Persistent Data
(and now ACID properties)
RelationalDB
Network DB
Hierarchical DB
OODB
Programming Languages
Emphasis in Efficiency
Simula, SmallTalk, C++, Protel,
Java
ERD
SDM
CM
ADT
ERD: Entity Relationship Diagram
SDM: Semantic Data Model
ADT: Abstract Data Type
CM: Conceptual Model
Why Object-Oriented
- Who’s Behind Object-Orientation
System/Software
Engineering

21. Unified Process
⚫ It emphasizes the difference between
engineering and production.
⚫ The Unified Process is not simply a
process, but rather an extensible
framework which should be
customized for specific organizations
or projects.

22. Difference: Engineering vs. Production
⚫ Engineering Stage
⚫ Driven by less predictable but smaller teams, focusing
on design and synthesis activities
⚫ Production Stage
⚫ Driven by more predictable but larger teams, focusing
on construction, test and deployment activities

23. Phases in the Unified Process
⚫ The two stages of the Unified Process
are decomposed into four distinct phases
⚫ Engineering stage
1. Inception phase
2. Elaboration phase
⚫ Production phase
3. Construction phase
4. Transition phase

24. Elaboration
Inception
Construction
Phases in the Unified Process
Transition
Transition from
engineering stage to
production stage.

25. Inception Phase
⚫ Investigation
⚫ Establish the project scope
⚫ Identify the critical use cases and
scenarios
⚫ Define acceptance criteria
⚫ Demonstrate at least one candidate
software architecture
⚫ Estimate the cost and schedule for the
project
⚫ Define and estimate potential risks

26. Elaboration Phase
⚫ Baseline the software architecture
⚫ Establish a configuration management plan
in which all changes are tracked and
maintained
⚫ Baseline the problem statement
⚫ Baseline the software project
management plan for the construction
phase
⚫ Demonstrate that the architecture
supports the requirements at a
reasonable cost in a reasonable time

27. Construction Phase
⚫ Minimize development costs by
optimizing resources
⚫ Achieve adequate quality as rapidly as
practical
⚫ Achieve useful version (alpha, beta, and
other test releases) as soon as possible

28. Transition Phase
⚫ The transition phase is entered when a
baseline is mature
⚫ A usable subset of the system has been built with
acceptable quality levels and user documents
⚫ It can be deployed to the user community
⚫ For some projects the transition phase means
the starting point for another version of the
software system
⚫ For other projects the transition phase means
the complete delivery of the software system to
a third party responsible for operation,
maintenance and enhancement.

29. Profile of a typical project showing the
relative sizes of the four phases of the
Unified Process.
Relative sizes of the four phases

30. Diagram illustrating how the relative emphasis of different
disciplines changes over the course of the project
Relative emphasis of different disciplines changes

31. What is UML?
⚫ UUML - Unified Modeling language
⚫ UML is a modeling language, not a methodology or process
⚫ Developed by Grady Booch, James Rumbaugh and Ivar
Jacobson at Rational Software.
The Unified Modelling Language (UML) is a language for
specifying, visualizing, constructing, and documenting the
artefacts of software systems, as well as for business
modelling and other non-software systems.

32. UML Models
Use Case
Diagrams
Collaboration
Diagrams
Component
Diagrams
Deployment
Diagrams
Object
Diagrams
Statechart
Diagrams
Sequence
Diagrams
Class
Diagrams
Activity
Diagrams
Models
Object
Diagrams
Object
Diagrams
Static
model
Dynamic

33. Structural
: element of spec. irrespective of time
• Class
• Component
• Deployment
• Object
• Composite structure
• Package
Behavioral
: behavioral features of a system / business
process
• Activity
• State machine
• Use case
Interaction
: emphasize object interaction
• Communication(collaber
ation)
• Sequence
• Interaction overview
• Timing
UML Diagrams

34. 34
Use cases diagram
⚫ Capture the specific ways of using the
system as dialogues between an actor
and the system.
⚫ Use cases are used to
⚫ Capture system requirements
⚫ Communicate with end users and Subject
Matter Experts
⚫ Test the system
Use cases diagrams describes the behavior of the target
system from an external point of view. Use cases
describe "the meat" of the actual requirements.

35. 35
Naming Use Cases
⚫ Must be a complete process from the
viewpoint of the end user
⚫ Usually in verb-object form, like Buy
Pizza
⚫ Use enough detail to make it specific
⚫ Use active voice, not passive
⚫ From viewpoint of the actor, not the
system

36. 36
Use Case Name Examples
⚫ Excellent - Purchase Concert Ticket
⚫ Very Good - Purchase Concert Tickets
⚫ Good - Purchase Ticket (insufficient detail)
⚫ Fair - Ticket Purchase (passive)
⚫ Poor - Ticket Order (system view, not user)
⚫ Unacceptable - Pay for Ticket (procedure,
not process)

37. 37
CRUD
⚫ Examples of bad use case names with
the acronym CRUD. (All are procedural
and reveal nothing about the actor’s
intentions.)
⚫ C - actor Creates data
⚫ R - actor Retrieves data
⚫ U - actor Updates data
⚫ D - actor Deletes data

38. 38
Actor
⚫ An actor is an idealized
user of a system
⚫ Actors can be users,
processes, and other
systems
⚫ Many users can be one
actor, in a common role
⚫ One user can be different
actors, based on different
roles
⚫ An actor is labeled with
the name of the role

39. 39
Identify Actors
⚫ We cannot understand a system until we
know who will use it
⚫ Direct users
⚫ Users responsible to operate and maintain it
⚫ External systems used by the system
⚫ External systems that interact with the
system

40. 40
Non-human Actor
⚫ Actors can be users,
processes, and other
systems.
⚫ Show non human actors
in a different manner,
usually as a rectangle
⚫ Non human actors are
usually not primary users,
and thus are usually
shown on the right, not
the left.
Inventory
System

41. 41
Types of Actors
⚫ Primary Actor
⚫ Has goals to be fulfilled by system
⚫ Supporting Actor
⚫ Provides service to the system
⚫ Offstage Actor
⚫ Interested in the behavior, but no
contribution
⚫ In diagrams, Primary actors go on the left and
others on the right.

42. 42
Define Actors
⚫ Actors should not be analyzed or described in
detail unless the application domain demands
it.
⚫ Template for definition:
⚫ Name
⚫ Definition
⚫ Example for an ATM application:
Customer: Owner of an account who manages
account by depositing and withdrawing funds

43. 43
Overview
⚫ A use case
diagram
identifies
transactions
between
actors and a
system as
individual use
cases

44. 44
Use Case
⚫ A use case is a coherent unit
of externally visible
functionality provided by a
system and expressed by a
sequence of messages
⚫ Additional behavior can be
shown with parent-child,
extend and include use
cases
⚫ It is labeled with a name that
the user can understand

45. 45
System
⚫ A system is shown as a
rectangle, labeled with
the system name
⚫ Actors are outside the
system
⚫ Use cases are inside the
system
⚫ The rectangle shows the
scope or boundary of the
system

46. 46
Association Relationship
⚫ An association is the
communication path between
an actor and the use case that
it participates in
⚫ It is shown as a solid line
⚫ It does not have an arrow, and
is normally read from left to
right
⚫ Here, the association is
between a Modeler and the
Create Model use case

47. 47
Relationships in Use Cases
There are several Use Case relationships:
⚫ Association
⚫ Extend
⚫ Generalization
⚫ Uses
⚫ Include
Most Use Cases have only associations.
Use other relationships sparingly.

48. 48
Extend Relationship
⚫ Extend puts additional
behavior in a use case
that does not know
about it.
⚫ It is shown as a dotted
line with an arrow point
and labeled <<extend>>
⚫ In this case, a customer
can request a catalog
when placing an order

49. 49
Use Case Generalization
⚫ Generalization is a
relationship between a
general use case and a
more specific use case
that inherits and extends
features to it
⚫ It is shown as a solid line
with a closed arrow point
⚫ Here, the payment
process is modified for
cash and charge cards

50. 50
Uses Relationship
⚫ When a use case uses
another process, the
relationship can be
shown with the uses
relationship
⚫ This is shown as a solid
line with a closed arrow
point and the <<uses>>
keyword
⚫ Here different system
processes can use the
logon use case

51. 51
Include Relationship
⚫ Include relationships
insert additional behavior
into a base use case
⚫ They are shown as a
dotted line with an open
arrow and the key word
<<include>>
⚫ Shown is a process that
I observed in an earlier
career

52. 52
Use Case Example: Alarm Clock
This is a contrived
example, to show
many relations.
Your diagrams
should be simpler.

53. Class Diagrams
⚫ A Class is a Description of Set of Objects
that Share the Same Attributes,
Operations, Methods, Relationships, and
Semantics
⚫ Classes are Graphically Represented as
Boxes with Compartments for
⚫ Class Name, Private Attributes, and
Public Operations

54. Class Diagram (Rumbaugh/Booch)
⚫ Class Diagram Describes
– Types of Objects in Application
– Static Relationships Among Objects
– Temporal Information Not Supported
⚫ Class Diagrams Contain
– Classes: Objects, Attributes, and Operations
– Packages: Groupings of Classes
– Subsystems: Grouping of Classes/Packages
⚫ Main Concepts: Class, Association,
Generalization, Dependency, Realization,
Interface

55. Classes
A class represent a concept
A class encapsulates state (attributes) and
behavior (operations).
Each attribute has a type.
Each operation has a signature.
The class name is the only mandatory information.
zone2price
getZones()
getPrice()
TariffSchedule
Table zone2price
Enumeration getZones()
Price getPrice(Zone)
TariffSchedule
Name
Attributes
Operations
Signature
TariffSchedule

56. UML Class Notation
A class is a rectangle divided into three parts
– Class name
– Class attributes (i.e. data members, variables)
– Class operations (i.e. methods)
Modifiers
– Private: -
– Public: +
– Protected: #
– Static: Underlined (i.e. shared among all members of the class)
Abstract class: Name in italics
+getName() : string
+setName()
-calcInternalStuff(in x : byte, in y : decimal)
-Name : string
+ID : long
#Salary : double
Employee
• An abstract class has one or more
abstract/pure virtual functions.
• An abstract class cannot be used to instantiate
objects.
• An abstract class can contain data members.

57. UML Class Notation
Lines or arrows between classes indicate relationships
– Association
• A relationship between instances of two classes, where one class
must know about the other to do its work, e.g. client communicates to
server
• indicated by a straight line or arrow
– Aggregation
• An association where one class belongs to a collection, e.g. instructor
part of Faculty
• Indicated by an empty diamond on the side of the collection
– Composition
• Strong form of Aggregation
• Lifetime control; components cannot exist without the aggregate
• Indicated by a solid diamond on the side of the collection
– Inheritance
• An inheritance link indicating one class a superclass relationship, e.g.
bird is part of mammal
• Indicated by triangle pointing to superclass

58. Binary Association
myB.service(); myA.doSomething();
Binary Association: Both entities “Know About” each other
Optionally, may create an Associate Class

59. Unary Association
A knows about B, but B knows nothing about A
Arrow points in direction
of the dependency
myB.service();

60. Aggregation
Aggregation is an association with a “collection-member” relationship
void doSomething()
aModule.service();
Hollow diamond on
the Collection side

61. Composition
+getName() : string
+setName()
-calcInternalStuff(in x : byte, in y : decimal)
-Name : string
+ID : long
#Salary : double
-adfaf : bool
Employee
-members : Employee
Team
1
*
Composition is Aggregation with:
Lifetime Control (owner controls construction, destruction)
Part object may belong to only one whole object
Filled diamond on
side of the Collection
members[0] =
new Employee();
…
delete members[0];

62. Inheritance
Standard concept of inheritance
class B() extends A
…
Base Class
Derived Class

63. Generalization and Associations
Item
NonPItem PerishItem
DeliItem ProduceItem
DiaryItem
Customer
GroceryOrder
1
*
DeliOrder
1
*
contains
Supermarket example

64. UML Multiplicities
Multiplicities Meaning
0..1
zero or one instance. The notation n . . M
indicates n to m instances.
0..* or *
no limit on the number of instances
(including none).
1 exactly one instance
1..* at least one instance
Links on associations to specify more details about the relationship

65. UML Class Example

66. Supermarket Example in Detail

67. Interaction Diagrams
⚫ Sequence Diagram
⚫ Communication Diagram (Collaboration Diagram)

68. Sequence Diagram
⚫ Sequence Diagram: For a Task, Indicates
the Object Interactions Over Time that are
Needed
⚫ Captures Dynamic Behavior (Time-
oriented)
⚫ Purposes:
⚫ Model Flow Of Control
⚫ Illustrate Typical Scenarios
⚫ Provide Perspective on Usage an Flow
⚫ Main Concepts: Interaction, Object,
Message, Activation

69. Sequence Diagram
Captures Dynamic Behavior (Time-Oriented)

70. Sequence Diagram

71. Sequence Diagram : Supermarket Example

72. Collaboration Diagram
⚫ Collaboration Diagram: Structured from the
Perspective of Interactions Among Objects
⚫ Captures Dynamic Behavior (Message-
oriented)
⚫ Purposes:
⚫ Model Flow of Control
⚫ Illustrate Coordination of Object Structure
and Control
⚫ Objects that Interact with Other Objects

73. Collaboration Diagram
Captures Dynamic Behavior (Message-
Oriented)

74. Collaboration Diagram

75. State chart Diagrams
initial State
state
transition
event
A State chart diagram shows the lifecycle of an object
• A state is a condition of an object for a particular time
• An event causes a transition from one state to another state
Here is a State chart for a Phone Line object:

76. State charts in UML: States in ovals, Transitions as arrows
Transitions labels have three
optional parts:
Event [Guard] / Action
– Find one of each
– Item Received is an event,
/get first item is an action,
[Not all items checked] is a
guard
State may also label activities,
e.g., do/check item
– Actions, associated with
transitions, occur quickly
and aren’t interruptible
– Activities, associated with
states, can take longer and
are interruptible
– Definition of “quickly” depends
on the kind of system,
e.g., real-time vs. info system

77. When to develop a state chart?
• Devices (microwave oven, Ipod)
• Complex user interfaces (e.g., menus)
• Transactions (databases, banks, etc.)
• Stateful sessions (server-side objects)
• Controllers for other objects, Etc.

78. Superstates (nested states)
Example shows a
super-state of three
states
Can draw a single
transition to and
from a super-state
How does this
notation make
things a bit
clearer?

79. Concurrency in state diagrams
– Dashed line indicates that an order is in two
different states, e.g. Checking & Authorizing
– When order leaves concurrent states, it’s in a
single state: Canceled, Delivered or Rejected

80. State Diagram

81. 81
Activity Diagram
⚫ Two definitions
– an activity is some task that needs to be done,
whether by a human or a computer
– an activity is a method on a class
⚫ Activity arrangement
– Sequential – one activity is followed by
another
– Parallel – two or more sets of activities are
performed concurrently, and order is irrelevant
• Interleaving is permitted – we can jump
between the parallel flows

82. 82
What is an Activity?
⚫ Activity Diagrams are used to describe activities
– Activity Diagrams are useful for describing
complicated methods
– Activity Diagrams are useful for describing use
cases & since.
⚫ Activity Diagrams are like Flow Charts, but Flow
Charts are usually limited to sequential activities while
Activity Diagrams can show parallel activities as well

83. 83
Activity Diagrams - Notation
⚫Start at the top black circle
⚫If condition 1 is TRUE, go right;
if condition 2 is TRUE, go down
⚫At first bar (a synchronization
bar), break apart to follow 2
parallel paths
⚫At second bar, come together to
proceed only when both parallel
activities are done
Notation

84. 84
Activity Diagrams – Example 1
Use Case: Receiving an Order

85. 85
Activity Diagram – Example 2
Use Case: Receiving a Supply

86. 86
Activity Diagram – Example 3
Use Case: Receiving an Order
and Receiving a Supply

87. UML Deployment Diagram
Deployment diagrams are used to visualize the
topology of the physical components of a system
where the software components are deployed.
Deployment diagrams consist of nodes and their
relationships.
Component diagrams and deployment diagrams
are closely related.
Component diagrams are used to describe the
components and deployment diagrams shows how
they are deployed in hardware.

88. Purpose of Deployment Diagrams
⚫ Visualize hardware topology of a system.
⚫ Describe the hardware components used
to deploy software components.
⚫ Describe runtime processing nodes.

89. Where to use Deployment Diagrams?
⚫ Deployment diagrams are mainly used by
system engineers.
⚫ These diagrams are used to describe the
physical components (hardwares), their
distribution and association.

90. Usage of deployment diagrams
⚫ To model the hardware topology of a system.
⚫ To model embedded system.
⚫ To model hardware details for a client/server
system.
⚫ To model hardware details of a distributed
application.
⚫ Forward and reverse engineering.

91. Deployment diagram for Order Management system

92. Communication Path
Communication path is an association
between two deployment targets.
Communication path between several application
servers and database server

93. Deployment Specification
A deployment specification can be aimed at a
specific type of container for a components.
The ejb-jar.xml deployment
specification

94. Deployment Specification Dependency
A deployment specification could be displayed as a
classifier rectangle attached to a component
artifact using a regular dependency arrow pointing
to deployed artifact.
ejb-jar.xml deployment specification for user-
service.ejb artifact

95. Deployment Specification Association

96. Deployment Diagram Example

97. UML Package Diagrams
UML Package Diagrams:
– Used to illustrate the logical architecture of
a system
• Layers, subsystems, Java packages
– Provides a way to group elements
• Different from (more general than) a Java
package
• Can group anything
– Classes, other packages, diagrams, use cases, …
• Nesting packages is very common

98. 98
Package Diagrams
Package – contains classes
Dependency – changes to the
definition (interface) of one
package may cause changes in
the other package

99. 99
Package Diagrams – Example

100. 100
Package Diagrams – Example
Domain Package – a collection of
related packages

101. UML Component Diagram
⚫Component diagrams can also be described as a static
implementation view of a system.
⚫Static implementation represents the organization of the
components at a particular moment.
⚫Component diagrams are used to model physical
aspects of a system.
⚫Used to visualize the organization and relationships
among components in a system.
⚫These diagrams are also used to make executable
systems.

102. Purpose of the component diagram
⚫ Visualize the components of a system.
⚫ Construct executables by using forward and
reverse engineering.
⚫ Describe the organization and relationships of
the components.

103. How to draw Component Diagram?
Before drawing a component diagram the following artifacts
are to be identified clearly:
– Files used in the system.
– Libraries and other artifacts relevant to the application.
– Relationships among the artifacts.
After identifying the artifacts the following points needs to be
followed:
– Use a meaningful name to identify the component for which the
diagram is to be drawn.
– Prepare a mental layout before producing using tools.
– Use notes for clarifying important points.

104. Where to use Component Diagrams?
⚫ Model the components of a system.
⚫ Model database schema.
⚫ Model executables of an application.
⚫ Model system's source code.

105. Basic Component Diagram Symbols and Notations
Component
Interface
Dependencies

106. Example

107. The Case Study
⚫ The text uses the development of a
Point of Sale (POS) System as a case
study to demonstrate object oriented
software development.
⚫ A POS system is a replacement for a
cash register that adds many
computer services to the traditional
cash register. Most retail stores now
use POS systems.

108. Architectural Layers
⚫ User Interface
⚫ Application Logic and Domain Objects
⚫ Sale and Payment
⚫ Technical Services
⚫ Log and Persistence

109. Case Study : POS System
⚫ A computerized NextGen point-of-sale (POS) system is to:
⚫ record sales, and
⚫ handle payments.
⚫ It includes H/S components such as:
⚫ Computer
⚫ Bar code scanner
⚫ Software
⚫ It interfaces to various service applications, such as:
⚫ Third party tax calculators
⚫ Inventory control
⚫ It must support multiple and varied client-side terminals and interfaces, such as:
⚫ A thin Web browser terminal
⚫ A regular PC with Java Swing graphical UI
⚫ Touch screen input
⚫ Wireless PDA’s
⚫ It should support different clients with different business rules.

110. Inception
⚫ Purpose is to decide whether to
proceed with development, not to
define requirements.
⚫ Only key requirements are investigated.

111. Inception
⚫ Determine the product scope,
vision, and business case.

112. Questions during inception
⚫ What is the vision for this project?
⚫ What is the business case?
⚫ Is the project feasible?
⚫ Should we buy or build?
⚫ Rough estimate of cost?
⚫ At end of inception: Go or No Go?

113. Problem statement
⚫ Do the stakeholders have basic
agreement on the vision of the project,
and is it worth investing in serious
investigation?

114. Vision and Business Case
⚫ Describes the high level goals and
constraints, the business case, and
provides an executive summary.
⚫ Usually has an estimate of costs (+/-
100%) and expected benefits stated in
financial terms.

115. Use Case Model
⚫ Describes the functional requirements
and related non-functional
requirements.
⚫ Preliminary only, usually the names of
most of the expected use cases and
actors, but usually only about 10% of
the use cases are detailed.
⚫ Do not confuse a use case diagram
with a use case. It is mostly text.

116. Use Cases and Actors
⚫ You should have identified most of the
use cases and actors during inception.
⚫ Do not detail all of the use cases. Only
document the most important ones.
About 10 or 20% of the use cases
should be detailed enough to estimate
the scope of the total project.

117. Use Case Relationships
Domain Model
Use Case Model
Interaction Diagrams
Design
Requirements
Business Model
Objects, attributes, associations
VISION
GLOSSARY
SUPPLEMENTARY
SPECIFICATION

118. Use Cases are not Diagrams
⚫ Use Cases may have a diagram associated
with them, and a use case diagram is an
easy way for an analyst to discuss a
process with a subject matter expert (SME).
⚫ But use cases are primarily text. The text is
important. The diagram is optional.

119. Why Use Cases?
⚫ Simple and familiar story-telling makes
it easier, especially for customers, to
contribute and review goals.
⚫ Use cases keep it simple
⚫ They emphasize goals and the user
perspective.
⚫ New use case writers tend to take them
too seriously.

120. Actors or Use Case First?
⚫ The text describes use cases substantially
before paying attention to actors.
⚫ Typically, both actors and use cases are
identified early and then examined to see if
more use cases can be found from the actors,
or more actors found by examining the use
cases.

121. How Use Cases look like?
⚫ Capture the specific ways of using the
system as dialogues between an actor
and the system.
⚫ Use cases are used to
⚫ Capture system requirements
⚫ Communicate with end users and Subject
Matter Experts
⚫ Test the system

122. USE CASE : Process Sale
(FULLY DRESSED VERSION)
⚫ Primary Actor: Cashier
⚫ Stakeholders and Interests:
Cashier: Wants accurate and fast entry, no
payment errors, …
Salesperson: Wants sales commissions
updated. …
⚫ Preconditions: Cashier is identified and authenticated.
⚫ Success Guarantee (Post conditions):
Sale is saved. Tax correctly calculated.…
⚫ Main success scenario (or basic flow)
⚫ Extensions (or alternative flows)
⚫ Special requirements: Touch screen UI, …

123. Use case (contd…)
⚫ Technology and Data Variations List:
Identifier entered by bar code scanner,…
⚫ Open issues: What are the tax law variations? …
⚫ Main success scenario (or basic flow):
The Customer arrives at a POS checkout with
items to purchase.
The cashier records the identifier for each item. If
there is more than one of the same item, the
Cashier can enter the quantity as well.
The system determines the item price and adds
the item information to the running sales
transaction. The description and the price of the
current item are presented.

124. Use case (contd…)
On completion of item entry, the Cashier
indicates to the POS system that item entry
is complete.
The System calculates and presents the sale
total.
The Cashier tells the customer the total. The
Customer gives a cash payment (“cash
tendered”) possibly greater than the sale
total.
⚫ Extensions (or alternative flows):
If invalid identifier entered. Indicate error.
If customer didn’t have enough cash, cancel

125. Things that are in Use Cases
⚫ Create a written document for each Use Case
⚫ Clearly define intent of the Use Case
⚫ Define Main Success Scenario (Happy
Path)
⚫ Define any alternate action paths
⚫ Use format of Stimulus: Response
⚫ Each specification must be testable
⚫ Write from actor’s perspective, in actor’s
vocabulary

126. Use cases Template
⚫ Name
⚫ Primary Actor
⚫ Scope
⚫ Level
⚫ Stakeholders and Interests
⚫ Minimal Guarantee
⚫ Success Guarantee
⚫ Main Success Scenario
⚫ Extensions

127. Naming Use Cases
⚫ Must be a complete process from the
viewpoint of the end user.
⚫ Usually in verb-object form, like Buy
Pizza
⚫ Use enough detail to make it specific
⚫ Use active voice, not passive
⚫ From viewpoint of the actor, not the
system

128. Golden Rule of Use-Case Names
⚫ Each use case should have a name that
indicates what value (or goal) is achieved
by the actor's interaction with the system
⚫ Here are some good questions to help
you adhere to this rule:
⚫ Why would the actor initiate this interaction with
the system?
⚫ What goal does the actor have in mind when
undertaking these actions?
⚫ What value is achieved and for which actor?

129. Use Case Name Examples
⚫ Excellent - Purchase Concert Ticket
⚫ Very Good - Purchase Concert Tickets
⚫ Good - Purchase Ticket (insufficient detail)
⚫ Fair - Ticket Purchase (passive)
⚫ Poor - Ticket Order (system view, not user)
⚫ Unacceptable - Pay for Ticket (procedure,
not process)

130. CRUD
Examples of bad use case names with the
acronym CRUD. (All are procedural and
reveal nothing about the actor’s intentions.)
⚫ C - actor Creates data
⚫ R - actor Retrieves data
⚫ U - actor Updates data
⚫ D - actor Deletes data

131. Identify Actors
⚫ We cannot understand a system until we
know who will use it
⚫ Direct users
⚫ Users responsible to operate and maintain it
⚫ External systems used by the system
⚫ External systems that interact with the
system

132. Types of Actors
⚫ Primary Actor
⚫ Has goals to be fulfilled by system
⚫ Supporting Actor
⚫ Provides service to the system
⚫ Offstage Actor
⚫ Interested in the behavior, but no
contribution
In diagrams, Primary actors go on the
left and others on the right.

133. Define Actors
⚫ Actors should not be analyzed or
described in detail unless the application
domain demands it.
⚫ Template for definition:
⚫ Name
⚫ Definition
⚫ Example for an ATM application:
Customer: Owner of an account who
manages account by depositing and
withdrawing funds

134. Working with Use Cases
⚫ Determine the actors that will interact with the
system
⚫ Examine the actors and document their
needs
⚫ For each separate need, create a use case
⚫ During Analysis, extend use cases with
interaction diagrams

135. Preconditions
⚫ Anything that must always be true before
beginning a scenario is a precondition.
⚫ Preconditions are assumed to be true, not
tested within the Use Case itself.
⚫ Ignore obvious preconditions such as the
power being turned on. Only document items
necessary to understand the Use Case.

136. Success Guarantees
⚫ Success Guarantees (or Post conditions)
state what must be true if the Use Case is
completed successfully. This may include
the main success scenario and some
alternative paths.
⚫ Example, if the happy path is a cash sale, a
credit sale might also be regarded a
success.
⚫ Stakeholders should agree on the
guarantee.

137. Scenarios
⚫ The Main Success Scenario, or “happy
path” is the expected primary use of the
system, without problems or exceptions.
⚫ Alternative Scenarios or Extensions are
used to document other common paths
through the system and error handling or
exceptions.

138. Documenting the Happy Path
⚫ The Success Scenario (or basic course) gives the best
understanding of the use case
⚫ Each step contains the activities and inputs of the actor and the
system response
⚫ If there are three or more items, create a list
⚫ Label steps for configuration management and requirements
traceability
⚫ Use present tense and active voice
⚫ Remember that User Interface designers will use this
specification
Note: Do not use the term “happy path” in formal documents.

139. Documenting Extensions
⚫ Use same format as Happy Path
⚫ Document actions that vary from ideal path
⚫ Include error conditions
⚫ Number each alternate, and start with the condition:
Condition: If [actor] performs [action] the system …
⚫ If subsequent steps are the same as the happy
path, identify and label as (same)
⚫ Steps not included in alternate course are assumed
not to be performed.

140. Two Parts for Extensions
⚫ Condition
⚫ Describe the reason for the alternative flow
as a condition that the user can detect
⚫ Handling
⚫ Describe the flow of processing in the
same manner as the happy path, using a
numbering system consistent with the
original section.

141. Types of Use Cases
⚫ High Level Use Case (Brief)
⚫ Name, Actors, Purpose, Overview
⚫ Expanded Use Case (Fully Dressed)
⚫ Add System Events and System
Responses
⚫ Essential Use Case (Black Box)
⚫ Leave out technological implications
⚫ Real Use Case (White Box)
⚫ Leave in technology

142. Overview
⚫ A use case
diagram
identifies
transactions
between
actors and a
system as
individual use
cases

143. Actor
⚫ An actor is an idealized user
of a system
⚫ Actors can be users,
processes, and other
systems
⚫ Many users can be one
actor, in a common role
⚫ One user can be different
actors, based on different
roles
⚫ An actor is labeled with the
name of the role

144. Non-human Actor
⚫ Actors can be users,
processes, and other
systems.
⚫ Show non human actors
in a different manner,
usually as a rectangle
⚫ Non human actors are
usually not primary users,
and thus are usually
shown on the right, not
the left.
Inventory
System

145. Use Case
⚫ A use case is a coherent unit
of externally visible
functionality provided by a
system and expressed by a
sequence of messages
⚫ Additional behavior can be
shown with parent-child,
extend and include use
cases
⚫ It is labeled with a name that
the user can understand

146. System
⚫ A system is shown as a
rectangle, labeled with
the system name
⚫ Actors are outside the
system
⚫ Use cases are inside the
system
⚫ The rectangle shows the
scope or boundary of the
system

147. Association Relationship
⚫ An association is the
communication path between
an actor and the use case that
it participates in
⚫ It is shown as a solid line
⚫ It does not have an arrow, and
is normally read from left to
right
⚫ Here, the association is
between a Modeler and the
Create Model use case

148. Relationships in Use Cases
⚫ There are several Use Case relationships:
⚫ Association
⚫ Extend
⚫ Generalization
⚫ Uses
⚫ Include
Most Use Cases have only
associations. Use other
relationships sparingly.

149. Extend Relationship
⚫ Extend puts additional
behavior in a use case that
does not know about it.
⚫ It is shown as a dotted line
with an arrow point and
labeled <<extend>>
⚫ In this case, a customer can
request a catalog when
placing an order

150. Use Case Generalization
⚫ Generalization is a
relationship between a
general use case and a
more specific use case
that inherits and extends
features to it
⚫ It is shown as a solid line
with a closed arrow point
⚫ Here, the payment
process is modified for
cash and charge cards

151. Uses Relationship
⚫ When a use case uses
another process, the
relationship can be
shown with the uses
relationship
⚫ This is shown as a solid
line with a closed arrow
point and the <<uses>>
keyword
⚫ Here different system
processes can use the
logon use case

152. Include Relationship
⚫ Include relationships
insert additional behavior
into a base use case
⚫ They are shown as a
dotted line with an open
arrow and the key word
<<include>>
⚫ Shown is a process that
I observed in an earlier
career

153. Use Case Example: Alarm Clock
This is a contrived
example, to show
many relations.
Your diagrams
should be simpler.

154. Ref: Text Book-1
Craig Larman, Applying UML and Patterns: An Introduction to Object Oriented Analysis and
Design and Iterative Development, Third Edition, Pearson Education, 2005.