Figure
Stimulus response behavior of a system.In the object model, we described the system, classes and relationships. The object model provides the static structure of a system. In the dynamic model we model the stimulus response behavior of a system. We take a dynamic, time oriented view of the system. We model "when" things happen in system. Two analogies for the dynamic model are a motion picture camera and a play director. A motion picture records "when" things happen. A play director directs "when" things happen. We model interactions, such as the control sequence of input events (stimuli) and output events (responses).
A system has stimulus response behavior as shown
below. We have a user that has a use (use case, objective or function)
for a system. The user sends input events (commands or stimuli)
to the system. The system responds by sending output events back
to the user. For a home copy machine a user has a use, e.g. "make
copy". The user presses the copy button and sends the input
event "make copy" to the copy machine. Within the copy
machine various parts (objects) send and receive messages for
the "make copy" input event. Finally, the machine sends
the output event "copy produced" to the user. We will
use the term system input event or input event to
refer to any stimulus to the system as a whole. We will use the
term system output event or output event to refer
to any response from the system as a whole to another system.
Figure
Stimulus response behavior of a system.The figure below shows the Copy Machine System example with its actor, use case, input event, and output event. In this example, the use case "make copy" and the input event "make copy" have the same name but different descriptions.
In the physical world, behavior is the way an entity
detects stimuli and responds to stimuli. For example, a child
touching a hot stove has the behavior to respond to a "hot
surface" stimulus with the response "move hand quickly".
Behavior is the sum of the stimuli that an entity detects
and the responses to those stimuli. In O-O modeling an input event
is any stimulus that a system or an object must respond to. Stimulus
response behavior is the description of the input events (stimuli)
that a system or object can detect and the responses to the input
events. For example a soda vending machine has stimulus response
behavior. For the "make soda selection" input event
(stimulus) there is the "soda dispensed" output event
(response). This is the planned, desired stimulus response behavior
without error or abnormal conditions.
In O-O modeling it is very important to model the
stimulus response behavior of a system. It aids in satisfying
the customer's requirements. The customer wants the system to
detect certain input events (stimuli or commands) and to produce
certain output events (responses or actions). Second, it aids
in identifying the control logic of a system. The control logic
is the sequence of object messages to invoke operations from an
input event to an output event. The control logic is an important
aspect of satisfying the customer's requirements. Third, it aids
in identifying and implementing complex control logic dealing
with states and transitions. Fourth, it provides a different viewpoint
to model a system that complements the object model and the functional
model. It provides a means to check and verify the object model
and the functional model. Finally, it is an aid to creating software
that is correct, reliable, extendible, and reusable.
In modeling stimulus response behavior, we are interested
in the control logic which is the sequence of messages to progress
from an input event to an output event. We are not interested
in calculations, formulas, or algorithms to compute values. These
are addressed in the functional model. For example, in the home
copy machine, we are interested in getting the output event "copy
produced" for the input event "make copy". We're
not interested the calculation of the toner required or the calculation
of the time required. We are only interested that a copy is produced.
We're interested in identifying the sequence of messages from
the "make copy" input event to the "copy produced"
output event.
In this and following sections we will progress from identifying system use cases, to identifying system input and output events, to identifying objects and messages, to creating messages in a programming language.
The first step in modeling stimulus response behavior
is to identify system use cases. A use case is a specific way
of using a system. Sample use cases for a copy machine are "make
copy", "add paper", "add toner", "repair
machine", etc. We describe a use case by listing the interactions
(events) from a user to and from the system. For the "make
copy" use case, there are the interactions (events) of "make
copy" and "copy produced". Once we have identified
the use cases, then we can identify the input and output events
at the system level, then identify the messages at the object
level, then code the messages for an executable program.
As shown below, for the system as a whole, identify the system use cases which helps identify system interactions (input and output events) for each use case. Create the use case diagram and use case descriptions as part of the System Dynamic Model.
The system use case description lists the major uses (functions) of the system from a user's point of view. Rumbaugh in "Getting started - Using use cases to capture requirements" in "Journal of Object-Oriented Programming" September 1994 suggests that it is useful to identify system users (called actors), use cases, and events very early in O-O modeling. Use cases are described in detail by Jacobson et. al. in Object-Oriented Software Engineering [Jacobson-92]. As shown below, there are four key entities in use cases: actor, use case, interaction, and system.
An actor is an outside entity that interacts with the system. Actors include human users, machines, devices, and other systems. Typical actors are customer, user, manager, supervisor, printer, network communications device, etc. An actor is a user type or category. An actor defines a role that a user can play, e.g. customer versus operator. Actors interact and communicate with the system. Frequently, an actor interacts with the system through an interacting system. For example, a customer interacts with a bank ATM system with User Interface System. Sometimes, an actor is an interacting system, e.g. printer is an actor and interacting system. We use the term actor early in O-O modeling then later use the term interacting system.
A use case is a specific way of using a system
by using some part of its functionality, e.g. "printReport".
Each use case is a complete sequence (scenario) of interactions
(input and output events). An input event is something
that occurs at a point in time that is a stimulus for a system.
An output event is something that occurs at a point in
time that is sent from the system. A complete scenario is an input
event leading to an output event. Typically, an actor initiates
an input event that leads to an output event. For example, the
actor "User" initiates the input event "printReport".
The event is detected by the system. The system issues a series
of output events to the printer.
A use case may have sub-use cases which reflect a
portion or specialized functionality of a system. The following
are sample sub-use cases for a bank ATM.
Actor Use Case System Remarks
- sub-use case Operation
Customer MakeTransaction -- Use Case
- MakeWithdrawTransaction MakeWithdraw Sub-use case
- MakeDepositTransaction MakeDeposit Sub-use case
- GetReport GetReport Sub-use case
Operator UpdateAvailableFunds UpdateFunds Use Case
PerformSystemTest PerformTest Use Case
It is useful to identify actors, use cases, and events early in O-O modeling for the following reasons:
- helps focus on user requirements at a very high level,
- leads to identifying interacting systems based upon actors,
- sets the system boundary,
- helps identify system operations.
The steps to identify and describe the system use
cases are as follows:
Step 1. Identify the system boundary in terms of
the actors (external agents) and the system. In the Car Simulation
System we identified a single actor, e.g. Car User and the Car
Simulation System.
Step 2. Identify each actor by the role that it plays
to interact with the system, e.g. normal user, maintainer, repairer,
etc. In the Car Simulation System we identified a single role
for the actor, e.g. normal user. In an expanded Car Simulation
System we could identify Maintainer, Repairman, Painter, Baggage
Loader, Junk Man, etc. In an expanded Car Simulation System we
could identify many more user roles to represent actors.
Step 3. For each actor, identify the fundamental
different ways (uses) that the actor can use the system. In the
Car Simulation System, we identified only three major uses of
the system: Use Car, Use Cellular Phone, and Manage Passengers.
Notice that each use case may have sub-use cases. In an expanded
Car Simulation System, we could identify many, many other uses,
e.g. Manage Cargo, Use Entertainment System, Use Climate Control
System, etc.
Step 4. For each use case or sub-use case, write a description of the typical interaction (scenario) of the actor with the system. In the Car Simulation System, we describe the interaction of actor with the system for each sub-use case to describe the interactions to start, operate, and stop a car.
The use case diagram shows the actors and use cases in a graphic form. The steps to create the system interaction diagram in a CASE tool or drawing tool are:
>> Run the CASE tool or drawing tool.
>> Select and place the system symbol (box) to represent the system.
>> Select and place the actor (user) symbol (box or stick figure) to represent each actor (user of the system).
>> Select and place the use case symbol (oval) inside the system box to represent each use case.
>> Select and place the interaction symbol (arrow) between the actor and the use case to represent interactions (input and output events).
>> Fill in the description for each use case
in a CASE tool dialog box or word processing table.
The use cases for the Car Simulation System are shown
in the Use Case Diagram and Use Case Descriptions shown below.
The stick person figure labeled Car User is an actor. Later Car
User will be referred to an interacting system. The box figure
labeled Car Simulation System is the system. The oval figure labeled
Use Car is a use case.
The following is a sample use case specification form created in a text editor. Some CASE tools do not offer the use case specification so a text editor is required to collect relationship information.
Use Case Number - 1
Initiating Actor - Car User
Use Case Name - Use Car
Use Case Description - Car User sends various input events to the
Car Simulation System to start, operate,
and stop the car.
Figure Sample Use Case Specification Input Form
The use case specification holds information on each relationship. Use case information includes the following:
- Use Case Number states the use case number.
- Initiating Actor states actor who initiates the use case.
- Use Case Name states the use case name.
- Use Case Description describes the scenario of interactions between the actor and the system.
A sample use case descriptions table listing the
use cases for the Car Simulation System is shown below. It shows
the use case descriptions for the Car Simulation System. This
table was created in a text editor.
| Number | Initiating Actor | Use Case/Sub-use Case | Use Case Description |
| 1 | Car User | Use Car | Car User sends various input events to the Car Simulation System to start, operate, and stop the car. |
| 1.1 | Car User | Start Car | Car User sends a start event to the Car Simulation System to start the car. The system sends the car status. |
| 1.2 | Car User | Operate Car | Car User sends the operate event to the Car Simulation System to operate the car at a speed. The system sends the car status. |
| 1.3 | Car User | Stop Car | Car User sends the stop event to the Car Simulation System to stop the car. The system sends the car status. |
| 2 | Car User | Use Cellular Phone | Car User sends various events to the Car Simulation System to make and receive cellular phone calls. The system sends the car status. |
| 2.1 | Car User | Make Phone Call | Car User sends the makePhoneCall event to the Car Simulation System to make an outgoing cellular phone call. The system sends the car status. |
| 2.2 | Car User | Receive Phone Call | Car User sends the receivePhoneCall event to the Car Simulation System to receive an incoming cellular phone call. The system sends the car status. |
| 3 | Car User | Manage Passengers | Car User sends various events to the Car Simulation System to add and remove passengers from the car. The system sends the car status. |
| 3.1 | Car User | Add Passenger | Car User sends the addPassenger event to the Car Simulation System to add a passenger to the car. The system sends the car status. |
| 3.2 | Car User | Remove Passenger | Car User sends the removePassenger event to the Car Simulation System to remove a passenger from the car. The system sends the car status. |
As shown in the diagram and table above, the Car Simulation System has a single user, e.g. Car User. The system has three use cases, e.g. Use Car, Use Cellular Phone, and Manage Passengers. Each use case has sub-use cases. For example, the Use Car use case has three sub-use cases: Start Car, Operate Car, and Stop Car. The sub-use cases have the numbers 1.1, 1.2, 1.3, etc.
The next step in modeling stimulus response behavior
is to identify system input and output events for each use case.
Stimulus response behavior is the sequence of input events (stimuli)
and associated output events (responses) in a system for users.
Users initiate or know about events. Input events cause the system
to initiate or generate output events (responses). An interacting
system benefits or knows about the output event (response). The
stimulus response behavior is associating an input event such
as "make copy" with an output event such as "copy
produced". The table below shows a simple example of stimulus
response behavior for a home copy machine. The interacting
system is an entity that uses or interacts with the system.
In this example, the copy machine user interacts with the machine.
The interacting system initiates an input event such as "make
copy" by pressing the copy button. An input event
is a significant occurrence at a point in time that is a stimulus
for the system or an object in the system. The copy machine detects
the input event and causes an output event, such as "copy
produced". An output event is a significant occurrence
that is caused by or the result of an input event. The interacting
system receives the benefit of the output event. We model the
system input and output events for each use case.
User Input Event System Output Event User
User Make Copy Copy Machine Copy Produced User
As shown below, at the system level for each use case, identify the interactions (input and output events) between the system and interacting systems. Create the system interaction diagram, system interaction scenario (table), and system/interaction specification (report) as part of the System Dynamic Model. An optional diagram is the system event flow diagram.
An interacting system (actor from use case)
is a human user or other entity that initiates an input event,
indicates that an input event has occurred, receives a output
event (response), or interacts with the system in any way. An
interacting system is external or outside the system. An interacting
system can be a human users, hardware devices, software programs.
The key point about an interacting system is that it is external
to the system and that it interacts with the system with input
and output events. The following are some sample software systems
and interacting systems.
Software System Interacting System
TV Control System Button Device, Speaker Device, Volume Device
Automatic Teller Machine User Interface Devices, Bank Interface Devices
An input event is something that occurs at
a point in time that is a stimulus for a system or an object of
the system. An event has no time duration. An event is an occurrence
that a system or an object must respond to. Forms of events include
user events, physical events, and time events. A user event is
initiated by an interacting system such as "user pressed
a button" or "user selected a menu item and "sensor
detected a high reading". A physical event occurs in the
physical word such as "temperature increased above a setpoint"
or "smoke becomes present". A time event is a time occurrence
such as "time is 12 o'clock" or "time-out has occurred.
An input event may have information attached to it,
such as time of the event, location, button number, menu selection
name, etc. Rumbaugh et. al. refers to event information as "event
attributes" [Rumbaugh-91]. An input event can be implemented
as an object, such as "theStartEvent" or as a messages
such as "start()". As an object, event information,
such as "time of the event" is implemented as an object
attribute. As a message, event information is implemented as an
operation parameter such as "start (aStartTime)". The
following are sample user events for a copy machine:
Interacting System User Input Event
User Turn On Event
User Make Copy Event
User Paper Added Event
User Turn Off Event.
An output event is something that occurs as
a result of an input event. An output event is frequently an event
that is a stimulus to an interacting system. Rumbaugh et. al.
call a response an "outgoing event" [Rumbaugh-91]. An
output event may have information attached to it such as "time
of event". An output event can be implemented as an object
such as "CarStarted output event" or as a message such
as "RecordCarStarted ()". It is an occurrence that a
system initiates or causes to happen. Sample input and output
events are as follows:
Table Sample input and output events.
------------------------------------------------------------------------------------------------------------------------
System Input Event Output Event
------------------------------------------------------------------------------------------------------------------------
Temperature Alarm System High Temperature Event Sound Alarm
Cruise Control System User Pressed Set Button Maintain the set speed
Automatic Teller Machine User Pressed Dispense Button Get the dispense amount
Smoke Detector Presence of smoke Ring alarm
Copy Machine Copy button pressed Production of a copy
Vending Machine Selection button pressed Dispensing of a soda
Car Horn Horn pressed Sound horn
Word Processing Program Selection of a menu item Execution of the menu item
------------------------------------------------------------------------------------------------------------------------
To model input and output events the following documentation products are useful. These products will described in the following sections.
- System Interaction Diagram
- System Interaction Scenario (Table)
- System and Interaction Specification (Report)
The system interaction diagram shows the system,
interacting systems, and interactions (input and output events).
The system interaction diagram described by Rumbaugh et. al. [Rumbaugh-91]
and Booch [Booch-94]. It is a graphic format that shows the sequence
of input and output events in a time order. It shows the interacting
system that send input events and receive output events. The general
steps to create the system interaction diagram are as follows:
Step 1. Start with the use cases.
Step 2. Identify the users or interacting systems
which interact with the system, e.g. User.
Step 3. Identify input events which are stimuli for
the system, e.g. start. The system must respond to each input
event. For each input event identify event information that describes
a particular event for the system.
Step 4. Identify output events that are a result
or reaction to input events, e.g. Car started. The system must
respond to each input event. For each output event identify output
event information that describes a particular output event and
that is passed to or from the system.
Step 5. Describe each input event and output event.
The form of the system interaction diagram is shown below. A arrow toward the system indicates an input event. An arrow leading away from the system indicates an output event. Input and output events are grouped by the applicable use case.
The system interaction diagram for the Car Simulation System is shown below. This diagram shows the input and output events for the three use cases in the Car Simulation System in a time ordered sequence.
The steps to create the system interaction diagram in a CASE tool or drawing tool are:
>> Run the CASE tool or drawing tool.
>> Select and place the system symbol (line or box) to represent the system and each interacting system.
>> Label the system and each interacting system, e.g. Car User.
>> Select and place the interaction symbol (arrow) to represent input and output events.
>> Enter input event names on the event symbols (arrows), e.g. start.
>> Enter output event names on the event symbols
(arrows), e.g. showStatus.
The system interaction diagram is an important diagram
in O-O modeling. It is used with the system interaction scenario
and system and interaction specification. It is used to walk-through
each input event leading to an appropriate output event. For example,
assign a person to represent the system and each user/interacting
system. Then each person representing a user/interacting system
sends his events to the person representing the system. The person
representing the system should send the appropriate output event
to the person representing a user/interacting system. Many times
you will discover that you've forgotten some important input events
or output events. Many times you will change the names of the
input events or output events to be more meaningful. Hopefully,
you will verify that each input event has a logical and meaningful
output event.
An alternative form of the system interaction diagram
is the system event flow diagram described by Rumbaugh
[Rumbaugh-91]. An example is shown below without the use case
grouping.
The system interaction diagram shows the system input and output events in a graphic form. The system event scenario is a time ordered list of input and output events. It shows the sequence of each input event and the output events to the input event over time. The basic question is: For each input event what is the output event (response) to the input event?
After a simple system event scenario has been created,
the variations may be added such as error or abnormal conditions.
The initial system event scenario for the Car Simulation System
is shown below in various system event scenario formats.
The basic steps to create the system event scenario
is as follows:
Step 1. Enter the input event that reasonably occurs
first.
Step 2. Enter the simplest output event to that input
event.
Step 3. Enter the next input event that may occur
and the simplest output event.
Step 4. Continue until all input events have been
listed with their simplest output events.
Step 5. Update the system event scenario with error
conditions and abnormal conditions. Alternatively, create various
system event scenarios showing variations including error conditions
and abnormal conditions.
The system interaction scenario (events) is useful for the following reasons:
- to understand system requirements,
- to generate initial test cases,
- to generate menus and dialog boxes,
- to provide a test scenario for walk-throughs.
We list the input event and the output event in a
time order. The system event scenario for the Car Simulation System
is shown below. The first input event is the start event. The
output event to the start event is "car started" under
normal circumstances. The next input event is the operate event.
There is event information attached to this event. It is the desired
speed that is passed to the vehicle system. The output event to
the operate event is "car operating". This output event
also has output event information shown in parentheses, "aSpeed".
The operating speed is passed to the user in the output event.
The system interaction scenario lists the system input and output events for each use case in a table form. The steps to create the system interaction diagram are:
>> Run the CASE tool.
>> Open the system interaction diagram, e.g. CARSYS.OMT and ensure that it is complete and accurate.
>> Input additional information in the system and interaction specification forms, e.g. Description.
>> Select "Generate Object Code/Report" and run a report generation script to create the system interaction scenario, e.g. TABSYSIN.SCT.
>> If required, update the scenario information.
>> If desired, import the scenario information into a word processor to format into a table as shown below.
The system interaction scenarios for the Car Simulation
System are shown below. There is a scenario for each use case.
| Sequence # | Sender System | Receiver System | Invoked Operation | Description |
| 1 | Car User | Car Simulation System | start | Input Event |
| 2 | Car Simulation System | Car User | showStatus | Output Event |
| 3 | Car User | Car Simulation System | operate | Input Event |
| 4 | Car Simulation System | Car User | showStatus | Output Event |
| 5 | Car User | Car Simulation System | stop | Input Event |
| 6 | Car Simulation System | Car User | showStatus | Output Event |
| Sequence # | Sender System | Receiver System | Invoked Operation | Description |
| 1 | Car User | Car Simulation System | makePhoneCall | Input Event |
| 2 | Car Simulation System | Car User | showStatus | Output Event |
| 3 | Car User | Car Simulation System | receivePhoneCall | Input Event |
| 4 | Car Simulation System | Car User | showStatus | Output Event |
| Sequence # | Sender System | Receiver System | Invoked Operation | Description |
| 1 | Car User | Car Simulation System | addPassenger | Input Event |
| 2 | Car Simulation System | Car User | showStatus | Output Event |
| 3 | Car User | Car Simulation System | removePassenger | Input Event |
| 4 | Car Simulation System | Car User | showStatus | Output Event |
The script (TABSYSIN.SCT) to generate the table from the system
interaction diagram is shown below.
SCRIPT_NOREPEAT_HEADER_BEGIN
Sequence Number, Sender System, Receiver System, Invoked Operation, Description SCRIPT_NOREPEAT_HEADER_END
[INTERACTION_SEQUENCE_NUMBER, INTERACTION_SENDER_OBJECT_NAME, INTERACTION_RECEIVER_OBJECT_NAME, INTERACTION_OPERATION_NAME, INTERACTION_DESCRIPTION]
The system and interaction specification shows detailed information about the system, interacting systems and interactions. Enter detailed information by filling in the input forms (dialog boxes) shown below. Output this information in a report by entering a command or running a CASE tool script. The steps to create the system and interaction specifications:
>> Run the CASE tool.
>> Open the system interaction diagram and ensure that it is complete and accurate.
>> Double click each system and interaction to bring up the object and interaction specification input forms.
>> Enter detailed information on each interacting system and interaction by filling the input forms (dialog boxes).
>> Select "Generate - Generate Object Code/Report" and run a report generation script to create the system and interaction specification report, e.g. RPTSYSIN.SCT.
>> Select "File Edit File" and enter the report name to view the report.
>> If required, update the system and interaction information.
>> If desired, import the system and interaction information into a word processor to sort and format.
A sample object specification input form is shown
below. This form is used to enter system information since a system
is also an object. It is not necessary to have a separate system
and object specification form in the dynamic model.
The following information is collected in this specification input form.
- Object Name: name of the object, e.g. car1. The interacting system name may be entered, e.g. CarUser.
- Class Name: name of the class of the object, e.g. Car
- Description: details information about the object or the interacting system.
- User Field 1, 2, and 3: any user supplied information, e.g. initial attribute values.
- Invoked Interactions: lists all the interactions (events or messages) that this system or object initiates.
A sample interaction specification input form (dialog box) is shown below to input system event information. This form is used to collect by system interactions (events) and object interactions (messages).
The following information is collected in this specification input form.
- Sequence Number: the sequence number of an interaction (event or message), e.g. 1
- Invoked Operation: the name of the invoked operation, e.g. start ()
- Operation Parameters: input parameters to the invoked operation, e.g. int speed
- Operation Return Type: return type of the invoked operation, e.g. void
- Description: details information about the interaction (event or message)
- Synchronization: simple, synchronous, balking, time-out, or asynchronous
- Sender and Receiver Object: the names of the sender and receiver system or object for the current interaction (event or message).
- Invoking Operation: the name of the invoking operation that initiates this interaction (event or message). For example, the sender object has the invoking operation start. Within this operation is the interaction (message) "motor1.start();"
To access the system (object) and interaction (event or message) specification information, you need to know the script variable for each peice of information in the object and interaction specification input form. The following are sample script variables from the object and interaction specification in a CASE tool. A brief description states what occurs when the script variable appears in a script. Object and interaction variables access information from object interaction diagrams.
OBJECT_NAME Prints the object name, e.g. car1
OBJECT_CLASS_NAME Prints the class name of the object, e.g. Car
OBJECT_DESCRIPTION Prints the description of the object
OBJECT_USER1 Prints user information
OBJECT_USER2 Prints user information
OBJECT_USER3 Prints user information
Since there are multiple relationship for each class,
these variables are used within the [] (Repeat Operator). For
example, the following script statement prints out the interaction
(event) names for each object [INTERACTION_OPERATION_NAME
, ].
INTERACTION_SEQUENCE_NUMBER Prints the interaction sequence number, e.g. 1, 2, ....
INTERACTION_OPERATION_NAME Prints the name of the invoked operation, e.g. turnOn
INTERACTION_OPERATION_PARAMETERS Prints the input parameters of the invoked operation, e.g. int aSpeed
INTERACTION_OPERATION_RETURN_TYPE Prints the return type, e.g. void
INTERACTION_SENDER_OBJECT_NAME Prints the name of the sender object, e.g. car1
INTERACTION_SENDER_CLASS_NAME Prints the name of the class of the sender object, e.g. Car
INTERACTION_SENDER_OPERATION_NAME Prints out the name of the operation that encloses the message,
e.g. Car::start operation encloses the motor1.start()
message
INTERACTION_RECEIVER_OBJECT_NAME Prints the name of the receiver object, e.g. motor1
INTERACTION_RECEIVER_CLASS_NAME Prints the name of the class of the receiver object, e.g. Motor
INTERACTION_DESCRIPTION Prints the interaction description
INTERACTION_OPERATION_LIST_NAME Prints the operation name in the operation list
INTERACTION_OPERATION_LIST_NAME_WITH_PARAMETERS Prints the operation name with parameters
in the operation list
INTERACTION_OPERATION_WITH_PARAMETERS Prints the operation name with parameters
INTERACTION_BALKING Prints Balking if checked
INTERACTION_TIMEOUT Prints Timeout if checked
INTERACTION_SYNC Prints Synchronous if checked
INTERACTION_ASYNC Prints Asynchronous if checked
INTERACTION_SIMPLE Prints Simple if checked
The following is a sample system and interaction
specification report. This was created by running a CASE tool
report script (RPTSYSIN.SCT). It presents the applicable system
and interaction information is a list format. If desired, a user
may enter additional information in the system user information
boxes.
System Name: CarUser
System Description: Car User is an interacting system.
Initiated Interactions: start, operate, stop,
System User1 Info: N/A
System User2 Info: N/A
System User3 Info:
N/A
Interaction Sequence Number: 1
Interaction - Receiver System Invoked Operation with Parameters: start()
Interaction - Receiver System Invoked Operation Parameters: --
Interaction - Receiver System Invoked Operation Return Type: void
Interaction - Receiver System Name: Car Simulation System
Interaction Synchronization: Simple
Interaction Description: start is an input event from CarUser Interacting System.
Interaction Sender System
Name: CarUser
The script (RPTSYSIN.SCT) to generate this report
is shown below.
System Name: OBJECT_NAME
System Description: OBJECT_DESCRIPTION
Initiated Interactions: [ INTERACTION_OPERATION_NAME ,DELETE_LAST_SYMBOL ]
Initiated Interactions with Parameters: [ INTERACTION_OPERATION_WITH_PARAMETERS ,DELETE_LAST_SYMBOL ]
System User1 Info: OBJECT_USER1
System User2 Info: OBJECT_USER2
System User3 Info: OBJECT_USER3
[
Interaction Sequence Number: INTERACTION_SEQUENCE_NUMBER
Interaction - Receiver System Invoked Operation with Parameters: INTERACTION_OPERATION_WITH_PARAMETERS
Interaction - Receiver System Invoked Operation Name: INTERACTION_OPERATION_NAME
Interaction - Receiver System Invoked Operation Parameters: INTERACTION_OPERATION_PARAMETERS
Interaction - Receiver System Invoked Operation Return Type: INTERACTION_OPERATION_RETURN_TYPE
Interaction - Receiver System Name: INTERACTION_RECEIVER_OBJECT_NAME
Interaction Synchronization: INTERACTION_SIMPLE INTERACTION_BALKING INTERACTION_SYNC INTERACTION_ASYNC INTERACTION_TIMEOUT
Interaction Description: INTERACTION_DESCRIPTION
Interaction Sender System Name: INTERACTION_SENDER_OBJECT_NAME ]
The third step in modeling stimulus response behavior is to identify objects and messages among objects in a system to progress from an input event to an output event. Up to this point we have modeled input events and output events for the system. Now we want to look inside the system to determine how a output event is created for each input event. Inside the system, when an input event is detected, then there is a series of messages among objects leading to a output event.
A message is the invocation of an operation
in an object. The control logic is the sequence of messages
from an input event to an output event. For each input event there
are one or more message scenarios or message threads showing a
sequence of messages. To identify objects and messages you need
to have the object model with classes and relationships identified.
The following shows a sample message scenario for the "make
copy" input event.
Table Sample message scenario for Make Copy Use Case
----------------------------------------------------------------------------------------------------------------------------------------
Seq- Sender Receiver Invoked Operation Input Output
ence Object Object Name Parameters Parameters
-----------------------------------------------------------------------------------------------------------------------------------------
1 theButtonInterface theCopyController copy none none
2 theCopyController theHWInterface checkPaper none Boolean
3 theCopyController theHWInterface copy none none
-----------------------------------------------------------------------------------------------------------------------------------------
As shown below, at the object level for each use
case, identify the interactions (messages) between objects. Create
the object interaction diagram, object interaction scenario (table),
and object/interaction specification (report) as part of the Dynamic
Model. An optional diagram is the annotated class diagram showing
messages.
A message is an invocation of an operation in an object. A message consists of the following:
object name
invoked operation name
input parameters (class name and object name)
output or return parameters (class name and object
name)
The following are several sample messages:
Table Sample Messages.
------------------------------------------------------------------------------------------------------------------------
Object Invoked Operation Input Output
Name Name Parameter (Return) Parameter
------------------------------------------------------------------------------------------------------------------------
theClock Give Time None Current Time
theCopyController Make Copy None OK or NotOK
theMoneyChanger Make Change One Dollar Change
There are three documentation products to describe the stimulus response behavior with messages:
Object Interaction Diagram
Object Interaction Scenario
Object and Interaction Specification
It is important to model messages. Messages are be directly implemented in an OOP language such as C++. We must have messages to have an executable prototype. We can trace messages through a system from an input event to a output event for each use case.
An object interaction scenario lists messages for some external action or input event in a time ordered sequence through a system from first message to last message. The object interaction diagram displays the messages between objects. The basic questions are "What are the input and output events at the system level, e.g. start and operate?" "For each input event, what are the messages through the system leading to output events?" The goal is the effective use of messages for loose message coupling for independent changeable modules with no undesirable side-effects. The form of the object interaction diagram is shown below.
The following are the general steps to identify objects
and messages to create the object interaction diagram.
Step 1. Start with the system use cases, system interaction
diagram, and system interaction scenario.
Step 2. Identify the objects and their classes, e.g.
car1:Car, motor1:Motor.
Step 3. For each input event or system operation,
identify messages between objects possibly leading to one or more
output events.
Step 4. Check the relationships on the class diagram
because objects with association or aggregation relationships
generally have messages.
Step 5. Create the object interaction diagram showing
objects and messages.
The steps to create the object interaction diagram
using a CASE tool or Windows drawing tool are listed below.
>> Create a directory for Car products, e.g. c:\md car
>> Run the CASE tool or Windows drawing editor from Windows
>> Select "File - New"
>> Select "File - SaveAs" e.g. c:\car\carmsg.omt
>> Select the object icon
>> Enter the object name, e.g. car1
>> Double click OK to create the object symbol
>> Place the object symbol on the page
>> Select the object icon
>> Enter the object and class name, e.g. motor1
>> Select the interaction arrow icon
>> Connect the interaction arrow from one object to another
>> Select "File - Save" to save the diagram
>> Select "File - Print" to print
the diagram
The following is the object interaction diagram for the Car Simulation System Use Car Use Case.
There is an alternative "box" form of the
object interaction diagram described by Coleman et al [Coleman-93].
A sample is shown below.
The message scenario shows the sequence of
messages for each use case. The sequence shows the control logic
of the system. It shows "what happens when". It shows
what is the first message, the second message, etc. The message
scenario is necessary to update source code. Messages must be
added to source code generated by a CASE tool for an executable,
functioning prototype. For prototyping only a few simple message
scenarios are done to "get started". For complex systems,
there could be thousands of message scenarios. The message scenario
for the Use Car use case is shown below:
Object Interaction Scenario Table - Use Car Use Case
| Sequence # | Sender System/Object | Receiver System/Object | Invoked Operation | Description |
| 1 | Car User | car1 | start | Input Event |
| 2 | car1 | motor1 | start | Message |
| 3 | car1 | Car User | showStatus | Output Event |
| 4 | Car User | car1 | operate | Input Event |
| 5 | car1 | motor1 | operate | Message |
| 6 | car1 | Car User | showStatus | Output Event |
| 7 | Car User | car1 | stop | Input Event |
| 8 | car1 | motor1 | stop | Message |
| 9 | car1 | Car User | showStatus | Output Event |
The script (TABOBJ.SCT) to generate this table is shown below.
SCRIPT_NOREPEAT_HEADER_BEGIN
Sequence #, Sender System/Object, Receiver System/Object, Invoked Operation, Description SCRIPT_NOREPEAT_HEADER_END
[INTERACTION_SEQUENCE_NUMBER, INTERACTION_SENDER_OBJECT_NAME, INTERACTION_RECEIVER_OBJECT_NAME, INTERACTION_OPERATION_NAME, INTERACTION_DESCRIPTION]
The object and interaction specification shows detailed information about the objects and interactions. Enter detailed information by filling in the input forms (dialog boxes). Output this information in a report by entering a command or running a CASE tool script. The steps to create the object and interaction specifications:
>> Run the CASE tool.
>> Open the object interaction diagram and ensure that it is complete and accurate.
>> Enter detailed information on each object and interaction by filling the input forms (dialog boxes)
>> Run a report generation script to create the object and interaction specification report, e.g. RPTOBJ.SCT and TABOBJ.SCT.
>> If required, update the object and interaction information.
>> If desired, import the object and interaction
information into a word processor to sort and format.
The following is a sample object and interaction
specification report. This was created by running a CASE tool
report script. It presents the applicable object and interaction
information is a list format. If desired, a user may enter additional
information in the object user information boxes.
Object Name: car1
Object Class Name: Car
Object Description: car1 is a single object of the Car class
Initiated Interactions: start, showStatus, operate, showStatus, stop, showStatus,
Initiated Interactions with Parameters: start(), showStatus(status), operate(aSpeed), showStatus(status), stop(), showStatus(status),
Object User1 Info: N/A
Object User2 Info: N/A
Object User3 Info:
N/A
Interaction Sequence Number: 2
Interaction - Receiver Object Invoked Operation with Parameters: start()
Interaction - Receiver Object Invoked Operation Name: start
Interaction - Receiver Object Invoked Operation Parameters: --
Interaction - Receiver Object Invoked Operation Return Type: --
Interaction - Receiver Object Name: motor1
Interaction - Receiver Class Name: Motor
Interaction Synchronization: Simple
Interaction Description: Message
Interaction Sender Object Name: car1
Interaction Sender Class Name: Car
Interaction Sender Operation Name: start
The script (RPTOBJ.SCT) to generate this report is
shown below.
SCRIPT_NOREPEAT_HEADER_BEGIN
Object and Interaction Report
All Received and Initiated Interactions: [ INTERACTION_OPERATION_LIST_NAME ,DELETE_LAST_SYMBOL ]
All Received and Initiated Interactions with Parameters: [ INTERACTION_OPERATION_LIST_NAME_WITH_PARAMETERS ,DELETE_LAST_SYMBOL ]
SCRIPT_NOREPEAT_HEADER_END
-------------------------------------------------------------------------------
Object Name: OBJECT_NAME
Object Class Name: OBJECT_CLASS_NAME
Object Description: OBJECT_DESCRIPTION
Initiated Interactions: [ INTERACTION_OPERATION_NAME ,DELETE_LAST_SYMBOL ]
Initiated Interactions with Parameters: [ INTERACTION_OPERATION_WITH_PARAMETERS ,DELETE_LAST_SYMBOL ]
Object User1 Info: OBJECT_USER1
Object User2 Info: OBJECT_USER2
Object User3 Info: OBJECT_USER3
[
Interaction Sequence Number: INTERACTION_SEQUENCE_NUMBER
Interaction - Receiver Object Invoked Operation with Parameters: INTERACTION_OPERATION_WITH_PARAMETERS
Interaction - Receiver Object Invoked Operation Name: INTERACTION_OPERATION_NAME
Interaction - Receiver Object Invoked Operation Parameters: INTERACTION_OPERATION_PARAMETERS
Interaction - Receiver Object Invoked Operation Return Type: INTERACTION_OPERATION_RETURN_TYPE
Interaction - Receiver Object Name: INTERACTION_RECEIVER_OBJECT_NAME
Interaction - Receiver Class Name: INTERACTION_RECEIVER_CLASS_NAME
Interaction Synchronization: INTERACTION_SIMPLE INTERACTION_BALKING INTERACTION_SYNC INTERACTION_ASYNC INTERACTION_TIMEOUT
Interaction Description: INTERACTION_DESCRIPTION
Interaction Sender Object Name: INTERACTION_SENDER_OBJECT_NAME
Interaction Sender Class Name: INTERACTION_SENDER_CLASS_NAME
Interaction Sender Operation Name: INTERACTION_SENDER_OPERATION_NAME
]
The following is the data dictionary listing objects
based upon the object interaction diagram.
| Entity Name | Type of Entity | Enclosing Class | Entity Description |
| Car User | System | N/A | Interacting system that initiates events. |
| car1 | Object | Car | Object of Car class. |
| motor1 | Object | Motor | Object of Motor class. |
The script (DDOBJ.SCT) that generates this table from the object
interaction diagram is shown below.
SCRIPT_NOREPEAT_HEADER_BEGIN
Entity Name, Type of Entity, Enclosing Class, Entity Description
SCRIPT_NOREPEAT_HEADER_END
OBJECT_NAME, Object, OBJECT_CLASS_NAME, OBJECT_DESCRIPTION
The final step in modeling stimulus response behavior
is to code messages in the programming language and update source
code to implement a message sequence. Typically, we generate source
code from the class diagram in the Object Model. To create an
executable prototype, we must update the source code with messages.
At the object level for each use case or sub-use case, identify message sequences for your programming language and update source code with the message sequences.
The message sequence list contains detailed information to create messages in source code format. As shown below the message sequence list has the name of the message receiver, invoked operation name, message parameters (arguments), and message return type. It shows the sequence of messages. You may directly create messages in your source code format and add the messages to your source code. Your CASE tool may have a command or script to automatically update your source code. The steps to create the message sequence list:
>> Run the CASE tool.
>> Open the object interaction diagram, e.g. CAROBJ.OMT and ensure that it is complete and accurate.
>> Examine detailed specification information on each object and interaction, e.g. parameters and return types.
>> Select "Generate - Generate Object Code/Report" and run a message sequence report generation script to create the report, e.g. TABOBMSG.SCT.
>> If required, update the object and interaction information.
>> If desired, import the object and interaction information into a word processor to sort and format.
>> Update the source code by placing messages
in the appropriate sender operations (functions).
| Sequence # | Sender System/
Class::Object | Sender
Operation | Return Type | Receiver System/
Class::Object | Invoked Operation (Parameters) |
| 1 | Car User:: Car User | Car::car1 | start () | ||
| 2 | Car::car1 | start | Motor::motor1 | start () | |
| 3 | Car::car1 | start | Car User::Car User | showStatus (status) | |
| 4 | Car User:: Car User | Car::car1 | operate (aSpeed) | ||
| 5 | Car::car1 | operate | Motor::motor1 | operate (aSpeed) | |
| 6 | Car::car1 | operate | Car User::Car User | showStatus (status) | |
| 7 | Car User:: Car User | Car::car1 | stop () | ||
| 8 | Car::car1 | stop | Motor::motor1 | stop () | |
| 9 | Car::car1 | stop | Car User::Car User | showStatus (status) |
The script (TABOBMSG.SCT) to generate this table is shown below.
SCRIPT_NOREPEAT_HEADER_BEGIN
Sequence #, Sender System/Class::Object, Sender Operation, Return Type, Receiver System/Class::Object, Invoked Operation (Parameters) SCRIPT_NOREPEAT_HEADER_END
[INTERACTION_SEQUENCE_NUMBER, INTERACTION_SENDER_CLASS_NAME::INTERACTION_SENDER_OBJECT_NAME, INTERACTION_SENDER_OPERATION_NAME, INTERACTION_OPERATION_RETURN_TYPE, INTERACTION_RECEIVER_CLASS_NAME::INTERACTION_RECEIVER_OBJECT_NAME, INTERACTION_OPERATION_NAME (INTERACTION_OPERATION_PARAMETERS)]
Once you have identified the messages required for
each use case listed in the message sequence list, you may add
the messages to the source code. The form of a message in C++
to an automatic object and an example are as follows:
<Automatic Object Name>.<Member Function Name> (Arguments);
car1.operate (65);
The steps to add the messages to the source code are:
>> Generate code from the class diagram.
>> Examine the message sequence list.
>> Select a set of messages for a specific use case, e.g. Use Car.
>> Place the message for the initial input event in a test function, event handling function, or main function.
For example, place car1.start() in the main function.
>> Place messages in the appropriate sender operations. For example, place motor1.start(); in the Car::start() function.
>> In the language environment, compile, link,
and run the source code.
Sample C++ Functions that Implement Messages for
Start Input Event
#include "car.h"
int main ()
{ Car car1;
car1.start ();
return 0;
}
void Car::start()
{ motor1.start ();
}
For complex use case, you may implement a message sequence for a single input event at a time. For example, you add messages for the "start" input event only rather than for the entire "use car" use case. You could compile, link, and run the program after you add the messages for a single event.
An important technique in O-O modeling is to identify superclasses and subclasses with polymorphic operations. Booch defines polymorphism as follows: "Polymorphism - A concept in type theory, according to which a name (such as a variable declaration) may denote objects of many different classes that are related by some common superclass; thus, any object denoted by this name is able to respond to some common set of operations in different ways." [Booch-91].
A polymorphic operation has a single name but many
implementations. For example, the start operation in the following
diagram has one name, start () but multiple implementations. There
is an implementation in the Car class and a different implementation
in the Truck class. Using polymorphic operations reduces complex
"if..then" logic statements and reduces the name space
of operations in the system. Polymorphic operations are used with
dynamic binding. Dynamic binding is the association of an object
name with an object and its class at runtime. The object name
may later be associated with a different object and its class.
For example, the object name "aVehicle" is first associated
with the car1 object and later associated with the truck1 object.
When a message is sent to "aVehicle", the correct version
of the operation is invoked depending upon what object "aVehicle"
refers to.
Class Diagram Showing Polymorphic Operations Object Interaction Diagram
There are three versions of the start operation aVehicle may be car1 or truck1
Polymorphism and dynamic binding are extensively
used in object-oriented programming. A major advantage of using
polymorphism and dynamic binding is that complex "if..then"
and "case" statements can be avoided. Whenever there
is a common operation that is invoked depending, upon the type
of input, consider creating a subclass for each type of input
with the common operations. Complex case and if statements can
be replaced with a single message as shown below.
Case case
statement circle : put_circle(); break;
triangle : put_triangle(); break;
....
Dynamic Binding Graphic_Object -> Put();
with no case statement
The following are the general steps to use polymorphic
operations and dynamic binding.
Step 1. Identify a superclass, e.g. Vehicle.
Identify a common set of polymorphic (one name many forms) operations,
such as Start().
Step 2. Identify subclasses that have the same common
polymorphic operations but with different implementations of the
operations. Objects of the subclasses have responsibility to respond
to messages with the appropriate action.
Step 3. Identify a general object name, such as aVehicle
for a polymorphic object. The name may refer dynamically to objects
of different subclasses, e.g. car1
or truck1.
Step 4. Assign the general object name to refer to
an object of one of the subclasses, such as aVehicle
= car1.
Step 5. Send the object with the general object name
a message, such as aVehicle -> start ();
Step 6. Expand the system by adding more subclasses
with new implementations of the common set of polymorphic operations,
such as a new Motorcycle class with a new implementation of the
start operation.
The following are the steps to use polymorphic operations
and dynamic binding in C++.
Step 1 - Create a base class with virtual functions
(polymorphic operations) that may be redefined in derived classes,
such as virtual void start ();
Step 2 - Create derived classes with the redefined functions (polymorphic operations), such as void Car:: start () {...} and void Truck::start () {...}.
Step 3 - Create a base class pointer (general object
name), such as Vehicle *aVehicle;
Step 4 - Assign an object of a derived class to the
base class pointer (general object name), such as aVehicle
= &car1;
Step 5 - Send the object referred to by the base
class pointer (general object name) a message, such as aVehicle
-> start (); This invokes the car version
of start ().
The listing below is a short example showing polymorphic
functions and dynamic binding in C++. This code listing is in
a single source code file (.cpp file).
Listing C++ code showing
polymorphism and dynamic binding.
#include <iostream.h>
//--------------------Vehicle Base Class -----------------------
class Vehicle { //Abstract Base Class
public:
virtual void start () = 0; //Pure Virtual Function
};
//--------------------Car Derived Class ------------------------
class Car : public Vehicle { //Derived Class
public:
void start () {cout << "Car is started.\n"; }
};
//--------------------Truck Derived Class-----------------------
class Truck : public Vehicle { //Derived Class
public:
void start () {cout << "Truck is started. \n"; }
};
//------------------Main Function Definition -------------------
int main ()
{ Vehicle *aVehicle; //Creates pointer to an object
//of the base class
Car car1; //Creates an object of the derived class
Truck truck1; //Creates an object of the derived class
aVehicle = &car1; //aVehicle refers to car1 object
aVehicle -> start (); //Message to car1 object
aVehicle = &truck1; //aVehicle refers to truck object
aVehicle -> start (); //Message to truck1 object
return 0;
}
//--------------------Program Output------------------------------
//Car is started.
//Truck is started.
This listing shows two important capabilities of
C++: abstract class and pure virtual function. An abstract class
is a base class that has no objects. Only objects of derived classes
may be created. An abstract class has at least one pure virtual
function. A pure virtual function declares a member function that
must be defined in derived classes. The form and an example of
a pure virtual function is as follows:
Base Class Form and Example:
virtual <class or type> <function name> () = 0;
virtual void start () = 0;
Derived Class Form and Example:
<class or type> <function name> () { < C++ Statements >
void start () {cout << "Car is started.\n"; }
In this chapter we presented the dynamic model to identify stimulus response behavior of systems and objects. Behavior is the sum of the stimuli that an entity detects and the responses to those stimuli. An input event is a significant occurrence at a point in time that is a stimulus for the system an object in the system. An output event is a significant occurrence that is caused by or the result of an input event. A use case is a major use or function of a system that is a sequence of input and output events.