How%20to%20hear%20this%20lecture

1
How to hear this lecture

• Click on the icon to hear the
  narration for each slide.

2
Fisher logo

Lecture 7 - Architecture Dr. Rajiv
Ramnath Director Collaborative for Enterprise
Transformation and Innovation (CETI) Department
of Computer Science and Engineering, College of
Engineering The Ohio State University Ramnath.6_at_os
u.edu http//www.ceti.cse.ohio-state.edu

• fisher.osu.edu

Partnership for Performance
3
Software Architecture

• The software architecture of a computing system
  is the structure(s) of the system, which comprise
  software elements, the externally visible
  properties of these elements, and the
  relationships between them.

Courtesy SEI
Ref Software Architecture In Practice, Len Bass
et. al., Safari
4
Things Common to All Architectures

• Goals that lead to quality attributes
  Performance, Availability etc.
• Modules and layers
• Needing multiple views to describe
• Static structure and dynamic behavior
• Tradeoffs
• Leading to common ways of defining, describing,
  creating, analyzing, evaluating, and documenting.

5
Styles of Architectural Views

• Module
• Decomposition contains
• Uses DEPENDS on the CORRECT execution of
• Layered constrains what calls what
• Component-and-Connector
• Process, concurrency, shared data (flow),
  client-server
• Allocation
• Deployment to infrastructure
• Implementation to file structure
• Work-assignment to teams
• Reason for Views? To systematically understand
  the functioning of the system and how it
  implements its quality attributes

Ref Software Architecture In Practice, Len Bass
et. al., Safari
6
41 View Model of Software Architecture
7

• Designing Architecture

8
Attribute Driven Design a Recursive
Decomposition Process

• Start with a module (in the beginning, the
  system) and refine it, as follows
• Create a prioritization of the architectural
  requirements functional and NFR (most relevant)
  quantified into Quality Attributes
• Starting with the 1st requirement, design the
  architecture using architectural tactics
• Decompose into child modules and interfaces as
  necessary
• Verify using use cases and quality scenarios
• Document this design using views

9
Quality Attributes

• System quality
• Availability
• Modifiability (includes scalability, portability)
• Performance
• Security
• Usability
• Testability
• Business qualities
• Time to market, cost/benefit, lifetime, target
  market, schedule, integration

Ref Software Architecture In Practice, Len Bass
et. al., Safari
10
Tactics for implementing Quality Attributes - 1

• Availability
• Fault detection Ping, heartbeat, exception
• Recovery Redundancy (active, passive), reboot
• Prevention Demand management, transactions
• Modifiability (including Extensibility and
  Scalability
• Localize, prevent ripple effects, defer binding
  time, limit allowable modifications
• Essentially Reduce coupling and increase
  cohesion
• Performance
• Reduce resource use (memory, communications,
  data)
• Reduce switching
• Increase resources
• Increase parallelism
• Control demand

Ref Software Architecture In Practice, Len Bass
et. al., Safari
11
Tactics for implementing Quality Attributes - 2

• Usability
• Runtime Feedback, use task, user and system
  models
• Design time Separate UI (modifiability tactic)
• Testability
• Goal Show the PRESENCE of faults
• Record/playback,
• Stub interface from implementation
• Specialized testing interface
• Use internal monitoring
• Security
• Detect Monitor and compare access patterns,
  store and analyze data
• Resist Authentication, levels of authorization
  to , limit exposure by limiting access,
  encryption, preservation of integrity through
  checksums
• Recover availability tactics, audit trails for
  identification and investigation

Ref Software Architecture In Practice, Len Bass
et. al., Safari
12

• Analyzing and Validating Architecture using The
  Architectural Tradeoff Analysis Method (ATAM)

13
ATAM Component - Scenarios

• Scenarios are used to
• Understand quality attributes
• Scenarios should cover a range of
• Anticipated uses of (use case scenarios),
• Anticipated changes to (growth scenarios), or
• Unanticipated stresses (exploratory scenarios) to
  the system.
• A good scenario makes clear what the stimulus is
  that causes it and what responses are of
  interest.
• Where have you seen this before? Acceptance
  Tests!!

Ref Software Architecture In Practice, Len Bass
et. al., Safari
14
ATAM Component - Utility Tree
Ref Software Architecture In Practice, Len Bass
et. al., Safari
15
ATAM Scenario Examples

• Use case scenario
• Remote user requests a database report via the
  Web during peak period and receives it within 5
  seconds.
• Growth scenario
• Add a new data server to reduce latency in
  scenario 1 to 2.5 seconds within 1 person-week.
• Exploratory scenario
• Half of the servers go down during normal
  operation without affecting overall system
  availability.
• Scenarios should be as specific as possible.

Ref Software Architecture In Practice, Len Bass
et. al., Safari
16
ATAM - Analyze Architectural Approaches

• Scenarios
• Used to Pose
• Architecture
• Questions

Ref Software Architecture In Practice, Len Bass
et. al., Safari
17
ATAM - Analysis Examples

• Scenario-based questions elicit the
  architectural decisions made.
• Examples
• Performance
• How are priorities assigned to processes?
• What are the message arrival rates?
• What are transaction processing times?
• Modifiability
• Are there any places where layers/facades are
  circumvented ?
• What components rely on detailed knowledge of
  message formats?
• What components are connected asynchronously?

Ref Software Architecture In Practice, Len Bass
et. al., Safari
18
ATAM - Sensitivity, Tradeoffs and Risks

• Sensitivity A property of a component that is
  critical to success of system.
• The number of simultaneous database clients will
  affect the number of transaction a database can
  process per second. This assignment is a
  sensitivity point for the performance
• Keeping a backup database affects reliability
• Power of encryption (Security) sensitive to
  number of bits of the key
• Tradeoff point- A property that affects more than
  one attribute or sensitivity point.
• In order to achieve the required level of
  performance in the discrete event generation
  component, assembly language had to be used
  thereby reducing the portability of this
  component.
• Keeping the backup database affects performance
  also so its a trade-off between reliability and
  performance
• Risk point - If a sensitivity or tradeoff point
  is close to limits, this is a risk point

Ref Software Architecture In Practice, Len Bass
et. al., Safari
19
How Much Architecting Is Needed?
Ref Software Architecture In Practice, Len Bass
et. al., Safari
20

• Architecture Work-Products

21
Architecture Work-Products

• Target environment
• 41 Deployment view
• Subsystem model
• 41 Conceptual view
• System Architecture
• Other views

22
Target environment

• Hardware, OS and runtime environment
• Purpose is to document deployment environment
• Participants - customer and system architects
• Timing - along with NFRs and then elaborated at
  design
• Technique - start with NFRs
• Notation Free format text with appropriate
  diagrams.

23
Subsystem model

• Delegation of system responsibilities into
  subsystems
• Clearly define interfaces
• Participants
• Architects, project manager
• Timing
• Along with system architecture
• Technique
• If possible start with analysis
• Use facades

24
System Architecture

• Global, project-wide design decisions on
• Layering, communication patterns, distribution,
  persistence, security, error-handling and
  recovery, debugging, reuse
• Application, application support and utility
  sub-domains
• Usually done by one person
• Technique
• Start with prioritized NFRs with global impact
  (performance, error handling, UI etc.)
• If an NFR does not exist, create appropriate ones
  at this stage!
• Make architectural decisions to meet these
• Transform a set of Analysis Sequence Diagrams to
  validate these decisions

25
The End