Module IV
Analysis and Design
Analysis:
To understand the problem with a view to eliminate any deficiencies in the
requirement specification such as incompleteness, inconsistencies, etc
Design
produce a model that will provide a seamless transition to the coding phase
Software design
Deals with transforming the customer requirements, as described in the SRS document, into a
form (a set of documents) that is suitable for implementation in a programming language.
Design activities can be broadly classified into two important parts:
Preliminary (or high-level or Architectural) Design and
Detailed design
Preliminary or High-level design means
identification of different modules and
the control relationships among them and
the definition of the interfaces among these modules
Outcome of high-level design is called the program structure or software architecture.
Notations
Tree-like diagram called the structure chart to represent the control hierarchy in a
high-level design.
Detailed design,
the data structure and
The algorithms of the different modules are designed.
The outcome of the detailed design stage is usually known as the module-specification
document.
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
Items developed during the software design phase
Different modules required to implement the design solution.
Control relationship among the identified modules. The relationship is also known as the call
relationship or invocation relationship among modules.
Interface among different modules. The interface among different modules identifies the
exact data items exchanged among the modules.
Data structures of the individual modules.
Algorithms required to implement each individual module
Objectives of Software Design
Design for Change
Way to design software that can be modified easily as requirements changes.
Care from initial stages
Not only concentrate on what is presently needed but also consider the expected or
possible evolution of the system.
Previous experience of software engineer & Deep understanding of the
problem domain by the end user.
Importance:
A minor mistake in the design based on current need.
Accommodating changes may clutter the design.
Changes
Algorithm
Data Representation
Underlying abstract machine
Peripheral devices
Social Environment
Due to development process
Product Family
View several end products as a family of products that share a single architecture that
is reused in different contexts, giving rise to different designs.
Every version constitutes an individual product
Set of versions constitutes a family
Designs a common architecture for all members of the family jointly.
E.g. DBMS runs on different machines (OS) for various configurations.
Avoids the cost of designing the common parts separately.
Function-Oriented Design
A system is viewed as something that performs a set of functions. Starting at this high-level
view of the system, each function is successively refined into more detailed functions.
E.g. Create-new-library-member
assign-membership-number
create-member-record
print-bill
The system state is centralized and shared among different functions.
E.g. data such as member-records is available for reference and updating to several functions
such as:
create-new-member
delete-member
update-member-record
Object-oriented design
The system is viewed as collection of objects (i.e. entities). The state is decentralized among
the objects and each object manages its own state information.
E.g. in a Library Automation Software, each library member may be a separate object with its
own data and functions to operate on these data.
The functions defined for one object cannot refer or change data of other objects.
Objects have their own internal data which define their state.
Similar objects constitute a class. In other words, each object is a member of some
class.
Classes may inherit features from super class.
Conceptually, objects communicate by message passing.
Function-oriented vs. object-oriented design approach
In OOD, the basic abstraction are not real-world functions.
E.g. In OOD, an employee pay-roll software is not developed by designing functions
such as update-employee-record, get-employee-address, etc. but by designing objects
such as employees, departments, etc.
In OOD, state information is not represented in a centralized shared memory but is distributed
among the objects of the system.
E.g. While developing an employee pay-roll system, the employee data such as the
names of the employees, their code numbers, basic salaries, etc. are usually
implemented as global data in a traditional programming system; whereas in an
object-oriented system these data are distributed among different employee objects of
the system.
Function-oriented techniques group functions together if, as a group, they constitute a higher-
level function. On the other hand, object-oriented techniques group functions together on the
basis of the data they operate on.
It is not necessary an object-oriented design be implemented by using an object-oriented
language only.
They do not replace each other but complement each other in some sense.
Modularization Techniques
A systematic approach to the design of product families.
Aspects
Problem of defining the overall structure of the architecture in terms of relationships
among modules. (Architectural Design)
Design of each module, to which the principle of information hiding is applied.
(Detailed Design)
A progress in which the interplay between these two activities take place in a flexible way.
Textual or graphical notations are used
The Module Structure and its Representation
Module
A well defined component of a software system.
A provider of computational resources or services.
A collection of routines, data, type definitions, or a mixture of all.
Overall module structure and relations must be defined.
Use of identified module relations
By a Manager: to monitor the development of the system
As a guideline for assigning work to programmers according to their skill and
experience.
Mathematical relations
S = {M1,M2,,Mn}
A relation r on S is a subset of SxS
If two Modules Mi and Mj are in S and the pair <Mi, Mj> is in r by using the infix
notation Mi r Mj.
Relations are irreflexive i.e. Mi r Mi cannot hold for any module Mi in S.
Transitive Closure (r+)
Mi r+ Mj if and only if Mi r Mj (Direct) or there is an element Mk in S such
that Mi r Mk and Mk r Mj (Indirect).
E,g. CALL relation
Hierarchy
There are no two elements Mi, Mj such that Mi r+ Mj and Mj r+ Mi.
Graphical form
Directed Graph
nodes elements of
S
Directed arc
relation between
modules
Coupling
Measures the
interdependence of two
modules
Cohesion
Types of Relationships
USES
Mi USES Mj: - Mi requires the presence of Mj coz Mj provides the resources that Mi
needs to accomplish its task.
Mi is a client of Mj (Server)
Mi contains a call to a procedure contained in Mj
It should be a hierarchy
Traversing the USES structure, starting from the nodes that do not use any other nodes up to
the nodes that are not used by any other node gives a clear concern
A cycle represents a strong coupling between all the modules in the cycle.
Defines system through levels of abstraction.
A module at level i USES only modules at any level j such that i>j
Abstract Machine
At each level a module provides a set of services
Defined statically
Identification of pairs is independent of the execution of the s/w
Picture about Coupling
IS_COMPONENT_OF
A module that is composed of other modules that may themselves composed of other
modules and so on.
Mi IS_COMPONENT_ OF Mj
Mj is realized by aggregating several modules, one of them being
Mi
The inverse of IS_COMPONENT_OF relation is COMPRISES
Mi COMPRISES Mj iff: Mj IS_COMPONENT_ OF Mi.
Mi IS_COMPOSED_OF Ms,i or Ms,i IMPLEMENTS Mi
Iff Ms,i ={Mk|Mk is in S and Mk IS_COMPONENT_OF Mi}
The modules of Ms, i provides all the services that Mi should
provide.
Thus the system is decomposed into modules
Graphical Representation
IS_COMPONENT_OF COMPRISES
If Mi IS_COMPOSED_OF{Mi,1,
Mi,2,..Mi,n} then Mi is a higher level
module that any of {Mi,1, Mi,2,..Mi,n}
A module can be a component of more
than one module.
WhenHiding
Interface and Information Mi is a component of both Mj & Mk:-
Divide the s/w into components such that each component can be designed independently
(less Coupling).
Define the interaction among modules take place (nature of USES relation).
The set of services that each module provides to its clients is called its interface.
The services are exported by the module and imported by the clients.
Abstraction of the module as viewed by its clients.
The way these services are accomplished is embedded in its Implementation.
Implementation of a module is
its decomposition in terms of components (IS_COMPONENT_OF)
if the module is simple ,its representation in terms of code which possibly uses
services from other lower level modules
The designer should know only the interfaces to other modules not their implementation.
The interface can be viewed as a Contract between module M and its clients.
The interface describe computational resources
A variable that belong to a module and is made accessible to other modules to
provide a form of interaction
Procedure (Function) that must be called to have some operation performed.
Information Hiding
The clients of a module know about its services only through interface; the
implementation is hidden from them.
It should be defined precisely
what goes into the modules interface (visible to the clients) and
What remains hidden in the implementation and can be changed at any time
without affecting the clients.
Categories of Modules
Categorization of modules is a step towards the development of standard SE components.
Standard Categories:
Procedural Abstraction
Libraries
Common pool of data
General & Abstract Categories
Abstract Objects
Abstract data types
Procedural Abstraction
Traditional form of Modularization
Module provides just a procedure/function which implements some abstract operation
Used to encapsulate an algorithm
e.g. sorting module, fast Fourier transform module,
Libraries
A group of related procedural abstractions
e.g., libraries of mathematical routines
Implemented by routines of programming languages
Common pools of data
Data shared by different modules
Low level type of module
No abstraction
Details of data visible to all the clients
e.g., configuration constants
Static variable in C & Java
Abstract objects
Need to hide the details of data representations and shield clients from changes in them.
E.g. Symbol-table module
Only changes in access routines are required.
Looks like libraries
Have a permanent hidden, encapsulated data structure in their implementation part
which is visible to routines that are internal to the module
But is hidden from client modules
Exhibits a state
Values stored in a data structure changes from call to call
There is no difference in syntax of the interface of Abstract Object and library module. A
comment is used for AO.
E.g.,At each step, problem P decomposed into
sequence of sub-problems: P1; P2; Pn
a selection: if (cond.) then P1 else P2
an iteration: while (cond.) loop P1; end loop
Alternatively CASE statement also can be used.
Can expressed in terms of Natural Language like description
Each refinement step is represented by rewriting NL description in terms of sub-
problem statements glued with the control structure represented by the foregoing
patterns.
Design Process
Starts with an overall description of the problem
Recursively applies functional decomposition
Terminates at appoint where each sub-problem is easy to express in terms of a few
lines of code in the chosen programming language
Stepwise refinement process may be depicted by a decomposition tree (DT)
Root labeled by name of top problem
Sub problem nodes labeled as children of parent node corresponding to problem
Children from left to right represent sequential order of execution
Nodes representing alternative sub-problem are identified by a dotted line groups the
arc that connects the nodes to their parent node.
Arcs are labeled by the condition
Iteration is represented by a solid line, to which the condition governing the while
structure is labeled.
EXAMPLE
Step 1
P; P problem to solve
Step 2
P1; P2; P3; P decomposed into
sequence
CORRESPONDIN P
P P P
1 2 3
C
P
2,1
C not C
1 1
P P
2,1, 1 2,1, 2
Relation with IS_COMPOSED_OF
Let M, M1, M2, M3 be modules representing P, P1, P2, P3
We cannot write
M IS_COMPOSED_OF {M1,M2,M3}
We need to add a control module acting as glue to impose a sequential flow from M1
to M2 to M3
M IS_COMPOSED_OF {M1,M2,M3,M4}
IS_COMPOSED_OF relation does not correspond to a meaningful modularization.
Stepwise refinement describes the logical structure of an algorithm implemented by a
module than the decomposition of system into modules.
An assessment of stepwise refinement
Stepwise refinement is a programming technique, not a modularization technique
It fails to scale up to systems of even moderate complexity.
When used to decompose system into modules, it tends to analyze problems in isolation, not
recognizing commonalities
It does not stress information hiding
No attention is paid to data (it decomposes functionalities)
Assumes that a top function exists
But which one is it in the case of an operating system? Or a word processor?
Enforces premature commitment to control flow structures among modules
Top-Down vs. Bottom-Up
Top Down Design
Design proceed from Top to Bottom,
By recursively applying decomposition through IS_COMPOSED_OF
Until we break down the system into manageable components.
Stepwise refinement is an intrinsically top-down method.
Bottom Up Design
Proceed from Bottom to Top
Information hiding proceeds bottom-up
Starting from what to be encapsulated within a module,
Recursively defining an abstract interface,
Then grouping together several modules to form a new
Design is a highly critical and creative human activity
No actual design does not proceed in either a strictly top-down or strictly bottom-up fashion.
A typical design strategy may proceed partly from the top-down and partly from the bottom-
up depending up on
The phase of design
The nature of the application being designed.
E.g. a system is decomposed from top down in terms of subsystems and at some later
point, synthesize subsystem in terms of a hierarchy of information hiding modules.
The Top-Down approach is useful to document a design.
Even though the design is in a combined fashion the description of the resulting design is
recommended to describe in top-down fashion for better understandability (gives the big
picture before showing the supporting details).
Handling Anomalies
Any engineering product is prone to failure.
The designer must anticipate failures and plan to;
Either avoid
Or tolerate them
Known as Defensive Design
Shield the application from errors that may
Creep in during development or
That may arise due to adverse circumstances during program execution.
Should build Robust systems
A module is anomalous if it fails to provide the service as expected and as specified in its
interface
Design notations are extended with a set of exceptions with each service exported by the
module.
An exception MUST be raised when anomalous state is recognized
How can failures arise?
Module M should fail and raise an exception if
one of its clients does not satisfy the required protocol for invoking one of Ms
services
M does not satisfy the required protocol when using one of its servers, and the server
fails
hardware generated exception (e.g., division by zero)
What a module can do before failing
Before failing, modules may try to recover from the anomaly by executing some exception
handler (EH)
EH is a local piece of code that may try to recover from anomaly (if successful,
module does not fail)
or may simply do some cleanup of the modules state and then let the module fail,
signaling an exception to its client.
