1. Implementation Goals: “map” design to clean, efficient code Document any design changes found to be useful Produce code that is correct, modular, understandable, modifiable Reduce errors which creep in during “transformations” (e.g., Lord of the Rings example, Ch. 10 of Bruegge & Dutoit)) Implementation / Coding RequirementsDesignSpecsVersion 1Version 2

2. Guiding principles: 1. “do the simplest thing that works” 2. Make good choices (array vs linked list; bubblesort vs quicksort; separate classes vs inheritance; etc.) 3. DOCUMENT!!!!!!!—keep code and documentation consistent

3. Types of transformations 1.model transformation 2.refactoring 3.forward engineering 4.reverse engineering

4. Model transformation: Simplify or optimize, e.g., --recognize that different types of events can be organized as children of an EVENT class --get rid of a redundant attribute (figure 10.2, p. 397)

5. Refactoring Change the source code to improve its readability or modifiability “pull up”: do in small incremental steps to check that behavior is appropriate Example: pp. 398-399: field constructor body method

6. Forward engineering: Use previously developed code to generate similar statements Example: p. 400

7. Reverse engineering: Recreate the model for an existing system

8. Principles of transformation: 1.One transformation addresses only one criterion for ONE design goal 2.A transformation must be local 3.Each transformation must be applied in isolation to other changes 4.Each transformation must be validated Q: how does this apply to coding habits?

9. Mapping activities: 1. optimizations 2.realizing associations between objects, classes 3.handling exceptions (“broken contracts”) 4.choosing a storage schema (e.g., in a database)

10. Useful mapping concepts for the object design model (examples): Access paths: does a sequence diagram show many similar traversals? Then you might want to create a direct path between the two objects If one class is accessing many objects of the same type, you might want to make the collection an indexed one to save time do some attributes in the called class really belong in the calling class?

11. Collapsing objects: Should some objects really be attributes? Delaying expensive computations Example: drawing an image—don’t create the image object until it is needed Caching the result of expensive computations Example: statistics calculations which will be referred to later in the program

12. Using efficient associations : Is the association: Unidirectional 1-1? Figure 10.8—account is private so that callers cannot accidentally modify account number Bidirectional 1-1? Figure 10.9—if an account has a reference to an advertiser, the advertiser must have a reference to that account—if changes are made, both classes must be recompiled Bidirectional 1-many? Figure 10.10—here the accounts are a “collection”—they might need to be ordered or unordered Many-many? Figure 10.11—2 lists—both must be consistent

13. “qualified” association—figure 10.12 May be able to use an “association class”— e.g., statistics, figure 10.13—this class holds binary associations

14. Mapping contracts to exceptions Java: throw / catch Simple method: check preconditions check postconditions check invariants encapsulate checking code into methods to deal with inheritance

15. Robust* procedure but may not be realistic * The word robust, when used with regard to computer software, refers to an operating system or other program that performs well not only under ordinary conditions but also under unusual conditions that stress its designers' assumptions. … operating systemprogram The Rule of Robustness in the Unix philosophy states that robustness results from transparency and simplicity. Software is transparent when a skilled programmer can examine its source code (i.e., the original version written by a human in a programming language) and soon comprehend how it works. It is simple when its operation is sufficiently uncomplicated that a programmer can visualize with little effort all of the potential situations that it might encounter. The more that programs have both of these qualities, the more robust they will be.source code Another important tactic for creating robust software is to write general code that can accommodate a wide range of situations and thereby avoid having to insert extra code into it just to handle special cases. This is because code added just to accommodate special cases is often buggier than other code, and stability problems can become particularly frequent and/or severe from the interactions among several such sections of code. http://www.linfo.org/robust.htmlhttp://www.linfo.org/robust.html, accessed 07/27/2010

16. Why is above procedure unrealistic? added code may be very long and complex, effort creating it may be better spent elsewhere more code means more chances for bugs code for checking is difficult to modify when original code is modified, this may leas to more bugs (“obfuscated code”) added code reduces performance efficiency

17. Heuristics for code-checking—do you agree with these? Omit checking postconditions and invariants—these are typically written by the code developer, tests should be written by an independent party Focus on subsystem interfaces—these are likely to be boundaries between developers; put less emphasis on checking private and protected methods Focus on components with the longest life, i.e., entity objects as opposed to interface objects Reuse constraint checking code where possible DOCUMENT the checking with comments

18. [Persistent storage mapping—we will not cover this, it is more relevant to databases]

19. Managing implementation: Core architect: selects transformations to be applied, e.g., storage method Architecture liaison: documents contracts for subsystem interfaces, keeps everyone up to date about these Developer: follows core architect’s conventions, converts object design model to source code, keeps source code documentation up to date

20. Ensuring consistency: --use tools consistently, don’t change development tools when your are working on a given transformation --keep the contracts in the source code, not in the object design model—this will increase the probability that they will be updated as needed --use the same names for the same objects --make transformations explicit

21. Question: is your coding style consistent with the recommendations given here?