1. 1 Phase Implementation

2. Janice Regan, 2008 2 Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine subphases) Define Coding Standards For each unit Implement Methods in class/es Code review Unit test Create integration Test plan Create unit Test plans Release unit for integration Integration Testing System Testing Create system Test plan For each group of units

3. Janice Regan, 2008 3 Goal of Implementation Phase  Represent software system such that it can be understood by computer (audience)  Code design models using programming language  Software developers still part of our audience  Must plan how  Order in which modules and classes are built  How the modules/classes are to be combined  How the system will be tested to assure it meets the requirements  For our class project implementation phases will be defined on the basis of a group of use cases

4. Janice Regan, 2008 4 Overview of Implementation Phase  Planning Implementation and testing  Data persistence  GUI  Internal documentation:  Class skeletons  Code standard ( Programming style ) then  Unit test plan  Integration test plan  System test plan

5. Janice Regan, 2008 5 Where are we starting from? (1)  From low level design we have a detailed class diagram. Each class on the diagram shows  Attributes: visibility, name, multiplicity, type  [visibility] name [multiplicity] [: type] [= initial-value] [{property- string}]  -listOfBorrowedResources[1..*] : List  Name : String  Methods: visibility, name, parameters and their types, return type  [visibility] name [(parameter-list)] [: return-type]  +getDueDate(patronType:int, todaysDate:date):date  getName():String  The information from each class can help us create a class skeleton

6. Janice Regan, 2008 6 Sample class skeleton: following text public class Patron { /* Class semantics and roles: Library patrons function in two primary */ /*roles: as researchers who use the index, reference and database */ /*materials, and as borrowers of loanable resources */ /* Creation: New patrons are introduce into the system by library staff */ /*when presented with a library membership application. */ /* Deletion: Patrons are removed from the library database 3 years after */ /*their membership has expired */

7. Janice Regan, 2008 7 Patron class (continued - 2) /* Instance variables */ private string name; //name of Patron, Last, First, MI private long patronID; //Patron's library ID#, sequentially generated private long homePhone; // area code (3), local exchange (9) private Date memberDate; //date of first membership mmddyyyy private Date expireDate; //date membership expires mmddyyyy private List resourceList; //List of resources checked out by patron private Address homeAddress; /*Class Variables */ private static long nexPatronID; //next available patron ID #

8. Janice Regan, 2008 8 Patron class (continued - 3) /*Constructors */ public Patron(string n, long home, Date m, Date e, String street, string city, String province, long postalCode) { /* Parameters: n = name, home = homePhone, m = memberDate */ /*e=expireDate, patronID = getNextPatronID( ) */ /*street, city, province, postalCode create an Address object for */ /* homeAddress, resourceList is null */ /* Precondition: Library database can accept an additional entry */ /* and memory allocation succeeds */ /* Postcondition: Library database will contain an additional */ /* Patron and Address entry */ }

9. Janice Regan, 2008 9 Patron class (continued - 4) /*Static methods */ Public static long getnextPatronIDI O {return nextPatronID; nextPatronID++;} /*Nonstatic methods Public boolean validatePatron(Date e) { /*precondition: expireDate is not null */ } } // end class Patron

10. Janice Regan, 2008 10 Where are we starting from? (2)  For previous phases we have  One class diagram showing the static properties of the system  In practice one class diagram is often used for each subsystem making it easier to implement the subsystems independently  a series of interaction diagrams for separate use cases showing the dynamic behaviors of the system  A use case diagram showing the interrelation of the actors and use cases in the system  A list of core and less core requirements or prioritized requirements, cross referenced on the above diagrams  The above information may help us to decide the order of subsystem or module development. But HOW?

11. Janice Regan, 2008 11 Planning the Implementation Phase  Because software systems are complex, they must be built of parts, which are first developed (implemented) independently then assembled (integrated) into “builds”  This also renders the implementation phase more efficient as parts can be implemented in parallel  Planning of the Implementation Phase consists of planning implementation of parts and integration of parts into builds

12. Janice Regan, 2008 12 The Plan  Select implementation and test approach  Build schedule: implementation phase divided into sub phases (e.g. each phase may implement a group of use cases)  Each sub phase may include:  Coding units (unit: smallest code component that will be separately implemented and tested)  Planning of unit testing, Inspecting (+ bug fixing) each unit  Unit testing (+ bug fixing) each unit, Planning of integration testing  Integrating units  Integration testing (+ bug fixing) that is testing units together  Don’t forget to document which functional requirements are implemented in each sub phase

13. Janice Regan, 2008 13 Implementation Phase  Linear software development process (waterfall)  Each phase of the development process is executed once  The whole software system is developed and tested  Evolutionary Software development process  Some section of the software system is designed  This section is implemented and tested  These two steps are repeated for each successive section of the system.  Independent sections are integrated and integration tested  Sections may be composed of subsystems or of groups of use cases

14. Janice Regan, 2008 14 Implementation Approaches - 1  Big bang  Implement parts separately  Integrate and test all at once  Simple  OK for small projects  Difficult to debug (difficult to know which module is the culprit)  User does not see product until very late in the development process  You end up with a single build of the system

15. Janice Regan, 2008 15 Design of Real (read large) Systems  Using the big bang approach, which may work for class assignments, will likely lead to chaos  Source of errors difficult to determine  Slow, debugging difficult  Impractical, difficult to coordinate the work of multiple programmers, testers, and, developers  Must decide how to break down the system so it can be developed piece by piece in a predetermined order  Different programmers must be able to work on different pieces simultaneously  Want to provide ongoing feedback (showing progress) to the client

16. Janice Regan, 2008 16 Implementation Approaches - 2  Top-down (in terms of execution flow)  In OO: Start by implementing main method (where execution begins)  All classes instantiated by main( ) and all functions invoked by main( ) are implemented as stubs  Stub: “empty” class or method  Test main( ) by having it instantiating objects of its stub classes and by having it invoking stub methods

17. Janice Regan, 2008 17 Example of Top-Down: Step 1  Build the GUI  All actions by other parts of the system requested by the GUI are implemented as “stub methods”  A stub method  Has all arguments and return types of the final method  Contains no code to perform the actions expected of the method  Often will print a message indicating execution of the “stub method” has occurred (usually should include parameter values)  Can use the list of messages the 'stub methods' produce when this build is run to compare with interaction diagrams to test 'flow' through the steps of a use case

18. Janice Regan, 2008 18 Top down approach: Step 1 UI Stub

19. Janice Regan, 2008 19 Example of Top-Down: Step 2  Implement methods in the system directly called by the GUI  Methods implemented as stubs in the Step 1 build are then implemented (sequentially or in parallel). For our project these would be methods implementing the core of the system  Any methods called by these core that are not already implemented will be implemented as “stub methods”  for our project the 'stub methods' at this level would probably be mostly DB interface classes  Can use the list of messages the 'stub methods' produce when this build is run to compare with interaction diagrams to test 'flow' through the steps of a use case.  Completeness and correctness of implemented method can now also be tested

20. Janice Regan, 2008 20 Top down approach: Step 2 UI Stub Core functional layer (implemented stubs for Step 1)

21. Janice Regan, 2008 21 Example of Top-Down: Step 3  Implement methods in the system directly called by any already implemented methods  Methods implemented as stubs in the Step 2 build are then implemented (sequentially or in parallel)  Any methods called by the methods being implemented that are not already implemented are implemented as “stub methods” (If there are none this is our last iteration)  for our project the methods implemented at this level would probably be mostly DB interface classes  Can use the list of messages the 'stub methods' (if any) produce when this build is run to compare with interaction diagrams to test 'flow' through the steps of a use case.  Completeness and correctness of implemented method can now also be tested

22. Janice Regan, 2008 22 Top down approach: Step 3 UI functional layer (implemented stubs for Step 1) Database layer (implemented stubs for Step 2) Stub If any further stubs are needed Network (or other) layer (implemented stubs for Step 2) Stub

23. Janice Regan, 2008 23 Implementation Approaches - 3  Bottom-up  In OO: Start by implementing classes that do not use other classes or parts of our software system (i.e., classes that only use predefined classes)  Test using test drivers for each of these classes  A unit test driver for a class implements the unit test cases planned for that class. It should Create several objects (different states) from the class Display these objects (attribute values) Invoke all methods of each instantiated object

24. Janice Regan, 2008 24 Bottom up approach: Step 1 Database layer (base level methods that call no other methods) Driver

25. Janice Regan, 2008 25 Bottom up: example step 1  Implement all classes for the database layer  Write a unit test plan for each class  Write a test driver to implement the test plan  Unit test each class  Write an integration test plan to integrate each class into the DB layer  Write test drivers for integration test  Integration test the DB layer, tests whether all classes function properly together

26. Janice Regan, 2008 26 Bottom up approach: Step 2 Database layer (base level methods that call no other methods) Driver Functional layer (methods that call database level methods)

27. Janice Regan, 2008 27 Bottom up: example step 2  Implement all classes for the functional layer  Write a unit test plan for each class  Write a test driver to implement the test plan  Unit test each class  Write an integration test plan to integrate each class into the functional layer  Write test drivers for integration test of functional layer  Integration test the functional layer, tests whether all classes in the functional layer and DB layer function properly together

28. Janice Regan, 2008 28 Bottom up approach: Step 3 UI (call functional layer methods) functional layer (call database methods) Database layer (call no other methods) Network (or other) layer (implemented stubs for Step 2)

29. Janice Regan, 2008 29 Implementation Approaches Advantages and Disadvantages  Advantages to both  Integration test by adding modules to previously debugged modules  Advantages  Bottom up: Low-level (critical) modules built first, hence extensively tested  Top down: User interface is top-level module, hence built first. This is advantageous because UI eases testing  Top down; Stubs are easier to code than drivers  Disadvantage to both  Stubs/drivers must be written

30. Janice Regan, 2008 30 Implementation Approaches - 4  Threads  Implement and test a minimal set of classes implementing a function (thread = use case) e.g.: ManageResource: large thread, many closely related functions AddResource: small thread, single function  Advantage: partial software system ready for user consumption early (so early user feedback)  Disadvantage: order in which classes (units) are to be implemented not dictated by approach.  Must establish which units are most important from the users point of view and start with them

31. Janice Regan, 2008 31 LMS Implementation plan diagram  Order based on importance of each use case as expressed by the user/client Library staff browseResource requestResource reserveResource manageResource checkInResource checkOutResource resource patron managePatron genFormLetter Overdue form letter Phase 4 Phase 1 Phase 2 Phase 3

32. Janice Regan, 2008 32 LMS Example: Thread phase 1 - 1  Implementing checkInResource and checkOutResource use cases during sub phase 1  In this sub phase, we need to implement the following units, then integrate them into build 1  parts of classes in GUI subsystem  parts of classes such as LibrarySystem in LibraryStuff subsystem  parts of classes such as LibraryDB in DB subsystem  Parts of the Patron and Resource classes (and their children) in the LibraryStuff module Part of a class that has been implemented and tested as part of this sub phase GUI subsystem some class LibraryStuff subsystem Library System Resource Part of a class that has been implemented and tested as part of this sub phase DB subsystem LibraryDB Patron

33. Janice Regan, 2008 33 LMS Example: Thread phase 1 - 2  Possible order in which to implement the classes during sub phase 1:  GUI class(es) can be first implemented and unit tested  Resource class is then implemented and unit tested  Patron class is then implemented and unit tested  Finally, LibrarySystem and LibraryDB classes are implemented and unit tested  Once unit tested, they can all be integrated into build 1  Build 1 can be tested (integration testing) by performing the checkInResource use case (function) and the checkOutResource use case

34. Janice Regan, 2008 34 LMS Example: Thread phase 2 - 1  Implementing manageResource use case during sub phase 2  In this sub phase, we need to implement the following units, then integrate the into build 2  parts of classes in GUI subsystem  parts of classes such as LibrarySystem in LibraryStuff subsystem  parts of classes such as LibraryDB in DB subsystem  perhaps the entire Resource class (and its children) in the LibraryStuff module Part of a class that has been implemented and tested as part of this sub phase GUI subsystem some class LibraryStuff subsystem Library System Class that has been fully implemented and tested as part of this sub phase Resource Part of a class that has been implemented and tested as part of this sub phase DB subsystem LibraryDB

35. Janice Regan, 2008 35 LMS Example: Thread phase 2 - 2 You need to consider if the parts of the classes being implemented in thread 2 are substantially independent of those implemented in thread 1  CASE A: If they are substantially different  You can produce build 2 by integrating all units developed during thread 2.  Build 2 can be developed at the same time as build 1.  When build 1 and build 2 have been individually integration tested they can be integrated together into build 3 and integration tested.  CASE B: If they substantially overlap can follow CASE A or  It may be more efficient to modify build 1 by sequentially integrating the partial classes (units) produced in thread 2 into build 1.  When all units for thread two have been integrated you have produced build 2.

36. Janice Regan, 2008 36 LMS Example: Thread phase 2 - 3  Possible order in which to implement the classes during sub phase 2:  GUI class(es) can be first implemented and unit tested  Resource class is then implemented and unit tested  Finally, LibrarySystem and LibraryDB classes are implemented and unit tested  Once unit tested, they can all be integrated into a build  This build (build 3 for CASE A, build 2 for CASE B) can be integration tested  CASE A build 2: by performing the ManageResource use case  CASE A build 3 and Case B build 2: by performing the checkInResource, the checkOutResource, and the manageResource use cases

37. Janice Regan, 2008 37 Implementation plan for class project  We shall use the thread implementation approach  Determine # of sub phases and their content  This is done by considering core use cases versus non-core use cases and distributing the core use cases in the earlier sub phase(s) and the non-core use cases in the later sub phases (why such distribution?)  Build Implementation Plan Schedule by scheduling the sub phases

38. Janice Regan, 2008 38 Test Planning and Test Phases  Unit Test Plan phase  Can be done as soon as you have detailed your classes (units)  Integration Test Plan phase  Technically, can be done as soon as you have defined your subsystems or use cases (parts)  Unit Test phase  Done after coding units, can be done in parallel with implementation phase  Integration Test phase  Done as you are integrating parts, can overlap implementation phase (while coding further units)

39. Janice Regan, 2008 39 Document: Implementation/Test Plan  To document your implementation plan, use  Implementation Plan Schedule  Schedule the sub phases ( coding, inspection, unit test plan, unit testing, integration test plan, integration, integration test) using a Gantt Chart  Add resource (name of assigned team member) to schedule  Update the Gantt chart for your project!  Describe the content of each sub phase  by using your Use Case Diagram (see Textbook, page 246, Deliverable 7.2, note that the textbook use the term “phase”, but we use the term “sub phase”)

40. Janice Regan, 2008 40 For your term project:  Use the thread implementation approach  Determine # of sub phases and their content  Consider core use cases vs non-core use cases  Distribute core use cases between the early phases  Distribute the non core use cases between the late phases  This way you will have a functional, if partially implemented project, after implementing the first phase or phases  Build the Implementation plan schedule by scheduling the resulting sub phases  Be sure you take into account the components needed to test each phase, are the phases independent or sequential.

41. Janice Regan, 2008 41 Evolutionary Software development  S oftware system to be developed is divided into development subgoals (phases)  A sub goal is  One use case for each iteration  A group of tightly coupled used cases for each iteration  In a pure evolutionary approach, each development sub goal is implemented by a full cycle through the development process, from requirements analysis to implementation and testing.