Unit 3 - Software Architecture and Design

3.1 Introduction to Software Design

Software Design is the process to transform the user requirements into some suitable form, which helps the
programmer in software coding and implementation. During the software design phase, the design document is
produced, based on the customer requirements as documented in the SRS document. Hence the aim of this phase
is to transform the SRS document into the design document.

 Different modules required.

 Control relationships among modules.
 Interface among different modules.
 Data structure among the different modules.
 Algorithms required to implement among the individual modules.

Objectives of Software Design:

1. Correctness:
A good design should be correct i.e. it should correctly implement all the functionalities of the system.
2. Efficiency:
A good software design should address the resources, time, and cost optimization issues.
3. Understandability:
A good design should be easily understandable, for which it should be modular and all the modules are
arranged in layers.
4. Completeness:
The design should have all the components like data structures, modules, and external interfaces, etc.
5. Maintainability:
A good software design should be easily amenable to change whenever a change request is made from the
customer side
Different levels of Software Design:
There are three different levels of software design. They are:

1. Architectural Design:
The architecture of a system can be viewed as the overall structure of the system & the way in which
structure provides conceptual integrity of the system. The architectural design identifies the software as a
system with many components interacting with each other. At this level, the designers get the idea of the
proposed solution domain.

2. Preliminary or high-level design:

Here the problem is decomposed into a set of modules, the control relationship among various modules
identified, and also the interfaces among various modules are identified. The outcome of this stage is called
the program architecture. Design representation techniques used in this stage are structure chart and UML.

3. Detailed design:
Once the high-level design is complete, a detailed design is undertaken. In detailed design, each module is
examined carefully to design the data structure and algorithms. The stage outcome is documented in the form
of a module specification document.

3.2 Role of Software Architecture

A Software Architect provides a solution that the technical team can create and design for the entire application. A
software architect should have expertise in the following areas −
Design Expertise
 Expert in software design, including diverse methods and approaches such as object-oriented design, event-
driven design, etc.
 Lead the development team and coordinate the development efforts for the integrity of the design.
  Should be able to review design proposals and tradeoff among themselves.
Domain Expertise
 Expert on the system being developed and plan for software evolution.
 Assist in the requirement investigation process, assuring completeness and consistency.
 Coordinate the definition of domain model for the system being developed.
Technology Expertise
 Expert on available technologies that helps in the implementation of the system.
 Coordinate the selection of programming language, framework, platforms, databases, etc.

Methodological Expertise
 Expert on software development methodologies that may be adopted during SDLC (Software Development
Life Cycle).
 Choose the appropriate approaches for development that helps the entire team.
Hidden Role of Software Architect
 Facilitates the technical work among team members and reinforcing the trust relationship in the team.
 Information specialist who shares knowledge and has vast experience.
 Protect the team members from external forces that would distract them and bring less value to the project.
Deliverables of the Architect
 A clear, complete, consistent, and achievable set of functional goals
 A functional description of the system, with at least two layers of decomposition
 A concept for the system
 A design in the form of the system, with at least two layers of decomposition
 A notion of the timing, operator attributes, and the implementation and operation plans
 A document or process which ensures functional decomposition is followed, and the form of interfaces is
controlled

Quality Attributes
Quality is a measure of excellence or the state of being free from deficiencies or defects. Quality attributes are the
system properties that are separate from the functionality of the system.
Implementing quality attributes makes it easier to differentiate a good system from a bad one. Attributes are overall
factors that affect runtime behavior, system design, and user experience.
They can be classified as −
Static Quality Attributes
Reflect the structure of a system and organization, directly related to architecture, design, and source code. They are
invisible to end-user, but affect the development and maintenance cost, e.g.: modularity, testability, maintainability,
etc.
Dynamic Quality Attributes
Reflect the behavior of the system during its execution. They are directly related to system’s architecture, design,
source code, configuration, deployment parameters, environment, and platform.
They are visible to the end-user and exist at runtime, e.g. throughput, robustness, scalability, etc.

3.4 Component & Connector 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.
In a diagram representing a C&C architecture view of a system, it is highly desirable to have a different
representation for different component types, so the different types can be identified visually. In a box-and-line
diagram, often all components are represented as rectangular boxes. Such an approach will require that types of the
components are described separately

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.

3.5 Design Concepts: Design Principles:

1. Should not suffer from “Tunnel Vision” –
While designing the process, it should not suffer from “tunnel vision” which means that is should not only
focus on completing or achieving the aim but on other effects also.
2. Traceable to analysis model –
The design process should be traceable to the analysis model which means it should satisfy all the
requirements that software requires to develop a high-quality product.

3. Should not “Reinvent The Wheel” –

The design process should not reinvent the wheel that means it should not waste time or effort in creating
things that already exist. Due to this, the overall development will get increased.

4. Minimize Intellectual distance –

The design process should reduce the gap between real-world problems and software solutions for that
problem meaning it should simply minimize intellectual distance.

5. Exhibit uniformity and integration –

The design should display uniformity which means it should be uniform throughout the process without any
change. Integration means it should mix or combine all parts of software i.e. subsystems into one system.

6. Accommodate change –
The software should be designed in such a way that it accommodates the change implying that the software
should adjust to the change that is required to be done as per the user’s need.

7. Degrade gently –
The software should be designed in such a way that it degrades gracefully which means it should work
properly even if an error occurs during the execution.

8. Assessed or quality –
The design should be assessed or evaluated for the quality meaning that during the evaluation, the quality of
the design needs to be checked and focused on.

9. Review to discover errors –

The design should be reviewed which means that the overall evaluation should be done to check if there is
any error present or if it can be minimized.

10. Design is not coding and coding is not design –

Design means describing the logic of the program to solve any problem and coding is a type of language that
is used for the implementation of a design.
3.6 Difference between conceptual design and technical design :

Conceptual Design Technical Design

Conceptual design is an initial/starting phase in the A Technical design is a phase in which the event team
process of planning, during which the broad outlines of writes the code and describes the minute detail of either
function and sort of something are coupled. the whole design or some parts of it.

It is written in the customer’s language and designed It describes any other thing that converts the
according to the client’s requirements. requirements into a solution to the customer’s problem.

It describes that what will happen to the data in the

It describes the functions or methods of the system.
system.

It shows the conceptual model i.e, what should a system

It shows the data flow and the structure of the data.
look like.
It also includes the process and sub-processes besides It includes the functioning and working of the
the strategies. conceptual design.

It starts when a system requirement comes and the phase

It starts after setting the system requirements.
looks for a potential solution.

At the end of this phase, the solutions to the problems At the end of this phase, and after analyzing the
are sent for review. technical design, the specification is initiated.

3.7 Cohesion:
Cohesion is the indication of the relationship within the module. It is the concept of intra-module. Cohesion has
many types but usually, high cohesion is good for software.
Coupling:
Coupling is also the indication of the relationships between modules. It is the concept of the Inter-module. The
coupling has also many types but usually, the low coupling is good for software.

3.8 Open/Closed Principle(OCP) –

The Open/Closed Principle (OCP) is a fundamental principle in software engineering that aims to improve the
design and maintainability of software systems. It states that software entities (such as classes, modules, and
functions) should be open for extension but closed for modification.

In other words, once a software entity (such as a class) is defined and implemented, it should be possible to extend
its behavior without modifying its source code. This can be achieved by using inheritance, interfaces, or other
techniques that allow new functionality to be added to a software entity without changing its existing
implementation.

The OCP promotes a modular and flexible design approach, which enables software systems to evolve over time
without breaking existing functionality. By designing software entities that are open for extension but closed for
modification, developers can reduce the risk of introducing bugs or unintended side effects when making changes to
existing code. Additionally, this principle can help to improve the maintainability and scalability of software
systems, as it encourages the use of loosely coupled components that can be easily modified or replaced without
affecting the rest of the system.
3.10 Function Oriented Design :
Function oriented design is the result of focusing attention to the function of the program. This is based on the
stepwise refinement. Stepwise refinement is based on the iterative procedural decomposition. Stepwise
refinement is a top-down strategy where a program is refined as a hierarchy of increasing levels of details.
We start with a high level description of what the program does. Then, in each step, we take one part of our high
level description and refine it. Refinement is actually a process of elaboration. The process should proceed from a
highly conceptual model to lower level details. The refinement of each module is done until we reach the
statement level of our programming language.

3.11 Object Oriented Design :

Object oriented design is the result of focusing attention not on the function performed by the program, but
instead on the data that are to be manipulated by the program. Thus, it is orthogonal to function -oriented design.
Object-oriented design begins with an examination of the real world “things”. These things are characteristics
individually in terms of their attributes and behavior.
Objects are independent entities that may readily be changed because all state and representation information is
held within the object itself. Object may be distributed and may execute sequentially or in parallel.

COMPARISON
FACTORS FUNCTION ORIENTED DESIGN OBJECT ORIENTED DESIGN

The basic abstractions, which are The basic abstractions are not the real world
Abstraction given to the user, are real world functions but are the data abstraction where the
functions. real world entities are represented.

Functions are grouped together by Function are grouped together on the basis of the
Function which a higher level function is data they operate since the classes are associated
obtained. with their methods.

carried out using structured analysis

execute and structured design i.e, data flow Carried out using UML
diagram

In this approach the state information is not

In this approach the state information
State represented in a centralized memory but is
is often represented in a centralized
information implemented or distributed among the objects of
shared memory.
the system.

Approach It is a top down approach. It is a bottom up approach.

Begins by considering the use case

Begins basis Begins by identifying objects and classes.
diagrams and the scenarios.

In function oriented design we

Decompose decompose in function/procedure We decompose in class level.
level.

This approach is mainly used for This approach is mainly used for evolving
Use
computation sensitive application. system which mimics a business or business
 COMPARISON
FACTORS FUNCTION ORIENTED DESIGN OBJECT ORIENTED DESIGN

case.

3.12 High Level Design :

High Level Design in short HLD is the general system design means it refers to the overall system design. It
describes the overall description/architecture of the application. It includes the description of system architecture,
data base design, brief description on systems, services, platforms and relationship among modules. It is also
known as macro level/system design. It is created by solution architect. It converts the Business/client
requirement into High Level Solution. It is created first means before Low Level Design.

3.13 Detailed Design (Low Level Design):

Low Level Design in short LLD is like detailing HLD means it refers to component-level design process. It
describes detailed description of each and every module means it includes actual logic for every system
component and it goes deep into each modules specification. It is also known as micro level/detailed design. It is
created by designers and developers. It converts the High Level Solution into Detailed solution. It is created
second means after High Level Design.

S.No. HIGH LEVEL DESIGN LOW LEVEL DESIGN

High Level Design is the general system design Low Level Design is like detailing HLD means
01.
means it refers to the overall system design. it refers to component-level design process.

02. High Level Design in short called as HLD. Low Level Design in short called as LLD.

03. It is also known as macro level/system design. It is also known as micro level/detailed design.

It describes the overall description/architecture of the It describes detailed description of each and
04.
application. every module.

High Level Design expresses the brief functionality Low Level Design expresses details functional
05.
of each module. logic of the module.

06. It is created by solution architect. It is created by designers and developers.

Here in Low Level Design participants are

Here in High Level Design the participants are
07. design team, Operation Teams, and
design team, review team, and client team.
Implementers.

It is created second means after High Level

08. It is created first means before Low Level Design.
Design.

09. In HLD the input criteria is Software Requirement In LLD the input criteria is reviewed High Level
S.No. HIGH LEVEL DESIGN LOW LEVEL DESIGN

Specification (SRS). Design (HLD).

High Level Solution converts the Business/client Low Level Design converts the High Level
10.
requirement into High Level Solution. Solution into Detailed solution.

In HLD the output criteria is data base design, In LLD the output criteria is program
11.
functional design and review record. specification and unit test plan.

3.14 Verification

As mentioned, verification is the process of determining if the software in question is designed and
developed according to specified requirements. Specifications act as inputs for the software development process.
The code for any software application is written based on the specifications document.

Verification is done to check if the software being developed has adhered to these specifications at every stage of the
development life cycle. The verification ensures that the code logic is in line with specifications.

Depending on the complexity and scope of the software application, the software testing team uses different
methods of verification, including inspection, code reviews, technical reviews, and walkthroughs. Software testing
teams may also use mathematical models and calculations to make predictive statements about the software and
verify its code logic.

The main advantages of the verification are:

1. It acts as a quality gateway at every stage of the software development process.

2. It enables software teams to develop products that meet design specifications and customer needs.

3. It saves time by detecting the defects at the early stage of software development.

4. It reduces or eliminates defects that may arise at the later stage of the software development process.

3.15 Metrics:
A software metric is a measure of software characteristics which are measurable or countable. Software metrics are
valuable for many reasons, including measuring software performance, planning work items, measuring
productivity, and many other uses.
Within the software development process, many metrics are that are all connected. Software metrics are similar to
the four functions of management: Planning, Organization, Control, or Improvement.

Software metrics can be classified into two types as follows:

1. Product Metrics: These are the measures of various characteristics of the software product. The two important
software characteristics are:
1. Size and complexity of software.
2. Quality and reliability of software.
These metrics can be computed for different stages of SDLC.
2. Process Metrics: These are the measures of various characteristics of the software development process. For
example, the efficiency of fault detection. They are used to measure the characteristics of methods, techniques, and
tools that are used for developing software.
Advantage of Software Metrics
 Comparative study of various design methodology of software systems.
 For analysis, comparison, and critical study of different programming language concerning their
characteristics.
 In comparing and evaluating the capabilities and productivity of people involved in software development.
 In the preparation of software quality specifications.
 In the verification of compliance of software systems requirements and specifications.
 In making inference about the effort to be put in the design and development of the software systems.
 In getting an idea about the complexity of the code.
 In taking decisions regarding further division of a complex module is to be done or not.
 In guiding resource manager for their proper utilization.
 In comparison and making design tradeoffs between software development and maintenance cost.
 In providing feedback to software managers about the progress and quality during various phases of the
software development life cycle.
 In the allocation of testing resources for testing the code.
Disadvantage of Software Metrics
 The application of software metrics is not always easy, and in some cases, it is difficult and costly.
 The verification and justification of software metrics are based on historical/empirical data whose validity
is difficult to verify.
 These are useful for managing software products but not for evaluating the performance of the technical
staff.
 The definition and derivation of Software metrics are usually based on assuming which are not
standardized and may depend upon tools available and working environment.
 Most of the predictive models rely on estimates of certain variables which are often not known precisely.