Design Concepts & Principles
Indu SharmaHOD(CSE)
CPTC,Rajsamand
Introduction The purpose of the design phase is to plan a
solution of the problem specified by the requirements documents.
It is a blueprint for the solution of a problem This phase is the first of three technical
activities-design, code generation, and test-that are required to build and verify the software.
The design of the system is perhaps the most critical factor affecting quality of the software, it has a major impact on the later phases, particularly testing and maintenance.
Introduction The design process for software systems
often has two levels.• Top-level design• Detailed design
At the first level the focus is on deciding which modules are needed for the system, the specifications of these modules, and how the modules should be interconnected.
In the second level, the internal design of the modules, or how the specifications of the module can be satisfied, is decided.
Fundamental Differences between Design and Analysis1. The problem analysis, we construct a
model of the problem domain, while in design we construct a model for the solution domain.
2. In design, the system depends on the model, while in problem analysis the model depends on the system.
3. The basic aim of the modeling in problem analysis is to understand, while the basic aim of modeling in design is to optimize (in our case, simplicity and performance).
Implement all explicit and implicit requirements
Be a readable and understandable guide for developers and customers
Provide a complete picture of software
A Good Design
Design Principles A good designer should consider
alternative approaches.• Each alternative should be judged with
respect to stated requirements.• Each alternative should be judged with
respect to resources required for the solution and resources available to do the job.
• Each alternative should be judged with respect to the design concepts (eg. Modularity, information hiding etc.)
A good design is traceable to the Analysis Model and to Software Requirements.
Design Principles A good designer will not “re-invent the
wheel”• If a good design exists and can be reused from
some other source, then do not re-design the solution. Time and money are always in short supply. A good software engineer will always look for a ready-made solution before developing a new one.
A good design should minimize “intellectual distance” between the software and the real world problem it is designed to solve.
• This is one of the most important benefits of the object-oriented approach to design.
Design Principles The design should exhibit uniformity and
integration.• It should appear as if “one person”
developed the entire system. There should be a well-defined set of coherent principles and rationale that guide design decisions throughout the system development. The description of the system uniformly should follow certain defined standards for style, format, and organization everywhere they could apply.
• Interfaces between components should be documented completely and clearly using a consistent style and presentation format.
Design Principles The design should be structured to
accommodate change.• Again, the object-oriented approach tends to
yield designs that satisfy this principle. Design should be structured to degrade
gently.• It should terminate gracefully and not bomb
suddenly. Design and coding are not
interchangeable.
Design Principles Design should have quality assessment
during creation, not afterwards• This is to reduce development time
A design should be reviewed to minimize conceptual (semantic) errors.
• Focus on omissions, ambiguity, and inconsistency before worrying about the syntax of the design model.
Relation of Analysis to Design
The 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 program
Procedural Design
Interface Design
Architectural Design
Data Design
The Design Model
Which is mapped from the Analysis model
The Design Model Interface Design
Describes how the software communicates with itself, to systems that interact with it and with humans.
Procedural Design Transforms structural
elements of the architecture into a procedural description of software construction
Procedural Design
Interface Design
Architectural Design
Data Design
The Design Model
Which is mapped from the Analysis model
Fundamental Concepts
Abstraction — data, procedure, control Refinement — elaboration of detail for
abstractions Modularity — compartmentalize data and function Architecture — overall structure of the software Partitioning — partition the program structure Data structure — the logical relationship of data Procedure — the algorithms that achieve function Hiding — controlled interfaces Function independences — cohesion, coupling
Abstraction Each step in the software process is
a refinement in the level of abstraction of the software solution.
Data Abstraction A data abstraction is a named
collection of data object. Eg. Classes and interfaces in JAVA.
Data Abstractiondoor
implemented as a data structure
manufacturermodel numbertypeswing directionweight
opening mechanism
AbstractionProcedural Abstraction:
A procedural abstraction is a named sequence of instructions that has a specific and limited function.
This allows the designer to reason in terms of inputs and results of the named computation without having to think about the details of how the computation will be accomplished or implemented.
Procedural Abstractionopen
details of enter algorithm
Walk to the door, reach out and grasp knob, turn know and pull the door, step away from moving door etc.
Abstraction Control Mechanism
Third form of abstraction used in software design.
It implies a control mechanism without specifying internal details.
Eg. Semaphore in OS, Concurrency control in databases etc.
Refinement Stepwise refinement is a top down strategy. Refinement is a process of elaboration. We begin
with a statement of function that is defined at a high level of abstraction. Refinement causes the designer to elaborate on the original statement, providing more and more detail as each successive refinement occurs.
Abstraction and refinement are complementary concepts. Abstraction enables a designer to specify procedure and data yet suppress low-level details. Refinement helps the designer to reveal low-level details as designer progresses. Both concepts aid the designer in creating a complete design model as the design evolves.
Refinement
open
walk to door;reach for knob;
open door;
walk through;close door.
repeat until door opensturn knob clockwise;if knob doesn't turn, then take key out; find correct key; insert in lock;endifpull/push doormove out of way;end repeat
Modularity Software is divided into separately named
and addressable components, often called modules, that are integrated to satisfy problem requirements.
Monolithic software (i.e. a large program composed of a single module) can’t be easily grasped by a reader. The number of control paths, span of references, number of variables and overall complexity would make understanding close to impossible.
Modularity Let C(x) ->perceived complexity of
a problem x.E(x) -> Effort (in time) required to solve a problem x.p1 and p2 are two problems
If C(p1) > C(p2) ---(i-a)it follows that
E(p1) > E(p2) ---(i-b)
Modularity Another interesting characteristics that has
been uncovered through experimentation in human problem solving. That is,C(p1+p2) > C(p1) + C(p2) ---(ii)Now from Equation (i-b)E(p1+p2) > E(p1) + E(p2) ---(iii)
This leads to a divide and conquer strategy-it is easier to solve a complex problem when you break it into manageable pieces.
Modularity: Trade-offs
What is the "right" number of modules What is the "right" number of modules for a specific software design?for a specific software design?
optimal numberoptimal number of modulesof modules
cost ofcost of softwaresoftware
number of modulesnumber of modules
modulemoduleintegrationintegration
costcost
module development cost module development cost
Modularity Under-modularity and over-modularity
should be avoided. Another important question arises when
modularity is considered. How do we define an appropriate module of a
given size? The answer lies in the method(s) used to
define modules within a system. Meyer defines five criteria that enables us
to evaluate a design method with respect to its ability to define an effective modular system.
Modularity Objectives of modularity in a design method Modular Decomposability
Provide a systematic mechanism to decompose a problem into sub problems.
Modular Composability Enable reuse of existing components
Modular Understandability Can the module be understood as a stand
alone unit (without reference to other modules)? Then it is easier to understand and change.
Modularity Modular Continuity
If small changes to the system requirements result in changes to individual modules, rather than system-wide changes, the impact of the side effects is reduced .
Modular Protection If there is an error in the module, then
those errors are localized and not spread to other modules
Architecture ““The The overall structureoverall structure of the software and of the software and
the ways in which that structure provides the ways in which that structure provides conceptual integrity for a system.” conceptual integrity for a system.”
In simplest form, architecture is the In simplest form, architecture is the hierarchical structure of program hierarchical structure of program components (modules), the manner in components (modules), the manner in which these components interact and the which these components interact and the structure of data that are used by the structure of data that are used by the components.components.
Architecture
superordinate
subordinate
Structural Partitioning If the architectural style of a system is
hierarchical, the program structure can be partitioned both horizontally and vertically.
Horizontally Partitioning defines separate branches of the modular hierarchy for each major program function.
For eg. The simplest approach to horizontal partitioning defines three partitions – input, data transformation, and output.
Structure Partitioning Benefits: Horizontal Partitioning
Easier to test Easier to maintain Propagation of fewer side effects Easier to add new features
F1 (Ex: Input) F2 (Process) F3(Output)
Structure Partitioning Vertical partitioning, often called factoring,
suggests that control (decision making) and work should be distributed top-down in the program structure.
Top-level modules should perform control functions and do little actual processing work. Modules that reside low in the structure should be the worker, performing all input, computation, and output tasks.
Structure Partitioning
Benefits: Vertical Partitioning Less susceptible to side effects Also very maintainable
Fan-out (span of control): Fan-out is a measure of the number of
modules that are controlled by another module.
objective: ”boss” modules should control a reasonable number of workers;
guideline: number of modules controlled by a “boss” < 7
(3)
Fan-in Fan-in indicates how many modules directly
control a given module. objective: maximize fan-in, create generalized
modules guideline: modules must have strong or moderate
cohesion(4)
Data Structure It refers to the representation of the
logical relationship among individual elements of data.
Eg. Scalar items: integer Vector: array Space: structure Linked lists Trees Stacks etc.
Software Procedure Software Procedure focuses on the
processing details of each module individually.
It must provide a precise specification of processing, including sequence of events, exact decision points, repetitive operations, and even data organization.
There is a relationship between structure and procedure.
Software Procedure
Information Hiding The concept of modularity leads to a
fundamental question : How do we decompose a software solution to
obtain the best set of modules? The principle of information hiding
suggests that the modules should be specified and designed so that information (procedure and data) contained within a module is inaccessible to other modules that have no need for such information.
Information Hiding
modulemodulecontrolledcontrolledinterfaceinterface
"secret""secret"clientsclients
a specific design decisiona specific design decision
Hiding Hiding — controlled interfaces— controlled interfaces
Why Information Hiding? Leads to encapsulation — an
attribute of high quality design Reduces the likelihood of “side
effects”. Easy modifications during testing
and software maintenance. Emphasizes communication through
controlled interfaces Discourages the use of global data Results in higher quality software
Functional Independence The concept of functional independence is a
direct result of modularity, and the concepts of abstraction and information hiding.
Each module addresses a specific subfunction of requirements.
Independent modules are: Easier to maintain Easier to test Error propagation is reduced Reusable modules are possible Encourage parallel development
Functional Independence Functional independence is the key
to good design, and design is the key to software quality.
Independence is measured using two qualitative criteria: Cohesion and Coupling.
Coupling Coupling is a measure of the relative
interdependence among modules. Two modules with high coupling are strongly
interconnected and thus, dependent on each other. Two modules with low coupling are not dependent on one another.
Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.
In software design, we strive for lowest possible coupling.
Coupling: Degree of dependence among components
No dependencies Loosely coupled-some dependencies
Highly coupled-many dependencies
High coupling makes modifying parts of the system difficult, e.g., modifying a component affects all the components to which the component is connected.
Range of CouplingHigh Coupling
Loose
Low
Content
Common
External
Control
Stamp
Data
Uncoupled
Data coupling Modules communicate
by parameters Each parameter is an
elementary piece of data Each parameter is
necessary to the communication
Nothing extra is needed
ProcessResults
CalculateGrade
mark grade
Data coupling No Tramp Data. Too many parameters - makes the
interface difficult to understand and possible error to occur.
Stamp coupling A composite data
(complete data structure) is passed between modules
Internal structure contains data not used
Stamp Typically involves tramp data.
ProcessResults
UpdateGrade
record updated record
Control coupling Communication by a
passing of control information. Eg. flags
A module controls the logic of another module through the parameter
Controlling module needs to know how the other module works - not flexible!
Checkrecord
Displayerror
Error code
External Coupling When modules are tied to an
environment external to software. For eg. I/O couples module to
specific devices, format, and communication protocols.
Common Coupling Shared data between modules. Global data Making a change to the common
data means tracing back to all the modules which access that data to evaluate the effect of change.
Common Coupling
Common Coupling
Content coupling A module refers to the
inside of another module Branch into another module Control is passed from one
module to the middle of another.
Refers to data within another module.
Content Coupling
Content Coupling
Cohesion A cohesive module performs a single task
within a software procedure, requiring a little interaction with procedures being performed in other parts of a program.
The degree to which a module performs one and only one function.
We aim for strongly cohesive modules Strong cohesion will reduce relations
between modules - minimize coupling
Range of CohesionHigh Cohesion (Best)
Low (Worst)
Functional
Sequential
Communicational
Procedural
Temporal
Logical
Coincidental
Functional Cohesion Strongest cohesion All elements contribute to the execution of
one and only one problem-related task Focussed - strong, single-minded purpose No elements doing unrelated activities Examples of functional cohesive modules:
Compute cosine of angle Read transaction record Assign seat to airline passenger
Functional Cohesion
Function A part 1
Function A part 2
Function A part 3
FunctionalSequential with complete, related functions
Sequential Cohesion The output of one component is
the input to another.Function A
Function B
Function C
SequentialOutput of one is input to another
Example of Sequential Cohesionmodule format and cross-validate
record use raw record format raw record cross-validate fields in raw record return formatted cross-validated
recordend module
Communicational Cohesion The activities are related to each
other by the data that the modules uses.
Each instruction acts on the same input or output data.
Function A
Function B
Function C
CommunicationalAccess same data
Example of Communicational Cohesion
module determine customer details use customer account no find customer name find customer loan balance return customer name, loan balanceend module
Procedural cohesion Elements are related only by sequence,
otherwise the activities are unrelated. In other words, the procedural cohesion
occurs in modules whose instructions although accomplish different tasks yet have been combined because there is specific order in which the task are to be completed.
Similar to sequential cohesion, except for the fact that elements are unrelated
Procedural Cohesion
Function A
Function B
Function C
ProceduralRelated by order of functions
Temporal cohesion Elements are involved in activities that are
related in time. The elements are grouped together
because they occur at about the same point in time.
Modules that perform activities like “initialization”, “clean up”, and “termination” are usually temporarily bound.
Temporal Cohesion
Time t0
Time t0 + X
Time t0 + 2X
TemporalRelated by time
Example of Temporal Cohesion
module initialise set counter to 0 open student file clear error message variable initialise arrayend module
Logical cohesion A module has logical cohesion if
there is some logical relationship between the elements of a module, and the elements perform functions that fill in the same logical class.
Usually have control coupling, since one of the activities will be selected
Example of Logical Cohesion
module display record use record-type, record if record-type is student then display student record else if record-type is staff then display staff recordend module
Logical Cohesion
Function A
Function A’
Function A’’
logic
LogicalSimilar functions
Coincidental cohesion Elements contribute to activities with no
meaningful relationship to one another Similar to logical cohesion, except the
activities may not even be the same type Mixture of activities. Difficult to understand and maintain, with
strong possibilities of causing ‘side effects’ every time the module is modified
Example of Coincidental Cohesion
module miscellaneous functions use customer record display customer record calculate total sales read transaction record return transaction recordend module
Function AFunction
BFunction
D
FunctionC
Function E
CoincidentalParts unrelated
Examples of CohesionFunction A
FunctionB
FunctionD
FunctionC
Function E
CoincidentalParts unrelated
Function A
Function A’
Function A’’
logic
LogicalSimilar functions
Time t0
Time t0 + X
Time t0 + 2X
TemporalRelated by time
Function A
Function B
Function C
ProceduralRelated by order of functions
Examples of Cohesion
Function A part 1
Function A part 2
Function A part 3
FunctionalSequential with complete, related functions
Function A
Function B
Function C
CommunicationalAccess same data
Function A
Function B
Function C
SequentialOutput of one is input to another
Determining Module Cohesion
Doing onefunction
only?
Activitiessame category?
Sequenceimportant?
Modulerelated
by?
Sequenceimportant?
Functional
Sequential
Communicational
Procedural Temporal
Logical
Coincidental
Yes
No
Data None
Control Flow
Yes
Yes
Yes
No
No
No
Design Heuristics for Effective Modularity Once program structure has been
developed, effective modularity can be achieved by manipulating the program structure according to the following set of rules:
1. Evaluate the “first iteration” of the program structure to reduce coupling and improve cohesion.
Design Heuristics Modules may be exploded or imploded
with an eye toward improving module independence.
2. Attempt to minimize structures with high fan-out; strive for fan-in as depth increases.
More reasonable distribution of control. A number of layers of control and highly
utilitarian modules at lower details.
Program Structure
Design Heuristics3. Keep scope of effect of a module
within the scope of control of that module.
The scope of control of module e is all modules that are subordinate and ultimately subordinate to module e.
If module e makes a decision that affects module r, we have a violation of this heuristic.
Design Heuristics4. Evaluate module interfaces to
reduce complexity and redundancy and improve consistency.
Module interfaces should be simple and should be consistent with the function of a module.
Interface inconsistency is an indication of low cohesion.
Design Heuristics5. Define modules whose function is
predictable, but avoid modules that are overly (excessively) restrictive.
A module is predictable when it can be treated as black box.
A module that arbitrarily restricts the size of a local data structure, options within control flow, or modes of external interface will invariably require maintenance to remove such restrictions.
Design Heuristics6. Strive for “controlled entry”
modules by avoiding “pathological connections.”
Warns against content coupling. Module interfaces are controlled. Pathological connection refers to
branches or references into middle of a module.
Software Design Methodologies The aim of design methodologies is to
provide guidelines to aid the designer during the design process.
A good design methodology is to organize the program in such a way that are easy to develop and later, to change.
The major software design methodologies are: Structured Design Methodology Object Oriented Design Methodology Real Time System Design Methodology
Structured Design Methodology (SDM) In SDM, the software is viewed as
transformation function that transforms the given inputs into the desired outputs.
The central objective is to properly designed this transformation function.
Due to this view of software, the SDM is primarily function oriented.
It is also called function oriented design methodology.
The concept of Program Structure, functional abstraction and functional decomposition lies at the heart of the structural design.
Structured Design Methodology (SDM) Design Notations
For a SDM, the design can be represented graphically or mathematically by the following:
DFDs Data Dictionaries Structure Charts Algorithms/Pseudcode etc.
Object Oriented Design Methodology Object oriented methodology reflects a natural view of the
world. OO Concepts:
Classes and Objects Data Abstraction & Encapsulation Polymorphism Inheritance Information Hiding
In and OO system, the basic module is a class. During design, the goal is to identify the modules that the
system should have, and their interfaces and relationships. In OOD, we are therefore identifying the classes that should exist in the software and the relationships between these classes.
UML(Unified Modeling Language): UML is a graphical notation for expressing object oriented designs
Top Related