Behaviour Diagrams EEE321.12

1
Behaviour Diagrams EEE321.12
Royal Military College of Canada Electrical and
Computer Engineering

• Maj JW Paul
• Jeff.Paul_at_rmc.ca
• 1-613-541-6000 x6656

2
Quod malum posset futurem
3
Lab 4
4
Polymorphism
parametric
An abstraction operates uniformly across
different types
run-time
universal
sub-type inclusion
An abstraction operates through an inclusion
relation
polymorphism
overloading
A single identifier denotes several abstractions
ad-hoc
compile-time
coercion
A single abstraction serves several types through
implicit type conversion
5
Sub Type Inclusion

• Things needed for a polymorphic function call
• Base Class Object Reference
• Over ridden methods
• Run-time Binding Mechanism
• (late dispatching)
• ALL THREE MUST BE PRESENT

6
Example?
public abstract class GameCharacter public
void whoAmI() public class Warrior
extends GameCharacter public void whoAmI()
mightyThor new Warrior(20,20,hammer)
mightyThor.whoAmI()
7
From Game.java (package gamedriver)
Warrior addToGame(Warrior newWarrior) if
(numWarriors maxWarriors) return null
numWarriors int i 0 while
(warriorsi ! null) i warriorsi
newWarrior return newWarrior
for each type of game character
what does this call?
GameCharacter addToGame(GameCharacter
newCharacter) if (numCharacters
maxCharacters return null numCharacters
int i 0 while (listOfCharactersi !
null) i listOfCharactersi
newCharacter return newCharacter
8
Todays Class

• Behaviour Diagrams

9
Analysis/Design Method

• Notation
• The language for expressing each model
• Process
• The activities leading to the orderly
  construction of the systems models
• Tools
• The artifacts that eliminate the tedium of
  modeling building and enforcing rules about the
  models themselves, so that errors and
  inconsistencies can be exposed

10
Relationships
11
OO Relationships (Booch p 137)

• Dependency
• A change in the specification of one thing may
  affect another thing that uses it, but not
  necessarily the reverse
• Generalization
• KIND of
• Association
• A structural relation, specifying that objects of
  one thing are connected to objects of another

12
Recall UML

• Class Diagram
• Object Diagram
• Component Diagram
• Deployment Diagram
• Use Case Diagram
• Sequence Diagram
• Collaboration Diagram
• Statechart Diagram
• Activity Diagram

Structure diagrams
STATIC VIEW
Behaviour diagrams
DYNAMIC VIEW
13
Collaboration

• An application is the sum of its parts working
  together. Each part (object, interface, etc)
  plays a specific role
• A society of classes, interfaces and other
  elements that work together to provide some
  cooperative behaviour thats bigger than the sum
  of all its parts (Booch p 327)

14
Two parts to collaboration

• Structural Part
• Specifies the classes, interfaces, etc that work
  together to carry out the required collaboration
• Behavioral Part
• Specifies the dynamics of how these parts
  interact
• may request a value (getter or return value)
• may change the state of another object (setter)

Class Diagrams Object Diagrams
Collaboration Diagrams Sequence Diagrams Use-Case
Diagrams
15
Collaboration Diagram

• Looks a lot like an object diagram (still need
  structure)
• Usually use anonymous instances of classes
• May represents other items (other collaborations,
  nodes, components, etc)
• But we need a behaviour diagram

• Add messages
• method calls
• order of operation

16
Message calls
royalBank
Bank
getBalance(String, Double)
anATM
17
Recall Association vs Link see Booch p 209
1

employer
employee
assign(development)
Company
pPerson
In general, a link implies an association
18
Another Example
19
One more example
20
Object Visibility
21
Object Visibility

• It is often not apparent when first studied that
  the design of object visibility is complex and
  fundamental
• The design of the web of object visibility's is
  critical to a project solution
• It is this web of visibility that provides the
  vehicle for the object communication which
  provides the solution to the problem

22
Object Visibility

• Associated with the understanding of object
  visibility for a system, is object creation
• Initially only an objects creator has
  visibility, any other object which needs access
  to this newly created object must get the
  visibility from the creator either directly or
  indirectly
• visibility can flow through object references or
  environment scope rules

23
Object Visibility

• The supplier object provides services through its
  interface
• The client object uses services of the supplier
• this means the client initiates a message to the
  supplier
• this means the client must have visibility to the
  supplier
• the supplier need not have visibility to the
  client

24
Four Kinds of Visibility

• Global
• The supplier object is in a global scope to the
  client
• Field
• The supplier object is a part of the client
• Parametric
• The supplier object is a parameter to some
  operation of the client
• The client gains visibility of the supplier
  through some exchange message with another object
• Local
• The supplier object is a locally declared object
  in the scope of the object diagram

25
Visibility Notation
26
Message Synchronization
27
Message Synchronization

• Messages may be passed
• From one passive object to another
• Assuming one flow of control
  simple invocation of an
  operation
• From one active object to another
• asynchronously
• synchronously
• From an active object to a passive object
• What if multiple active objects call the passive
  object
• From a passive object to an active object
• ???

28
Need more modelling symbols
29
Review

• What is the purpose of a collaboration diagram?