CS 586 – Aspect-Oriented Software Development Aspect-Oriented Design - Method

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


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)


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);


Characteristics of an aspect...

Systemic, tends to affect multiple components

Cross-cuts, spread over different components

Affects performance/quality


Aspect identification...

Analysis

Design

Implementation

Testing

Requirements Analysis

Domain Analysis

Problem

Solution

Aspects?!Where?


software developm

ent

Analysis

Design

Implementation

Testing


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?


Late Aspect Identification

Too late!

Analysis

Design

Implementation

Testing


Domain Analysis

Missing early aspects.

Difficult to model aspects.


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?


Early Aspect Identification

Analysis

Design

Implementation

Testing


Domain Analysis

All relevant aspects can be identified.

Modeling aspects from domain knowledge.


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.


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


Aspect-Oriented Method Identifying Specifying Evaluating aspects

in a systematic way


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


Software engineering

methodm

applicationn

modelo

tools1

application layer

method layer

model layer

support layerDriver

Monitoringsystem

objects,classes

inheritance

Method

CASE,OO

compiler


What is a method?

Usecases

entities

classes associations STD

attributesinheritance

Ifthen ..

Ifthen ..

Ifthen ..

Ifthen ..

Ifthen .. If

then ..

Ifthen ..

Rules (heuristics)

Process

Artifacts


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


Architecture Design Methods

Ok, but is there a method to identify aspects?

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/


Contents Software Architecture Evaluating Architectures using Scenarios SAAM Example: Window Management System

Architectural Aspects ASAAM Conclusion & Discussions


Architecture

Describes (is) StructureConsisting of componentswhich forms the foundation of the whole....


Intuitive notion of software architecture

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

Design : Implementation = Software Architecture : Design


Design, Realize and Test Architecture

Software Architecture 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; }}

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


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


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 …

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


Architecture Ok?

Architecture(Re)definition

Go!Implement Architecture

yes

no

Review GuidelinesQuality Criteria

Software Architecture Evaluation


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


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…


Stakeholders Stakeholders:

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


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?


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…


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


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


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


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.


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


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.


Example: SAAM

1. Describe candidate architectures2. Develop scenarios3. Perform scenario evaluation4. Reveal scenario interactions5. 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.


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


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


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


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


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


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





Indirect Scenarios

Direct Scenarios





update screen

communicates

notifies


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.


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


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


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


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


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


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.


5. Generate overall evaluation Reason about quality attributes State list of architectural problems Give hints/guidelines for improvements Refactor...


refactor, refactor, refactor,....

Architecture Ok?

Go!Implement Architecture

yes

Indirect Scenario

Refactor

I cannot get the architecture right?What’s wrong...?!

no


Different indirect scenarios...



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)


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


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





system S20. Minimize windows after idle time for each

Indirect Scenarios

Good or Bad


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

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


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


Scenarios


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



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


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


Indirect Scenarios

Direct Scenarios





update screen

communicates

notifies



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


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



Derive ARCHITECTURAL ASPECT from ASPECTUAL SCENARIO Scenario

DirectScenario

IndirectScenario

AspectualScenario

ArchitecturalAspect

R0

R1 R2

R3

R4 R5

R6


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


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


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


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



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



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


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


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


Aspectual Refactoring





updatescreen

communicates

notifies

<<arch-aspect>> EventManager

<<pointcut>> log()<<pointcut>> checkpoint()<<pointcut>> recover()


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.

CS 586 – Aspect-Oriented Software Development Aspect-Oriented Design - Method

Documents

Transcript of CS 586 – Aspect-Oriented Software Development Aspect-Oriented Design - Method