Software Design

Software Design

CS215 – Software EngineeringReference: Software Engineering Concepts

Richard Fairley

Software Design

The process of design involves “conceiving and planning out in mind and making a drawing, pattern and sketch of it

Software Design

External Design

Architectural Design

Detailed Design

Internal Design

External Design

External Design involves conceiving, planning out, and specifying the externally observable characteristics of software product. The external design includes• User displays and report format•External data source and sinks•Functional Characteristics • Performance requirement and high level process structure.

Internal Design

Internal design involves conceiving, planning out and specifying the internal structure and processing details of the software. The main aim is to record•Design decisions•Indicate why certain alternative and trade-off were chosen•Elaborate test plan•To provide a blue print for implementation, testing and maintenance activity,

Internal Design

Outcome of Internal Design are

• Architectural structure• Details of algorithms and data structures• Test plan

Architectural Design

• Concerned with refining the conceptual view of the system.

• Identifying internal processing functions• Decomposing high-level functions into sub

functions.• Defining internal data streams and data stores• Establishing the relationship and interconnection

between among functions and data streams and data stores.

Detailed Design

• includes specification of algorithm that implement the functions.

• Concrete data structure that implement the data stores.

• The actual interconnection among the functions and data structures

• Packaging scheme for system

Phases Analysis Design Implementation

ActivitiesPlanning and requirement definition

External

Architectural

Detailed

Coding

Debugging and testing

Reviews SSR PDR CDR

Phases in the design process

Architecturaldesign

Abstractspecificatio

n

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products

Design phases• Architectural design Identify sub-systems• Abstract specification Specify sub-systems • Interface design Describe sub-system interfaces• Component design Decompose sub-systems

into components• Data structure design Design data structures to hold

problem data• Algorithm design Design algorithms for problem

functions

Design Concepts

• Abstraction• Structure• Information hiding • Modularity• Concurrency• Verification• Design aesthetics

Abstraction

•Abstraction is the intellectual tool that allow us to deal with concept apart from their implementations. •Abstraction permits the separation of conceptual aspects from the implementation details. •Abstraction allow us to organize and channel out our thought process by postponing the structural consideration and detailed algorithm details until the functional characteristics, data streams and data stores have been established.

Abstraction Mechanism

• Functional Abstraction• Data abstraction• Control abstraction

Functional Abstraction

• Involves the use of parameterized sub program. The ability to parameterized a sub program and to bind different parameter values on different invocations of the subprogram is a powerful abstraction mechanism.

• Functional abstraction can be generalized to selection of sub programs called as groups.

• Some of these subprograms may have visible property and some may be hidden,

Data Abstraction

• Involves specifying a data type or data object by specifying legal operations on them; representation and manipulation details are suppressed. E.g. for stack can specify POP, PUSH operation without their actual implementation.

• Abstract data type are abstract in the sense that the representation details of the data items and the implementation detail of functions that manipulate the data items are hidden within the group that implements the abstract data type.

Control Abstraction

• Is used to state a desired effect without stating the exact mechanism of control. e.g. IF and WHILE statements are example of abstraction of machine code implementation that involves conditional jump instruction.

“ for all I in S sort files I”

Information Hiding

• Using Information hiding approach, each module in the system hides the internal details of its processing activities and modules communicate only through well defined interfaces.

• Design should begin with the a list of difficult design decisions and design decisions likely to change.

Information Hiding

• Each module is designed to hide such a decision from other modules.

Other candidates for information hiding include• A data structure, its internal linkages, and the

implementation details of the procedures that manipulate it.

• The format of control blocks such as those for queues in an operating system.

• Character codes, ordering of character set, and other implementation details.

Information Hiding

• Shifting, masking, and other machine dependent details.

Structure• The use of structuring permits the

decomposition of large system into smaller, more manageable units with well-defined relationships to the other units of the system.

• The most general form of the system structure is the network. A computing network can be represented as directed graph, consisting of nodes and arcs.

• The nodes can represent processing elements that transform the data and the arcs can be used to used to represent data links between nodes.

Structure

• Alternatively node can represent data stores and and the arcs data representation.

• A network might specify the data flow and processing steps for single subprogram or the data flow among a collection of sequential subprograms.

• The most complex form of computing network is a distributed computing system in which each node represents a geographically distinct process with private memory.

Structure

• Inside each processes one might have functional abstraction groups ,data abstraction groups and control abstraction group.

• Each group might consist of visible specification part and a hidden body.

ModularityModular systems consist of a well defined, manageable units with well defined interfaces among units Desirable properties of modular system includes]

• Each processing abstraction is a well defined sub system that is potentially useful in other application.• Each function in each abstraction has a single, well defined purpose.•Each function manipulate no more than one major data types.

Modularity

• Function share global data selectively. It is easy to identify all routines that shares a major data structure.

• Function that manipulate instances of abstract data types are encapsulated with the data structure being manipulated.

Concurrency

• Software systems can be categorized as sequential or concurrent. In sequential systems only one portion of the software is active at any time.

• Concurrent system can have independent processes that can be activated simultaneously if multiple processors are available.

Concurrency

• Problems unique to concurrent system includes Deadlocks Mutual Exclusion Synchronization of processes• Concurrency is the fundamental principle of

software design because parallelism in software introduces added complexity and additional degrees of freedom into design process.

Verification

This is typically done in two steps:

• verification that the software requirement definition satisfy the customer needs( verification of requirements)

• verification that the design satisfy the requirements definition( verification of the design).

Aesthetics

Simplicity, elegance and clarity of purpose distinguish products of outstanding quality from mediocre products

Design Notations

• Data flow diagrams• Structure charts• HIPO diagrams• Procedure specifications• Pseudocode• Structured English• Structured Flowcharts

Data flow diagrams

• Data flow diagrams are directed graphs in which the node specify the processing activity and the arcs specify the data items transmitted between processing nodes.

Data Flow Diagram(depicting flow of data among components)

Source or Destination of Data

Flow of Data

Processing

Data Store

Example of DFD

CustomerProcess

OrderPackage

Order

Inventory Info Packaging Instructions

Customer Info

Order

Invoice

ShippingInstruction

Structure Charts• Used during architectural design to document

hierarchical structure, parameters, and interconnections in a system.

• The structure of a hierarchical system can be specified using a structure chart.

• The chart can be augmented with module- by-module specification of the input and output parameters, as well as input and output parameter attribute.

• During architectural design the parameter attributes are abstract: they are defined into concrete representation during detailed design.

Difference Between Flow Chart and Structure Chart

• Structure chat has no decision boxes.

• Sequential ordering of task inherent in flow chart can be suppressed in structure chart.

Format of a structure chart

A

B C D E

F G H

Input Data

OutputData

in out12345678

Repetition

Selection

HIPO diagrams• HIPO diagrams( Hierarchy-Process-Input-Output) were

developed at IBM as design representation scheme for top-down software development, and as external documentation aids for released products.

• A set of HIPO diagrams contains a visual table of contents, a set of overview diagrams and a set of detail diagrams.

• The visual table of contents is a directory to the set of diagrams in the package; it consists of a tree-structured directory, a summary of contents of each overview diagram and a legend of symbol definition .

HIPO Diagrams

• The visual table of contents is a stylized structure chart.

• Overview diagrams specify the functional processes in the system. Each overview diagram describes the inputs, processing steps, and outputs for the function being specified. An overview diagram can point to several subordinate detail diagrams, as required.

Visual Table of Contents for a HIPO package

Legend

Contents1. ---2. ---3. ---

1

2 5 8

3 4 6 7 9

10 11

12

Procedure Templates

• Procedure interface specifications are effective notations for architectural design when used in combination with structure charts and data flow diagrams.

• They also provide a natural transition from architectural to detailed design and from detailed design to implementation.

Procedure TemplatesPROCEDURE NAME:PART OF( subsystem name & number)CALLED BY:PURPOSE:DESIGNER/DATE(s): LEVEL 1

PARAMETERS:(names,modes,attributes,purpose)INPUT ASSERTION: ( preconditions)OUTPUT ASSERTION:(post conditions)GLOBALS:( name, modes,attributes, purposes, shared with)SIDE EFFECTS: LEVEL 2

Procedure TemplatesLOCAL STRUCTURES: (names, attributes,purposes)EXCEPTIONS: (conditions, responses)TIMING CONSTRAINTS:OTHER LIMITATIONS: LEVEL 3

PROCEDURE BODY: (pseudocode, structured English, structure flow chart, decision table) LEVEL 4

Pseudocode

• Used in both the architectural and detailed design phases.

• Using pseudocode the designer describes the system characteristics using short, concise, English language phrases that are structured by keywords such as IF-THEN-ELSE, While-DO, and End. Key words and indentation describes the flow of control while English phrases describes the processing actions.

Pseudocode

• Using the top-down design strategy \, each English phrase is expanded into more detailed pseudocode until the design specification reaches the level of detailed implementation language.

• E.g. Initialize tables and counters;Open file Read the first text record

Structure Flow Charts• Traditionally used for specifying and documenting

algorithmic details in a software system.

• Flowcharts incorporate rectangular boxes for actions, diamond shape boxes for decisions, directed arcs for specifying interconnections between boxes and a variety of symbols for representing input and output.

• Unlike flow chart structure charts are restricted to composition of certain basic terms.

• The basic forms are characterized by single entry into and single exit from the form.

• Structure flowchart are logically equivalent to pseudo code. They have same expressive power as pseudo code.

• Structured flow chart are preferred in situations where clarity of control flow is to be emphasized.

Structured Flow ChartsS1

S2

P

S

S

P

P

S1 S2

IF P THEN S1 ELSE S2

REPEAT S UNTIL P

WHILE P DO S

Structured English

Structured English can be used to provide a step-by-step specification for an algorithm. Structured English can be used at any desired level of detail. Structured English is often used to specify cookbook recipes.1.Preheat Oven to 350 degree F.2.MIX eggs,milk, and vanilla.3.Add flour and baking soda.4.Pour into a greased baking dish5.Cook until done.

Decision Tables

Decision tables can be used to specify complex design logic in a high level software specification. They are useful for specifying algorithm logic during detailed design.

Module-Level Concepts

• Now we will consider some concepts specific to function oriented design.

• A module is a logically separable part of a program.

• In a system using functional abstraction, coupling and cohesion are two modularization criteria, which are often used together.

Cohesion

• Cohesion of a module represent how tightly bound the internal elements of the module are to one another.

• We are interested in determining how closely the elements of module are related to one another.

• The greater the cohesion of each module in the system, the lower the coupling between module is.

Cohesion• A measure of how well a component 'fits

together'• A component should implement a single logical

entity or function• Cohesion is a desirable design component

attribute as when a change has to be made, it is localised in a single cohesive component

• Various levels of cohesion have been identified

Cohesion levels• Coincidental cohesion (weak)

– Parts of a component are simply bundled together• Logical association (weak)

– Components which perform similar functions are grouped

– For example:output text to screenoutput line to printeroutput record to file

– Seems ok – Problem is it carries out a range of similar but

different actions – No single well defined action

Cohesion levels

• Temporal cohesion (weak)– Components which are activated at the same time are

grouped– For example:

clear screenopen fileInitialise total

– again not related – solution is to make initialisation module all other

specialised modules: call init_terminal call init_files call init_calculations

Cohesion levels

• Procedural cohesion (weak)– The elements in a component make up a single control

sequence• Communicational cohesion (medium)

– All the elements of a component operate on the same data

– e.g. display and log temperature • Sequential cohesion (medium)

– The output for one part of a component is the input to another part

Cohesion levels

• Functional cohesion (strong)– optimal type of cohesion – performs a single well-defined action on a single

data object – e.g. calculate average – Each part of a component is necessary for the

execution of a single function• Object cohesion (strong)

– Each operation provides functionality which allows object attributes to be modified or inspected

Cohesion as a design attribute• Not well-defined. Often difficult to classify

cohesion• Inheriting attributes from super-classes

weakens cohesion• To understand a component, the super-classes

as well as the component class must be examined

• Object class browsers assist with this process

Coupling• A measure of the strength of the inter-connections

between system components• Loose coupling means component changes are

unlikely to affect other components• Shared variables or control information

exchange lead to tight coupling• Loose coupling can be achieved by state

decentralisation (as in objects) and component communication via parameters or message passing

Tight coupling

Module A Module B

Module C Module D

Shared dataarea

Loose couplingModule A

A’s data

Module B

B’s data

Module D

D’s data

Module C

C’s data

Coupling levels

• Altering another modules code (LISP, Assembler) • Modifying data within another module

– fault that appears in one module may be due to another

– complicated understanding and debugging – can be done via global variables or pointers or call be

reference in C++ / Java• Shared or global data

Coupling levels

• Procedure call with a parameter that is a switch (or a function pointer in C) – io (command, device buffer, length); – where command is 0,1,2 for read, write open; better to

use – read( device, buffer, length);

• Procedure call with parameters that are pure data – ideal is call by value, where a small number of

parameters are used and a copy of the data is passed to the procedure invoked

– clear what information is being communicated

Coupling levels

• Passing a serial data stream – most ideal situation– one module passes stream of data to another– once passed data is outside control of process/module– like piping in UNIX– data can be thought of as a temporary intermediate file– only possible in languages that support concurrency such

as Ada and Erlang and Parallel C

Coupling and inheritance• Object-oriented systems are loosely

coupled because there is no shared state and objects communicate using message passing

• However, an object class is coupled to its super-classes. Changes made to the attributes or operations in a super-class propagate to all sub-classes. Such changes must be carefully controlled

DESIGN TECHNIQUES

Several techniques have been developed for software design. These are

• Step-Wise Refinement• Levels of abstraction • Structured Design• Integrated top down development• Jackson Design method

Step-Wise Refinement

Step-wise refinement is a top-down technique for decomposing a system from high-level specifications into more elementary levels. This is also called as “stepwise program development” and “successive refinement”. It involves following activities:

• Decomposing design decision to elementary levels.• Isolating design aspects that are not truly

interdependent.

• Postponing decisions concerning representation details as long as possible.

• Carefully demonstrating that each successive step in the refinement process is faithful expansion of previous steps.

Benefits of step-wise refinement

• Top-down decomposition• incremental addition of details• Postponement of design decisions• Continual verification of consistency

Integrated Top-Down Development

• Integrated top-down development integrates design, implementation, and testing.

• Design proceeds top-down from the highest level routine.

• They have the primary function function of coordinating and sequencing lower-level routines.

• Lower-level routines can not access the high-level routines.

STRATEGY: DESIGN MAINCODE MAINSTUBS FOR GET, PROCESS, PUTTEST GETDESIGN GETCODE GETTEST MAIN GETDESIGN PROCESSCODE PROCESSSTUBS FOR SUB1, SUB2TEST MAIN GET PROCESSDESIGN PUTCODE PUT TEST MAIN, GET, PROCESS, PUTDESIGN SUB1CODE SUB1 TEST MAIN, GET, PROCESS, PUT,SUB1DESIGN SUB2CODE SUB2 TEST MAIN GET, PROCESS, PUT,SUB1,SUB2

MAIN

GET PROCESS PUT

SUB1 SUB2

Advantages

• This technique provide orderly and systematic framework for software development.

• Design and coding are integrated.• Test cases are developed systematically and

each routine is tested in actual operating environment.

Disadvantages

• Early high level design decisions may have to be reconsidered when the design progresses to lower levels

• System may be very expensive test harness for newly added procedures

Jackson Structured Programming

This a systematic technique for mapping the structure of problem into a program structure to solve the problem.

• The problem is modeled by specifying the input and output data structure using tree structured diagrams.

• The input-output model is converted into a structural model for the program identifying points of correspondence between nodes in the input and output trees.

• The structural model of the program is expanded into a detailed design that contains the operations needed to solve the problem.

Input and output data is specified using a graphical notation to specify data hierarchy, sequence of data, repetition of data items, and alternate data items.

A

B C D

E o F 0

G * H I

Specification of object A using Jackson Structured Programming notation

O selection

* Zero or more occurrences

• The second step of Jackson method involves converting the input and output structures into a structural model of the program.

• The third step expands the structural model of the program into a detailed design model

a) A list of operations required to perform the processing steps is developed.

b) the operations are associated with the program structure

c) Program structure and operations are expressed in a notation called schematic logic, which is stylized pseudocode. Control flow for selection and iteration are specified in this step.

Input and output structure of an inventory program

INPUT FILE

Part Group*

Movement * record

Issue o Receipt o

Output Report

heading Body

NET *MOVEMENT

TIME

Correspondence between Input and output structure of an inventory program

INPUT FILE

Part Group*

Movement * record

Issue o Receipt o

Output Report

heading Body

NET *MOVEMENT

TIME

Program Structure for an inventory problem

Program

Process heading

Process Body

Process PTGP * and line

Process PTGP Body

Processline

Process Record *

Process Issue o Process Receipt o`

Operations needed in the inventory program

1. OPEN FILES2. CLOSE FILES3. STOP RUN4. READ A RECORD INTO PART_NUM,

MOVMNT5. WRITE HEADING6. WRITE NET_MOVEMENT LINE7. SET NET_MOVMNT TO ZERO8. ADD MOVMNT TO NET_MOVMNT

Association of operations wit Program Structure

Program

Process heading

Process Body

Process PTGP * and line

Process PTGP Body

Processline

Process Record *

Process Issue o Process Receipt o`

1 4 5 32

7 6

4

9 8