ASAAM: Aspectual Software Architecture Analysis Method

1
ASAAM Aspectual Software Architecture Analysis
Method
Bedir TekinerdoganUniversity of
Twente Department of Computer Science Enschede,
The Netherlands email bedir_at_cs.utwente.nl http
//www.cs.utwente.nl/bedir/
2
Contents

• Evaluating Architectures using Scenarios
• SAAM
• Example Window Management System
• ASAAM
• Conclusion Discussions

3
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

4
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.

5
Software Architecture Evaluation
6
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
7
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.
8
Example SAAM

1. Describe candidate architectures
2. Develop scenarios
3. Perform scenario evaluation
4. Reveal scenario interactions
5. Generate overall evaluations

9
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.

10
Scenario Evaluation
Direct Scenarios

• 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

Component Direct Scenarios Indirect Scenarios
EventManager S3, S5 S12,S13,S16, S17,S18,S19
ScreenManager S4, S7 S16,18,S19,S20
WindowManager S2, S3, S6,S8 S11, S14, S15, S16,S19
ProcessManager S1, S3, S9, S10 S13, S16,S19
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

11
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

12
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

13
refactor, refactor, refactor,....
Indirect Scenario
no ?
Architecture Ok?
14
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

15
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

16
Heuristic rules for scenario evaluation

• R0Develop SCENARIO artifacts based on PROBLEM
  DESCRIPTION
• R1IF 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
• R3IF INDIRECT SCENARIO can be resolved after
  refactoring THEN INDIRECT SCENARIO is DIRECT
  SCENARIO
• R4IF DIRECT SCENARIO is scattered and cannot be
  localized in one component THEN DIRECT SCENARIO
  is ASPECTUAL SCENARIO
• R5IF INDIRECT SCENARIO is scattered and cannot
  be localized in one component THEN INDIRECT
  SCENARIO is ASPECTUAL SCENARIO
• R6Derive ARCHITECTURAL ASPECT from ASPECTUAL
  SCENARIO

R0
Scenario
R1
R2
Direct Scenario
Indirect Scenario
R3
R4
R5
Aspectual Scenario
R6
Architectural Aspect
17
Heuristic Rules for Component Classification

• R7 Select COMPONENT from ARCHITECTURE
• R8IF COMPONENT is not affected by a SCENARIO
  THEN component is DIRECT COMPONENT for SCENARIO
• R9IF 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
• R14IF INDIRECT COMPONENT includes semantically
  close scenariosTHEN INDIRECT COMPONENT is
  COHESIVE COMPONENT
• R15IF INDIRECT COMPONENT includes semantically
  distinct scenarios AND cannot be decomposed THEN
  COMPONENT becomes TENTATIVE TANGLED COMPONENT
• R16IF INDIRECT COMPONENT includes semantically
  distinct scenarios AND can be decomposed THEN
  INDIRECT COMPONENT is COMPOSITE COMPONENT
• R17IF TENTATIVE TANGLED COMPONENT includes
  ASPECTUAL SCENARIO THEN TENTATIVE TANGLED
  COMPONENT is TANGLED COMPONENT for given
  aspectual scenario
• R18IF TENTATIVE TANGLED COMPONENT does not
  include ASPECTUAL SCENARIO THEN TENTATIVE
  TANGLED COMPONENT is Ill-DEFINED COMPONENT

18
Identified Aspects and Tangled Components
Component Cohesive Aspect Compos. Ill-def.
EventManager S5 S13,S16,S19 S12,S17 -
ScreenManager S14 S13,S19 S4,S7 -
WindowManager S2,S3,S6, S8,S20 S16,S19 S11,S18,S15 -
ProcessManager S1,S9,S10 S13,S16,S19 -
Aspects derived from scenarios S13, S16, S19
Failure Management, Monitoring, Operating
System Portability
19
Aspectual refactoring
ltltarchgtgt EventManager
communicates
update screen
ltltarchgtgt WindowManager
ltltarchgtgt ScreenManager
notifies
ltltarchgtgt ProcessManager
20
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.