Title: UML Artifacts (Part 2)
1UML Artifacts (Part 2)
Contents
- Collaboration Diagrams
- State Transition Diagrams
- Visibility
- Review
2Collaboration 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.
3Collaboration Diagrams
4Alternatively (or perhaps primarily) Sequence
Diagrams can be used instead of Collaboration
Diagrams
5Sequence Diagrams
6Collaboration 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.
7Collaboration Diagrams
Illustrating links
UML standard syntax for messages
return message(parameter parameterType)
returnType
sender
receiver
8Collaboration Diagrams
Illustrating Iteration
1 i0..9 str getName() String
receiver
sender
9Collaboration 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)
10Collaboration 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.
11Collaboration Diagrams
Conditional Paths mutually exclusive messages
msg1( )
1a test msg2( )
1b not test msg4( )
1a.1 msg3( )
1b.1 msg5( )
12Collaboration Diagrams
Creating a new instance during implementation of
the system operation
Create a new MenuItem, m, and add it to the Menu
13Sequence 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
14Sequence 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.
15Sequence Diagrams
Conditional message has guard to specify the
condition
Mutually exclusive conditional message
16Sequence Diagrams
Iteration for a single message
Iteration for a sequence of messages
Enclose the repeated sequence in a box, and
indicate the multiplicity
17Refining 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)
18Refining the Class Diagram
Class name
Data attributes Link attributes
methods
Class Description
19State 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
- method development -- State transition diagrams
provide the blueprints for developing the
algorithms that implement methods in the class
- 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.
20State Transition Diagrams
Notation
eventoutput
start
final state
21State Transition Diagrams
Additional Notation
boolean condition
22State Transition Diagrams
Example Nested States in Telephone Call
active
The state labeled active has substates
23State 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.
24Description 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
25Visibility
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
26Visibility
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
27Visibility
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
28Visibility
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.
29Visibility
(Partial) Specification of class Computer
class Computer private ProductSpec
ps public
Computer (ProductSpec theMod)
ps(theMod) //other methods
30Visibility
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
31Visibility
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
32Visibility
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.
33Review
In designing and constructing an object-oriented
system one must
- From a statement of the requirements and from the
use cases identify the objects (concepts) that
occur in the problem domain
- Construct a Concept Diagram showing the static
relationship (long-term associations) between
concepts
- 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
- 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
- Elaboration Review your models for lack of
clarity and inconsistency and add or modify as
necessary.
34Review (continued)
- 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)
- Construct Sequence Diagrams or Collaboration
diagrams (for each system operation) to detail
the sequence of messages that must be exchanged
to implement the task
- 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
- Continue elaboration of the models until the
system is well understood and class
specifications (In C, header files) can be
constructed.
- 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)
35Postscript
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