Software

Design & Architecture

Lecture 4
Design Concepts

SESD-2222
Spring 2024
Design Concepts

Abstraction
Refinement
Modularity
Control Hierarchy
Software Architecture
Data Structure
Software Procedure
Information Hiding
 Structural Partitioning
 Functional Independence
 Structural Partitioning

 If the architectural style of a system is hierarchical program

structure can be partitioned -----it can be
 Horizontal partitioning
 Vertical partitioning
 Horizontal Partitioning
 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. Separate
branches can be defined for each major function
 Eg : 3 partitions
1. Input
2. Data Transformation
3. Output

Advantages
 Easier to test
 Easier to maintain
 Propagation of fewer side effects
 Easier to add new features
Example Horizontal Partitioning
Example Horizontal Partitioning
 Vertical Partitioning
 Control and work modules are distributed top down
 Top level modules perform control functions
 Lower modules perform computations (input processing and output)
Example Vertical Partitioning
Example Vertical Partitioning
 Functional Independence
 Functional independence is achieved by developing modules with “single
minded "function and an aversion to excessive interaction with other
modules.
 Measured using 2 qualitative criteria:
 Cohesion : Measure of the relative strength of a module.
 Coupling : Measure of the relative interdependence among modules.
 Cohesion
 Strength of relation of elements within a module
 Element- Group of instructions or a data definition.
 Strive for high cohesion
 There are different types of cohesion
1. Functional (Highest)
2. Sequential
3. Communicational
4. Procedural
5. Temporal
6. Logical
7. Coincidental (Lowest)
 Coincidental Cohesion (Lowest)

 A coincidentally cohesive module is one whose elements contribute to activities with no

meaningful relationship to one another.
 Eg. When a large program is modularized by arbitrarily segmenting the program into several
small modules.
 Logical Cohesion
 Parts of a module are related only by the logic structure of its code.
 E.g. A procedure that performs very different operations depending on the values of its parameters but they may
share some program structure and code statements.
 A logically cohesive module is one whose elements contribute to activities of the same general category in
which the activity or activities to be executed are selected from outside the module.
 A logically cohesive module contains a number of activities of the same general kind.
 To use the module, we pick out just the piece(s) we need.
 Temporal Cohesion
 A temporally cohesive module is one whose elements are involved in activities that are related in time or
represent different phases of executions:
 E.g. initialization, read input, compute, print output, cleanup.
 The module’s data and functions are related just because they are used at same time in an execution.
 A module INITIALIZE initializes many different functions in a mighty sweep, causing it to be broadly related to
several other modules in the system.
 Procedural Cohesion
 Sometimes functions must be performed in a certain order, functions are grouped together in a
module to encapsulate the order of their execution.
 E.g. data must be entered before they can be checked and then manipulated.
 A procedurally cohesive module is one whose elements are involved in different and possibly
unrelated activities in which control flows from each activity to the next. A piece of coding ties
the activities together.
 Appears cohesive only in the context of its use.
 Eg: Module that averages two completely unrelated tables, TABLE-A and TABLE-B, which both
just happen to have 100 elements each.
 Communicational Cohesion
 Association of certain functions because they operate on the same dataset.
 E.g. unrelated data fetched together because its collected from same input sensor.
 A communicationally cohesive module is one whose elements contribute to activities that use the same
input or output data.
 Suppose we wish to find out some facts about a book. For instance, we may wish to
 FIND TITLE OF BOOK
 FIND PRICE OF BOOK
 FIND PUBLISHER OF BOOK
 FIND AUTHOR OF BOOK
 These four activities are related because they all work on the same input data, the book, which makes
the “module” communicationally cohesive.
 The cure for communicational cohesion is placing each data element in its own module.
 Communicational Cohesion

 Eg: module which produces employee salary report and calculates average
salary
 Sequential Cohesion

 A sequentially cohesive module is one whose elements are involved in activities such that
output data from one activity serves as input data to the next.
 Eg: Module read and validate customer record
 Read record
 Validate customer record
 Here output of one activity is input to the second
 Functional Cohesion

 The ideal cohesion; which holds two conditions:

1. All elements essentials to a single function are contained in one module.
2. All of that module’s elements are essential to the performance of that function.
 Functionally cohesive module contains elements that all contribute to the execution of one
and only one problem-related task.
 Performs only the function for which it is designed, and nothing else.
 Put data, actions, or objects together only when they have one common sensible purpose.
 Examples of functionally cohesive modules are
 Compute cosine of an angle
 Calculate net employee salary
Decision Tree for Module Cohesion
 Coupling

 Measure of interconnection among modules in a software structure

 Two unrelated features may interact in such a way that one feature disables the possible
execution of other feature;
 E.g. an authorization feature that prohibits an unauthorized user from accessing protected
services.
 Strive for lowest coupling but not for complete independence.
 Types of coupling includes
1. Data Coupling
2. Stamp Coupling
3. Control Coupling
4. Common Coupling
5. Content Coupling
 Content Coupling (Least Desirable)

 Two modules are said to be content coupled if one module branches into another module
or modifies data within another.
 The modified module is completely dependent on the modifying one.
 Eg:
 Common Coupling
 Takes place when a number of modules access a data item in a global data area.
 Making a change to the common data means that, to evaluate the effect of change, we have to look
at all modules that access those data.
 Difficult to determine which module is responsible for changing data.
 In the figure below, Modules c, g and k exhibit common coupling.
 Control Coupling
 Two modules are said to be control coupled if one module passes a control element to the other
module.
 One module passes parameters or a return code to control the behavior of another module.
 It is impossible for the controlled module to function without some direction from the controlling
module.
 This control element affects /controls the internal logic of the called module
 Eg: flags
 Stamp Coupling

 Two modules are said to be stamp coupled if a data structure is passed as

parameter but the called module operates on some but not all of the
individual components of the data structure.
 It represents a more complex interface between modules, because the
modules have to agree on the data’s format and organization.
 Data Coupling (Most Desirable)

 Two modules are data coupled, if they communicate through parameters

where each parameter is an elementary piece of data.
 Only data values are passed, not structured data.
 e.g. an integer, a float, a character, etc.
 It is simpler and less likely to be affected by changes in data
representation.
 This data item should be problem related and not be used for control
purpose.
 Design Heuristics for Effective Modularity

 Evaluate 1st iteration to reduce coupling & improve cohesion

 Minimize structures with high fan-out
 Keep scope of effect of a module within scope of control of that module.
 Evaluate interfaces to reduce complexity
 Define modules with predictable function: A module is predictable when it can be treated
as a black box.
 Strive for controlled entry -- no jumps into the middle of things.
Design Heuristics for Effective Modularity
 References

 Selected Topics from CHAPTER 8 of the Book (Software Engineering. A practitioner’s Approach, by
Roger .r . Pressman)
 Topic Modularity from CHAPTER 6 of the Book (Software Engineering, Theory and Practice by Shari
Lawrence Pleeger)