Implementation Coding Requirements Specs Design Version 1 Version

Implementation / Coding Requirements Specs Design Version 1 Version 2 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: 5 published versions, none completely correct))

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

Goal: produce robust software Problem: a 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. … 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. 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. html, accessed 07/27/2010

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

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: email: Address in 3 separate classes is moved to a superclass User for these 3 classes

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— 3 steps, check consistency, test after each: 1 -“pull up” field email: Address to superclass (check consistency) 2 -“pull up” constructor body which initializes email address 3 -”pull up” any associated methods which can be moved

Forward engineering: Use previously developed code to generate similar statements Example: p. 400: --design made “League. Owner” a subclass of “User” --in code “League. Owner” can be designated as a class which “extends” “User” and code can be reused, with changes in variable and method names as needed

Reverse engineering: Recreate the model for an existing system from the implementation (also common in hardware)

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?

Common transformation (“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)

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?

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

Using efficient associations: Is the association: • Unidirectional 1 -1? Example: account is private so that account users cannot accidentally modify account number • Bidirectional 1 -1? Example: if an account has a reference to user, the user must have a reference to that account—if changes are made, both classes must be recompiled • Bidirectional 1 -many? A user can have several accounts; the accounts must be included in a “collection” of some kind —they might need to be ordered or unordered • Many-many? Students-enrolled in classes: 2 lists—both must be consistent

Associations (continued): “qualified” association: example—”league” and “player” may be many-to-many, but a player can have a unique nickname in a given league May be able to use an “association class”— e. g. , statistics —this class holds binary associations between objects

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

Why is above “checking” 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 lead to more bugs (“obfuscated code”) • added code reduces performance efficiency

Note: adding error checking ALWAYS increases code length AND provides more opportunities for errors to occur (and is NOT foolproof) The same is true of error checking in general Example: simple error detection / correction in an n-bit string (Hamming) Detect 1 error: add parity bit, use xor Correct 1 error: if we add r bits, there are n + r + 1 possible cases for 1 error (n + r positions + “no error”) so we need room to store n + r + 1 results, i. e. , 2 r > n + r + 1 Examples: if n = 8, need r = 4 check bits if n = 32, need r = 6

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

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

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

Ensuring consistency: --use tools consistently, don’t change development tools when you 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

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