Phase - PowerPoint PPT Presentation

1 / 42
About This Presentation
Title:

Phase

Description:

Create Class Skeletons. Define Implementation Plan ( determine subphases) ... street, city, province, postalCode create an Address object for ... – PowerPoint PPT presentation

Number of Views:65
Avg rating:3.0/5.0
Slides: 43
Provided by: jr2
Category:
Tags: create | phase

less

Transcript and Presenter's Notes

Title: Phase


1
Phase
  • Implementation

2
Overview 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
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
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
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
  • -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

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
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
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 /
  • /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
    /

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
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
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
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
  • Dont forget to document which functional
    requirements are implemented in each sub phase

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
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
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
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
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
Top down approach Step 1
UI
Stub
Stub
Stub
Stub
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
Top down approach Step 2
UI
Core functional layer (implemented stubs for Step
1)
Stub
Stub
Stub
Stub
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
Top 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
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
Bottom up approach Step 1
Driver
Driver
Driver
Database layer (base level methods that call no
other methods)
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
Bottom 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)
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
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
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

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

31
Document 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)

32
LMS Implementation plan diagram
  • Order based on importance of each use case as
    expressed by the user/client

33
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
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
34
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

35
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
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
36
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.

37
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

38
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

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

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

41
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.

42
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.
Write a Comment
User Comments (0)
About PowerShow.com