1

CSCD 326 Data Structures ISoftware Design

2

The Software Life Cycle

1. Specification

2. Design

3. Risk Analysis

4. Verification

5. Coding

6. Testing

7. Refining

8. Production

9. Maintainence

3

1. Specification

Determine needs of program users.

Involves communication with non-programmers to determine needs in detail.

Must explain all necessary aspects of the program to programmers.

May involve construction of a prototype program to get more details from users.

4

2. Design

Generate an outline of the problem solution.

Requires breaking the entire problem down into small manageable parts - modules.

Modules are self-contained units of code.

Modules should be loosely coupled except for the inter-module communication mechanism -the module interface.

Must include specification of not only module purpose and interface but also of how data flow will happen between modules.

5

2. Design (con't)

One or more program modules may already have been implemented.

The Java Application Programmer's Interface (API) contains many class libraries of already implemented modules.

Programmers do not have access to the source code for these modules but documentation explains the interface for each module.

6

3. Risk Analysis

Risks are primarily business related but can be personal as well.

Example: If a piece of software is not ready in time the company may lose the market to a competitor.

Not an important issue for this course.

7

4. Verification

Formal theoretical methods for proving algorithm correctness.

Assertions - a statement about conditions at a particular point of a algorithm.

Invariants - a condition that is always true at a particular point in an algorithm.

Loop Invariant - a condition that is always true before and after each iteration of a loop.

Algorithm proving techniques are very similar to inductive proofs.

8

5. Coding

Translation of the design specification into a particular programming language.

A minor and sometimes automated part of the entire cycle in industry.

Programming language knowledge is taken for granted at upper levels of computer science.

9

6. Testing

Often involves testing individual methods of the solution using dummy programs that call the methods with appropriate data.

Eventually involves testing of the entire program.

10

7. Refining the Solution

Usually involves increasing the "robustness" of a solution.

Often simplifying assumptions are made in the design process that must be removed from final versions.

Example: assume that the input will be be integers between 0 and 1000.

During this step code would be inserted to actually test the input values.

11

8. Production

Distribution of the software to user's and installation on their machines.

12

9. Maintainence

Two components:

Users detect errors not discovered during testing - very common in complex programs.

These errors must be fixed for subsequent releases.

Enhancing software by adding new features.

13

Documentation

All levels of the software life cycle depend on good documentation.

Especially important when software is developed in a group environment.

14

Modular Design Concepts

Key techniques for use in achieving a modular design are:

Abstraction and Information Hiding

Object-Oriented Design

Top Down Design

15

Abstraction

Abstraction separates the purpose of a module from its implementation.

16

Procedural Abstraction

Procedural Abstraction is the process of separating the purpose of a method from its implementation.

Once written the method can be used without any knowledge of how it is implemented - only need to know the parameters.

Example: nearly all methods in the entire Java API.

Essential in team projects.

17

Data Abstraction

Given a collection of data and a set of operations that can be performed on the data.

Data Abstraction focuses on what the operations do rather than how they are implemented.

18

Abstract Data Types

ADT - a collection of data along with a set of operations that can be performed on that data.

No details about how the data is stored or how the operations on the data are implemented.

An ADT is a general description of the design of a module with no details.

The interface of a module can be a part of an ADT.

19

Abstract Data Types

Data Structure - the implementation of an ADT in a programming language.

The details of data storage and how operations are performed are crucial parts of a data structure.

20

ADT List

Any List in general will allow the following operations:

Create an empty list

Destroy a list

Determine whether a list is empty

Determine the number of items in a list

Insert an item at a given position in the list

Delete the item at a given position in the list

Look at (retrieve or get) the item at a given position in the list

21

Information Hiding

Information hiding

After a module is implemented, a user of the module does not need to know how the module stores data or performs operations .

Module's interface

The means by which the user gets the module to perform its operation(s).

The only information that is not hidden from the module user.

Referred to the by the textbook as a "wall".

22

Information Hiding Implementation

Accessibility modifiers:

Public view of a module - consists of all public data elements and methods -defines the module's interface.

Private or protected data elements and methods - define the parts of the module's data storage or operations that users will not be allowed to see.

23

Object-Oriented Design

Three elements to OOD:

Encapsulation - combining data and operations within one object.

Inheritance - objects can inherit data and/or methods from other objects.

Polymorphism - objects can determine operations at execution time.

Every object knows its "true" type regardless of type casting

24

Top-Down Design

Focused on algorithm design.

A method for designing the way object operations will be performed.

Provides a tool for moving from ADT's which generally use procedural abstraction to an implementation in a programming language.

Goal is to break a large problem into a set of smaller problems that are more easily solved.

25

Top-Down Design

Structure Charts:

26

Pseudocode

A tool for moving from a structure chart to a specific implementation.

Pseudocode can vary from written descriptions to compilable code.

It is usually code-like but ignores many code details needed by compilers.

Successive Refinement:

Start with a very general description of what the algorithm will do

Work toward more code-like details.

27

Successive Refinement Example (1)

Early pseudocode for the get operation from ADT List:

get (index)

// returns the item at position index of a list

// if 0 <= index < size the list is left unchanged

// Throws an exception if index is out of range

Assuming that the implementation of List will store data in an array - more specific get pseudocode.

28

Successive Refinement Example (2)

Assuming that the implementation of List will store data in an array - more specific get pseudocode.

get (index){ if( index > alist.size ) throw out of range exception return alist.array[index]}

The final refinement involves writing a Java class to implement the list ADT