CSE 5324: Software Engineering I

(Analysis, Design, Creation)

Fall 1997

Design - Overview

What is design?

When is it done:

Lifecycles

After Requirement

Before Implementation

Why design?

Makes Implementation Mechanical

Different from Requirement or Code

How is design done:

Many methods:

Structured

OO

Etc.

Goal:

Define process (or system) in enough detail to

Implement. (Create, realize)

What is designed:

Processes (PSPEC) -> procedures

Data (DFD) -> data, architecture

Data (DD) -> data, interfaces

Control (CSPEC) -> procedures

The Design Process

McGlaughlin suggests

Include explicit analysis requirement

Implicit customer desires

Readable and understandable

Code, Test, Maintain

Provide a complete picture of the software:

Data, Function, Behavior

Text guidelines:

Hierarchical organization

Modular and Partitioned

Data and Procedure abstractions

Independent modules

Interfaces to reduce connection complexity

Repeatable method driven by RA

Principles:

(Davis)

Avoid "Tunnel Vision"

Traceable to Analysis

Not reinvent the wheel

Software should mimic the problem domain

Uniform and integrated

Changeable

Fault tolerant (degrade gently) when abnormal

Design not code

Quality during design, not after

Review to avoid semantic error

Concepts:

Abstraction

This is critical

Refinement

Stepwise, decompose

Modular

Divide and conquer

How can this be measured?

(Meyer)

Method to decompose

Reuseable modules

Understandability

Continuity (local effect)

Protected (unusual conditions)

Software Architecture:

Structure

Non-functional (reliablity, security, etc.)

Reuse of realted blocks, systems

Models:

Structure

Dynamic

Process (mapped to application domain)

Functional

Software Architecture:

Modules

A

B C D

E F G H I J

K L M

Terms and Metrics:

Partitioning:

Horizontal

Separate design into branches (functionality)

Maintainable, fewer side effects, testable

Vertical (Factoring)

Top-down

Higher levels make decisions, lower implement

those. Layered system.

Data structure:

Scalars

Vectors

Hierarchical Types

Stacks, trees, linked lists, etc.

What is information hiding?

Share only what is necessary

Modular design:

Cohesion

Module should have a single purpose

(Avoid coincidental cohesion.)

(Logical cohesion maybe OK, temporal?)

Coupling

Modules should avoid unnecessary connections

(shared variables, part of a structure)

(Content coupling – go to into middle of another

module, changing other modules data – Very

(Common coupling – sharing a global variable)

(Control coupling – passing a control "flag")

(Data coupling; stamp coupling – only a part of

data)

Design documentation

Must include:

Scope

Data design

Software architecture

Interfaces

Procedures

How design relates to RA

Test Issues

Must be reviewed.

Design walkthrough – by peers

Design review

Some Design Heuristics:

Use Graphical Notations

Pictures can help

Use PDL (Program Description Lang.)

Use CASE Tools

If possible identify several solutions, evaluate each

Use what fits You

Quality is important

Iterate, go top down

Make design Flexible

Avoid high fan-out, strive for fan-in

Simple interfaces

Re-use