1. Complements on Unified Modeling Language
Software Engineering
2007/2008
Ernesto Damiani

2. Outline Use case diagrams Class diagrams Sequence diagrams
State diagrams
Activity diagrams

3. UML
It is an international industry standard graphical notation for describing software analysis and designs
It has been accepted as a standard by the Object Management Group (OMG). The OMG is a non-profit organization with about 700 members that sets standards for distributed object-oriented computing

4. Diagrams Five fundamental UML notations that are introduced here are:
Use case diagrams
Class diagrams
Sequence diagrams
State diagrams
Activity diagrams

5. Use Case Diagrams
Used during requirements elicitation and analysis as graphical means of representing the functional requirements of the system
developed during requirements elicitation and
further refined and corrected as they are reviewed (by stakeholders) during analysis
Very helpful for writing acceptance test cases
Note: The use case diagram is accompanied by a textual use case flow of events.

6. Use Case
It is a sequence of transactions performed by a system that yields an outwardly visible, measurable result of value for a particular actor
They typically represents a major piece of functionality that is complete from beginning to end
Example: for a Word processor
Make some text bold
Create an index
Delete a word

7. Actor
An entity that interacts with the system (person, machine, or other)
It is not part of the system itself
Anyone or anything that must interact with the system to:
Input information to the system;
Receive information from the system; or
Both input information to and receive information from the system
The name should identify the role or set of roles the actor plays relative to one or more use cases

8. Use Case Diagram
A use case diagram is a visual representation of the relationships between actors and use cases together that documents the system’s intended behavior

9. Use Case Diagram -Early Example
Select/Delete
Courses
Current Status
actor
student
Print
Timetable
use case

10. Example

11. Use Case Diagram -Wrong
Select the functionality to use
student

12. Use Case Diagram –Correct, somewhat
Enrollment to exams
Study plan
Study career
student
Management of the final exam

13. Types of relationship Between actors and use cases:
«communicates» relationship indicates that one of these entities initiated invoked a request of the other
An actor communicates with use cases because actors want measurable results.
Two use cases communicate if a case
needs information from another use case or
needs to initiate action of another use case.
There are two other kinds of relationships between use cases (not between actors and use cases) that you might find useful.
«include» and
«extend»

14. <<include>>
Used when a chunk of behavior is similar across more than one use case
Breaking out re-used functionality in a program into its own methods that other methods invoke for the functionality

15. «extend»
Used to describe a variation on normal behavior or behavior that is only executed under stated conditions
Used when the alternative flow is fairly complex and/or multi-stepped, possibly with its own sub-flows and alternative flows

16. Example
The train waits at the station until the signal turns green. After the signal turns green, the train ensures that no doors are blocked. If any door is blocked, the train sounds an announcement for passengers to clear the doorways, waits for 10 seconds, and then tries to close the doors again. If the doors are not closed after three such cycles, a train operator is dispatched to find the problem. After the doors are closed, the train leaves the station at an acceleration rate of 10km/min2. After six seconds, the train reaches a cruising speed of 60km/h. The train maintains that speed until it reaches the next station. The train stops at the next station.

17. «include» vs. «extend» Use Case X includes Use Case Y:
X has a multi-step subtask Y. In the course of doing X or a subtask of X, Y will always be completed.
Use Case X extends Use Case Y:
Y performs a sub-task and X is a similar but more specialized way of accomplishing that subtask (e.g. closing the door is a sub-task of Y; X provides a means for closing a blocked door with a few extra steps). X only happens in an exception situation. Y can complete without X ever happening

18. Developing a Use Case
What are the main tasks or functions that are performed by the actor?
What system information will the the actor acquire, produce or change?
Will the actor have to inform the system about changes in the external environment?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected changes?

19. Example Suppose we want to model the New York Stock Exchange …
There are traders ...
… and Sales systems

20. Use case diagram <<includes>> Evaluation Analyze risks
Trader
Price details
Sales system
Get the deal
<<extends>>
Limit exceeded

21. Example use case description
Use Case: Get the deal
1. Enter the user name & bank account
2. Check that they are valid
3. Enter number of shares to buy & share ID
4. Determine price
5. Check limit
6. Send order to NYSE
7. Store confirmation number

22. Another Example
A Use Case description of the web site of Air Canada (

23. Extraction of Classes in the AirCanada example
The user enters the subsystem. To do so it needs to be a frequent flyer. Inside the subsystem, the user can access (a) general information about the frequent flyer program -the reward schema, how to enroll, how to earn miles with partner companies, and (b) specific information on her/his miles earned, the status level. The user can also update her/his address.
For status we have generalization!!!

24. Partial Solution Reserve a seat <<includes>>
Manage reservations and schedules
Analyse frequent flyer status and related information
<<includes>>
<<includes>>
Check the time for a flight
<<includes>>
Customer
Manage fares
Search for a cheap trip
<<includes>>

25. Textual Description (only for the frequent flyer use case) (2/2)
The user enters the subsystem to gain more information about its frequent flyer status. Inside the subsystem, the user can access:
(a) general information about the frequent filer program – the reward schema, how to enroll, how to get miles with partner companies, and

26. Textual Description (only for the frequent flyer use case) (2/2)
(b) specific information on her/his status, such as the miles earned, the status level. The user can also update her/his address.
NOTICE: This is a very different format!!!

27. Outline Class diagrams Use case diagrams Sequence diagrams
State diagrams
Activity diagrams

28. Class Diagrams Used in both the analysis and the design phases.
analysis phase:
describes the classes and relationships in the problem domain, but it does not suggest how the system is implemented.
design phase:
class diagram describes how the system to be implemented should be developed.
after the design phase:
class diagram has detailed implementation information, including the class names, the methods and attributes of the classes, and the relationships among classes
UML notation for a class

29. Evolution… One class At analysis you know the class name
At design you specify the attributes
At analysis you specify the name of the operations
At design you specify the behaviour of the operation
At coding level you provide the specifics of the method
One class

30. Extraction of Classes Normal sequence: Get the deal
1. Enter the user name & bank account
2. Check that they are valid
3. Enter number of shares to buy & share ID
4. Determine price
5. Check limit
6. Send order to NYSE
7. Store confirmation number

31. How to define classes? Look for nouns in the Use Cases
Define a class for every noun (+ add others)
Document the set of rules that determine the set of objects belonging to the class
Add associations to model the relations
Think about the subset relationship to build generalizations ...

32. Static Relationships Inheritance (“generalization”)
can be thought of as an “is-a” relationship
Association represents a relationship between two instances of classes
Association indicates that one class utilizes an attribute or methods of another class
aggregation, and
composition

33. Generalization: extension & restriction
Attributes & operations of an ancestor class are inherited to the subclass
Extension: adding of new attributes or operations
Restriction:Additional restrictions on ancestor attributes
circle = Ellipse with equally long axes
Caution: arbitrary change of size of an axis of the circle can violate restriction

34. Restriction class Ellipse { double axis1, axis2;
Ellipse(double d1, double d2) {
axis1 = d1; axis2=d2; }
double getAxis1() {return axis1;}
double getAxis2() {return axis2;}
void setAxis1(double d1) { axis1=d1; }
void setAxis2(double d2) { axis2=d2; }
class Circle extends Ellipse {
Circle(double radius) {
super(radius,radius)
double getRadius() { return getAxis1() ;}
void setRadius(double radius) {
setAxis1(radius);setAxis2(radius);

35. Generalization vs. Extension
Car
Truck
Bus
Station wagon
Many things in common
Some differences
Extension
Generalization

36. Multiple inheritance
Class inherits features from several super-classes
vehicle
land vehicle
water vehicle
car
amphibian
ship

37. Proposed Exercise
Define the class of “textbooks” as derived from the concept of “educational tool” and of “book”
Redefine the class avoiding multiple inheritance
Show the problem of virtual base classes

38. Discussing multiple inheritance
Advantages:
closer to human thinking
higher flexibility for specifying classes
higher chances for reuse
Disadvantages:
loss of clarity which method is executed
implementation more complicated
conflict resolution is necessary for multiple inherited features

39. Avoiding multiple inheritance
Basically: question of implementation
Often the simplest way: restructure model
Techniques for restructuring:
Delegation & aggregation
Inheritance based on the most important feature and delegation of the rest
Generalization based on different dimensions

40. Delegation & aggregation
vehicle
vehicle
land vehicle
water vehicle
car
amphibian
ship
VehicleFeature
LandFeature
WaterFeature
Notice the symbol for virtual inheritance

41. Aggregation
It conveys the information that one object is part of another object, but their lifetimes are independent (they could exist independently)
Aggregation is stronger than association
is often thought of as a “has-a” relationship
is unidirectional: there is a container and one or more contained objects
“a Department contains a set of Employees”
“a Faculty contains a set of Teachers”

42. Example: Aggregation (1/2)
Company *
Unit *
Department
works for *
Group *
employs
Employee

43. Example: Aggregation (2/2)
Company *
Unit *
Department
works for *
Group
1..3 *
employs
has
Employee
1..*
Here we say that an employee belongs to at least one group
Can an employee belong to more than one department?
Here we have no constraints. Constraints may be added in OCL

44. Composition (1/2)
An object is contained in another object, and it can exist only as long as the container exists and it only exists for the benefit of the container
Any deletion of the whole is considered to cascade to all the parts
Stronger than aggregation

45. Composition (2/2)
Example

46. Aggregation and composition
Components belong only to one whole
Parts live and die with the whole
cascading delete
also needed for 1..1 associations
The players can be aggregated for the Flames BUT they are not killed when the Flames disappear
Polygon
Aggregation
Composition 1 1 1
Graphics Bundle
{ordered}
3..*
Point
color
texture

47. Attributes and Operations
visibility name : type [= defaultValue]
The operations are the services that a class is responsible for carrying out.
visibility name(parameter-list) :
return-type{property string}

48. Attributes Conceptual: Indicates that customer have names
Specification: Customer can tell you the name and set it
Implementation: An instance variable is available
Customer
name
address
creditRating

49. Difference between attributes and associations
Conceptual perspective
not much of a difference!
Attributes are simple/single valued (0..1)
Specification/implementation perspective
Navigability from type to attribute
Attribute stores values NOT references
no sharing of attribute values between instances!
Often: Stores simple objects
Numbers, Strings, Dates, Money objects

50. Operations Processes that a class knows to carry out
Correspond to messages of the class
Conceptual level
principal responsibilities
Specification level
public messages = interface of the class
Normally: Don’t show operations that manipulate attributes –the setter and getter methods

51. Types of operations
Query = returns some value without modifying the class’ internal state
Modifier = changes the internal state
Queries can be executed in any order
Getting & setting messages
getting: query
setting: modifier

52. Multiplicity
indicates how many objects of each class can legitimately be involved in a given relationship
Cardinality and modality
UML symbol
One-to-one and mandatory 1
One-to-one and optional
0..1
One-to-many and mandatory
1..*
One-to-many and optional *
With lower bound l and upper bound u
l..u
With lower bound l and no upper bound
l..*

53. Example Classes of association Kind Information held
Track, TrackSection
Composition
A track contains one or more track sections. A track section is contained in one and only one track. The track can access its sections, while these do not need to access their track. The track sections cannot exist in isolation, but only if contained by a track.
TrackSection, TrackSection
Association
Every track section is associated to, and must be able to access, its next section and its preceding section, along the track.
TrackSection, Train
A track section contains zero or one train. A train is contained in one or more track sections. The track section can access its train, and the train can access the track section it is contained in.

54. Class diagram example
Actuator
Back to the example of the air conditioning system
startUp( )
shutDown( )
Light
Heater
Cooler
Temperature 1 1
off( ) 1 1
on( ) * * 1 1 1 1 1 1
SystemLog
Environmental Controller
Display( )
Define_climate( )
RecordEvent( )
Terminate_climate( )

55. More Advanced Class Diagram Concepts
Abstract Classes
Packages
Stereotypes
Notes

56. Packages
If a system is big, it should be partitioned in smaller sub-systems, each with its own class diagram
A package is a grouping of model elements
A package may contain both:
subordinate packages and
ordinary elements
Package 1
Package 2

57. Stereotypes
Stereotypes are high-level classifications of an object that gives some indication of the kind of object it is
Common class stereotypes are:
«control», a class, an object of which denotes an entity that controls interactions between a collection of objects;
«entity», a class that represents a domain-specific situation or a real-world object and that does not initiate interactions; and
«boundary», a class that lies on the periphery of a system but within it

58. Object Diagram
A snapshot of the detailed state of a system at a point in time. It can contain:
many different instances of the same class, and
no instance of other classes.
While there is only class diagram of the system, there may be hundreds of different object diagrams
the associations among objects are shown as links

59. Example: object diagram

60. Outline Sequence diagrams Use case diagrams Class diagrams
State diagrams
Activity diagrams

61. Sequence diagrams
Often used to depict the chronologically-structured event flow through a use case
Sequence diagrams represent a system behavior based upon the needed interactions among a set of objects in terms of the messages that exchange among them to produce the desired result
They have two dimensions:
the vertical dimension represents time
the horizontal dimension represents different objects

62. Timelines Messages point from client to supplier : Professor
CourseManager
Math Section
1 : CourseOffering
Add professor (Professor)

63. Example: Sequence diagram
: Registrar
course form :
CourseForm
theManager :
CurriculumManager
aCourse :
Course
1 : set course info
2 : process
3 : add course
4 : new course

64. Sequence diagrams: More details
Iteration
Object
creation
Condition
an Order
an Order
a Stock Item
Entry window
an Order
1: prepare()
Line
2: * prepare()
3: check()
4: [check = true] remove()
5: needsToReorder() X
Asynchronous
Message
Self delegation
Activation
Object deletion

65. Asynchronous messages
Does not block the caller
Can do 3 things:
Create a new thread
Create a new object
Communicate with a thread that is already running

66. Example

67. Outline State diagrams Use case diagrams Class diagrams
Sequence diagrams
State diagrams
Activity diagrams

68. State Diagram
A state is a condition in which an object can be at some point during its lifetime, for some finite period of time
A state diagram describes the behavior of one object across several use cases
all the possible states a particular object can get into
how the objects state changes as a result of external events that reach the object
It is used to identify object attributes and to refine the behavior description of an object

69. State changes (1) States may be changed when an event occurs
overdrafted
deposit
withdraw ok

70. State changes (2) Events: Messages received
Events may or may not change the state
deposit
overdrafted
withdraw
withdraw
deposit ok

71. Example 1 (on-line auction)

72. State diagram notation
Activity: Can take longer and be interrupted
Action: Occur quickly what does “quickly” mean?
entry: an action that is performed on entry to the state
do: an ongoing activity performed while in the state (example: display window)
on: an action performed as a result of a specific event
exit: an action performed on exiting the state
On Auction
state variable(s)
entry: generate&link web page
do: perform access statistics
on: event-A: action-A
exit: unlink the page from site

73. State diagram notation (2)
State-A
Event(arguments)[condition]/action
State-B
Event: message send
Guard condition:
Transition only occurs when guard evaluates to true
Guards of transition exiting one state are mutually exclusive
Action: Processes considered to occur quickly and are not interruptible
Each part can be omitted!

74. Example 2 (air conditioner)
Initialize
Idle
Daytime
Nighttime
Temperature drop or rise / adjustTemperature()
Temperature drop or rise / adjustTemperature()
Terminate
Climate
Sunset / Lights::off()
Terminate Climate
Sunrise / Lights::on()
Define Climate

75. Example 3 (States of a hockey game)
shootout
tie[ time is up ]
playing
Boxing
penalty
In the arcs:
action [condition]
face off
win[ time is up ]
break
end of game

76. State transitions for an order
Event
get next item[ not all
Item received[ some
items checked ]
items not in stock ]
Action
[ All items checked && some
/ get first item
Checking
items not in stock ]
Waiting
do: check item
[ All items checked &&
Guard
Item received[ all items
all items available ]
available ]
Dispatching
Delivered
Delivered
do: initiate delivery

77. Problem: Cancel the order
Want to be able to cancel an order at any time
Solutions
Transitions from every state to state “cancelled”
Superstate and single transition

78. Transitions to “cancelled”
get next item[ not all
Item received[ some
items checked ]
items not in stock ]
[ All items checked &&
some items not in stock ]
/ get first item
Checking
Waiting
do: check item
Item received[ all
[ All items checked &&
items available ]
all items available ]
cancelled
cancelled
Dispatching
cancelled
do: initiate delivery
Cancelled
Delivered
Delivered

79. Superstate / Substates
Active
get next item[ not all
Item received[ some
items checked ]
items not in stock ]
[ All items checked && some
items not in stock ]
/ get first item
Checking
Waiting
do: check item
cancelled
Cancelled
[ All items checked &&
Item received[ all
all items available ]
items available ]
There are also concurrent substates
Delivered
Dispatching
Delivered
do: initiate delivery

80. Outline Activity diagrams Use case diagrams Class diagrams
Sequence diagrams
State diagrams
Activity diagrams

81. Activity diagrams Used to describe Activities Similar to Petri nets
workflow
parallel processing
Activities
conceptual: task to be done
specification/implementation: method on a class
Similar to Petri nets

82. Activity diagrams They consist of:
Activities: activity is a single step that needs to be done, whether by a human or a computer
Incoming transitions trigger the activity
If there are several incoming transitions, any of these can trigger the activity independent of the others

83. Activity diagrams They are used during:
Analysis, to break down the complex flow of a use case
Design of complex methods
They are updated and enhanced form of flowcharts
They are variation of a state chart, in which
the states are activities representing the performance of operations and
the transitions are triggered by the unconditional completion of the operations
They are enhancement over flowcharts is the ability to handle parallelism when the order of the ensuing activities is irrelevant; they can run
consecutively,
simultaneously, or
alternately

84. Activity diagrams (coffee machine)

85. Structure of activity diagrams
Fork
Activity
Synchronization bar:
Activities can be carried out in parallel (any order)
- Incoming: all predecessors have to be finished
Activity diagram shows partial order of activities
Activity
Activity
[synchronization condition]
Join
Activity

86. Examples

87. A Comprehensive Example: The Elevator

88. enter and exit through a door
Elevator -- Use Case
n elevators, m floors
Elevator
press an elevator button
Objects
press a floor button
User
enter and exit through a door

89. Elevator - First Class Diagram
Floor Button
Elevator Button
Elevator Controller
Elevator
Button
illuminated: boolean
controls mn
2m-2 1 n
Elevator Doors
doors open: boolean

90. Elevator - State Diagram
[button pushed,
button unlit]
Process Request
do/update request
do/turn on button
[elevator moving
in direction d,
floor f is next]
Determine if Stop Requested
do/ check requests
[no request
to stop at
floor f]
[user requested
stop at floor f]
Stop at Floor
do/stop elevator
do/open doors
do/update requests
Continue Moving
do/move elevator
one floor in
direction d
[elevator
Elevator Button Off
do/ turn off elevator
button
button lit]
Elevator Controller Loop
Process Next Request
do/move elevator one
floor in direction of
next request
Floor Button Off
do/turn off floor
Close Elevator Doors
do/close elevator doors
after timeout
stopped,
request(s)
pending]
Go into Wait State
no requests
[floor
[no requests pending,
doors closed]
[button pushed, button lit]
Elevator - State Diagram

91. Elevator - Sequence Diagram
User A
Floor
Button
Elevator
Button
Elevator
Controller
Elevator
Elevator
Doors
1. Press floor button
2.Turn on light
3.* Move up one
floor
4.Turn off light
5. Open doors
6. Press elevator button
7. Turn on
light
8. Close doors
9.* Move up one
floor
10. Turn off light
11. Open doors
12. Start timer
13 Close doors
14.* Move
up one floor
*elevator movement can be up or down