CSCD 326 Data Structures I Software Design

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 lt index lt 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 gt alist.size )
• throw out of range exception
• return alist.arrayindex
• The final refinement involves writing a Java
  class to implement the list ADT