Analysis Modeling:
Object - Oriented Analysis
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 1
Object-oriented analysis
• Over 60 different techniques exist for OOA
• Unified Modeling Language (UML)
• Object modeling language invented by Booch,
Rumbaugh, and Jacobson
• Adopted as a standard by the Object Management Group
in 1997 http://www.uml.org/
• Tools that support UML
o IBM Rational Software Architect and Modeler
o Umbrello UML Modeller
• Useful tutorials
o Umbrello UML Modeller Handbook
o Borland’s UML Tutorial
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 2
Object-oriented analysis: UML
• UML diagrams are used to visualize, specify,
construct, and document artifacts of software
systems
• Two types of diagrams
• Structural – static aspects
• Behavioral – dynamic aspects
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 3
1
Behavioral diagrams
•
•
•
•
•
Use case diagrams
Sequence diagrams
Collaboration diagrams
Statechart diagrams
Activity diagrams
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 4
Use case modeling
• Identify the actors (different types of people or
devices) that use the system or product
• Formal definition – actor is anything that communicates
with the system or product and that is external to the
system itself
• Develop the use cases – the manner in which an
actor interacts with the system
• What are the main tasks or functions that are performed by the actor?
• What system information would the actor acquire, produce, or change?
• Will the actor have to inform the system about the changes in the
external environment?
• What information does the actor desire from the system?
• Does the actor needs to be informed about the unexpected changes?
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 5
Use case diagrams: ATM
System boundary
ATM
Use case is behavior of
the system; ellipse that
contains the name of the
use case
Operator transaction
Operator
Customer transaction
Customer
Command functions
Host bank
Actor is an entity (user or another system) that interacts
with the system; stick figures or stereotyped icons
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 6
2
Use case diagrams: SafeHome software
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 7
Use case diagrams: Doctors office
• More details
http://bdn.borland.com/article/0,1410,31863,00.html#use-case-diagrams
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 8
Interaction diagrams
• Behavioral (dynamic) representation
• Describe how objects collaborate
• Present the same information, with a different focus
• Sequence diagrams detail how operations are carried out
o what messages are sent and when
o organized according to time
• Collaboration diagrams convey the same information as
sequence diagrams, but they focus on object roles
instead of the times that messages are sent
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 9
3
Sequence diagrams: ATM
: User
:Host Bank
:ATM
Card Inserted
Object lifeline
Request PIN
aPIN
Request Transaction
Response
Request Account
Messages – interaction
between objects
Account
Request Amount
Amount
Transaction Request
Transaction Authorization
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 10
Sequence diagrams: Making hotel reservation
• More details
http://bdn.borland.com/article/0,1410,31863,00.html#sequence-diagrams
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 11
Collaboration diagrams: Making hotel reservation
• More details
http://bdn.borland.com/article/0,1410,31863,00.html#collaboration-diagrams
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 12
4
Statechart diagram
• Shows the possible states of the object and the transitions that cause a
change in state
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 13
Activity diagram
Focus on the flow
of activities and
shows the how
those activities depend
on one another
essentially a flowchart
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 14
Structural diagrams
•
•
•
•
•
Class diagram
Package diagram
Object diagram
Component diagram
Deployment diagram
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 15
5
Class modeling
• Extract classes and their attributes
• Similarities with entity-relationship diagrams
• Deduce the classes
• from use cases and their scenarios
• noun extraction
• Class-responsibility-collaboration (CRC) cards
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 16
Class diagram
Association - a relationship between instances of the two classes. There
is an association between two classes if an instance of one class must
know about the other in order to perform its work. In a diagram, an
association is a link connecting two classes.
•
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 17
Class diagram
• The multiplicity of an association end is the number of possible
instances of the class associated with a single instance of the other end.
Multiplicities are single numbers or ranges of numbers.
• Most common 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
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 18
6
Class diagram
• Generalization - an inheritance link indicating one class is a superclass
of the other. A generalization has a triangle pointing to the superclass
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 19
Class diagram
• Aggregation - an association in which one class belongs to a collection.
•
An aggregation has a diamond end pointing to the part containing the
whole
Composition - a strong association in which the part can belong to only
one whole - the part cannot exist without the whole. Composition is
denoted by a filled diamond at the whole end.
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 20
Component and Deployment diagrams
• show the physical configurations of software and hardware
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 21
7
Elevator problem
• Software should control n elevators in a building with
m floors
1. Each elevator has a set of m buttons one for each floor.
These illuminate when pressed and cause the elevator to
visit the corresponding floor. The illumination is canceled
when the corresponding floor is visited by the elevator
2. Each floor, except the first floor and top floor, has two
buttons, one to request an up- elevator and one to request
down-elevator. These buttons illuminate when pressed.
The illumination is canceled when an elevator visits the
floor and then moves in the desired direction.
3. When an elevator has no requests, it remains at its current
floor with its doors closed.
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 22
Use case diagram for elevator problem
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 23
Instance of a use case - Normal scenario
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 24
8
Instance of a use case – Exception scenario
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 25
Class modeling
• Stage 1. Concise Problem Definition
Buttons in elevators and on the floors control the motion of
n elevators in a building with m floors.
• Stage 2. Incorporate constraints
Buttons in elevators and on the floors control movement of
n elevators in a building with m floors. Buttons illuminate
when pressed to request the elevator to stop at a specific
floor; illumination is canceled when the request has been
satisfied. When an elevator has no requests, it remains at
its current floor with its doors closed.
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 26
Class modeling (contd)
• Stage 3. Identify nouns. Use nouns as candidate
classes
Buttons in elevators and on the floors control movement of
n elevators in a building with m floors. Buttons illuminate
when pressed to request the elevator to stop at a specific
floor; illumination is canceled when the request has been
satisfied. When an elevator has no requests, it remains at
its current floor with its doors closed.
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 27
9
Class modeling (contd)
• Nouns- button, elevator, floor, movement, building,
illumination, request, door
• Exclude nouns that are outside problem boundary floor, building, door
• Exclude abstract nouns - movement, illumination,
request (may become attributes)
• Candidate classes: Elevator and Button
• Subclasses: Elevator Button and Floor Button
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 28
First Iteration of Class Diagram
Denotes
inheritance
in UML
Attributes
• Buttons do not communicate directly with elevators
• We need an additional class: Elevator Controller
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 29
Second Iteration of Class Diagram
• All relationships are
now one-to-many
• Makes design and
implementation easier
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 30
10
Dynamic Modeling
• UML state diagram for
the class
Elevator Controller
• States, events, and
predicates are
distributed over state
diagram
• UML predicates or
“guards” are in brackets
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 31
Class-responsibility-collaboration (CRC) Cards
• CRC cards are filled for each class
• Name of the class
• Functionality (responsibility)
• List of classes it invokes (collaboration)
class name:
class type: (e.g., device, property, role, event, ...)
class characterisitics: (e.g., tangible, atomic, concurrent, ...)
responsibilities:
Copyright © K.Goseva 2006
collaborators:
CS 230 Introduction to Software Engineering
Slide 32
Class-responsibility-collaboration (CRC) Cards
• CRC cards are an excellent testing technique
• When acted out by team members, powerful tool for
highlighting missing or incorrect fields (attributes or
methods)
• Used for OOA since 1989
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 33
11
CRC card for the class Elevator Controller
• Derived from class diagram &
state diagram
• Responsibility – listing all the
actions in the state diagram for
Elevator Controller
• Collaboration – all the classes
that interact with Elevator Controller
on the class diagram
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 34
CRC Cards – Problem 1
• Consider the responsibility
1.Turn on elevator button
• Responsibility-driven design and information
hiding are ignored
• Responsibility
1.
Turn on elevator button
should be
1.
Send message to Elevator Button to turn on
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 35
CRC Cards – Problem 2
• Consider the responsibilities
7. Open elevator doors and start timer
8. Close elevator doors after timeout
• Elevator doors have a state that changes during
execution (class characteristic)
• Add class Elevator Doors
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 36
12
Second Iteration of CRC Card
• Reconsider
• class model
• dynamic model
• use-case diagram
• Update scenarios
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 37
Third Iteration of Class Diagram
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 38
Second Iteration of Normal Scenario
Copyright © K.Goseva 2006
CS 230 Introduction to Software Engineering
Slide 39
13