Subject: how and why BDE came about, 
and its place within the COOL framework.
RJLRef: $PH/COOL-FAQ/COOL_Framework_Evolution080126.txt
[$PH is either ~lechner/public_html or www.cs.uml.edu/~lechner]

COOL Framework Component Evolution and Motivation

> From jingyoko@hotmail.com  Thu Nov 17 12:01:46 2005
> ... my question asked for documentation written by a designer 
> before starting writing code, NOT schema declarations. The reason I asked is 
> that I want to understand how and why the BDE came from and its structure.

In response to Jing's question, here are some more 
BDE sources (for the Why, more than the How):  
[Don't look here for BDE's GUI code design. 
Look for a vision of an evolving code generation framework 
with automatic code generation and protoype evaluation goals.]

R Lechner
===================================================

(1) Why chGENcpp?
--------------------------
When SWEng was required of ALL MS/CS candidates,
I tried to understand project code that was well-documented
based on SSAD unencapsulated ad-hoc data structures 
that populated their Data Flow Diagram designs.
(Legions of graduate students who produced this code 
were using the latest contemporary Structured Analysis 
and Design (SSAD) methodology, but SSAD failed to 
encapsulate their ad-hoc data structures. 

Here I can quote Fred Brooks in "The Mythical Manmonth" 
A-W 1975 (Anniversary Edition, A-W 1995), on page 102: 
"Representation Is The Essence of Programming...
...This is where the heart of a program lies.
Show me your flowcharts and conceal your tables,
and I shall continue to be mystified. Show me your 
tables, and I won't usually need your flowcharts;
they'll be obvious."  

When Brooks first wrote TMM in 1975, Charles Bachman 
had already generalized those tables into network data models
(Data Structure Diagrams), which later morphed into 
Entity-Relational Models extended with inheritance, or 
UML class models. Flowcharts evolved into Data Flow Diagrams 
of Structured Analysis (SA). Distributed systems
required further generalization of DFDs, into Interaction 
Diagrams among process nodes whose internal behavior obeyed 
constraints modeled by event-driven State Transition Diagrams.

I soon gave up trying to read ad-hoc data structures 
and decided to invent a data-modeling-first
(but-not-only) framework that would standardize data 
structures by basing them on network/relational models.
The first framework component was chgen, which can generate
persistent database code automatically for any application 
with arbitrarily complex data models (including all three
COOL framework components). [Caveat: scaling up data models 
requires separate subsystem namespaces (TBD).]

GEN is an application itself: GEN's data model is 
the meta-model SV-->TT-->TA: (SchemaVersions contain TableTypes 
which contain TableAttributes). This metadata is extracted 
from schema file input, which may come from BDE. 

GEN's 2D graphic model (ERD or class diagram) was inspired 
by Charles Bachman's Data Structure Diagrams (DSDs) 
and his Network Data Model and Network Database.
These were the basis of Honeywell's Integrated Data Store 
(IDS) and Cullinane's IDMS. It spawned a Network DB indusry 
that competed effectively with IBM. Peter Chen (then at  MIT) 
invented his Entity-Relationship Diagram for RDBs 
after spending a summer at Honeywell with Bachman.
Surrogate pkeys became part of chGENcpp after they were
advocated by EFCodd's RMT (Relational Model/Tasmania).
Bachman, Codd and Chen all won ACM's Turing Awards.

ChGENcpp can generate a persistent database code library 
automatically from a schema file representing a
network/relational data model for ANY application.
I believe in practicing what I preach, so GEN 
is used by the other two framework components, 
BDE and LCP.

====================================

(2) WHy BDE?
--------------
BDE was first planned to represent 'horizonal' data flow
for Data Flow Diagrams (DFDs) with (HG, HN, HL),
and 'vertical' parameter flow along call tree bran ches 
for structure charts (call trees) with  (VG, VN, VL).
I soon realized that BDE could be used as a
'general purpose' graphic front end, even if restricted 
to a sub-domain of generic block diagrams, with style
defaults and filters to capture the semantics 
of alternate diagram types.

First two on the (new) list were static conceptual
(information) models and dynamic behavioral (state) models.
Thereaftter, VG/VN/VL went away and HG/HN/HL became
general purpose graph, node and link components.

In designing BDE, BDE's data model came FIRST! 
BDE's current and future data models are shown in
$PH/COOL-BDE/bdeUG_2005DataModels.ppt

[This I advocate for all apps: Before designng code, 
its info model must be comprehended. The core content
and goal of BDE's data output follows the directed graph 
(node + edge) pattern. This came from Electronic CAD 
(layout and connectivity of printed circuit boards 
and VLSI chips).  The CASE Data Interchange Format
committee (CDIF) grew out of its Electronic counterpart 
(EDIF) (In my view, EE came from Physics,
CS came from Math/Physics, and SWEng came from CS/EE.)

Version control requirements for design data justified 
RDB constraints for data persistence. Bde's  data model 
supports multi-level composition because real-world apps do.
(They used the Composite Design Pattern  before OOP.)
Together with our lack of experience at OOP, these motivated 
BDE and LCP reliance on delegation instead of inheritance.

Can you imagine how an ad hoc OOP version of BDE, without 
constraints to insure flat ASCII data table file format, 
would have to be retrofitted to achieve persistence and 
version control capabilities? This is exactly the problem 
we have with the GUI initialization front end of BDE,
because I neglected to understand X11's data model FIRST! 

=======================================

(3) Why LCP?
---------------

Last but not least came the LCP component for dynamic control 
of event-driven distributed behavior. State models from BDE 
supplied the design documentation and also the input to the 
LCP interpreter.  LCP manages an event queue and dispatches 
runtime control flow (i.e. it simulates a prototype of a
system of concurrent processes). 

GEN provides LCP (or BDE, or any other application based on GEN) 
with encapsulated logging and replay options 
for capturing both data changes and state+event logs.
The history captured by such logs can be post-processed into 
sequence diagrams for BDE to display as test-case post-mortems.
[StateMate had this capability years ago: DHarel and MPoliti, 
Modeling Reactive Systems with Statecharts, McGraw-Hill New York.]

The language that really motivated LCP, before Harel's StateMate 
and Shlaer-Mellor's Object Life Cycles [PH 1992] was presented in:

RLechner and WStallings: TRAIL: Tabular Rule-Action Interpreted Language
for Mini-system Programming, ACM National Conference (circa 1975).

TRAIL was a graphic design language for developing business apps.
Its notation came from Civil Engineering Prof. Steven Fenves at CMU.
A Java-like interpreter was written to execute TRAIL state diagrams
(in limited memory) on the Honeywell Level 6 Minicomputer. 
Honeywell marketeers killed this SW concept as too far-reaching.

iLogix' StateMate product (now Rhapsody from Telelogic) is a very 
elegant proprietary tool approved by OMG for its standard UML2/MDA.
LCP is a much simpler and publicly accessible tool for use in 
academic research toward the pedagogy of teaching platform-independent 
dynamic modeling.


==========================

(4) Why the COOL Framework?
--------------------------

LCP BDE and GEN interface well and can collaborate: 

A. BDE can be used to define the data model of an application
including but not limited to all three COOL Framework components.

B. GEN supports navigation of persistent data 
including logging and replay in BDE and LCP;

C. BDE can be used to design a hierarchy of state models;
The data and state model diagrams are web-browsable with
links from nodes to expansion diagrams and/or program text.
($PH/COOL-BDE/whereis_bde2ht_demos.hlp)

D. LCP can simulate event-driven distributed behavior by 
executing code for the event-driven computations 
that must occur at the leaf nodes;

E. BDE can visualize the results of LCP's interpretive execution.

Code for leaf nodes (state actions) is atomic = non-interruptible
at that state model's level of granularity or decomposition.
(It can even be non-branching, if state models are decomposed 
far enough, although this is unlikely to survive beyond 
prototype evaluation due to performance problems.)

LCP's data model is shown in slide 3 at $PH/COOL-LCP/JP2html
LCP provides a superclass ActiveClass (AC) for each 
application class (each Entity Type with complex 
state-dependent transactions).  Each AC aggregates 
the state models (SM) for complex methods of that class.
Application classes delegate method execution to their
AC and its corresponding SM's for methods 
that require internal control state memory.

States (ST) can use the Composite Design Pattern to define 
their expansions into lower-level State Models (SM)
by expanding a new subtype of State ST (the composite subtype CS) 
into its expansion SM. This composite state CS has a new 
second fkey SMid2 to its expansion as a State Model.

BDE has a corresponding hook to expand a node HN 
of diagram HNid1 into a nested diagram HGid2  
by adding fkey HGid2 to class HN. This enables bde2htm 
to create 'hotspot' links in BDE nodes.

Caveat: There is no free lunch:

  i. Leaf node state actions must be implemented directly in code.

 ii. LCP is an interpreter, whose performance degrades when state
models are nested to a low level such as basic blocks.
(There are much better ways to do lexical analysis.:-)
Prototypers need not worry about performance unless
it slows down testing or distorts real-time behavior.

iii. Future goal: Add a chGENcpp option to compile low-level 
LCP state models instead of interpreting them. 
High-level models can still be interpreted.

-------------------------------------
Originally sent as email (COOL_Framework_Evolution051117.txt):
To: jingyoko@hotmail.com (jingyoko@hotmail.com Tan)
Cc: ralmonte@cs.uml.edu (Almonte), mandava_s@yahoo.com, smandava@cs.uml.edu, jtan@cs.uml.edu
, jingyoko@hotmail.com, uguntu@cs.uml.edu (Guntu), kpatel1@cs.uml.edu (Patel), lechner@cs.um
l.edu (Bob Lechner), sfrye@cs.uml.edu (Scot Frye)