RJLRef: $PH\06s524\SWFCh89Notes_rl_sf_rl060318.txt
 
Subject: Comments on Chapter 8 notes. 
Here are my notes on your notes: Sorry for the delayed recovery. 
I'll see you Tues eve. 
(5:45, since I may attend the Biodegradable Plastics seminar 4-530 Kitson 310.

Bob Lechner
--------------------------------------------
Message 14/1197  From Scott Frye 		Mar 14, 06 09:25:48 AM -0500  
>[COOL-LCP is deterministic; guard expressions can be evaluated in 
intermediate states created for this purpose.]
But the user can make different choices that would allow different paths 
to be taken.

This whole deterministic thing has me confused.  I understand deterministic and non-deterministic as described in the software foundations class I took several semesters ago.  But what I got from that was that programs have to be deterministic for a computer to evaluate them.  

[RJL: A computer is a DFSA (with a LIFO stack). the only way to make 
a program non-deterministic  is with a (pseudo-)random  number generator. 
Dijkstra introduced ND programs meaning intentional randomization 
so he could  formalize constraints that guarantee serializability 
(so it doesn't MATTER what branch a NDFSA takes, because they all 
provably yield the same external behavior). 
This is a key property of  distributed systems - 
because time delays make the order of event arrivals unpredictable: 
non-deterministic behavior arises from uncertain arrival order. 
DBMS reliability usually requires this property.]


Here we are discussing non-deterministic programs, which to me means 
that the actual code MUST be deterministic in the sense that for a 
given input, a particular piece of code is executed, but the program 
is viewed as non-deterministic from the point of view that it must 
be able to handle a variety of inputs.

[RJL: (No!) Here, ND arises from unpredictable order and kind of events 
during interaction with humans. A program is always predictable 
(given enough code-readingi time :-) An operator's behavior is never 
predictable (computers can detect erratic operator  behavior for good 
purposes (fail-safe jet-piloting, car driver falling asleep).]

I understood this statement in the text to refer to the fact that 
a state machine for a deterministic system is the simplest case 
because there is only one path that has to be modeled.  However 
if there are choices (based on user input) at each state, 
the algorithm becomes more complex.

Am I understanding this correctly?  Based on this, 
is COOL-LCP deterministic or non-deterministic?

>Runtime method execution proceeds by responding to events which cause 
transitions from one current state to another, and executing one state 
action per transition. 
[RJL: or one action per new state isserted on the transition itself.]

Here it seems that deterministic means that only one transition can be
executed from a state.  In other words a specific event can't result in the
spawning of two paths that will continue in parallel thru the state machine.

[RJL: that is correct. LCP expects the designer of the State Model 
(particularly its Guard Conditions and event-dispatching discipline) 
to insure dis-jointness and therefore order-independence  
(and freedom from side-effects, to the extent this matters). 

(It is the model designer's responsibility to Avoid non-disjoint Guards, 
whose behavior MAY depend on the order of evaluation. 
This is a maintainer's nightmare (including mine with bde/src/*ops.cc) 
and prevents an optimizer from re-ordering code to improve performance. 

Avoiding non-determinism is not the job of LCP's generic interpreter. 
The designers of a specific model and the implementers of  its
actual transition guards and action code (event generators) must do this. ]

>"Unfortunately, these specifications are insufficiently precise to make UML
> usable on its own as a language for defining machine-processable artifacts."
>[UML2 is better.]

Do you know what they added to UML2 that makes it better?  
Or what was lacking in UML1?

[RJL: 
UML evolution is explained in its doc set: 
v1.4 added Object Constraint Language (OCL). 
[Ref: Warmer & Kleppe: The OCL, AWL 1999 - a nice small book]
v1.5 added Action Semantic/Spec  Language (ASL) (Steve Mellor took part).

Still TBD (and way behind schedule) is UML v 2.0 
which adds Model-Driven Architecture (MDA). 
The OMG vision is that  MDA's Platform-Independent Models (PIM) can 
automatically be transformed into compilable code for a  
Platform-Specific Model (PSM) implementation, by a PS-translator.]

...
>"Layout information is normally kept in the same physical store as the elements
>in the abstract syntax graph, so that the information can be persisted and
>serialized in the same way."

I seem to remember some conversations two semesters ago, during one of
your lectures, discussing if BDE should keep these separate or together.

[RJL: That BDE discussion could have been about one of two issues:

(1) Retaining world coordinates from graphic diagrams in the outputs 
of converters like bde2SM for LCP and bde2schema for GEN. 
Then these converters would be info-lossless (reversible): 
the diagram 'artwork' would be reconstructible from schema or SM  files.
E.g. STD and EERD layout need node size position and link bendpoints, 
schemas and LCP State Models only need topological abstractions 
which ignore geometry.

(2) Merging metadata tables SV, TT, TA etc. from schema.msdat 
into bde design data files. Pr_util has this metadata compiled in, 
but loading it into objects permits  its runtime use for reflection  
(e.g. auto-generating column header labels with field names
for display and printout and error-reporting.).


> "If this trend continues, it will not be long before software specifications
>contain large amounts of declarative metadata, in addition to imperative logic,
>using serialized formats intended more for tools than for human consumption."

This is already happening with Microsoft Visual Studio.  More and more things
can be done in the visual designer.  Not just visual components, but also
adding a data connection or a timer or other things with no visual component.

[RJL: I am not surprised. The competition is also touting Model-Driven tools.
All the tool-vendors need them to keep competitive with each other. 
The question is: 
How much should the small development company or in-house SW dept. 
invest in such toolsets?
I suspect most will depend on Visual Studio/C# or Eclipse/Java 
because these skills will tend to have the fastest growth rate 
among most new hires. But the innovators will train workers 
to use models and automation to leverage re-use in their product line.]