CS 586

1
CS 586 Aspect-Oriented Software
DevelopmentAspect-Oriented Design - Method
Bedir TekinerdoganBillkent University,
Department of Computer Engineering Bilkent,
Turkey, Ankaraemail - bedir_at_cs.bilkent.edu.tr ht
tp//www.cs.bilkent.edu.tr/bedir/
2
Table of Contents

• Problem Statement
• Scenario-based Analysis of Software Architecture
• ASpectual SAAM (ASAAM)
• Modeling Aspects using Domain Analysis

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

5
Characteristics of an aspect...
6
Aspect identification...
7
Where are the aspects?
software development
8
Late Aspect Identification
9
Modeling Aspects
Alright, tracing is an aspect But what is
tracing/ how to model this?
10
Early Aspect Identification
11
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
Rationale for method

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

13
Aspect-Oriented Method

• Identifying
• Specifying
• Evaluating aspects
• in a systematic way

14
Rationale for aspect-oriented method

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

15
Software engineering
Driver Monitoring system
application layer
support layer
applicationn
tools1
method layer
methodm
objects, classes inheritance
CASE, OO compiler
model layer
modelo
16
What is a method?

• Artifacts

• Rules (heuristics)

If then ..
If then ..
If then ..

• Process

entities
attributes
If then ..
inheritance
If then ..
If then ..
If then ..
Use cases
associations
classes
STD
17
Example Requirements Analysis

• Models
• use case
• actor
• Rules
• Identify Actors
• Identify Use Case
• Draw the use case diagram
• Process
• Application

18
Architecture Design Methods
19
ASAAM Aspectual Software Architecture Analysis
Method
Bedir TekinerdoganBillkent University,
Department of Computer Engineering Bilkent,
Turkey, Ankaraemail - bedir_at_cs.bilkent.edu.tr ht
tp//www.cs.bilkent.edu.tr/bedir/
20
Contents

• Software Architecture
• Evaluating Architectures using Scenarios
• SAAM
• Example Window Management System
• Architectural Aspects
• ASAAM
• Conclusion Discussions

21
Architecture
22
Intuitive notion of software architecture

• Software Architecture represents the gross level
  structure of a software system.
• Design Implementation
• Software Architecture Design

23
Design, Realize and Test Architecture
Requirements Analysis
....... ....... ....... .......
Software Architecture Design
Analysis Design
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
24
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
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
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
Software Architecture Evaluation
28
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
Scenarios

• 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
30
Stakeholders

• Stakeholders
• end users
• managers
• developers
• maintainers
• analysts
• designer
• testers
• customers
• ....

31
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
Qualities are vague

• Is the system modifiable?

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
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
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
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
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
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
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.
39
Example SAAM

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

40
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
1. Describe Candidate Architectures

• Identify alternative architectures
• domain model
• patterns
• Structures should be selected based on functional
  and quality requirements

42
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
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
Identify Stakeholders

• Who are the important stakeholders?
• What is their interest?
• Interview stakeholders
• iterate until sufficient coverage (never sure)

45
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
Classify Scenarios - Example
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

47
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
Perform Scenario Evaluation - Example
Indirect Scenario
Impacts

• 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

• WindowManager
• EventManager
• EventManager, ProcessManager
• WindowManager
• WindowManager
• all components
• EventManager
• EventManager, ScreenManager
• all components
• ScreenManager

49
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 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
50
Cohesion

• Cohesive component performs only one concern/task
  
• Maximize cohesion within an architectural
  component
• required changes can be easily localized and will
  not propagate

Synchronization
Recovery
Synchronization Recovery Authentication
Authentication
Many concerns in one module Low Cohesion
Each module addresses one concernHigh Cohesion
51
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
C1
C3
C2
C2
52
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
5. Generate overall evaluation

• Reason about quality attributes
• State list of architectural problems
• Give hints/guidelines for improvements
• Refactor...

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

difficult to localize... affect multiple
components (crosscut)
56
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
The good and the bad...
Indirect Scenarios
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

• 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

Good or Bad
58
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
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

60
Heuristic rules for scenario evaluation
R0

• R0Develop SCENARIO artifacts based on PROBLEM
  DESCRIPTION

Scenario
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
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
61
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
Heuristic rules for scenario evaluation

• 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

R0
Scenario
R1
R2
Direct Scenario
Indirect Scenario
R3
63
Direct and Indirect Scenarios
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
64
Heuristic rules for scenario evaluation

• 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

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

• 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
• -

Aspectual Scenarios
Aspectual Scenarios
66
Heuristic rules for scenario evaluation

• R6Derive ARCHITECTURAL ASPECT from ASPECTUAL
  SCENARIO

R0
Scenario
R1
R2
Direct Scenario
Indirect Scenario
R3
R4
R5
Aspectual Scenario
R6
Architectural Aspect
67
Architectural Aspects
Aspectual Scenarios
S13. A failure occurs and the system shuts down.
S16. Monitor activities of the user S19. Port
system to command-based operation system
Domain Analysis
Architectural Aspects
Failure Management Logging Restarting Checkpoi
nting Monitoring Operating System Aspect
68
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 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

R7
Component
R8
R9
Direct Component
Indirect Component
R10
69
Direct and Indirect Components
Component Direct for Scenarios Indirect for Scenarios
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
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

R7
Component
R8
R9
Direct Component
Indirect Component
R10
R13
R11
R12
Cohesive Component
Tentative Tangled Component
Composite Component
71
Cohesive, Tentative Tangled or 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

R7
Component
R8
R9
Direct Component
Indirect Component
R10
R13
R14
R16
R11
R12
R15
Cohesive Component
Tentative Tangled Component
Composite Component
72
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
Tangled Component or Ill-Defined Component
R7

• 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

Component
R8
R9
Direct Component
Indirect Component
R10
R13
R14
R16
R11
R12
R15
Cohesive Component
Tentative Tangled Component
Composite Component
R17
R18
Tangled Component
Ill-Defined Component
74
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
Aspectual Refactoring
ltltarchgtgt EventManager
communicates
update screen
ltltarchgtgt WindowManager
ltltarchgtgt ScreenManager
notifies
ltltarchgtgt ProcessManager
76
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.