Software Architecture

1
Software Architecture Centric Methods and
Agile Development

• by Craig Castaneda

2
The Agile Approach

• Feedback Not just for stereos anymore
• Adaptable Just in case you havent made up your
  mind
• Simplicity Lets keep it that way
• Small Groups Because the boss is cheap

3
The Agile Approach

• Short Development Iterations
• Plan
• Gather Requirements
• Design
• Code
• Test
• Document

4
The Agile Approach

• Iterations done But the software isnt.
• At least it worksSort of
• Resolution is the solution

5
The Agile Approach - Extreme Programming (XP)

• Planning User Stories, Prioritizing
• Testing Test comes before code
• Implementation Simplest code to fulfill the
  test
• Design System metaphors, spike solutions, CRC
  cards

6
Extreme Programming (XP) Criticisms

• Doesnt scale to large dev teams or products
• Success is a function of the dev teams experience
• Not for critical systems
• Tends to overlook software quality attributes
• Customer On-Site necessary

7
Software Architecture Centric Methods to the
Rescue!!!!

• Architecture Centric Activities
• Emphasize quality attributes
• Focus early on architecture design decisions

8
The Architecture Centric Activities

• Quality Attribute workshop
• Attribute Driven Design
• Architecture Trade-off Analysis Method (ATAM)
• Cost-Benefit Analysis Method

9
Quality Attribute Workshop

• Goal To identify requirements
• Held early in development
• Includes stakeholders
• Outputs
• Business Goals
• Quality Attribute Scenarios and Use Cases
• Scenarios are six fold (stimulus, source of the
  stimulus, artifact, environment, response, and
  response measure)

10
Attribute Driven Design

• Goal To localize the effects of design changes
• Focuses on the overall system structure that the
  quality attributes shape
• Choice of architectural tactics to satisfy
  quality scenarios
• Outputs
• Course Grain Architectural Structure
• Generate and Test architectural design model

11
Architecture Trade-off Analysis Method (ATAM)

• Goal Assess architectural decisions
  consequences with respect to requirements and
  business goals
• Helps stakeholders ask the right questions to
  discover problematic architectural decisions

12
Cost-Benefit Analysis Method(CBAM)

• Goal To make the decisions made during the ATAM
  part of the roadmap by assigning priorities,
  costs and benefits with each architectural
  decision
• Business consequences allow the dev team to make
  informed choices among architectural options

13
Sample Example Bank ATM

• From XPs user stories we receive
• Feature requirements
• From the QAW process we identify additional
  quality attributes that need to be satisfied
• Modifiability
• Extensibility
• Performance

14
Sample Example Bank ATMQuality Attribute
Workshop

• Modifiability Attribute Scenario I
• A developer wants to add a new auditing business
  rule at design time in 10 person-days without
  affecting other functionality
• Modifiability Attribute Scenario II
• A system administrator wants to employ a new
  database in 18 person-months without affecting
  other functionality

15
Sample Example Bank ATM Quality Attribute
Workshop

• Modifiability Attribute Scenario III
• A developer needs to add a Web-based client in 90
  person-days without affecting the existing ATM
  clients functionality

16
Modifiability Scenario I

• Stimulus Adding a Business Rule
• Source The Developer
• Artifact Business Rule System
• Environment New Business Rule
• Response Business Rule added within 10 Days
• Response Measure Business Rule is added and
  Existing functionality is unchanged

17
Modifiability Scenario II

• Stimulus Employing a new Database
• Source A System Administrator
• Artifact Data Organization and Storage
• Environment New Platform
• Response Database employed within 18
  person-months
• Response Measure Database Deployed and In Use.
  Existing functionality is unchanged

18
Modifiability Scenario III

• Stimulus Adding an Additional Client
• Source The Developer
• Artifact User Interface
• Environment New Capability
• Response Business Rule added within 10 Days
• Response Measure Business Rule is added and
  Existing functionality is unchanged

19
Attribute Driven Design Results

• The ADD method localizes the effect of this
  design change by using the following tactics
• Localize Changes Identifies three separate
  components of the system, Business Rules, Client,
  and Database
• Use an intermediary
• These components should be separate
• The Business Rules and Database should
  communicate through an abstract interface (ODBC)
• There should be a translation layer between the
  client and the business rules (XML)

20
Cost-Benefit Analysis Method

• CBAM helps architects consider the return on
  investment of any architectural decision and
  provides guidance on the economic trade-offs
  involved.
• Sample Performance Quality Attributes in the
  Sample Problem

21
Summary

• Architecture-centric methods provide explicit and
  detailed guidance on eliciting architectural
  requirements, designing those requirements into
  the system, and analyzing the resulting design.
  The results of which can be tailored to an agile
  approach.
• This tactic can help to resolve one of agile
  developments largest weaknesses. Improving
  overall quality of the final product.