UML

1
UML

• COSC 2P90

2
Unified Modelling Language

• All engineering disciplines have some sort of
  modelling standard
• Required to communicate design
• Simply complex interaction
• Software engineering should be no different!
• Booch, Rumbaugh, Jacobson c. 1995 came up with
  UML
• Collaboration of various techniques for different
  modelling diagrams
• Goals of UML
• Model systems, from concept to executable, using
  OO techniques
• Address issues of scale inherent in complex
  systems
• Create a modelling language understandable by
  humans and machines
• Standard language for specifying, visualizing,
  constructing and documenting a software system

3
Modeling

• UML has 3 essential building blocks
• Things
• Relationships
• Diagrams
• There are 4 kinds of things
• Structural
• The nouns or static objects
• Classes, interfaces, collaborations, use cases,
  active classes, components, nodes variants on
  these
• Behavioral
• verbs represent behavior over time and space
• Interactions (messages), states
• Grouping
• Organizational - packages
• Annotational
• Comments/Notes

4
Modeling

• 4 Relationships
• Dependency
• Semantic relationship indicating a change to one
  thing may change another
• Association
• Structural relationship indication a link between
  objects (e.g. aggregation)
• Generalization
• Indicates substitutability (i.e. inheritance)
• Realization
• Realization of a contract (i.e. implement an
  interface)

5
Modeling

• Diagrams
• 4 Types of static view diagrams
• Class diagram
• shows classes their relationships
• Object diagram
• shows a set of objects their relationships
• Component diagram
• Shows components their relationships higher
  level than class diagram
• Deployment diagram
• Shows the relationship between a set of nodes
• 5 types of dynamic view diagrams
• Use case diagram
• Organization of the behaviors of the system
• Sequence diagram
• Interaction diagram that shows the time ordering
  of messages
• Collaboration diagram
• Interaction diagram that shows the structural
  organization of objects that send and receive
  messages
• Statechart diagram
• Statemachine diagram

6
Use Case

• Use Cases
• Show what the system does, not how
• Start design with creating a set of use case
  diagrams show what the behavior of the system is
• Scenario a description of specific use of the
  system by a user, e.g.
• Joe goes to the box-office to buy a ticket to
  the Ron Sexsmith concert. The clerk checks the
  availability. Joe chooses a seat. The clerk asks
  for payment. Joe hands his credit card. The clerk
  enters the credit card information. The system
  validates bills the credit card. The system
  prints the ticket. The clerk gives Joe the
  ticket.
• Use case generalization of a set of scenarios
  that start with the same request to achieve the
  same user goal
• goal the business value to the user
• system application and hardware used by user
• actor an external entity that interacts with
  the system
• In this case, the system is the box office
  software hardware, the goal is buying a
  ticket(s) and the actor is the clerk.

7
Use Case Template

• Use Case Name
• Description A one or two sentence description of
  the use case
• Actors Identifies the actors participating in
  the use case
• Includes Identifies the use cases included in it
• Extends Identifies the use cases that it may
  extend
• Pre-Conditions Identifies the conditions that
  must be met to invoke the use case
• Details Identifies the details of the use case
  the action
• Post-conditions Identifies the conditions that
  are assured to hold at the conclusion of the use
  case
• Exceptions Identifies any exceptions that might
  arise in the execution of this use case
• Constraints Identifies any constraints that may
  apply
• Variants Identifies any variations that might
  hold for the use case
• Comments Provides any additional information
  that might be important in this use case

8

• Buy Tickets
• Description A customer purchases tickets for an
  event from a clerk
• Actors Clerk
• Includes Make Charges
• Extends none
• Pre-Conditions Event must be scheduled
• Details
• Clerk requests availability for number of tickets
  for event
• Box-Office displays availability
• Clerk selects seats
• Box-Office indicates cost
• Clerk selects credit card purchase and enters
  card number
• Box-Office makes charges to credit card
• Box-Office prints tickets
• Post-conditions Selected ticks are sold
• Exceptions Credit card not validated
• Constraints None
• Variants Cash purchase
• Comments None

9
Use Case Diagrams

• Shows how use cases are related to each other and
  to the actors
• Shows which actors participate in which use cases
• Actors roles played by users (or anything
  external to the system)
• Cause input into the system
• Use cases a transaction among actors and the
  system
• Associations
• Inclusion one use case is a part of another
• Extension specialized version of the case
• system boundary
• example Box-Office

10
Use Case Diagram
Box-Office
Clerk
association
ltltincludegtgtrelationship
ltltincludegtgt
Kiosk
Credit card Service
System boundary
actor
use case
Supervisor
11
Class Diagrams (U4,U5,U8)

• Depict static structure of the design
• Classes are depicted by boxes with
• Name
• Attributes
• Operations
• Responsibilities
• Relationships between objects
• Dependency uses a
• Association has a
• Can have 4 adornments name, role, multiplicity,
  aggregation
• Inheritance
• advanced features multiplicity, named
  relationships, dependencies, visibility

12
Relationships (U5-1)
Window
Event
dependency
generalization
association
ConsoleWindow
Control
DialogBox
13
Structural Relationships

• Association has 4 adornments
• Name
• describes the nature of the relationship
• Role
• The role an object plays in a relationship
• E.g. A Person plays the role of an employee when
  associate with a company
• Multiplicity
• Description of how many objects can be connected
• Aggregation/Composition
• Aggregation (open diamond) has a relationship
  where each object can exist independently
• Composition (filled diamond) has a relationship
  where one objects existence is dependent on the
  other (i.e. life cycle dependency)

14
Structural Relationships (U5-10)
has
0..1
Department
School
1..
1
1..
1..
1..
assignedTo
member
0..1 chairperson
1..
1..

teaches
attends
Instructor
Course
Student



1..
15
Modeling Simple Collaborations

• No class exists in isolation. They collaborate to
  achieve behavior
• To model a collaboration
• Identify the behavior you need to model
• Identify the classes, interfaces and other
  collaborations that are active in the behavior
• Walk through use cases to identify associations
• Identify responsibilities, evolve them into
  properties and operations
• Focus only on the relevant information dont
  clutter with irrelevant information

16
Modeling Simple Collaborations (U8-2)
1

CollisionSensor
1
1
1
1
MainMotor
SteeringMotor
Motor
Move(dDirection sSpeed) stop() resetCounter() S
tatus status() Integer distance()
17
Dynamic Modelling (U7, U18)

• Modelling the behaviour of a system
• i.e. Describing the interaction of the system
• Usually involves modelling concrete or
  prototypical instances
• Use case diagrams
• Collaboration diagrams
• flow of function calls between objects
• emphasis structural relationship
• Sequence diagrams
• interaction of objects as messages are passed
• emphasis timing
• State diagrams
• sequence of states for an object
• states, events and transitions
• Activity diagrams
• flowcharts
• emphasis flow of control from activity to
  activity

18
Sequence Diagrams (U18)

• Emphasizes the time-ordering of messaging
• Is an interaction diagram that uses
• objects
• messages
• Each object has an lifeline representing the
  existance of the object (dashed line)
• The focus of control is a think bar around the
  lifeline representing the time an object is
  performing an action
• Objects that participate are placed across the
  X-axis
• The timeline is represented down the Y-axis
• examples ODBC, phone call

19
Sequence Diagram (U18-2)
objects
p ODBCProxy
c Client
transient
ltltcreategtgt
Transaction
setActions(a, d, o)
setValues(d, 3.4)
setValues(a, CO)
time
committed
lifeline
ltltdestroygtgt
focus of control
20
Modeling Sequence Diagrams

• To model a sequence (flow-of-control)
• Identify which objects play a role in the
  interaction
• Lay them out left to right, with most important
  objects to the left
• Create the lifelines for the objects
• Indicate birth and death
• Start with the initial message
• Lay out each subsequent message
• Show each messages properties (parameters)
• Attach time or space constraints (with adornments)

21
Sequence Diagram (U18-4)
Switch
r Caller
s Caller
liftReceiver
setDialTone()
dialing.executionTime lt 30 sec
dialDigit(d)
routeCall(s, n)
dialing
ltltcreategtgt
c Conversation
ring()
liftReceiver
connect(r, s)
connect(r)
connect(s)