Transcript Design - Specfication

Illinois Institute of Technology
CS487
Software Engineering
Component Level Design & Design
Documentation
Instructor: David A. Lash
CS48709-1/32
Design Process
Functional Design
Architectural Design
New
Function
Architectural
Specification
Architectural
Defect
Functional Design
Functional
Specification
Functional
Defect
Write Document
Design
Document
Review Specification
Approved
CS48709-2/32
Component-level Design

Purpose: Translate the design model into
operational software
–
–
–
–
–
Establishes the algorithmic detail of the design
Normally done by software engineer
Determines what the program will do before
worrying about the details of the code.
Output is generally a graphic representation,
table, text-based pseudo-code
Generally reviewed via design review
CS48709-3/32
Component-level Design Structured Programming

Concepts formed in 1960s, by Dijkstra and
others
–
Proposed a set of logical constructs from
which any program can be formed.
Each construct have a “predictable logical
structure”. (once identified can understand
easier)

–
–
–

The idea has been to limit procedural
design to a small number of constructs
–
CS48709-4/32
Sequence
Repetition
Condition
enhance readability, testability and
maintainability.
Component-level Design Structured Programming
F
T
Condition
(if-then-else)
Sequence
F
T
T
F
Do While
CS48709-5/32
Repeat Until
Repetition
SP Constructs Use


Using the 3 only can be quite useful
Strict use of only the 3 constructs can lead to
inefficiency and be awkward:
–
Sometimes escape from loop or nesting
conditions use SP constructs only can become
awkward.
Either redesign or allow an “escape branch”

CS48709-6/32
Program Design Language
(Pseudocode)



Original developed as a design tool for
assembler language programmers.
As a design tool today it is not often used
because of high-level and middle-level
language.
Works well in teaching.
–

Showing logical coding fragments.
Analysis is an iterative process that requires
some design. Pseudocode provides a view of
what is required.
CS48709-7/32
Pseudocode Characteristics

Can use any language syntax. i.e. Ada or C

Characteristics for a design language
–
–
–
–
Fixed syntax of keywords with structured
constructs
Free syntax describing processing features
Data declaration facilities (scalar and complex)
Subprogram definition and calling conventions
CS48709-8/32
Pseudocode Examples
keywords
Statement
Termination
PROCEDURE security.monitor;
INTERFACE RETURNS system.status;
Interface declaration
CS48709-9/32
Pseudocode Example (data
declaration)
TYPE signal IS STRUCTURE DEFINED;
name IS STRING LENGTH VAR;
address IS HEX device location;
bound.value IS upper bound SCALAR;
message IS STRING LENGTH VAR;
END signal TYPE;
Structure or record
CS48709-10/32
declaration
Pseudocode
(Commands and Instruction)
Procedure Statement
Initialize all system ports and reset all hardware;
CASE OF control.panel.switches (cps);
WHEN cps = “test” SELECT
CALL alarm PROCEDURE WITH
“on” for test.time in seconds;
Case Statement
CS48709-11/32
More Pseudocode
Loop Construct
REPEAT UNTIL activate.switch is turn off
reset all signal.values and switches;
DO FOR alarm.type = smoke, fire, water, burglar;
READ address[alarm.type] signal.value;
IF signal.value > bound[alarm.type]; THEN
phone.message = message[alarm.type];
set alarm.bell to “on” for alarm.seconds;
PARBEGIN
Decision
,
,
Statement
,
PAREND
ENDIT
CS48709-12/32
ENDREP
ENDFOR
Design Process
Write Document
Architectural Design
New
Function
Architectural
Specification
Architectural
Defect
Functional Design
Functional
Specification
Functional
Defect
Write Document
Design
Document
Review Specification
Approved
CS48709-13/32
Design Documentation Detail

IEEE/ANSI Std1016 Recommended Practice
for Software Design Descriptions
–
Defines elements necessary for functional
design
–
Provides suggested organizational concepts
CS48709-14/32
Functional Design:
Recommended Practices

Key Concepts:
–
Design entity - An element of a design that
is structurally and functionally distinct
from other elements and that is
separately named and referenced
–
Some Sample Design Entities:



CS48709-15/32
a component Level module - processing,
function,
an architectural layer - design restrictions
and limitations
The global and local data structures - data
type restrictions, bounding values, memory
usage limitations
Functional Design:
Recommended Practices

Key Concepts:
–
Entity attribute - A named characteristic or
property of a design entity. It provides a
statement of fact about the entity

CS48709-16/32
Its identify, type, purpose, function, etc
Functional Design:
Entity Attributes

Design Entity Attributes
–
–
Identification - The name of the entity
Type - A description of the kind of entity,
i.e. function, process, data store, interface,
etc.
Purpose - A description of why the entity
exists
Function - A statement of what the entity does

–
–
CS48709-17/32
Functional Design:
Entity Attributes

More Design Entity Attributes
–
Processing - description of the processing of
each module
that is, the tasks, decisions, and I/O
the rules used by the entity to achieve its
function
Data - A description of data elements internal
to the entity (major structures in design)
Interface for each entity - A description of
how other entities interact with this entity
that is, internal module, external system
and human/computer description


–
–

CS48709-18/32
Functional Design - Entity
Attributes

More Design Entity Attributes
–
–
–
Subordinates - The identification of all entities
composing this entity
Dependencies - A description of the
relationships of this entity with other entities
Resources - A description of the elements
used by the entity that are external to the
design. i.e. printers, scanners, software
services, etc.
CS48709-19/32
Narratives to Attributes

Single words
–
–

Narrative
–
–
–

Identification
Type
Purpose (One sentence)
Function (One or two paragraphs)
Processing
Lists
–
–
Data (major internal structures)
Resources
CS48709-20/32
Relating Diagrams to Attributes

E/R Diagram
–
Dependencies (data) - A description of the
relationships of this entity with other entities
–
Subordinates (data) - The identification of all
entities composing this entity

Data Flow Diagram
–
Processing - A description of the rules used by
the entity to achieve its function
–
–
Dependencies
Interfaces - A description of how other entities interact
with this entity
CS48709-21/32
Relating Diagrams to Attributes

State Diagram
–
Processing - A description of the rules used by
the entity to achieve its function
–

Dependencies
Structure Chart
–
Subordinates - The identification of all entities
composing this entity
–
Dependencies - A description of the relationships
of this entity with other entities
–
Interface - A description of how other entities interact
with this entity
CS48709-22/32
Design Process
Write Document
Architectural Design
New
Function
Architectural
Specification
Architectural
Defect
Functional Design
Functional
Specification
Functional
Defect
Write Document
Design
Document
Review Specification
Approved
CS48709-23/32
Methods of Organizing the
Design Document

Design View
–
A subset of design entity attributes information
that is specifically suited to the needs of a
software project activity.
CS48709-24/32
IEEE Suggested View
Design View
Scope
Partition of the
Decomposition
system into
Description
design entities
Dependency
Description
CS48709-25/32
Description of
the relationship
among entities
and system
resources
Entity
Attributes
Example
Representation
Identification,
type, purpose,
function,
subordinates
Hierarchical
decomposition
diagram,
natural
language
Identification,
type, purpose,
dependencies,
resources
Structure
charts, data
flow diagrams,
transaction
diagrams
IEEE Suggested View
Design View
Interface
Description
Detail
Description
CS48709-26/32
Scope
Entity
Attributes
List of
Identification,
everything a
function,
designer,
interfaces
programmer, or
tester needs to
know to use
the design
entities that
make up the
system.
Description of
the internal
design details
of an entity.
Identification,
processing
data
Example
Representation
Interfac100e
files, parameter
tables
Flowcharts, NS charts, PDL,
state diagrams,
data flow.
A modern View
Design View
Scope
Description of the
structure of the
Architectural components and how
view
they will fit in the
environment. Include
modules and data stores
Functional
view
Description functional
characteristics and how
the perform there
purpose. Include
Processes, Modules and
data.
CS48709-27/32
Entity
Attributes
Identification,
type, purpose,
subordinates,
interfaces,
dependencies,
resources,
Identification,
type, purpose
function,
processing
Example
Representation
E-R diagrams,
Module charts,
data flow
diagrams
Architectural
diagram
Data flow
diagrams,
decision tables,
PDL, N-S charts,
state diagrams.
Design Process
Review
Architectural Design
New
Function
Architectural
Specification
Architectural
Defect
Functional Design
Functional
Specification
Functional
Defect
Write Document
Design
Document
Review Specification
Approved
CS48709-28/32
Design Specification Review
Checklist

General Review issues
–
Are diagrams clear?
Are they labeled correctly?
Is there enough supporting detail to make
them clear?


–
Is the language clear?
Was active voice used?
Written in the present tense?


–
Is the behavior consistent with process?
–
Do inconsistencies and omission exist?
CS48709-29/32
Design Specification Review
Checklist

Design Specification Review issues:
–
–
–
–
–
–
–
Are all functions referenced to the
requirements specification?
Are the requirement constraints met?
Are the interfaces complete?
Are the interface broader than necessary?
Does each entity achieve its purpose?
What is the cohesion and if not functional then
why?
What is the coupling and if not data then why?
CS48709-30/32
Design Specification Review
Checklist

Suggestion
–
Document some hypothetical test cases and
use then to exercise the design
CS48709-31/32
Design Methodologies

What is a design methodology?
–

The myth
–

A collection of rules and procedures that
govern how the analysis and design process
proceeds
A magical solution that resolves all of the
problems with software development
The reality
–
Software design is hard work and there are no
magic solutions; just the application of sound
principals.
CS48709-32/32