VEL TECH HIGH TECH Dr. RANGARAJAN Dr.

SAKUNTHALA ENGINEERING COLLEGE

UNIT -I

INTRODUCTION AND ARCHITECTURAL DRIVERS

Introduction – What is software architecture? – Standard Definitions – Architectural structures –

Influence of software architecture on organization-both business and technical – Architecture
Business Cycle- Introduction – Functional requirements – Technical constraints – Quality
Attributes.

INTRODUCTION

➢ The architecture of a system describes its major components, their relationships

(structures), and how they interact with each other.
➢ In architecture, non functional requirements are cast and separated by the functional
requirements. In Design, functional requirements are accomplished.

GOALS OF SOFTWARE ARCHITECTURE

✓ Expose the structure of the system, but hide its implementation details.
✓ Realize all 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 the quality and functionality offered by the system
✓ Improve external confidence in either the organization or system.

LIMITATIONS OF 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 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 following areas,

✓ Design Expertise
✓ Domain Expertise
✓ Technology Expertise
✓ Methodological Expertise

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 1

 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE

✓ Deliverables of the Architect

TYPES OF ARCHITECTURE

1. Enterprise Architecture
✓ Aligned with the goals of the enterprise
✓ Captures business processes and workflows
✓ Encompasses various systems, software and technical architectures
✓ Addresses enterprise-wide issues such as security, inter-operability, integrity
✓ Consistency and reuse across multiple systems within organization.

2. System Architecture
✓ A collection of components that are connected to accomplish a specific purpose.
✓ Described as one or more models possibly with different architectural views.

3. Software Architecture
✓ Provides a decomposition of the software system without going into details
✓ Provides the structure of the system that comprises software components
✓ Consists of various software components including those that manage the data,
performs computations and enables connectivity.
✓ Described using multiple views

4. Technical Architecture
✓ Formally describes components and their relationships
✓ Provides clear and specific guidelines on how to design, evolve and maintain the
system.

WHAT IS SOFTWARE ARCHITECTURE?

❖ Architecture serves as a blueprint for a system.

❖ Architecture is a high level design.
❖ Architecture is the overall structure of the system.
❖ Architecture is components and connectors.

STANDARD DEFINITIONS

→ The software architecture of a program or computing system is the structure or structures

of the system, which comprise software elements, the externally visible properties of
those elements, and the relationships among them .
→ The software architecture of a system is the set of structures needed to reason about the
system, which comprise of software elements, relations among them and properties of
both.

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 2

 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE

Eg. Basic architecture diagram for underwater acoustic simulation

Why Software Architecture is important?

→ An architecture will inhibit or enable a system’s driving quality attributes.

→ The analysis of an architecture enables early prediction of a system’s quality
→ A documented architecture enables communication among stakeholders
→ An architecture defines a set of constraints on subsequent implementation
→ The architecture dictates the overall structure of an organization
→ An architecture can be created as a transferable, reusable model that forms the heart of
the product line.

ARCHITECTURAL STRUCTURES

➢ A structure is the set of elements itself, as they exist in software or hardware.

➢ Architectural structures can be divided into three groups, depending on the broad nature
of the elements,
❖ Module structures - How is the system to be structured as a set of
code units (modules)?
❖ Component-and-connector structures - How is the system to be
structured as a set of elements that have runtime behavior
(components) and interactions (connectors)?
❖ Allocation structures - How is the system to relate to non software
structures in its environment (i.e., CPUs, file systems, networks,
development teams, etc.)?

1. MODULE STRUCTURES

 Module structures represent decisions as to how the system is to be structured as the set
of code or data units that have to be constructed.
 In any module structure, the elements are modules of some kind (classes, or layers, or
merely divisions of functionality, all of which are units of implementation).
 Module structures allow us to answer questions such as

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 3

 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE

✓ What is the primary functional responsibility assigned to each module?

✓ What other software elements is a module allowed to use?
✓ What other software does it actually use?
✓ What modules are related to other modules by generalization or
specialization (i.e., inheritance) relationships?

 Module structures includes the following,

a) Decomposition Structure
➢ The units are modules related to each other by the "is a submodule of " relation,
showing how larger modules are decomposed into smaller ones recursively until
they are small enough to be easily understood.
➢ The decomposition structure determines, to a large degree, the system’s
modifiablitiy, by assuring that likely changes are localized.

b) Uses Structure
➢ The units are related by the uses relation, a specialized form of dependency.
➢ A unit of software uses another if the correctness of the first requires the presence
of a correctly functioning version of the second.
➢ The uses structure is used to engineer systems that can be easily extended to add
functionality or from which useful functional subsets can be easily extracted.
c) Layered Structure
➢ Layer is a coherent set of related functionality. Layer n may only use the services
of layer n – 1.
➢ A Layer is an abstract “virtual machine” that provides a cohesive set of services
through a managed interface.
d) Class (or) generalization Structure
➢ The module units in this structure are called classes. The relation is "inherits-
from" or "is-an-instance-of."
➢ The class structure allows one to reason about re-use and the incremental addition
of functionality.

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 4

 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE

e) Data model
➢ The data model describes the static information structure in terms of data entities
and their relationships.
➢ For example, in a banking system, entities includes account, customer, loan.
Account has several attributes such as account number, type, status and current
balance. A relationship may dictate that one customer can have one or more
accounts, and one account is associated to one or more customers.

2. COMPONENT-AND-CONNECTOR STRUCTURES

 Component-and-Connector Structures represent decisions as to how the system is to be

structured as the set of elements that have runtime behavior (components) and interaction
(connectors).
 Component-and-Connector structures allows us to answer the following questions such
as,
✓ What are the major executing components and how do they interact?
✓ What are the major shared data stores?
✓ Which parts of the system are replicated?
✓ How does data progress through the system?
✓ What parts of the system can run in parallel?
✓ How can the system's structure change as it executes?
 Component-and-Connector Structures includes the following,

a) Process or communicating processes

➢ The units here are processes or threads that are connected with each other by
communication, synchronization, and/or exclusion operations.

b) Concurrency

➢ The units are components and the connectors are "logical threads."
➢ A logical thread is a sequence of computation that can be allocated to a separate physical
thread later in the design process.

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 5

 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE

c) Shared data, or repository

➢ This structure comprises of components and connectors that create, store, and access
persistent data.

d) Client-server

➢ The components are the clients and servers, and the connectors are protocols and
messages they share to carry out the system's work.

3. ALLOCATION STRUCTURES

 The allocation structures represent decisions as to how the system will relate to non
software structures in its environment.
 These structures show the relationship between the software elements and the elements in
one or more external environments in which the software is created and executed.
 Allocation structures allow us to answer questions such as
✓ What processor does each software element execute on?
✓ In what files is each element stored during development, testing, and system
building?
✓ What is the assignment of software elements to development teams?
 Allocation structures includes the following,

a) Deployment

➢ The deployment structure shows how software is assigned to hardware-processing and

communication elements.

b) Implementation

➢ This structure shows how software elements (usually modules) are mapped to the file
structures in the system's development, integration, or configuration control
environments.

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 6

 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE

c) Work assignment

➢ This structure assigns responsibility for implementing and integrating the modules to the
appropriate development teams.

INFLUENCE OF SOFTWARE ARCHITECTURE ON ORGANIZATION-BOTH

BUSINESS AND TECHNICAL

• Architecture is the result of a set of business and technical decisions. There are many
influences at work in its design, and the realization of these influences will change
depending on the environment in which the architecture is required to perform.
• Architectures are influenced by,
✓ System stakeholders
✓ The developing organization
✓ The experience of the architects
✓ The technical environment

1. Architectures are influenced by system stakeholders

❖ Many people and organizations are interested in the construction of a software system
and are referred to as stakeholders. Eg. Customers, end users, developers, project
manager etc.
❖ Having an acceptable system involves properties such as performance, reliability,
availability, platform compatibility, memory utilization, network usage, security,
modifiability, usability, and interoperability with other systems as well as behavior.
❖ The underlying problem is that each stakeholder has different concerns and goals, some
of which may be contradictory.
❖ The reality is that the architect often has to fill in the blanks and mediate the conflicts.

2. Architectures are influenced by the developing organization

❖ Architecture is influenced by the structure or nature of the development organization. For

example, if the organization has an abundance of idle programmers skilled in client-
server communications, then a client-server architecture might be the approach supported
by management. If not, it may well be rejected.
❖ There are three classes of influence that come from the developing organization,
→ Immediate business- An organization may have an immediate business
investment in certain assets, such as existing architectures and the products based
on them.
→ Long-term business- An organization may wish to make a long-term business
investment in an infrastructure to pursue strategic goals and may review the
proposed system as one means of financing and extending that infrastructure.

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 7

 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE

→ Organizational structure-The organizational structure can shape the software

architecture.

3. Architectures are influenced by the experience of the architects

❖ If the architects for a system had good results using a particular architectural approach,
such as distributed objects or implicit invocation, chances are that they will try that same
approach on a new development effort.
❖ Conversely, if their prior experience with this approach was disastrous, the architects may
be reluctant to try it again.
❖ Architectural choices may also come from an architect's education and training, exposure
to successful architectural patterns, or exposure to systems that have worked particularly
poorly or particularly well.
❖ The architects may also wish to experiment with an architectural pattern or technique
learned from a book or a course.

4. Architectures are influenced by the technical environment

❖ A special case of the architect's background and experience is reflected by the technical
environment.
❖ The environment that is current when an architecture is designed will influence that
architecture.
❖ It might include standard industry practices or software engineering techniques prevalent
in the architect's professional community.

ARCHITECTURE BUSINESS CYCLE

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 8

 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE

Working of architecture business cycle

1. The architecture affects the structure of the developing organization. If a company becomes
adapt at building families of similar systems, it will tend to invest in each team by nurturing each
area of expertise.

2. The architecture can affect the goals of the developing organization. A successful system built
from it can enable a company to establish a foothold in a particular market area.

3. The architecture can affect customer requirements for the next system by giving the customer
the opportunity to receive a system (based on the same architecture) in a more reliable, timely,
and economical manner than if the subsequent system were to be built from scratch.

4. The process of system building will affect the architect's experience with subsequent systems
by adding to the corporate experience base Eg. Usage of new architecture or framework, if
successful it will be continued.

5. A few systems will influence and actually change the software engineering culture, that is, the
technical environment in which system builders operate and learn. Eg. Usage of First RDBMS,
Spreadsheet, WWW.

Software Processes and the Architecture Business Cycle

Software process is the term given to the organization, and management of software
development activities. The various activities involved in creating software architecture are:

1. Creating the business case for the system - assessing the market need for a system.

2. Understanding the requirements - There are a variety of techniques for eliciting requirements
from the stakeholders.

3. Creating or Selecting the Architecture.

4. Communicating the Architecture – Architecture is to be communicated to all stakeholders,

developers, testers and management with good architecture documentation.

5. Analyzing or Evaluating the Architecture- Choosing among multiple competing designs in a

rational way is one of the architect’s greatest challenges. Evaluating an architecture for the
qualities that it supports is essential to ensuring that the system constructed from the architecture
satisfies its stakeholders needs. Eg. Architecture Tradeoff Analysis Method(ATAM).

6. Implementing Based on the Architecture- This activity is concerned with keeping the
developers faithful to the structures and interaction protocols constrained by the architecture.
Having an explicit and well-communicated architecture is the first step toward ensuring
architectural conformance.

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 9

 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE

7. Ensuring Conformance to an Architecture- When an architecture is created and used, it goes

into a maintenance phase. Constant vigilance is required to ensure that the actual architecture and
its representation remain faithful to each other during this phase.

FUNCTIONAL REQUIREMENTS

➢ A functional requirement defines a function of a system or its component.

➢ A function is described as a set of inputs, the behavior, and the outputs. Functional
requirements may be calculations, technical details, data manipulation and processing
and other specific functionality that define what a system is supposed to accomplish.
➢ Functional requirements are expressed in the form “system must do<requirement>”.
➢ The plan for implementing functional requirement is detailed in the system design.
➢ They are the statements of services the system should provide, how the system should
react to a particular input and how the system should behave in particular situations.
➢ Functional requirement may also explicitly state what the system should not do.

TECHNICAL CONSTRAINTS

✓ Technical constraints are fixed technical design decisions that absolutely cannot be
changed. Most often technical constraints are provided by stakeholders at the outset of
the project.
✓ A constraint is a design decision with zero degrees of freedom. That is, it is a design
decision that’s already been made.
✓ Examples include the requirement to use a certain programming language or to reuse a
certain existing module, or a management to make the system service oriented.
✓ These choices are arguably in the purview of the architect, but external factors (such as
not being able to train the staff in a new language or having a business agreement with a
software supplier, or pushing business goals of service interoperability) have led those in
power to dictate these design outcomes.
✓ Constraints are satisfied by accepting the design decision and reconciling it with other
affected design decisions.

QUALITY ATTRIBUTES

 A quality attribute is a property of a process or product that can have some qualitative or
quantitative value and can be measured or observed.
 Quality attributes are the overall factors that affect the run time behavior, system design
and user experience.
 Some of these attributes are related to the overall system design, while others are specific
to runtime, design time or user centric issues.

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 10

 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE

 The various quality attributes are as follows,

I. Design Qualities
1. Availability
2. Conceptual Integrity
3. Interoperability
4. Maintainability
5. Manageability
II. Runtime Qualities
6. Performance
7. Reliability
8. Reusability
9. Scalability
10. Security
11. Supportability
III. System qualities
12. Testability
IV. User Qualities
13. User Experience/Usability

I. DESIGN QUALITIES

1. AVAILABILITY

➢ 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.
Availability will be affected by system errors, infrastructure problems, malicious attacks,
and system load.
➢ The key issues for availability are:
✓ A physical tier such as the database server or application server can fail or become
unresponsive, causing the entire system to fail.
✓ Denial of Service (DoS) attacks, which prevent authorized users from accessing the
system, can interrupt operations if the system cannot handle massive loads in a timely
manner, often due to the processing time required, or network configuration and
congestion.
✓ Inappropriate use of resources can reduce availability.
✓ Bugs or faults in the application can cause a system wide failure.
✓ Frequent updates, such as security patches and user application upgrades, can reduce
the availability of the system.
✓ A network fault can cause the application to be unavailable.

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 11

 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE

2. CONCEPTUAL INTEGRITY

➢ Conceptual integrity defines the consistency and coherence of the overall design. This
includes the way that components or modules are designed, as well as factors such as
coding style and variable naming.
➢ The key issues for conceptual integrity are:
✓ Mixing different areas of concern within the design.
✓ Inconsistent or poorly managed development processes.
✓ Lack of collaboration and communication between different groups involved in the
application lifecycle.
✓ Lack of design and coding standards.
✓ Existing system demands can prevent both refactoring and progression toward a new
platform.

3. INTEROPERABILITY

➢ Interoperability is the ability of a system or different systems to operate successfully by

communicating and exchanging information with other external systems written and run
by external parties.
➢ The key issues for interoperability are:
✓ Interaction with external or legacy systems that use different data formats.
✓ Boundary blurring, which allows artifacts from one system to defuse into another.
✓ Lack of adherence to standards.

4. MAINTAINABILITY

➢ Maintainability is the ability of the system to undergo changes with a degree of ease.
These changes could impact components, services, features, and interfaces when adding
or changing the application’s functionality in order to fix errors, or to meet new business
requirements.
➢ The Key issues of maintainability are:
✓ Excessive dependencies between components and layers, and inappropriate coupling
to concrete classes, prevents easy replacement, updates, and changes; and can cause
changes to concrete classes to ripple through the entire system.
✓ The use of direct communication prevents changes to the physical deployment of
components and layers.
✓ Reliance on custom implementations of features such as authentication and
authorization prevents reuse and hampers maintenance.
✓ The logic code of components and segments is not cohesive, which makes them
difficult to maintain and replace, and causes unnecessary dependencies on other
components.
✓ The code base is large, unmanageable, fragile, or over complex; and refactoring is
burdensome due to regression requirements.
✓ Lack of documentation may hinder usage, management, and future upgrades.

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 12

 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE

5. MANAGEBILITY

➢ Manageability defines how easy it is for system administrators to manage the application,
usually through sufficient and useful instrumentation exposed for use in monitoring
systems and for debugging and performance tuning.
➢ The key issues of manageability are:
✓ Lack of health monitoring, tracing, and diagnostic information.
✓ Lack of runtime configurability.
✓ Lack of troubleshooting tools.

II. RUNTIME QUALITIES

6. PERFORMANCE

➢ Performance is an indication of the responsiveness of a system to execute specific actions

in a given time interval. It can be measured in terms of latency or throughput. Latency is
the time taken to respond to any event. Throughput is the number of events that take
place in a given amount of time.
➢ The key issues of performance are:
✓ Increased client response time, reduced throughput, and server resource over
utilization.
✓ Increased memory consumption, resulting in reduced performance, excessive
cache misses, and increased data store access.
✓ Increased database server processing, resulting in reduced throughput.
✓ Increased network bandwidth consumption, resulting in delayed response times
and increased load for client and server systems.

7. RELIABILITY

➢ Reliability is the ability of a system to continue operating in the expected way over time.
Reliability is measured as the probability that a system will not fail and that it will
perform its intended function for a specified time interval.
➢ The key issues of reliability are:
✓ The system crashes or becomes unresponsive.
✓ Output is inconsistent.
✓ The system fails due to unavailability of other externalities such as systems,
networks, and databases.

8. REUSABILITY

➢ Reusability is the probability that a component will be used in other components or

scenarios to add new functionality with little or no change. Reusability minimizes the
duplication of components and the implementation time.
➢ The key issues of reusability are:

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 13

 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE

✓ The use of different code or components to achieve the same result in different
places
✓ The use of multiple similar methods to implement tasks that have only slight
variation.
✓ Using several systems to implement the same feature or function instead of
sharing or reusing functionality in another system, across multiple systems, or
across different subsystems within an application.

9. SCALABILITY

➢ Scalability is ability of a system to either handle increases in load without impact on the
performance of the system, or the ability to be readily enlarged.
➢ The key issues of scalability are:
✓ Applications cannot handle increasing load.
✓ Users incur delays in response and longer completion times.
✓ The system cannot queue excess work and process it during periods of reduced
load.

10. SECURITY

➢ Security is the capability of a system to reduce the chance of malicious or accidental

actions outside of the designed usage affecting the system, and prevent disclosure or loss
of information.
➢ The key issues of security are:
✓ Spoofing of user identity.
✓ Damage caused by malicious input such as SQL injection and cross-site scripting.
✓ Data tampering.
✓ Repudiation of user actions.
✓ Information disclosure and loss of sensitive data.
✓ Interruption of service due to Denial of service (DoS) attacks.

11. SUPPORTABILITY

➢ Supportability is the ability of the system to provide information helpful for identifying
and resolving issues when it fails to work correctly.
➢ The key issues of supportability are:
✓ Lack of diagnostic information.
✓ Lack of troubleshooting tools.
✓ Lack of tracing ability.
✓ Lack of health monitoring.

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 14

 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE

III. SYSTEM QUALITIES

12. TESTABILITY

➢ Testability is a measure of how well system or components allow you to create test
criteria and execute tests to determine if the criteria are met. Testability allows faults in a
system to be isolated in a timely and effective manner.
➢ The key issues of testability are:
✓ Complex applications with many processing permutations are not tested
consistently, perhaps because automated or granular testing cannot be performed
if the application has a monolithic design.
✓ Lack of test planning.
✓ Poor test coverage, for both manual and automated tests.
✓ Input and output inconsistencies; for the same input, the output is not the same
and the output does not fully cover the output domain even when all known
variations of input are provided.

IV. USER QUALITIES

13. USABILITY (or) USER EXPERIENCE

➢ The application interfaces must be designed with the user and consumer in mind so that
they are intuitive to use, can be localized and globalized, provide access for disabled
users, and provide a good overall user experience.
➢ The key issues of Usability are:
✓ Too much interaction required for a task.
✓ Incorrect flow of steps in multistep interfaces.
✓ Data elements and controls are poorly grouped.
✓ Feedback to the user is poor, especially for errors and exceptions, and the
application is unresponsive.

YEAR/SEM: III/VI IT6602- SOFTWARE ARCHITECTURES Page 15