Scenario-Based Analysis of Software Architecture Rick Kazman, Gregory Abowd, Len Bass, and Paul Clements Presented by Cuauhtémoc Muñoz.

Slides:



Advertisements
Similar presentations
Dr. Rogelio Dávila Pérez
Advertisements

ARCH-05 Application Prophecy UML 101 Peter Varhol Principal Product Manager.
Ch 3 System Development Environment
Traditional Approach to Design
Outline About author. The problem that discussed in the article.
SE 555 Software Requirements & Specification Requirements Management.
Week 8 Implementation Design Alex Baker. Implementation Design System Design – Describes what the system should do Implementation Design – Describes what.
Model Driven Architecture (MDA) Partha Kuchana. Agenda What is MDA Modeling Approaches MDA in a NutShell MDA Models SDLC MDA Models (an Example) MDA -
Software Architecture Quality. Outline Importance of assessing software architecture Better predict the quality of the system to be built How to improve.
Course Instructor: Aisha Azeem
Automated Tests in NICOS Nightly Control System Alexander Undrus Brookhaven National Laboratory, Upton, NY Software testing is a difficult, time-consuming.
Software architecture evaluation
Software Architecture. Agenda " Why architect? " What is architecture? " What does an architect do? " What principles guide the process of architecting?
Software maintenance Managing the processes of system change.
Architecture Tradeoff Analysis Method Based on presentations by Kim and Kazman
1 Object-Oriented Software Engineering CIS 375 Bruce R. Maxim UM-Dearborn.
Methods and Models for Evaluating Software Product Line Architecture Hyotaeg Jung Computer Science Department Univ. of Texas at Dallas Software Architecture.
SEG Software Maintenance1 Software Maintenance “The modification of a software product after delivery to correct faults, to improve performance or.
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 3: Phase Management - Inception.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Evaluating Architectures: ATAM
Thirteenth Lecture Hour 8:30 – 9:20 am, Sunday, September 16 Software Management Disciplines Process Automation (from Part III, Chapter 12 of Royce’ book)
ATAM –Cont’d SEG 3202 N. Elkadri.
CSE 303 – Software Design and Architecture
OHTO -99 SOFTWARE ENGINEERING LECTURE 5 Today: - An overview to OO Analysis and OO Design - Introduction of Assignment 2.
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
 CS 5380 Software Engineering Chapter 2 – Software Processes Chapter 2 Software Processes1.
1 Chapter 5 Software Engineering Practice. 2 What is “Practice”? Practice is a broad array of concepts, principles, methods, and tools that you must consider.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Requirements Engineering ments_analysis.
Software Architecture in Practice Architectural description (The reduced version)
SOFTWARE DESIGN Design Concepts Design is a meaningful engineering representation of something that is to be built It can be traced to a customer’s requirements.
Drexel University CS 451 Software Engineering Winter Yuanfang Cai Room 104, University Crossings
Component Technology. Challenges Facing the Software Industry Today’s applications are large & complex – time consuming to develop, difficult and costly.
1 Systems Analysis and Design in a Changing World, Thursday, January 18, 2007.
Team Think For You. Outline  Introduction  Process  Requirements Engineering  Architecture  Detailed Design  Testing  Demo  Extensibility  Conclusions.
Assessing the influence on processes when evolving the software architecture By Larsson S, Wall A, Wallin P Parul Patel.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
CPSC 372 John D. McGregor Module 3 Session 1 Architecture.
Software Architecture Assessment RAVI CHUNDURU CS6362 UTD Summer 2005.
Part4 Methodology of Database Design Chapter 07- Overview of Conceptual Database Design Lu Wei College of Software and Microelectronics Northwestern Polytechnical.
Configuration Management and Change Control Change is inevitable! So it has to be planned for and managed.
CPSC 871 John D. McGregor Module 3 Session 1 Architecture.
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
Software Requirements: A More Rigorous Look 1. Features and Use Cases at a High Level of Abstraction  Helps to better understand the main characteristics.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
CSE 303 – Software Design and Architecture
Overview of SAIP and LSSA. Software Architecture in Practice Provides a set of techniques, not a prescriptive method for architectural design. Based on.
Review of Parnas’ Criteria for Decomposing Systems into Modules Zheng Wang, Yuan Zhang Michigan State University 04/19/2002.
Software Architecture Design Processes
Requirements Engineering ments_analysis.
CHAPTER 3 MODELING COMPONENT-LEVEL DESIGN.
Architecture Tradeoff Analysis Method Software Engineering Institute Carnegie Mellon University Presented by: Senthil ayyasamy CS 590l- winter 2003.
 CMMI  REQUIREMENT DEVELOPMENT  SPECIFIC AND GENERIC GOALS  SG1: Develop CUSTOMER Requirement  SG2: Develop Product Requirement  SG3: Analyze.
4+1 View Model of Software Architecture
Week 6: Software Design HNDIT Software Engineering Software Design Learning Outcomes  Understand the activities involved in the Design process.
CS223: Software Engineering Lecture 13: Software Architecture.
Lecture 17 Enterprise Systems Development ( CSC447 ) COMSATS Islamabad Muhammad Usman, Assistant Professor.
Chapter 7: Modifiability
Chapter 24: Architecture Competence
Chapter 25: Architecture and Product Lines
Component Based Software Engineering
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Software Architecture Analysis Method
System Reengineering Restructuring or rewriting part or all of a system without changing its functionality Applicable when some (but not all) subsystems.
Coupling Interaction: It occurs due to methods of a class invoking methods of other classes. Component Coupling: refers to interaction between two classes.
Software Architecture Analysis Method
Presentation transcript:

Scenario-Based Analysis of Software Architecture Rick Kazman, Gregory Abowd, Len Bass, and Paul Clements Presented by Cuauhtémoc Muñoz

Outline Software Architecture Analysis Method Overview Software Architecture Analysis Method Activities WRCS: Case Study Advantages of SAAM Conclusion

SAAM Overview Software Architecture Analysis Method (SAAM) – Scenarios – Quality attributes Why Scenarios? – Quality attributes and roles

SAAM Activities Describe the candidate architecture Develop Scenarios Evaluate each scenario Reveal scenario interactions Weight scenarios and scenarios interactions * Dependencies

SAAM

WRCS: Case Study (1/11) WRCS – Version control/configuration management system. – Functions: create projects, compare files, check files in and out, create releases, back up to old versions, etc.

WRCS Case Study (2/11) Applying SAAM: 1. Describe candidate architecture: – Reverse engineering. – Level of abstraction above source code. – Architectural description done iteratively. Three iterations in this case.

WRCS Case Study (3/11)

WRCS Case Study (4/11) 2. Develop scenarios – Stakeholder representations (e.g. customer). – For the user role: Compare binary file representations. Compare binary files generated by other products. Configure the toolbar. Manage multiple projects – For the maintainer role: Port to another operating system. Modify the user interface in minor ways.

WRCS Case Study (5/11) – For the administrator role: Change access permissions for a project. Integrate WRCS functionality with a new development environment. Port to a different network-management system.

WRCS Case Study (6/11) 3. Evaluate each scenario – Direct and indirect scenarios Focus on indirect scenarios. – Estimate the cost of indirect scenarios Minimal cost (e.g. modifications to a resource file). Moderate cost (e.g. recompilation). Considerable cost (e.g. restructuration of code).

WRCS Case Study (7/11)

WRCS Case Study (8/11) 4. Reveal scenario interactions – Focus on scenarios with the most interactions.

WRCS Case Study (9/11)

WRCS Case Study (10/11) 5. Weight scenarios and scenario interactions – Prioritize scenarios based on organizational requirements and preferences of the SAAM user.

WRCS Case Study (11/11) Results: – Severe limitations in achieving portability and modifiability. – SAAM exposed specific product’s limitations in a simple, straightforward, and cost effective way.

Advantages of SAAM (1/3) Enhanced communication – Scenarios. – Visualizations Improvement of traditional metrics – Coupling and cohesion Low coupling, high cohesion. Proper description level – Higher level of abstraction

Advantages of SAAM (2/3) – Mapping of scenarios onto the structure Highlight components and connections that will be affected by the change the scenario implies. Architectural evaluation. Validation of scenario interaction. Appropriate level of architectural representation. – Example: A case in which multiple indirect scenarios affect a single module. Three possibilities:

Advantages of SAAM (3/3) The scenarios are of the same class. The scenarios are of different classes and you can further divide the module. The scenarios are of different classes and you cannot further divide the module. Efficient scenario generation – Like software testing.

Conclusion SAAM has been applied to large-scale industrial systems such as “Global Information System” and “Air Traffic Control System.” Future plans include the extension of this technique from maintainability and modifiability to execution-based measures such as performance and reliability.