RJLRef: $PH/SWFChptr7Notes060306.txt
[With SWFChptr7Notes2.txt attached]

Ch7 p238-245 Automating Patterns.

They view this problem as sophisticated and hard, 
requiring Prod families to amortize the expense.
I agree.

Merging multiple pattern applications covers up tracks 
and prevents rev engrg., unless the entire trace history 
(of transformations, not just text edits as in cvs diff)
is retained (p.239-240). I doubt that parameterization can
be applied to anything more complex than type signatures.

Pattern engines exist, they say, and its editors 
must support copying and merging 'object graphs'.
('just extend current graphic editor copy/paste 
and drag/drop to 'pattern fragments', they say).

The closest I come is in using macros to abbreviate 
'aspects' like debug printout and stats reporting.

A prototype is defined by a closure.(p.242).
In GEN EERDs, inheritance and containment links
translate to subclass and containment, schema.h and
pr_accessors.c and LCP/olcarch code generates access
methods and child_loop macro 'patterns' and gencpp
iterators. 

(p.245)Pattern Evaluation: argument distinguishing 
pattern evaluation from pattern application seems 
weak, and a false dichotomy when name <--1:1--> objectidpkey? 
Re-applying means rebinding; 
re-evaluating (if parameter values change) does not.
This means a pattern applied once can be evaluated multiple times.
My analogy is the LCP/olcarch trick of defining a macro that
generates a Get or Set function that is specialized 
by passing arguments that specify class and field names;
these can be type-and containment-checked in the TT-->TA
metadata for the schema version at hand.

[Unfortunately for me I think they have in mind 
something more elegant: generating mappings between
schema versions (like ghost variables) not just
methods within a single schema.] 

(p. 245-6) They point out that delaying pattern evaluation
until well after pattern application can cause more
problems in retrieving the prior pattern definition.
(Figs. 7.8 - 7.10)

p.249: Automated Refactoring.
 
p.252: Debugging with Models.
Fig. 7.17 shows a runtime display of a breakpoint n 
a communiction diagram message flow path. 

p 258-263: Aspectual Composition/decomposition:
This tells WHAT but not HOW, AOP distribution over code
is needed. (Too bad no example is given.) Interpretation
or generation is proposed. 
Interpretation can use DPs (Adapter, Bridge, Mediator, Strategy)
with loss of adaptability and traceability.
On generation, [CE00] Czarnecki et al: Generative Programming 
(AW2000) is recommended for details. 
Set/Get encapsuiation is said to use AOP Principles[?].
I suppose logging and replay also does (or can) use AOP.

p. 272-274 Adding code to models augments declarative specs

From declarative specs (e.g. EERDs) 'up to' 70&% of 'structure
and behavior' code can be generated. The rest must be hand-coded
(e.g. code to invoke framework-supplied get and set and iterator
methods). A method annotation in a STD example is shown in 
Fig. 7.31; is this declarative?

------------------------------------------------

From lechner@cs.uml.edu  Mon Mar  6 20:50:05 2006
Subject: Re: Chapter 7. [8?]
To: sfrye@cs.uml.edu (Scott Frye)
Cc: lechner@cs.uml.edu (Bob Lechner), ralmonte@cs.uml.edu (Almonte)
RJLRef: ./SWFChptr7Notes2.txt
> From sfrye@cs.uml.edu  Thu Mar  2 08:40:28 2006
> Subject: Chapter 7.
> 
> How did the lecture go yesterday?  Were there a lot of people?  Was there 
> a lot of interest from those that did attend?
> 
> I'm almost done with Chapter 8.  I got hit with a flu this weekend but 
> Chapter 9 is short so I expect to have all the reading done by Tuesday.  
> 
> What sparked my interest the most, so far, was the correlation of an 
> Abstract Syntax tree to a Metamodel.  I never made the connection that the 
> entity relationship diagrams we had been using in your class  
> could be used to define a language.
> 
> This is great!
> 
> -Scott Frye
> 

Talk 3/1 was poorly attended. My time was worth it only because
it forced me to collect many URLs onto one page and link them
by name and path, in  
	
http://www.cs.uml.edu/~lechner/06s524/RJLtalk2CS060301/SWF-COOL-Seminar060301.{htm,doc}


Re: BNF to EERD, Ch. 8 mixes class level metamodels and 
instance level example parse trees without much explanation.  

I tried to convey these in 91.204 CompIV class:
EERDs [meta-]model parse tree data structures ;
syntax diags or STDs model LL-parser state transition constraints;
runtime parser output for one source code file instance 
can be saved in a parse-tree-modeled database (and in CVS if GEN formatted.)


See my notes at  

http://www.cs.uml.edu/~lechner/01s204/2kf204CalculatorR1.ppt 
http://www.cs.uml.edu/~lechner/01s204/WhileIfCodeGen.ppt
(Grammars to class diagram/EERD's)

and
http://www.cs.uml.edu/~lechner/2kf204/CASE/2kf204/syntaxDiag2BNF.ppt
(BNF to syntax diagrams/STDs)

and 
http://www.cs.uml.edu/~lechner/2kf204/CASE/2kf204/BNFNotationR1.2k0917 
(BNF notation for Lex/Yacc/Bison parsers)


I'll send another email re: Chptrs 8 and 9 Qs.