1 Phase Implementation. Janice Regan, 2008 2 Overview of Implementation phase Create Class Skeletons...
-
Upload
jemimah-bell -
Category
Documents
-
view
218 -
download
0
Transcript of 1 Phase Implementation. Janice Regan, 2008 2 Overview of Implementation phase Create Class Skeletons...
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
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
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
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
Janice Regan, 2008 6
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 */
Janice Regan, 2008 7
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 #
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 */}
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
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?
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
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
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
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
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
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
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
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
Janice Regan, 2008 20
Top down approach: Step 2
UI
Stub Stub Stub Stub
Core functional layer (implemented stubs for Step 1)
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
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 Stub If any further
stubs are needed
Network (or other) layer (implemented stubs for Step 2)
Stub
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
Janice Regan, 2008 24
Bottom up approach: Step 1
Database layer (base level methods that call no
other methods)
Driver Driver Driver
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
Janice Regan, 2008 26
Bottom up approach: Step 2
Database layer (base level methods that call no other methods)
Driver Driver Driver
Functional layer (methods that call database level methods)
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
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)
Janice Regan, 2008 29
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
Janice Regan, 2008 30
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
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
reserveResourcemanageResource
checkInResource
checkOutResource
resourcepatron
managePatron
genFormLetterOverdue form letter
Phase 4
Phase 1
Phase 2
Phase 3
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 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
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
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 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
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.
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
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
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)
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”)
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.
Janice Regan, 2008 41
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.