The purpose of this chapter is to present "how to" create the system level models for the TV Control System. In this chapter we will present a brief overview of modeling systems. Then we will present a complete System Object Model, System Dynamic Model, and System Functional Model for the TV Control System. In later chapters we will present the class level models and an executable C++ prototype.
In previous sections we modeled a small number of
classes to get familiarity with basic O-O concepts, documentation
products, and CASE tools. In this section we will look at how
to model and prototype a system of classes. We will apply the
basic O-O concepts as listed below:
O-O Entities - system environment, system, interacting system, class and object
O-O Relationships - association, aggregation, generalization specialization, interaction (events and messages)
Models - system object model, system dynamic model, system functional model, object model, dynamic model, functional model
Documentation Products - diagrams, text specifications, code
Tools - Windows CASE tools,
Windows drawing tool, Windows word processor, Windows C++ Compiler
O-O modeling follows the Analysis Model in Rumbaugh's OMT O-O methodology with interpretations. O-O modeling emphasizes the early identification of the system environment and the identification of separate interface, control, and entity classes for highly portable systems. We will follow an iterative approach to model and prototype a system. First we'll take a system level point of view to model the system as a whole. We'll examine the TV Control System from a system point of view and create the system object model, system dynamic model, and the system functional model. Then we'll look inside the TV Control System and identify classes, attributes, operations, relationships, etc. We'll create the object model, dynamic model, and functional model.
There are several key entities in modeling the system within its environment. These are defined below.
User - A user is a human,
a machine, or other entity that interacts with the system environment
to change or receive benefit from the system. For example, a user
of a word processing program is the person sending a print command
to the word processor to print a document. A user of an air traffic
control system is the human air traffic controller. A user may
have a use case which is the sequence of interactions for
a typical use of the system. For example, a typical use case for
a bank automatic teller machine is "withdraw cash".
System Environment - The
system environment consists of a system and interacting systems
(devices or programs). In S/W a GUI based text processor is a
system environment with a system, for example, the text processor
program and interacting systems (device or program), for example,
a GUI system and a file system.
System - The system is
the system to be modeled and prototyped. It is our center of focus.
It generally consists of 10 to 100 classes as a rough order of
magnitude. It is generally programmed as a single .EXE or concurrent
process. The text editor program is an example of a system. A
large system may be partitioned into subsystems. A subsystem may
consist of other subsystems or the subsystem may consist of classes.
A system may have system attributes which are a characteristic
or property of the system as a whole. A system has system operations
which are major functions, activities, or services that the system
performs.
Interacting System (Device Or Program)
- An interacting system (device or program) is any entity that
interacts with the system. An interacting system can be a H/W
device, S/W program, a GUI program, a data management program,
a communications program, etc. An interacting system is sometimes
called an actor, terminator, outside agent, or external system.
Input and Output Object - An input object and output object are objects that are passed as a parameter in an input event and or an output event. It exists in the system environment and is manipulated by the system. Examples are bank account, customer, registration, product, etc. that are passed into or from the system. An input or output object is sometimes called a real world object, a domain object, or problem domain object.
Relationships - A system
has a relationship with one or more interacting systems. A system
is associated ("has a", "knows about", "is
associated with") with one or more interacting systems. A
system interacts with one or more interacting systems with input
and output events. These are defined below.
Association Relationship - An association relationship is a connection or link between the system and an interacting system. In an association relationship the system has one of the following with an interacting system:
- the system "has a " interacting system,
- the system "knows about" an interacting system,
- the system "is associated with" an interacting
system.
Interaction Relationship (Events) - An interaction relationship is a communication, interaction, or stimulus response connection between the system and an interacting system. In an interaction relationship, there are one or more input or output events between the system and an interacting system.
Input Event - An input
event is a stimulus (interaction or communication) from an interacting
system (device or program) to the system. The system must detect
and respond. An input event is based on a user or physical phenomenon
such as a user action of pressing a function key. Examples of
input events are turn on, turn off, record data, store data, print
report, etc. Generally, a menu item or button in a GUI window
represents an input event. The input event represent the functional
requirements of the system, i.e. what the system must do. In implementation,
an input event could be a message, remote procedure call, interrupt,
or other communication.
Output Event - An output event is an outgoing stimulus from the system to an interacting system (device or program). It is in response to an input event such as a message to a printer. Examples of output events to an interacting GUI system are open window, show dialog box, display text, etc. Examples of output events to an interacting data base management system are get record, update record, delete record, find record, etc. In implementation, an output event could be a message, remote procedure call, or other communication.
The following is a recommended strategy to identify
major entities in the system environment.
1. Start with the customer provided information,
e.g. requirements statement, drawing, block diagram, etc.
2. Identify the system to be modeled and interacting
systems which interact (communicate) with the system. This is
to set the scope and boundary of the system.
3. For a large system, identify smaller subsystems
to developed individually.
4. Identify input events. These are based upon events
which occur in the system environment to which the system must
respond.
5. Identify output events. These are responses to
input events.
6. Identify input and output objects that are passed into and from the system in input or output events. The input and output objects will be basic objects used in the system.
To rapidly model and prototype O-O systems, it is desirable to understand the basic patterns, structures, and architectures in the systems we're working on. In the real world we see patterns, structures, and architectures all around us. We see houses, buildings, tables, chairs, stairs, etc. In S/W we see windows, dialog boxes, lists. Each of these represent a well defined pattern, structure, or architecture. The term pattern is the broadest and most general term describing a high level entity, e.g. a group of entities that work together to perform a function. We will use the term pattern in this tutorial. We will describe various basic, connection, subsystem, and class patterns that can help us to understand O-O concepts and to rapidly model and prototype O-O systems. An excellent book on patterns is Design Patterns Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides [Gamma-95].
A pattern consists of two or more entities with a
well defined purpose, behavior, connections, and structure. A
simple example of a pattern in the physical word is a book shelf.
Its component entities are shelves, sides, top, and nails. Its
purpose is to store books. Its behavior is that it "accept
books", "hold books", "provide books",
and "collect dust". Its connections are physical association
connections with nails, "part of" aggregation connections,
and "is a" generalization specialization connections.
Its structure is a tree structure in terms of "part of"
aggregation and "is a" generalization specialization.
Its structure is a network structure in terms of physical association
connections.
A simple example of a pattern in S/W information
systems is a window. Its component entities are border, menu,
and dialog box. Its purpose is to interact with a user. Its behavior
is to open, close, move, etc. Its connections are weak association
("has a"), aggregation ("part of"), messages
("interacts"), and generalization specialization ("is
a" - sharing - inheritance). Its structure is a tree structure
in terms of aggregation ("part of") and a network structure
in terms of messages ('interacts") and generalization specialization
("is a" - sharing - multiple inheritance).
It is valuable to understand patterns in the real world and in S/W information systems for the following reasons:
- patterns facilitate faster learning of O-O concepts,
- patterns help analyze and describe systems,
- patterns provide "building blocks" to create complex systems,
- patterns can speed up the development of complex systems,
- patterns can result in reduced coupling and greater cohesion for extendibility.
There are basic structures or patterns in O-O systems.
These are frequently referred to as "structures" in
mathematics texts. These basic structures include set, positional,
linear, tree, layered, and network structures. These basic structures
are primarily drawn from mathematics. Michael Feldman presents
most of these structures in Data Structures with Ada [Feldman-85].
These basic structures help us to understand basic O-O entities,
basic O-O connections, and patterns. These structures are ordered
from the simplest, e.g. set to the most complex, e.g. network.
In general a simpler structure provides more effective coupling
than a more complex structure.
A basic structure (pattern) consists of two or more entities with a well defined form or pattern as shown in the figure and table below.
Table Basic structures in O-O modeling.
------------------------------------------------------------------------------------------------------------------------
Structure Mathematics Physical S/W
Term Example Example
------------------------------------------------------------------------------------------------------------------------
Set Set Set of Books Set Class
Positional Vector Daily Pill Box One Dimension Array
Matrix Table or Spreadsheet Two Dimension Array
Linear Linear Movie Theater Line Linked List Class
Tree Rooted Tree Organization Chart Tree Class
Layered Directed Acyclic Layered Military Layered GUI
Graph (No Cycles) Organization Classes
Network Directed Road Network Graph Class
Graph (Cycles OK)
------------------------------------------------------------------------------------------------------------------------
In general, simpler structures are easier to model,
understand, and implement. However, do not distort a system by
forcing a simpler structure. The following is a brief definition
of these basic structures.
Set Structure - The set
structure is an unordered collection of entities (elements). A
real world example of a set is a set of books. A S/W example of
a set is a set class.
Positional Structure -
The two primary positional structures are vector and matrix. A
vector is a set of entities that are ordered in the sense that
each entity is assigned to a specific position in the set. In
the real world, a pill box with a compartment for each day is
an example of a vector. In S/W a one dimension array is an example
of a vector. A matrix is a group of entities in a row and column
organization. Every entity can be referred to by its row and column
position. In the real world, a military marching unit or a group
of movie goers in a theater is an example of a matrix. In S/W
a table or two dimension array is an example of a matrix.
Linear Structure - In
a linear structure, entities are connected in a linear or sequential
order. The first entity is connected to the second entity, the
second entity is connected to the third entity, etc. In the real
world, a line chain or line of bank patrons waiting for a teller
is a example of linear structure. In S/W a linked list is an example
of a linear structure.
Tree Structure - In a tree structure entities are organized in a layered, pure hierarchical fashion with a root node, interior nodes, and leaf nodes. In a tree there is exactly one path from the root node to any other node. Each node may have a path to one or more lower level nodes. In the real world, a living tree, an organization chart, or a genealogical family tree are examples of trees. In S/W a binary tree or any object that has components (aggregation "part of") is an example of a tree structure.
Layered Structure - In
a layered structure entities are connected with an arc to another
node. Entities are organized into logical layers with one way
message connections. Entities on a higher level may interact with
entities on any lower level. However, entities on a lower level
cannot initiate interactions with an entity on a higher level.
Entities within a level may interact together. A real world example
of a layered structure is a military "chain of command".
Commands (orders) flow from the highest level commander to subordinate
commanders to lower level soldiers. This chain of command is not
a tree because commands may flow within a layer, i.e. the soldier
level and because there may be more than one path from a root
node to another node. A S/W example of a layered structure is
a UNIX X Windows application in which the application layer calls
the MOTIF layer which calls the Xlib layer.
Network Structure - In
a network structure entities are connected with one or more arcs
to other entities. There is no a strict ordering scheme. There
are one way or two way messages. Any entity can interact with
any other entity. In the real world, a road network and a communications
network are examples of a network structure. In S/W a graph class
is an example of a network structure. This is a common way of
structuring subsystems. Many concurrent systems are organized
in the network structure without layers.
To meet the goal of effective coupling for system understandability and extendibility we suggest the following preferences assuming each logically describes the problem domain and does not distort the problem domain: 1st - tree structure, 2nd - layered structure, and 3rd - network structure. In this tutorial most of the examples shown in class diagrams are a tree structure, such as aggregation examples. There is only one path from a high level class, such as Car to a lower level class, such as Motor. The path is Car -> Motor. There are some examples of a layered structure, such as when parts interact with each other. A part Motor class whose objects interact with objects of a part Transmission class is an example of the layered structure. There are multiple paths to the Motor class or the Transmission class, such as Car -> Transmission or Car -> Motor -> Transmission. An example of a network structure is mutual interaction from an object of a User class and an object of a Car class. Both can initiate an interaction with the other. There can be a cycle of interaction, such as User -> Car -> User.
To model a complex system one must identify the system and interacting systems. One must identify the input and output events of the system. It is useful to identify key patterns such as the tree, layered, and network patterns.
The system object model corresponds to the OMT Object
Model at the system level. The major question is "What is
the system and interacting systems?" We are setting the boundary
of the system. The object model is "snapshot" of a system
at a point in time. As described below the system object model
consists of the following documentation products: system requirements
statement, system drawing, system block diagram, system diagram
(OMT class diagram notation), system specification, and data dictionary.
In the system object model, we define the static
structure of the system and interacting systems. We specify the
relationships between the system and interacting systems, e.g.
association. The interaction relationship (input and output events)
is specified in the system dynamic model. To create the system
object model, we will present the objective, key entities, key
relationships, and key products as introduced below.
Objective - The objective
of the system object model is to define the boundary and scope
of the system within a larger environment in terms of interacting
systems. It is important to have a clearly defined boundary and
scope to accomplish development requirements, cost, and schedule
goals.
Entities - The key entities are the system being modeled and interacting systems (devices or programs). Each system has system attributes and system operations.
Relationships - The key
relationship is association between the system and interacting
systems.
Products (Diagrams and Text) - The key products are the system requirements statement, system drawing, system block diagram, system diagram, system specification, and data dictionary.
System Requirements Statement - States
the system requirements for the system.
System Drawing or Physical Representation
- Provides a physical, real world view of the system environment.
System Block Diagram (Inputs and Outputs) - Shows
the system, interacting systems, and input/output objects within
the system environment.
System Diagram (OMT Notation) - Shows
the system, interacting systems, and association relationships
in the OMT class diagram format.
System Specification - The
system specification lists key information about the system, e.g.
name, enclosing system, and remarks.
Data Dictionary - The data dictionary lists key terms and a brief description of each term. The data dictionary is updated to add new terms and descriptions in each model.
In the object model we specify classes with their
attributes, operations, relationships, and other relevant information.
Follow these steps.
Step 1 - Draft the system requirements statement.
The system requirements statement describes the system and its
functionality.
Step 2 - Make a system drawing. The system
drawing provides a physical, real world view of the objects that
we are modeling. The system drawing will help us to visualize
the attributes and to walk-through a scenario of input and output
events.
Step 3 - Create a system block diagram (inputs
and outputs). The system block diagram shows the system, interacting
systems, and input/output objects.
Step 4 - Create the system diagram (OMT Notation).
The system diagram shows the system, interacting systems, and
association relationships in the OMT class diagram format. Create
the system table with the sample CASE tool script TABSYS.SCT
Step 5 - Create the system specification.
The system specification lists key information about the system,
e.g. name, enclosing system, and remarks. The sample CASE tool
script is RPTSYS.SCT.
Step 6 - Create or update the data dictionary.
Initially define the terms representing the system, interacting
systems, and system operations. The sample CASE tool script is
DDSYS.SCT.
Step 7 - Check and update consistency between the diagrams, specifications, and other models. Check all diagrams and text specifications for the consistent spelling, capitalization, and meaning of all names.
The purpose of the system requirements statement
is to state the system requirements for the system. The system
requirements statement is a primary document to describe the system
requirements and functions of the system. The system requirements
statement is the problem statement and charter. The emphasis in
the system requirements statement is to describe the system and
its interactions with interacting systems (devices or programs).
For simple systems, the system requirements statement consists
of a few sentences stating what the system must do. For complex
systems, the system requirements statement may be thousands of
pages of detailed requirements and specifications. In this tutorial
only very simple requirements statements are presented. This section
describes the system requirements statement, its purpose, steps
to create, and a sample requirements statement. The following
are the steps to create a requirements statement.
Step 1. Identify the system environment with the
system and interacting systems (devices or programs).
Step 2. State the functional requirements of the
system, i.e. what the system must do.
Step 3. State the users, user types, user roles,
or user categories of the system, e.g. customer, operator, supervisor,
end user, etc. In Object-Oriented Software Engineering,
Jacobson et. al. uses the term actor to refer to a user
role or user category. Each actor has one or more events and an
interaction scenario (use case) consisting of input events,
messages through the system, and output events.
Step 4. Describe the system's commands (input events),
responses (output events), and input and output objects.
Step 5. If necessary, describe the interacting systems (device or program).
The following is the system requirements statement
for the TV Control System Case Study.
The TV Control System is a software program (system) that receives commands (input events) from a TV Buttons Device (interacting system) and sends commands (output events) to TV Speaker Device, TV Channel Device, and TV Storage Device (interacting systems). The TV Control System stores the last used volume and channel selection. The commands (input events) are turn on, turn off, increase volume, decrease volume, increase channel, and decrease channel. The TV Control System initiates the following output events: retrieve volume, store volume, set volume, retrieve channel, store channel , and set channel. The following data (input and output objects) are passed in the output events: volume setting and channel setting.
The purpose of the system drawing is to provide a physical, real world view of the system environment including the user, H/W devices, S/W programs, etc. A drawing is a physical diagram of the system environment showing typical users, hardware devices, software programs, and input and output objects passed into and from the system. This section describes the system requirements statement including its purpose, steps to create, and a sample requirements statement.
The following are the steps to create the system
drawing.
Step 1. Show the system as a box in the middle of
the system drawing.
Step 2. Show users and their user roles, e.g. user,
operator, etc.
Step 3. Show the interacting systems (H/W devices
and S/W programs) that interact with the system.
Step 4. Show the association between the system and
interacting systems (H/W devices and S/W programs).
Step 5. Optionally, draw small arrow symbols to represent input and output objects that are passed to and from the system in events.
The system drawing for the TV Control System is shown
below. This block diagram shows the TV User, the TV Buttons
Device with buttons to handle each event, the TV Control System,
the Speaker Device, the Channel Device, and the Storage Device.
The system block diagram shows a high level view
of the system environment with the system and interacting systems
(devices or programs). The system block diagram has boxes for
each major entity in the system environment. It shows major hardware
devices, software programs, and relationships. This section describes
the system block diagram including its purpose, steps to create,
and a sample block diagram.
The system block diagram shows the system being modeled
and interacting systems (devices or programs) within the system
environment. The system block diagram shows interacting systems
that initiate commands (input events). The system block diagram
show interacting systems that receive responses (output events).
An input object is passed into the system. An output object is
passed from the system. The system block diagram leads to the
system interaction diagram (events).
The purpose of the system block diagram is to show
the system, interacting systems (also called terminators, actors,
or agents), input objects (also known as input data flows), and
output objects (also known as output data flows). The input and
output objects may be an atomic object, a structured object, and
a collection object. The system block diagram is a graphic, visual
representation showing the system inputs and outputs (objects)
with interacting systems. The system block diagram has a box for
the system being modeled and a box for each interacting system.
Input and output objects are shown as small arrows. The system
block diagram is functionally equivalent to the Structured Analysis
system context diagram.
The following are the steps to create the system
block diagram.
Step 1. Start with the system requirements statement.
Step 2. Show the system being modeled and interacting
systems (devices or programs) as boxes.
Step 3. Place the system being modeled in the box
in the middle of the diagram.
Step 4. Place interacting systems that send commands
(input events) on the top or left of the diagram.
Step 5. Place interacting systems that receive commands
(output events) from the system on the right or bottom of the
diagram.
Step 6. Show a line between interacting systems and
the system being modeled. These lines represent interaction or
communication.
Step 7. Show input and output objects as arrows being passed into and from the system.
The system block diagram of the TV Control System
is shown below.
The system diagram shows the system and interacting
systems in the OMT Object Class Diagram Notation. For the system
and interacting systems, it shows the system attributes and operations.
This diagram is described by Clinton Gilliam in "An Approach
for Using OMT in the Development of Large Systems" in Journal
of Object-Oriented Programming 1994 [Gilliam-94]. This section
describes the system diagram including its purpose, steps to create,
and a sample system diagram.
The steps to create the system diagram (OMT Class
Diagram Notation) are:
Step 1. Start with the system block diagram showing
the system and interacting systems.
Step 2. Place an OMT class symbol in the middle of
the page to represent the system.
Step 3. For each interacting system, place an OMT
class symbol on the page. Show an association between the system
and the interacting system.
Step 4. Fill in the system attributes. A system
attribute is a property or characteristic of the system. Ask the
question, "As a system, what objects or data do I know about?
Step 5. Fill in the system operations. A system
operation is a function or transformation of the system as a whole.
Ask the questions, "As a system, what do I do?" "As
a system, what are my major functions?" "As a system,
what input events do I respond to?"
Step 6. For each interacting system, fill in the system attributes and system operations. The system has a system operation for each input event. An interacting system that receives output events has a system operation for each output event.
The system diagram of the TV Control System is shown below. This diagram shows the system and each interacting system. The TV Control System has the system attributes: volumeSetting and channelSetting. The TV Control System has the system operations: turnOn, increaseVolume, decreaseVolume, increaseChannel, decreaseChannel, and turnOff.
The following is the system table showing the system, e.g. TVControl System and interacting systems. The sample CASE tool table generation script is TABSYS.SCT.
| System Name | Attribute Names | System Operation Names |
| TVButtonsDevice | ||
| TVControlSystem | volumeSetting channelSetting | turnOn increaseVolume decreaseVolume increaseChannel decreaseChannel turnOff |
| SpeakerDevice | volumeSetting | setVolume |
| ChannelDevice | channelSetting | setChannel |
| StorageDevice | volumeSetting channelSetting | retrieveChannel storeChannel retrieveVolume storeVolume |
The system specification lists key information about
the system as a whole. The steps to create the system specification
are:
Step 1. Start with the system block diagram and the
system diagram (OMT Class Diagram Notation) showing the system
and interacting systems.
Step 2. Fill in applicable information in the system specification form, e.g. access, description, etc.
The system specification of the TV Control System is shown below. The sample CASE tool report generation script is RPTSYS.SCT.
- System Name: TV Control System
- System Access: public access.
- System Imports: None.
- Enclosing System: None
- System Description: The TV Control System is an embedded software system in a television that is controlled by a hand held TV control device. System responds to the following user commands: turn on, increase volume, decrease volume, increase channel, decrease channel, and turn off.
The data dictionary lists the terms used in the system
and a brief description of each term. In the system object model,
the data dictionary lists the system and the interacting systems.
Additionally, it may list the system attributes and system operations.
TV Control System Case Study - The initial data dictionary for the TV Control System is shown below. The sample CASE tool table generation script is DDSYS.SCT.
| Entity Name | Type of Entity | Enclosing System | Entity Description |
| TVControlSystem | System | -- | Controls the TV volume and channel settings. |
| TVButtonsDevice | Interacting System | -- | Handles all user initiated button pushes. |
| SpeakerDevice | Interacting System | -- | Controls the volume setting. |
| ChannelDevice | Interacting System | -- | Controls the channel setting. |
| StorageDevice | Interacting System | -- | Stores the channel and volume settings. |
| volumeSetting | System Attribute | TVControlSystem | The value of the volume. |
| channelSetting | System Attribute | TVControlSystem | The value of the channel setting. |
| turnOn | System Operation | TVControlSystem | Turns on the TVControlSystem. |
| increaseChannel | System Operation | TVControlSystem | Increases the channel setting. |
| decreaseChannel | System Operation | TVControlSystem | Decreases the channel setting. |
| increaseVolume | System Operation | TVControlSystem | Increase the volume setting. |
| decreaseVolume | System Operation | TVControlSystem | Decreases the volume setting. |
| turnOff | System Operation | TVControlSystem | Turns off the TVControlSystem. |
The following are various criteria and questions
to ask in evaluating the adequacy of the products describing the
system in the system environment.
- Have we collected enough information to identify
and describe the system and interfaces to interacting systems
(devices or programs)?
- Have we grouped interacting systems together that
have a common function?
- Have we organized the interacting systems for loose
coupling in terms of events?
- Have we described the system in terms of commands
(input events), functions (system operations), and data inputs
and outputs (objects)?
- Have we identified users and their user roles,
e.g. operator, supervisor?
- Have we clearly stated the scope (boundary) of
the system in terms of the "10 most important" input
events, output events, system operations and input and output
objects?
- Does the customer (requester of the system) agree that we have clearly stated the scope (boundary) and the functionality of the system?
The system object model is the description of the system, system attributes, system operations, and system relationships with interacting systems. The system object model consists of documentation products, e.g. system requirements statement, system drawing, system block diagram, system diagram (OMT class diagram notation), system specification, and data dictionary.
The purpose of the system dynamic model is to show
stimulus response behavior over time of a system. The system dynamic
model corresponds to the OMT Dynamic Model at the system level.
The major questions are "What is the stimulus response behavior
of a system?", "What input events does the system respond
to?", "What occurs over time in the system? and "What
is the state based behavior of the system?" In the system
dynamic model, we define stimulus response behavior and the time
oriented sequence (scenario) of input and output events. We define
the states, e.g. modes of behavior of the system.
An input event is something that happens
at a point in time that is a stimulus for action. An input
event is an incoming stimulus for the system. Sample input
events are "user presses the start button", "temperature
reaches 100 degrees", "user selects a menu item - print".
An output event is an outgoing stimulus from the system
to an interacting system. Sample output events are "display
status" and "print report".
Objective - The objective
of the system dynamic model is to define the stimulus response
behavior of the system over time in terms of input and output
events.
Entities - The key entities in the system described in the system dynamic model are the system, input events, output events, and states.
Relationships - The key
relationship is interaction. Each interaction is represented by
an input or output event.
Products (Diagrams and Text) - The key products are the system interaction diagram (events), system interaction scenario, system interaction scenario, system state diagram, and data dictionary as described below.
Use Case Diagram and Descriptions
- Show the system use cases.
System Interaction Diagram (Events)
- Shows input events and output events. It sets the boundary for
the system.
System Interaction Scenario and Specification
(Events) - Displays the time ordered sequence
and specification of input and output events.
System State Diagram -
States the stimulus response logic for the system. It specifies
the pattern of input events, conditions, states, and output events.
System State Transition Table and Specification
- Shows the system states and transitions in a table and specifies
the system states and transitions.
Data Dictionary - List key terms in the system dynamic model, e.g. system interactions and states.
In the dynamic model we have specify stimulus response
behavior and the time sequence of input and output events. Follow
these steps.
Step 1 - Start with the system requirements statement,
system block diagram, system drawing, and system
diagram (OMT class diagram notation).
Step 2 - Create the system use case diagram and
descriptions.
Step 3 - Create a system interaction diagram (events).
Step 4 - Create the system interaction scenario,
system and interaction specification, and data dictionary
(system events). The sample CASE tool scripts are TABSYSIN.SCT,
RPTSYSIN.SCT, and DDSYSIN.SCT.
Step 5 - Create a system state diagram (if
required).
Step 6 - Create the system state transition table,
system state and transition specification, and data dictionary
(system states). The sample CASE tool scripts are TABSTATE.SCT,
RPTSTATE.SCT, and DDSTATE.SCT.
Step 7 - Optionally, create or generate C++ source
code. Compile and execute the program.
Step 8 - Check and update consistency between the diagrams, specifications, and other models. Check all diagrams and text specifications for the consistent spelling, capitalization, and meaning of all names.
The use case diagram and descriptions are useful to capture requirements. A general use case diagram is shown below.
The steps to create the use case diagram and descriptions
are:
Step 1 - Start with the requirements statement.
Step 2 - Identify the actors, use cases, sub-use
cases. Describe each use case in terms of the sequence of input
and output events.
Step 3 - Create the use case diagram and use case
table.
Step 4 - Walk through the use case diagram.
The use case diagram and descriptions for the TV Control System is shown below. It shows that the TV Control System has three use cases: Operate TV, Manage TV Volume, and Manage TV Channel.
| Num-ber | Initiating Actor | Use Case/Sub-use Case | Use Case Description |
| 1 | TV User | Operate TV | TV User sends various input events turnOn and turnOff to the TV Control System. The system sends output events to the Storage Device, Speaker Device, and Channel Device. |
| 1.1 | TV User | turnOn | TV User sends the turnOn event to the TV Control System to get and set the stored values of volumeSetting and channelSetting. |
| 1.2 | TV User | turnOff | TV User sends the turnOff event to the TV Control System to turnOff the system. |
| 2 | TV User | Manage TV Volume | TV User sends the increaseVolume and decreaseVolume events to the TV Control System to increase and decrease the system volume. |
| 2.1 | TV User | increaseVolume | TV User sends the increaseVolume event to the TV Control System to increase the volume setting. The system sends the output event setVolume to the Speaker Device. |
| 2.2 | TV User | decreaseVolume | TV User sends the decreaseVolume event to the TV Control System to decrease the volume. The system sends the output event setVolume to the Speaker Device. |
| 3 | TV User | Manage TV Channel | TV User sends the increaseChannel and decreaseChannel events to the TV Control System to increase and decrease the system channel setting. |
| 3.1 | TV User | increaseChannel | TV User sends the increaseChannel event to the TV Control System to increase the channel setting. The system sends the output event setChannel to the Channel Device. |
| 3.2 | TV User | decreaseChannel | TV User sends the decreaseChannel event to the TV Control System to decrease the channel setting. The system sends the output event setChannel to the Channel Device. |
The purpose of the system interaction diagram (events) is to show the scope and boundary of the system in terms of input and output events. The system interaction diagram (events) displays the system, input events, and output events in graphic form. The system interaction diagram (events) is functionally equivalent to the structured analysis context diagram showing control flows described by Ward and Mellor in Structured Development for Real-Time Systems Volume 1 [Ward-85]. Both the system interaction diagram (events) and structured analysis context diagram set the boundary of the system. This section describes the system interaction diagram (events) including its purpose, steps to create, and a sample diagram.
The following are the steps to create the system
interaction diagram (events).
Step 1. Start with the system requirements statement,
system drawing, system block diagram, use case diagram, and use
case descriptions.
Step 2. Place interacting systems that send commands
(input events) on the left of the diagram.
Step 3. Place the system being modeled in the middle.
Step 4. Place interacting systems that receive commands
(output events) from the system on the right or bottom of the
diagram. However, many interacting systems both send and receive
events.
Step 5. Show input events as arrows from interacting
systems to the system being modeled.
Step 6. Show output events as arrows from the system
being modeled to the interacting systems.
Step 7. If desired, show input and output objects
as small arrows. The small arrow should point in the direction
that the input object or output object is passed.
Step 8. Walk-through each input event to the system
possibly leading to one or more output events.
In creating the system interaction diagram, we must answer the following questions:
What are major uses (use cases) of the system?
What is the system and interacting system?
What are the input events (stimuli) to which the system must respond?
What event information (data) is passed to the system in each event?
Who is the sender of the event, e.g. an interacting system?
For each input event what are the output event?
What output event information (data) is passed from the system in each output event?
Who is the receiver of the output event, e.g. an interacting system?
The system interaction diagram (events) of the TV
Control System is shown below. It shows the TV Control System
receiving the input events from the TV Buttons Device. It shows
the TV Control System initiating output events to the Speaker
Device, Channel Device, and Storage Device.
Alternatively, you may create the system event flow diagram described by Rumbaugh [Rumbaugh-91]. The form of this diagram is shown below.
The system event flow diagram for the TV Control System is shown below.
The purpose of the system interaction scenario is
to show the time ordered sequence of input and output events.
It lists and describes all the input events to which the system
must respond and all the resulting output events from the system.
This section describes the system interaction scenario with its
purpose, steps to create, and a sample system interaction scenario
(events). The following are the steps to create the system interaction
scenario.
Step 1. Start with the system use case diagram and
descriptions. Identify input events from interacting systems to
which the system must respond. Question is "What occurs in
the external environment to which the system must respond? "Group
input events by user type, user role, or user category, e.g. user,
customer, operator, accountant, etc. Describe each input event.
For each input event state timing, priority, throughput, and other
requirements. Identify output events from the system to interacting
systems. Question: For each input event what are the output events?
Step 2. Create the system interaction scenario. For
each input event state the resulting output events in a scenario
(script). State the simplest scenario (script) first then add
variations and errors later. The recommended table includes the
following headings: sequence from 1 to ?, interacting system that
sends the input event, the system that receives the input event,
the input event name, and remarks. A sample CASE tool script is
TABSYSIN.SCT.
Step 3. Using the system interaction diagram (events),
walk-through all input events to output events to check completeness.
Step 4. Specify each system and interaction by completing
the system and interaction input forms. Create the system and
interaction (events) specification report. A sample CASE tool
script is RPTSYSIN.SCT.
Step 5. After the initial system interaction scenario has been completed, update the scenario with comments, decision trees, or additional scenarios for variations, boundary conditions, and exceptions.
The following are the system interaction tables for the TV Control System. The sample CASE tool table generation script is TABSYSIN.SCT.
System Interaction Scenario for Operate TV Use Case
| Sequence # | Sender System | Receiver System | Invoked Operation | Description |
| 1 | TV Buttons Device | TV Control System | turnOn | Input Event |
| 2 | TV Control System | Storage Device | retrieveVolume | Output Event |
| 3 | TV Control System | Speaker Device | setVolume | Output Event |
| 4 | TV Control System | Storage Device | retrieveChannel | Output Event |
| 5 | TV Control System | Channel Device | setChannel | Output Event |
| 6 | TV Buttons Device | TV Control System | turnOff | Input Event |
| 7 | TV Control System | Storage Device | storeVolume | Output Event |
| 8 | TV Control System | Storage Device | storeChannel | Output Event |
System Interaction Scenario for Manage TV Volume Use Case
| Sequence # | Sender System | Receiver System | Invoked Operation | Description |
| 1 | TV Buttons Device | TV Control System | increaseVolume | Input Event |
| 2 | TV Control System | Speaker Device | setVolume | Output Event |
| 3 | TV Buttons Device | TV Control System | decreaseVolume | Input Event |
| 4 | TV Control System | Speaker Device | setVolume | Output Event |
System Interaction Scenario for Manage TV Channel Use Case
| Sequence # | Sender System | Receiver System | Invoked Operation | Description |
| 1 | TV Buttons Device | TV Control System | increaseChannel | Input Event |
| 2 | TV Control System | Channel Device | setChannel | Output Event |
| 3 | TV Buttons Device | TV Control System | decreaseChannel | Input Event |
| 4 | TV Control System | Channel Device | setChannel | Output Event |
The system and interaction specification lists detailed information about each system and interaction (event). You may create a text specification report for each system and interaction (event). The sample CASE tool report generation script is RPTSYSIN.SCT.
The purpose of the system state diagram is to show
the stimulus response behavior of a system in terms of input events,
conditions, states, and output events. The system state diagram
(state transition diagram) specifies stimulus response logic for
a system. It specifies the pattern of input events, conditions,
actions, and states. Definitions and steps are presented in the
previous section on "Creating the State Diagram".
The steps to create the system state diagram are
listed below.
Step 1. Determine if the system has modes of behavior,
e.g. states. A system has states if an input event results in
different output events based upon the mode of the system.
Step 2. Identify the input events and any conditions.
Step 3. Identify actions, e.g. output events.
Step 4. Identify the states of the system.
Step 5. Identify any activities, e.g. continuous
operations in a state.
Step 6. Create the state diagram.
Step 7. Walk-through the state diagram by tracing
each input event leading to output events.
Step 8. If desired, generate or create code based upon the state diagram.
The following is the system state diagram for the TV Control System Case Study. The applicable system state diagram is shown below. It shows that the TV Control System has three states: OffState, OnState, and Terminal State. It shows the state transitions caused by each input event.
The purpose of the system state transition table is to show the stimulus response behavior of a system in terms of input events, conditions, states, and output events. The system state transition table specifies stimulus response logic for a system. It specifies the pattern of input events, conditions, actions, and states. Definitions and steps are presented in the previous section on "Creating the State Diagram".
The following is the system state transition table for the TV Control System Case Study. The sample CASE tool table generation script is TABSTATE.SCT. This table shows the states, input events, conditions, actions, and next state for all transitions for the TV Control System.
| State Name | Input Event Name | Transition Condition | Transition Action
(Output Events) | Transition Next State |
| OffState | turnOn() | StorageDevice.retrieveVolume SpeakerDevice.setVolume StorageDevice.retrieveChannel ChannelDevice.setChannel | OnState | |
| OnState | increaseVolume() | SpeakerDevice.setVolume | OnState | |
| OnState | decreaseChannel() | ChannelDevice.setChannel | OnState | |
| OnState | increaseChannel() | ChannelDevice.setChannel | OnState | |
| OnState | decreaseVolume() | SpeakerDevice.setVolume | OnState | |
| OnState | turnOff() | StorageDevice.storeVolume StorageDevice.storeChannel | Terminal |
You may create a text specification report for each state and transition. The sample CASE tool script is RPTSTATE.SCT.
In the system dynamic model, new terms are added for input events, output events, and states. The update for the data dictionary for the TV Control System is shown below. The sample CASE tool table generation script is DDSTATE.SCT.
| Entity Name | Type of Entity | Enclosing System | Description |
| OffState | State | TVControlSystem | Initial State |
| OnState | State | TVControlSystem | -- |
| Terminal | State | TVControlSystem | Terminal State |
The following are various criteria and questions
to ask in evaluating the adequacy of the products describing the
system dynamic model.
- Have we identified the "top 10" input
events to which the system must respond?
- Have we identified the output events that are responses
to the input events?
- Have we identified the scenario of each input event
leading to output events?
- Have we identified the states of the system?
- Have we "walked through" the system interaction diagram (events), system interaction scenario, and system state diagram from each input event to output events?
The system dynamic model is the description of the stimulus response behavior of the system. Stimulus response behavior is sum of stimuli that a system detects and the responses to those stimuli. At the system level we describe stimulus response behavior in terms of input events leading to output events. Some systems have modes or states which are described in state diagrams. The dynamic model consists of documentation products, e.g. system interaction diagram (events), system interaction scenario, system state diagram, and data dictionary.
The purpose of the system functional model is to describe transformations (operations) and input and output objects for the system as a whole. The system functional model corresponds to the OMT Functional Model at the system level. We identify the input objects and output objects for the system as a whole. We identify system operations. The system operations represent the system's behavior. Transformations occur in the system operations. As shown below, a system operation may have preconditions, postconditions, and exceptions. Later at the class level, we document the transformations in each class and object operation.
Objective - The objective
of the system functional model is to define the input objects,
output objects, and system operations at the system level.
Entities - The key entities
are the system being modeled, input objects, output objects, and
system transformations.
Products (Diagrams and Text) - The key products are the system operation table and specification.
System Operation Specification - Describes each system operation in terms of preconditions, postconditions, exceptions, and transformations.
In the functional model we have specify transformations
of object values in operations. In the functional model, we specify
how object values are transformed in operations. Follow these
steps.
Step 1 - Start with the system requirements,
system drawing, system block diagram, and system diagram
(OMT class diagram notation) which show the system operations.
Step 2 - Update the system diagram (OMT notation)
to show all system operations.
Step 3 - Update each system operation specification
input form to describe each system operation, e.g. formulas, expressions,
equations and correctness assertions. Assertions include preconditions,
postconditions, and invariants for each operation.
Step 4 - Create the system operation table
and system operation specification. The sample CASE tool
scripts are TABOPER.SCT and RPTOPER.SCT.
Step 5 - Check and update consistency between the diagrams, specifications, and other models. Check all diagrams and text specifications for the consistent spelling, capitalization, and meaning of all names.
The purpose of the system operation specification
is to describe each system operation. The system operation specification
describes each system operation in terms of its name, description,
input parameters, output parameter, output type/class, preconditions,
postconditions, exceptions, and transformation. The steps to create
the system operation table and specification are listed below.
Step 1 - Examine the system operations on the system
diagram (OMT class diagram notation) and the input events on the
system interaction scenario. Typically, there is a system operation
for each input event.
Step 2 - Describe each system operation in the system operation specification.
The following is the system operation specification for the increaseVolume system operation in the TV Control System Case Study. It shows the input parameters, precondition, precondition exception, transformation, postcondition, postcondition exception, and output parameters.
The system operation table for the TV Control System is shown below. The sample CASE tool table generation script is TABOPER.SCT.
| Operation Name | Input Parameters | Transformation | Return Type |
| turnOn | volumeSetting = aVolumeSetting;
channelSetting = aChannelSetting; | ||
| increaseVolume | volumeSetting = volumeSetting + 1; | ||
| decreaseVolume | volumeSetting = volumeSetting - 1; | ||
| increaseChannel | channelSetting = channelSetting + 1; | ||
| decreaseChannel | channelSetting = channelSetting - 1; | ||
| turnOff |
The system operation specification report for the increaseVolume
operation is shown below. The sample CASE tool report generation
script is RPTOPER.SCT.
Operation Name: increaseVolume
Operation Return Type/Class: None
Operation Parameters: None
Operation Access: public
Operation Transformation: volumeSetting = volumeSetting + 1
Operation Precondition: volumeSetting < maxVolumeSetting
Operation Postcondition: volumeSetting = oldVolumeSetting + 1
Operation Exception Type: N/A
Operation Exception Name: N/A
Operation Classification: modifier
Operation Concurrency: sequential
Operation Code: N/A
Comment 1: The increaseVolume operation increases the current value of volumeSetting. This operation is invoked by the input event increaseVolume. This operation invoked the output event SpeakerDevice.setVolume.
Comment 2:
Comment 3:
The following are various criteria and questions
to ask in evaluating the adequacy of the products describing the
system functional model.
- Have we identified the "top 10" input
and output objects that are passed into and from the system?
- Have we grouped smaller input and output objects
into larger structured input and output objects with strong cohesion.
For example, have we created a large structured object, aPerson
that groups together several smaller objects, e.g. personAddress,
personPhones, etc.
- Have we identified the "top 10" system
operations that represent the most important functionality of
the system?
- Does the customer (requester of the system) agree that we have clearly stated the scope (boundary) and the functionality of the system?
The system functional model describes input objects, output objects, and system operations. Typically, a system operation transforms (changes) an input object into an output object. For each system operation we describe the operation transformation, preconditions, postconditions, and exceptions. The system functional model consists of documentation products, e.g. system operation specification.
In this chapter we presented "how to" create system level models for the TV Control System. We presented a complete System Object Model, System Dynamic Model, and System Functional Model for the TV Control System.