RJLRef: $PH/06s524/SWFChptr7Notes060312_sf_rl.txt Some comments below. > From sfrye@cs.uml.edu Sun Mar 12 18:43:25 2006 > Date: Sun, 12 Mar 2006 18:43:25 -0500 (EST) > From: Scott Frye > To: Bob Lechner > cc: Almonte > Subject: Re: $PH/RJLtalk2CS060301/SWFChptr7Notes060306.txt > Professor, > > My comments are below. > > On Mon, 6 Mar 2006, Bob Lechner wrote: > > RJLRef: $PH/RJLtalk2CS060301/SWFChptr7Notes060306.txt > > > > Ch7 p238-245 Automating Patterns. > > > > They view this problem as sophisticated and hard, > > requiring Prod families to amortize the expense. > > I agree. > > I think that I need to learn more about patterns. The idea > of creating a pattern, and passing it variables to make more > generic seemed pretty straight forward to me. I imagine > that if the pattern was going to be designed to be VERY > generic, it would require many, complex variables. However, > I imagine one would make the pattern code more generic > incrementally as needed. Notice I said Pattern[S] not Pattern. They recognize that interdependence among patterns is hard to specify ahead of time, and harder to back-trace after multiple changes are made (next parag.) > > > 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). > > If they exist, it seems like they haven't caught on much yet. I think all of this is new territory - except for refactoring where Fowler may know about automation support.. > > > > > 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. > > > > I was somewhat confused about their description of apply vs. evaluation. [So was I :-)] > I took their distinction to be based on the need to implement > refactoring. In this case, you would specify that you want to apply a > pattern. During this process you would indicate what objects you wanted > to map to the corresponding objects in the pattern. After that, when you > changed names of the objects in your code, you should not have to re-apply > the patterns, just re-evaluate them so that the proper object/variable > names are used. This would allow re-factoring tools to be independent of > the pattern application tools. You might consider gen_pr_accessrs.c in GENv13, where a macro (Could become a template-based function) produces an accessor tailored to each class and fieldname bo passing them as parameters. Since this is clearly not a futuristic technique, I suspect something more is in their minds (next parag:) > > > [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. > > > > I wish they had given more examples here! [Me too.] The book is rep;lete with 'topics left hanging', where pretty simple examples are given and do not seem complex, but NO HINT is given as to where they are at, in tackling more sophisticated problems. > > > 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. > > I seem to recall reading an article in Software Development that discussed > this topic. They suggested the use of tagging a class with an XML tag > before > the class/method declaration. I know C# supports this and I think java > supports it with an add-in. The plan was that if you tagged a class > with, for instance, the logging tag, it would apply the logging AOP class > to your new class. You could assume all errors from your class that are > directed to the standard output, would instead go to a log file. There > were other examples but I don't remember them. > OK but your log is not mine. Mine is a DB Edit log, which can be replayed. Replay can be immediate (for edit undos) or deferred or distributed. GEN sees persistent fields defined in the schema, and they are the ones logged. Richer data models add more loggable object types and fkey associations, and views can be imposed to select a subset of these to log and/or replay (of course the view must be complete enough to debug the app). However, pointer fields are private and [I hope] need not be logged assuming pr_util.a is reliable enough to be trusted. > > 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? > > > My interpretation was that the graph diagram represented the 70% > of the declarative spec that can be generated and the method annotations > is the 30% imperative. > That seems a reasonable interpretation. I believe auto code generation is also applicable to state model guards and OCL constraints which are expressed procedurally. A DSL can probably be invented to translate declarative specs into procedural onesi provided the domain is narrow enough. That's nice if laws change the rules annaually as some do.. Caveat: The 70/30 ratio is for business apps with fairly trivial transactions. Note they say 'up to' 70% automated. Bde is an interesting case study because bde/src has lots more code than pr_util_[no]log. I.e. tne manual code is a majority because it does lots of on-canvas calculations to edit its constructive graphic images for which there is no GUI support as far as I know (without much of a search). ------------------------- mercury.cs.uml.edu(193)> pwd /nfs/galaxy/faculty/fac1/lechner/bde2alpha_rl/sandbox/bdeNT050526/bdegen13/bde/pr_util_nolog mercury.cs.uml.edu(194)> wc *.c *.h | grep total 11: 5437 20842 202871 total mercury.cs.uml.edu(195)> cd ../pr_util_log mercury.cs.uml.edu(196)> wc *.c *.h | grep total 15: 10837 41754 398143 total mercury.cs.uml.edu(197)> cd ../src mercury.cs.uml.edu(198)> wc *.cc ../include/*.h | grep total 58: 27141 123231 1011928 total mercury.cs.uml.edu(199)> ------------------------- When we get rid of pr_init() pr_util will get significantly smaller. bde/src can also be reduced a lot, by sharing code in delegates or superclasses. Bob Lechner > > -Scott Frye