CSC-335 Data Structures and Algorithms
(Chapter 1 Software Development)
Instructor: Ahmad Reza Hadaegh
The content of this power point lecture has been originally created by Christos Kolonis and modified by Dr. Ahmad R Hadaegh
Chapter Contents
1.1 Problem Analysis and Specification 1.2 Design
1.3 Coding
1.4 Testing, Execution, and Debugging
1.5 Maintenance
Chapter Objectives
Introduce software development approaches
Contrast software development in programming course with real world Study top-down, objected oriented approaches Introduce design aspects
Select or build data types Develop algorithms for operations on data
Investigate error types Emphasize importance of testing Note time and effort devoted to maintenance
5 Phases of Software Life Cycle
Waterfall Model
4
5 Phases of Software Life Cycle
Realistic Waterfall Model
5
1.1 Problem Analysis and Specification
CS courses
small systems
few hundred lines of
code simple, straightforward self-contained
Real world
large systems
thousands of lines of code complex many components problem initially poorly defined
1.1 Problem Analysis and Specification The specification or "contract" will include
Purpose
Precondition Postcondition
Real world contracts
Must be precise May be required to prove end product meets these precise specifications
1.2 Top Down Design Original problem partitioned into simpler sub problems
Each of these sub problems likewise subdivided
1.2 OOD: Object-Oriented Design Identify the objects in the problem's specification and their types. Identify the operations or tasks to manipulate the objects
1.2 OOD: Object-Oriented Design
Fig. 1.7
UML class diagram
10
1.2 Data Types of the Objects Simple Structured
arrays structures Class objects
Think of them as Containers
11
1.2 Algorithms Pseudo code Must be
Definite, unambiguous Simple Finite correct and efficient well structured
Cannot separate data structures from algorithms
12
Fig. 1.8(a)
1.2 Algorithms
Fig. 1.8(b)
Structured
while loop switch stmt Unstructured goto's
if-else's
13
1.3 Coding
Select language of implementation Encode the design Example
Figure 1.9 Financial-aid update function Figufre 1.10 Test-driver for Financial-aid update function Figure 1.11 Header file for FinancialAidAward class Figure 1.12 Implementation file for FinancialAidAward class
14
14
1.3 Coding
Verify integration combining program units into a complete software system. Insure quality programs must be correct, readable, and understandable well-structured, documented, formatted for readability
15
1.4 Testing, Execution, and Debugging
Validation: "Are we building the right product?" check that documents, program modules, etc. match the customer's requirements. Verification: "Are we building the product right?" check that products are correct, complete, consistent with each other and with those of the preceding phases.
16
16
1.4 Different Kinds Of Tests Required
Unit tests:
Each individual program unit works? Program components tested in isolation
Integration tests :
Units combined correctly?
Component interface and information flow tested
System tests:
Overall system works correctly?
17
17
The "V" Life Cycle Model
FIG. 1.13
18
Types of Errors Syntax errors
errors in the grammar of the programming language
Ex: forgetting ; at the end of the sentence.
Run-time errors
happen during program execution Ex: Division by zero
Logic errors
errors in algorithm design Ex: instead of a = b + c you have written a = b - c
19
Black Box or Functional Test Outputs produced for various inputs
Checked for correctness Do not consider structure of program component itself.
Program unit is viewed as a black box
Accepts inputs and produces outputs, Inner workings of the box are not visible.
20
20
White Box or Structural Test Performance is tested
examine codes internal structure.
Test data is carefully selected
specific parts of the program unit are exercised.
Shows what is going on
21
21
Maintenance
Large % of
Computer center budgets Programmer's time Software development cost
Because
Includes modifications and enhancements Poor structure, poor documentation, poor style
Bug finding and fixing is tougher Delays implementation of enhancements
22
22
