UML Artifacts (Part 2)

1
UML Artifacts (Part 2)
Contents

1. Collaboration Diagrams
2. State Transition Diagrams
3. Visibility
4. Review

2
Collaboration Diagrams
For each system operation identified in the Use
Case Diagrams, and described in a
contract Design a system of interacting objects
to perform the operation.
The collaboration diagram will indicate the
objects participating in the collaboration,
and The sequence of messages message(parameters),
sender, receiver exchanged to achieve the task
involved.
3
Collaboration Diagrams

4
Alternatively (or perhaps primarily) Sequence
Diagrams can be used instead of Collaboration
Diagrams
5
Sequence Diagrams

6
Collaboration Diagrams
Notation
class
instance
named instance
The Collaboration diagram should consist of
illustrations of the messages sent to objects of
the classes identified in the creates/destroys,
reads, changes sections of the contract. The
system operation will be directed to one of the
objects in this group that will act as the
controller for executing this task.
7
Collaboration Diagrams
Illustrating links
UML standard syntax for messages
return message(parameter parameterType)
returnType
sender
receiver
8
Collaboration Diagrams
Illustrating Iteration
1 i0..9 str getName() String
receiver
sender
9
Collaboration Diagrams
Illustrating Iteration
In the example described on the previous slide,
we assumed that the target object contained a
sequence of names (simple strings) as an
attribute. More generally the ClassList may be
considered a collection of StudentRec objects,
and messages may be directed to the collection.
The depiction of a message to a multiobject a
group of objects stored in a collection is
indicated on the next slide.
Representation of a collection (multiobject)
10
Collaboration Diagrams
Given A vector of StudentRecord
Version 1 message to a collection (but vector
is NOT a concept in the problem
domain)
Version 2 (preferred) Emphasizes the objects in
the collection, not (the solution
domain) container.
11
Collaboration Diagrams
Conditional Paths mutually exclusive messages
msg1( )
1a test msg2( )
1b not test msg4( )
1a.1 msg3( )
1b.1 msg5( )
12
Collaboration Diagrams
Creating a new instance during implementation of
the system operation
Create a new MenuItem, m, and add it to the Menu
13
Sequence Diagrams
Sequence diagrams offer an alternate way of
expressing the exchange of messages that occur
between objects in an object-based system.
The notation for objects and collections is the
same as used in collaboration diagrams. Time
ordering is from top to bottom.
Each message between objects is represented with
a message expression on an arrowed line between
the objects
14
Sequence Diagrams
Additional Notation
Object creation -- let the classB object create
an instance of a classC object.
Newly created class is placed in a column
starting at the level (time) of creation.
15
Sequence Diagrams
Conditional message has guard to specify the
condition
Mutually exclusive conditional message
16
Sequence Diagrams
Iteration for a single message
Iteration for a sequence of messages
Enclose the repeated sequence in a box, and
indicate the multiplicity
17
Refining the Class Diagram

• For every class, examine each collaboration
  diagram and identify
• Every message received by an instance of that
  class (these will be the methods for that
  class)
• Each object (class) to which an instance of this
  class sends a message (these may require
  reference attributes within the class, depending
  upon the visibility)

18
Refining the Class Diagram
Class name
Data attributes Link attributes
methods
Class Description
19
State Transition Diagrams
State transition diagrams are a useful tool for
constructing the individual classes.
Specifically, they aid in two important ways in
fleshing out the structure of the class

1. method development -- State transition diagrams
   provide the blueprints for developing the
   algorithms that implement methods in the class

1. attribute identification Attributes contain the
   state information needed for regulating the
   behaviors of the instances of the class

When constructing state transition diagrams, take
care to ensure that the post-conditions
stipulated in the contracts are enforced.
20
State Transition Diagrams
Notation
eventoutput
start
final state
21
State Transition Diagrams
Additional Notation
boolean condition
22
State Transition Diagrams
Example Nested States in Telephone Call
active
The state labeled active has substates
23
State Transition Diagrams
Second Example A Queue of Capacity Two
The queue has three states that indicate its
number of occupants. When the queue is full, new
arrivals cannot enter, and must leave the system.
24
Description of Class Queue
class Queue private int capacity,
size public Queue(int cap) void
enqueue(Object obj) //precondition
queue not full //post condition if
(queue not full) // size size
1 // else no change Object
dequeue() //precondition queue not
empty //post-condition size size-1
25
Visibility
For an object A to send a message to object B, B
must be visible to A.
In determining the visibility of one object to
another, we must decide during the design whether
the link between objects A and B is
permanent or transient
exclusive or shared
fixed or variable
26
Visibility
Example 1. permanent, exclusive , and fixed
Consider a clock composed of three Counters
(hours, mins, secs)

• The Counters have the same lifetime as the Clock
  They are created with the clock and dissolved
  when the clock is out of scope.
• The Counters are bound exclusively to the Clock
  They cannot be referenced by any other object in
  the system

27
Visibility
Implementation of the association between Clock
and Counters
class Clock private Counter hours,
mins, secs public Counter( )
hours(24), mins(60), secs(60) //other
methods
C header file
28
Visibility
Example 2. permanent, shared, fixed
The ProductSpec exists before an instance of the
product is created. That product (computer) will
have a permanent association with its ProductSpec
that it will share access to with other computers
of the same model.
29
Visibility
(Partial) Specification of class Computer
class Computer private ProductSpec
ps public
Computer (ProductSpec theMod)
ps(theMod) //other methods
30
Visibility
Attribute visibility -- an association that must
be remembered is implemented as attribute
visibility. We have just seen a couple of
examples of attribute associativity. In C
attribute associativity is provided via three
forms of the declaration
Counter c Stack s ProductSpec ps
31
Visibility
Transient visibility is not remembered, but
persists only during the execution of a single
method. It is implemented in one of two ways.
1 new sale create()
3 makeLineItem(spec, qty)
2 spec specification(upc)
A ProductSpec object is passed to the Sale object
for use by its makeLineItem method
32
Visibility
Transient associations may also be implemented
with locally declared visibility. Consider a
method breadfirstSearch that uses an auxiliary
Queue to perform a breadth first traversal of a
binary tree. The lifetime of the Queue object
will be within the scope of the method, and the
reference need not exist outside of this method.
33
Review
In designing and constructing an object-oriented
system one must

1. From a statement of the requirements and from the
   use cases identify the objects (concepts) that
   occur in the problem domain

1. Construct a Concept Diagram showing the static
   relationship (long-term associations) between
   concepts

1. Identify the concepts that are outside of the
   system to be built (Actors) and use Sequence
   Diagrams to identify the events (system
   operations) that they generate

1. For each system operation construct a contract
   that stipulates the state of the system before
   and after the operation (pre- and post-
   conditions) and identifies the concepts that
   collaborate in performing the operation

1. Elaboration Review your models for lack of
   clarity and inconsistency and add or modify as
   necessary.

34
Review (continued)

1. Enhance the Concept model by exploring the
   associations in greater detail (roles,
   aggregation, generalization, link attributes,
   etc) and iteratively add design concepts from the
   solution domain (programming concepts)

1. Construct Sequence Diagrams or Collaboration
   diagrams (for each system operation) to detail
   the sequence of messages that must be exchanged
   to implement the task

1. For each relevant object (or collection of
   aggregates) use a State Chart Diagram (state
   transition diagram) to detail the states of the
   system and the sequence of transitions that can
   occur during its operation

1. Continue elaboration of the models until the
   system is well understood and class
   specifications (In C, header files) can be
   constructed.

1. Test design and specification for completeness
   and consistency, then develop test plans and
   begin (or continue) implementing the classes. (an
   on-going process during many phases of the
   project)

35
Postscript
I have been one acquainted with the night. I have
walked out in rain and back in rain. I have
outwalked the furthest city light. I have looked
down the saddest city lane. I have passed by the
watchman on his beat And dropped my eyes,
unwilling to explain. I have stood still and
stopped the sound of feet When far away an
interrupted cry Came over houses from another
street, But not to call me back or say
good-bye And further still at an unearthly
height, One luminary clock against the
sky Proclaimed the time was neither wrong nor
right. I have been one acquainted with the
night. Robert Frost