UNIT-3

Software Design and Architecture

Software Design (or) Design process:
Software design is a mechanism to transform user requirements into some suitable form, which
helps the programmer in software coding and implementation. It deals with representing the
client's requirement, as described in SRS (Software Requirement Specification) document, into a
form, i.e., easily implementable using programming language.
The software design phase is the first step in SDLC (Software Design Life Cycle), which moves
the concentration from the problem domain to the solution domain. In software design, we
consider the system to be a set of components or modules with clearly defined behaviors &
boundaries.
Software Design Levels:- Software design yields three levels of results:
 Architectural Design - The architectural design is the highest abstract version of the system. It

identifies the software as a system with many components interacting with each other. At this
level, the designers get the idea of proposed solution domain.
 High-level Design- The high-level design breaks the ‘single entity-multiple component’ concept

of architectural design into less-abstracted view of sub-systems and modules and depicts their
interaction with each other. High-level design focuses on how the system along with all of its
components can be implemented in forms of modules. It recognizes modular structure of each sub-
system and their relation and interaction among each other.
 Detailed Design- Detailed design deals with the implementation part of what is seen as a system

and its sub-systems in the previous two designs. It is more detailed towards modules and their
implementations. It defines logical structure of each module and their interfaces to communicate
with other modules.
Objectives of Software Design
Following are the purposes of Software design:

1. Correctness: Software design should be correct as per requirement.

2. Completeness: The design should have all components like data structures, modules, and
external interfaces, etc.
3. Efficiency: Resources should be used efficiently by the program.
4. Flexibility: Able to modify on changing needs.
5. Consistency: There should not be any inconsistency in the design.
6. Maintainability: The design should be so simple so that it can be easily maintainable by other
designers.
***************
Principles Leading to Good Design:
Many principles are employed to organize, coordinate, classify, and set up software design’s
structural components. Software Designs become some of the most convenient designs when the
following principles are applied. They help to generate remarkable User Experiences and
customer loyalty.
The principles of a good software design are:
1. Modularity
2. Coupling
3. Abstraction
4. Anticipation of change
5. Simplicity
6. Sufficiency and completeness
Modularity:-Dividing a large software project into smaller portions/modules is known as
modularity. It is the key to scalable and maintainable software design. The project is divided into
various components and work on one component is done at once. It becomes easy to test each
component due to modularity. It also makes integrating new features more accessible.
Advantages of Modularity:
o It allows large programs to be written by several or different people.

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

1. Coupling:- Coupling refers to the extent of interdependence between software modules and
how closely two modules are connected. Low coupling is a feature of good design. With low
coupling, changes can be made in each module individually, without changing the other modules.
Coupling: It measures the relative interdependence among modules.
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.
Cohesion: It measures the relative function strength of a 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."
 Coupling Cohesion

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

Binding.
Coupling shows the relationships betweenmodules. Cohesion shows the relationship withinthe
module.
Coupling shows the Cohesion shows the module's
relative independence between the modules. relative functional
strength.
While creating, you should aim for low coupling, i.e.,
While creating you should aim for high cohesion,
dependency among modules should be less. i.e., a cohesive component/ module focuses on a
single function (i.e., single-mindedness) with little
interaction with other modules of the system.
In coupling, modules are linked to the othermodules. In cohesion, the module focuses on asingle thing.

2. Abstraction:- The process of identifying the essential behavior by separating it from its
implementation and removing irrelevant details is known as Abstraction. The inability to separate
essential behavior from its implementation will lead to unnecessary coupling.
3. Anticipation of Change:- The demands of software keep on changing, resulting in
continuous changes in requirements as well. Building a good software design consists of its
ability to accommodate and adjust to change comfortably.
4. Simplicity:- The aim of good software design is simplicity. Each task has its own module,
which can be utilized and modified independently. It makes the code easy to use and minimizes
the number of setbacks.
5. Sufficiency and Completeness:- A good software design ensures the sufficiency and
completeness of the software concerning the established requirements. It makes sure
that the software has been adequately and wholly built.
****************
TECHNIQUES FOR MAKING GOOD DESIGN DECISIONS
Using priorities and objectives to decide among alternatives
 Step 1: List and describe the alternatives for the design decision.
 Step 2: List the advantages and disadvantages of each alternative with respect to your
objectives and priorities.
 Step 3: Determine whether any of the alternatives prevents you from meeting one or more of
the objectives.
  Step 4 : Choose the alternative that helps you to best meet your objectives.
 Step 5: Adjust priorities for subsequent decision making.
Example priorities and objectives:
Imagine a system has the following objectives, starting with top priority:
 Security: Encryption must not be breakable within 100 hours of computing time ona 400Mhz
Intel processor, using known cryptanalysis techniques.
 Maintainability: No specific objective.
 CPU efficiency: Must respond to the user within one second when running on a400 MHz intel
processor.
 Network bandwidth efficiency: Must not require transmission of more than 8KB of data per
transaction.
 Memory efficiency: Must not consume over 20MB of RAM.
 Portability: Must be able to run on Windows 98,NT 4 and ME as well as Linux.
Using cost-benefit analysis to choose among alternatives
 To estimate the costs add up:
The incremental cost of doing the software engineering work, including ongoing maintenance.
The incremental costs of any development technology required.
The incremental costs that end-users and product support personnel will experience.
 To estimate the benefits, add up:
The incremental software engineering time saved.
The incremental benefits measured in terms of either increased sales or else financial benefit to
users.
**************
WRITING A GOOD DESIGN DOCUMENT
Design document is an aid to make better designs.
 They force you to be explicit and consider the important issues before starting
implementation.
 They allow a group of people to review the design and therefore to improve it.
 Design documents as a means of communication. To those who will be implementing the
design.
To those who will need, in the future, to modify the design.
To those who need to create systems or subsystems that interface with the system being
designed.
Structure of design document:
A. Purpose: What system or part of the system this design document describes. Make reference
 to the requirements that are being implemented by this design.
B. General priorities: Describe the priorities used to guide the design process.
C. Outline of the design: Give a high level description of the design that allows the reader to
quickly get a general feeling for it.
D. Major design issues: Discuss the important issues that had to be resolved.
E. Other details of the design: Give any other details the reader may want to know that have
not yet been mentioned.
***************
SOFTWARE ARCHITECTURE
Software Architecture typically refers to the bigger structures of a software system, and it deals
with how multiple software processes cooperate to carry out their tasks. Software Design refers to
the smaller structures and it deals with the internal design of a single software process.
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.
1. It defines a structured solution to meet all the technical and operational requirements, while
optimizing the common quality attributes like performance and security.
2. 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 –
1. Selection of structural elements and their interfaces by which the system is composed.
 2. Behavior as specified in collaborations among those elements.
3. Composition of these structural and behavioral elements into large subsystem.
4. Architectural decisions align with business objectives.
5. 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 −
1. To negotiate system requirements, and to set expectations with customers, marketing, and
management personnel.
2. Act as a blueprint during the development process.
3. 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 −
1. Expose the structure of the system, but hide its implementation details.
2. Realize all the use-cases and scenarios.
3. Try to address the requirements of various stakeholders.
4. Handle both functional and quality requirements.
5. Reduce the goal of ownership and improve the organization’s market position.
6. Improve quality and functionality offered by the system.
7. Improve external confidence in either the organization or system.
 Limitations:
1. Lack of tools and standardized ways to represent architecture.
2. Lack of analysis methods to predict whether architecture will result in an implementation
that meets the requirements.
3. Lack of awareness of the importance of architectural design to software development.
4. Lack of understanding of the role of software architect and poor communication among
stakeholders.
5. Lack of understanding of the design process, design experience and evaluation of design.
****************
ARCHITECTURAL PATTERNS
The architectural pattern shows how a solution can be used to solve a reoccurring problem. In
another word, it reflects how a code or components interact with each other. Moreover, the
architectural pattern is describing the architectural style of our system and provides solutions for
the issues in our architectural style. Personally, I prefer to define architectural patterns as a way
to implement our architectural style.
1. MULTI-LAYER ARCHITECTURAL PATTERNS:
The layered pattern is probably one of the most well-known software architecture patterns. Many
developers use it, without really knowing its name. The idea is to split up your code into “layers”,
where each layer has a certain responsibility and provides a service to a higher layer.
There isn’t a predefined number of layers, but these are the ones you see most often:
1. Presentation or UI layer
2. Application layer
3. Business or domain layer
4. Persistence or data access layer
5. Database layer
The idea is that the user initiates a piece of code in the presentation layer by performing some
action (e.g. clicking a button). The presentation layer then calls the underlying layer,
i.e. the application layer. Then we go into the business layer and finally, the persistence layer
stores everything in the database. So higher layers are dependent upon and make calls to the lower
layers.
You will see variations of this, depending on the complexity of the applications. Some applications
might omit the application layer, while others add a caching layer. It’s even possible to merge two
layers into one.
Advantages
 Most developers are familiar with this pattern.

 It provides an easy way of writing a well-organized and testable application.

Disadvantages
 It tends to lead to monolithic applications that are hard to split up afterward.

 Developers often find themselves writing a lot of code to pass through the different layers,

without adding any value in these layers. If all you are doing is writing a simple CRUD
application, the layered pattern might be overkill for you.
2.THE CLIENT-SERVER PATTERN:
A Client-Server Architecture consists of two types of components: clients and servers. A server
component perpetually listens for requests from client components. When a request is received, the
server processes the request, and then sends a response back to the client. Servers may be further
classified as stateless or stateful. Clients of a stateful server may make composite requests that
consist of multiple atomic requests. This enables a more conversational or transactional
interactions between client and server. To accomplish this, a stateful server keeps a record of the
requests from each current client. This record is called a session.
In order to simultaneously process requests from multiple clients, a server often uses the Master-
Slave Pattern. In this case the Master perpetually listens for client requests. When a request is
received, the master creates a slave to processes the request, and then resumes listening.
Meanwhile, the slave performs all subsequent communication with the client.
Here is a simple component diagram showing a server component that implements operations
specified in a Services interface, and a client component that depends on these services.
3. THE BROKER ARCHITECTURAL PATTERN:
Transparently distribute aspects of the software system to different nodes.
1. An object can call method of another object without knowing that thisobject is remotely
located.
2. COBRA is a well known open standard that allows you to build this kind ofarchitecture.

4. THE TRANSACTION- PROCESSING ARCHITECTURAL PATTERN:

A process reads a series of inputs one by one.
1. Each input describes a transaction- a command that typically some change to the data stored
by the system.
2. There is a transaction dispatcher component that decides what to do witheach transaction.
3. This dispatches a procedure call or message to one of a series of component that will handle
the transaction.

THE PIPE AND FILTER ARCHITECTURAL PATTERN:

A stream of data , in a relatively simple format, is passed through a series of processes
1.Each of which transforms it in some way.
2.Data is constantly fed into the pipeline.
3.The processes work concurrently.
4.The architecture is very flexible.
 - Almost all the components could be removed.
- Components could be replaced.
- New components could be inserted.
- Certain components could be reordered.

5. THE MODEL-VIEW-CONTROLLER(MVC) ARCHITECTURAL PATTERN:

An architectural pattern used to separate the user interface layer from other parts of the system.
1. The model contains the underlying classes whose instances are to be viewedand manipulated.
2. The view contains objects used to render the appearance of the data fromthe model in the
user interface.
3. The controller contains the objects that control and handle the users interaction with the view
and the model.
4. The observable design pattern is normally used to separate the model fromthe view.
Advantages
 Multiple developers can work simultaneously on the model, controller and views.
 MVC enables logical grouping of related actions on a controller together. The views for a
specific model are also grouped together.
 Models can have multiple views.

Design Patterns
Design patterns are used to represent some of the best practices adapted by experienced object-
oriented software developers. A design pattern systematically names, motivates, and explains a
general design that addresses a recurring design problem in object-oriented systems. It describes
the problem, the solution, when to apply the solution, and its consequences. It also gives
 implementation hints and examples.
Usage of Design Pattern
Design Patterns have two main usages in software development.
Common platform for developers
Design patterns provide a standard terminology and are specific to particular scenario. For
example, a singleton design pattern signifies use of single object so all developers familiar with
single design pattern will make use of single object and they can tell each other that program is
following a singleton pattern.
Best Practices
Design patterns have been evolved over a long period of time and they provide best solutions to
certain problems faced during software development. Learning these patterns helps unexperienced
developers to learn software design in an easy and faster way.
Types of Design Patterns
As per the design pattern reference book Design Patterns - Elements of Reusable Object-
Oriented Software , there are 23 design patterns which can be classified in three categories:
Creational, Structural and Behavioral patterns. We'll also discuss another category of design
pattern: J2EE design patterns.

S.N. Pattern & Description

1 Creational Patterns
These design patterns provide a way to create objects while hiding the creation logic, rather than
instantiating objects directly using new operator. This gives program moreflexibility in deciding which
objects need to be created for a given use case.

2 Structural Patterns
These design patterns concern class and object composition. Concept of inheritance isused to compose
interfaces and define ways to compose objects to obtain new functionalities.

3 Behavioral Patterns
These design patterns are specifically concerned with communication between objects.

4 J2EE Patterns
These design patterns are specifically concerned with the presentation tier. These patterns are identified
by Sun Java Center.
1. THE ABSTRACTION-OCCURRENCE PATTERN
• Context:
1. Often in a domain model you find a set of related objects(occurrences).
2. The members of such a set share common information
3. But also differ from each other in important ways.
• Problem:
1.What is the best way to represent such sets of occurrences in a classdiagram?
• Forces:
1. You want to represent the members of each set of occurrences without duplicating the common
information
 Solution:
Create an <Abstraction> class that contains the data that is common to all the members of
a set of occurrences. Then create an
<<occurrence>> class representing the occurrences of this abstraction. Connect these classes with
a one-to-many association.

Antipatterns: Solutions that are inferior or do not work in this context.

Square variant or related Patterns: patterns that are similar to this pattern.

Refereneces: This pattern is a generalization of the Title-Item pattern of Eriksson and Penker.
2. THE GENERAL HIERARCHY PATTERN
• Context:
1.Objects in a hierarchy can have one or more objects above them(superiors), and one or more
objects below them (subordinates).
2. Some objects cannot have any subordinates.
• Problem:
1.How do you represent a hierarchy of objects, in which some objects cannot have subordinates?
• Forces:
1.You want a flexible way of representing the hierarchy that prevents certain objects from having
subordinates.
2.All the objects have many common properties and operations.
• Solution:
 Antipattern:

References: The composite pattern is one of the ‘Gang of Four ‘ Patterns.

3. THE PLAYER-ROLE PATTERN
• Context:
1.A role is a particular set of properties associated with an object in aparticular context.
2. An object may play different roles in different contexts.
• Problem:
1.How do you best model players and roles so that a player canchange roles or possess multiple
roles?
• Forces:
1.It is desirable to improve encapsulation by capturing the informationassociated with each
separate role in a class.
2.You want to avoid multiple inheritance.
3. You cannot allow an instance to change class.
• Solution:
Example:

 Antipatterns:

• Merge all the properties and behaviours into a single «Player» class and not have «Role»
classes at all.
• Create roles as subclasses of the «Player» class.
4. THE SINGLETON PATTERN
• Context:
— It is very common to find classes for which only one instance shouldexist (singleton)
• Problem:
— How do you ensure that it is never possible to create more than one instance of a singleton
class?
• Forces:
— The use of a public constructor cannot guarantee that no more thanone instance will be
created.
— The singleton instance must also be accessible to all classes that require it
 Solution:

5. THE OBSERVER PATTERN

• Context:
1.When an association is created between two classes, the code for theclasses becomes
inseparable.
2. If you want to reuse one class, then you also have to reuse the other.
• Problem:
1. How do you reduce the interconnection between classes, especially between classes that belong
to different modules or subsystems?
• Forces:
1.You want to maximize the flexibility of the system to thegreatest extent possible
• Solution:
Antipatterns:
• Connect an observer directly to an observable so that they both have references to each other.
• Make the observers subclasses of the observable.
6. THE DELEGATION PATTERN
• Context:
1. You are designing a method in a class
2. You realize that another class has a method which provides therequired service
3.Inheritance is not appropriate
4.E.g. because the isa rule does not apply
• Problem:
1.How can you most effectively make use of a method that already exists in the other class?
• Forces:
1.You want to minimize development cost by reusing methods
• Solution:

Example:

7. THE ADAPTER PATTERN

• Context:
1. You are building an inheritance hierarchy and want to incorporate it into an existing class.
2.The reused class is also often already part of its own inheritance hierarchy.
• Problem:
1.How to obtain the power of polymorphism when reusing a class whose methods have the same
function but not the same signature as the other methods in the hierarchy?
• Forces:
1.You do not have access to multiple inheritance or you do not wantto use it.
• Solution:

Example:

8. THE FAÇADE PATTERN

• Context:
1. Often, an application contains several complex packages.
2.A programmer working with such packages has to manipulate manydifferent classes
• Problem:
1.How do you simplify the view that programmers have of a complexpackage?
• Forces:
1.It is hard for a programmer to understand and use an entiresubsystem
2.If several different application classes call methods of the complex package, then any
modifications made to the package will necessitate a complete review of all these classes.
• Solution:

9. THE IMMUTABLE PATTERN

• Context:
1.An immutable object is an object that has a state that never changesafter creation
• Problem:
1.How do you create a class whose instances are immutable?
• Forces:
1.There must be no loopholes that would allow ‘illegal’ modificationof an immutable object
• Solution:

1.Ensure that the constructor of the immutable class is the only placewhere the values of instance
variables are set or modified.
2.Instance methods which access properties must not have sideeffects.
3.If a method that would otherwise modify an instance variable isrequired, then it has to return a
new instance of the class.
10. THE READ-ONLY INTERFACE PATTERN
• Context:
1.You sometimes want certain privileged classes to be able to modify attributes of objects that are
otherwise immutable
• Problem:
1.How do you create a situation where some classes see a class asread-only whereas others are
able to make modifications?
• Forces:
1.Restricting access by using the public, protected and private keywords is not adequately
selective.
2.Making access public makes it public for both reading and writing
 Solution:

Example:

11.THE PROXY PATTERN

Context:
• Often, it is time-consuming and complicated to create instances of aclass (heavyweight
classes).
• There is a time delay and a complex mechanism involved in creatingthe object in memory
Problem:
• How to reduce the need to create instances of a heavyweight class?
Forces:
• We want all the objects in a domain model to be available forprograms to use when they
execute a system’s various responsibilities.
• It is also important for many objects to persist from run to run of thesame program
Solution:
12.The Factory Pattern:
• Context:
1. A reusable framework needs to create objecs; however the classofthe created objects depends
on the application.
• Problem:
1.How do you enable a programmer to add new application-specificclass into a system built on
such a framework?
• Forces:
1.We want to have the framework create and work with application-specific classes that the
framework does not yet know about.
• Solution:
1.The framework delegates the creation of application-specific classesto a specialized class, the
Factory.
2.The Factory is a generic interface defined in the framework.
3.The factory interface declares a method whose purpose is to createsome subclass of a generic
class.