UCS2703 : Software Architecture

Unit-I
Architectural views and Quality Attributes

1
 Session Meta Data

Prepared By : Swarnalakshmi Ravi, Associate

Professor
Date : 25-Jul-2024

2
 Session Objectives
– The fundamentals of software architecture
– The basics of architectural styles, views and patterns
– The various quality attributes influencing architectural styles

3
 Session Outcomes
• At the end of this unit, participants will be able to
– Understand the fundamentals of software architecture
– Understand the architectural styles
– Understand the quality attributes influencing architectural styles

4
  When systems are constructed from many
components, the organization of the overall system—
the software architecture—presents a new design
paradigm
 Software Architecture (SA) is an emerging field
these days, though it was once perceived as
conservative and traditional discipline.
 Architectural style and implementation for complex
Why this systems a growing challenge and we have lot of
course? scope for solving it.
 To describe system components, the nature of
interactions among the components, and the patterns
that guide the composition of components into
systems can be defined by this field.
 SA: From Land to Space, across the domain and
sectors, a crucial learning
Lecture Text-books

slides

and
Reference books
books +
world of
web

for
knowledge
Lots of gamification attempted in class slides to make it easy and
stress-free learning for you
  Cloud Architect –ex: GCP
 SAP architect ex: for salesforce module
Career  BI architect
options with  Data Engineer

industry  Database architect

and  Solution architect

 IT Infra Architect
multiple
sectors The average total compensation for a
Software Architect at Tesla in the United States is
around $197,190 per annum [Tesla website] and rest
of US $120,000 to $180,000 per annum.
The average total compensation for a
Software Architect in India is around 25-27 Lacs INR
per annum [Payscale.com]
Big News
Big News

Microsoft Crowd strike 20th July 2024 –

Global Outage
  24+ years of IT industry experience
 Education: B.E (CSE) with Masters and PhD from IIT Madras
 IT experience with Patni computers Mumbai, Tata
Consultancy Services & Wells Fargo Bank at Chennai etc.
 Multiple domain exposure Banking , Manufacturing, IoT,
Cloud computing, Healthcare , Energy Utilities with US,
Europe and Japan geos
 Multiple technologies exposure to ML, AI, BI Cognos,
About Self Informatica, J2EE, Python, R programming, SQL, SPARQL,
Ontology, Semantics, Knowledge graphs etc.
 Certifications: Scrum Agile ,Six sigma GB certified,
Informatica, Cognos BI
 Honors: Business excellence award from Ratan Tata, late
Cyrus Mistry and Best thesis award for PhD from IIT Madras
 Academic: Research publications, conference, book chapter
+ visiting faculty @ IIT Madras, Krea IFMR, IIM Nagpur, IIM
Kashipur, IIM Trichy , VIT Chennai for DS&AI since 2015.
  The software architecture of a system is the set of
structures needed to reason about the system, which
comprise software elements, relations among them,
Unit 1- and properties of both

Architectura  For example ERP at SSN is split into HR ERP and

Academic ERP.
l views and  Architecture speaks about components ,their
Quality attributes and their inter relationship within a system
(how they interact)
Attributes  Architecture is the backbone for implementing a
complex system like this ERP example
  Architecture Is an Abstraction ?
 Analogous and similar to Entity Relation model and
schema [ER diagram] in a database
Unit 1-  System Architecture [Hardware, Software
Architectura components]

l views and  Enterprise Architecture [ Organizational functions,

Business units, Workflows]
Quality  Structures -> has actual components
Attributes  Module structures, Component and connector,
Allocation structures
 Views -> representation of the components
 Client-server , Decomposition view
Unit 1-
Architectura
l views and
Quality
Attributes
Unit 1-
Architectura
l views and
Quality
Attributes
Unit 1-
Architectura
l views and
Quality
Attributes

ABC – Architectural Business Cycle incl. social, organizational and

business impacts
 System and Enterprise Architecture:

A system's architecture is a representation of a system in which

there is a mapping of functionality onto hardware and software
components,
Unit 1- a mapping of the software architecture onto the hardware architecture,
Architectura and

l views and a concern for the human interaction with these components.

Quality That is, system architecture is concerned with a total system, including

Attributes hardware, software, and humans

Enterprise architecture is a description of the structure and

behavior of an organization's processes, information flow, personnel,
and organizational subunits,

aligned with the organization's core goals and strategic direction

concerned with how an enterprise's software systems support the

business processes and goals of the enterprise
 System and Enterprise Architecture:

A description of the system architecture will allow reasoning about

additional qualities such as power consumption, weight, and physical
footprint
Unit 1- System Architect vs Software Architect – The tradeoff
Architectura how this functionality is implemented and how the various processors
l views and interact through the exchange of messages on the network

Quality Software is only one concern of enterprise architecture.

Attributes Two other common concerns addressed by enterprise architecture are

how the software is used by humans to perform business processes,
and

the standards that determine the computational environment.

 Layered Competence
based

Unit 1-
Architectura
l views and
Quality
Attributes

Client server
Unit 1-
Architectura
l views and
Quality
Attributes

Credits:
O’Reilley
 Layered pattern. When the uses relation among software elements
is strictly unidirectional, a system of layers emerges. A layer is a
coherent set of related functionality.

Shared-data (or repository) pattern. This pattern comprises

components and connectors that create, store, and access persistent
Unit 1- data

Architectura
l views and
Quality
Attributes

Client-server pattern. The components are the clients and the

servers, and the connectors are protocols and messages they share
among each other to carry out the system's work

Sub types: [Multi tier and Competence based]

Unit 1-
Architectura
l views and
Quality
Attributes

Credits: medium.com
Unit 1-
Architectura
l views and
Quality
Attributes
Unit 1-
Architectura
l views and
Quality
Attributes
Unit 1-
Architectura
l views and
Quality
Attributes
Unit 1-
Architectura
l views and
Quality
Attributes
Unit 1-
Architectura
l views and
Quality
Attributes
Unit 1-
Architectura
l views and
Quality
Attributes
Unit 1-
Architectura
l views and
Quality
Attributes
Unit 1-
Architectura
l views and
Quality
Attributes
 Reference Architectural design must
be good:
Unit 1- - Portability /Interoperability
Architectura - Reliability
l views and - Well defined (components and its
Quality relations)
Attributes - Version independent
- Right choice of patterns and styles
- Right choice of structures and
views
 Importance of Architecture quality:

An architecture will inhibit or enable a

Unit 1- system's driving quality attributes.
Architectura An architecture defines a set of constraints
l views and on subsequent implementation.
Quality
Attributes An architecture can provide the basis for
evolutionary prototyping.

An architecture can be created as a

transferable, reusable model
 Importance of Architecture quality:

Architecture-based development focuses

Unit 1- attention on the assembly of components,
Architectura rather than simply on their creation
l views and (interactions revealed in detail)
Quality The architecture dictates the structure of an
Attributes organization, or vice versa.

It provides inputs for cost budgeting and

scheduling in software project execution.
Learn with
Fun

[An activity-
based
learning]
Guess
What? Use
subject
related
terminology
learnt so far
Guess
What? Use
subject
related
terminology
learnt so far
Guess
What? Use
subject
related
terminology
learnt so far
 Common Architectural styles for defining the
structures or views (Mary Shaw… reference
book)

Unit 1- Pipes and filters

Architectura
Object orientation
l views and
Quality Event based trigger system
Attributes
Layered system

Repositories

Table driven
 Other popular styles for defining the
structures or views (Mary Shaw…. reference
book)

Unit 1- Distributed systems

Architectura
Domain specific systems
l views and
Quality Process control systems
Attributes
State Transition

Main program…sub routine

 Key Considerations for Structure:

• Gross organization and global control

Unit 1- structure;
Architectura • Protocols for communication;
l views and • Synchronization and data access;
• Assignment of functionality to design
Quality elements & physical distribution;
Attributes • Composition of design elements;
• Scaling and performance; and
• Selection among design alternatives.
 Tools to facilitate structure:

• Module interconnection languages,

Unit 1- templates and frameworks ,
Architectura • Systems that serve the needs of specific
l views and domains,
• Formal models of component integration
Quality mechanism,
Attributes • Software patterns
• Architectural principles (ex: Tsunami
warning system…resilient time is key)
• Software architects
 Role of high-level programming languages
in SA:

Shift from machine language to assembly language

Unit 1- to high level programming language over the
Architectura decades
l views and
Higher-level languages allowed more sophisticated
Quality programs to be developed, and patterns in the use
Attributes of data emerged

Progress in language design continued with the

introduction of modules to provide protection for
related procedures and data structures
[Encapsulation in OOPS]
Unit 1-
Architectura Match Motu and Patlu for samosa distribution:

l views and Architectural style

Enterprise Architecture
Quality Modules
Attributes Structure

Organizational goals and process

Views

Representation of system
Protection for data structures

System and components

 Three kinds of structures:

Module structures embody decisions as to how the system is to be

Unit 1- structured as a set of code or data units that have to be constructed or

procured for functional deployment
Architectura Component-and-connector structures embody decisions as to

l views and how the system is to be structured as a set of elements that have
runtime behavior (components) and interactions (connectors).
Quality
Attributes Allocation structures embody decisions as to how the system will
relate to non-software structures in its environment (such as CPUs,
file systems, networks, development teams, etc.)
Ex: Tsunami
Warning
System’s
Software
Architecture
Ex:
Architecting
the working
of a
blockchain
Do it  Design a system or structure and its associated
Yourself software architecture for student background
verification at SSN for UG & PG admissions
Now
 Module structures:
Decomposition structure. The units are modules that are related to
each other by the is-a-submodule-of relation, showing how modules
are decomposed into smaller modules recursively
Unit 1- Uses structure. In this important but overlooked structure, the units
Architectura here are also modules, perhaps classes. The units are related by the
uses relation, a specialized form of dependency
l views and
Layer structure. The modules in this structure are called layers. A
Quality layer is an abstract "virtual machine" that provides a cohesive set of
Attributes services through a managed interface

Class (or generalization) structure. The module units in this

structure are called classes. The relation is inherits from or is an
instance of .This view supports reasoning about collections of similar
behavior or capability (e.g., the classes that other classes inherit from)

Data model. The data model describes the static information

structure in terms of data entities and their relationships.
Caption the pic
for this random
forest ex in S.A
terminology
Caption the
pic in S.A
terminology
Caption the pic
in IoT Smart
Manf. using S.A
terminology
 C&C structures:
Service structure. The units here are services that interoperate with
each other by service coordination mechanisms such as SOAP

Unit 1- Concurrency structure. This component-and-connector structure

allows the architect to determine opportunities for parallelism of
Architectura process, threads and the locations where resource contention may
occur
l views and
Quality
Attributes
 Allocation structures:
Deployment structure. The deployment structure shows how software
is assigned to hardware processing and communication elements

Unit 1- Implementation structure. This structure shows how software

elements (usually modules) are mapped to the file structure( s) in the
Architectura system's development, integration, or configuration control
environments
l views and
Work assignment structure. This structure assigns responsibility for
Quality implementing and integrating the 1nodules to the teams who will carry
Attributes it out
 Enabling System Quality Attributes:

If your system requires high performance

Unit 1- If modifiability is important

Architectura
If your system must be highly secure
l views and
Quality If you believe that scalability will be important
Attributes
If your projects need the ability to deliver
incremental subsets

If you want the elements from your system to

be reusable
 Intended Software Architecture Vs Actual

Failed
quality
 Predicting System Quality Attributes:

It is possible to make quality predictions about a

system based solely on an evaluation of its
architecture
Unit 1-
Architectura The design analysis must be a standard part of the
architecture development process
l views and
Quality To ensure that an architecture will deliver its prescribed
Attributes benefits

Must be abstract that most nontechnical people can

understand it adequately [End user friendly] ex: UI/UX
and AR/VR in shopping

Must overcome constraints and support decision

 Predicting System Quality Attributes:

If it is influencing the Organizational Structure in a

positive and effective way

Unit 1- If it is enabling Evolutionary Prototyping

Architectura
If it is improving Cost and Schedule Estimate
l views and
Quality If it is supplying a Transferable, Reusable Model
Attributes
If it is allowing Incorporation of Independently
Developed Components

If it is restricting the Vocabulary of Design Alternatives

and serves as role model for training other modules
Dumb
Charades
  Concurrency structure
 work breakdown
Recap of  customer communication
key  pipe and filter
terminologi  layered structure
es  client-server
 Software Architecture for project life cycle:

Unit 1- Waterfall
Architectura
Iterative
l views and
Quality Agile
Attributes
Model based dev
 Software Architecture for project life cycle:

Unit 1-
Architectura
l views and
Quality
Attributes
 Software Architecture for project life cycle:

Unit 1-
Architectura
l views and
Quality
Attributes
 Software Architecture for project life cycle:

Unit 1-
Architectura
l views and
Quality
Attributes
 Software Architecture for project life cycle:

Unit 1-
Architectura
l views and
Quality
Attributes
 Software Architecture for business:

Systems are created to satisfy the business

Unit 1- goals of one or more organizations.
Architectura
Development organizations want to :
l views and make a profit, or capture market, or stay in
Quality business, or help their customers do their jobs
Attributes better, or keep their staff gainfully employed,
or make their stockholders happy

Architects need to understand who the vested

organizations are and what their goals are.
Unit 1-
Architectura
l views and Example of a business goal: To maximise reusability and reduce
cost
Quality
Company invested already in some existing system. How will you
Attributes reuse the max and propose a new system?

How will you prove that the new system is cost effective and
beneficial?

Only FACTS!!!
Unit 1-
Architectura
l views and
Quality
Attributes
Example of a business goal: To maximise reusability and reduce
cost

How will the architecture impact each of these stakeholders?

Only FACTS!!!
  performance,
 reliability,
 availability,
 platform compatibility,
 memory utilization,
FACTS  network usage,
CHECK  security,
 modifiability,
 usability, and
 interoperability with other systems as well as
behavior
Stakeholder
s’ corner
Stakeholder
s’ corner
Influencers
for
architecture

Ex: Organization wide embracing Microsoft for office365,

cloud computing and all digital needs
  Technical context. The architecture can affect
stakeholder 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 (ie., cost
Influencers effectiveness of newly proposed architecture)
for  Project context. The architecture affects the
structure of the developing organization. An
architecture architecture prescribes a structure for a system; as
we will see, it particularly prescribes the units of
software that must be implemented (or otherwise
obtained) and integrated to form the system (ie.
modularity)
  Business context. The architecture can affect the
business goals of the developing organization. A
successful system built from an architecture can
Influencers enable a company to establish a foothold in a
particular market segment.
for
architecture  Professional context. The process of system building
will affect the architect's experience with subsequent
systems by adding to the corporate experience base.
  So far we have played
 Connexions
 Caption the pic
Software  Motu Patlu matching
Architecture  Do it yourself
 Dumb Charades
Fun Zone
 We will now play Scrabble
  Functional requirements. These
requirements state what the system must
do, and how it must behave or react to
runtime stimuli. Ex: precedence process
triggers some action
Requiremen  Quality attribute requirements. These
ts for a requirements are qualifications of the
software functional requirements or of the overall
product ex: speed, cost efficiency, resilience
architecture effectiveness etc.
 Constraints. A constraint is a design
decision with zero degrees of freedom. That
is, it's a design decision that's already been
made. how to overcome then?
  Functional requirements:

 Functionality is the ability of the system to do the

Requiremen work for which it was intended.
 Of all of the requirements, functionality has the
ts for a strangest relationship to architecture.
software  First of all, functionality does not determine
architecture architecture.
 That is, given a set of required functionality, there is
no end to the architectures you could create to satisfy
that functionality
 Ex: rehabilitation system for displaced refugees
  Functional requirements:

 functional suitability as "the capability of the software

product to provide functions which meet stated and
Requiremen implied needs when the software is used under
specified conditions”
ts for a
software  Quality attributes to validate
architecture  availability, performance, or usability [Scalability
check]
 modifiability or testability. [Reliability check]
  Functional requirements: Quality attributes
to validate

Requiremen
ts for a
software
architecture
  Functional requirements:

Requiremen
ts for a
software
architecture
Hot in news
and in the
industry

Read more@ Tsunamis | NASA Applied Scienc

es
  Why Tactics?

 Design patterns are complex; they typically consist

of a bundle of design decisions. But patterns are
Quality often difficult to apply as is; architects need to
modify and adapt them. Tactics is easy to adapt,
attributes serves as an alternate approach
 If no pattern exists to realize the architect's design
goal, tactics allow the architect to construct a
design fragments.
 By cataloging tactics, we provide a way of making
design more systematic within some limitations.
More choice to pick and use ----Flexibility in
approach
  The seven categories of design decisions are
 1. Allocation of responsibilities
 2. Coordination model
Quality  3. Data model
Design  4. Management of resources
Decisions  5. Mapping among architectural elements
 6. Binding time decisions
 7. Choice of technology
  Allocation of responsibilities
 Decisions involving allocation of
responsibilities include the following: •
 Identifying the important
responsibilities, including basic system
Quality functions, architectural infrastructure,
and satisfaction of quality attributes.
Design  Determining how these responsibilities
Decisions are allocated to non-runtime and
runtime elements (namely, modules,
components, and connectors).
 Ex: in a thermal power
plant…units like raw
materials handling, boiler
unit, exhaust unit etc
  Coordination model

 Identifying the elements of the system that must coordinate,

or those prohibited from coordinating. ·­
Quality  Determining the properties of the coordination, such as
timeliness, concurrency, completeness, correctness, and
Design consistency.
Decisions  Choosing the communication mechanisms (between
systems, between our system and external entities, between
elements of our system) that realize those properties.
 Important properties of the communication mechanisms
include stateful versus stateless, synchronous versus
asynchronous, guaranteed versus nonguaranteed delivery,
and performance-related properties such as throughput and
latency.
  Data model
 Choosing the major data abstractions, their operations,
and their properties.
Quality  This includes determining how the data items are created,
Design initialized, accessed, persisted, manipulated, translated,
and destroyed.
Decisions  Compiling metadata needed for consistent interpretation
of the data. • Organizing the data.
 This includes determining whether the data is going to be
kept in a relational database, a collection of objects, or
both. If both, then the mapping between the two different
locations of the data must be determined.
  Data model

Quality
Design
Decisions
  Resource management and optimization
 Identifying the resources that must be managed and
Quality determining the limits for each.
Design  Determining which system element(s) manage each
resource.
Decisions  Determining how resources are shared and the
arbitration strategies employed when there is contention.
 Determining the impact of saturation on different
resources. [constraints?]
  Resource Mapping in-to modules
 The mapping of modules and runtime elements to each
Quality other that is, the runtime elements that are created from
each module; the modules that contain the code for each
Design runtime element.

Decisions  The assignment of runtime elements to processors.

 The assignment of items in the data model to data
stores.
 The mapping of modules and runtime elements to units
of delivery.
  Time bound decision making as appropriate
 For allocation of responsibilities, you can have build-time
selection of modules via a parameterized make file.
Quality  For choice of coordination model, you can design
runtime negotiation of protocols.
Design  For resource management, you can design a system to
Decisions accept new peripheral devices plugged in at runtime,
after which the system recognizes them and downloads
and installs the right drivers automatically.
 For choice of technology, you can build an app store for
a smartphone that automatically downloads the version of
the app appropriate for the phone of the cust01ner buying
the app..
  Choice of Technology
 Choice of technology decisions involve the following:
 Deciding which technologies are available to realize the decisions
made in the other categories.
 Determining whether the available tools support this technology
Quality choice (IDEs, simulators, testing tools, etc.) are adequate for
development to proceed.
Design  Determining the extent of internal familiarity as well as the
Decisions degree of external support available for the technology (such as
courses, tutorials, examples, and availability of contractors who
can provide expertise in a crunch) and deciding whether this is
adequate to proceed.
 Determining the side effects of choosing a technology, such as a
required coordination model or constrained resource
management opportunities.
 Determining whether a new technology is compatible with the
existing technology stack or how to make it interoperable.
  End of Unit 1
THANK YOU  Quick recap and discussions