Software

Design & Architecture

Lecture 3
Design Concepts

SESD-2222
Spring- 2024
Today’s Agenda

 Design Model
 Goals of a Design Process
 Translation of Analysis Model to Design Model
 Design Concepts
 Design Model
Components of a design model :
 Data Design
Transforms information domain model into data structures required to implement software
 Architectural Design
Defines relationship among the major structural elements of a software
 Interface Design
Describes how the software communicates with systems that interact with it and with humans.
 Procedural Design
Transforms structural elements of the architecture into a procedural description of software components
 Software Design
An iterative process transforming requirements into a “blueprint” for constructing the software.
Goals of the Design Process

 The design must implement all of the explicit requirements contained in the analysis
model and it must accommodate all of the implicit requirements desired by the
customer.
 The design must be a readable, understandable guide for those who generate code and
for those who test and subsequently support the software.
 The design should address the data, functional and behavioral domains from an
implementation perspective
Translating Analysis Model into a Software Design
Design Concepts

 Abstraction
 Refinement
 Modularity
 Control Hierarchy
 Software Architecture
 Data Structure
 Software Procedure
 Information Hiding
 Structural Partitioning
 Functional Independence
 Abstraction
 Wasserman: “Abstraction permits one to concentrate on a problem at some level of
abstraction without regard to low level detail.
 At the highest level of abstraction a solution is stated in broad terms using the language of
the problem environment.
 At lower level of abstraction, a more detailed description of the solution is provided.
 The solution stated in implementation-oriented terminology.
 At the lowest level of abstraction the solution is stated in a manner that can be directly
implemented.
 Types of abstraction

1. Procedural Abstraction :
 A named sequence of instructions that has a specific & limited function
 The name implies these functions but specific details are suppressed.
Example: Word OPEN for a door
 OPEN implies a long sequence of procedural steps( e.g. Walk to door, reach out and grasp knob,
turn knob, pull door……)

2. Data Abstraction :
 A named collection of data that describes a data object.
 Data abstraction for door would be a set of attributes that describes the door
Example: (door type, swing direction, weight, dimension)
Refinement
 Process of elaboration.
 Start with the statement of function defined at the abstract level, decompose the
statement of function in a stepwise fashion until programming language statements are
reached.
 Modularity
 In this concept, software is divided into separately named and addressable components called modules
 “Modularity is the single attribute of software that allows a program to be intellectually manageable”.
 Follows “divide and conquer” concept, a complex problem is broken down into several manageable pieces
 Let p1 and p2 be two problems.
 Let E1 and E2 be the effort required to solve them ----->
If C(p1)>C(p2)
Hence E(p1)>E(p2)
 Now------>
 Complexity of a problem that combines p1 and p2 is greater than complexity when each problem is
consider
C(p1+p2) > C(p1)+C(p2),
Hence E(p1+p2) > E(p1)+E(p2)
 It is easier to solve a complex problem when you break it into manageable pieces
Modularity and Software Cost
 Evaluation of Design Method w.r.t Modularity
Modular understandability
 module should be understandable as a standalone unit (no need to refer to other modules)
Modular continuity
 If small changes to the system requirements result in changes to individual modules, rather than
system wide changes, the impact of side effects will be minimized
Modular protection
 If an error occurs within a module then those errors are localized and not spread to other modules.
Modular Composability
 Design method should enable reuse of existing components.
Modular Decomposability
 Complexity of the overall problem can be reduced if the design method provides a systematic
mechanism to decompose a problem into sub problems
 Control Hierarchy
 Also called program structure
 Represent the organization of program components.
 Does not represent procedural aspects of software such as decisions, repetitions etc.
 Depth –No. of levels of control (distance between the top and bottom modules in program control
structure)
 Width- Span of control.
 Fan-out -no. of modules that are directly controlled by another module
 Fan-in - how many modules directly control a given module
 Super ordinate -module that control another module
 Subordinate - module controlled by another
 Visibility -set of program components that may be called or used as data by a given
component
 Connectivity – A module that directly causes another module to begin execution is
connected to it.
Control Hierarchy (Example)
 Software Architecture
 Software architecture is the hierarchical structure of program components (modules), the
manner in which these components interact and the structure of data that are used by the
components.
 A set of properties should be specified as part of an architectural design:
Structural properties: This aspect of the architectural design representation defines the
components of a system (e.g., modules, objects) and the manner in which those components
are packaged and interact with one another.
Extra-functional properties: The architectural design description should address how the
design architecture achieves requirements for performance, reliability, security, adaptability,
and other system characteristics.
Families of related systems: The design should have the ability to reuse architectural building
blocks.
 Data Structures and Software Procedures

 Data structure is a representation of the logical relationship among

individual elements of data.
 Scalar item –A single element of information that may be addressed by an
identifier .
 Scalar item organized as a list- array
 Data structure that organizes non-contiguous scalar items-linked list
 Software procedure focuses on the processing details of each module
individually.
 Information Hiding

 Information (data and procedure) contained within a module should be

inaccessible to other modules that have no need for such information.
 Hiding defines and enforces access constraints to both procedural detail
within a module and any local data structure used by the module.
 References
 Selected Topics from CHAPTER 8 of the Book (Software Engineering. A practitioner’s
Approach, by Roger .r . Pressman)