Complements on Unified Modeling Language

1
Complements on Unified Modeling Language

• Software Engineering
• 2007/2008
• Ernesto Damiani (Ernesto.Damiani_at_unibz.it)

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 systems intended
  behavior

9
Use Case Diagram -Early Example
actor
student
Print Timetable
use case
10
Example
11
Use Case Diagram -Wrong
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
ltltincludegtgt

• 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
ltltincludesgtgt
Evaluation
Analyze risks
ltltincludesgt
Trader
Price details
Sales system
Get the deal
ltltextendsgtgt
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 (http//www.aircanada.ca/home.html)

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.

24
Partial Solution
Reserve a seat
ltltincludesgtgt
Manage reservations and schedules
ltltincludesgtgt
Analyse frequent flyer status and related
information
ltltincludesgtgt
Check the time for a flight
ltltincludesgtgt
Customer
Manage fares
Search for a cheap trip
ltltincludesgtgt
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

• Use case diagrams
• Class 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
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
• RestrictionAdditional 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 axis2d2
• double getAxis1() return axis1
• double getAxis2() return axis2
• void setAxis1(double d1) axis1d1
• void setAxis2(double d2) axis2d2
• 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

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

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
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

• 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
  FlamesBUTthey are not killed when the Flames
  disappear

Polygon
Composition
Aggregation
1
1
1
GraphicsBundle
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-typeproperty 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 Dont 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

53
Example
54
Class diagram example
Actuator
Back to the example of the air conditioning system
startUp( )
shutDown( )
Light
Heater
Cooler
Temperature
1
1
1
1
off( )
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

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

• Use case diagrams
• Class diagrams
• Sequence diagrams
• State diagrams
• Activity diagrams

61
Sequence diagrams

• Often used to depict the chronologically-structure
  d 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 101 - Section 1 CourseOffering
Add professor (Professor)
63
Example Sequence diagram
aCourse Course
theManager CurriculumManager
course form CourseForm
1 set course info
2 process
3 add course
4 new course
64
Sequence diagrams More details
Object creation
Iteration
Condition
an Order
an Order
a Stock Item
Entry window
an Order
Line
1 prepare()
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

• 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 generatelink web page
do perform access statistics
on event-A action-A
exit unlink the page from site
73
State diagram notation (2)
Event(arguments)condition/action
State-A
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)
75
Example 3 (States of a hockey game)
shootout
tie time is up
playing
Boxing
penalty
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
items not in stock
Checking
/ get first item
Waiting
do check item
All items checked
Item received all items
Guard
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
Item received some
get next item not all
items not in stock
items checked
All items checked
some items not in stock
Checking
/ get first item
Waiting
do checkitem
Item received all
items available
All items checked
all items available
cancelled
cancelled
Dispatching
cancelled
do initiate delivery
Cancelled
Delivered
Delivered
79
Superstate / Substates
Active
Item received some
get next item not all
items checked
items not in stock
All items checked some
items not in stock
Checking
/ get first item
Waiting
do checkitem
cancelled
Cancelled
Item received all
All items checked
items available
all items available
Delivered
Dispatching
Delivered
do initiate delivery
80
Outline

• Use case diagrams
• Class diagrams
• Sequence diagrams
• State diagrams
• Activity diagrams

81
Activity diagrams

• Used to describe
• 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
Activity
Activity
Activity
synchronization condition
Activity
86
Examples
87
A Comprehensive ExampleThe Elevator
88
Elevator -- Use Case
n elevators, m floors
Elevator
press an elevator button
press a floor button
User
enter and exit through a door
89
Elevator - First Class Diagram
90
Elevator -StateDiagram
91
Elevator - Sequence Diagram
1. Press floor button
9. Move up one floor
14. Move up one floor
elevator movement can be up or down