Design Model

• The data design transforms the information domain model created

during analysis into the data structures that will be required to
implement the software. The data objects and relationships defined in
the entity relationship diagram and the detailed data content
depicted in the data dictionary provide the basis for the data design
activity.
• The architectural design rep resentation—the framework of a
computer-based system—can be derived from the system
specification, the analysis model, and the interaction of subsystems
defined within the analysis model.
Design model
• The interface design describes how the software communicates
within itself, with systems that interoperate with it, and with humans
who use it. An interface implies a flow of information (e.g., data
and/or control) and a specific type of behavior. There fore, data and
control flow diagrams provide much of the information required for
interface design.
• The component-level design transforms structural elements of the
software archi tecture into a procedural description of software
components. Information obtained from the PSPEC, CSPEC, and STD
serve as the basis for component design.
Characteristics are actually a goal of
the design process.
• 1. A design should exhibit an architectural structure that (1) has been
created using recognizable design patterns, (2) is composed of
components that exhibit good design characteristics (these are
discussed later in this chapter), and (3) can be implemented in an
evolutionary fashion, thereby facilitating implementation and testing.
• 2. A design should be modular; that is, the software should be
logically parti tioned into elements that perform specific functions
and subfunctions.
• 3. A design should contain distinct representations of data,
architecture, inter faces, and components (modules).
• 4. A design should lead to data structures that are appropriate for the
objects to be implemented and are drawn from recognizable data
patterns.
• 5. A design should lead to components that exhibit independent
functional characteristics.
• 6. A design should lead to interfaces that reduce the complexity of
connections between modules and with the external environment.
• 7. A design should be derived using a repeatable method that is
driven by information obtained during software requirements
analysis.
Coupling and Cohesion
• Coupling and Cohesion are two key concepts in software engineering
that are used to measure the quality of a software system's design.
Cohesion
• Cohesion refers to the degree to which elements within a module
work together to fulfill a single, well-defined purpose. High cohesion
means that elements are closely related and focused on a single
purpose, while low cohesion means that elements are loosely related
and serve multiple purposes.
Cohesion
• Cohesion is a natural extension of the information hiding concept
• Cohesion may be represented as a "spectrum.“
• We always strive for high cohesion, although the mid-range of the
spectrum is often acceptable. The scale for cohesion is nonlinear.
• That is, low-end cohesiveness is much "worse" than middle range,
which is nearly as "good" as high-end cohesion.
• the overall concept should be understood and low levels of cohesion
should be avoided when mod ules are designed.
Types of Cohesion
• Cohesion is a measure of the degree to which the elements of the
module are functionally related. It is the degree to which all elements
directed towards performing a single task are contained in the
component. Basically, cohesion is the internal glue that keeps the
module together. A good software design will have high cohesion.
• Functional Cohesion: Every essential element for a single computation is contained in the
component. A functional cohesion performs the task and functions. It is an ideal situation.
• Sequential Cohesion: An element outputs some data that becomes the input for other element,
i.e., data flow between the parts. It occurs naturally in functional programming languages.
• Communicational Cohesion: Two elements operate on the same input data or contribute
towards the same output data. Example- update record in the database and send it to the
printer.
• Procedural Cohesion: Elements of procedural cohesion ensure the order of execution. Actions
are still weakly connected and unlikely to be reusable. Ex- calculate student GPA, print student
record, calculate cumulative GPA, print cumulative GPA.
• Temporal Cohesion: The elements are related by their timing involved. A module connected
with temporal cohesion all the tasks must be executed in the same time span. This cohesion
contains the code for initializing all the parts of the system. Lots of different activities occur, all
at unit time.
• Logical Cohesion: The elements are logically related and not functionally. Ex- A component
reads inputs from tape, disk, and network. All the code for these functions is in the same
component. Operations are related, but the functions are significantly different.
• Coincidental Cohesion: The elements are not related(unrelated). The elements have no
conceptual relationship other than location in source code. It is accidental and the worst form
of cohesion. Ex- print next line and reverse the characters of a string in a single component.
• Procedural Cohesion: This type of cohesion occurs when elements or tasks are grouped
together in a module based on their sequence of execution, such as a module that performs a
set of related procedures in a specific order. Procedural cohesion can be found in structured
programming languages.
• Communicational Cohesion: Communicational cohesion occurs when elements or tasks are
grouped together in a module based on their interactions with each other, such as a module
that handles all interactions with a specific external system or module. This type of cohesion
can be found in object-oriented programming languages.
• Informational Cohesion: Informational cohesion occurs when elements or tasks are
grouped together in a module based on their relationship to a specific data structure
or object, such as a module that operates on a specific data type or object.
Informational cohesion is commonly used in object-oriented programming.
• Functional Cohesion: This type of cohesion occurs when all elements or tasks in a
module contribute to a single well-defined function or purpose, and there is little or
no coupling between the elements. Functional cohesion is considered the most
desirable type of cohesion as it leads to more maintainable and reusable code.
• Layer Cohesion: Layer cohesion occurs when elements or tasks in a module are
grouped together based on their level of abstraction or responsibility, such as a
module that handles only low-level hardware interactions or a module that handles
only high-level business logic. Layer cohesion is commonly used in large-scale
software systems to organize code into manageable layers.
Coupling
• Coupling is a measure of interconnection among modules in a
software structure
• Coupling depends on the interface complexity between modules, the
point at which entry or reference is made to a module, and what data
passes across the interface.
Types of Coupling
• 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

• Data coupling problems
• Too many parameters - makes the interface difficult to understand and possible error to occur

• Tramp data - data ‘traveling’ across modules before being used

Stamp coupling
A composite data is passed between modules

Internal structure contains data not used

Bundling - grouping of unrelated data into an artificial structure

Control coupling
A module controls the logic of another module through the parameter

Controlling module needs to know how the other module works - not flexible!
Hybrid coupling
A subset of data used as control

Example: account numbers 00001 to 99999

​
If 90000 - 90999, send mail to area code of last 3 digit (000 - 999)
Common coupling
Use of global data as communication between modules

Dangers of
ripple effect

inflexibility

difficult to understand the use of data

Content coupling
A module refers to the inside of another module

Branch into another module

Refers to data within another module

Changes the internal workings of another module

Mostly by low-level languages

Types of coupling
• Coupling is the measure of the degree of interdependence between the modules. A good
software will have low coupling.
• Data Coupling: If the dependency between the modules is based on the fact that they
communicate by passing only data, then the modules are said to be data coupled. In data
coupling, the components are independent of each other and communicate through data.
Module communications don't contain tramp data. Example-customer billing system.
• Stamp Coupling In stamp coupling, the complete data structure is passed from one
module to another module. Therefore, it involves tramp data. It may be necessary due to
efficiency factors- this choice was made by the insightful designer, not a lazy programmer.
• Control Coupling: If the modules communicate by passing control information, then they
are said to be control coupled. It can be bad if parameters indicate completely different
behavior and good if parameters allow factoring and reuse of functionality. Example- sort
function that takes comparison function as an argument.
• Content Coupling: In a content coupling, one module can modify the data of another module, or
control flow is passed from one module to the other module. This is the worst form of coupling and
should be avoided.
• Temporal Coupling: Temporal coupling occurs when two modules depend on the timing or order of
events, such as one module needing to execute before another. This type of coupling can result in
design issues and difficulties in testing and maintenance.
• Sequential Coupling: Sequential coupling occurs when the output of one module is used as the
input of another module, creating a chain or sequence of dependencies. This type of coupling can
be difficult to maintain and modify.
• Communicational Coupling: Communicational coupling occurs when two or more modules share a
common communication mechanism, such as a shared message queue or database. This type of
coupling can lead to performance issues and difficulty in debugging.
• Functional Coupling: Functional coupling occurs when two modules depend on each other's
functionality, such as one module calling a function from another module. This type of coupling can
result in tightly-coupled code that is difficult to modify and maintain.
• Data-Structured Coupling: Data-structured coupling occurs when two or more modules
share a common data structure, such as a database table or data file. This type of coupling
can lead to difficulty in maintaining the integrity of the data structure and can result in
performance issues.
• Interaction Coupling: Interaction coupling occurs due to the methods of a class invoking
methods of other classes. Like with functions, the worst form of coupling here is if
methods directly access internal parts of other methods. Coupling is lowest if methods
communicate directly through parameters.
• Component Coupling: Component coupling refers to the interaction between two classes
where a class has variables of the other class. Three clear situations exist as to how this
can happen. A class C can be component coupled with another class C1, if C has an
instance variable of type C1, or C has a method whose parameter is of type C1,or if C has a
method which has a local variable of type C1. It should be clear that whenever there is
component coupling, there is likely to be interaction coupling.
Benefits of high cohesion and low
coupling
High Cohesion
• Cohesion = how strongly the elements within a module/class belong together.
• High Cohesion → a module/class focuses on a single, well-defined task.
• Low Cohesion → a module does many unrelated things.
• Benefits of High Cohesion
• Improved Understandability – Easier to read, learn, and maintain.
• Reusability – Well-focused modules can be reused in different projects.
• Maintainability – Changes are localized to one module.
• Reduced Complexity – Each part of the system is simpler.
• Better Testability – Easier to test modules with single responsibilities.
• Low Coupling
• Coupling = degree of dependency between modules.
• Low Coupling → modules are independent, with minimal knowledge of each other.
• High Coupling → modules heavily depend on each other’s details.
• Benefits of Low Coupling
• Flexibility – Modules can change without breaking others.
• Reusability – Independent modules can be reused elsewhere.
• Scalability – Easy to add or remove features.
• Maintainability – Debugging and fixing issues is simpler.
• Parallel Development – Teams can work on different modules independently.
Refactoring, Reengineering,
Reverse Engineering
• Refactoring is the process of improving the internal structure of the
code without changing its external behavior.
• Reengineering is the process of analyzing and modifying an existing
software system to improve it (in performance, maintainability,
functionality, or technology) without changing its basic functionality.
• Reverse Engineering is the process of analyzing an existing software
system to extract design and specification information.
Difference
Aspect Refactoring Reverse Engineering Reengineering
Clean up code, improve Understand system (from Modernize & improve the
Goal
quality code → design) system
Yes (large-scale,
Changes to Code? Yes (small, incremental) No (only analysis)
restructuring)
Maintenance, migration,
Focus Internal structure of code Extract design/knowledge
quality improvement
Cleaner, maintainable Documentation, design
Output Improved/modern system
code models
During
When documentation is When system is outdated
When Used development/maintenanc
missing but still useful
e