Part III Unified Modeling Language

1
Part IIIUnified Modeling Language
2
Chapter 6Introduction
3
UML (Unified Modeling Language)

• An industrial defacto standard for modeling
  object-oriented software.
• Resulted from the convergence of notations from
  three leading object-oriented methods
• OMT (James Rumbaugh), OOSE (Ivar Jacobson), OOD
  (Grady Booch)
• UML II
• Supports the entire software development
  lifecycle, diverse applications areas
• Supported by several CASE tools, e.g. Rational
  ROSE, Together/J
• Three categories (Notation-wise)
• Modeling Elements (Things)
• Relationships
• Diagrams
• Formal semantics
• Object Constraint Language (OCL)

4
Modeling Elements

• Structural elements
• class, interface, collaboration, use case, active
  class, component
• Behavioral elements
• interaction, state machine
• Grouping elements
• package, subsystem
• Other elements
• note

5
Relationships

• Generalization/Specialization
• Association
• Aggregation
• Composition
• Dependency
• Refinement/Realization

multiplicity
0..1 relation_name
Class 1
Class 2
role_name1 role_name2
6
Extension Mechanisms

• Stereotype
• Tagged value
• Constraint

7
UML Core Conventions

• Rectangles are classes or instances
• Ovals are functions or use cases
• Instances are denoted with an underlined names
• myWatchSimpleWatch
• JoeFirefighter
• Types are denoted with nonunderlined names
• SimpleWatch
• Firefighter
• Diagrams are graphs
• Nodes are entities
• Arcs are relationships between entities

8
Diagrams

• A diagram is a view of a model
• Presented from the aspect of a particular
  stakeholder
• Provides a partial representation of the system
• semantically consistent with other views
• There are 9 standard diagrams
• Use case diagram
• Class (object) diagram
• Behavior diagram
• activity, collaboration, sequence, state
• Implementation diagrams
• Component, Deployment,

9
Diagrams

• Use case diagrams
• Describe the functional behavior of the system as
  seen by the user, that is I.e. how to use the
  system
• Illustrate actors, use cases, and their
  relationships
• Class diagrams
• Describe the static structure of the system
  Objects, Attributes, and Associations.
• Shows classes and their relationships with each
  other.
• Activity diagrams
• Model the workflow of the system.
• Shows activities, object states, states, state
  transitions, and events.
• Collaboration diagram
• Shows objects and their relationships, including
  their spatially structure message exchange

10
Diagrams(cont)

• Sequence diagrams
• Describe the dynamic behavior between actors and
  the system and between objects of the system.
• Illustrate objects and their relationships,
  including their chronologically structured
  message exchange
• State diagrams
• Describe the dynamic behavior of an individual
  object as a finite state machine.
• Illustrate state, state transitions, and events
• Component diagram
• Illustrate components and their relationships
• Deployment diagram
• Illustrate components, nodes and their
  relationships

11
Chapter 7Use Case Diagram
12
Use Case Diagram

• A graph of actors, a set of use cases, possibly
  some interfaces, and the relationships between
  these elements.
• The relationships are associations between the
  actors and the use cases, generalizations between
  the actors, and generalizations, extends, and
  includes among the use cases.
• The use cases represent functionality of a system
  or a classifier, like a subsystem or a class.
• Developed by analysts and domain experts

13
Use Case Diagram

• Purposes of use case diagram
• Describe the interaction between a set of use
  case and the actors
• Capture system functionality as seen by users
• Used during requirements elicitation to represent
  external behavior of system
• Drive implementation and generate test cases

14
Use Case Diagram
Package
SimpleWatch
Actor
ReadTime
SetTime
WatchUser
WatchRepairPerson
Use case
ChangeBattery
15
Actors

• An external entity communicates with the system
  by sending and receiving messages, and exchanging
  data and events.
• user, external system, physical environment, a
  user of the system
• A description to represent roles that play the
  system functions
• A person can play a number of roles (actors)
• Examples
• Passenger A person in the train
• GPS satellite Provides the system with GPS
  coordinates
• ATM the client is an actor who can withdraw
  money from an account, transfer money to an
  account, or check balance of an account

16
Actors

• Notation
• Textual stereotyping
• Visual stereotyping
• Textual and visual stereotyping
• Generalization/specialization

ltltactorgtgt Customer
ltltactorgtgt Customer
Home insurance clerk
Car insurance clerk
Field service clerk
17
Actors

• Other parties
• ltltboundarygtgt, ltltinterfacegtgt dialogs and other
  interaction interfaces
• ltltcontrolgtgt controller control the interaction
  between different objects
• ltltentitygtgt passive objects needed in use case

Controller
Schedule
18
Use Case

• A use case representing a coherent unit of
  functionality provided by a system, a subsystem,
  or a class.
• A sequences of messages exchanged among the
  system and the actors together with actions
  performed by the system.
• A scenario that describes a thread of usage for
  a system
• Describe a set of activities of a system from the
  point of view of its actor
• Be always initiated by an actor
• Extension points may be listed in a compartment
  of the use case with the heading extension
  points.
• The name of an abstract use case may be shown in
  italics.

19
Use Case

• A use case can be described as the
  content-related structuring text
• Unique name of use case
• Participating actors
• Entry conditions, preconditions
• Exit conditions, post conditions
• Invariants conditions must always be satisfied
• Special requirements, non-functional requirements
• Flow of events, process description
• Exceptions, error situations
• Variations deviations and exceptions from the
  normal process and description of alternative
  process for these case.

20
Use Case

• Business rules, validation rules
• Services
• Contact partners
• Notes / open questions design decisions / design
  alternatives
• Documents, reference, dialog samples, references
  screen shots, instructions, manuals
• Diagrams UML diagram

21
Explorative prototypes

• To communication with users
• Concrete screen dialog
• Business forms
• Sample print-outs
• Visual material

22
The Relationships of Use Case

• Extend (A to B)
• B is extended (for specific conditions) by the
  behavior of A. The behavior of A is inserted at
  the extension point in B.
• The direction is to the extended use case
• Include (C to D)
• C contains the behavior of D.
• To extract identical section occurring in several
  use cases in order to prevent redundancy.
• The direction is to the using use case
• Generalization (E to F)
• E is a specialization of F.

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

24
Use Case Example(1)

• Name Purchase ticket
• Participating actor Passenger
• Entry condition
• Passenger standing in front of ticket
  distributor.
• Passenger has sufficient money to purchase
  ticket.
• Exit condition
• Passenger has ticket.

• Event flow
• 1. Passenger selects the number of zones to be
  traveled.
• 2. Distributor displays the amount due.
• 3. Passenger inserts money, of at least the
  amount due.
• 4. Distributor returns change.
• 5. Distributor issues ticket.

Anything missing?
25
(No Transcript)
26
Validate
validate with PIN
validate with card
27
Use Cases Example(2)

• ATM. The client (actor) can withdraw money from
  an account, transfer money to an account, or
  check the balance of an account. These
  operations, correspond to flows, which can be
  represented by use cases.

28
Use Case Example(3)
29
Chapter 8Class Diagram
30
Class Diagram

• Captures the structure of a system
• during requirements analysis to model problem
  domain concepts
• during system design to model subsystems and
  interfaces
• during object design to model classes.

31
Class

• To represent a concept and encapsulates state
  (attributes) and behavior (operations).
• attribute has a type.
• operation has a signature.

Name
Signature
32
MetaClass

• Classes of class objects (underline for operation
  and attribute)
• A class operation is new
• A class attribute is numberOfInstances

ltltinstance ofgtgt
33
Parameterized Class

• Template class (in C)
• With generic formal parameters

iElement
WaittingRoom
WaittingQueue
ltltbindgtgt(patient)
Add() Remove()
ltltbindgtgt(Car)
TrafficJam
34
Abstract Class

• Virtual class (in C)
• Never used to generate object instance

GeomFigure abstract
Circle
Rectangle
Triangle
35
Utility Class

• Collections of global variables and functions
• Math class in Java

ltltutilitygtgt Math Pi Sin() Cos()
36
Object

• An Object is a unit which actually exists and
  acts in the current system, a phenomenon.
• An alternative term is instance
• The name of an instance is underlined and can
  contain the class of the instance.
• The attributes are represented with their values.
• Multiple classification an object is an instance
  of more than one class
• Dynamic classification an object can became an
  instance of more than one class

aCircle Circle radius25 Center (10,10)
37
Attribute

• An attribute is a data element which is contained
  in the same way in each object of a class
• Name
• Constraint restrict the value range
• Tagged value specify special properties
• Derived attributes /
• Class attributes
• Visibility
• Private -
• Protected
• Public

Circle nameString Unknow -radiusradiusgt0 C
enter (10,10) /perimeterInterger perimeter2P
iradius
38
Operation

• Operation
• Operation is a service that an object may be
  requested to perform
• By message passing
• Signature visibility returnType name(argument
  argumentType)
• Tagged value abstract
• constrain rgt0
• Visibility
• Private -
• Protected
• Public
• Naming
• Try to use active verbs
• Method
• A method can implement an operation
• The algorithm of a method may be indicated in a
  note attached to the operation entry.

method body
39
Object Diagram

• Built during analysis and design
• Illustrate data/object structures
• Specify snapshots
• Captures instances and links
• Developed by analysts, designers, and
  implementers
• Comparison
• Actor an entity outside the system to be
  modeled, interacting with the system
• Class an abstraction modeling entity in the
  problem domain, inside the system to be modeled
• Object a specific instance of a class

40
Object Diagram
41
Interface class

• Interface class describe the externally visible
  behavior of model elements
• Interface class is an abstract classes which
  define abstract operations
• Contain only operations
• Interface class can extend several other
  interfaces
• A common class can implement several interface
• The different interfaces do not contain
  homonymous signatures
• make the interface concept more powerful, to
  specify constraints for each signature
• Precondition
• Postcondition
• Invariants
• Exported exceptions

42
Interface class

• Realization relationship

ltltimplementsgtgt
ltltinterfacegtgt Sortable isEqual(String)Boolean
String isEqual(String)Boolean Length()Integer
String isEqual(String)Boolean Length()Integer
Sortable
43
Interface class

• dependency relationship
• SortedStringList as the interface user is only
  dependent on the operation of the String class

String isEqual(String)Boolean Length()Integer
ltltusegtgt
SortedStringList
Sortable
44
Extension Mechanisms

• Constraint
• Restrict the possible contents, states, or the
  semantics of a model element and which must
  always be satisfied
• Describes a condition or integrity rule
• Describe the legal set of values of a attributes,
  specify pre- or postconditions
• be formulated free text or a formula-like
  description

Project
Project
project Self.projectMembers-gt includes(self.projec
tLe)
has
has
consists of
Subset
Subset
consists of
1.. projectMembers
1.. projectMembers
projectLeader 1
projectLeader 1
Employee
Employee
Constraint with dependency relation
Constraint with OCL expression
45
Constraints

• OR

has ?
Domestic Address
Person
OR
Foreign Address
has ?

• Values

Rectangle a agt0 b bgt0

• Oredr

Person lastName firstName
1 contains ? 1..
ordered lastName
NameList
46
Tagged value

• user-defined, keyword/value pairs
• add specific additional properties
• allow individual instance of existing model
  elements to be extended by specific properties

abstract version 2.1 GeomFigure visible
Boolean readonly display( ) abstract remove(
) abstract
47
Stereotypes

• extend the metamodel by a new elements
• be applied to affect directly the semantic of
  model element
• apply the class, relationship, or package
• four types
• decorative look more visually appealing, e.g.
  ltltactorgtgt, ltltentitygtgt, ltltcontrolgtgt in use case
  diagram
• descriptive describe contexts of usage, e.g.
  ltltbusiness classgtgt, ltltprocess controlgtgt in class
  diagram
• restrictive ltltinterfacegtgt
• redefining metamodel modification

48
Notes

• be comments to a diagram or an arbitrary element
  in a diagram
• development state, version of a class, developer
  responsible for the class

Person birthDate Date /age
/age today birthDate
49
Package

• collections of model elements of arbitrary types
  which are used to structure the entire model into
  smaller, clearly visible units
• may contain different model elements, e.g. use
  cases and class

50
Chapter 9Class Diagram(Relational Elements)
51
Generalization/Specialization

• Generalization relationships denote inheritance
  between classes.
• The children classes inherit the attributes and
  operations of the parent class.

52
Generalization

• Disjoint default, inverse constraint of
  overlapping
• Overlapping for multiple inheritance to control
  combination of common properties from separate
  inheritance paths
• Complete all subclass are specified
• Incomplete further subclass are expected

53
Generalization
Vehicle name manufacture
overlapping
WindPoweredVehicle minWindForce
WaterVehicle draft
SailingBoat numOfSail
disjointSailingBoat waterVehicle.name windPoweredV
ehilcle.name waterVehicle.manufacture windPowerVeh
icle.manufacture draft
overlappingSailingBoat name manufacture draft
54
Specialization

• Extension add a new operation and attributes.
• Redefinition(overriding)
• retain the original interface
• but recode a particular method
• Restriction
• inherit a subset of operations / or tighten
• the type of attribute or operation output
• Reason for overriding
• to specify behavior that depends on the subclasse
• to tighten the specification of a feature.
• for better performance

55
Specialization
Specialization
class relationship
type relationship

• class membership
• by rule (predicate) (implicitly)
• a rule defines a condition for membership in a
  class all objects whose values satisfy the rule
  belong to the class.
• by enumeration (explicitly)
• an object has explicit class membership and the
  attributes flows from its class.

subtype
Extension
subclass
subclass
same type
Redefinition
subclass
supertype
Restriction
56
Associations

• Associations denote relationships between
  classes.
• cardinality number of elements
• multiplicity range of allowed cardinalities

ltltstereotypesgtgt RelationName ? constraint/propert
yValue
class A
class B
1
1
role b
role a
Assist ?
Faculty
Students
? Advice
? Teach
Take ?
Courses
57
Associations
TarifSchedule Enumeration getZones() Price
getPrice(Zone)
TripLeg

pricezone

many-to-many
Has ? capital
Country
City
1
1
nameString
nameString
1-to-1
Polygon
Point

1
1-to-many
xInteger yInteger
draw()
58
Associations

• recursive association
• qualified association

Employee name staffNo roomNo
clerk
manager 1
File fileName
Directory
Unqualified
Directory
file name
File
Qualified
59
Associations

• association constraints an association satisfies
  specific conditions
• derived associations

Person
Address
Has ? delete related object
1 ?belong to employer
Enterprise
Department
? works in
? /work for Employee.employer
Employee.department.employer
Employee
60
Attributed Associations

• attributed association an association with
  additional class properties
• association class a class with additional
  association properties

Person
Company
name address
name SSN address
WorkFor salary job title
61
Attributed Associations Example

• A route connect two city

City name
connect 1
1
route path search
62
N-ary Associations
project
Language
person
project
Language
Manager
person
63
Aggregation

• An aggregation is a special case of association
  denoting a consists of hierarchy.
• The aggregate is the parent class, the components
  are the children class.

order
Polygan
Point
64
Composition

• A solid diamond denote composition, a strong form
  of aggregation where components cannot exist
  without the aggregate.

3
2 1 1
65
Dependency

• Indicates a situation in which a change to the
  target element may require a change to the source
  element in the dependency.
• a class uses a specific interface of another
  class
• a class is dependent on another class
• an operation is dependent on a class
• a package is dependent on another package (a
  class in one of the package is dependent on a
  class in the other package)
• Example Person depends on House.
• House could be pass in as a parameter to some
  operation inside Person.

66
Refinement/realization

• realization is relation between an interface and
  its implementation
• refinement is relation between similar elements
  of different degrees of detail

String isEqual(String)Boolean Length()Integer
ltltimplementsgtgt

• refinement

Tariffing
Tariffing1
performance optimized calculation now running
on locally replicated data
67
Problem Statements An Example

• A person has a name, address, and social security
  number. A person may charge time to projects and
  earn a salary. A company has a name, address,
  phone number, and primary product. A company
  hires and fires persons. Person and Company have
  a many-to-many relationship.
• There are two types of persons workers and
  managers. Each worker works on many projects
  each manager is responsible for many projects. A
  project is staffed by many workers and exactly
  one manager. Each project has a name, budget, and
  internal priority for securing resources.
• A company is composed of multiple departments
  each department within a company is uniquely
  identified by its name. A department usually, but
  not always, has a manager. Most managers manage a
  department a few managers are not assigned to
  any department. Each department manufactures many
  products while each product is made by exactly
  one department. A product has a name, cost, and
  weight.

68
Class Diagram
Person name address SSN
1..
1..
work_for
1..
position
department name
charge_time
Worker
Manager
0..
1..
manage
staff
staff
1..
produce
0..
1..
1..
1..
69
Extended Entity Relation Diagram
70
Chapter 10Behavioral Diagram
71
Activity Diagrams

• A special case of a state chart diagram in which
  states are activities (functions)
• Purpose
• Model business workflows, flow control within a
  system, and operations
• Captures dynamic behavior (activity-oriented)
• Three types of states
• Action state
• Cannot be decomposed any further
• Happens instantaneously with respect to the
  level of abstraction used in the model
• Activity state
• Can be decomposed further
• The activity is modeled by another activity
  diagram
• object state

72
Activity Diagram Modeling Decisions
Object State
73
Activity Diagrams Modeling Concurrency

• Synchronization of multiple activities
• Splitting the flow of control into multiple
  threads

74
Activity Diagrams Swim lanes

• Actions may be grouped into swim lanes to denote
  the object or subsystem that implements the
  actions.

Dispatcher
FieldOfficer
75
Collaboration Diagram

• Captures dynamic behavior (message-oriented)
• Purpose
• Model flow of control
• Illustrate coordination of object structure and
  control

76
Collaboration Diagram

• Synchronization conditions
• simple, sequential accepted by receiver and
  processed completely
• synchronous the sender waits until the receiver
  has accepted the message
• restricted the exchange is aborted if the
  receiver does not immediately accept the message
• time-dependent the exchange is aborted if the
  receiver does not accept the message within a
  specific delay
• asynchronous end up in the waiting queue of the
  receiver

77
Sequence Diagram

• Used during requirements analysis
• To refine use case descriptions
• to find additional objects (participating
  objects)
• Used during system design
• to refine subsystem interfaces
• Classes are represented by columns
• Messages are represented by arrows
• Activations are represented by narrow rectangles
  to sent the message, and is as long as all nested
  activations
• Lifelines are represented by dashed lines
• Purpose
• Captures dynamic behavior (time-oriented) in
  terms of interactions.
• Model flow of control
• Illustrate typical scenarios
• Complement the class diagrams which represent
  structure.

78
Sequence Diagram
Object
Message
Activation
79
Sequence Diagrams Nested Messages
TicketMachine
Passenger
selectZone()
ZoneButton
TarifSchedule
Display
selectZone()
lookupPrice(selection)
insertCoins()
displayPrice(price)
pickupChange()
Dataflow
pickUpTicket()
80
Sequence Diagram
81
Sequence Diagram
82
Sequence Diagram
83
State Diagram

• Captures dynamic behavior (event-oriented)
• Purpose
• Model object lifecycle
• Model reactive objects (user interfaces, devices,
  etc.)

84
State Diagrams
State
Event
Initial state
Transition
button12Pressed
Final state
85
State Generalization

• Generalization is the or-relationship
• States may have substates that inherit the
  transition of their superstates.
• e.g.

SuperState contour
Super State (abstract state)
event1
substate2
substate1
event3
event2
Active
on-hook
Idle
off-hook
86
Chapter 11 Implementation Diagram
87
Component Diagram

• Captures the physical structure of the
  implementation
• Built as part of architectural specification
• Purpose
• Organize source code
• Construct an executable release
• Specify a physical database
• Developed by architects and programmers

88
Component Diagram

• Component. A component is a physical module of
  code, including
• source code library
• executable
• Types of components
• Component. A software module with well-defined
  interface.
• Subprogram. A collection of subroutines.
• Package specification and body. The
  implementation of a class.
• Specification a header file which contains
  function prototype information for the class,
  e.g., .JAVA file
• Body the code for the operations of the class.
• Task specification (e.g., .exe) and body.
  Independent threads of control,

89
Component Diagram
90
Component Diagram
91
Deployment Diagram

• Captures the topology of a systems hardware
• Illustrate the structure of the runtime system,
  including the configuration of runtime processing
  elements and the software components, processes,
  and objects that live on them.
• Built as part of architectural specification
• Purpose
• Specify the distribution of components
• Identify performance bottlenecks
• Developed by architects, networking engineers,
  and system engineers
• Example A browser-based three-tier account
  management system

92
Deployment Diagram
node
component
dependency
93
Deployment Diagram
94
Representing System Architecture
Logical View
Implementation View
Programmers Software management
Use Case View
Process View
Deployment View
System engineering
System topology Delivery, installation Communicat
ion
Conceptual
Physical
95
Process

• To concentrate only on a few notations
• Functional model use case diagram
• Static model class diagram
• Dynamic model sequence diagrams, and activity
  diagrams

Use case dia- gram desc- ription
Refined Class diagram
Class diagram
scenarios
Use case dia- gram desc- ription
Implementation diagram (package, component,
deployment diagram)
Activity diagram
96
Generic Approach to OO Development
Requirements
Analysis
Design
Implementation and Testing
Business Process Reengineering or Context Diagram
Deployment Diagram
State Diagrams
Screen or Web Pages
Activity Diagram
Component Diagram
Use Case Diagram with Descriptions
Sequence Diagram
Scenarios
Package Diagram
RDB or OODB
Ideal Object Model (MVC Model)
Class Diagram (Architectural Patterns)
Updated Sequence Diagram
Object Diagram
CRC Cards
(Design Patterns)
Collaboration Diagram
Java Bytecode
Elaborated Class Diagram
Basic process
Legend
Optional
Additional process, if any
97
Chapter 12 Object Constraint Language
98
Object Constraint Language(OCL)

• A simple formal language which allows additional
  semantics to be added to UML models.
• With the OCL
• Specify constraints of a model
• Indicate invariants, precondition, and
  postconditions of operations and similar
• Describe navigation paths of an object network.
• Simple examples
• employee.salary lt boss.salary
• person.age gt 18
• person.addresses-gt is Empty
• person.addresses-gt size
• employee-gt select(age gt 30)
• set operations

99
OCL

• Complex example

• CarRentalContract
• self.driver-gt forAll (d d.age gt18)
• CarRentalContract
• self.driver -gt select (d d.age lt 25
• and d.
  isMale)
• CarRentalContract
• self.driver -gtselect (d d .birthDate today)
  -gt firstName)
• CarRentalContract
• self.driver -gt forAll (d1, d2 p1 lt gtp2
• implies p1.customer p2.customer)

Car rental contract
Authorized drivers

Driver
100
OCL

• Precedence
• Dot operation(.)
• Unary operation(not)
• Binary operation(, and)
• Bracketing( and ) forces a different order

101
OCL

• The operations predefined for the basic types
• Types Operations
• Boolean and, or, xor, not, implies, if ..then
  ..else,
• Integer, Real ,(integer), (real), round
• Collection , s.size(number of elements of s),
  sum,
• includes, isEmpty, exists, forAll
• Set union, intersection, -, include, exclude,
  select,
• reject, collect, asSequence, asBag
• Bag union, intersection, include, exclude,
  select,
• reject, collect, asSequence, asSet
• Sequence append, prepend, first, last, at,
  include,
• exclude, select, reject, collect, asBag, asSet