Software Architecture – Centric Methods and Agile Development
- 1. Software Architecture – Centric Methods and Agile Development By SATHISHKUMAR G (sathishsak111@gmail.com)
- 2. The Agile Approach • Feedback – Not just for stereos anymore • Adaptable – Just in case you haven’t made up your mind • Simplicity – Let’s 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 • Iteration’s done – But the software isn’t. • At least it works…Sort 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 • Doesn’t 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 XP’s 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 ATM Quality 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 client’s 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.
- 22. Thank you