1 phase implementation. janice regan, 2008 2 overview of implementation phase create class skeletons...

1

Phase

Implementation

Janice Regan, 2008 2

Overview of Implementation phase

Create Class Skeletons

Define Implementation Plan (+ determine subphases)

Define Coding Standards

For each unit

ImplementMethods in class/es

Code review

Unit test

Create integration Test plan

Create unitTest plans Release unit

for integration

IntegrationTesting

System Testing

Create systemTest plan

For each group of units


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


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


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


Sample class skeleton: following textpublic 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 */


Patron class (continued - 2)/* Instance variables */private string name; //name of Patron, Last, First, MIprivate long patronID; //Patron's library ID#, sequentially generatedprivate long homePhone; // area code (3), local exchange (9)private Date memberDate; //date of first membership mmddyyyyprivate Date expireDate; //date membership expires mmddyyyy private List resourceList; //List of resources checked out by patronprivate Address homeAddress;

/*Class Variables */private static long nexPatronID; //next available patron ID #


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 */}


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


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?


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


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


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


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


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


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


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


Top down approach: Step 1

UI

Stub Stub Stub Stub


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



UI

Stub Stub Stub Stub

Core functional layer (implemented stubs for Step 1)


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



UI

functional layer

(implemented stubs for Step 1)

Database layer (implemented stubs for Step 2)

Stub Stub If any further

stubs are needed

Network (or other) layer (implemented stubs for Step 2)

Stub


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


Bottom up approach: Step 1

Database layer (base level methods that call no

other methods)

Driver Driver Driver


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



Database layer (base level methods that call no other methods)

Driver Driver Driver

Functional layer (methods that call database level methods)


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



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)


Implementation ApproachesAdvantages 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


Implementation Approaches - 4 Threads

Implement and test a minimal set of classesimplementing 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


LMS Implementation plan diagram Order based on importance of each use

case as expressed by the user/client

Library staff

browseResource

requestResource

reserveResourcemanageResource

checkInResource

checkOutResource

resourcepatron

managePatron

genFormLetterOverdue form letter

Phase 4

Phase 1

Phase 2

Phase 3


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 modulePart of a class that has been implemented and tested as part of this sub phase

GUI subsystem

some class

LibraryStuff subsystem

LibrarySystem Resource

Part of a class that has been implemented and tested as part of this sub phase

DB subsystem

LibraryDB Patron


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


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 modulePart of a class that has been implemented and tested as part of this sub phase

GUI subsystem

some class

LibraryStuff subsystem

LibrarySystem

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


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.


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


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


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)


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”)


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.


Evolutionary Software development Software 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.

1 phase implementation. janice regan, 2008 2 overview of implementation phase create class skeletons...

Documents