RJLRef: $PH/06f522/models2codeKeyProcesses061116.txt In response to CGuffey, here is a broader look at [my :-)] OOAD: > From cguffey@gmail.com Thu Nov 16 11:57:36 2006 > To: "Bob Lechner" > Subject: Re: [UML_CS522_f2006_OOA] Re: [Don't change asgnt3.h: chgen will change it back! > Cc:all > > I have read both manuals you gave us, I do not think I could have > written the code for assignment 3 if I had not. That doesn't mean > however that I caught every point they were trying to make. I just > needed clarification on that. > OK - I take it back, Chris :-). (BTWay thanks for commenting your code so well.) I agree the points are too many to gather from the UManual alone. That's because chgen was aligned with a broad philosopy - with context provided by the .ppt slideshows on Obj-RelDBs, COOLFAQs, Cardinality etc., which I referenced online and in class. (I welcome comments on this philosophy :-) - it includes: 1. Get the data models right FIRST: -------------------------------------- Use a standard modeling approach for most applications: Use a common and consistent way of referencing and structuring data, particularly aggregates; Avoid confusiing notation by eliminating complex variations; Do not ignore symmetric n-ary relations: Split them up by using associative entities. This brings the conceptual model closer to the logical one. 2. Use a homeomorphic (1:many) translation to implement the models: -------------------------------------- Maximize the amount of code that can be auto-generated from the model in a uniform way; then the problem of code comprehension is scalable - the work required to understand it doesn't expand faster then the size of the model itself; it enables much more effective communication via a common modeling language AND semantics. This brings the physical data model closer to the logical one. 3. Use a similar approach to modeling behavior: -------------------------------------- Apply a standard way to model control flow as states and transitions instead of ad hoc flag variables and flag-dependent branches. This separates control concerns (transitions) from computational ones (atomic state or transition actions). Use a common approach for metadata, operational and test data. 4. Manage concurrency and synchronization in distributed systems: -------------------------------------- One huge semantic leap is from models for hierarchical procedures within a single thread vs. models for processes that are distributed over multiple threads and/or hosts. Traditional programming focuses on the first of these. Modern programming deals much more with the latter. and introduces additional models such as Activity Diagrams and new semantics for concurrency and synchronization requirements. Modern tools need to manage hierarchies of 2-dimensional models operating in parallel. This will promote understanding of concurrent systems by adequately representing their complexity while separating concerns. 5. Do object-based design before object-oriented design. -------------------------------------- None of the above is dependent on object-orientation (inheritance). But the models are heavily object-based: i.e., persistent instances with unique immutable identifiers (oid's). Don't exclude object-oriented programming, but defer it: After common behaviors are recognizd (but no earlier) they can be simplified by inheritance and polymorphism. 5. Use prototypas for testing and measurement. -------------------------------------- After performance bottlenecks are measured (but no earlier) they can be reduced by better algorithms and data structures. Both are likely to change with experience using prototyes. GUI designs are also likely to change - but human factors is a subject for another day.