OOSD UML

1
OOSD - UML

• Based on Martin Fowler UML Distilled
• Viviane Jonckers

2
Introduction - Chapter 1

• Guidelines

Methodology
Philosophy
Models
Tool Support
Notations
Process
3
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

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

6
Unified Modeling Language ways of using it (1)

• As a sketch -gt selectivity, exploration
• High level diagrams to help communicate some
  aspects of a system
• Can be used in 2 directions
• Forward engineering draw UML diagram before
  writing code, discuss and communicate ideas and
  alternatives about the software that needs to be
  written
• Reverse engineering build diagram from existing
  code, use sketches to explain how some part of
  the software works
• Sketches are informal and dynamic, on whiteboard
  or with lightweight drawing tool
• UML diagrams in books are typically sketches

7
Unified Modeling Language ways of using it (2)

• As a blueprint -gt completeness, definition
• Complete detailed design with all design
  decisions laid out so that a programmer can code
  from it straightforwardly
• Can also be used in 2 directions
• Requires more sophisticated tools
• Forward engineering tools support diagram drawing
  and back it up with a repository to hold the
  information
• Reverse engineering tools read source code,
  interpret from it into the repository and
  generate diagrams
• Round-trip tools can do both forward and reverse
  engineering
• Tripless tools treat diagrams as a viewport on
  the code

8
Executable UML

• Many CASE tools do some kind of code generation
  from UML diagrams which automates building part
  of the system
• When all of the system can be specified in the
  UML and then compiled to executable source code
  UML becomes a programming language, the UML model
  becomes the source code
• Not yet realised!!!
• Skeleton code generation is around
• How to model behavioural logic remains a problem.
  UML 2 offers three ways of behavioral modeling
  Interaction, state and activity diagrams. Detail
  needed to allow automatic code generation wipes
  out the advantages of using a visual modeling
  language

9
Different views on UML for modeling

• Software Perspective (implementation perspective)
• elements in UML map directly to elements in a
  software system
• Conceptual Perspective (domain perspective)
• represents a description of the concepts of a
  domain of study

10
Notations and Meta-Models

• A language
• Concrete syntax (notation)
• Abstract syntax (defining concepts of the
  language)
• Semantics (meaning of the concepts)
• The UML
• Diagrams (concrete syntax)
• Class diagrams (abstract syntax)
• English and OCL (semantics)

11
Meta-Model
12
Diagrams
13
Approach of this course

• Intuitive approach
• Emphasise legal diagrams
• For more information, consult
• http//www.uml.org/

14
Development process

• UML emerged from a bunch of OO analysis and
  design methods. Each method has its own graphical
  modeling language and a process.
• the groups involved in the UML initiative could
  agree on a graphical notation but NOT on a
  process
• it's important to see how modeling techniques fit
  into a process...
• UML can be used with any process

15
Iterative and Waterfall Process

• Both break down a project into smaller chunks
• Waterfall style breaks down a project based on
  activity
• E.g. analysis, design, coding, testing, etc
• Backflow to previous stages can be necessary
• Iterative style breaks down a project by subsets
  of functionality
• E.g. per iteration do a complete software life
  cycle for a subset of the requirements
• Hybrid Approaches are also possible
• Example staged delivery -gt analysis and design
  first (waterfall) and coding and testing divided
  up (iterative)

16
Waterfall Process
17
Waterfall Process with backflow
18
Iterative Process (Spiral model - Incremental)
19
Good Practices

• Avoid using pure waterfall process Difficult to
  see if project is going in the right direction
• Time boxing set fixed length of time on each
  iteration
• Automatic Regression Tests use of testing
  framework to detect bugs and broken functionality
  (xUnits)
• Refactoring use a disciplined technique for
  changing existing software
• Continuous integration keep a team in sync using
  automatic build processes in order to quickly
  detect inconsistencies at integration time

20
Predictive Planning

• Waterfall process endures due to desire for
  predictability
• Predictive Planning
• Do work early in the project
• First stage comes up with plans and it is
  difficult to predict
• In Second stage much more predictable the actual
  development takes place based on the plans
• Not necessarily black and white. As the project
  goes on you get more predictability
• Requirement Churn changes in requirements in
  later stages
• Can mess up the planning
• Freezing of requirements can be a solution. Risk
  -gt deliver a system that does not correspond to
  the users needs

21
Predictive and Adaptive Planning (contd)

• Two directions
• More effort in requirement process itself -gt more
  accurate reqs.
• Requirement churn is unavoidable -gt adaptive
  planning
• While predictability is desirable (fixed scope,
  fixed price) it may be too difficult to come up
  with a precise, accurate and stable set of
  requirements
• Statement Predictivity is an illusion change
  is a constant in a software project
• Make controllable projects instead of predictable
  projects

22
Agile Processes

• Agile covers many processes
• Examples
• Extreme Programming, Scrum, Feature Driven
  Development,
• Strongly adaptive
• Quality of the people on the project is the most
  important factor
• Low in ceremony

23
Agile Software Development Manifesto
We are uncovering better ways of developing
software by doing and helping others do
it. Through this work we have come to
value Individuals and interactions over
processes and tools Working software over
comprehensive documentation Customer
collaboration over contract negotiation Responding
to change over following a plan That is, while
there is value in the items on the right, we
value the items on the left more. The Manifesto
for Agile Software Development
24
Rational Unified Process (RUP)
Inception
Transition
Elaboration
Construction

• Process framework tailor it for a particular
  projects needs
• Iterative process
• Inception initial evaluation of a project,
  decide whether to commit enough funds to do an
  elaboration phase.
• Elaboration identifies primary use cases and
  builds software in iterations. At the end
  requirements, found and resolved major risks to
  the project.
• Construction developing enough functionality to
  release
• Transition deployment, user training,
  performance tuning

25
(No Transcript)
26
Fitting UML into a Development Process
Implementation
Requirement Capturing
Design
Analysis

• Requirements Analysis what the users and
  customer want the system to do?
• Use cases describing interaction between people
  and system
• Conceptual class diagram building a vocabulary
• Activity diagrams showing the workflow of an
  organisation
• State diagram showing life cycle of a concept

27
Fitting UML into a Development Process (contd)

• Design decisions on architecture, full
  specification of the objects static structure
  and behaviour
• Get more technical
• Class diagrams from a software perspective
• Sequence diagrams for common scenarios
• Package diagrams showing large-scale organisation
  of the software
• State diagrams for classes with complex life
  histories
• Deployment diagrams to show the physical layout
• Implementation the translation to a specific
  programming language

28
Fitting UML into a Development Process (contd)

• Documentation
• UML diagrams for an overall understanding of a
  system
• Highlighting the most important parts of the UML
• Package diagram as road map
• Deployment diagram as high-level physical picture
• Class diagram supported by interaction diagrams
  showing most important interactions
• State diagrams for classes exposing complex
  life-cycle behaviour
• Understanding Legacy Code

29
Scope of this course

• Guidelines

Methodology
Philosophy
Models
Tool Support
Notations
Process
30
UML Diagrams

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

31
Tool Support - CASE Tools

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

32
The Toll Road Example
33
The Toll Road Example

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

34
The Toll Road Example (contd)

• 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

35
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
• Iterative process of adding more technical
  details to the diagrams

36
Use Cases

• 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 scenario is a sequence of steps describing an
  interaction between a user and a system.

37
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.
• A use case is a set of scenarios tied together by
  a common user goal.

38
Actors

• Users are referred to as actors
• An actor is the role that a user plays with
  respect to the system.
• Actors carry out use cases
• 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

39
Actors

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

40
Use Cases in the UML

• Definition is rather sparse
• No description on how content of a use case must
  be captured
• Only use case diagram
• How use cases are related
• NOT the content

41
Use Case Content

• 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

42
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

43
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

44
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

45
Register as a customer (1)

• Name Register as a customer
• Summary a person can apply to register as a
  customer of the toll road company
• Actors person
• Precondition the involved person is not yet a
  customer of the toll road company

46
Register as a customer (2)

• Description
• the persons name and
• address is asked,
• an account and password are asked, the password
  needs to be confirmed,
• the e-mail address is asked
• the information is registered by the system,
• an e-mail is sent to the person with the
  necessary information
• the account of the new customer is zero
• Result the person in question is now a customer
  with account zero

47
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
48
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.

49
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

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

51
Levels of Use Cases

• System use case interaction with software
• Business use case how business responds to a
  customer
• Levels
• Sea-level use cases represent the core use cases
• Fish-level use cases are only included by
  sea-level use cases
• Kite-leve use cases show how sea-level use cases
  fit into the wider business interactions.

52
When to Use Use Cases

• Help understand functional requirements of a
  system
• Use cases represent external view of the system
• Concentrate on the use cases content
• Do not make it too complicated!!
• Use cases serve as issues of discussion!

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

54
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

55
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

56
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

57
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
58
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
59
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
60
Properties

• Structural features of a class
• One concept, two notations
• attributes,
• associations.

61
Attributes (1)

• visibility name type multiplicity default
  property-string
• Example
• Name String 1 "Untitled" readOnly
• The visibility marker indicates whether the
  attribute is public () or private (-)
• The name of the attribute roughly corresponds to
  the name of a field in a programming language.

62
Attributes (2)

• The type of the attribute indicates a restriction
  on what kind of object may be placed in the
  attribute. (cf. the type of a field in a
  programming language)
• Multiplicity (see slide 19)
• The default value is the value for a newly
  created object if the attribute isn't specified
  during creation.

63
Attributes (3)

• The property-string allows you to indicate
  additional properties for the attribute.
• In the example, readOnly is used to indicate
  that clients may not modify the property.
• Other properties (see slide 42)

64
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

65
Multiplicities

• Multiplicity of a property is an indication of
  how many objects may fill the property
• Most common 1, 0..1,
• Multiplicities are defined with a lower and an
  upper bound
• Optional implies a lower bound of 0.
• Mandatory implies a lower bound of 1 or possibly
  more.
• Single-valued implies an upper bound of 1.
• Multivalued implies an upper bound of more than
  1 usually .

66
Navigation

• 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

67
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
68
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
  implementation
• 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)
• In general the arrows indicate a-symmetrical
  responsibilities a trajectory knows the card
  used, a card does not know the associated
  trajectory(s).

69
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

70
Operations

• Operations are the actions that a class knows to
  carry out
• visibility name (parameter-list) return-type
  property-string
• The visibility marker is public () or private
  (-) (see slide 54).
• The name is a string.
• The parameter-list is the list of parameters for
  the operation.
• The return-type is the type of the returned
  value.
• The property-string indicates property values
  that apply to the given operation.

71
Parameters

• direction name type default value
• The name, type, and default value are the same as
  for attributes.
• The direction indicates whether the parameter is
  input (in), output (out) or both (inout). If no
  direction is shown, it's assumed to be in.

72
Generalisation

• Conceptually one class is a generalisation of
  another class if every instance of the latter is
  by definition an instance of the former
• With a software perspective, the obvious
  interpretation is inheritance a season card is a
  subclass of a prepaid card.
• The subclass inherits all the features of the
  superclass and may override any superclass
  operations.
• Substitutability it must be possible to
  substitute a season card within any code that
  requires a prepaid card.

73
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?
74
Dependency

• between two elements if changes to the definition
  of one element (the supplier) may cause changes
  to the other (the client)
• UML allows to depict dependencies between all
  sorts of elements.
• Many varieties of dependency, each with
  particular semantics and keywords.
• Minimize dependencies and watch out for cycles!

75
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 cf. OCL

76
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

77
Keywords

• Reduce the number of symbols and use keywords
  instead
• If you need a modelling construct that is similar
  to an existing UML construct, add a keyword to
  the existing UML construct.
• Jacobson for example distinguishes three types of
  classes interface objects, control objects, and
  entity objects with a special icon for each of
  them
• Keywords are usually shown as text between
  guillemets ltlt some type gtgt
• Within class diagrams there might be keywords for
  classes, associations and generalisations

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

80
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
• On implementation diagrams derived values are
  useful for annotating fields that are used as
  caches for performance reasons

81
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

82
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
83
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
84
Abstract Classes and Interfaces

• 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
• An interface is a class that has no
  implementation, i.e all its features are abstract
• An interface is marked with the keyword
  ltltinterfacegtgt
• Classes have two kinds of relationships with
  interfaces providing and requiring

85
ltltInterfacegtgt Collection equals add
interface
Abstract class
Trajectory Roadsegments
Abstract List equals add get
ltltInterfacegtgt List get
Abstract method
Implementation (provides interface)
Dependency (requires interface)
ArrayList add get
overriding
86
Trajectory Roadsegments
ArrayList
List
Collection
requires
provides
87
Static Operations and Attributes

• Operations or attributes that apply to a class
  rather than to an instance are referred to as
  static.
• Equivalent to static members in C-based languages
• Static features are underlined on a class diagram.

88
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

89
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

90
Node Description
Company ExistsSince Date
Description
Access Control Node Enter Leave
Service Node
0..1
manages
91
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)
• Place each generalisation relationship into a
  generalisation set and label the set with a
  discriminator.
• Generalisation sets are by default disjoint
• The discriminator can be marked as complete
• Dynamic classification allows objects to change
  type within the subtype structure, it is noted
  with ltltdynamicgtgt

92
complete
Male
sex
Customer
Female
ltltdynamicgtgt
type
Frequent Customer
Corporate Customer
Customer Name string Address string Sex
Male,Female PrintAddress()void
Transport Customer
93
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

94
Company ExistsSince Date
Node Description
RoadSegment Distanceinteger OpenSinceDate
1



begin
owns
owner
1

end
Ownership Since Date
95
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

96
T
T
Sequence Insert(T) Remove(T)
Sequence Insert(T) Remove(T)
RoadSegment Distance
ltltbindgtgt ltTRoadSegmentgt
RoadSequence Distance
SequenceltTRoadSegmentgt
1 ..
ordered
1


Trajectory DateOfEntry PrintInvoice ComputeTotal

ordered
Trajectory DateOfEntry PrintInvoice ComputeTotal


Trajectory DateOfEntry PrintInvoice ComputeTotal

97
Visibility

• Simple concept any class has public and private
  elements
• Public elements can be used by any other class
• Private elements can only be used by the owning
  class
• Each language has its own rules
• In the UML, use any marker you want and its
  meaning is language dependent

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

99
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

100
(No Transcript)
101
Interaction Diagrams

• Interaction diagrams are models that describe how
  groups of objects collaborate in some behaviour
• There are several forms of interaction diagrams
  sequence diagrams are the most common
• A sequence diagram captures the behavior of a
  single scenario. This diagram shows a number of
  example objects and the messages that are passed
  between these objects.

102
Sequence Diagrams (1)

• Participants are shown as boxes on top of a
  lifeline
• Participant can be an object, syntax used
  Classname or ObjectName ClassName or ObjectName
• Messages are represented by arrows between the
  lifelines of two participants. Messages are
  labeled with the message name and optional
  arguments.
• The order in which messages occur is shown top to
  bottom

103
Sequence Diagrams (2)

• Self-delegation or self-call, a message that a
  participant sends to itself, is shown by an arrow
  back to the same lifeline.
• 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.

104
a Customer
a Road Segment
an Access Control Node
a Card
Enter
Valid?
checkAccount
New
a Trajectory
Leave
ComputeTotal
GetDistance
GetUnitPrice
PrintInvoice
found message
UpdateAccount
X
105
Creating and Deleting Participants

• Creation by drawing the message arrow directly to
  the participant box.
• Message name is optional.
• Deletion is indicated by a big X.
• Message arrow going directly into the X indicates
  one participant explicitly deleting another one.

106
Loops, conditionals and the like

• Loops and conditionals use interaction frames.
• Interaction frame is used to mark off a piece of
  a sequence diagram.
• Frame consists of some region that is divided
  into one or more frames.
• Each frame has an operator and a guard
• Examples
• Loop loop operand and basis of the iteration in
  the guard
• Conditional alt operator and put a condition on
  each fragment
• Alternative fragments alt operator

107
an Access Control Node
a Card
a Customer
a Road Segment
Enter
isValidValid?
accountOKcheckAccount
alt
New
a Trajectory
isValid And accountOK
Leave
loop
for each roadSegment
ComputeTotal
GetDistance
GetUnitPrice
PrintInvoice
UpdateAccount
X
108
Loops and conditionals in UML 1.x

• Conditions, e.g., checkOk the message is sent
  only if the condition is true
• Iteration markers, DoSomething shows that the
  message is sent many times to multiple receiver
  objects

109
(No Transcript)
110
Synchronous and Asynchronous Calls

• Synchronous message
• filled arrowhead
• Caller waits until the synchronous message is
  done
• Asynchronous message
• stick arrowhead
• Caller can continue processing after asynchronous
  message send

111
an Access Control Node
a Card
a Customer
a Card Reader
a Barrier
a Traffic Light
Enter
Read
isValidValid?
accountOKCheckAccount
isValid And accountOK
New
Open
PutGreen
after 30 sec PutRed
opt
112
When to Use Sequence Diagrams?

• Look at behaviour of several objects within a
  single use case
• showing collaborations among objects
• precise definition of behaviour
• Behaviour of a single object across many use
  cases -gt state diagram
• Behaviour across many use cases -gt activity
  diagram

113
Communication Diagrams (1)

• Emphasis is on the data links between the
  different participants in the interaction.
  (collaboration diagrams in UML 1.x)
• Participants are shown as icons using the same
  syntax as in sequence diagrams.
• 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

114
Collaboration diagrams (2)

• Link is an instance of an association.
• In UML 1.x, keywords 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)
• Iteration markers and guards can be used to
  specify control information (as in sequence
  diagrams in UML 1.x).

115
a Card
8. GetUnitPrice
a Road Segment
7. GetDistance
2. isValidValid?
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
116
a Card
a Road Segment
2.3 GetUnitPrice
2.2 GetDistance
1.1 isValidValid?
1. Enter
1.3 isValid And accountOK New 2.1 ComputeTotal
an Access Control Node
a Trajectory
2. Leave
2.4 PrintInvoice
1.2 accountOKCheckAccount
2.5 UpdateAccount
a Customer
117
Comparing Sequence and Communication Diagrams

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

118
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.
• It is not so minimalist that it misinforms the
  reader about semantics that are important.

119
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

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

121
States

• Different parts of a state
• Name textual string a state may be anonymous
  meaning that it has no name.
• Internal activities states react to events
  without transition.
• Entry/exit activities activities executed on
  entering and exiting the state resp.
• Composite states nested structure of a state,
  involving disjoint (sequentially active) or
  orthogonal (concurrently active) substates

122
Initial and Final States

• Initial state indicates the default starting
  place for the state machine or composite
  state.(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.

123
Transitions

• Transition is a relationship between two states
  indicating that
• an object in the first state will perform certain
  activities 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.

124
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

125
Transitions

• Trigger-signature Guard / Activity
• Trigger-signature an event whose reception by
  the object in the source state makes the
  transition legible to fire, providing the guard
  condition is satisfied.
• Guard 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.
• Activity some behaviour executed during the
  transition

126
Trigger-signature

• 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 a Trigger-signature within
  their label occur as soon as the activity
  associated with the state is finished

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

128
Activity

• Activity is executed if and when the transition
  fires
• Activities may include
• operation calls to the object that owns the state
  diagram or to other visible objects),
• attributes and links of the context object,
• parameters of the triggering event
• activity sequence

129
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
130
AccountOk / New, PutGreen, Open
Enter / CardOk?
idle
checking-card
CardOk / AccountOk?
after 30 sec
checking-account
not CardOk
refusing-access
not AccountOk
131
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.
• Internal Activities

132
Entry and Exit Activities

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

133
Internal Activities

• 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 activity (if any) is
  dispatched, same state is reentered. A
  self-transition dispatches the states exit
  activity and dispatches the states entry
  activity.
• Internal activity if event is triggered, the
  corresponding activity is dispatched WITHOUT
  leaving and then reentering the state!!
• Internal activities may have events with
  parameters and guard conditions, internal
  activities are essentially interrupts.

134
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 activity is
  dispatched.
• The activity of a do activity might
• name another state machine,
• specify a sequence of activities.
• Regular activities cannot be interrupted, while
  do-activities can take finite time and can be
  interrupted.

135
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
136
Composite States

• Composite states can be introduced to group a
  number of states. All substates inherit any
  transition on the composite state. The use of
  composite states makes diagrams often more
  readable
• Orthogonal state diagrams combine different
  independent behaviours of a given object. An
  object can be in different states, each from an
  orthogonal region in the diagram

137
Sequential Composite States

• Sequential composite states 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.

138
Sequential Composite States (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 activity (if any).
• It the target is a substate, control passes to
  the substate after dispatching the entry activity
  (if any) of the composite state and then the
  entry activity (if any) of the substate.

139
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
140
AccountOk / New, PutGreen, Open
Cancel
idle
Enter / CardOk?
active
checking-card
CardOk / AccountOk?
after 30 sec
checking-account
not CardOk
refusing-access
not AccountOk
141
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
142
Orthogonal Composite States

• An orthogonal composite state lets you specify
  two or more state machines that execute in
  parallel in the context of the enclosing object.
• If one orthogonal region reaches its final state
  before the other, control in that region waits at
  its final state. When both nested regions reach
  their final state, control from the two
  orthogonal regions joins back in one flow.

143
/ New, PutGreen, Open
idle
Cancel
Enter
checking
CardOk?
checking-card
CardOk
AccountOk?
checking-account
AccountOk
144