Upload
sybill-flowers
View
51
Download
11
Tags:
Embed Size (px)
DESCRIPTION
CS 586 – Aspect-Oriented Software Development Aspect-Oriented Design - Method. Bedir Tekinerdogan Billkent University, Dep artment of Computer Engineering Bilkent, Turkey, Ankara e:mail - [email protected] http://www.cs.bilkent.edu.tr/~bedir/. Table of Contents. Problem Statement - PowerPoint PPT Presentation
Citation preview
CS 586 – Aspect-Oriented Software Development
Aspect-Oriented Design - Method
Bedir Tekinerdogan
Billkent University,
Department of Computer Engineering
Bilkent, Turkey, Ankarae:mail - [email protected]
http://www.cs.bilkent.edu.tr/~bedir/
2© Bedir Tekinerdogan
Problem Statement Scenario-based Analysis of Software
Architecture ASpectual SAAM (ASAAM) Modeling Aspects using Domain Analysis
Table of Contents
3© Bedir Tekinerdogan
Aspect-Oriented Programming Crosscutting and tangling at code level Modeling aspects at code level
Aspect-Oriented Design Modeling aspects at design level (Model) Identifying aspects (Method)
4© Bedir Tekinerdogan
Current aspect identification approaches In general ad-hoc
“aspects are for the picking...” Usually based on code-analysis:
“Assume the given example....Concerns crosscuts code and is tangled in classes...”
class Point { void setX(int x) {
_x = x;
}}
Tracer.traceEntry(“Point.set”);
Tracer.traceExit(“Point.set”);
DisplayTracker.updatePoint(this);
5© Bedir Tekinerdogan
Characteristics of an aspect...
Systemic, tends to affect multiple components
Cross-cuts, spread over different components
Affects performance/quality
6© Bedir Tekinerdogan
Aspect identification...
Analysis
Design
Implementation
Testing
Requirements Analysis
Domain Analysis
Problem
Solution
Aspects?!Where?
7© Bedir Tekinerdogan
software developm
ent
Analysis
Design
Implementation
Testing
Requirements Analysis
Domain Analysis
Systemic, cross-cuts and relates to quality…
Hmmm…There is an aspect, and
there, and there too,ooh and over there...
Where are the aspects?
8© Bedir Tekinerdogan
Late Aspect Identification
Too late!
Analysis
Design
Implementation
Testing
Requirements Analysis
Domain Analysis
Missing early aspects.
Difficult to model aspects.
9© Bedir Tekinerdogan
Modeling Aspects
class Point { void setX(int x) {
_x = x;
}}
Tracer.traceEntry(“Point.set”);
Tracer.traceExit(“Point.set”);
DisplayTracker.updatePoint(this);
Alright, tracing is an aspectBut what is tracing/how to model this?
10© Bedir Tekinerdogan
Early Aspect Identification
Analysis
Design
Implementation
Testing
Requirements Analysis
Domain Analysis
All relevant aspects can be identified.
Modeling aspects from domain knowledge.
11© Bedir Tekinerdogan
What is a method?Webster's dictionary: Method: 1: a procedure or process for attaining
an object: as a (1): a systematic procedure, technique, or mode of inquiry employed by or proper to a particular discipline or art (2): a systematic plan followed in presenting material for instruction b (1): a way, technique, or process of or for doing something (2): a body of skills or techniques.
Methodology: A branch of philosophy dealing with the science of method; a system of methods and rules applied in a science.
12© Bedir Tekinerdogan
Guidelines for production Guidelines for verification Provides logical consistency among the different
processes and phases in design. Helps to reduce possible errors Helps to identify important progress milestones.
Rationale for method
13© Bedir Tekinerdogan
Aspect-Oriented Method Identifying Specifying Evaluating aspects
in a systematic way
14© Bedir Tekinerdogan
Guidelines for identification/production of aspects
Guidelines for verification of aspects Provides logical consistency among the different
processes and phases in design; consistency for/with aspects.
Helps to reduce possible errors in aspect-oriented programs/designs
Helps to identify important progress milestones.
Rationale for aspect-oriented method
15© Bedir Tekinerdogan
Software engineering
methodm
applicationn
modelo
tools1
application layer
method layer
model layer
support layerDriver
Monitoringsystem
objects,classes
inheritance
Method
CASE,OO
compiler
16© Bedir Tekinerdogan
What is a method?
Usecases
entities
classes associations STD
attributesinheritance
Ifthen ..
Ifthen ..
Ifthen ..
Ifthen ..
Ifthen .. If
then ..
Ifthen ..
Rules (heuristics)
Process
Artifacts
17© Bedir Tekinerdogan
Example: Requirements Analysis Models
use case actor
Rules Identify Actors Identify Use Case Draw the use case diagram
Process Application
Use case
Actor
Monitor Driver Actions
Track SteeringMovement
Track BrakeManeuvers
Monitor
Track TransmissionManeuvers
ASAAM: Aspectual Software Architecture Analysis Method
Bedir Tekinerdogan
Billkent University,
Department of Computer Engineering
Bilkent, Turkey, Ankarae:mail - [email protected]
http://www.cs.bilkent.edu.tr/~bedir/
20© Bedir Tekinerdogan
Contents Software Architecture Evaluating Architectures using Scenarios SAAM Example: Window Management System
Architectural Aspects ASAAM Conclusion & Discussions
21© Bedir Tekinerdogan
Architecture
Describes (is) StructureConsisting of componentswhich forms the foundation of the whole....
22© Bedir Tekinerdogan
Intuitive notion of software architecture
Software Architecture represents the gross level structure of a software system.
Design : Implementation = Software Architecture : Design
23© Bedir Tekinerdogan
Design, Realize and Test Architecture
Software Architecture Design
Requirements Analysis
Implementation
....... ....... ....... .......
public class Student {private String name;private int id;public String getName ()return name}public void setName (String str){name = str;}public int getId(){return id; }public void setId(int i){id = i; }}
Analysis & DesignComputer Science
Electrical Engineering
Transcript
courseGrades
gradeForCourse()
Department
namedeaninstructorsstudents
...()
Course
namenumberdepartmentprerequisitecredit
Student
nametranscriptschedule
gradeInCourse()setId()getId()
Registrar
theRegistrar aSection theTranscriptaStudent
state of prereqhave
prereqenroll
ed
enrollInSection:
return sections
getSectionsFor:
addStudent:
enrolled
takenCourse: prerequisite
takenCourse: prerequisite
24© Bedir Tekinerdogan
Rationale for Software Architecture Improved understanding because of a higher
level abstract specification Guides construction since it embodies earliest
design decisions Supports stakeholder communication Support for large-grained reuse Enables to evaluate system before it is
implemented Controls impact of change Management of software development activities
25© Bedir Tekinerdogan
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
26© Bedir Tekinerdogan
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 Evaluation/Analysis provides a mechanism for
understanding how the system will evolve. Identify potential risks Evaluation later in the project: damage control
27© Bedir Tekinerdogan
Architecture Ok?
Architecture(Re)definition
Go!Implement Architecture
yes
no
Review GuidelinesQuality Criteria
Software Architecture Evaluation
28© Bedir Tekinerdogan
Evaluation Techniques Simulations Mathematical Modeling Question-based
Questionnaire-based List of general open questions that apply to all software
architectures (see project review guidelines). Checklist-based
detailed set of questions after experience of analyzing common set of systems usually domain specific
Scenario-based analysis
29© Bedir Tekinerdogan
Scenarios Scenario is a brief description of an interaction of a
stakeholder with a system
System
What if…
What if…
What if…
What if…
What if…
30© Bedir Tekinerdogan
Stakeholders Stakeholders:
end users managers developers maintainers analysts designer testers customers ....
31© Bedir Tekinerdogan
Quality Correctness does software do what its supposed
to? Flexibility how easy is it to change it? Security how secure is it? Interoperability does it interface easily? Maintainability how easy is it to repair? Portability how easy is it to transport? Usability how easy is it to use? Reliability how often will it fail? Reusability is it reusable in other systems? Safety does it prevent hazards? Verifiability can it be tested?
32© Bedir Tekinerdogan
Is the system modifiable?
Qualities are vague…
What if we change the color of the user interface, is that
possible…?
Sure! We have just to change that parameter
in this component
What about changing the data format?
Hmmm, no this is not that easy, we have to
change too many components…
33© Bedir Tekinerdogan
Quality depends on context We cannot completely define the context but we can focus on important parts of the
context and describe desired or anticipated use of the
system so that quality considerations become more
clear. Scenarios help to provide a view of the
context
34© Bedir Tekinerdogan
Stakeholders-Quality Different stakeholders see quality in different
terms : End user
Usability Understandability Functionality
Customer Efficiency
Developer Reusability Interoperability Portability
Maintainer maintainability
Tester Testability
Every stakeholder will define specific set of scenarios
35© Bedir Tekinerdogan
Example Scenarios Use Scenario
User downloads document from the file server Change scenario
The relational database is mapped to an object-oriented database
Exploratory scenarios Half of the servers go down during operation
36© Bedir Tekinerdogan
Scenarios should be specific S1. System fails
what is system? which component fails? why does it fail? when?
S1’. Database is destroyed and the data is recovered from the backup files.
37© Bedir Tekinerdogan
How to extract scenarios Brainstorming Session with different
stakeholders Collect Scenarios of different stakeholders Workshop
Look at domain Possible uses of system Risks
Look at other systems Compare systems Experiences
Reuse Scenarios Evaluate scenarios Select scenarios
38© Bedir Tekinerdogan
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
Scenario-based evaluation techniques
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.
39© Bedir Tekinerdogan
Example: SAAM
1. Describe candidate architectures2. Develop scenarios3. Perform scenario evaluation4. Reveal scenario interactions5. Generate overall evaluations
40© Bedir Tekinerdogan
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.
41© Bedir Tekinerdogan
1. Describe Candidate Architectures Identify alternative
architectures domain model patterns
Structures should be selected based on functional and quality requirements
<<arch>>EventManager
<<arch>>WindowManager
<<arch>>ScreenManager
<<arch>>ProcessManager
update screen
communicates
notifies
42© Bedir Tekinerdogan
2. Develop and Prioritize Scenarios Develop task scenarios that the system must
support Develop change scenarios which describe
anticipated changes of system Capture all important scenarios
43© Bedir Tekinerdogan
Develop Scenarios - Example
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 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
44© Bedir Tekinerdogan
Identify Stakeholders Who are the important stakeholders? What is their interest? Interview stakeholders iterate until sufficient coverage (never sure)
45© Bedir Tekinerdogan
Classify Scenarios Direct Scenarios
can be executed by the system without modification Indirect scenarios
require modifications to the system addition/removal/update of architectural components
or relations
Whether a scenario is direct or indirect depends on both architecture and the scenario itself
46© Bedir Tekinerdogan
Classify Scenarios - Example
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
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
Indirect Scenarios
Direct Scenarios
<<arch>>EventManager
<<arch>>WindowManager
<<arch>>ScreenManager
<<arch>>ProcessManager
update screen
communicates
notifies
47© Bedir Tekinerdogan
3. Perform Scenario Evaluation For each indirect scenario
identify the components and relations that must be modified (added, removed or updated)
provide an estimation of the difficulty of the modification
Difficulty of modification is based on the architectural components that need to be modified.
48© Bedir Tekinerdogan
Perform Scenario Evaluation - Example
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
Indirect Scenario Impacts WindowManager EventManager EventManager, ProcessManager WindowManager WindowManager all components EventManager EventManager, ScreenManager
all components
ScreenManager
49© Bedir Tekinerdogan
4. Reveal Scenario Interactions Scenario interaction:
Multiple indirect scenarios affect the same components
Good scenario interactions Semantically related
scenarios affect the same architectural components.
Bad scenario interactions Semantically unrelated
scenarios affect the same components shows which components are implementing semantically unrelated functions
Poor separation of concerns
Component DirectScenario
s
IndirectScenarios
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
50© Bedir Tekinerdogan
Cohesion Cohesive component performs only one
concern/task
Maximize cohesion within an architectural component required changes can be easily localized and will not
propagate
SynchronizationRecovery
Authentication
Many concerns in one moduleLow Cohesion
Synchronization Recovery
Authentication
Each module addresses one concernHigh Cohesion
51© Bedir Tekinerdogan
Coupling Two components are independent if they do not
have interactions Highly coupled components have many
dependencies/interactions Minimize coupling between architectural
components reduces complexity of interactions reduces ‘ripple’ effect
C1 C3
C2
C1 C3
C2
52© Bedir Tekinerdogan
What to do if scenarios interact? Scenarios are all of the same class (cohesion). Scenarios are of different classes, and
component can be subdivided. Scenarios are of different classes and
component cannot easily be subdivided.
53© Bedir Tekinerdogan
5. Generate overall evaluation Reason about quality attributes State list of architectural problems Give hints/guidelines for improvements Refactor...
54© Bedir Tekinerdogan
refactor, refactor, refactor,....
Architecture Ok?
Go!Implement Architecture
yes
Indirect Scenario
Refactor
I cannot get the architecture right?What’s wrong...?!
no
55© Bedir Tekinerdogan
Different 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
Indirect Scenarios
difficult to localize...
affect multiple components(crosscut)
56© Bedir Tekinerdogan
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
57© Bedir Tekinerdogan
The good and the bad...
Component DirectScenario
s
IndirectScenarios
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
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
Indirect Scenarios
Good or Bad
58© Bedir Tekinerdogan
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
59© Bedir Tekinerdogan
ASAAM
1. Describe candidate architecture2. Develop and prioritize scenarios3. Individual scenario evaluation and aspect
identification Direct Scenarios, Indirect Scenarios, Aspectual
scenarios, Architectural aspects
4. Scenario interaction evaluation and component classification
Cohesive component, tangled component, composite component, ill-defined component
5. Refactor architecture using conventional techniques (OO, patterns etc.) using aspect-oriented techniques
60© Bedir Tekinerdogan
Heuristic rules for scenario evaluation R0:
Develop SCENARIO artifacts based on PROBLEM DESCRIPTION
Scenario
R0
S1. Start multiple processes at the same time.S2. Change color of widgets in the window.S3. Close all open windowsS4. Change screen resolutionS5. Enter a command to start application
processS6. Move the main windowS7. Screen saver is activatedS8. Resize a windowS9. Terminate a processS10. Interrupt a process
S11. Change look-and-feel style on run-time.S12. Add voice controlS13. A failure occurs and the system shuts
down. S14. Provide dual display screen.S15. Use multiple desktops. S16. Monitor activities of the userS17. Provide touch screen and light pen as inputS18. A memory overflow due to many opened
windowsS19. Port system to command-based operation
system S20. Minimize windows after idle time
Scenarios
61© Bedir Tekinerdogan
Extract Scenarios Brainstorming Session with different
stakeholders Collect Scenarios of different stakeholders Workshop
Look at domain Possible uses of system Risks
Look at other systems Compare systems Experiences
Reuse Scenarios Evaluate scenarios Select scenarios
62© Bedir Tekinerdogan
Heuristic rules for scenario evaluation 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
Scenario
DirectScenario
IndirectScenario
R0
R1 R2
R3
63© Bedir Tekinerdogan
Direct and Indirect Scenarios
S1. Start multiple processes at the same time.S2. Change color of widgets in the window.S3. Close all open windowsS4. Change screen resolutionS5. Enter a command to start application processS6. Move the main windowS7. Screen saver is activatedS8. Resize a windowS9. Terminate a processS10. Interrupt a process
S11. Change look-and-feel style on run-time.S12. Add voice controlS13. A failure occurs and the system shuts
down. S14. Provide dual display screen.S15. Use multiple desktops. S16. Monitor activities of the userS17. Provide touch screen and light pen as inputS18. A memory overflow due to many opened
windowsS19. Port system to command-based operation
system S20. Minimize windows after idle time
Indirect Scenarios
Direct Scenarios
<<arch>>EventManager
<<arch>>WindowManager
<<arch>>ScreenManager
<<arch>>ProcessManager
update screen
communicates
notifies
64© Bedir Tekinerdogan
Heuristic rules for scenario evaluation 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
Scenario
DirectScenario
IndirectScenario
AspectualScenario
R0
R1 R2
R3
R4 R5
65© Bedir Tekinerdogan
Aspectual Scenarios
S11. Change look-and-feel style on run-time.S12. Add voice controlS14. Provide dual display screen.S15. Use multiple desktops. S17. Provide touch screen and light pen as inputS18. A memory overflow due to many opened
windowsS20. Minimize windows after idle time for each
S13. A failure occurs and the system shuts down. S16. Monitor activities of the userS19. Port system to command-based operation system
Indirect ScenariosS1. Start multiple processes at the same time.S2. Change color of widgets in the window.S3. Close all open windowsS4. Change screen resolutionS5. Enter a command to start application
processS6. Move the main windowS7. Screen saver is activatedS8. Resize a windowS9. Terminate a processS10. Interrupt a process
-
Direct Scenarios
Aspectual ScenariosAspectual Scenarios
66© Bedir Tekinerdogan
Heuristic rules for scenario evaluation R6:
Derive ARCHITECTURAL ASPECT from ASPECTUAL SCENARIO Scenario
DirectScenario
IndirectScenario
AspectualScenario
ArchitecturalAspect
R0
R1 R2
R3
R4 R5
R6
67© Bedir Tekinerdogan
Architectural Aspects
S13. A failure occurs and the system shuts down.
S16. Monitor activities of the user
S19. Port system to command-based operation system
Aspectual Scenarios
Failure Management LoggingRestartingCheckpointing
MonitoringOperating System Aspect
Architectural Aspects
Domain Analysis
68© Bedir Tekinerdogan
Heuristic Rules for Component Classification
Component
DirectComponent
IndirectComponent
R7
R8 R9
R10
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 a SCENARIO THEN component is INDIRECT COMPONENT for SCENARIO
R10IF INDIRECT COMPONENT can be refactored to perform INDIRECT SCENARIO THEN INDIRECT COMPONENT is DIRECT COMPONENT
69© Bedir Tekinerdogan
Direct and Indirect Components
Component Direct forScenarios
Indirect forScenarios
EventManager S3, S5, S8 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
70© Bedir Tekinerdogan
Cohesive, Tentative Tangled or Composite 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
Component
DirectComponent
IndirectComponent
R7
R8 R9
R10
CohesiveComponent
TentativeTangled
Component
CompositeComponent
R11R12
R13
71© Bedir Tekinerdogan
Cohesive, Tentative Tangled or 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
Component
DirectComponent
IndirectComponent
R7
R8 R9
R10
CohesiveComponent
TentativeTangled
Component
CompositeComponent
R11 R12R13 R14
R15 R16
72© Bedir Tekinerdogan
Cohesive, Tentative Tangled or Composite Component
Component Cohesive Tent. Tangled Composite
EventManager S3, 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
73© Bedir Tekinerdogan
Tangled Component or Ill-Defined 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
Component
DirectComponent
IndirectComponent
R7
R8 R9
R10
CohesiveComponent
TentativeTangled
Component
CompositeComponent
R11 R12R13 R14
R15 R16
TangledComponent
Ill-DefinedComponent
R17 R18
74© Bedir Tekinerdogan
Identified Aspects and Tangled Components
Component Cohesive Tangled(Aspect)
Composite Ill-defined.
EventManager S3, 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
75© Bedir Tekinerdogan
Aspectual Refactoring
<<arch>>EventManager
<<arch>>WindowManager
<<arch>>ScreenManager
<<arch>>ProcessManager
updatescreen
communicates
notifies
<<arch-aspect>> EventManager
<<pointcut>> log()<<pointcut>> checkpoint()<<pointcut>> recover()
76© Bedir Tekinerdogan
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.