UNIT-III

Software Design: Principles

Software Design Principles

Software design principles are concerned with providing means to handle the complexity of the design
process effectively. Effectively managing the complexity will not only reduce the effort needed for design but
can also reduce the scope of introducing errors during design.

Following are the principles of Software Design

Problem Partitioning

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.

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 two common abstraction mechanisms

1. Functional Abstraction
2. Data Abstraction

Functional Abstraction
i. A module is specified by the method it performs.
ii. The details of the algorithm to accomplish the functions are not visible to the user of the function.

Functional abstraction forms the basis for Function oriented design approaches.

Data Abstraction

Details of the data elements are not visible to the users of data. Data Abstraction forms the basis for Object
Oriented design approaches.

Modularity

Modularity specifies to the division of software into separate modules which are differently named and
addressed and are integrated later on in to obtain the completely functional software. It is the only property
that allows a program to be intellectually manageable. Single large programs are difficult to understand and
read due to a large number of reference variables, control paths, global variables, etc.

The desirable properties of a modular system are:

o Each module is a well-defined system that can be used with other applications.
o Each module has single specified objectives.
o Modules can be separately compiled and saved in the library.
o Modules should be easier to use than to build.
o Modules are simpler from outside than inside.
Advantages and Disadvantages of Modularity

Advantages of Modularity

There are several advantages of Modularity

o It allows large programs to be written by several or different people
o It encourages the creation of commonly used routines to be placed in the library and used by other
programs.
o It simplifies the overlay procedure of loading a large program into main storage.
o It provides more checkpoints to measure progress.
o It provides a framework for complete testing, more accessible to test
o It produced the well designed and more readable program.

Disadvantages of Modularity

There are several disadvantages of Modularity

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

Modular Design

Modular design reduces the design complexity and results in easier and faster implementation by allowing
parallel development of various parts of a system. We discuss a different section of modular design in detail in
this section:

1. Functional Independence: Functional independence is achieved by developing functions that perform only
one kind of task and do not excessively interact with other modules. Independence is important because it
makes implementation more accessible and faster. The independent modules are easier to maintain, test, and
reduce error propagation and can be reused in other programs as well. Thus, functional independence is a
good design feature which ensures software quality.

It is measured using two criteria:

o Cohesion: It measures the relative function strength of a module.
o Coupling: It measures the relative interdependence among modules.

2. Information hiding: The fundamental of Information hiding suggests that modules can be characterized
by the design decisions that protect from the others, i.e., In other words, modules should be specified that
data include within a module is inaccessible to other modules that do not need for such information.
 o The use of information hiding as design criteria for modular system provides the most significant
benefits when modifications are required during testing's and later during software maintenance. This
is because as most data and procedures are hidden from other parts of the software, inadvertent errors
introduced during modifications are less likely to propagate to different locations within the software.
How Can a Software Module be Independent, Reusable, and Interchangeable?

There are some important properties of a software module that make it possible for teams to work
independently, making the software module reusable in many systems and interchangeable.

A module…

1. encapsulates functionality and data. Encapsulation is about hiding the implementation details of a
module. The less a module knows about other modules, the less dependent it will be on changes in other
modules. Other modules can only access functionality and data via the provided interface. Generally, it is
good to encapsulate as much as possible.

2. provides an interface to other modules for accessing its functionality and data. The software module
interface should be as abstracted and as small as possible. Fewer details mean looser coupling between
software modules and make them more independent, reusable, and interchangeable.
3. requires interfaces provided by other software modules. To realize the functionality of a software
module, it must sometimes use the provided interfaces of other modules. A software module that uses
another module through its interface has a dependency on that other module. The fewer dependencies,
the better. Since non-backward compatible interface changes may occur in a software module's lifecycle,
an update to a module can be forced without any benefit to customers, such as better performance,
functionality, or quality. Forced software updates that do not improve customer benefit should be
considered a cost of complexity in software development.

Let's illustrate.

Figure 1. A software module provides and requires interfaces

 Module B1 provides Interface B to Module A and requires Interfaces C and D. Assume we have a new Module
B2 with improved performance. If Module B2 provides the same interface and requires the same interfaces as
B1, then it is interchangeable with B1.

Software Architecture
Architecture serves as a blueprint for a system. It provides an abstraction to manage the system complexity
and establish a communication and coordination mechanism among components.
 It defines a structured solution to meet all the technical and operational requirements, while
optimizing the common quality attributes like performance and security.
 Further, it involves a set of significant decisions about the organization related to software
development and each of these decisions can have a considerable impact on quality, maintainability,
performance, and the overall success of the final product. These decisions comprise of −
o Selection of structural elements and their interfaces by which the system is composed.
o Behavior as specified in collaborations among those elements.
o Composition of these structural and behavioral elements into large subsystem.
o Architectural decisions align with business objectives.
o Architectural styles guide the organization.

Software Design
Software design provides a design plan that describes the elements of a system, how they fit, and work
together to fulfill the requirement of the system. The objectives of having a design plan are as follows −
 To negotiate system requirements, and to set expectations with customers, marketing, and
management personnel.
 Act as a blueprint during the development process.
 Guide the implementation tasks, including detailed design, coding, integration, and testing.

It comes before the detailed design, coding, integration, and testing and after the domain analysis,
requirements analysis, and risk analysis.
Goals of Architecture
The primary goal of the architecture is to identify requirements that affect the structure of the application. A
well-laid architecture reduces the business risks associated with building a technical solution and builds a
bridge between business and technical requirements.
Some of the other goals are as follows −
 Expose the structure of the system, but hide its implementation details.
 Realize all the use-cases and scenarios.
 Try to address the requirements of various stakeholders.
 Handle both functional and quality requirements.
 Reduce the goal of ownership and improve the organization’s market position.
 Improve quality and functionality offered by the system.
 Improve external confidence in either the organization or system.
Limitations

Software architecture is still an emerging discipline within software engineering. It has the following limitations
−
 Lack of tools and standardized ways to represent architecture.
 Lack of analysis methods to predict whether architecture will result in an implementation that meets
the requirements.
 Lack of awareness of the importance of architectural design to software development.
 Lack of understanding of the role of software architect and poor communication among stakeholders.
 Lack of understanding of the design process, design experience and evaluation of design.

Coupling and Cohesion

Module 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.

Types of Module Coupling

1. No Direct Coupling: There is no direct coupling between M1 and M2.

In this case, modules are subordinates to different modules. Therefore, no direct coupling.

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. When the module passes non-global data structure or entire structure to another
module, they are said to be stamp coupled. 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.

Module Cohesion

In computer programming, cohesion defines to the degree to which the elements of a module belong
together. Thus, cohesion measures the strength of relationships between pieces of functionality within a given
module. For example, in highly cohesive systems, functionality is strongly related.

Cohesion is an ordinal type of measurement and is generally described as "high cohesion" or "low cohesion."

Types of Modules Cohesion

1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of a module,
cooperate to achieve a single function.
 2. Sequential Cohesion: A module is said to possess sequential cohesion if the element of a module
form the components of the sequence, where the output from one component of the sequence is
input to the next.
3. Communicational Cohesion: A module is said to have communicational cohesion, if all tasks of the
module refer to or update the same data structure, e.g., the set of functions defined on an array or a
stack.
4. Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose of the module
are all parts of a procedure in which particular sequence of steps has to be carried out for achieving a
goal, e.g., the algorithm for decoding a message.
5. Temporal Cohesion: When a module includes functions that are associated by the fact that all the
methods must be executed in the same time, the module is said to exhibit temporal cohesion.
6. Logical Cohesion: A module is said to be logically cohesive if all the elements of the module perform
a similar operation. For example Error handling, data input and data output, etc.
7. Coincidental Cohesion: A module is said to have coincidental cohesion if it performs a set of tasks
that are associated with each other very loosely, if at all.

Differentiate between Coupling and Cohesion

Coupling Cohesion

Coupling is also called Inter-Module Binding. Cohesion is also called Intra-Module Binding.

Coupling shows the relationships between Cohesion shows the relationship within the module.
modules.

Coupling shows the Cohesion shows the module's relative functional strength.
relative independence between the modules.

While creating, you should aim for low While creating you should aim for high cohesion, i.e., a
coupling, i.e., dependency among modules cohesive component/ module focuses on a single function (i.e.,
should be less. single-mindedness) with little interaction with other modules of
the system.

In coupling, modules are linked to the other In cohesion, the module focuses on a single thing.
modules.

Refactoring

Refactoring is the process of restructuring code, while not changing its original functionality. The goal of
refactoring is to improve internal code by making many small changes without altering the code's external
behavior.
Computer programmers and software developers refactor code to improve the design, structure and
implementation of software. Refactoring improves code readability and reduces complexities.
The refactoring process features many small changes to a program's source code. One approach to
refactoring, for example, is to improve the structure of source code at one point and then extend the same
changes systematically to all applicable references throughout the program. The thought process is that all the
small, behavior-preserving changes to a body of code have a cumulative effect. These changes preserve the
software's original behavior and do not modify its behavior.

What are the benefits of refactoring?

Refactoring can provide the following benefits:

 Makes the code easier to understand and read because the goal is to simplify code and reduce
complexities.

 Improves maintainability and makes it easier to spot bugs or make further changes.

 Encourages a more in-depth understanding of code. Developers have to think further about how their
code will mix with code already in the code base.

 Focus remains only on functionality. Not changing the code's original functionality ensures the original
project does not lose scope.
What are the challenges of refactoring?

Challenges do come with the process, however. Some of these include:

 The process will take extra time if a development team is in a rush and refactoring is not planned for.

 Without clear objectives, refactoring can lead to delays and extra work.

 Refactoring cannot address software flaws by itself, as it is made to clean code and make it less complex.

Structured Analysis
Structured Analysis is a development method that allows the analyst to understand the system and its
activities in a logical way.
It is a systematic approach, which uses graphical tools that analyze and refine the objectives of an existing
system and develop a new system specification which can be easily understandable by user.
It has following attributes −
 It is graphic which specifies the presentation of application.
 It divides the processes so that it gives a clear picture of system flow.
 It is logical rather than physical i.e., the elements of system do not depend on vendor or hardware.
 It is an approach that works from high-level overviews to lower-level details.

Structured Analysis Tools

During Structured Analysis, various tools and techniques are used for system development. They are −
 Data Flow Diagrams
 Data Dictionary
 Decision Trees

Data Flow Diagrams (DFD) or Bubble Chart

It is a technique developed by Larry Constantine to express the requirements of system in a graphical form.
 It shows the flow of data between various functions of system and specifies how the current system is
implemented.
 It is an initial stage of design phase that functionally divides the requirement specifications down to the
lowest level of detail.
 Its graphical nature makes it a good communication tool between user and analyst or analyst and
system designer.
Basic Elements of DFD

DFD is easy to understand and quite effective when the required design is not clear and the user wants a
notational language for communication. However, it requires a large number of iterations for obtaining the
most accurate and complete solution.
The following table shows the symbols used in designing a DFD and their significance −
Symbol Name Symbol Meaning

Square Source or Destination of Data

Arrow Data flow

Circle Process transforming data flow

Open Rectangle Data Store

Data Dictionary
A data dictionary is a structured repository of data elements in the system. It stores the descriptions of all DFD
data elements that is, details and definitions of data flows, data stores, data stored in data stores, and the
processes.
A data dictionary improves the communication between the analyst and the user. It plays an important role in
building a database. Most DBMSs have a data dictionary as a standard feature. For example, refer the
following table −
Sr.No. Data Name Description No. of Characters

1 ISBN ISBN Number 10

2 TITLE title 60

3 SUB Book Subjects 80

4 ANAME Author Name 15

Decision Trees
Decision trees are a method for defining complex relationships by describing decisions and avoiding the
problems in communication. A decision tree is a diagram that shows alternative actions and conditions within
horizontal tree framework. Thus, it depicts which conditions to consider first, second, and so on.
Decision trees depict the relationship of each condition and their permissible actions. A square node indicates
an action and a circle indicates a condition. It forces analysts to consider the sequence of decisions and
identifies the actual decision that must be made.

The major limitation of a decision tree is that it lacks information in its format to describe what other
combinations of conditions you can take for testing. It is a single representation of the relationships between
conditions and actions.
For example, refer the following decision tree −
Object Modeling Technique (OMT) is real world based modeling approach for software modeling and
designing. It was developed basically as a method to develop object-oriented systems and to support
object-oriented programming. It describes the static structure of the system.
Object-oriented development did not spontaneously generate itself from the ashes of the uncounted
failed software projects that used earlier technologies. It is not a radical departure from earlier approaches.
Indeed, it is founded in the best ideas from prior technologies.
Object Modeling Technique is easy to draw and use. It is used in many applications like telecommunication,
transportation, compilers etc. It is also used in many real world problems. OMT is one of the most popular
object oriented development techniques used now-a-days. OMT was developed by James Rambaugh.
Purpose of Object Modeling Technique:
 To test physical entity before construction of them.
 To make communication easier with the customers.
 To present information in an alternative way i.e. visualization.
 To reduce the complexity of software.
 To solve the real world problems.
Object Modeling Technique’s Models:
There are three main types of models that has been proposed by OMT:
1. Object Model:
Object Model encompasses the principles of abstraction, encapsulation, modularity, hierarchy, typing,
concurrency and persistence. Object Model basically emphasizes on the object and class. Main concepts
related with Object Model are classes and their association with attributes. Predefined relationships in
object model are aggregation and generalization (multiple inheritance).
2. Dynamic Model:
Dynamic Model involves states, events and state diagram (transition diagram) on the model. Main
concepts related with Dynamic Model are states, transition between states and events to trigger the
transitions. Predefined relationships in object model are aggregation (concurrency) and generalization.
3. Functional Model:
Functional Model focuses on the how data is flowing, where data is stored and different processes. Main
concepts involved in Functional Model are data, data flow, data store, process and actors. Functional
Model in OMT describes the whole processes and actions with the help of data flow diagram (DFD).

Unified Modeling Language (UML)

Unified Modeling Language (UML) is a general purpose modelling language. The main aim of UML is to
define a standard way to visualize the way a system has been designed. It is quite similar to blueprints used
in other fields of engineering.
UML is not a programming language, it is rather a visual language. We use UML diagrams to portray
the behavior and structure of a system. UML helps software engineers, businessmen and system architects
with modelling, design and analysis. The Object Management Group (OMG) adopted Unified Modelling
Language as a standard in 1997. Its been managed by OMG ever since. International Organization for
Standardization (ISO) published UML as an approved standard in 2005. UML has been revised over the years
and is reviewed periodically.
Do we really need UML?
 Complex applications need collaboration and planning from multiple teams and hence require a clear
and concise way to communicate amongst them.
 Businessmen do not understand code. So UML becomes essential to communicate with non
programmers essential requirements, functionalities and processes of the system.
 A lot of time is saved down the line when teams are able to visualize processes, user interactions and
static structure of the system.
UML is linked with object oriented design and analysis. UML makes the use of elements and forms
associations between them to form diagrams. Diagrams in UML can be broadly classified as:
1. Structural Diagrams – Capture static aspects or structure of a system. Structural Diagrams include:
Component Diagrams, Object Diagrams, Class Diagrams and Deployment Diagrams.
2. Behavior Diagrams – Capture dynamic aspects or behavior of the system. Behavior diagrams include:
Use Case Diagrams, State Diagrams, Activity Diagrams and Interaction Diagrams.
The image below shows the hierarchy of diagrams according to UML 2.2

Goals of UML
o Since it is a general-purpose modeling language, it can be utilized by all the modelers.
o UML came into existence after the introduction of object-oriented concepts to systemize and
consolidate the object-oriented development, due to the absence of standard methods at that time.
o The UML diagrams are made for business users, developers, ordinary people, or anyone who is looking
forward to understand the system, such that the system can be software or non-software.
o Thus it can be concluded that the UML is a simple modeling approach that is used to model all the
practical systems.

Characteristics of UML

The UML has the following features:

o It is a generalized modeling language.
o It is distinct from other programming languages like C++, Python, etc.
o It is interrelated to object-oriented analysis and design.
o It is used to visualize the workflow of the system.
o It is a pictorial language, used to generate powerful modeling artifacts.
UML-Building Blocks

UML is composed of three main building blocks, i.e., things, relationships, and diagrams. Building blocks
generate one complete UML model diagram by rotating around several different blocks. It plays an essential
role in developing UML diagrams. The basic UML building blocks are enlisted below:
1. Things
2. Relationships
3. Diagrams

Things

Anything that is a real world entity or object is termed as things. It can be divided into several different
categories:
o Structural things
o Behavioral things
o Grouping things
o Annotational things

Structural things

Nouns that depicts the static behavior of a model is termed as structural things. They display the physical and
conceptual components. They include class, object, interface, node, collaboration, component, and a use case.

Class: A Class is a set of identical things that outlines the functionality and properties of an object. It also
represents the abstract class whose functionalities are not defined. Its notation is as follows;

Object:: An individual that describes the behavior and the functions of a system. The notation of the object is
similar to that of the class; the only difference is that the object name is always underlined and its notation is
given below;
Interface: A set of operations that describes the functionality of a class, which is implemented whenever an
interface is implemented.

Collaboration: It represents the interaction between things that is done to meet the goal. It is symbolized as a
dotted ellipse with its name written inside it.

Use case: Use case is the core concept of object-oriented modeling. It portrays a set of actions executed by a
system to achieve the goal.

Actor: It comes under the use case diagrams. It is an object that interacts with the system, for example, a user.
Component: It represents the physical part of the system.

Node: A physical element that exists at run time.

Behavioral Things

They are the verbs that encompass the dynamic parts of a model. It depicts the behavior of a system. They
involve state machine, activity diagram, interaction diagram, grouping things, annotation things

State Machine: It defines a sequence of states that an entity goes through in the software development
lifecycle. It keeps a record of several distinct states of a system component.
Activity Diagram: It portrays all the activities accomplished by different entities of a system. It is represented
the same as that of a state machine diagram. It consists of an initial state, final state, a decision box, and an
action notation.

Interaction Diagram: It is used to envision the flow of messages between several components in a system.
Grouping Things

It is a method that together binds the elements of the UML model. In UML, the package is the only thing,
which is used for grouping.

Package: Package is the only thing that is available for grouping behavioral and structural things.

Annotation Things

It is a mechanism that captures the remarks, descriptions, and comments of UML model elements. In UML, a
note is the only Annotational thing.

Note: It is used to attach the constraints, comments, and rules to the elements of the model. It is a kind of
yellow sticky note.

Relationships

It illustrates the meaningful connections between things. It shows the association between the entities and
defines the functionality of an application. There are four types of relationships given below:

Dependency: Dependency is a kind of relationship in which a change in target element affects the source
element, or simply we can say the source element is dependent on the target element. It is one of the most
important notations in UML. It depicts the dependency from one entity to another.

It is denoted by a dotted line followed by an arrow at one side as shown below,

AD

Association: A set of links that associates the entities to the UML model. It tells how many elements are
actually taking part in forming that relationship.

It is denoted by a dotted line with arrowheads on both sides to describe the relationship with the element on
both sides.
Generalization: It portrays the relationship between a general thing (a parent class or superclass) and a
specific kind of that thing (a child class or subclass). It is used to describe the concept of inheritance.

It is denoted by a straight line followed by an empty arrowhead at one side.

Realization: It is a semantic kind of relationship between two things, where one defines the behavior to be
carried out, and the other one implements the mentioned behavior. It exists in interfaces.

It is denoted by a dotted line with an empty arrowhead at one side.

Diagrams

The diagrams are the graphical implementation of the models that incorporate symbols and text. Each symbol
has a different meaning in the context of the UML diagram. There are thirteen different types of UML
diagrams that are available in UML 2.0, such that each diagram has its own set of a symbol. And each diagram
manifests a different dimension, perspective, and view of the system.

UML diagrams are classified into three categories that are given below:
1. Structural Diagram
2. Behavioral Diagram
3. Interaction Diagram

Structural Diagram: It represents the static view of a system by portraying the structure of a system. It shows
several objects residing in the system. Following are the structural diagrams given below:
o Class diagram
o Object diagram
o Package diagram
o Component diagram
o Deployment diagram

Behavioral Diagram: It depicts the behavioral features of a system. It deals with dynamic parts of the system.
It encompasses the following diagrams:
o Activity diagram
o State machine diagram
o Use case diagram

Interaction diagram: It is a subset of behavioral diagrams. It depicts the interaction between two objects and
the data flow between them. Following are the several interaction diagrams in UML:
o Timing diagram
o Sequence diagram
 o Collaboration diagram
UML-TOOLS

Visio

Visio is a part of the Microsoft family, which is a diagramming software. It is helpful in drawing building plans,
floor charts, data flow diagrams, process flow diagrams, business process modeling, swimlane diagrams, and
many more.

Features:
o It connects the diagrams and the flowcharts to real-time data.
o Since it is a platform-independent, it can be accessed from anywhere.

Download link: https://products.office.com/en-in/visio/flowchart-software

Lucidchart
Lucidchart is an HTML-5 based UML tool that allows user interaction while drawing, editing, and sharing
diagrams and charts. With Lucidchart, you can create simple flowcharts as well as complex technical diagrams.

Features:
o It works faster with keyboard shortcuts.
o It constitutes the concept of containerization as the complex diagram involves several steps and
people.
o It manages user account by increasing security.
o It is platform-independent.

Download link: https://www.lucidchart.com/pages/

Gliffy

Gliffy is an open-source software that designs UML diagrams, floor plans, Venn diagrams, flowcharts, and
much more. It allows the user to share and edit Gliffy diagrams dynamically.

Features:
o It constitutes a drag and drop interface.
o It exports diagrams in various formats that are; PDF, JPEG, PNG, and SVG.
o It is supported by all web browsers such as Google Chrome, Firefox, Safari, and Internet Explorer 9+.

Download link: https://www.gliffy.com