SA Module 2
SA Module 2
SA Module 2
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
Architectural Description
Architecture Design Process
• Hierarchy of Components
Architecture Design Process
3. Identifying design elements and their relationships (contd.)
Define the
System Context
Identify the
Modules
Describe
Components and
Controllers
Architectural Description
Architecture Design Process
3. Identifying design elements and their relationships (contd.)
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
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
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
• 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
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.
• 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
• Design Tasks
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.)
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.)
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
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
Obstacle
Design
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
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
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.
Three tools that can be used reduce subjectivity and gap in understanding in discussions:
Definition, Predication and Inference.
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