CS 477 Lecture Notes
Week Twelve, Thursday: Design Phase (continued)
Team Presentations
Teams doing handoff projects should be well into implementation by now. Teams
doing new projects should be finishing up product design (implementation language,
data structures, and algorithms should all be decided).
Each team will have 7 minutes to present the project status. One minute
will be provided to answer questions from the audience, leaving a one
minute "guard band" between presentations.
Your team presentation may utilize overhead projector slides
(transparencies).
MBASE Teams:
- Implementation: describe progress to date. What modules have been
coded, tested, etc.
- Turn in copies of only those documents that have changed since the last review.
- Turn in a copy of your presentation slides.
Non-MBASE Teams:
- Discuss your product design and plans for implementation.
- Turn in a copy of your design document. This should be based on the specification
and should answer all questions about algorithms and data structures. Every function
should have a name and parameter list, and every class should have a member function
and private data lists, for example. If you are using a high level implementation
tool such as MS Access, you should have a name and field list for each entity and
relationship in your data model, and you should have any necessary SQL queries identified
as to parameters and return values.
- Turn in a copy of your presentation slides.
Design and Abstraction
Three activities take place in the design phase: architectural design, detailed
design, and design testing.
Architectural Design
Specifications are analyzed and a modular decomposition is produced. Output:
list of modules and interconnection descriptions.
Abstraction: assume the existence of certain modules.
Detailed Design
Specific algorithms and data structures are chosen. Output: pseudocode.
Abstraction: ignore module interconnections.
Action-Oriented Design
Two techniques: data flow analysis and transaction analysis. In theory, every
product can be represented by a data flow diagram (DFD). Data flow analysis
can be applied where the specification is represented by a DFD. Transaction
analysis is more appropriate to transaction processing products.
Data Flow Analysis
Input: DFD. Define points of highest abstraction and decompose into modules.
Continue until each module performs a single action (results in modules
with high cohesion).
Transaction Analysis
Transaction processing products are common. The ATM is an example. Also included
in this category are the user interfaces of client-server database systems. The client
initiates a transaction that is handled by the server. This type of product
is also called OLTP (online transaction processing). Transaction analysis is
more appropriate to this type of product than is data flow analysis. There are
many CASE tools for building OLTP products.
Data-Oriented Design
The product is designed according to the structure of the data.
Object-Oriented Design
The product is designed in terms of the objects resulting from object-oriented
analysis. The methods of the classes are determined. Object clients (callers of
of object methods) are determined. Class pseudo-code is written.
Detailed Design
Formal techniques can be used, e.g., writing correctness proofs and pseudo-code in
parallel.
Testing During the Design Phase
Design inspections and walkthroughs (customer representative usually not present).
Inspections can be transaction-driven and specification-driven.
Metrics for the Design Phase
Keep a record of design faults detected. Detailed design complexity can be computed.
OOD complicates metrics.
This page established March 30, 1998; last updated March 27, 2000.