From lechner@cs.uml.edu  Fri Feb 17 17:50:13 2006
From: Bob Lechner <lechner@cs.uml.edu>
Subject: Scot Frye + RJL comments: i
To: sfrye@cs.uml.edu (Scott Frye)
RJLRef: $PH/06s524/SWFChptr6Notes060217_sf_rl.txt
[was $PH\06s524\SWFCh5and6BDENotes.060217.txt]

Message 7/1090  From Scott Frye                     Feb 17, 06 11:56:23 AM -0500
Subject: Finished Chapter 6!
[My coments are appended - RJL]

I finished chapter 6 about models and Pattern.  I thought it was much
better than chapter 5.  I think they made a strong case for programs being
driven by models.  I guess the question to ask is what would be the best
way to represent a model for the BDE program.  They made a strong case for
XML as a useful model.  I would use this technique if I were to apply this
to my stuff at work because XML is so ubiquitous.

-Scott Frye

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

- from R Lechner, 060217:    I am glad you liked Ch. 6.  
I believe their divide and conquer approach will get progressively
more sophisticated thru the paired chapters in part II. 
I hope they don't drop the ball in Part III, which ought to be longer 
to really show a full implementation of their vision.

Wrt. XML, I didn't see any case for that, except as a medium for exchange
of tree-structured composition hierarchies of data.
I couldn't care less about an alternate exchange representation
for data - behavior is much tougher to represent because it needs to 
be [mappable into an] executable. 
XML would be an easy target for a converter from/to BB...EB depth-first 
representation of relational tables using pr_dump_row, 
as well as pr_dump's current one-table as a time format.
Such conversion is easy AFTER pr_dump writes such a file 
and BEFORE pr_load reads it back in. IF needed, XML representation
could be generated as an option inside pr_load/dump. But how would
you make this compatible with CVS version control storage?
That's my primary target for pr_dumped files of design specifications.

[XML might indeed be useful for distributed applications with log/replay, 
Distributed BDE, and event-drivwen message-exchange requirements, 
if performance doesn't suffer from XML's increased data-volume  and 
resulting decrease in effective bandwidth.]


Wrt to a model for BDE, you are right -  
for the major bde2fox PI-GUI migration goal,
I am very hopeful of Robert Almonte's pattern-based encapsulation approach.
However, there are other migration goals for bde/src and bde/pr_util 
which are more constrained by re-use of  BDE's past, particularly for migrating 
BDE's s obsolete legacy code toward my COOL framework  vision.

I trust you will help keep me honest and realistic about what SWF  can do to help in this.
My intuition is that SWF will help strengthen encapsulation and pattern use, and confirm 
Almonte's bde2fox approach. I don't think it will contribute much to the custom code 
in bde/src  or the generic code in pr_util because I don't think it will reveal its approach
in as much depth as GENCPP and LCP already provide. (I could be mistaken on this.)

I believe we face a Question that is more general than a migration plan for BDE: 
Are the SAME models suitable for designing and implementing COOL Framework 
components (GEN, BDE, LGP)  AND for applications that are based on use of  this framework?

I would say YES, in order to practice what I preach, but this is still unproven.
Existing examples are the JuicePlant, with its OP class and  bde Display interfaces, 
the distributed setGame and Hominid toy projects, GEN's bootstrap use of metadata 
which should be incorporated within pr_util, and the flag-less state model architecture of 
bde/src/*ops.cc code (a comment-embedded prelude to full use of  LCP).

SWF would likely say NO since they are  biased toward specialized non-generic models, 
with a distinct DSL for each app (perhaps justifiably, since they are looking toward 
high-volume production of product families).  SWF also identifies other  aspects that
are important for product families, such as  build, configuration and version control, 
packaging, environment-adaptation  and deployment management. 
These are definitely NOT in the current scope of COOL.  CVS is adequate for version 
control but we obviously need much better build flexibility and configuration adaptability 
than imake/gmake  tools provide.

The COOL components BDE, LCP and GEN  themselves are (I would like to think) 
independent and complementary aspects of the framework. In other words I think 
of them as practical aspect-oriented programming (AOP at the MVC level).

I believe the COOL components GEN/BDE/LCP  are independent generic  aspects 
of an overall model/view/controller approach, that CAN AND SHOULD BE used 
to specify and implement design frameworks as well as other applications: 

GEN supports a structural model and BDE a visual model for the acquisition 
of both static information and dynamic behavior models,, while BDE is the HCI tool that 
supports design visualization. A new BDE can be supported by pr_util from gencpp
and use a State-Model-based controller architecture from LCP; the latter conrols 
sequencing among  State actions  specified as  C++ code fragments).
 
BDE is used to produce [visual] structural and behavior model specifications, 
which bde2sch and bde2SM respectively transform into information structures 
that specify structural and behavior aspects of ANY application (including GEN and BDE).  
These structures drive GEN[CPP] to produce *ops.cc (including pr_accessors.cc) 
and also the LCP Controller that mediates between the bde/pr_util Model library 
and the bde/src View action code fragments  [and similarly for other applications of COOL].


The above vision is a point well beyond  the current chgen + bde  implementation: 
Obviously (if you have read the KM_MO_RL report) gencpp must replace chgen 
to support an effective OO-based architecture for bde and lcp. 
I would like to replace  chgen by gencpp as soon as I can repair and refactor bde/src code.


These preliminary refactorings of bde/src code involves 5 steps; the first four of these
affect pr_util's API interface. Bde's database and bde/src code depend on this API
but (fortunately) not vice-versa. 
 (1) Elimination of pr_init's object-level version-maintenance over multiple files,
which should become a CVS responsibility;
(2) migration from pr_set/get_* in pr_load.c to XXget/set_* in pr_accessors.c,
which is compatible with gencpp's accessor methods.
(3) migration from hcg-structures to metadata tables TT and TA for database house-keeping;
(4) migration from chgen's tables of structs to gencpp's Vectors of row-classes (but retaining
parent-to-child-sets as privatem friend-based intrusive linked lists, not STL containers);
(5) migration from switch(state) case-based *ops.cc  to LCP -interpretation of action routines,
(first manually and later with gencpp enhancements).
Migrating bde/src can teach us much about  lost opportunities for encapsulation,.


Date: Wed, 15 Feb 2006 12:59:53 -0500 (EST)
To: Bob Lechner <lechner@cs.uml.edu>
Subject: Re: DTrace - SW tracing from app into OS kernel - Solaris--->FreeBSD;  FYInfo
Hi Professor,

I just finished Chapter 5 last night.  But I'm planning on doing chapter 6
before the weekend.  I didn't care for chapter 5 much.  I don't think that
it added a lot to what was discussed in chapter 1-4.  It restated
everything and in that aspect provided a good summary, but I don't think
it added a lot of new material.

As I read, I am skeptical that this is going to be the next programming
paradigm.  They seem to be under the impression that people will suddenly
start assembling components and using the same language to define
requirements and all the other parts of the development process.  But they
don't indicate what is going to drive this to happen.

[Same language?  They promote DSL's? - RJL]

They also seem to be under the impression that no one will want to use general
purpose programming languages and all these vertical supply chains are
going to materialize to support the DSL.  If we look at what has happened
in the past 30 years, however, the most general purpose languages are the
only ones that have become popular.  Granted these languages have bloated
and developed more features.  There is so much in a general purpose
language that it needs and accompanying framework, (java, .NET), but, in
my opinion, developers are not going to choose to specialize in a language
that serves a tiny market.  They are going to want to work with general
purpose languages, so they can get a job anywhere, doing anything?

[GPLs are too low a level - they envision languages made up of high-level 
domain-specific abstractions.  These used to be called API's or subroutine libraries.
Some SWF components are outside the scope of build/compile/link/test chains. 
I agree with you that glue code written in GPLs will remain essential, and many of its  
less-well-heeled competitors will avoid bankruptcy, at least until swallowed up
by uSoft and other better-capitalized SW developers. - RJL]

I think the authors fail to look at this issue.  What is going to make the
these vertical supply chain companies want to work only within the tight
little markets that the authors claim they will want to specialize in?
-Scott Frye

[I think that horizontal-layered  DSLs have more promise:  higher-tech and better programmers.
However, engineering mindsets may be under-estimating 
the sophistication of code-independent business-process modelers. - RJL]

On Tue, 14 Feb 2006, Bob Lechner wrote:

> Scot - this is a good article, related to SWF Ch. 8,
> section on trace-bassed semantics (pp 312-318, 320,325).
> (printable from link at end - I've done some reading ahead.:-)
> How is your SWF reading coming? I just finished Chapter 6,
> and expect to read Ch. 7 by next Tues.
> Bob Lechner
>
> From: ** ACM TechNews; Monday, February 13, 2006 (=acmtechnews060213)
>
> "Hidden in Plain Sight"
> Queue (02/06) Vol. 4, No. 1, P. 26; Cantrill, Bryan
>
> A lack of software observability is responsible for lengthy and often
> needless diagnosis of serious performance problems that usually have a
> relatively simple root cause, according to Bryan Cantrill with Sun
> Microsystems' Solaris Kernel Development Group.  Software cannot manifest
> itself physically, which means modifying the software is the only way to
> observe the software being executed; but such constructs can slow down the
> system by their very presence.  Avoiding this scenario supports the paradox
> that addressing performance problems seen in production requires
> replicating the problems in either a development or test environment.
> Cantrill also notes that performance problems are usually introduced at the
> highest software abstraction layers, but are often first seen at and blamed
> on the lowest abstraction layers.  Therefore, it stands to reason that
> unintentional or unnecessary work could be eliminated by moving up the
> software stack to uncover underlying performance problems instead of
> focusing on their cascading symptoms in the lower stack.  Shifting the
> observability infrastructure's focus from software development to
> production and from programs to systems is Cantrill's solution, and it
> requires the optimization of software when it ships, dynamic
> instrumentation of the production system, and, above all, absolute safety
> of the infrastructure.  Sun's DTrace system was designed with dynamic
> production system instrumentation in mind, and it offers the flexibility of
> such instrumentation without sacrificing safety by drawing a line between
> the system's manner of instrumentation and the framework that consumes the
> data.  "The architectural elements of DTrace--safe and heterogeneous
> dynamic instrumentation, arbitrary actions and predicates, and scalable, in
> situ data aggregation--allow for unprecedented observability of production
> systems," Cantrill writes.
> http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=361
>
> NOTEWORTHY: Ref to APL p.7;  Experience Section - pp 1 and 8-10 on print-friendly version.
> A FreeBSD version being worked on part-time - Ref. 1, p. 11