i
About the Tutorial
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.
By the end of this tutorial, the readers will develop a sound understanding of the
concepts of software architecture and design concepts and will be in a position to
choose and follow the right model for a given software project.
Audience
This tutorial is designed for all software professionals, architects, and senior
system design engineers. Managers of architecture teams also will be benefited
from this tutorial.
Prerequisites
There is no exact prerequisite for this tutorial. Any software professional can go
through this tutorial to get a bigger picture of how high quality software
applications and products are designed.
Copyright & Disclaimer
© Copyright 2015 by Tutorials Point (I) Pvt. Ltd.
All the content and graphics published in this e-book are the property of Tutorials
Point (I) Pvt. Ltd. The user of this e-book is prohibited to reuse, retain, copy,
distribute or republish any contents or a part of the contents of this e-book in any
manner without written consent of the publisher.
We strive to update the contents of our website and tutorials as timely and as
precisely as possible, however, the contents may contain inaccuracies or errors.
Tutorials Point (I) Pvt. Ltd. provides no guarantee regarding the accuracy,
timeliness, or completeness of our website or its contents including this tutorial.
If you discover any errors on our website or in this tutorial, please notify us at
[email protected]
i
Software Architecture and Design
Table of Contents
About the Tutorial .................................................................................................................................... i
Audience .................................................................................................................................................. i
Prerequisites ............................................................................................................................................ i
Copyright & Disclaimer ............................................................................................................................. i
Table of Contents .................................................................................................................................... ii
1.
INTRODUCTION ................................................................................................................... 1
Software Architecture ............................................................................................................................. 1
Software Design ...................................................................................................................................... 2
Goals of Architecture .............................................................................................................................. 3
Limitations .............................................................................................................................................. 3
Role of Software Architect ...................................................................................................................... 3
Quality Attributes ................................................................................................................................... 5
Quality Scenarios .................................................................................................................................... 5
Common Quality Attributes ................................................................................................................... 6
2.
KEY PRINCIPLES ................................................................................................................... 8
Architectural Style ................................................................................................................................... 8
Common Architectural Design ................................................................................................................. 8
Types of Architecture .............................................................................................................................. 9
Architecture Design Process .................................................................................................................. 10
Key Architecture Principles ................................................................................................................... 12
Key Design Principles ............................................................................................................................ 12
3.
ARCHITECTURE MODELS ................................................................................................... 15
UML ...................................................................................................................................................... 15
Structural Diagrams .............................................................................................................................. 16
Behavioral Diagrams ............................................................................................................................. 17
Architecture View Model ...................................................................................................................... 18
4+1 View Model .................................................................................................................................... 18
ii
Software Architecture and Design
Architecture Description Languages (ADLs) ........................................................................................... 20
4.
OBJECT-ORIENTED PARADIGM .......................................................................................... 21
Development of OO .............................................................................................................................. 21
Introduction to OO Paradigm ................................................................................................................ 21
Object ................................................................................................................................................... 21
Class ...................................................................................................................................................... 22
Encapsulation ....................................................................................................................................... 23
Polymorphism....................................................................................................................................... 23
Message Passing ................................................................................................................................... 23
Composition or Aggregation ................................................................................................................. 23
Association ........................................................................................................................................... 24
Inheritance ........................................................................................................................................... 24
OO Analysis ........................................................................................................................................... 24
Object Modeling ................................................................................................................................... 25
Dynamic Modeling ................................................................................................................................ 25
Functional Modeling ............................................................................................................................. 26
Object-Oriented Design ......................................................................................................................... 26
Design Principles................................................................................................................................... 27
5.
DATA FLOW ARCHITECTURE .............................................................................................. 29
Batch Sequential ................................................................................................................................... 29
Pipe and Filter Architecture................................................................................................................... 30
Filter...................................................................................................................................................... 30
Pipe ....................................................................................................................................................... 32
Process Control Architecture ................................................................................................................. 32
Types of Subsystems ............................................................................................................................ 32
Application Areas.................................................................................................................................. 32
6.
DATA-CENTERED ARCHITECTURE ...................................................................................... 34
Types of Components ............................................................................................................................ 34
Repository Architecture Style ................................................................................................................ 35
Blackboard Architecture Style ............................................................................................................... 36
Parts of Blackboard Model ................................................................................................................... 37
7.
HIERARCHICAL ARCHITECTURE .......................................................................................... 39
Main-subroutine ................................................................................................................................... 39
Master-Slave ......................................................................................................................................... 40
iii
Software Architecture and Design
Virtual Machine Architecture ................................................................................................................ 42
Layered Style ......................................................................................................................................... 44
8.
INTERACTION-ORIENTED ARCHITECTURE .......................................................................... 46
Model-View-Controller (MVC) ............................................................................................................... 46
Model ................................................................................................................................................... 46
Controller.............................................................................................................................................. 47
View ...................................................................................................................................................... 47
MVC - I .................................................................................................................................................. 48
MVC - II ................................................................................................................................................. 48
Presentation-Abstraction-Control (PAC) ................................................................................................ 50
PAC with Multiple Agents ..................................................................................................................... 51
9.
DISTRIBUTED ARCHITECTURE ............................................................................................ 53
Concept of Distributed Architecture ...................................................................................................... 53
Basis of Distributed Architecture ........................................................................................................... 54
Client-Server Architecture ..................................................................................................................... 55
Thin-client model .................................................................................................................................. 56
Thick/Fat-client model .......................................................................................................................... 56
Advantages ........................................................................................................................................... 57
Disadvantages....................................................................................................................................... 57
Multi-Tier Architecture (n-tier Architecture) ......................................................................................... 58
Presentation Tier .................................................................................................................................. 58
Application Tier (Business Logic, Logic Tier, or Middle Tier) ................................................................ 58
Data Tier ............................................................................................................................................... 59
Broker Architectural Style ..................................................................................................................... 59
Components of Broker Architectural Style ........................................................................................... 60
Stub....................................................................................................................................................... 60
Skeleton ................................................................................................................................................ 60
Bridge ................................................................................................................................................... 61
Broker implementation in CORBA ........................................................................................................ 61
Service-Oriented Architecture (SOA) ..................................................................................................... 62
Features of SOA .................................................................................................................................... 63
Distributed Deployment: ....................................................................................................... 63
SOA Operation ...................................................................................................................................... 63
10. COMPONENT-BASED ARCHITECTURE ................................................................................ 65
What is a Component? .......................................................................................................................... 65
Views of a Component ......................................................................................................................... 65
Characteristics of Components ............................................................................................................ 66
iv
Software Architecture and Design
Principles of Component−Based Design ................................................................................................ 67
Component-Level Design Guidelines ..................................................................................................... 68
Conducting Component-Level Design .................................................................................................... 69
11. USER INTERFACE ............................................................................................................... 71
Functions and Features of UI ................................................................................................................. 71
Graphical User Interface........................................................................................................................ 71
Design of User Interface ........................................................................................................................ 72
Elements of UI ...................................................................................................................................... 72
Levels of UI Design ................................................................................................................................ 72
Steps of UI Design ................................................................................................................................. 73
User Interface Development Process .................................................................................................... 73
User Interface Models .......................................................................................................................... 74
Design Considerations of User Interface................................................................................................ 75
12. ARCHITECTURE TECHNIQUES ............................................................................................ 77
Iterative and Incremental Approach...................................................................................................... 77
Identify Architecture Goal .................................................................................................................... 77
Key Scenarios ........................................................................................................................................ 77
Application Overview ........................................................................................................................... 78
Key Issues or Key Hotspots ................................................................................................................... 78
Candidate Solutions .............................................................................................................................. 79
Architecture Review .............................................................................................................................. 79
Communicating the Architecture Design ............................................................................................... 80
4 + 1 Model ........................................................................................................................................... 80
Architecture Description Language (ADL) ............................................................................................ 81
Agile Modeling ...................................................................................................................................... 81
IEEE 1471 .............................................................................................................................................. 81
Unified Modeling Language (UML) ....................................................................................................... 81
v
1. INTRODUCTION
Software Architecture and Design
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.
1
Software Architecture and Design
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.
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.
Domain analysis, requirements analysis, and risk analysis comes before
architecture design phase, whereas the detailed design, coding, integration, and
testing phases come after it.
2
Software Architecture and Design
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.
Role of Software Architect
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:
3
Software Architecture and Design
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 or planned 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 help 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 help the entire
team.
Deliverables of the Architect
An architect is expected to deliver clear, complete, consistent, and achievable set
of functional goals to the organization. Besides, he is also responsible to provide:
•
•
•
•
A simplified concept of the system
A design in the form of the system, with at least two layers of
decomposition.
A functional description of the system, with at least two layers of
decomposition.
A notion of the timing, operator attributes, and the implementation and
operation plans.
4
Software Architecture and Design
•
A document or process which ensures functional decomposition is followed,
and the form of interfaces is controlled.
Hidden Role of Software Architect
Besides, facilitating the technical work among team members, it has also some
subtle roles such as reinforce the trust relationship among team members and
protect team members from the external forces that could distract them and bring
less value to the project.
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:
1. 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.
2. 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.
Quality Scenarios
Quality scenarios specify how to prevent a fault from becoming a failure. They can
be divided into six parts based on their attribute specifications:
1. Source: An internal or external entity such as people, hardware, software,
or physical infrastructure that generate the stimulus.
2. Stimulus: A condition that needs to be considered when it arrives on a
system.
3. Environment: The stimulus occurs within certain conditions.
4. Artifact: A whole system or some part of it such as processors,
communication channels, persistent storage, processes etc.
5
Software Architecture and Design
5. Response: An activity undertaken after the arrival of stimulus such as
detect fault, recover from fault, disable event source etc.
6. Response measure: Should measure the occurred responses so that the
requirements can be tested.
Common Quality Attributes
The following table lists the common quality attributes that a software architecture
must have:
Category
Quality
Attribute
Description
Conceptual
Integrity
Maintainability
Reusability
Defines the capability for components and
subsystems to be suitable for use in other
applications.
Ability of a system or different systems to
operate successfully by communicating and
exchanging information with other external
systems written and run by the external parties.
Manageability
Run-time
Qualities
Ability of the system to undergo changes with a
degree of ease.
Interoperability
Design
Qualities
Defines the consistency and coherence of the
overall design. This includes the way,
components or modules are designed.
Defines how easy it is for the system
administrators to manage the application.
Reliability
Ability of a system to remain operational over
period of time.
Scalability
Ability of a system to either handle the load
increase without impacting the performance of
the system or the ability to be readily enlarged.
Security
Capability of a system to prevent malicious or
accidental actions outside of the designed
usages.
Performance
Indication of the responsiveness of a system to
execute any action within a given time interval.
Availability
Defines the proportion of time that the system is
functional and working. It can be measured as a
percentage of the total system downtime over a
predefined period.
6
Software Architecture and Design
System
Qualities
Supportability
Ability of the system to provide information
helpful for identifying and resolving issues when
it fails to work correctly.
Testability
Measure of how easy it is to create test criteria
for the system and its components.
User
Qualities
Usability
Defines how well the application meets the
requirements of the user and consumer by being
intuitive.
Architecture
Quality
Correctness
Accountability for satisfying all the requirements
of the system.
Portability
Ability of the system to run under different
computing environment.
Integrality
Ability to make separately developed
components of the system work correctly
together.
Modifiability
Ease with which each software system can
accommodate changes to its software.
Cost and
schedule
Cost of the system with respect to time to
market, expected project lifetime & utilization of
legacy.
Marketability
Use of a system with respect to the market
competition.
Non-runtime
Quality
Business
quality
attributes
7
2. KEY PRINCIPLES
Software Architecture and Design
Software architecture is described as the organization of a system, where the
system represents a set of components that accomplish the defined functions.
Architectural Style
The architectural style, also called as architectural pattern, is a set of
principles which shapes an application. It defines an abstract framework for a
family of system in terms of the pattern of structural organization.
The architectural style is responsible to:
Provide a lexicon of components and connectors with rules on how they can
be combined.
Improve partitioning and allow the reuse of design by giving solutions to
frequently occurring problems.
Describe a particular way to configure a collection of components (a module
with well-defined interfaces, reusable, and replaceable) and connectors
(communication link between modules).
The software that is built for computer-based systems exhibit one of many
architectural styles. Each style describes a system category that encompasses:
A set of component types which perform a required function by the system.
A set of connectors (subroutine call, remote procedure call, data stream,
and socket) that enable communication, coordination, and cooperation
among different components.
Semantic constraints which define how components can be integrated to
form the system.
A topological layout
interrelationships.
of
the
components
indicating
their
runtime
Common Architectural Design
The following table lists architectural styles that can be organized by their key
focus area:
Category
Architectural
Design
Description
8
Software Architecture and Design
Message bus
Communication
Service–Oriented
Architecture (SOA)
Client/server
Deployment
3-tier or N-tier
Prescribes use of a software system that
can receive and send messages using one
or more communication channels.
Defines the applications that expose and
consume functionality as a service using
contracts and messages.
Separates the system into two
applications, where the client makes
requests to the server.
Separates the functionality into separate
segments with each segment being a tier
located on a physically separate computer.
Focuses on modeling a business domain
and defines business objects based on
entities within the business domain.
Component
Domain
Domain Driven
Design
Breakdowns the application design into
reusable functional or logical components
that exposes well-defined communication
interfaces.
Based
Layered
Divides the concerns of the application into
stacked groups (layers).
Object oriented
Structure
Based on the division of responsibilities of
an application or system into objects, each
containing the data and the behavior
relevant to the object.
Types of Architecture
There are four types of architecture from the viewpoint of an enterprise and
collectively, these architectures are referred to as enterprise architecture.
1. Business architecture: Defines the strategy of business, governance,
organization, and key business processes within an enterprise and focuses
on the analysis and design of business processes.
2. Application (software) architecture: Serves as the blueprint for
individual application systems, their interactions, and their relationships to
the business processes of the organization.
3. Information architecture: Defines the logical and physical data assets
and data management resources.
9
Software Architecture and Design
4. Information technology (IT) architecture: Defines the hardware and
software building blocks that make up the overall information system of the
organization.
Architecture Design Process
The architecture design process focuses on the decomposition of a system into
different components and their interactions to satisfy functional and nonfunctional
requirements. The key inputs to software architecture design are:
•
The requirements produced by the analysis tasks.
•
The hardware architecture (the software architect in turn provides
requirements to the system architect, who configures the hardware
architecture).
The result or output of the architecture design process is an architectural
description. The basic architecture design process that involves the following
steps:
Understand the Problem
This is the most crucial step because it affects the quality of the design that
follows. Without a clear understanding of the problem, it is not possible to create
an effective solution. In fact, many software projects and products are considered
as unsuccessful because they did not actually solve a valid business problem or
have a recognizable return on investment (ROI).
Identify Design Elements and their Relationships
In this phase, build a baseline for defining the boundaries and context of the
system. Decomposition of the system into its main components is based on the
functional requirements. The decomposition can be modeled by using a design
structure matrix (DSM), which shows the dependencies between design elements
without specifying the granularity of the elements.
In this step, the first validation of the architecture is done by describing a number
of system instances and this step is referred as functionality based architectural
design.
10
Software Architecture and Design
Architecture Design Process
1. Understand the Problem
2. Evaluate the Architecture Design
3. Transorm the Architecture Design
Evaluate the Architecture Design
Each quality attribute is given an estimate, so in order to gather qualitative
measures or quantitative data, the design is evaluated. It involves evaluating the
architecture for conformance to architectural quality attributes requirements.
If all the estimated quality attributes are as per the required standard, the
architectural design process is finished. If not, then the third phase of software
architecture design is entered: architecture transformation. However, if the
observed quality attribute does not meet its requirements, then a new design must
be created.
Transform the Architecture Design
This step is performed after an evaluation of the architectural design. The
architectural design must be changed until it completely satisfies the quality
attribute requirements. It is concerned with selecting design solutions to improve
the quality attributes while preserving the domain functionality.
Further, a design is transformed by applying design operators, styles, or patterns.
For transformation, take the existing design and apply design operator such as
decomposition, replication, compression, abstraction, and resource sharing.
Moreover, the design is again evaluated and the same process is repeated multiple
times if necessary and even performed recursively. The transformations (i.e.
quality attribute optimizing solutions) generally improve one or some quality
attributes while they affect others negatively.
11
Software Architecture and Design
Key Architecture Principles
Following are the key principles to be considered while designing an architecture:
Build to Change Instead of Building to Last
Consider how the application may need to change over time to address new
requirements and challenges, and build in the flexibility to support this.
Reduce Risk, and Model to Analyze
Use design tools, visualizations, modeling systems such as UML to capture
requirements and design decisions. The impacts can also be analyzed. Do not
formalize the model to the extent that it suppresses the capability to iterate and
adapt the design easily.
Use Models and Visualizations as a Communication and Collaboration
Tool
Efficient communication of the design, the decisions, and ongoing changes to the
design is critical to good architecture. Use models, views, and other visualizations
of the architecture to communicate and share the design efficiently with all the
stakeholders. This enables rapid communication of changes to the design.
Identify and understand key engineering decisions and areas where mistakes are
most often made. Invest in getting key decisions right the first time to make the
design more flexible and less likely to be broken by changes.
Use an Incremental and Iterative Approach
Start with baseline architecture and then evolve candidate architectures by
iterative testing to improve the architecture. Iteratively, add details to the design
over multiple passes to get the big or right picture and then focus on the details.
Key Design Principles
Following are the design principles to be considered for minimizing cost,
maintenance requirements, and maximizing extendibility, usability of
architecture:
Separation of Concerns
Divide the components of system into specific features so that there is no
overlapping among the components functionality. This will provide high cohesion
and low coupling. This approach avoids the interdependency among components
of system which helps in maintaining the system easy.
Single Responsibility Principle
12
Software Architecture and Design
Each and every module of a system should have one specific responsibility, which
helps the user to clearly understand the system. It should also help with
integration of the component with other components.
Principle of Least Knowledge
Any component or object should not have the knowledge about internal details of
other components. This approach avoids interdependency and helps
maintainability.
Minimize Large Design Upfront
Minimize large design upfront if the requirements of an application are unclear. If
there is a possibility of modifying requirements, then avoid making a large design
for whole system.
Do not Repeat the Functionality
It specifies that functionality of the components should not to be repeated and
hence a piece of code should be implemented in one component only. Duplication
of functionality within a single application can make it difficult to implement
changes, decrease clarity, and introduce potential inconsistencies.
Prefer Composition over Inheritance while Reusing the Functionality
Inheritance creates dependency between children and parent classes and hence it
blocks the free use of the child classes. In contrast, the composition provides a
great level of freedom and reduces the inheritance hierarchies.
Identify Components and Group them in Logical Layers
Identity components and the area of concern that are needed in system to satisfy
the requirements. Then group these related components in a logical layer, which
will help the user to understand the structure of the system at a high level. Avoid
mixing components of different type of concerns in same layer.
Define the Communication Protocol between Layers
Understand how components will communicate with each other which requires a
complete knowledge of deployment scenarios and the production environment.
Define Data Format for a Layer
Various components will interact with each other through data format. Do not mix
the data formats so that applications are easy to implement, extend, and maintain.
Try to keep data format same for a layer, so that various components need not
code/decode the data while communicating with each other. It reduces a
processing overhead.
System Service Components should be Abstract
13
Software Architecture and Design
Code related to security, communications, or system services like logging,
profiling, and configuration should be abstracted in the separate components. Do
not mix this code with business logic, as it is easy to extend design and maintain
it.
Design Exceptions and Exception Handling Mechanism
Defining exceptions in advance, helps the components to manage errors or
unwanted situation in an elegant manner. The exception management will be
same throughout the system.
Naming Conventions
Naming conventions should be defined in advance. They provide a consistent
model that helps the users to understand the system easily. It is easier for team
members to validate code written by others, and hence will increase the
maintainability.
14
.PDF 
87 
232 
115 
