Chapter 15 Design, Coding, and Testing

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Design Document The next step in the Software Engineering process after preparing the Specification Document is to perform the design and prepare the Design Document In contrast with the Specification Document that describes what the system is supposed to do, the Design Document describes how the system is to do what it does

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Readers of the Design Document Coding Group, which use it to produce the code Quality Control Group, which use it to design tests Maintenance Group, which will use it, at a later time, to implement system enhancements

Copyright © 2005 Pearson Addison-Wesley. All rights reserved By Contrast: Readers of the Specification Document Customer, who uses it to determine that the system will satisfy its needs and that the delivered version is correct Design Group, which uses it to perform the design Quality Control Group, which uses it to design tests Maintenance Group, which will use it, at a later time, to implement system enhancements

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Design Document (con’t) The design document includes –The (compilable) declaration of every global data structure used in the system The complete database schema (possible with an E-R diagram) Any objects used in the application programs –The decomposition of each database interaction into transactions and procedures –Detailed description of the behavior of every module, object, procedure, and transaction

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Database Design The Design Document must contain a complete design of the database including executable statements that declare the database schema –E-R or UML diagrams are used to model the business objects in the enterprise –These diagrams are converted into relational schemas –The schemas are normalized and tuned –These topics were discussed in Chapters 4, 6, 9, and 12

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Transaction Design Our main concern in this chapter is with transaction design One important part of transaction design is specifying how the execution of a transaction changes the internal state of the objects in the database

Copyright © 2005 Pearson Addison-Wesley. All rights reserved UML State Diagrams UML class diagrams and E-R diagrams provide static models of the business objects in an enterprise UML state diagrams can be used to model the dynamic behavior of those objects –How their internal state changes when their methods are invoked

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Available Full Start/Enrollment=0 Deregister/Enrollment=Enrollment-1 [Enrollment<MaxEnrollment-1] Register/Enrollment=Enrollment+1 [Enrollment=MaxEnrollment-1] Register/Enrollment=Enrollment+1 Deregister/Enrollment=Enrollment-1 A UML State Diagram for the Class Object

Copyright © 2005 Pearson Addison-Wesley. All rights reserved State Diagram for Class Object Class has two states Available and Full –Based on integrity constraint that class size cannot exceed MaxEnrollment Transitions between states are of the form [guard] operation / action –Guard: specifies when the transition can take place –Operation: the method that causes the transition –Action: how the internal attributes of the object change when the transaction takes place.

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Uses of State Diagrams Can be used to communicate the design to –Other designers –Coders who must implement the design –Test designers who must test the final system A good test set must visit all the states in the diagram.

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Description of a Transaction Name Brief Description Arguments -- in and out, and Return Values Called from, and Calls –The event or procedure that calls it and those it calls Preconditions (what is true when it starts) Isolation level Actions –Detailed description of what it does, what tables it accesses, what validity checks it makes, what constraints it checks, what it does if it finds an error, etc

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Design Review When Design Document is complete, designers hold a Design Review with technical peers –Is the Design Document consistent with the Specification Document? –Is the Design Document inconsistent, incomplete, ambigious? –Can the design be improved? –What are the risks involved in the design?

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Test Plan Testing is an important part of the project, not an informal ad hoc activity that starts after the code is complete –Module tests – each programmer checks his code before submitting it –Integration Tests – as the modules are integrated into the system –Quality Assurance Tests – when the implementers think the system works

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Quality Assurance Tests Black Box Tests –Designed without looking inside the design and code –Does the system meet its specifications –There must be at least one test for each numbered specification Glass Box Tests –Designed looking at the design and code –Tests must visit every line of code, every branch, check boundary conditions of every loop, invoke every event, execute every integrity check, check all error situations Stress Tests –Does the system meet its specifications for throughput and response time

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Test Plan Document Contains scripts of all tests and the correct result for each Highly desirable to employ a test driver or scripting mechanism to perform test automatically because tests will be repeated many times Must include some mechanism for reporting bugs and ensuring that the final version includes all bug fixes Contains the rationale for each test, so test plan can be maintained and enhanced as the system evolves If the implementors are in a different organization than the customer, the Test Plan Document is often a deliverable with the product

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Acceptance and Beta Testing Acceptance Testing –Before accepting and paying for the system, the customer runs its own acceptance tests –Using real data from the application Beta Testing –If the system is a product and there are many customers, developers might select a subset of the customers to be beta testers –Beta testers use the system and report errors After delivery, the system is often run in parallel with the existing system until its reliability has been demonstrated

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Project Planning Document Project Planning is a key aspect of any Software Engineering project –Initial plan should be made while specification is being done and refined while design is being done. Manager divides the project into tasks –The completion of each task can be precisely defined –Task can be completed in some short period of time –Estimating the time for task completion takes experience and knowledge –Manager then determines task dependencies Task 6 cannot be started until Task 2 completes Tasks 1 and Task 2 can be done at the same time Plan can be documented using charts

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Dependency Chart (PERT Chart)

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Critical Path The longest path through the PERT chart is called the critical path –Lower bound on the time required to complete the project –In the example, Tasks 2, 6, and 7 form the critical path and the corresponding lower bound on project completion time is 27 days

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Activity Chart (Gantt Chart)

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Staff Allocation Chart

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Planning To be accurate, charts must take into account such factors as –Experience and competence of people assigned to each task –Holidays and vacations –Percentage of time people will spend on project Although project planning software can automate the generation of charts, the preparation and monitoring of a project plan requires considerable skill and experience –Poor project management is the cause of most failures

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Project Management The project manager schedules periodic (weekly) project meetings Team members report on status and expected completion time of their tasks compared to scheduled completion time Project manager takes appropriate steps to ensure project completes on time

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Coding Highest priorities are correctness and clarity All coders should use the same style Comments –Each module and procedure should have a preamble, including a description of what the code is supposed to do and a revision history –Comments in code should be application- oriented Give all employees a 5% raise

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Incremental Development Many projects take a long period of time –System requirements might change during that time Incremental development involves building the system in stages, each of which can be implemented in a short period of time –Initially a core version with limited capability is built –Later, new versions are built with increased functionality and based on new customer requirements and on customer experience with older versions

Copyright © 2005 Pearson Addison-Wesley. All rights reserved Design and Code for Student Registration System Text contains –Complete design of database schema, including integrity constraints –Complete design of Registration Transaction –Partial code for Registration Transaction