What is UML

1
What is UML?

• Guidelines

Methodology
Philosophy
Models
Tool Support
Notations
Process
2
Object Oriented Analysis Design

• Late 80s - early 90s wave on Object Oriented
  Analysis and Design methods (OOAD)
• Most methods consist of a graphical modeling
  language and a process in the form of advice on
  what steps to take in doing development e.g.
  analysis, design, implementation
• In practice when people say they follow a method
  they usually mean that they use the notation
• Different processes are good for different
  clients and different systems, the method war
  is not necessary
• It is annoying when similar concepts have
  slightly different notation or vice versa,
  standardization of notation is useful

3
Unified Modeling Language

• The Unified Modeling Language(UML) unifies the
  notations of Booch, Rumbaugh (OMT) and Jacobson
  (OOSE)
• Notation is the graphical stuff in the different
  types of models, it is the syntax of the
  modeling language
• The UML is approved as a standard by the OMG and
  has become widely accepted in the IT industry
• The UML is a modeling language, not a software
  development process it intends to support
  different object oriented approaches to software
  production

4
Why do OOAD?

• The switch to OO is not easy, OO modeling
  languages do support to some degree the paradigm
  shift necessary for good OO solutions
• One of the biggest challenges in development is
  building the right system, OO modeling languages
  help in achieving good communication with
  customers and domain experts

5
An Outline Development Process
Inception
Construction
Elaboration
Transition
1 2 3 4 ...

• Inception describe the business rationale and
  scope of the project
• Elaboration collect more detailed requirements,
  do high level analysis and design to establish a
  baseline architecture and make a planning
• Construction iterative and incremental, each
  iteration builds a production quality software
  that satisfies a subset of the requirements
• Transition beta-testing, user training,
  performance tuning

6
Object Oriented Software Development
Implementation
Requirement Capturing
Design
Analysis

• Requirements Capturing what is going to be
  build?
• Analysis build conceptual model of the domain
  and write down use cases
• Design decisions on architecture, full
  specification of the objects static structure
  and behaviour
• Implementation the translation to a specific
  programming language

7
UML Diagrams

• Use Case diagrams
• Class and Object diagrams
• Interaction diagrams
• Sequence diagrams
• Collaboration diagrams
• State diagrams
• Activity diagrams
• Package diagrams
• Deployment and Component diagrams

8
Tool Support - CASE Tools

• Draw diagrams
• Act as repository
• Support navigation
• Multiuser support
• Generate code
• Reverse engineer
• Integrate with other tools

9
The Toll Road Example
10
The Toll Road Example (1)

• A PayDrive company manages a network of roads.
  The network consists of a number of road
  segments. Each road segment is delimited by two
  nodes that are typically described by their
  geographical location. The distance between the
  delimiting nodes of a road segment is known.
• Some of the nodes are equipped with access
  control stations and can be used to enter and
  leave the road network. Some of the nodes are
  equipped as service points (gas station,
  restrooms, etc.)
• A trajectory is a consecutive sequence of road
  segments. It starts and ends at nodes with access
  control.

11
The Toll Road Example (2)

• Customers can register with a PayDrive company
  and obtain up to three cards. Customers can use
  these cards to travel trajectories on the road
  network.
• Regular cards are valid for a given time period
  and invoices will be send for each use that is
  made of the card. The amount to be invoiced is
  computed from the length of the trajectory
  travelled and the unit price associated with the
  card.
• Besides the regular cards there exist a number
  of special cards. Minitrip cards are prepaid
  cards, valid for a given trajectory only. They
  expire when the trajectory is travelled. Season
  cards are also prepaid, they are valid for a
  given time period and give access to the whole
  road network

12
From Requirements Capturing to Analysis

• Discover the potential use cases for the system,
  the typical interactions users have with a system
  to achieve goals
• A use case is written as a couple of paragraphs
  of text, UML provides use-case diagrams
• Develop a conceptual domain model, explore the
  vocabulary of the domain, give a description of
  the world the system will fit in
• A conceptual UML class diagram is useful here and
  some UML activity diagrams can be useful when
  workflow processes are part of the users world

13
Analysis and Design Models

• The conceptual class diagram resulting from the
  domain analysis together with the use-cases
  constitutes an analysis model
• A design model realizes both the information in
  the domain concepts and the behavior in the use
  cases, it adds classes to actually do the work
  and provides some architecture
• A specification-perspective UML class diagram can
  be used here together with some UML interaction
  and/or state diagrams that show how classes
  implement use cases

14
Use Case Model Actors

• Actors ARE NOT part of the system they
  represent anyone or anything that must interact
  with the system.
• The book borrower borrows copy of book
• The librarian updates the catalog
• An actor may
• Only input information to the system
• Only receive information from the system
• Input and receive information to and from the
  system
• Actors read, create, destroy and modify
  information
• Actors are found in the problem statement and by
  conversations with customers and domain experts.
• A single actor may perform many use cases and one
  use case may have many actors performing it.

15
Use Case Model Use Cases (1)

• A use case models a dialogue between an actor and
  a system.
• a text editor make some text bold, create an
  index
• a library system borrow copy of book, update
  catalog
• A use case represents the functionality provided
  by the system, i.e. what capabilities will be
  provided to an actor by the system.
• The sum of all the use cases is the external
  picture of the system.
• A use case is a sequence of transactions
  performed by a system that yields a measurable
  result of values for a particular actor.

16
Use Case Model Use Cases (2)

• A use case may be small or large but achieves a
  discrete goal to some user.
• A use case typically represents a major piece of
  functionality that is complete from beginning to
  end. A use case must deliver something of value
  to an actor.
• Definition of a use case basic course of events,
  number of exceptional or alternative courses,...
• No standard defined by UML!!

17
Use Case Model Use Cases (3)

• Example of definition of a use case
• Name name used to refer to the use case
• Summary a short description
• Actors all actors involved
• Preconditions condition of the system at the
  start of the use case
• Description the complete description
• Exceptions special cases
• Result condition of the system at the end of the
  use case

18
The Toll Road Example Use Cases (1)

• A person can apply to register as a customer
• Some personal information must be put in and is
  registered by the system, the customer starts
  with a zero account
• A customer can apply for a card
• The system checks the account, when the credit
  limit is exceeded the card is refused, otherwise
  a new card is issued and the system registers
  this
• A customer can apply for a prepaid card
• The system checks the account, when the credit
  limit is exceeded the card is refused, otherwise
  a new card is issued and the system registers
  this
• The system prints an invoice for the new card
  and updates the customers account

19
The Toll Road Example Use Cases (2)

• A customer can (attempt to) travel a trajectory
  on a given date with a regular card
• The customer enters the road network using some
  node with access control
• The system checks the validity of the card and
  the customers account When ok, the system
  registers the node of entry and date of entry
  for the card and permits access When not ok,
  access is denied
• The customer leaves the road network at some
  other node with access control
• The system computes the total price, prints an
  invoice, updates the customers account and
  permits exit

20
The Toll Road Example Use Cases (3)

• A customer can (attempt to) travel a trajectory
  on a given date with a season card
• Is a variation on the previous use case, on exit
  no invoice is printed and the customers account
  is not updated
• A customer can (attempt to) travel a trajectory
  on a given date with a minitrip card
• Is an extension on the previous use case, the
  nodes of entry and exit are checked against the
  trajectory the card is made out for
• An engineer can update the road network
• A bookkeeper (or a accountant system) can
  register payment of invoices

21
Apply For Card
ltltincludesgtgt
Apply For Prepaid Card
Travel Trajectory With Regular Card
customer
Travel Trajectory With Season Card
Travel Trajectory With Minitrip Card
ltltextendsgtgt
Update Road Network
Register Payment Of Invoices
engineer
bookkeeper
22
Relationships on Use Case Diagrams Actor
Relationships

• The association relationship between an actor
  and a use case
• The participation of an actor in a use case.
• This is the only relationship between actors and
  use cases.
• The generalization relationship from an actor A
  to an actor B
• This indicates that an instance of A can
  communicate with the same kinds of use-case
  instances as an instance of B.

23
Relationships on Use Case Diagrams Use Case
Relationships

• The ltltincludesgtgt relationship allows to factor
  out a chunk of behavior that is similar across
  more than one use case to avoid copying of
  descriptions of that behavior
• The ltltextendsgtgt relationship provides a more
  controlled form of extending the behaviour of a
  use case than the generalization relationship.
  The base use case declares a number of extension
  points. The extending use case can only alter the
  behaviour at those extension points.
• The generalisation relationship indicates that
  one use case is a variation on another. It allows
  a specialised use case to change any aspect of a
  base use case

24
Analyze Risk
Price Deal
ltltincludesgtgt
Valuation
Trader
Capture Deal _________ Extension points After
creation of the deal
Request Catalog
ltltextendsgtgt
Limits Exceeded
SalesPerson
25
Use Case Relationships Rule of thumb

• Use include when you are repeating yourself in
  two or more separate use cases and you want to
  avoid repetition.
• Use generalization when you are describing a
  variation on normal behaviour and you wish to
  describe it casually.
• Use extend when you are describing a variation on
  normal behaviour and you wish to use the more
  controlled form, declaring your extension points
  in your base use case.

26
Exercises!!!
27
Object State, Behaviour and Identity (1)

• Representation of an entity
• Real-world
• Conceptual
• Something concrete or a concept
• gt Concept, abstraction, or thing with
  well-defined boundaries and meaning for an
  application.

28
Object State, Behaviour and Identity (2)

• State
• One of the possible conditions in which it may
  exist
• Changes over time
• Defined by a set of properties, with the values
  of the properties, plus the relationships the
  object has
• Behaviour
• How an object responds to requests
• Implemented by a set of operations
• Identity
• Each object is unique

29
Class

• Description of a group of objects with common
  properties (attributes), common behaviour
  (operations), common relationships to other
  objects and common semantics.
• A good class captures one and only one
  abstraction
• Classes should be named using the domain
  vocabulary

30
Packages

• How do you break down a large system into smaller
  systems?
• Group model elements together, for example
  classes
• Package is a collection of model elements, for
  example a collection of related packages and/or
  classes.
• Each package contains an interface, realized by
  its set of public classes.
• Rest of the classes in a package are
  implementation, i.e. do not communicate with
  classes in other packages.

31
Relationships between Packages

• Import a kind of access that specifies that the
  public contents of the target package enter the
  flat namespace of the source, as if they had been
  declared in the source
• Access specifies that the source package is
  granted the right to reference the elements of
  the target package.
• Generalization families of packages

32
(No Transcript)
33
Class and Object Diagrams

• A class diagram describes the types of objects in
  the system and the various kinds of static
  relationships that exist amongst them
• Association and subtype (generalisation
  /specialisation) are the two principal types of
  static relationships
• Class diagrams also show attributes and
  operations of a class and the constraints that
  apply to the way objects are connected
• An object diagram is a snapshot of the objects in
  a system at a point in time, is also called an
  instance diagram

34
Customer Name Address Account
CheckAccount UpdateAccount
Card ValidFrom ValidThrue UnitPrice Valid?
1 .. 3
1
registered-to
card-used
1

1
RoadSegment Distance
Node Description
begin
1

end
1 ..
ordered

1
Trajectory DateOfEntry PrintInvoice ComputeTotal


Access Control Node Enter Leave
entry

1

exit
35
a Card UnitPrice 4 ValidFrom1/1/00 ValidTo30/6/
01
a Customer Name Viviane Address
Brussels Account-500
registered-to
a Card UnitPrice 5 ValidFrom1/1/01 ValidTo31/12
/01
registered-to
a Customer Name Michel Address
Leuven Account0
registered-to
a Card UnitPrice 5 ValidFrom1/1/01 ValidTo30/6/
01
36
a Node Description Orleans
end
a RoadSegment Distance 90
begin
a Node Description Olivet
begin
A Trajectory DateOfEntry 1/4/01
a RoadSegment Distance 120
end
a Node Description Meung
begin
a RoadSegment Distance 20
end
a Node Description Mer
37
Associations

• Associations represent relationships between the
  instances of the classes
• Each association has two roles a role being a
  direction on the association
• A role can be explicitly named with a label, if
  there is no label the name of the target class is
  used
• A role has multiplicity, an indication of how
  many objects may participate in the given
  relationship. In general multiplicity indicates
  lower and upper bounds

38
Associations and Perspectives

• From the conceptual perspective associations
  represent conceptual relationships a user works
  for a single department, a department has several
  users working for it.
• Within the specification perspective associations
  represent responsibilities a user is responsible
  for knowing the department it works for, a
  department is responsible for knowing its users
  (employees). With good conventions interfaces can
  be deduced from the diagram.
• In an implementation model associations would
  show actual pointers a pointer from a user to
  the department it works for, a collection of
  pointers from a department to its users.

39
Navigation

• Arrows can be put on associations to indicate
  navigability
• Navigability does not serve a purpose in
  conceptual diagrams, they appear in the shift to
  specification and implementation
• In a specification model the arrows indicate
  a-symmetrical responsibilities a tool release
  knows its status, a status does not know the
  associated tool release(s).
• In an implementation diagram the arrows indicate
  pointer(s) from one to the other only a pointer
  from tool release to a status no pointer(s) back
  from status to tool release(s)

40
Customer Name Address Account
CheckAccount UpdateAccount
Card ValidFrom ValidThrue UnitPrice Valid?
1 .. 3
1
registered-to
card-used
1
Node Description
RoadSegment Distance
1

begin
1

end
1 ..
ordered

1
Trajectory DateOfEntry PrintInvoice ComputeTotal


Access Control Node Enter Leave
entry

1

exit
41
Navigation and Conventions

• When navigability is in one direction only the
  association is uni-directional
• When navigability is in both directions the
  association is bi-directional
• Associations without arrows are according to UML
  either bi-directional or the navigability is
  undecided decide on one of the interpretations
  for each project !
• Bi-directional associations imply the extra
  constraint that the two roles are the inverse of
  each other

42
Associations and Names

• Associations can be named
• Traditional data modelers use a verb phrase for
  an association name so that the relationship can
  be used in sentences is employed by is married
  to
• Object modelers prefer to use nouns for one or
  the other of the roles of the association, it
  corresponds better to responsibilities and
  operations employer wife husband
• Name an association when it improves
  understanding, avoid has or is related to

43
Attributes

• Attributes are similar to associations
• At the conceptual level, an attribute is just
  another notation for a single-valued association
• At the specification level, attributes imply
  navigability from the objects to the attribute
  only
• At the implementation level using an attribute
  implies that the objects contains their own copy
  of the attribute object, i.e. value rather than
  reference semantics for the type used as an
  attribute (strings, numbers, etc.)
• visibility name type defaultValue
• Notation exists for visibility, frozen, class
  scope

44
Operations

• Operations are the processes that a class knows
  to carry out
• At the specification level operations correspond
  to public methods on a type operations that
  simply manipulate attributes are not shown, they
  can be inferred
• In the implementation model private and protected
  operations may be shown as well C inspired
  visibility notation exists (public), -(private),
  (protected) the meaning of these indicators is
  often language dependent
• A query is an operation that gets a value without
  changing the systems state query constraint
  is used

45
Operations

• The full UML syntax for operations isvisibility
  name(parameter-list) return-type-expression
  property-string
• visibility is (public), (protected), or
  (private)
• name is a string
• parameter-list contains comma-separated
  parameters, syntax direction name type
  default valuedirection in, out, inout
• return-type-expression comma-separated list of
  return types
• property-string property values applying to the
  given operation

46
Derived Associations and Attributes

• Derived association and attributes are those that
  can be calculated from other attributes or
  associations
• the age of a person can be calculated from its
  date of birth
• On conceptual diagrams, the derived markers just
  remind one that the derivation (thus the
  constraint) exists
• In the specification perspective derived features
  indicate a constraint between values, not a
  statement about what is calculated or stored
  explicitly
• On implementation diagrams derived values are
  useful for annotating fields that are used as
  caches for performance reasons

47
Reference Objects and Value Objects

• For reference objects identity is important.
  There is usually one software object to
  designate one object in the real world. For value
  objects identity is less important, multiple
  value objects can reference the same real world
  object
• Reference objects are the same when they have the
  same identity, value objects are the same when
  they represent the same value
• Value objects are created and destroyed
  frequently but they should be immutable or
  sharing must be avoided
• Within UML attributes are usually used for value
  objects and associations are used for referencing
  reference objects

48
Customer Name string Address string Account
integer CheckAccount()boolean UpdateAccount(nin
teger) RegisterCard() void PrintAddress() void
Card ValidFrom Date ValidThrue Date UnitPrice
integer CardIdnumber Valid?(dDate)
boolean GetNewCardId() number GetCard(nnumber)
Card
1
1 .. 3
registered-to
Date Dayinteger Month integer Year
integer IsBefore(dDate) boolean
IsAfter(dDate) boolean Equal(dDate) boolean
Date is a utility class
49
Customer -Name string -Address string -Account
integer -CardsSet(Card) RegisterCard()void Ch
eckCredit()boolean query UpdateAccount(ninteg
er) PrintAddress() void
Card CardIdnumber ValidFrom Date ValidThrue
Date UnitPrice integer Registered-to
Customer Valid?(dDate) boolean SetValidFrom(dD
ate) void SetValidThue(dDate)
void SetUnitPrice(dDate) void GetValidFrom(dDat
e) boolean GetValidThue(dDate)
boolean GetUnitPrice(dDate) integer GetNewCardId
() number GetCard(nnumber)Card
Trajectory DateOfEntry Date Card-Used
Card /Customer Customer Entry
Node ExitNode CheckTrajectory()boolean PrintInv
oice () void
50
Generalisation

• Conceptually one class is a generalisation of
  another class if every instance of the latter is
  by definition an instance of the former
• Within a specification model, generalisation
  means that the interface of the subtype includes
  all elements of the interface of the supertype
• Generalisation at the implementation perspective
  is associated with inheritance in programming
  languages and thus with subclassing and not with
  subtyping

51
Abstract Classes

• An abstract class is a class with method
  declarations but no method bodies it serves
  essentially as an interface specification.
  Subclassing must provide the implementation (the
  method bodies) before instantiation
• For an abstract class or method, the UML
  convention is to italicize the abstract item or
  to use the abstract constraint

52
Card abstract Valid?
A regular card is valid on a given date if the
date is between the validfrom and the validthrue
Prepaid Card PricePaid
A minitrip card is valid if the trajectory
matches
Season Card ValidFrom ValidThrue Valid?
Minitrip Card Used? Trajectory Valid? Invalidate
What to do if trajectory is exited
printinvoice, invalidate, nothing?
53
Interfaces

• OrderReader needs DataInput
• DataInputStream implements DataInput and
  InputStream interfaces and is subclass of the
  latter.
• If the DataInput interface changes, the
  OrderReader may also have to change.

54
Aggregation and Composition

• Aggregation is the part-of relation
• a car has an engine and wheels as its parts
• The differentiation between aggregation and
  association is a heavily debated issue (often
  domain dependent)
• a company is not the aggregation of its
  customers
• Composition is a stronger variety of aggregation,
  the part objects belong to one whole only, they
  live and die with the whole a deletion of the
  whole cascades to the parts
• A 1..1 multiplicity on an association or
  aggregation also implies a cascading delete

55
Constraint Rules

• The basic constructs of association, attribute
  and generalisation do specify important
  constraints but they cannot indicate every
  constraint over a problem domain
• Constraint can be written in a class diagram
  between either using informal natural
  language or using a more formal notation cfr.
  OCL

56
Customer Name string Address string DateOfBirth
Date /Age()number
Node Description
RoadSegment Distance
1

age() gt 18
begin
1

end
begin ltgt end
Traffic Light
1
Access Control Station
1..12
Access Control Node
Barrier
1
Card Reader
1
57
Collections for Multi-Valued Roles

• A multi-valued role is one whose multiplicitys
  upper bound is greater that 1
• The convention is that multi-valued roles are
  thought of as sets no ordering is implied and no
  target object appears in the role more than once
• This default can be changed by using constraints
  ordered, bag, ordered bag, hierarchy,
  dag

58
Frozen Constraint

• frozen is a constraint that can be applied to
  an attribute, a role or a class
• On an attribute or role it indicates that the
  value of that attribute or role may not change
  during the life time of the source object, when
  applied to a class it indicates that all roles
  and attributes associated with that class are
  immutable
• The value is set at object creation time expect
  an argument in a constructor, do not expect
  operations that update the value
• People make mistakes, watch out with this
  constraint in a specification model

59
Stereotypes

• A stereotype indicates a high level
  classification
• Jacobson for example distinguishes three types of
  classes interface objects, control objects, and
  entity objects with a special icon for each of
  them
• UML uses stereotypes as a general language
  extension mechanism ltlt some type gtgt
• Within class diagrams there might be stereotypes
  for classes, associations and generalisations

60
Multiple and Dynamic Classification

• Single, static classification of objects is too
  restrictive for conceptual modeling
• In multiple classification an object may be
  described by several types that are not
  necessarily connected by inheritance (/
  multiple inheritance)
• Subtypes with the same discriminator (role name)
  are disjoint
• The discriminator can be marked as complete
• Not all subtype combinations are legal
• Dynamic classification allows objects to change
  type within the subtype structure, it is noted
  with ltltdynamicgtgt

61
(No Transcript)
62
complete
Male
sex
Customer
Female
ltltdynamicgtgt
type
Frequent Customer
Corporate Customer
Customer Name string Address string Sex
Male,Female PrintAddress()void
Transport Customer
63
Association Class

• Association Classes allow to add attributes,
  operations and other features to an association
• It is useful to model information that belongs
  with the association itself and not with any of
  the two participating objects
• It adds an extra constraint in comparison to the
  more general case of having a full class in
  between the two participating classes there can
  be only one instance of the association class
  between any two participating objects

64
(No Transcript)
65
Company ExistsSince Date
Node Description
RoadSegment Distanceinteger OpenSinceDate
1



begin
owns
owner
1

end
Ownership Since Date
66
Qualified Associations

• A qualified association is the UML equivalent of
  programming constructs like associationlists,
  maps and dictionaries
• A qualifier is drawn with the source class, a
  multiplicity can be shown on the target role
• In a conceptual model it indicates a constraint
• In a specification model it indicates that access
  to the target role is through a keyed-lookup
• In an implementation model it shows the use of
  an associative data structure

67
(No Transcript)
68
Node Description
Company ExistsSince Date
Description
Access Control Node Enter Leave
Service Node
0..1
manages
69
Parameterised Class

• Is inspired by the notion of parameterised class
  (template) from C
• Is a useful concept when working with collections
  in static typed languages
• In UML a parameterised class gets a template
  parameter
• Either C alike syntax in the name of a class or
  a ltltbindgtgt stereotype on a refinement relation
  can be used to show a bound element
• Using a bound element is different from
  subtyping, it is about restricting the type only,
  no new features can be added

70
T
T
Sequence Insert(T) Remove(T)
Sequence Insert(T) Remove(T)
RoadSegment Distance
ltltbindgtgt ltRoadSegmentgt
RoadSequence Distance
SequenceltRoadSegmentgt
1 ..
ordered
1


Trajectory DateOfEntry PrintInvoice ComputeTotal

ordered
Trajectory DateOfEntry PrintInvoice ComputeTotal


Trajectory DateOfEntry PrintInvoice ComputeTotal

71
Advanced Relationship Dependency

• using relationship
• Change in the specification of one thing may
  affect another thing that uses it.
• 17 stereotypes that can be applied to dependency
  relationships.

72
Exercises!!!
73
Interaction Diagrams

• Interaction diagrams are models that describe how
  groups of objects collaborate in some behavior
• Typically, an interaction diagram captures the
  behavior of a single use case
• There are two kinds of interaction diagrams
  sequence diagrams and collaboration diagrams
• Both types of diagrams show a number of example
  objects and the messages that are passed between
  these objects

74
Sequence Diagrams (1)

• Objects are shown as boxes on top of a lifeline
  using the UML object naming scheme a Classname
  or ObjectName ClassName
• Messages are represented by arrows between the
  lifelines of two objects. Messages are labeled
  with the message name and optional arguments.
• The order in which messages occur is shown top to
  bottom
• Self-delegation or self-call, a message that an
  object sends to itself, is shown by an arrow back
  to the same lifeline

75
Sequence Diagrams (2)

• Control information can be added
• Conditions, ex. checkOk the message is sent
  only if the condition is true
• Iteration markers, ex DoSomething shows that
  the message is sent many times to multiple
  receiver objects
• Returns can be shown with a dotted line, they can
  be omitted to avoid cluttering the diagram
• To show when an object is active an activation
  box can be used, it makes the diagram more
  difficult to draw but easier to understand
• Object deletion can be shown with a large x

76
(No Transcript)
77
(No Transcript)
78
Concurrent Processes in Sequence Diagrams

• Activation boxes appear explicitly on the
  lifeline to indicate either executing or waiting
  for a return of a synchronous message
• Stick arrowheads indicate asynchronous messages
• Create a new thread (arrow to top of activation)
• Create a new object (arrow to object box)
• Communicate with a thread that is already running
• Consequences of self-delegations can be shown
  more clearly through stacked activations
• Two scenarios for one use case can be drawn in
  two diagrams or on one diagram using conditional
  logic

79
a Card
an Access Control Node
a Customer
a Barrier
a Traffic Light
a Card Reader
Enter
Read
isValidValid?
accountOKCheckAccount
isValid And accountOK
New
Open
PutGreen
after 30 sec PutRed
80
a Card Reader
a Card
an Access Control Node
a Customer
Read
Enter
CardValid?
AccountOk?
CardValid
ChecksComplete?
AccountOk
ChecksComplete?
a Trajectory
81
Collaboration Diagrams

• Example object are shown as icons using the UML
  object naming scheme a Classname or ObjectName
  ClassName
• Arrows indicate messages sent and sequencing is
  indicated by numbering the messages
• The simple numbering scheme shows the overall
  sequence only
• The decimal numbering scheme makes clear which
  operation is calling which other operation
• Control information is as in the sequence diagram

82
Collaboration diagrams Links

• Link is an instance of an association.
• Role name may be shown at each end of the link.
• Association name may be shown near the path
  (underlined).
• Stereotype may be attached to the link end to
  indicate various types of implementation
• Association
• Parameter (method parameter)
• Local (local variable of a method)
• Global (global variable)
• Self (self link)

83
a Card
8. GetUnitPrice
a Road Segment
2. isValidValid?
7. GetDistance
1. Enter
4. isValid And accountOK New 6. ComputeTotal
an Access Control Node
a Trajectory
5. Leave
9. PrintInvoice
3. accountOKCheckAccount
10. UpdateAccount
a Customer
84
a Card
2.1.2. GetUnitPrice
a Road Segment
1.1. isValidValid?
2.1.1. GetDistance
1. Enter
1.3. isValid And accountOK New 2.1. ComputeTotal
an Access Control Node
a Trajectory
2. Leave
2.2. PrintInvoice
1.2. accountOKCheckAccount
2.3. UpdateAccount
a Customer
85
Comparing Sequence and Collaboration Diagrams

• Sequence diagrams put more emphasis on sequence
• Collaboration diagrams allow to position objects
  corresponding to their static relation
• Either form is served by simplicity when
  representing much conditional or looping behavior
  the techniques break down
• When there is a lot of conditional behavior, it
  is advisable to use separate diagrams for each
  scenario
• Interaction diagrams are good for looking at the
  behavior of several objects within a single use
  case they are not good for precise definition of
  behavior

86
A well-structured interaction diagram

• Is focused on communicating one aspect of a
  systems dynamics
• Contains only those elements that are essential
  to understanding that aspect.
• Provides detail consistent with its level of
  abstraction and should expose only those
  adornmenst that are essential to understanding.
• Is not so minimalist that it misinforms the
  reader about semantics that are important.

87
Exercises!!!
88
State Diagrams

• State diagrams describe all the possible states
  an object can get into and how the objects state
  changes as a result of events that reach the
  object
• State diagrams are drawn for a single class to
  show the lifetime behavior of a single object
• Use state diagrams for those classes that exhibit
  interesting behavior only
• UI and control objects are popular candidates

89
States

• State is a condition or situation during the life
  of an object during which it
• satisfies some condition,
• performs some activity or
• waits for some event.
• Object remains in a state for a finite amount of
  time.

90
States

• Different parts of a state
• Name textual string a state may be anonymous
  meaning that it has no name.
• Entry/exit actions actions executed on entering
  and exiting the state resp.
• Internal transitions transitions that are
  handled without causing a change in state
• Substates nested structure of a state,
  involving disjoint (sequentially active) or
  concurrent (concurrently active) substates

91
Initial and Final States

• Initial state indicates the default starting
  place for the state machine or substate.(filled
  black circle)
• Final state indicates that the execution of the
  state machine or the enclosing state has been
  completed(filled black circle surrounded by an
  unfilled circle)
• Initial and final states are pseudo-states.
  Neither may have the usual parts of a normal
  state, except for a name.

92
Transitions

• Transition is a relationship between two states
  indicating that
• an object in the first state will perform certain
  actions and
• enter the second state when a specified event
  occurs and specified conditions are satisfied.
• On such a change of state, the transition is said
  to fire.

93
Transitions

• Transition has 5 parts
• Source state the state affected by the
  transition if an object is in the source state,
  an outgoing transition may fire when the object
  receives the trigger event of the transtion and
  if the guard condition is satisfied
• Target state the state that is active after the
  completion of the transition

94
Transitions

• Event Guard / Action
• Event trigger the event whose reception by the
  object in the source state makes the transition
  legible to fire, providing the guard condition is
  satisfied.
• Guard condition a boolean expression, evaluated
  when the transition is triggered byt the
  reception of the event trigger if the expression
  evaluates True, the transition is legible to
  fire, if the expression evaluates to False, the
  transition does not fire and if there is no other
  transition that could be triggered by the same
  event, the event is lost.
• Action an executable atomic computation that
  may directly act on the object

95
Events

• Event-name ( comma-separated-parameter-list )
• parameter-name type-expression
• Elapsed-time eventafter(5 seconds)after(10
  seconds since exit from state A)
• Condition becoming true is shown with the keyword
  when followed by a boolean expression.
  (continuous test for the condition until it is
  true)
• Transitions without an Event within their label
  occur as soon as the activity associated with the
  state is finished

96
Guard Condition

• Boolean expression enclosed in square brackets
  and placed after the trigger event.
• Evaluated only after the trigger event for its
  transition occurs.
• It is possible to have multiple transitions from
  the same source state and with the same event
  trigger, as long as those conditions do not
  overlap.
• Within the boolean expression, it is possible to
  include conditions about the state of an object.

97
Action

• An action is an executable atomic computation
• Actions may include
• operation calls to the object that owns the state
  diagram or to other visible objects),
• creation and destruction of another object.
• Actions is atomic, i.e. it cannot be interrupted
  by an event and must run to completion. An
  activity may be interrupted by other events!

98
Ok / New, PutGreen, Open
Enter
idle Do/display welcome mess
checking Do/Checks Do/display wait mess
not Ok
refusing-access Do/display refusal mess
after 30 sec
99
(No Transcript)
100
AccountOk / New, PutGreen, Open
Enter / CardOk?
idle
checking-card
CardOk / AccountOk?
after 30 sec
checking-account
not CardOk
refusing-access
not AccountOk
101
Advanced States and Transitions

• UMLs state diagrams have some advanced features
  helping to
• Manage complex behavioral models
• Reduce the number of states and transitions
• Codify a number of common and somewhat complex
  idioms.
• Entry/exit actions, internal transitions,
  activities.

102
Entry and Exit Actions

• Dispatch the same action whenever you enter a
  state
• In the symbol for the state, include an entry
  action marked by the keyword event entry
• Dispatch the same actions whenever you leave a
  state
• In the symbol for the state, include an exit
  action marked by the keyword event exit
• Entry and exit actions may not have arguments or
  guard conditions.

103
Internal Transitions

• Events occuring inside a state but handled
  without leaving the state.
• Difference with self-transitions!!
• Self-transition event triggers the transition,
  state is left, an action (if any) is dispatched,
  same state is reentered. A self-transition
  dispatches the states exit action and dispatches
  the states entry action.
• Internal transition if event is triggered, the
  corresponding action is dispatched WITHOUT
  leaving and then reentering the state!!
• Internal transitions may have events with
  parameters and guard conditions, internal
  transitions are essentially interrupts.

104
Activities

• Ongoing activity while the object is in a state,
  waiting for an event to occur, i.e. while in a
  state, the object does some work that will
  continue until it is interrupted by an event.
• Do transition specifying the work that is to be
  done inside a state after the entry action is
  dispatched.
• The activity of a do transition might
• name another state machine,
• specify a sequence of actions.
• Actions are never interruptible but sequences of
  actions are.

105
Sensorwarning / Blockmotor
Stop-bell
ringing
silent
opening Do/activate-motor-till-closed Entry/Ring-b
ell Exit/Stop-bell
Ring-bell
Open
closed
open
closing Do/Activate-motor-till-open SensorWarning/
Blockmotor Entry/Ring-bell Exit/Stop-bell
Close
106
Substates

• Superstates can be introduced to group a number
  of states. All substates inherit any transition
  on the superstate. The use of superstates makes
  diagrams often more readable
• Concurrent state diagrams combine different
  independent behaviors of a given object. An
  object can be in different states, each from a
  concurrent section in the diagram

107
Sequential Substates

• Sequential substates composite states can be
  introduced to group a number of states.
• If the object is in a composite state, it is in
  only one of its substates at a time. (substates
  are disjoint)
• Transition leading out of a composite state may
  have its source the composite state or a
  substate. In either case, control first leaves
  the nested state, then it leaves the composite
  state.
• From a source outside a composite state, a
  transition may target the composite state or a
  substate.

108
Sequential Substates (continued)

• If the target is the composite state, this must
  include an initial state to which control passes
  after entering the composite state and after
  dispatching its entry action (if any).
• It the target is a substate, control passes to
  the substate after dispatching the entry action
  (if any) of the composite state and then the
  entry action (if any) of the substate.

109
AccountOk / New, PutGreen, Open
Cancel
Enter / CardOk?
idle
Cancel
checking-card
CardOk / AccountOk?
Cancel
after 30 sec
checking-account
not CardOk
refusing-access
not AccountOk
110
AccountOk / New, PutGreen, Open
Cancel
idle
Enter / CardOk?
active
checking-card
CardOk / AccountOk?
after 30 sec
checking-account
not CardOk
refusing-access
not AccountOk
111
Stop-bell
ringing
silent
opening Do/activate-motor-till-closed Entry/Ring-b
ell Exit/Stop-bell
Ring-bell
Open
closed
open
closing Do/Activate-motor-till-open Entry/Ring-bel
l Exit/Stop-bell
Close
112
Concurrent Substates

• These substates let you specify two or more state
  machines that execute in parallel in the context
  of the enclosing object.
• If one concurrent substate reaches its final
  state before the other, control in that substate
  waits at its final state. When both nested state
  machines reach their final state, control from
  the two concurrent substates joins back in one
  flow.

113
/ New, PutGreen, Open
idle
Cancel
Enter
checking
CardOk?
checking-card
CardOk
AccountOk?
checking-account
AccountOk
114
Concurrent Substates (continued)

• Transition to a composite state decomposed into
  concurrent substates, control forks inot as many
  concurrent flows as there are concurrent
  substates.
• Transition from a composite substate decomposed
  into concurrent substates, control joins back
  into one flow.
• If all concurrent substates reach their final
  state, or if there is an explicit transition out
  of the enclosing composite state, control joins
  back into one flow.

115
Well-structured state machine (1/2)

• One state machine represents the dynamic aspects
  of an individual object, representing e.g. an
  instance of a class, a use case or the system as
  a whole.
• Is simple and therefore should not contain any
  superfluous states or transitions.
• Has a clear context and therefore may have access
  to all the objects visible to its enclosing
  object.
• Is efficient and therefore should carry out its
  behavior with an optimal balance of time and
  resources required by the actions it dispatches.

116
Well-structured state machine (2/2)

• Is understandable and therefore should name its
  states and transitions from the vocabulary of the
  system.
• Is not nested too deeply.
• Uses concurrent substates sparingly.

117
Exercises!!!