Software Design:

- Software design is a process to transform user requirements into some suitable form,
which helps the programmer in software coding and implementation.
- For assessing user requirements, an SRS (Software Requirement Specification)
document is created whereas for coding and implementation
- Software design is the first step in SDLC (Software Design Life Cycle), which moves the
concentration from problem domain to solution domain. It tries to specify how to fulfill
the requirements mentioned in SRS.

Software Design Levels

Software designs have three levels of results:

 Architectural Design - The architectural design is the highest abstract version of the
system. It identifies the software as a system with many components interacting with
each other. At this level, the designers get the idea of proposed solution domain.
 High-level Design- The high-level design breaks the ‘single entity-multiple component’
concept of architectural design into less-abstracted view of sub-systems and modules
and depicts their interaction with each other. High-level design focuses on how the
system along with all of its components can be implemented in forms of modules. It
recognizes modular structure of each sub-system and their relation and interaction
among each other.
 Detailed Design- Detailed design deals with the implementation part of what is seen as a
system and its sub-systems in the previous two designs. It is more detailed towards
modules and their implementations. It defines logical structure of each module an d their
interfaces to communicate with other modules.

Modularization

- Modularization is a technique to divide a software system into multiple discrete and

independent modules, which are expected to be capable of carrying out task(s)
independently.
- These modules may work as basic constructs for the entire software. Designers tend to
design modules such that they can be executed and/or compiled separately and
independently.
- Modular design unintentionally follows the rules of ‘divide and conquer’ problem-
solving strategy
Advantage of modularization:
  Smaller components are easier to maintain
 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect

Coupling:
Coupling is the measure of the degree of interdependence between the different
modules in a program. Good software will have low coupling. It represents how the sub
system can be connected with other sub system. It measures the interconnection
among subsystem (inter module) in a program structure.
Types of coupling:

1. Data Coupling: In data coupling, the components are independent to each other and
communicating through data. Example-customer billing system.
2. Stamp Coupling In stamp coupling, the complete data structure is passed from one
module to another module.
3. Control Coupling: the different modules communicating by passing control information,
so that one module controls the sequence of processing steps in another module.
 4. External Coupling: In external coupling, the modules depend on other modules, external
to the software being developed or to a particular type of hardware. Ex- protocol,
external file, device format, etc.
5. Common Coupling: The modules have shared data such as global data structures. The
changes in global data mean tracing back to all modules which access that data to
evaluate the effect of the change.
6. 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.
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.
Types of Cohesion:

1. 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.
2. Sequential Cohesion: An output on element becomes input for other element in a
module, i.e., data flow between the parts. It occurs naturally in functional programming
languages.
3. Communicational Cohesion: Two elements operate on the same input data or
contribute towards the same output data. Example- update record int the database and
send it to the printer.
4. 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.
 5. 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 init time.
6. Logical Cohesion: The elements are logically related and not functionally. For example
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.
7. 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.
Different between coupling and cohesion:

Cohesion Coupling
Cohesion is the indication of the relationship within the Coupling is the indication of the
module. relationships between modules.
Cohesion shows the module’s relative functional strength. Coupling shows relative independence
among the modules.
Cohesion is a degree (quality) to which a / module focuses Coupling is a degree to which a
on a single thing. component/module is connected to the
other modules.
While designing you should strive for high cohesion i.e. a While designing you should strive for low
cohesive component/ module focus on a single task (i.e., coupling i.e. dependency between
single-mindedness) with little interaction with other modules should be less.
modules of the system.
Cohesion is the kind of natural extension of data hiding, for Making private fields, private methods
example, the class having all members visible with a package and nonpublic classes provide loose
having default visibility. coupling.
Cohesion is Intra -Module Concept. Coupling is the Inter-Module Concept.

Information Hiding:

- Information hiding is a software design principle, where certain aspects of a program or

module (the “secrets”) are inaccessible to clients.
- The primary goal is to prevent extensive/broad modification to clients whenever the
implementation details of a module or program are changed.
- This way, if the implementation changes, the clients do not have to change.
 Applying Information Hiding
- The key challenge when applying information hiding is determining what information
should be hidden and what should be exposed.
- Using this heuristic, information hiding can be thought of as a three-step process:

1. Identify all of the pieces of a design that are likely to change or other design details that you
might want to hide
2. Isolate each secret into its own module, class, or function
3. Design intermediate interfaces that are insensitive to changes in the underlying secrets.

Functional Independencies:

Functional independence occurs where modules (such as a package or class) address a

specific and constrained range of functionality. The modules provide interfaces only to this
functionality. By constraining their functionality, the modules require the help of fewer other
modules to carry out their functionality.

The functional independence of a module can be judged using two

concepts: cohesion and coupling: cohesion is the degree to which a module performs only one
function. coupling is the degree to which a module requires other modules to perform its
function.

Note

The goal of functional independence is to maximise cohesion while minimising coupling.

Having many functionally independent modules helps a software system be resilient to change:
because functionally independent modules rely on fewer other modules, there is less chance of
changes to these modules spreading to those which are functionally independent.

Functional independence makes modules easier to develop and test. Changes made to how
they perform their function are less likely to affect the software as a whole.

Functional independence is one of the goals of using information hiding and modularity.
Consider this: there can be no good information hiding if the software has not been broken into
modules. If the software has not been broken into modules, there can not ever be functionally
independent modules. If no information is hid from other modules of the software, if every
module always depended on all the others to perform its function, any change made to the
software will always result in changes having to be made elsewhere in the software in order to
handle these changes.

Refinement:
Stepwise refinement is the idea that software is developed by moving through the levels of
abstraction, beginning at higher levels and, incrementally refining the software through each
level of abstraction, providing more detail at each increment. At higher levels, the software is
merely its design models; at lower levels there will be some code; at the lowest level the
software has been completely developed.

At the early steps of the refinement process the software engineer does not necessarily know
how the software will perform what it needs to do. This is determined at each successive
refinement step, as the design and the software is elaborated upon.

Refinement can be seen as the compliment of abstraction. Abstraction is concerned with hiding
lower levels of detail; it moves from lower to higher levels. Refinement is the movement from
higher levels of detail to lower levels. Both concepts are necessary in developing software.

Design classes

As the design progresses, classes can often be fit into various roles. Five common roles are
presented below.

 User interface classes. Instances of these classes are used to provide all the
interaction between the user and the software. Often, interaction with the software
occurs through the use of a metaphor (think of the desktop metaphor, or the drawing
board metaphor in Computer Aided Design software), and user interface classes may
represent elements of this metaphor.
 Domain classes. These are the classes that are used to implement some specific
portion of the problem domain that the software is attempting to solve. Classes that
represent books and catalogues are examples of domain classes for software used in a
library.
 Process classes. Are lower-level domain classes used to implement the software.
 Persistent classes. Are classes that represent data stores, and data that will persist
even when the program is not executing. They are useful for hiding the details of
obtaining specific data from databases and files.
 System classes. Provide the functionality the software requires to operate and
communicate with the environment in which it will be functioning.

When used in software design, these classes can be represented using appropriately named
stereotypes. For example, user interface classes can be represented in class diagrams using the
«user interface» stereotype, persistence classes with «persistent», and system classes with
«system». However, the stereotypes should only be used if they will add useful meaning to the
model. If knowing that a particular class will be used in the user interface is not useful, do not
add the stereotype.

These classes should have the following properties:

 The class should do all that its name implies, and do only what its name implies.
 The class and each of its method should provide only one way to do the same thing.
 The class should be functionally independent. That is, it should have high cohesion and
low coupling.
Architectural Design:

Repository Model

A repository model is a system that will allow interfacing sub-systems to share the same data.
Sub-system must exchange data so that they can work together effectively. This may be done in
two ways:

1. All shared data is held in a central database that can be accessed by all subsystems. It is called
repository model.

2. Each sub-system maintains its own database. Data is interchanged with other sub-systems by
passing messages to them.

Example: CASE Toolset

Advantages:

 It is an efficient way to share large amounts of data. There is no need to transmit data
explicitly from one sub-system to another.
 Sub-systems that produce data need not be concerned with how that data is used by other
subsystems.
 Activities such as backup, security, access control and recovery from error are
centralized.

Disadvantages:
 It is a compromise between the specific needs of each tool. Performance may be
adversely affected by this compromise.
 Evolution may be difficult as a large volume of information is generated according to an
agreed data model.
 Different sub-systems may have different requirements for security, recovery and backup
policies. The repository model forces the same policy on all subsystems.