ECE 473573 Class Notes

1
ECE 473/573 Class Notes

• Towards a Systems Methodology for Object-Oriented
  Software Analysis

2
A Short Review of the System Modeling Methodology
Hierarchy of System specifications
Table 1 Levels of System Knowledge.
3
Modeling
Association Mapping (Structure-to-Behavior )
Level 0 Level 1 Level 2 Level 3
Downward direction
Upward direction
preservation relation or system morphism
4
System morphisms as a fundamental means for
building abstractions
Figure Morphisms between a detailed model and
a coarse model
5
Use case driven design in the system modeling
perspective
- The use case driven design process compares to
the system methodology as use cases are a special
form to record I/O behaviors. - Object
oriented models with associations and
collaborations represent system descriptions at
the coupled system level. Object oriented
analysis is a process to go from behavior to
structure, from use case descriptions to an
object oriented class/object diagram. - The
main deficit of current object oriented modeling
practice compared to the system methodology is
its vague concept of building abstractions. In
particular in dynamic modeling, concepts for
building abstractions are missing.
6
Improved Software Development Process

• The proposed improvements of the standard
  Unified Process for software development
• follow three main lines
•    instead of the usual user-centered approach,
  a system-centered approach to find
• and cast use cases
•   a general architecture for analysis models of
  embedded systems which suggests
• a more fine grained classification of objects
• . an approach to model entity objects based on
  interface descriptions and
• system morphism concepts

7
System-centered approach for use case
descriptions

• In a system-centered approach one proceeds as
  follows
•  
•          First try to get an understanding of
  the interfaces to the system, in particular,
  which events are triggered by the actors and
  which by the system.
•          Then look for events which initiate
  behaviors which will lead to state changes within
  the software system such events may come from
  some actor or come from the system itself (and
  then are scheduled.)
•         Finally, set up the use case for the
  input/output behavior following the triggering
  event.

8
Architecture for embedded systems
9
In the architecture information objects of
different types are distinguished as follows
           State objects State objects are
similar to entity objects. They have to interpret
the inputs and measurements from the real system
and store information about the real system
behavior.          Result objects Result
objects are objects which store computations.
Usually they summarize or filter the state
information to report those to the upper level.
         Task and planning objects Those
objects are supposed to store tasks and goals
received from the upper level. Also planning data
may be generated based on the tasks received.
         Control models Control models are
used to carry out the control tasks. The planned
tasks are broken down into concrete control
sequences which contain the sequences of commands
which have to be issued to the lower level
system. Based on the feedback messages received
and the state updates, the control models have to
be able to decide on the actions.
10
Several interface and control objects take over
the responsibility to update the information
structures accordingly and realize the flow of
events through the system in fulfillment of a
particular use case. They are as follows
           Command interpreter Command
interpreters receive commands and goals from the
superior layer and generate tasks and plans and
store them in the planning data base.         
Task sequencer A task sequencer will select
tasks or plans from the data base and forward
those to the control model which are responsible
to execute those.          Command generator
The command generators read the information from
the control models and issue commands to the
lower level system.          Input
interpreter The input interpreters function as
input interface objects to the real system. They
encapsulate the transformation of sensor data
into higher level information or handle the
feedbacks received from the subordinate workers.
Based on the information received they update the
internal state information. They also supervise
the reactions from the real system for errors.
         Result calculator The result
calculators observe the state information
gathered and compute from those higher level
information, i.e., they prepare information for
usage at the higher levels. Often this means
filtering relevant information out of the
magnitude of available state information or
computing summary statistics.          Report
generator The report generator reads the results
computed and forwards those to the interested
upper level components.          Coordinator
Finally, one or more coordinators are employed as
central control objects which have the
responsibility to coordinate the whole process.
In particular, they check if the observed process
run is in correspondence with the planned one
and, if necessary, update the planning data
accordingly.
11
System morphisms as a means to build information
models
Figure real system and state information
models
12
Figure State information models and result
objects
13
Figure Real system and inverse control model
14
Application Example Elevator Control System
Figure Actors and input/output interfaces
15
Defining the system environment and the
input/output interactions
         the buttons for calling the elevator
         the buttons in the elevator to define
the destination floors          the sensors to
signal the arrivals of the elevator in the floors
         the door which contains sensors to
signal that the door is open and closed, a light
barrier to signal that the door is blocked, as
well as a motor to open and close it         
the motor to move the elevator up and
down          a supervisor which gets status
reports on the elevator.
Figure Use cases for the elevator control
system
16
Identifying and Describing Use Cases
         Call an elevator Pressing the call
button usually will only lead to a registration
of the call. Only when the elevator is idle and
parked, will it be immediately started to
service the call.          Enter destination
Pressing the floor button will register the floor
as a destination floor.          Arrival to a
floor A signal of an arrival of the elevator in
a floor initiates the use case that the elevator
eventually stops at the floor, opens the door,
and allows people to leave the elevator and new
passengers to enter. We assume that this use case
is finished with the schedule of a departure
event and the departure use case follows.
         Departure This use case is initiated
by the scheduled departure event within the
elevator control system. The door is closed, the
direction is determined, and the elevator starts
to the next destination floor.
Figure Use case arrival to a floor
17
Finding Information Objects
         Planning objects (Figure (a))
Obviously the calls for elevators as well as the
desired destination floors entered by pressing
the buttons represent tasks the elevator is
supposed to carry out. The call buttons give us
the information regarding the floors for which
there are open calls. This information is stored
by object OpenCalls which has two sets of floors
for which open calls exist up and down.
Analogously, an object DestinationFloors contains
a set of floors where current passengers desire
to be let off.          State information
objects (Figure (b)) The sensor inputs showing
the arrivals in the floors and status information
about the door provide information about the
current behavior of the elevator. Two objects
Elevator and DoorStatus are supposed to store
this information. The Elevator object has a
reference to the floor object which represents
the current floor at which the elevator resides.
The DoorStatus object stores the information
about current status of the door using an
enumeration attribute.          Control model
objects (Figure (c)) The outputs to the motor as
well as to the door are control commands and
therefore have to be handled by control models.
The MotorControl object shown in Figure 17.11 (c)
works without feedback. It is triggered by
commands goUp, goDown, doStop and forwards those
commands to the motor. Note, although this
control model is simple, it is useful to filter
out forbidden control sequences, e.g., that an up
command directly follows a down command. The
DoorControl model is a control model with
feedback. Therefore, the state information of the
DoorStatus object is merged into the DoorControl
model. The model receives inputs closeDoor and
openDoor from other parts of the elevator control
system and forwards those to the door. And it
receives feedbacks open, closed and blocked from
the door. Note, how the control model reflects
the expected behavior of the door, i.e., it is an
inverse model of the door.          Result
objects (Figure (d)) Finally the outputs to the
supervisor as well as the button lights turned on
and off report on the current performance of the
system. The lights status directly corresponds to
the planning objects and therefore no additional
result objects are required. The StatusInfo
object gathers the information for the supervisor
from other objects within the system. The floor
last visited is stored as an association to a
Floor object. The current direction corresponds
to the state of the MotorControl object.
18
Figure Information objects in the elevator
system
19
Putting it together Realizing the use case
behaviors
Figure Collaboration for arrival in floor
use case