Project Deliverables

1. Project Deliverables • This week • Sequence diagram(s) • User interface design (mock-up) • State machine diagram for the user interface • Revised specification • Next week • Test plan

2. Implementation Class Skeletons

3. Class Skeletons • This is the start of the coding phase of system development • Skeletons can be written in the target programming language or pseudo-code • The decision really depends on • Knowing (or not knowing) the target language • Knowing (or not knowing) who will do the programming

4. Class Skeletons • They’re really just a formal structure for documentation purposes placed on top of the code you are writing • Written by the designer • Provide original designer’s insights/motivations • Useful when the designer isn’t the programmer • Most useful when the designer isn’t the maintainer • Individual project managers may have their personal style preferences • Style should be consistent across all programmers on the project

5. Class Skeletons • Should consist of at least these sections: • Roles • Information maintenance • Attributes • Constructors/destructors • Methods

6. Roles • Behavior of the class within a specified context • In a particular situation, what does the class provide? • May partition the class into functionalities that can be designed or maintained independently

7. Information Maintenance • Specifies when objects of a particular class type are created and deleted • Not all classes/instances will be used throughout the entire execution of the system • Note that this information comes from the Sequence Diagram • This section is especially important for resource management

8. Attributes • Declaration of member variables • Brief statement of what the variable will be used for • If the variable represents a measured value, specify the units of the measurement • If the variable stores information in a specific format, specify it • If the variable has a “legal” range of values, specify it • If the variable has dependencies on other variables, specify them • Two explicit sections • Instance variables • Hold data specific to an instance of the class • Non-static member variables • Class variables • Hold data common to all instances of the class • Static member variables • Group all variables of a given type together to improve readability

9. Constructors/Destructors • If multiple constructors are provided they should be grouped together • Specify the types of initializations or default assumptions made by each constructor • If a destructor/finalizer is provided it should be right after the constructors • Specify any clean-up activity performed

10. Methods • Three distinct groups • Public – those available to the outside world • Private – those available internally (helper methods) • Protected – language dependent • Grouping by access will make the code more readable for anyone not involved in the original coding • Two distinct sub-groups within each group • Non-static member functions • Static member functions • Again, grouping leads to readability

11. Skeleton Example (one way to do it) public class Patron { // Class semantics and roles: // Library patrons function in two primary roles, // as researchers who use index, reference, and database // materials and as borrowers of loanable resources // Information maintenance: // Creation: New patrons are introduced into the system // by library staff when presented with a library // membership application or from information retrieved // from a web-based application form. // Deletion: Patrons are removed from the library database // 3 years after their membership has expired

12. Skeleton Example (cont.) // Private instance variables: private String name; // name of Patron in // <last-name, first-name, MI> order private long PatronID; // Patron’s library identification // number sequentially generated private long homephone; // Patron’s home phone number in // 11 digits (xxx)yyy-zzzz stored as // xxxyyyzzzz private Date memberDate; // date of first membership in // mmddyyyy format private Date expireDate; //date membership expires in // mmddyyyy format private List resourceList; // Object reference to Patron’s // list of checked out resources private Address homeAddress; // Object reference to // patron’s home address

13. Skeleton Example (cont.) // Public instance variables: // Private class variables: private static long nextPatronID; // keeps track of the // next patron membership ID to // be assigned // Public class variables:

14. Skeleton Example (cont.) // Constructors: public Patron(String name, long homePhone, Date memberDate, Date expireDate, String street, String city, String state, long zip) { // TODO List: // PatronID = getnextPatronID() // Create an Address object initialized with street, // city, state, and zip // Create Date objects for membership data and // expiration dates initialized with memberDate and // expireDate.

15. Skeleton Example (cont.) // Precondition: Library database can accept another // entry and memory allocation succeeds // Postcondition: Library database will contain another // Patron and Address entry } // Destructors/Finalizers: ~Patron() { // Precondition: Patron object is not null // deallocate any memory allocated by the constructor // or other nonstatic methods } // Public static methods: public static long getnextPatronID() { return nextPatronID; nextPatronID++;}

16. Skeleton Example (cont.) // Public static methods: public static long getnextPatronID() // controlled access { return nextPatronID; nextPatronID++;} // to patron ID // Private static methods:

17. Skeleton Example (cont.) // Public nonstatic methods: public boolean validatePatron(Date expire) { // precondition: expireDate is not null expire = expireDate; // pass expiration date back to // calling function via parameter // list // if expireDate <= Today return false // else return true } public boolean checkout(Resource resourceID) { // precondition: resourceID points to a legitimate // Resource object that is available for checkout // postcondition: if resource list is null, one is // created, otherwise a new Resource reference is added // to the patron’s List of checked out resources } }

18. Goals • Keep in mind that the goal is to provide readable code • Readable code will reduce the chance of introducing bugs during both initial coding and maintenance phases • Readable code will make it easier to detect bugs that find their way in • It’s easy to skip skeleton development but someone usually pays for it later on down the road • Might as well practice good habits

19. End Notes • Much of the “style” presented is my own preference – you may or may not agree with it • The key is to develop a style and stick with it • No matter who’s style you follow, you should (must?) provide the information • CONSISTENCY COUNTS • IF you know the target programming language you may use it for developing skeletons • If using Java then you may as well use javadoc style • doxygen is an open source version for various languages • Those teams with multiple programmers have an inherent checks-and-balances system with respect to style • Those teams with a single programmer must use other team members (non-programmers) to perform the stylistic checks-and-balances

20. Where Does This Get Us? • We’ve started the process of writing code • We’ve started the process of documenting the code

21. Implementation

22. Implementation • It’s time to start turning out code! • In doing so, a couple of issues arise • Configuration management • Coding

23. Configuration Management • Goals of configuration management (CM) • Identify change • Control change • Ensure proper implementation of change • Report change • In this context “change” refers to alterations in the original, agreed upon specification • Another goal of CM is to track progress (which is another form of change) • The two are separated because “change” is much more difficult to deal with than is “progress”

24. Identifying Change • Change is going to happen • Market conditions change • Seasonal • Competition • Timing in general • Customer needs change • As their understanding of the product/market increases • Team structure changes • Personnel get pulled off • Personnel get put on • Business resources change • Budgets shrink/grow • Time lines shrink/grow

25. Controlling Change • Given that change is going to happen, we’d like to make it as painless as possible • Uncontrolled change has the potential to sink a project • Controlling change requires both manual and automated systems working together

26. Identify Need Request Evaluation Report approved denied Create Baseline No Action Controlling Change Decision Implement

27. Proper Implementation • Once the change is approved, the implementation must follow all software engineering practices • Formal design and review procedures • Formal system test procedures (regression testing)

28. Report Change • After implementation, the change procedure must be audited • Did the change request pass all proper channels? • Were proper S/W engineering practices adhered too?

29. Tracking Progress • Status reporting • Baseline generation

30. Status Reporting • Regularly submitted reports • What happened? • Who did it? • When did it happen? • What else was/will be affected? • Reports may be written (classical S/W engineering) or oral (agile methods)

31. Baseline Generation • When you have a working (albeit incomplete) system you should make a copy and hide it away in a safe, dark corner where no one can get at it • This way any progress or change that goes awry can be easily rolled back

32. Configuration Management Tools • Various semi-automated tools exist for aiding in the performance of all of the aforementioned tasks • The provide mechanisms for • Version identification • Version control • Auditing • Reporting • But, the tools are only useful when used properly!

33. Configuration Management Tools • Computer Associates AllFusion (used to be CCC/Harvest?) • Rational (IBM) ClearCase • Open source Concurrent Versions System (CVS) • Serena ChangeMan (used to be Merant PVCS?) • SourceForge • Microsoft Visual SourceSafe • SubVersion • Perforce

34. Coding class Shape { private int xPosition; // -- (0,0) is the private int yPosition; // upper-left // corner private int area; // -- pixels^2 private int perimeter; // -- pixels // -- accessors public int GetX() {…} public int GetY() {…} public int GetArea() {…} public int GetPerimeter() {…} // -- mutators public int SetX() {…} public int SetY() {…} public int SetArea() {…} public int SetPerimeter() {…} // -- message handlers public void ComputeArea() {…} // -- sets area member to // default, should be // overridden in derived // classes …

35. Coding class Square extends Shape { … // -- message handlers public void ComputeArea() {…} // -- overrides base class // method …

36. Big Bang Method • Code all the modules individually • Integration happens when all module coding is complete • Basic recipe for disaster • Essentially how beginning programmers do things • Because that’s how they’re taught

37. Top-Down Method • Start by defining the “architecture” defining modules • Corresponds to the “product design” items we studied • The “main” function • Provide “stub” or “dummy” classes and methods for all other functionality • Fill in details with a “refinement” approach • A good approach when the details of the design are not fully worked out • Allows you to get something running while design is ongoing

38. Bottom-Up Method • Start with the detailed classes and methods • Work your way up to the architecture • A question arises… • How do you test the detailed classes and methods? • Answer: You create test drivers for each class/module. • A good approach when the details are critical and require a lot of testing prior to product release • Also a good approach when you have nervous designers…like me

39. Top-Down/Bottom-Up Method • Top-Down and Bottom-Up are both Incremental approaches • Contrary to the Big-Bang Method • Thus, they are compatible with one another • In practice, a combination of the two approaches is applied • Results in the Threads method

40. Threads Method • Define a minimal set of modules required to perform a system function • May correspond to a Use Case • As one thread is completed it can… • go to the customer for feedback • go into testing • …while the next one is being developed

41. Implementation Plan • The most important thing is to have a plan! • Plan for coding • Plan for unit testing • Plan for integration • Plan for integrated testing

42. These will not only support implementation, but maintenance Programming Style • Very subjective topic • Goals are • Simplicity • Readability • General rule • Consistency • Uniformity

43. Placement of “{” is not consistent Constant comparison format is not consistent Consistency • Consider the following code fragment: if (x == 10) { y = 17; } … while (17 == y) { z = z + 5; }

44. Variable Naming • Consider the following declarations: int tempA, tempb; int m, n, o; int localarea; int globalArea Int UniversalArea; • Name selection is inconsistent • Use of upper/lower case is inconsistent

45. Variable Naming • Consider the following declarations: int a, b; int variableToHoldTheValueOfTheArea; • Variable names are not descriptive [unless they have some special, acceptable meaning in context] • Variable name switched from descriptive to downright annoying after 3 words

46. Naming Conflicts • Use package (Java), namespace (C++), source/header file combinations (C and others) to avoid naming collisions • Use predefined naming conventions • e.g. • Control department: cont_<variable name> • Security department: sec_<variable name> • Image Processing dept.: ip_<variable name>

47. Constant Values • Thou shall not type numbers into your code • Instead use • final values (Java) • const values (C++) • #define values (C)

48. Side Effects • If functions (methods) must modify values outside their “immediate scope” (i.e. global values), make the situation clear through documentation • If functions (methods) modify their parameters (pass by reference) make the situation clear through documentation • This is especially important in Java (use of Object class and type casting)

49. Both a class name and a method name within another class • Stuff like this can cause problems in inheritance situations Avoid Ambiguity • This is perfectly legal but scary public class AClassName { public AClassName () { } } public class Ambiguous { public static void main(String[] args) { Ambiguous ambiguous = new Ambiguous(42); ambiguous.AClassName(); AClassName aclassname = new AClassName(); } public Ambiguous () { } public void AClassName () { } }

50. Coding Standards • Coding standards are created to ensure consistency • Although we may feel that they’re created to make some meddling micro-manager feel important • Define them! (they may be defined for you) • Make sure they are • Useful • Easily adhered to • Stick to them! • Many IDE’s will define standards for you • These are usually customizable