Title: Phase
1Phase
2Overview of Implementation phase
Create Class Skeletons
Define Implementation Plan ( determine subphases)
Define Coding Standards
For each group of units
For each unit
Create unit Test plans
Implement Methods in class/es
Release unit for integration
Create system Test plan
Code review
Unit test
Integration Testing
System Testing
Create integration Test plan
3Goal 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
4Overview 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
5Where 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 - -listOfBorrowedResources1.. List
- Name String
- Methods visibility, name, parameters and their
types, return type - visibility name (parameter-list)
return-type - getDueDate(patronTypeint, todaysDatedate)date
- getName()String
- The information from each class can help us
create a class skeleton
6Sample 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
/
7Patron 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
8Patron 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 / - /eexpireDate, 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
/
9Patron 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
10Where 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?
11Planning 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
12The 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 - Dont forget to document which functional
requirements are implemented in each sub phase
13Implementation 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
14Implementation 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
15Design 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
16Implementation 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
17Example 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
18Top down approach Step 1
UI
Stub
Stub
Stub
Stub
19Example 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
20Top down approach Step 2
UI
Core functional layer (implemented stubs for Step
1)
Stub
Stub
Stub
Stub
21Example 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
22Top down approach Step 3
UI
functional layer (implemented stubs for Step 1)
Database layer (implemented stubs for Step 2)
Network (or other) layer (implemented stubs for
Step 2)
If any further stubs are needed
Stub
Stub
Stub
23Implementation 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
24Bottom up approach Step 1
Driver
Driver
Driver
Database layer (base level methods that call no
other methods)
25Bottom 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
26Bottom up approach Step 2
Driver
Driver
Driver
Functional layer (methods that call database
level methods)
Database layer (base level methods that call no
other methods)
27Bottom 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
28Bottom 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)
29Implementation 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
30Implementation 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
31Document your Implementation Plan
- To document your implementation plan, use
- Implementation Plan Schedule
- Schedule the sub phases (coding, inspection, unit
test, integration, integration test) using a
Gantt Chart - Add resource (name of assigned team member) to
schedule - 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)
32LMS Implementation plan diagram
- Order based on importance of each use case as
expressed by the user/client
33LMS 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
Part of a class that has been implemented and
tested as part of this sub phase
LibrarySystem
some class
Resource
LibraryDB
Patron
GUI subsystem
LibraryStuff subsystem
DB subsystem
34LMS 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
35LMS 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
Part of a class that has been implemented and
tested as part of this sub phase
Class that has been fully implemented and tested
as part of this sub phase
some class
LibrarySystem
Resource
LibraryDB
GUI subsystem
LibraryStuff subsystem
DB subsystem
36LMS 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.
37LMS 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
38Implementation 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
39Test 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)
40Document 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)
41For 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.
42Evolutionary 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.