MODULE 5

System Integration
and Architecture 1

VENUS, HARVEY G.
Instructor
 CHAPTER 5

SOFTWARE ARCHITECTURE
 It refers to the bigger structures of a software system, and it deals with
how multiple software processes cooperate to carry out their tasks.
 It 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 is the primary carrier of system qualities such as performance,
modifiability, and security, none of which can be achieved without a
unifying architectural vision.

FACTORS OF SOFTWARE ARCHITECTURE

 Design
A plan or specification for the construction of an object or system or
for the implementation of an activity or process, or the result of that plan or
specification in the form of a prototype, product or process.
 Quality Attributes
It includes correctness, reliability, adequacy, learnability,
robustness, maintainability, readability, extensibility, testability, efficiency,
portability.
  IT Environment
An integrated collection of technology components that serves the
needs of its users and the owner of the resulting system.
 Human Dynamics
A team-oriented activity involving engineers, developers, business
analysts, domain experts, data/infrastructure architects, projects
managers etc.
 Business Strategy
It refers to the actions and decisions that a company takes to reach
its business goals and be competitive in its industry.

SOFTWARE DESIGN
 It 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.

Requirement
desired Hardware
Quality Architecture
Domain Analysis
Software Architecture Hardware Architecture
Requirement analysis
Design Design
Risk Analysis

Modification to Requirement Modification to H/W

Architecture

Implementation Constraint

Detailed design,
Coding, integration,
Testing
GOALS OF ARCHITECTURE
 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 OF SOFTWARE ARCHITECTURE

 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 design process, design experience and
evaluation of design.

ROLES OF SOFTWARE ARCHITECT

 Design Expertise
 Expert in software design, including diverse methods and approaches
such as object-oriented design, event-driven design, etc.
 Domain Expertise
 Expert on the system being developed and plan for software evolution.
 Technology Expertise
 Expert on available technologies that helps in the implementation of
the system.
 Methodological Expertise
 Expert on software development methodologies that may be adopted
during SDLC (Software Development Life Cycle).
COMMON QUALITY ATTRIBUTES
Category Quality Attributes Description
Design Qualities Conceptual Integrity Defines the consistency and
coherence of the overall
design. This includes the way
components or modules are
designed.
Maintainability Ability of the system to
undergo changes with a
degree of ease.
Reusability Defines the capability for
components and subsystems
to be suitable for use in other
applications
Run Time Qualities Interoperability Ability of a system or different
systems to operate
successfully by
communication and
exchanging information with
other external systems written
and run by external parties.
Manageability Defines how easy it is for
system administrators to
manage the application.
Reliability Ability of a system to remain
operational over 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 a percentage of
the total system downtime
over a predefined.
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.
Non-runtime Quality Portability Ability of the system to run
under different computing
environment.
Integrality Ability to makes separately
developed components of the
system work correctly
together.
Modifiability Ease with which each
software system can
accommodate changes to its
software.
Business quality Cost and schedule Cost of the system with
attributes respect to time to market,
expected project lifetime &
utilization of legacy.
Marketability Use of system with respect to
market competition.

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.)
COMMON ARCHITECTURAL DESIGN
Category Quality Attributes Description
Communication Message Bus Prescribes use of a software
system that can receive and
send messages using one or
more communication
channels.
Service-Oriented Defines the applications that
Architecture (SOA) expose and consume
functionality as a service
using contracts ad messages.
Deployment Client/Server Separate the system into two
applications where the client
makes requests to the server.
3-tier or N-tier Separates the functionality
into separate segments with
each segment being a tier
located on a physically
separate compute.
Domain Domain Driven Design Focused on modeling a
business domain and defining
business objects based on
entities within the business
domain.
Structure Component Based Breakdown the application
design into reusable
functional or logical
components that expose well-
defined communication
interfaces.
 Layered Divide the concerns of the
application into stacked
groups (layers).
Object Oriented 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
 Business Architecture
 It defines the strategy of business, governance, organization, and
key business processes within an enterprise and focuses on the
analysis and design of business processes.
 Application (software) Architecture
 It serves as the blueprint for individual application system their
interactions and their relationships to the business processes of the
organization.
 Information Architecture
 It defines the logical and physical data assets and data
management resources.
 Information Technology (IT) Architecture
 It defines the hardware and software building blocks that make up
the overall information system of the organization.

ARCHITECTURE DESIGN PROCESS

 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.
 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 based on
functional requirements. The decomposition can be modeled using
a design structure matrix (DSM), which shows the dependencies
between design elements without specifying the granularity of the
elements.
 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.
 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.

KEY ARCHITECTURE PRINCIPLES

 Build to Change Instead of Building to Last.
 Reduce Risk and Model to Analyze.
 Use Models and Visualizations as a Communication and Collaboration
Tool.
 Use an Incremental and Iterative Approach.
KEY DESIGN PRINCIPLES
 Separation of Concerns
 Single Responsibility Principle
 Principle of Least Knowledge
 Minimize Large Design Upfront
 Do not Repeat the Functionality
 Prefer Composition over Inheritance while Reusing the Functionality
 Identify Components and Group them in Logical Layers.
 Define the Communication Protocol between Layers
 Define Data Format for a Layer
 System Service Components should be Abstract
 Design Exceptions and Exception Handling Mechanism
 Naming Conventions