Transcript ASAAM - utwente.nl
ASAAM: Aspectual Software Architecture Analysis Method
Bedir Tekinerdogan University of Twente Department of Computer Science Enschede, The Netherlands e:mail – [email protected]
http://www.cs.utwente.nl/~bedir/
Contents
Evaluating Architectures using Scenarios SAAM Example: Window Management System ASAAM Conclusion & Discussions © Bedir Tekinerdogan 2
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 © Bedir Tekinerdogan 3
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.
© Bedir Tekinerdogan 4
Software Architecture Evaluation
no Architecture (Re)definition Review Guidelines Quality Criteria Architecture Ok?
yes Go!
Implement Architecture © Bedir Tekinerdogan 5
Scenario-based evaluation
Scenario is a brief description of an interaction of a stakeholder with a system
What if… What if… What if… System What if… What if…
© Bedir Tekinerdogan 6
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.
© Bedir Tekinerdogan 7
Example: SAAM
1.
2.
3.
4.
5.
Describe candidate architectures Develop scenarios Perform scenario evaluation Reveal scenario interactions Generate overall evaluations © Bedir Tekinerdogan 8
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.
<
update screen
<
communicates notifies © Bedir Tekinerdogan 9
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
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
Component
EventManager ScreenManager WindowManager ProcessManager
Direct Scenarios
S3, S5 S4, S7 S2, S3, S6,S8 S1, S3, S9, S10
Indirect Scenarios
S12,S13,S16, S17,S18,S19 S16,18,S19,S20 S11, S14, S15, S16,S19 S13, S16,S19 © Bedir Tekinerdogan 10
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 © Bedir Tekinerdogan 11
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 © Bedir Tekinerdogan 12
refactor, refactor, refactor,....
Indirect Scenario I cannot get the architecture right?
What’s wrong...?!
Refactor no Architecture Ok?
yes Go!
Implement Architecture © Bedir Tekinerdogan 13
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 © Bedir Tekinerdogan 14
ASAAM
1.
2.
Describe candidate architecture Develop and prioritize scenarios 3.
Individual scenario evaluation and aspect identification Direct Scenarios, Indirect Scenarios, Aspectual scenarios, Architectural aspects 4.
5.
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 © Bedir Tekinerdogan 15
Heuristic rules for scenario evaluation
R0:
Develop SCENARIO artifacts based on PROBLEM DESCRIPTION
R1:
IF SCENARIO does not require any changes to architectural description THEN 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 ASPECTUAL SCENARIO from
R1
Direct Scenario
R4
Scenario
R3 R0
Aspectual Scenario
R6
Architectural Aspect
R2
Indirect Scenario
R5
© Bedir Tekinerdogan 16
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
R10
IF INDIRECT COMPONENT can be refactored to perform INDIRECT SCENARIO THEN INDIRECT COMPONENT is DIRECT COMPONENT
R11
IF DIRECT COMPONENT performs semantically close scenarios THEN DIRECT COMPONENT is COHESIVE COMPONENT
R12
IF DIRECT COMPONENT performs semantically distinct scenarios AND cannot be decomposed THEN DIRECT COMPONENT is TENTATIVE TANGLED COMPONENT
R13
IF DIRECT COMPONENT performs semantically distinct scenarios AND can be decomposed THEN DIRECT COMPONENT is COMPOSITE COMPONENT
R14:
IF INDIRECT COMPONENT includes semantically close scenarios THEN 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 R7 Component R8 R9 Component R11 Direct R12 R13 R10 Indirect Component R14 R15 R16 Cohesive Component R17 Tentative Tangled Component R18 Tangled Component ill-Defined Component Composite Component © Bedir Tekinerdogan 17
Identified Aspects and Tangled Components
Component
EventManager ScreenManager WindowManager ProcessManager
Cohesive Aspect Compos.
S5 S13,S16,S19 S14 S2,S3,S6, S8,S20 S13,S19 S16,S19 S1,S9,S10 S13,S16,S19 S12,S17 S4,S7 S11,S18,S15 -
Ill-def.
Aspects derived from scenarios S13, S16, S19: Failure Management, Monitoring, Operating System Portability © Bedir Tekinerdogan 18
Aspectual refactoring
<
communicates update screen
<
notifies
<
© Bedir Tekinerdogan 19
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.
© Bedir Tekinerdogan 20