asaam aspectual software architecture analysis method l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
ASAAM: Aspectual Software Architecture Analysis Method PowerPoint Presentation
Download Presentation
ASAAM: Aspectual Software Architecture Analysis Method

Loading in 2 Seconds...

play fullscreen
1 / 20

ASAAM: Aspectual Software Architecture Analysis Method - PowerPoint PPT Presentation


  • 570 Views
  • Uploaded on

ASAAM: Aspectual Software Architecture Analysis Method Bedir Tekinerdogan University of Twente Dep artment of Computer Science Enschede, The Netherlands e:mail – bedir@cs.utwente.nl http://www.cs. utwente.nl /~bedir/ Contents Evaluating Architectures using Scenarios SAAM

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'ASAAM: Aspectual Software Architecture Analysis Method' - elina


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
asaam aspectual software architecture analysis method

ASAAM: Aspectual Software Architecture Analysis Method

Bedir TekinerdoganUniversity of Twente

Department of Computer Science

Enschede, The Netherlands

e:mail – bedir@cs.utwente.nl

http://www.cs.utwente.nl/~bedir/

contents
Contents
  • Evaluating Architectures using Scenarios
  • SAAM
  • Example: Window Management System
  • ASAAM
  • Conclusion & Discussions
implementing architecture
Implementing Architecture
  • Architecture is the earliest artifact
    • with the largest impact
    • where trade-offs are visible.
  • Implementing it requires lots of resources
    • time
    • money
    • manpower
therefore evaluate architecture early
Therefore evaluate architecture early …
  • Analyzing for system qualities early in the life cycle allows for a comparison of architectural options.
  • Predict quality of system before it has been built
  • Identify potential risks
  • Evaluation later in the project: damage control
  • Evaluation/Analysis provides a mechanism for understanding how the system will evolve.
software architecture evaluation

Architecture

(Re)definition

Review Guidelines

Quality Criteria

no

Architecture Ok?

yes

Go!

Implement Architecture

Software Architecture Evaluation
scenario based evaluation
Scenario-based evaluation
  • Scenario is a brief description of an interaction of a stakeholder with a system

What if…

What if…

System

What if…

What if…

What if…

scenario based evaluation techniques
Scenario-based evaluation techniques
  • SAAM
    • Scenario-Based Architecture Analysis Method
  • SAAMCS
    • SAAM Founded on Complex Scenario
  • ESAAMI
    • Extending SAAM by Integration In The Domain
  • SAAMER
    • Software Architecture Analysis Method Evolution and Reusability
  • ATAM
    • Architecture Trade-off Analysis Method
  • SBAR
    • Scenario-Based Architecture Re-engineering
  • ALPSM
    • Architecture Level Prediction of Software Maintenance
  • SAEM
    • A Software Architecture Evaluation Model

L.Dobrica & E.Niemela, A Survey on Software Architecture Analysis Methods,IEEE Transactions on Software Engineering, Vol 28, No. 7, pp. 638-654, July 2002.

example saam
Example: SAAM
  • Describe candidate architectures
  • Develop scenarios
  • Perform scenario evaluation
  • Reveal scenario interactions
  • Generate overall evaluations
example window management system
A window management system includes

different important components such as

EventManager for I/O controlling, e.g.

keyboard and mouse events;

Process-Manager for scheduling and managing application processes;

ScreenManager for maintaining the integrity of the screen;

WindowManager for managing the windows that are related to the application processes.

<<arch>>

EventManager

communicates

<<arch>>

ScreenManager

<<arch>>

WindowManager

update screen

notifies

<<arch>>

ProcessManager

Example: Window Management System
scenario evaluation
Scenario Evaluation
  • S1. Start multiple processes at the same time.
  • S2. Change color of widgets in the window.
  • S3. Close all open windows
  • S4. Change screen resolution
  • S5. Enter a command to start application process
  • S6. Move the main window
  • S7. Screen saver is activated
  • S8. Resize a window
  • S9. Terminate a process
  • S10. Interrupt a process

Direct Scenarios

Indirect Scenarios

  • S11. Change look-and-feel style on run-time.
  • S12. Add voice control
  • S13. A failure occurs and the system shuts down.
  • S14. Provide dual display screen.
  • S15. Use multiple desktops.
  • S16. Monitor activities of the user
  • S17. Provide touch screen and light pen as input
  • S18. A memory overflow due to many opened windows
  • S19. Port system to command-based operation system
  • S20. Minimize windows after idle time for each
the good and the bad
The good and the bad

Scenario interactions can mean:

  • Scenarios are semantically related
    • good scenario interactions
    • shows the cohesiveness of components
  • Scenarios are semantically distinct
    • bad scenario interactions
    • architecture must be refactored
different indirect scenarios
Different indirect scenarios...

Indirect Scenarios

  • S11. Change look-and-feel style on run-time.
  • S12. Add voice control
  • S13. A failure occurs and the system shuts down.
  • S14. Provide dual display screen.
  • S15. Use multiple desktops.
  • S16. Monitor activities of the user
  • S17. Provide touch screen and light pen as input
  • S18. A memory overflow due to many opened windows
  • S19. Port system to command-based operation system
  • S20. Minimize windows after idle time for each
refactor refactor refactor

I cannot get the architecture right?

What’s wrong...?!

Refactor

yes

Go!

Implement Architecture

refactor, refactor, refactor,....

Indirect Scenario

no

Architecture Ok?

the good the bad and the ugly
The good, the bad and the ugly...
  • Current architecture evaluation methods do not explicitly consider potential aspects (the ugly )
  • Therefore it is not possible to detect these at the software architecture design level.
  • Undetected aspects will still pop up later in the software development life cycle.
  • This is too late,
  • and will lead to aspectual problems
  • which is as such contrary to purpose of architecture evaluation approaches
asaam
ASAAM
  • Describe candidate architecture
  • Develop and prioritize scenarios
  • Individual scenario evaluation and aspect identification
    • Direct Scenarios, Indirect Scenarios, Aspectual scenarios, Architectural aspects
  • Scenario interaction evaluation and component classification
    • Cohesive component, tangled component, composite component, ill-defined component
  • Refactor architecture
    • using conventional techniques (OO, patterns etc.)
    • using aspect-oriented techniques
heuristic rules for scenario evaluation
Heuristic rules for scenario evaluation
  • R0:Develop SCENARIO artifacts based on PROBLEM DESCRIPTION
  • R1:IF SCENARIO does not require any changes to architectural descriptionTHEN SCENARIO becomes DIRECT SCENARIO
  • R2: IF SCENARIO requires changes to one or more ARCHITECTURAL COMPONENTs THEN SCENARIO becomes INDIRECT SCENARIO
  • R3:IF INDIRECT SCENARIO can be resolved after refactoring THEN INDIRECT SCENARIO is DIRECT SCENARIO
  • R4:IF DIRECT SCENARIO is scattered and cannot be localized in one component THEN DIRECT SCENARIO is ASPECTUAL SCENARIO
  • R5:IF INDIRECT SCENARIO is scattered and cannot be localized in one component THEN INDIRECT SCENARIO is ASPECTUAL SCENARIO
  • R6:Derive ARCHITECTURAL ASPECT from ASPECTUAL SCENARIO

R0

Scenario

R1

R2

Direct

Scenario

Indirect

Scenario

R3

R4

R5

Aspectual

Scenario

R6

Architectural

Aspect

heuristic rules for component classification
Heuristic Rules for Component Classification
  • R7: Select COMPONENT from ARCHITECTURE
  • R8:IF COMPONENT is not affected by a SCENARIO THEN component is DIRECT COMPONENT for SCENARIO
  • R9:IF COMPONENT is affected by one or more SCENARIO THEN component is INDIRECT COMPONENT for SCENARIO
  • R10IF INDIRECT COMPONENT can be refactored to perform INDIRECT SCENARIO THEN INDIRECT COMPONENT is DIRECT COMPONENT
  • R11IF DIRECT COMPONENT performs semantically close scenarios THEN DIRECT COMPONENT is COHESIVE COMPONENT
  • R12IF DIRECT COMPONENT performs semantically distinct scenarios AND cannot be decomposed THEN DIRECT COMPONENT is TENTATIVE TANGLED COMPONENT
  • R13IF DIRECT COMPONENT performs semantically distinct scenarios AND can be decomposed THEN DIRECT COMPONENT is COMPOSITE COMPONENT
  • R14:IF INDIRECT COMPONENT includes semantically close scenariosTHEN INDIRECT COMPONENT is COHESIVE COMPONENT
  • R15:IF INDIRECT COMPONENT includes semantically distinct scenarios AND cannot be decomposed THEN COMPONENT becomes TENTATIVE TANGLED COMPONENT
  • R16:IF INDIRECT COMPONENT includes semantically distinct scenarios AND can be decomposed THEN INDIRECT COMPONENT is COMPOSITE COMPONENT
  • R17:IF TENTATIVE TANGLED COMPONENT includes ASPECTUAL SCENARIO THEN TENTATIVE TANGLED COMPONENT is TANGLED COMPONENT for given aspectual scenario
  • R18:IF TENTATIVE TANGLED COMPONENT does not include ASPECTUAL SCENARIO THEN TENTATIVE TANGLED COMPONENT is Ill-DEFINED COMPONENT
identified aspects and tangled components
Identified Aspects and Tangled Components

Aspects derived from scenarios S13, S16, S19: Failure Management, Monitoring, Operating System Portability

aspectual refactoring

<<arch-aspect>>

EventManager

<<pointcut>> recover()

Aspectual refactoring

<<arch>>

EventManager

communicates

update

screen

<<arch>>

ScreenManager

<<arch>>

WindowManager

notifies

<<arch>>

ProcessManager

conclusion
Conclusion
  • Architectural aspects exist
    • e.g. failure management, monitoring, operating system portability
  • ASAAM extends existing scenario based software architecture analysis methods
  • to explicitly identify architectural aspects
  • and pinpoint aspectual refactoring for corresponding aspects.