Function Oriented System
Design
Software Design
• Deriving a solution which satisfies software
requirements.
• The activities carried out during the design
phase called as design process, transform the
SRS document into the design document.
Stages of Design
• Problem understanding
• Look at the problem from different angles to discover the design requirements.
• Identify one or more solutions
• Evaluate possible solutions and choose the most appropriate depending on the
designer's experience and available resources.
• Describe solution abstractions
• Use graphical, formal or other descriptive notations to describe the components
of the design.
• Repeat process for each identified abstraction until the design is
expressed in primitive terms.
The Design Process
• Any design may be modelled as a directed graph made up of
entities with attributes which participate in relationships.
• The system should be described at several different levels of
abstraction.
• Design takes place in overlapping stages. It is artificial to
separate it into distinct phases but some separation is usually
necessary.
Software design and its activities
Software design : Transforming the customer requirements, described
in the SRS document, into a form (a set of documents) that is suitable for
implementation in a programming language.
A good software design is seldom arrived by using a single step
procedure but rather through several iterations through a series of steps.
Design activities can be broadly classified into two important parts:
• Preliminary (or high-level) design
and
• Detailed design.
Preliminary (or high-level) design
• Through high-level design, a problem is decomposed into a set of modules.
• The control relationships among the modules are identified and the
interfaces among the various modules are identified.
• The outcome of high-level design is called program structure or software
architecture.
• Many different types of notations have been used to represent a high-level
design.
• High-level design is a crucial step in the overall design of a software.
• Once the high-level design is complete, detailed design is undertaken.
Detailed Design
During detailed design each module is examined carefully to design its data
structure and the algorithms.
The outcome of the detailed design stage is usually known as the module-
specification (MSPEC) document.
The data structure and the algorithms described using MSPEC, can be easily
grasped by programmers for initiating the coding.
From Analysis Model to
Design Model (continued)
Component-level Design
(Class-based model, Flow-oriented model
Behavioral model)
Interface Design
(Scenario-based model, Flow-oriented model
Behavioral model)
Architectural Design
(Class-based model, Flow-oriented model)
Data/Class Design
(Class-based model, Behavioral model)
Dimensions of the Design Model
High
Analysis model
Abstraction Dimension
Design model
Data/Class Architectural Interface Component-level Deployment-level
Low Elements Elements Elements Elements Elements
Process Dimension (Progression)
Difference between analysis and design
The aim of analysis is to understand the problem with a view to eliminate any
deficiencies in the requirement specification such as
incompleteness,
inconsistencies, etc.
The model which we are trying to build may be or may not be ready.
The aim of design is to produce a model that will provide a seamless transition
to the coding phase.
Once the requirements are analyzed and found to be satisfactory, a design
model is created which can be easily implemented.
Items developed during the software design phase
The following items must be designed during the 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.
Characteristics of a good software design
• The definition of “a good software design” can vary depending on the
application being designed.
Every good software design for general application must possess. The
characteristics are listed below:
• Correctness: A good design should correctly implement all the
functionalities identified in the SRS document.
• Understandability: A good design is easily understandable.
• Efficiency: It should be efficient.
• Maintainability: It should be easily amenable to change.
Features of a design document
In order to facilitate understandability, the design should have the following
features:
• It should use consistent and meaningful names for various design
components.
• The design should be modular. The term modularity means that it should
use a cleanly decomposed set of modules.
• It should neatly arrange the modules in a hierarchy, e.g. in a tree-like
diagram.
M1
Modularity & Layered Design
A designed solution is said to be highly modular, M2 M3 M4
• If the different modules in the solution have
M5
high cohesion and their inter-module coupling
are low A modular and hierarchical design
A layered design can make the design solution M1
easily understandable,
• Since to understand the working of a module, M2 M3 M4
one would at best have to understand how
the immediately lower layer modules work M5
without having to worry about the functioning
of the upper layer modules.
A design of poor modularity and hierarchy
Coupling and Cohesion
• When a software program is modularised, its tasks
are divided into several modules based on some
characteristics.
• As we know, modules are set of instructions put
togeather in order to achive some tasks.
• They are though, considered as single entity but
may refer to each other to work to geather.
• There are measures by which the quality of a
design of modules and their interaction among
them can be measured.
These measures are called coupling and cohesion.
Coupling and Cohesion
• COUPLING between two modules is a measure of the degree of
interaction (or interdependence) between the two modules.
• Whereas the COHESION is a measure of functional strength of a
module.
A module having high cohesion and low coupling is said to be functionally
independent of other modules.
i.e, A module performs a single task and needs very little interaction with
other modules.
Classification of Coupling
Different classes
of Coupling LOW
Data
Stamp
Control
Common
Content
HIGH
Data Coupling
n Def: Component passes data (not data structures) to another
component.
n Every argument is simple argument or data structure in which all
elements are used
n Good, if it can be achieved.
n Example: Customer billing system
¨The print routine takes the customer name, address, and billing
information as arguments.
Classification of cohesion
The different classes of cohesion that a module may
possess are;
Different classes of
Cohesion
LOW
Coincidental
Logical
Temporal
Procedural
Communicational
Sequential
Functional HIGH