5.

Design concepts
• In this phase the focus is on dividing the system into modules that will be developed later.
• A design methodology is basically a systematic approach to creating a design by applying a
set of techniques and guidelines.
5.1DESIGN PROCESS

• Design models provide variety of different views of the system and works in an iterative
manner to translate the requirements into a blueprint for constructing the software.
• Different methods are used for constructing the design model.
• All these methods use a set of design principles for designing a model.
• Software design characteristics
I. The design must cover all the explicit requirements as specified in the requirement
models and must also support the implicit requirements as desired by the stake
holders. Example, if you are designing a battery operated toy, then one of the explicit
requirement is to provide for a battery slot within the toy body, whereas the implicit
requirement is an interface for charging the battery.This is so because without the
charging interface, the battery slot is of no use to the toy.
II. The design must support for documentation which can be further used by developers
and testers.
III. The design artifacts, all put together, must provide a complete picture of the software,
focusing on the data, functional and behavioral domains from the implementation point
of view.
5.1.1 Guidelines for Software Design
• A design should support an architecture that is part of recognizable or standard architectural styles and
patterns, is made up of components with good design characteristics and can be implemented in an
evolutionary manner, thereby facilitating coding and testing
• A design should define the software as a set of modules or subsystems that are logically interconnected
to each other.
• A design should provide distinct representations of data, interfaces, and components.
• A design should depict the data structures that are appropriate for class implementation.
• A design should also depict the components along with their functional characteristics. and also define
their degree of interrelationship with other components in the system.
• A design should exhibit the interfaces that the components will use to provide their services or get
services from the external environment.
• A design should be obtained in an iterative manner.
• A design should be depicted using notations that depict its meaning
• Quality Attributes
i. Functionality is assessed by evaluating the generality of the services that are provided by
the software and the security of the overall system.
ii. Usability is evaluated by considering the overall features, consistency and documentation.
iii. Reliability factor of the software defines the extent to which the system can continue to
work, inspite of failures. It is checked by measuring the frequency and the severity of failure,
the accuracy of the output results, the mean-time-to-failure(MTTF), and the ability to
recover from a failure.
iv. Performance, measured by factors like processing speed, response time, throughput,
efficiency, etc.
v. Supportability refers to the ability of the design to support for maintenance (ie, software
extension, adaptability and serviceability), testability, compatibility, and configurability (ease
of system installation and or customization).
5.1.2 Evolution of Software Design
• The evolution of software design has been a continuous process, spanning across decades.
• The early works concentrated on a top down approach for software design, which came to be
known as the structured programming approach.This approach focused on the procedural
aspects of design definition (focus on designing the logic for each service provided by the
application )
• Later works proposed methods for integrating data flow or data structure into design
definition This led to the birth of object-oriented approach for software design process.
• As different types of software applications came up, there was an interest to identify patterns
in their architecture thereby coming up with a new term the design patterns.This led to
shifting focus on software architecture and design patterns that can be used to implement
software architectures and lower levels of design abstractions.
5.2 DESIGN CONCEPTS
5.2.1 Problem Partitioning/Modularity
For small problem, we can handle the entire problem at once but for the significant problem, divide the problems and conquer the
problem it means to divide the problem into smaller pieces so that each piece can be captured separately.

• For software design, the goal is to divide the problem into manageable pieces.

• Benefits of Problem Partitioning

1. Software is easy to understand

2. Software becomes simple

3. Software is easy to test

4. Software is easy to modify

5. Software is easy to maintain

6. Software is easy to expand

• These pieces cannot be entirely independent of each other as they together form the system. They have to cooperate and
communicate to solve the problem. This communication adds complexity.
DISADVANTAGES OF MODULARITY

• Execution time maybe, but not certainly, longer

• Storage size perhaps, but is not certainly, increased
• Compilation and loading time may be longer
• Inter-module communication problems may be increased
• More linkage required, run-time may be longer, more source lines must be written, and
more documentation has to be done
5.2.2 ABSTRACTION

• An abstraction is a tool that enables a designer to consider a component at an abstract level

without bothering about the internal details of the implementation. Abstraction can be used
for existing element as well as the component being designed.
• Here, there are three common abstraction mechanisms
1. Functional Abstraction
2. Data Abstraction
3. Control Abstraction
 5.2.3 ARCHITECTURE

• Software architecture refers to the structure of the system, which is composed of various
components of a program/ system, the attributes (properties) of those components and the
relationship amongst them.

• The software architecture enables the software engineers to analyze the software design
efficiently. In addition, it also helps them in decision-making and handling risks.
 5.2.4 PATTERNS

• A pattern provides a description of the solution to a recurring design problem of some

specific domain in such a way that the solution can be used again and again. The objective
of each pattern is to provide an insight to a designer who can determine the following.
1. Whether the pattern can be reused
2. Whether the pattern is applicable to the current project
3. Whether the pattern can be used to develop a similar but functionally or structurally
different design pattern.
 5.2.4 SEPARATION OF CONCERNS(COUPLING)

• In software engineering, the coupling is the degree of interdependence between

software modules.
• Two modules that are tightly coupled are strongly dependent on each other. However,
two modules that are loosely coupled are not dependent on each other.
• Uncoupled modules have no interdependence at all within them.
The various types of coupling techniques are shown in fig:
A good design is the one that has low coupling. Coupling is measured by the number of
relations between the modules. That is, the coupling increases as the number of calls
between modules increase or the amount of shared data is large. Thus, it can be said that a
design with high coupling will have more errors.
1. NO DIRECT COUPLING: THERE IS NO DIRECT
COUPLING BETWEEN M1 AND M2.
2. DATA COUPLING: WHEN DATA OF ONE MODULE IS PASSED TO ANOTHER MODULE, THIS IS CALLED
DATA COUPLING.
3. STAMP COUPLING:

• Two modules are stamp coupled if they communicate using composite data items such
as structure, objects, etc.
• For example, passing structure variable in C or object in C++ language to a module.
4. CONTROL COUPLING:

• Control Coupling exists among two modules if data from one module is used to direct the
structure of instruction execution in another.
5. EXTERNAL COUPLING:

• External Coupling arises when two modules share an externally imposed data format,
communication protocols, or device interface. This is related to communication to
external tools and devices.
 6. COMMON COUPLING:

• Two modules are common coupled if they share information through some global data
items.
7. CONTENT COUPLING:

• Content Coupling exists among two modules if they share code, e.g., a branch from one
module into another module.
5.2.5 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 modification by clients .
• Information hiding serves as a criterion that can be used to decompose a
system into modules. The principle is also useful for reducing coupling within a
system.
5.2.6 FUNCTIONAL DEPENDENCE(COHESION)

• The measure of how strongly the elements are related functionally inside a
module is called cohesion in software engineering
• Cohesion is considered as good thing because it is about creating a software
component that combines related functionalities into a single unit.
 TYPES OF COHESION
• Coincidental cohesion (worst)
Coincidental cohesion is when parts of a module are grouped arbitrarily; the only relationship between the parts is that
they have been grouped together (e.g., a “Utilities” class).
• Logical cohesion
Logical cohesion is when parts of a module are grouped because they are logically categorized to do the same thing even
though they are different by nature (e.g., grouping all mouse and keyboard input handling routines ).
• Temporal cohesion
Temporal cohesion is when parts of a module are grouped by when they are processed - the parts are processed at a
particular time in program execution (e.g., a function which is called after catching an exception which closes open files, creates
an error log, and notifies the user).
• Procedural cohesion
Procedural cohesion is when parts of a module are grouped because they always follow a certain sequence of execution
(e.g., a function which checks file permissions and then opens the file).
• Communicational/informational cohesion
Communicational cohesion is when parts of a module are grouped because they operate
on the same data (e.g., a module which operates on the same record of information).
• Sequential cohesion
Sequential cohesion is when parts of a module are grouped because the output from
one part is the input to another part like an assembly line (e.g., a function which reads data
from a file and processes the data).
• Functional cohesion (best)
Functional cohesion is when parts of a module are grouped because they all contribute
to a single well-defined task of the module .
 5.2.7 REFINEMENT

• Refinement- removes impurities

Refinement simply means to refine something, to remove any impurities if present and
increase the quality.
• The refinement concept of software design is actually a process of developing or
presenting the software or system in a detailed manner that means to elaborate a
system or software. Refinement is very necessary to find out any error if present and
then to reduce it.
5.2.8 ASPECTS

• Object Oriented Modeling(OOM) divides designing concept into two aspects of work:
1. The modelling of dynamic behaviors like business processes and use cases.
2. The modelling of static structures like classes and components.
5.2.9 REFACTORING

• Refactoring is the process of changing a software system in such a way that it does not
alter the function of the code yet improves its internal structure .
• i.e. to reconstruct something in such a way that it does not affect the actual behavior or
any other features.
• Used to reduce complexity, to simplify the design without affecting the actual behavior
of the system.
5.2.10 OBJECT ORIENTED DESIGN CONCEPTS
1. Objects: All entities involved in the solution design are known as objects. For example, person, banks,
company, and users are considered as objects. Every entity has some attributes associated with it and has
some methods to perform on the attributes.
2. Classes: A class is a generalized description of an object. An object is an instance of a class. A class defines all
the attributes, which an object can have and methods, which represents the functionality of the object.

3. Messages: Objects communicate by message passing. Messages consist of the integrity of the target object,
the name of the requested operation, and any other action needed to perform the function. Messages are
often implemented as procedure or function calls.
4. Abstraction In object-oriented design, complexity is handled using abstraction. Abstraction is the removal of
the irrelevant and the amplification of the essentials.
5. Encapsulation: Encapsulation is also called an information hiding concept. The data and
operations are linked to a single unit. Encapsulation not only bundles essential information of an
object together but also restricts access to the data and methods from the outside world.

6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner where the lower or
sub-classes can import, implement, and re-use allowed variables and functions from their
immediate superclasses.This property of OOD is called an inheritance. This makes it easier to
define a specific class and to create generalized classes from specific ones.
7. Polymorphism: OOD languages provide a mechanism where methods performing similar tasks
but vary in arguments, can be assigned the same name. This is known as polymorphism, which
allows a single interface is performing functions for different types. Depending upon how the service
is invoked, the respective portion of the code gets executed.
 5.2.11 DESIGN CLASSES
There are five different types of design classes and each type represents the layer of the design architecture these are
as follows:
1. User interface classes
•These classes are designed for Human Computer Interaction(HCI).
2. Business domain classes
•These classes are recognized as attributes and methods which are required to implement the elements of the
business domain.
3. Process classes
•It implement the lower level business abstraction which is needed to completely manage the business domain
class.
4. Persistence classes
•It shows data stores that will persist behind the execution of the software.
5. System Classes
•System classes implement software management and control functions that allow to operate and communicate in
computing environment and outside world.
5.2.12 DEPENDENCY INVERSION

• The general idea of this principle is as simple as it is important: High-level modules,

which provide complex logic, should be easily reusable and unaffected by changes in
low-level modules. To achieve that, you need to introduce an abstraction that decouples
the high-level and low-level modules from each other.
• definition of the Dependency Inversion Principle consists of two parts:
1. High-level modules should not depend on low-level modules. Both should depend on
abstractions.
2. Abstractions should not depend on details. Details should depend on abstractions.
5.2.13 DESIGN FOR TEST

• Design verification ensures that the product i.e. designed is the same as the product i.e.
intended.
• Design verification methods are:
1.Demonstration: It is done in actual or simulated environment.
2.Inspection : It is done to verify the requirements related to physical characteristics.
3.Analysis: It is done to verify the design and is most preferred method in case if testing is not
feasible or in case when there is minimal risk.
4.Testing: It is most expensive verification method due to project complexity as well as
equipment & facility requirements.
5.3 DESIGN MODEL

• Design is very important phase and is

a multi-step process which represents
data structure, program structure,
interface characteristics and
procedural details.
5.3.1 DATA DESIGN ELEMENTS

• Data design represents the data objects and their inter-relationships.

• It is used to describe the logical structure of data processed by the system.
• E-R Model- illustrates the entities in the
system, their attributes and relationships
between the entities.
• It is widely used in database design.
• Data Object-is a data model that
illustrates composite information of
entities in such a way that it is
understood by the software.
A Data Dictionary

is a collection of names,
definitions, and attributes
about data elements that are
being used or captured in a
database, information
system,
5.3.2 ARCHITECTURAL DESIGN ELEMENTS

• The architectural design shows the relationship amongst the major structural elements of
the software
• Architectural design process is about identifying the components i.e. the sub-systems that
make-up a system and the structure of sub-systems and their inter-relationships.
1.A LAYERED ARCHITECTURE

• A layered architecture is classified into four distinct layers: presentation, business,

persistence, and database; however, the pattern is not confined to the specified layers
and there can be an application layer or service layer or data access layer.
2.CLIENT-SERVER ARCHITECTURE
3.CALL AND RETURN ARCHITECTURE
4.DATA CENTERED ARCHITECTURE
5.3.3INTERFACE DESIGN ELEMENTS

• User Interface (UI) design describes how the software communicates with the users Le.
the behavior of the system.
• How the user feels' when working with the application is the key to acceptance.And
that's why, the User Interface Design is necessary in the design process.
UI design elements include input controls such as:
• Buttons
• Text fields
• Checkboxes
• Radio buttons, etc.
UI design elements include navigational components such as
• Search fields
• Sliders, icons
• Links etc.
UI design elements include informational components such as:
• Tooltips
• Progress bar
• Message box
• Pop up window
UI design elements include containers such as:
• Frames
• Panel
5.3.4 COMPONENT –LEVEL DIAGRAM

• A component diagram describes the organization of the physical components in a

system..
• Components are concern with the physical aspect of the system. Physical aspects are the
elements like executable, libraries, files, documents etc, which reside in the node.
5.3.5 DEPLOYMENT - LEVEL DIAGRAM

• Deployment Diagram contains nodes, components and the connection between them.
• Deployment diagram show the configuration of run-time processing elements and the
software components ,processes and objects that live in them.
• Deployment diagram models the hardware of the implementation environment.
• Example 1: Database server (any kind of) can connect with client machine through
Internet.