SA Module 2

Download as pdf or txt
Download as pdf or txt
You are on page 1of 33

Software Architecture

Module II
Architectural Design Process
&
Introduction to Software Design
Key Assumptions
• You are part of a very large team across geographies and cultures – ‘following
the sun’
• The time for development and deployment runs into at least a year
• The client sees enormous business benefit (immediate profits, competitive edge,
first mover advantage) in quickly using the product
• You are playing multiple roles at various stages of the development lifecycle
• During the life of the project you communicate with a variety of stakeholders
• You are developing a very large enterprise-wide software application
• The application caters to thousands of users across geographies, cultures and
time zones
• It is accessible across variety of channels and the final product is deployed on a
very large infrastructure scattered across data centers and cloud
• Client expectation: Services are up-and-running 24 x 7
Topics

1. What is Architecture Design Process


2. Understanding the problem
3. Identifying design elements and their relationship
4. Evaluating the Architecture
5. Transforming the Architecture
6. Problems in Software Architectural Design
7. Solutions to Problems in Software Architecture Design
8. Function form and Fabrication
9. The scope of Design
10. Psychology and Philosophy of Design
11. General Methodology of Design
Architecture Design Process
1. Architecture design focuses on
• Decomposition of a system into components
• Interactions between those components
• Satisfy functional and non-functional requirements

Understanding the Problem

Identify Design Elements & their Relationships

Evaluate the Architecture Design

Transform the Architecture Design

Architectural Description
Architecture Design Process

2. Understanding the Problem

• Why focus efforts on solving technical problems that do not


address business problems aka Implementation Trap!
• Incorrect understanding of the problem may lead to numerous
other downstream problems such as usability and reliability

3. Identifying design elements and their relationships

• Split the system into multiple smaller parts based on functional


requirements
• This is the first draft or baseline
• Tools: Design Structure Matrix (DSM) or Unified Modeling Language
(UML), Hierarchy of Components - represent the dependencies between
design elements without prescribing the granularity of the elements
Architecture Design Process

3. Identifying design elements and their relationships (contd.)

• Design Structure Matrix (DSM)

X’s specify dependencies


Architecture Design Process
3. Identifying design elements and their relationships (contd.)

• Unified Modeling Language (UML)


Architecture Design Process
3. Identifying design elements and their relationships (contd.)

• Hierarchy of Components
Architecture Design Process
3. Identifying design elements and their relationships (contd.)

• Steps for identification of design elements and their relationships

Define the
System Context

Identify the
Modules

Describe
Components and
Controllers

Architectural Description
Architecture Design Process
3. Identifying design elements and their relationships (contd.)

• Steps for identification of design elements and their relationships

Define the
System Context

Identify the
Modules

Describe
Components and
Controllers

Architectural Description
Tools: Use Case / Domain Model
Architecture Design Process
3. Identifying design elements and their relationships (contd.)
• Steps for identification of design elements and their relationships

A module refers to a static unit of software that can be


Define the designed, implemented, and compiled into a deliverable
System Context executable system or subsystem; it is a unit of execution

A component is a runtime entity, the definition of which


Identify the exists in a module. Binary modules are instantiated at run
Modules time and these instantiations are commonly called
components

Describe Connectors define interaction between components


Components and
Controllers E.g. The Web server module is the binary code that exists
as a set of program files. The Web server component is a
running instance of the Web server
Architectural Description
Architecture Design Process
3. Identifying design elements and their relationships (contd.)

• Steps for identification of design elements and their relationships

Define the Module View


System Context

Identify the
Modules

Describe
Components and
Controllers

Architectural Description
Architecture Design Process
3. Identifying design elements and their relationships (contd.)
• Steps for identification of design elements and their relationships

A module refers to a static unit of software that can


Define the be designed, implemented, and compiled into a
System Context deliverable executable system or subsystem; it is a
unit of execution

Identify the A component is a runtime entity, the definition of


Modules which exists in a module. Binary modules are
instantiated at run time and these instantiations are
Describe commonly called components
Components and
Controllers Connectors define interaction between components

E.g. The Web server module is the binary code that


Architectural Description
exists as a set of program files. The Web server
component is a running instance of the Web server
Architecture Design Process
3. Identifying design elements and their relationships (contd.)
• Steps for identification of design elements and their relationships

Define the
System Context

Identify the
Modules

Describe
Components and
Controllers

Architectural Description
Architecture Design Process
4. Evaluating the Architecture
• Evaluating the architectural design to determine if it satisfies the
architectural requirements
• Qualitative and Quantitative metric is used to assess compliance with quality
attribute requirements
• Tools: Architecture Tradeoff Analysis Method (ATAM), Software Architecture
Analysis Method (SAAM), Active Review for Intermediate Designs (ARID)
• Quality attribute requirements must be clearly articulated and their
acceptance values must be defined
• E.g.
Quality Attribute Metric Type Metric
Performance Numeric Range Number of transactions per unit time
Reliability Numeric Range Mean Time to Failure
Availability Numeric Range Downtime, Time to Resume
Operations
Modifiability Numeric Range Expense per change type
Architecture Design Process

5. Transforming the Architecture

• If the architectural design does not fully satisfy its quality attribute
requirements, then it must be changed until it does satisfy them
• Instead of starting from scratch, we can take the existing design
and apply design operators to it in order to transform it
• Two types of design operators:
Modular operators affect modular architecture
Component operators affect components
Architecture Design Process
• Modular Operators
Architecture Design Process
• Design Operators

Decomposition Decomposition of a system into


components
Replication Replication of components to
improve reliability
Compression Compression of two or more
components into a single component
to improve performance
Abstraction Abstraction of a component to
improve modifiability and
adaptability
Resource Sharing Sharing of a single component
instance with other components to
improve integrability, portability and
modifiability
Introduction to Software Design

6. Problems in Software Architectural Design

As size & complexity of application increases and development team


grows; there is a definite need for control on design of application

Here are some problems:


• A lack of awareness of the importance of architectural design to
software development
• A lack of understanding of the role of the software architect
• A widespread view that designing is an art form, not a technical activity
• A lack of understanding of the design process
• A lack of design experience in a development organization
• Insufficient software architecture design methods and tools
• A lack of understanding of how to evaluate designs
• Poor communication among stakeholders
Introduction to Software Design

7. Solutions to Problems in Software Architectural Design

Solutions to the problem of inadequate design:


• Evangelizing the importance of software architecture
• Improving software architecture education
• Using architecture methods and tools

Solutions to improving communication:


• Improve quality of information being communicated
• Standardized architectural terminology, design processes, and description
languages

Solutions to improving design:


• careful planning of design process
• systematic execution of production of design artefacts
Introduction to Software Design
8. Function, Form, and Fabrication: The Vitruvian Triad

Vitruvius was a Roman architect and engineer from the first century whose most famous work,
De Architectura, describes some of the most fundamental construction processes and designs.
Fabrication + Form + Function = Optimum Design Solution
These processes provided a foundation for a multitude of construction innovations moving
forward.

Means beauty - The


Fabrication architecture of a building
Means strength - The Form should be attractive and
building should have a Firmatis Venustatis appealing for people.
strong infrastructure Building should not only
so it can stand delight the visitor but also
robustly through years. Function raise their good spirits
It should be in an
excellent condition Utilitas
Means functionality - A building is
functional for the residents or the
people who are using it. It should
be useful and beneficial
Introduction to Software Design
• Function (& Product Planning)
Requirements
Business Problem Analysis of Problem
List

An applications architecture must address end user needs aka


requirements list

• Form (& Interaction Design)


Requirements Functional
Requirements Analysis
List Specifications

Functional Design Interaction Design


Specifications
Program Design
Interaction Design: Affects end-user (aka user experience)
Program Design: System design (other than interaction design)
Cognitive Friction:
Poor Interaction Design Cognitive Friction Resistance encountered by
users when engaging with
the system
Introduction to Software Design

• Fabrication
Architecture + Construction = Superior Quality Product

Architecture should include design and selection of technologies. It should also factor
using COTS that satisfy the solution domain (Build v/s Buy)

• Application Architecture

Includes:
1. Interaction Design (functional features that the end user sees)
2. Quality attributes that may affect the architecture
― Cost of implementation
― Cost of deployment, administration, and technical support
― Cost of training
― Time to deliver
Introduction to Software Design

9. The Scope of Design

• Design Tasks

Tasks of designers are influenced by several characteristics

Market need / new product


idea, application design and
Creative ends with product EOL
Logic, programming Aquirer’s View
languages, software Pyschological
design methodologies, Organizational
domain

Engineering
Systematic
Finding optimized solutions to a set of
objectives or problems while
balancing competing obstacles or
constraints
Introduction to Software Design
9. The Scope of Design (contd.)

• Design Tasks (contd.)

Tasks and activities of designers are influenced by several characteristics.

Characteristics Understanding
Origin of task Tasks originate from
• Product Planning Group: Identification of a real or perceived need &
establishment of requirements
• In-house software: Software built by company’s own IT organization or third
party software development firm
• Systems integration: Applications requiring integration with third party
applications, other in-house applications
• Production & Field Testing: Once the product is ready, it requires effort or
testing
Organization Tasks also originate from the type of the organization:
• Product-oriented companies: Product development & production is split
among different divisions
• Problem-oriented companies: Work is organized around division of labor e.g.
database, UI
Introduction to Software Design
9. The Scope of Design (contd.)

• Design Tasks (contd.)

Tasks and activities of designers are influenced by several characteristics.

Characteristics Understanding

Novelty Some design tasks may require novelty (creativity, invention) in solving a problem:
• Original Design: A problem where no known solution exists
• Adaptive Design: Application of known and established solution principles
• Variant Design: E.g. a system may be reworked to handle greater user traffic

Production Design tasks originate from the need for:


• Custom system: One-off software requirement
• Commercial systems: Requiring mass production

Technology Different technologies require different design methods viz. UI, ETL, Middleware, etc.

Horizontal Domain The layers in an application may require different design methods viz. UI, Business
Logic and Database

Quality Attributes Design tasks are also influenced by quality attributes (in addition to functional
requirements) viz. modifiability, performance, availability, usability, portability
Introduction to Software Design
10. The Psychology and Philosophy of Design
Language + Logic + Knowledge = Software Design

Psychology = Intuition, Mental, Subconscious, Attitude ……. INTUITIVE THINKING

Philosophy = Wisdom, Fundamental ……………………………. DISCURSIVE THINKING

• Intuitive Thinking: characterized by flashes of insight and inspiration triggered by


association of ideas

• Discursive Thinking: involves analyzing facts and relationships

• Design Activity: Problem


Obstacles:
Activity

Obstacle
Design

• Lack of understanding of problem


Solution • Shorter schedules

Design is a creative activity, cannot be measured and understood. However adoption of


systematic approaches to design can bring a degree of predictability viz. time for design,
quality of design.
An architect may not apply OOAD methodology for a procedural implementation.
Introduction to Software Design

10. The Psychology and Philosophy of Design (contd.)

• Example 1: Conversation between two gentleman expressing their feelings about


beetle inside their respective boxes

Person A: The beetle is cute.

Person B: The beetle is definitely not cute.

Person A: I can ensure you it is because I know it!

Person B: And I know it too, that is why I am saying it is not cute!

Person A: The beetle has 6 legs.

Person B: Yes, and 2 eyes too!

Person A: You are right, I know exactly what you are talking about!

Although, even with objective descriptions, there is no guarantee they are the same.
Introduction to Software Design

10. The Psychology and Philosophy of Design (contd.)

Example 2: Now about software engineering!

Let's say that you are talking with a person and you want to suggest how to improve a piece of
code.

You can start making suggestions to create maintainable code using standard development
principles. The other developer will understand that creating maintainable code is a good thing
and that using standard development principles is useful; you both agree.

But then when the work is done you realize the code is totally different from what you expected.
The other developer is not using standard development principles or creating maintainable code.

But wait, what exactly are "standard development principles" and the act of creating more
"maintainable code"?
Introduction to Software Design

10. The Psychology and Philosophy of Design (contd.)

Example 2: Now about software engineering! (contd.)

What if you really don't know what you are talking about?
The developer might have implemented principles that are unknown to you and you just don't
see the benefits because you lack context.

What if the other developer doesn't know what they are talking about?
The other developer might have less experience than you. Or have different opinions over
"good" principles.

What if neither of you has any idea of what good principles are?
Both of you can discuss naturally, and still, both of you can be wrong.

Answer: Aristotelian Reasoning!


Introduction to Software Design
10. The Psychology and Philosophy of Design (contd.)

• Aristotelian Reasoning (Reference: Aristotle’s The Organon)

Three tools that can be used reduce subjectivity and gap in understanding in discussions:
Definition, Predication and Inference.

Definition: ‘What-it-is-to-be’; something that differentiates (distinct) itself from others

− Essential distinctions: kind of thing it is e.g. ‘components of type A are singleton’


− Accidental distinctions: other than what it is e.g. ‘components of type A must not have
knowledge of the structure of data in components of type B’

Predication: creating statements about a subject in which a predicate is either affirmed or denied
e.g. ‘class A is-a class B’

Inference: discovery of new truths about subjects, involves the ordering of statements with the
purpose of drawing a conclusion e.g. ‘class B inherits from class A. class A is a singleton’
implies class A is a singleton
Introduction to Software Design
11. General Methodology of Design

Following are the essential elements for a good design:

• Purposeful thinking: Systematic approach (including intuition and creativity)

• Analysis: Structured decomposition of complex systems into elements and their


interrelationships, identifying essential distinctions, and discarding accidental distinctions

• Abstraction: reduces the complexity of a problem while emphasizing the essential


characteristics of it and aids in the discovery of solutions

• Synthesis: combining of individual elements or parts to produce a new effect

• General Heuristics: searching for suitable solutions


Lecture Takeaways
• Define Scope of Design
• Define psychology and philosophy of design
• Define changes and list types of change in an environment
• State different Views in Software Architecture.
• Describe the Challenges faced while implementing Software Architecture for any system
• Elaborate on how significance of Software Architecture
• Write a note on “the Vitruvian Triad”
• Describe the Modular and Design operators
• Describe the working of the RUP model with its diagram
• List at least 10 stakeholders, their responsibilities and their influence on the system with
respect to Software Architecture
• Draw the architecture design process and explain the same in detail
• Construct a Use case diagram for any given problem statement
• Define and elaborate about DSM for any given problem statement
• Develop a case study on Architectures of Block chain systems.

You might also like