Download - Design final
![Page 1: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/1.jpg)
Design Concepts & Principles
Indu SharmaHOD(CSE)
CPTC,Rajsamand
![Page 2: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/2.jpg)
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.
![Page 3: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/3.jpg)
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.
![Page 4: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/4.jpg)
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).
![Page 5: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/5.jpg)
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
![Page 6: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/6.jpg)
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.
![Page 7: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/7.jpg)
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.
![Page 8: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/8.jpg)
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.
![Page 9: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/9.jpg)
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.
![Page 10: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/10.jpg)
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.
![Page 11: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/11.jpg)
Relation of Analysis to Design
![Page 12: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/12.jpg)
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
![Page 13: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/13.jpg)
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
![Page 14: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/14.jpg)
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
![Page 15: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/15.jpg)
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.
![Page 16: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/16.jpg)
Data Abstractiondoor
implemented as a data structure
manufacturermodel numbertypeswing directionweight
opening mechanism
![Page 17: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/17.jpg)
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.
![Page 18: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/18.jpg)
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.
![Page 19: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/19.jpg)
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.
![Page 20: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/20.jpg)
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.
![Page 21: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/21.jpg)
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
![Page 22: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/22.jpg)
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.
![Page 23: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/23.jpg)
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)
![Page 24: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/24.jpg)
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.
![Page 25: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/25.jpg)
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
![Page 26: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/26.jpg)
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.
![Page 27: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/27.jpg)
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.
![Page 28: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/28.jpg)
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
![Page 29: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/29.jpg)
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.
![Page 30: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/30.jpg)
Architecture
superordinate
subordinate
![Page 31: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/31.jpg)
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.
![Page 32: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/32.jpg)
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)
![Page 33: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/33.jpg)
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.
![Page 34: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/34.jpg)
Structure Partitioning
Benefits: Vertical Partitioning Less susceptible to side effects Also very maintainable
![Page 35: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/35.jpg)
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)
![Page 36: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/36.jpg)
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)
![Page 37: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/37.jpg)
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.
![Page 38: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/38.jpg)
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.
![Page 39: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/39.jpg)
Software Procedure
![Page 40: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/40.jpg)
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.
![Page 41: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/41.jpg)
Information Hiding
modulemodulecontrolledcontrolledinterfaceinterface
"secret""secret"clientsclients
a specific design decisiona specific design decision
Hiding Hiding — controlled interfaces— controlled interfaces
![Page 42: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/42.jpg)
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
![Page 43: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/43.jpg)
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
![Page 44: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/44.jpg)
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.
![Page 45: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/45.jpg)
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.
![Page 46: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/46.jpg)
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.
![Page 47: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/47.jpg)
Range of CouplingHigh Coupling
Loose
Low
Content
Common
External
Control
Stamp
Data
Uncoupled
![Page 48: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/48.jpg)
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
![Page 49: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/49.jpg)
Data coupling No Tramp Data. Too many parameters - makes the
interface difficult to understand and possible error to occur.
![Page 50: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/50.jpg)
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
![Page 51: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/51.jpg)
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
![Page 52: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/52.jpg)
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.
![Page 53: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/53.jpg)
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.
![Page 54: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/54.jpg)
Common Coupling
Common Coupling
![Page 55: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/55.jpg)
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.
![Page 56: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/56.jpg)
Content Coupling
Content Coupling
![Page 57: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/57.jpg)
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
![Page 58: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/58.jpg)
Range of CohesionHigh Cohesion (Best)
Low (Worst)
Functional
Sequential
Communicational
Procedural
Temporal
Logical
Coincidental
![Page 59: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/59.jpg)
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
![Page 60: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/60.jpg)
Functional Cohesion
Function A part 1
Function A part 2
Function A part 3
FunctionalSequential with complete, related functions
![Page 61: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/61.jpg)
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
![Page 62: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/62.jpg)
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
![Page 63: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/63.jpg)
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
![Page 64: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/64.jpg)
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
![Page 65: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/65.jpg)
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
![Page 66: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/66.jpg)
Procedural Cohesion
Function A
Function B
Function C
ProceduralRelated by order of functions
![Page 67: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/67.jpg)
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.
![Page 68: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/68.jpg)
Temporal Cohesion
Time t0
Time t0 + X
Time t0 + 2X
TemporalRelated by time
![Page 69: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/69.jpg)
Example of Temporal Cohesion
module initialise set counter to 0 open student file clear error message variable initialise arrayend module
![Page 70: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/70.jpg)
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
![Page 71: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/71.jpg)
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
![Page 72: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/72.jpg)
Logical Cohesion
Function A
Function A’
Function A’’
logic
LogicalSimilar functions
![Page 73: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/73.jpg)
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
![Page 74: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/74.jpg)
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
![Page 75: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/75.jpg)
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
![Page 76: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/76.jpg)
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
![Page 77: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/77.jpg)
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
![Page 78: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/78.jpg)
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.
![Page 79: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/79.jpg)
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.
![Page 80: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/80.jpg)
Program Structure
![Page 81: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/81.jpg)
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.
![Page 82: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/82.jpg)
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.
![Page 83: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/83.jpg)
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.
![Page 84: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/84.jpg)
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.
![Page 85: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/85.jpg)
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
![Page 86: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/86.jpg)
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.
![Page 87: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/87.jpg)
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.
![Page 88: Design final](https://reader035.vdocument.in/reader035/viewer/2022070510/58a6e9aa1a28abcf0e8b4f17/html5/thumbnails/88.jpg)
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