1. Standard UML: Communication and Dynamic Behavior

2. Collaboration (Object Message) Diagrams
UML :
Collaboration (Object Message) Diagrams
Black Box Testing

3. UML language contains many methods which will not be covered here.
(And some of the methods we are covering are not officially part of UML, although they are often used with UML, e.g., CRC cards).
What we have covered so far:
use cases, data flow diagrams--for requirements analysis, design specification
ER diagrams, CRC cards--for initial design
To be covered:
collaboration or object-message diagrams, state diagrams, sequence diagrams--for more detailed design and dynamic aspects

4. Remember:
Errors caught at the design stage will be much less costly to fix than errors that make it to the implementation stage, just as errors caught at the specification stage are much easier to fix than errors caught at the design stage.
You cannot just write down an ER specification and complete set of CRC cards. Design requires discussion and modification.
As you work on the design, you should refer to the specification, including use cases and any additional materials, to check that your design is meeting this specification and to revise and refine the design as necessary.
As you work on the ER diagram and CRC cards, you MAY want to revisit the specifications

5. Additional UML tools we will use:
Collaboration or Object message diagrams
State diagrams
Sequence diagrams
These allow us to further refine the design, in preparation for coding.

6. Collaboration or Object message diagrams:
Each “responsibility” on a CRC card will be implemented as one or more functions, with information being shared by the collaborators as needed.
The collaboration or object message diagram makes each information-sharing event explicit, by showing the flow of function calls or “messages” related to that event, and gives a more precise way to check on the design being constructed.
Collaboration diagrams make explicit the communications specified through the ER diagram and the CRC cards
They also help to define Black Box tests
(Not ALL functions need to be diagrammed this way, if the information-sharing mechanism is simple and obvious.)
Note: what differences are there between hardware-level communications and software-level communications?

7. Information Sharing options (software?):
In a collaboration or object message diagram we use a rectangle to represent each participating object (labeled by object name or by class name: object name) and we denote each function call by a labeled line or arrow from the calling object to the object responsible for carrying out the function. These calls can be sequentially numbered. These connecting lines can also be labeled to show the status of the objects carrying out the functions in question. Labels used are:
S--the object itself
F--data field of the object itself
P--procedure parameter
G--global variable
L--local variable

8. Example:
A contrived but instructive example in Practical Object-Oriented Development in C++ and Java by Cay Horstmann (Wiley 1997) considers the case where an object of class Car must carry out the operation add_gas by accessing an object from class GasStation.
Note: what would be the relationship of Car and GasStation in the ER diagram?
This example can be used to show the differences in the cases above, as follows:

9. buy_gas void Car::add_gas(GasStation& station)
{ station.buy_gas(…); }
//add_gas has procedure parameter of type //GasStation
buy_gas void Car::add_gas( )
{ the_gas_station.buy_gas(…);
//there is ONE global gas station
buy_gas void Car::add_gas( )
{ _my_gas_station -> buy_gas(…);
//car has ptr to its "own" station, a field in
//the “car” object
Car
GasStation:
station P
Associated test(s) = ?
Car
GasStation:
the_gas_station G
Associated test(s) = ?
Car
GasStation:
_my_gas_station F
Associated test(s) = ?

10. buy_gas void Car::add_gas( )
{GasStation* station = new GasStation( );
station -> buy_gas(…);
delete station; }
//"build and destroy a station” (local variable)
2. buy_gas void Car::add_gas( )
{GasStation* station = find_gas_station();
//Car class has a “find_gas_station”
1.find_gas_station //operation which it must ask itself to //carry out; the return value, of type //GasStation, is a local variable
Car
GasStation:
station L
Associated test(s) = ?
Car L
GasStation:
station S
Associated test(s) = ?

11. Here is another example, also taken from Horstmann, which is more realistic. This diagram shows the messages necessary to execute the "process_dialing" operation in a mail system. Note that "receive_message" can be carried out in two ways, depending on whether the message is for the administrator or for a general reader. The steps to be carried out are:
1. Read input
2a. If input is 9999, have administrator mailbox receive message.
2b1. If input is another extension, find the mailbox for that extension.
2b2. Have that mailbox receive a message.

12. InputReader
process_dialing 1. read_input
MailSystem G S
2a. receive message
2b1. locate mailbox
AdminMailbox F
2b2. receive message L
Mailbox
Steps:
1. read_input
2. receive message (case a or case b)

13. Example: In the bank example, what are examples of appropriate communication mechanisms and associated black box tests
For each module
Between modules?
1.____________
2.____________
3.____________
4.____________
5.____________
6.____________
7.____________
8.____________
9.____________
Event
Departure
Arrival
Customer
Bank
EventQueue
Simulation
Bank Statistics 9 8 1 7 6 2 4 5 3

14. Example: What about the “safe-home” system? What modules might there be? What will be the responsibilities of each module? What communication is needed? What if we add other features, such as environmental modeling?

15. UML—Modeling Dynamic Behavior: State and Sequence Diagrams
(replacements for “flow charts”)

16. State Diagram:
another way of adding detail to the design--models dynamic behavior
describes all the possible states a particular object can be in and how that object's state changes as a result of events that affect that object
usually drawn for a single class to show behavior of a single object
used to clarify dynamic behavior within the system, as needed

17. A state diagram contains a "start" point, states, and transitions from one state to another.
Each state is labeled by its name and by the activities which occur when in that state.
Transitions can have three optional labels: Event [Guard] / Action.
A transition is triggered by an Event.
If there is no Event, then the transition is triggered as soon as the state activities are completed.
A Guard can be true or false. If the Guard is false, the transition is not taken.
An Action is completed during the transition.

18. Example: this state diagram example for an "order" in an order-processing system is from Fowler and Scott, UML Distilled (Addison-Wesley, 1997):
start
/get first item
[not all items checked]
/get next item
[all items
checked &&
all items available]
Dispatching
Checking
initiate delivery
check item
[all items
checked &&
some items not in
stock]
delivered
item received
[all items in stock]
Delivered
Waiting
item received
[some items not in stock]

19. Sequence Diagram:
a sequence diagram also models dynamic behavior
typically a sequence diagram shows how objects act together to implement a single use case
messages passed between the objects are also shown
sequence diagrams help to show the overall flow of control in the part of the program being modeled
they can also be used to show:
concurrent processes
asynchronous behavior

20. Objects in the sequence diagram are shown as boxes at the top
below each object is a dashed vertical line--the object’s “lifeline”
an arrow between two lifelines represents each message
arrows are labeled with message names and can also include information on arguments and control information
two types of control:
condition, e.g., [is greaterthan zero]
iteration, e.g., *[for all array items]
“return” arrows can also be included

21. Example from Fowler and Scott, UML Distilled (note: dashed horizontal line denotes “return”):
an Order Entry
window
an Order
an Order Line
a Stock Item
prepare()
*[for all order lines]
prepare()
hasStock:=check()
[hasStock]
remove()
needsReorder := needsToReorder()
[needsReorder] new
a Reorder Item
a Delivery
Item
[hasStock] new

22. Questions:
What needs to be added to deal with hardware?
What needs to be added to deal with real-time systems and scheduling?