Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Construction. Implementation System Specification Requirements Analysis Architectural Design Detailed Design Coding & Debugging Unit Testing.

Similar presentations


Presentation on theme: "Software Construction. Implementation System Specification Requirements Analysis Architectural Design Detailed Design Coding & Debugging Unit Testing."— Presentation transcript:

1 Software Construction

2 Implementation System Specification Requirements Analysis Architectural Design Detailed Design Coding & Debugging Unit Testing System Testing Maintenance

3 System Construction/Implementation (cont.) Reviewing other team members’ low-level designs and code and having them review yours Polishing code by carefully formatting and commenting it Integrating software components that have been built separately Tuning code to make it smaller and faster

4 System Construction/Implementation Verifying that the groundwork has been laid so that construction can proceed successfully Designing and writing routines and modules Creating data types and naming variables Selecting control structures and organizing blocks of statements Finding and fixing errors

5 Why is Software Construction Important? Construction is a large part of software development Construction is the pivotal (center) activity in software development With a focus on construction, the individual programmer’s productivity can improve enormously Construction’s product, the source code, is often the only accurate description of the software Construction is the only activity that’s guaranteed to be done

6 Software Metaphors/Style of Programming 1.Software Penmanship: Writing Code: It is like writing a casual letter – just write it from start to finish. It does not require any formal planning Problems: if the software is a project that requires more than one person

7 Software Metaphors/Style of Programming (cont.) 2.Software Farming: Growing a System: It is like planting seeds and growing crops. You design a piece, code a piece, test a piece and add it to the system a little bit at a time Problems: you don’t have any direct control over how the software develops

8 Software Metaphors/Style of Programming (cont.) 3.Software Oyster Farming: System Accretion: This approach is done by adding to your software a small amount at a time, that is, incremental designing, building and testing Problems: it takes time to finish, but more reliable

9 Software Metaphors/Style of Programming (cont.) 4.Software Construction: Building Software: –Developing software like building a tower –It covers planning, preparation, and execution –Apply reuse code, library, tools, etc to speed up the process

10 Prerequisites to Construction (Why is it important?) Prerequisites: the work that must be done to prepare for software construction. Many programmers don’t make preparation because: –They can’t resist the urge to begin coding –Managers force programmer to do coding soon Doing prerequisites before construction is necessary for: –Planning the stages of software development –Create a blueprint to be reviewed and approved before coding –Finding error or mistakes at the early stages

11 Problem-Definition Prerequisite Problem Definition Requirements Analysis Architecture Construction System Testing Future Improvement A clear statement of the problem that the system is supposed to solve.

12 Requirements Prerequisite Formal requirements is important –Help to ensure that the user, not programmer, drives the system functionality –Minimize changes to a system after development –Specifying requirements adequately is a key to a project success, perhaps even more important than effective construction techniques. The cost of errors detected in architecture stage is 5 times more expensive than in requirement phase. If detected in coding, 10 times more expensive; during system test is 20 times; during acceptance test is 50 times; and during maintenance is 100 times.

13 Architecture/Design Prerequisite The quality of the design determines the conceptual integrity of the system, and the quality of the system

14 Typical architectural components: Program organization (project modules) Change strategy (make it flexible to change) Buy vs build decisions (tools, libraries) Major data structures (database structure) Key algorithms (such as sorting technique) Major objects to be implemented Generic functionality (user interface, input/output) Error processing (preventing & detecting error) Robustness (ability to continue running after error) Performance goals (in terms of speed & memory) General architectural quality (open platform, future improvements)

15 Language Selection ProgramBest LanguagesWorst Lang Structured dataC/C++, PascalBasic, Assembler Quick projectVisual ProgrammingPascal, Assembler Fast executionAssembler, CBasic Easy-to-maintainPascal, C++Fortran Real-time program.Assembler, CBasic, Fortran String manipulationBasic PascalC DatabaseOracle, DB2, InformixAccess, GUI + OOVisual ProgrammingC, Cobol, Fortran Numeric ProcessingFortranBasic, C++

16 STEPS IN BUILDING ROUTINE Design the routine Check the design Check the code Code the routine Begin Done

17 PDL (Program Design Language) Use English-like statements that precisely describe specific operations Avoid syntactic elements from the target programming language Write PDL at the level of intent Write PDL at a low enough level that generating code from it will be nearly automatic

18 Example of PDL Increment resource number by 1 Allocate a dig struc using malloc If malloc() returns NULL then return 1 Invoke 0Srsrc_init to initialize a resource Example of bad PDL Example of Good PDL Keep track of current number of resources If another resource is available Allocate a dialog box structure If a dialog box structure could be allocated Note that one more resource in use Initialize the resource Store the resource number Endif Return TRUE if a new resource was created

19 Benefits of using PDL PDL makes reviews easier PDL supports the idea of iterative refinement PDL makes changes easier PDL minimizes commenting efforts PDL is easier to maintain than other forms of design documentation

20 Design the Routine Check the prerequisites Define the problem the routine will solve Name the routine Decide how to test the routine Think about efficiency Research the algorithms and data structures Write the PDL Think about the data Check the PDL Iterate

21 Code the Routine Write the routine declaration –Example: // This routine outputs an error msg // based on an error code supplied.... Procedure RecordErrorMsg { ErrorCode : ErrorCode_t; Var Status: Status_t; };

22 Code the Routine Turn the PDL into high-level comments, –Example: begin //set the default status.... end

23 Code the Routine Fill in the code below each comment Example: Check the code informally Clean up the leftovers Repeat steps as needed begin // set the default status Status := Failure; …… end

24 Code the Routine Check the code formally –Mentally check the routine for errors –Compile the routine –Use the computer to check the routine for errors –Remover errors from the routine


Download ppt "Software Construction. Implementation System Specification Requirements Analysis Architectural Design Detailed Design Coding & Debugging Unit Testing."

Similar presentations


Ads by Google