JP2HTML PROJECT
OBJECT ORIENTED & DESIGN (97f522)
PROF. ROBERT LECHNER
The Juice Plant is an extended case study based on the text
"Object Life Cycles" by Shlaer and Mellor [Prentice-Hall 1992].
The Juice Plant simulation was implemented as a complete
proof-of-concept demonstration for our COOL (CASE O-O Laboratory)
Project. Our COOL framework is described in this overview:
CASE Object-Oriented Laboratory
COOL includes a database code generator (GEN) in addition to the three
components BDE, SMA and LCP and the Juice Plant application
entities described here.
The Juice Plant Browser demonstrates a browsable
hierarchy of Entity-Relationship and State Model diagrams.
These diagrams graphically represent a complete set of structural
and behavioral models for the active and passive classes
that comprise our version of the Juice Plant.
To browse the Juice Plant architecture demo, go to:
Note: The top-level diagram is really a Domain Diagram,
for the Life Cycle Prototyping Framework, which includes BDE,
the Block Diagram Editor, SMA, the State Model Architecture,
and the Juice Plant application itself.
The Juice Plant application is partitioned into two sub-domains:
passive classes for the plant layout (piping diagram) and
active classes for the process control software components.
(TBD: Object/Class Communication/Interaction diagrams.)
These diagrams were drawn by our BDE (Block Diagram Editor).
For a look at BDE's user interface, see
To make BDE's Block Diagrams browsable
was a documentation goal for our COOL framework.
For this we developed a file conversion tool called bde2ht.
Bde2ht converts BDE block diagrams into .gif formats
and associated html files with embedded IMAGE and MAP elementa.
Data model nodes (entity classes) may contain links to
entity attribute definitions and to entity class methods.
State-event model nodes (control states - see Note 1) may contain
links to expansion diagrams and to the active class methods
which are invoked during state transitions.
Bde's data model has always suported an unused extension capability
of linking any node of one diagram to its expansion as a diagram
within the same file, if it exists. For the current browser, we
generalized the hotspot to a grid of hotspots within a bde node.
This grid is configurable with a fixed number of grid rows and columns.
Bde2ht currently splits BDE Diagram nodes into one row of
three 'hotzone' cells:
- Left cell: Linked to an Action spec for a State Transition Diagram (STD)
or (TBD) an Entity Attribute list for an Entity Relation Diagram (ERD).
- Middle cell:
- For Entity nodes of an ERD that represent Active Classes
(those with multiple state memory) and State nodes of an STD which have a
submachine expansion, the middle cell links to the referenced state diagram.
- For Entity nodes of an ERD that represent Passive Classes (those with
only one state that contains all its behavior), and for STD state nodes
without a submachine expansion, the middle cell links to the source code
which implements class behavior or State Action Routine.
- Right cell: Linked to Graph Caption (TBD; this text is currently irrelevant -
see Note 2).
Another format conversion tool, bde2sm, translates State Diagrams into a database
of State-Event Models that can drive an executable prototype for an arbitrary application.
The State Model architecture ER Diagram shows how this database represents event-driven
control flow as inter-state transition links labeled by event-types.
Our executable prototype engine (called LCP xior (Life Cycle Prototyper)
interprets the SMA database content to simulate concurrent event-driven processes
The browser demo includes data models for BDE and the State Model Architecture
(SMA) interpreter, as well as for the Juice Plant's Active and Passive Classes.
The SMA Nodes (entity classes) are linked to the source code method files.
Data models (ERDiagrams) for the JuicePlant have Nodes representing Active
and Passive Classes:
- Active Class nodes are linked to State Diagrams.
Nodes on State Diagrams are linked both to (crude) specifications
and to source code for their Action Routines.
- Passive class entities are nodes on ER Diagrams without State Diagrams
- for example, the Juice Plant piping layout and all SMA Nodes.
These are linked to the corresponding source code file for the entity type.
State models have been drawn with BDE for most Juice Plant Active Classes
and for two generic 'Service Classes', Operator (OP) and Timer (TI).
OP and TI Classes are part of LCP, independent of the application
(see Note 3).
The inter-node links on these state diagrams represent state transitions
with event-type labels.
A Moore-style action execution model is implemented:
actions are executed upon state entry. However, these actions may include a
switch(event) statement. This makes them equivalent to a Mealy model
since action case blocks may be defined independently for each incoming
transition (see Note 4).
Notes:
- Control States partition the data state into equivalence clases
determined by prior state history.
Active Class attributes contain much more state data that does not
significantly influence control flow or state transitions.
E.g., the actual balance of an overdrawn bank account
and the transactions leading up to this status do not have much influence on
future behavior.
- For ER Diagrams, this cell should link to the schema file data definitions
for this entity type or class. (Goal: Use BDE to create HN--->HA childlist text,
then hide and link to this since it takes up too much diagram space.) - RJL 020822.
- The Timer class has since been replaced by a Timed-Event Queue Manager
which manages a que of future scheduled events that provide Timer functions.
- Event labels currently do not include guard conditions, but each
event-specific case block may include sub-branches depending on guard conditions.
Simulation of true Mealy state models with guarded transitions may
require additional states.