Unit 4: Software Architecture & Design Introduction

The architecture of a system describes its major components, their

relationships (structures), and how they interact with each other.
Software architecture and design includes several contributory
factors such as Business strategy, quality attributes, human
dynamics, design, and IT environment.

We can segregate Software Architecture and Design into two

distinct phases: Software Architecture and Software Design.
In Architecture, nonfunctional decisions are cast and separated by
the functional requirements. In Design, functional requirements are
accomplished.

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 −
  Selection of structural elements and their interfaces by which the
system is composed.
 Behavior as specified in collaborations among those elements.
 Composition of these structural and behavioral elements into large
subsystem.
 Architectural decisions align with business objectives.
 Architectural styles guide the organization.

Architecture View :
It is generally used to represent entire architecture that is useful and
meaningful to one or more stakeholders in system. Architecture view or
viewpoint is set of representations of an architecture that covers
stakeholder issues. It also represents functional and non-functional
requirements of software application. View is basically partial expression
of system from specific perspective. A viewpoint is generally collection of
patterns, templates, and even conventions for developing one type of
view.

In the diagram shown above, you can see following points :

 Use case view –
A use case view is generally used in requirements discipline to provide and
 give basis for planning technical contents of iterations. Using use case
diagrams, it is modeled statically, and using UML behavioral diagrams, it is
modeled dynamically.

 Design View –
A design view generally means to organize design information and
addresses basic structure and also functionality of solution. It simply
explains architecturally important and significant features. It is used to
organize design information. It also describes overall design entities and
attributes.

 Process View –
It generally deals with dynamic aspects of system, describes processes of
system, and even how they communicate and emphasizes behavior of
system during run time. It simply describes different activities of system. It
also describes control thread relationships between components of design
and deployment views. It also describes synchronization aspects of the
design.

 Component View –
It addresses source code realization of system software from perspective of
integrators and developers of project. It simply explains structure and design
of implementation set. It has basically three different views i.e. conventional
view, process-related view, and also object-oriented view.

 Deployment View –
It generally explains distribution of processing across set of nodes in system,
along with physical distribution of processes and fields. It simply explains
structure and design of deployment set. It also shows physical distribution of
processing within system. It basically describes and explains environment
within which system is runner and executed.
Component and Connector View

Introduction:- Component and Connector (C&C) architecture view of a

system has two main elements—components and connectors.
Components are usually computational elements or data stores that have
some presence during the system execution. Connectors define the means
of interaction between these components.

A C&C view of the system defines the components, and which component is
connected to which and through what connector. A C&C view describes a
runtime structure of the system—what components exist when the system is
executing and how they interact during the execution. The C&C structure is
essentially a graph, with components as nodes and connectors as edges. C&C
view is perhaps the most common view of architecture and most box-and-line
drawings representing architecture attempt to capture this view.

Components:-

Components are generally units of computation or data stores in the

system. A component has a name, which is generally chosen to represent
the role of the component or the function it performs.

A component is of a component-type, where the type represents a generic

component, defining the general computation and the interfaces a component of
that type must have. Note that though a component has a type, in the C&C
architecture view.

A component is essentially a system in its own right providing some behavior at

defined interfaces (i.e., ports) to its environment. Like any system, a component
may be complex and have a structure of its own, which can be determined by
decomposing the component. In many situations, particularly for systems that are
not too large, there may not be a need to decompose the components to
determine their internal architecture.

Connectors: -

The different components of a system are likely to interact while the

system is in operation to provide the services expected of the system. After all,
components exist to provide parts of the services and features of the system, and
these must be combined to deliver the overall system functionality. For
composing a system from its components, information about the interaction
between components is necessary.

Interaction between components may be through a simple means supported by

the underlying process execution infrastructure of the operating system. For
example, a component may interact with another using the procedure call
 mechanism (a connector,) which is provided by the runtime environment for the
programming language.

Architectural styles :
The architectural styles that are used while designing the software as
follows:

1. Data-centered architecture

 The data store in the file or database is occupying at the center of the
architecture.
 Store data is access continuously by the other components like an update,
delete, add, modify from the data store.
 Data-centered architecture helps integrity.
 Pass data between clients using the blackboard mechanism.
 The processes are independently executed by the client components.

2. Data-flow architecture

 This architecture is applied when the input data is converted into a series of
manipulative components into output data.
 A pipe and filter pattern is a set of components called as filters.
 Filters are connected through pipes and transfer data from one component to
the next component.
 The flow of data degenerates into a single line of transform then it is known as
batch sequential.

3. Call and return architectures

This architecture style allows to achieve a program structure which is easy to
modify.
Following are the sub styles exist in this category:
1. Main program or subprogram architecture

 The program is divided into smaller pieces hierarchically.

 The main program invokes many of program components in the hierarchy
that program components are divided into subprogram.
2. Remote procedure call architecture
 The main program or subprogram components are distributed in network of
multiple computers.
 The main aim is to increase the performance.

4. Object-oriented architectures

 This architecture is the latest version of call-and-return architecture.

 It consist of the bundling of data and methods.

5. Layered architectures

 The different layers are defined in the architecture. It consists of outer and
inner layer.
 The components of outer layer manage the user interface operations.
 Components execute the operating system interfacing at the inner layer.
 The inner layers are application layer, utility layer and the core layer.
 In many cases, It is possible that more than one pattern is suitable and the
alternate architectural style can be designed and evaluated.
Function Oriented Design :
Function Oriented Design is an approach to software design where the design
is decomposed into a set of interacting units where each unit has a clearly
defined function.
Generic Procedure:
Start with a high level description of what the software / program does. Refine
each part of the description one by one by specifying in greater details the
functionality of each part. These points lead to Top-Down Structure.

Function Oriented Design Strategies:

Function Oriented Design Strategies are as follows:
1. Data Flow Diagram (DFD) :
A data flow diagram (DFD) maps out the flow of information for any process
or system. It uses defined symbols like rectangles, circles and arrows, plus
short text labels, to show data inputs, outputs, storage points and the routes
between each destination.

2. Data Dictionaries:
Data dictionaries are simply repositories to store information about all data
items defined in DFDs. At the requirement stage, data dictionaries contains
data items. Data dictionaries include Name of the item, Aliases (Other
names for items), Description / purpose, Related data items, Range of
values, Data structure definition / form.

3. Structure Charts:
It is the hierarchical representation of system which partitions the system
into black boxes (functionality is known to users but inner details are
unknown). Components are read from top to bottom and left to right. When a
module calls another, it views the called module as black box, passing
required parameters and receiving results.

Pseudo Code:
Pseudo Code is system description in short English like phrases describing
the function. It use keyword and indentation. Pseudo codes are used as
replacement for flow charts. It decreases the amount of documentation
required.
Principles of Software Design:
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.

1Problem 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 compexity.
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 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.
3.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.

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

In this topic, we will discuss various advantage and disadvantage 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

4.Strategy of Design

A good system design strategy is to organize the program modules in such

a method that are easy to develop and latter too, change. Structured
design methods help developers to deal with the size and complexity of
programs. Analysts generate instructions for the developers about how
code should be composed and how pieces of code should fit together to
form a program.

To design a system, there are two possible approaches:

1. Top-down Approach
2. Bottom-up Approach

1. Top-down Approach: This approach starts with the identification of the

main components and then decomposing them into their more detailed
sub-components.
 2.Bottom-up Approach: A bottom-up approach begins with the lower details and moves
towards up the hierarchy, as shown in fig. This approach is suitable in case of an existing
system.

Module level concept :

 Modularization is the process of breaking a software into

multiple small modules, where each module works
independently. The main advantage of modularization is that it
 makes it easy to understand the software, makes it reusable, and it
can be tested easily.

 Independent modules can function without each other, but all

modules in a system must interact to produce desired behavior.
Coupling measures the strength of interconnections between
modules, with higher connections requiring more knowledge to
understand or solve other modules. Loosely coupled modules
have weak interconnections, while independent modules have no
interconnections. The choice of modules determines coupling,
which is largely decided during system design and cannot be
reduced during implementation.

 Coupling reduces when relationships among elements in different

modules are minimized. Cohesion captures the intra module
relationship, determining how closely elements are related. It
helps designers determine if different elements belong together in
the same module. Cohesion and coupling are related, with greater
cohesion reducing coupling. This correlation is not perfect but
has been observed in practice.

]
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- Cohesion is also called Intra-Module
Module Binding. Binding.
Coupling shows the Cohesion shows the relationship within
relationships between modules. the module.
Coupling shows the Cohesion shows the module's
relative independence between relative functional strength.
the modules.
While creating, you should aim While creating you should aim for high
for low coupling, i.e., cohesion, i.e., a cohesive component/
dependency among modules module focuses on a single function
should be less. (i.e., single-mindedness) with little
interaction with other modules of the
system.
In coupling, modules are linked In cohesion, the module focuses on a
to the other modules. single thing.

Design Notations and Specification :

Design Notations
Design Notations are primarily meant to be used during the process of design
and are used to represent design or design decisions. For a function-oriented
design, the design can be represented graphically or mathematically by the
following:
Data Flow Diagram
Data-flow design is concerned with designing a series of functional
transformations that convert system inputs into the required outputs. The
design is described as data-flow diagrams. These diagrams show how data
flows through a system and how the output is derived from the input through
a series of functional transformations.

Data-flow diagrams are a useful and intuitive way of describing a system. They
are generally understandable without specialized training, notably if control
information is excluded. They show end-to-end processing. That is the flow of
processing from when data enters the system to where it leaves the system
can be traced.

Data-flow design is an integral part of several design methods, and most CASE
tools support data-flow diagram creation. Different ways may use different
icons to represent data-flow diagram entities, but their meanings are similar.

The notation which is used is based on the following symbols:

The report generator produces a report which describes all of the named
entities in a data-flow diagram. The user inputs the name of the design
represented by the diagram. The report generator then finds all the names
used in the data-flow diagram. It looks up a data dictionary and retrieves
information about each name. This is then collated into a report which is
output by the system.

Data Dictionaries
A data dictionary lists all data elements appearing in the DFD model of a
system. The data items listed contain all data flows and the contents of all data
stores looking on the DFDs in the DFD model of a system.

A data dictionary lists the objective of all data items and the definition of all
composite data elements in terms of their component data items. For
example, a data dictionary entry may contain that the data grossPay consists
of the parts regularPay and overtimePay.
 grossPay = regularPay + overtimePay

For the smallest units of data elements, the data dictionary lists their name
and their type.

A data dictionary plays a significant role in any software development process

because of the following reasons:

o A Data dictionary provides a standard language for all relevant

information for use by engineers working in a project. A consistent
vocabulary for data items is essential since, in large projects, different
engineers of the project tend to use different terms to refer to the same
data, which unnecessarily causes confusion.
o The data dictionary provides the analyst with a means to determine the
definition of various data structures in terms of their component
elements.

Structured Charts
It partitions a system into block boxes. A Black box system that functionality is
known to the user without the knowledge of internal design.
Structured Chart is a graphical representation which shows:

o System partitions into modules

o Hierarchy of component modules
o The relation between processing modules
o Interaction between modules
o Information passed between modules

The following notations are used in structured chart:

Pseudo-code
Pseudo-code notations can be used in both the preliminary and detailed
design phases. Using pseudo-code, the designer describes system
characteristics using short, concise, English Language phases that are
structured by keywords such as If-Then-Else, While-Do, and End.
 Design specifications are precise and complete enough to be
used as a basis for further development by other
programmers. They provide:

 Initial architectural design

 Specification of side effects
 Exception handling
 Processing algorithms
 Data representation
Design notations should lead to a procedural representation that is easy to
understand and review. They should also enhance "code to" ability so that
code becomes a natural by-product of design

Object-Oriented Design
In the object-oriented design method, the system is viewed as a collection of
objects (i.e., entities). The state is distributed among the objects, and each
object handles its state data. For example, in a Library Automation Software,
each library representative may be a separate object with its data and
functions to operate on these data. The tasks defined for one purpose cannot
refer or change data of other objects. Objects have their internal data which
represent their state. Similar objects create a class. In other words, each object
is a member of some class. Classes may inherit features from the superclass.

The different terms related to object design are:

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.