CST 201 DATA STRUCTURES

Module 1

1
System Life Cycle
 The System life cycle(SLC) is defined as collection of the
phases of development through which a computer-based
system passes.

 System life cycle (SLC) is an organizational process of

developing and maintaining systems.

2
System Life Cycle

1. Requirements
2. Analysis
3. Design
4. Refinement and coding
5. Verification

3
1. Requirements
 All large programming projects begin with a set of
specifications that define the purpose of the project.
 These requirements describe the information that we, the
programmers, are given (input) and the results that we must
produce (output).
 Frequently the initial specifications are defined vaguely, and
we must develop rigorous input and output descriptions that
include all cases.

4
2. Analysis
 In this phase, we begin to break the problem down into
manageable pieces.
 There are two approaches to analysis: bottom-up and top-down.
 The bottom-up approach is an older, unstructured strategy
that places an early emphasis on the coding fine points.
 Since the programmer does not have a master plan for the
project, the resulting program frequently has many loosely
connected, error-ridden segments.
 Bottom-up analysis is akin to constructing a building from a
generic blueprint.

5
2. Analysis
 In contrast, the top-down approach begins with the purpose
that the program will serve and uses this end product to divide
the program into manageable segments.
 This technique generates diagrams that are used to design the
system.
 Frequently, several alternate solutions to the programming
problem are developed and compared during this phase.

6
3. Design
 The designer approaches the system from the perspectives of
both the data objects that the program needs and the operations
performed on them.
 The first perspective leads to the creation of abstract data types,
while the second requires the specification of algorithms and a
consideration of algorithm design strategies.

7
3. Design
 For example, suppose that we are designing a scheduling system for a
university.
 Typical data objects might include students, courses and professors.
 Typical operations might include inserting, removing, and searching within
each object or between them.
 That is, we might want to add a course to the list of university courses or
search for the courses taught by some professor.
 Since the abstract data types and the algorithm specifications are language-
independent, we postpone implementation decisions.
 Although we must specify the information required for each data object, we
ignore coding details.
 For example. we might decide that the student data object should include
name, social security number, major, and phone number.
 However, we would not yet pick a specific implementation for the list of
students. 8
4. Refinement and coding
 In this phase, we choose representations for our data objects and
write algorithms for each operation on them.
 The order in which we do this is crucial because a data object's
representation can determine the efficiency of the algorithms
related to it.
 Typically this means that we should write those algorithms that
are independent of the data objects first.
 Frequently at this point we realize that we could have created a
much better system.
 Perhaps we have spoken with a friend who has worked on a
similar project or we realize that one of our alternate designs as
superior. 9
4. Refinement and coding
 If our original design is good, it can absorb changes easily.
 In fact, this is a reason for avoiding an early commitment to
coding details.
 If we must scrap our work entirely, we can take comfort in the
fact that we will be able to write the new system more quickly
and with fewer errors.
 The programmer produces the program code that is needed to
solve the problem.
 The nature of the problem determines how much programming
is required.

10
5. Verification
 This phase consists of developing correctness proofs for the
program, testing the program with a variety of input data, and
removing errors.
Correctness proofs:
 Programs can be proven correct using the same techniques that

abound in mathematics.
 Unfortunately, these proofs are very time-consuming. and

difficult to develop for large projects. Frequently scheduling

constraints prevent the development of a complete set of proofs
for a large system. However, selecting algorithms that have
been proven correct can reduce the number of errors.
11
5. Verification

Testing:
We can construct our correctness proofs before and during the

coding phase since our algorithms need not be written in a specific

programming language.
Testing, however, requires the working code and sets of test data.

This data should be developed carefully so that it includes all

possible scenarios.

12
5. Verification
Testing:
Frequently beginning programmers assume that if their program

ran without producing a syntax error, it must be correct.

 Little thought is given to the input data, and usually only one set

of data is used.
Good test data should verify that every piece of code runs

correctly.
For example, if our program contains a switch statement, our test

data should be chosen so that we can check each case within the
switch statement.

13
5. Verification

Testing:
 Initial system tests focus on verifying that a program runs

correctly.
 While this is a crucial concern, a program's running time is
also important.
 An error-free program that runs slowly is of little value.

 Theoretical estimates of running time exist for many

algorithms and we will derive these estimates as we introduce

new algorithms.
 In addition, we may want to gather performance estimates for

portions of our code.

14
5. Verification
Error removal :
If done properly, the correctness proofs and system tests will

indicate erroneous code.

The ease with which we can remove these errors depends on

the design and coding decisions made earlier.

A large undocumented program written in "spaghetti" code is a

programmer's nightmare.
When debugging such programs, each corrected error possibly

generates several new errors.

On the other hand, debugging a well-documented program that is

divided into autonomous units that interact through parameters is

far easier. This is especially true if each unit is tested separately
and then integrated into the system. 15
Thank You…

16