Theme/UML

Advanced Software Tools Seminar

Maayan Goldstein, TAU

December, 2004

Introduction

The problem: structural mismatch between the specification of requirements for software systems and the specifications of object-oriented software systems. Single requirement is scattered across the design units A single design unit supports various requirements.

Theme/UML, based on UML, presents new approach of decomposing requirements and aligning them within design models according to a theme, and composing them back using composition relationship.

Most basic units of decomposition: object, and class

Employee

Object encapsulates additional unitsCompany

salary

• Structural: attributes and relationships

• Behavioural: operations, interfaces, methodsaddEmployee()

Object – Oriented Paradigm

Example: Library management system

The system should support the following: Addition, removal, ordering and search of books (resources) Borrowing and return of books. Fines may be imposed for late return. The services for managing resources are available

concurrently. The system should take care of synchronizing actions an query services.

Multiple query services should be allowed run concurrently. We will require our design to have the following qualities:

Product flexibility Comprehensibility Managerial

Structural Mismatch Requirements - OO Designs : Scattering

AddResource

RemoveResource

OrderResource

SearchResource

BorrowBook

ReturnBook

PayFine

Synchronize

Order

Borrower

Fine

ResourceManager

Resource

Book Periodical

Location

CopyNoGenerator

CopyCourse

Structural Mismatch Requirements - OO Designs : Tangling

Order

Borrower

Fine

ResourceManager

Resource

Book Periodical

Location

CopyNoGenerator

CopyCourse

+ setLocation(Location)+ setCourse(Course)+ setOrder(Order)+ addCopy(Copy)+ deleteCopies()

Resource- title : String- publisher : String- date: Date

+ addBook()+ addPeriodical()+ removeResource()- deleteResource()+ orderBook()+ orderPeriodical()+ search()# waitWriterReaders() {concurrent}# waitWriter() {concurrent}# wait() {concurrent}- incrementReaders()- decrementReaders()- incrementWriters()

- decrementWriters()

ResourceManager

AddResource

RemoveResource

OrderResource

SearchResource

BorrowBook

ReturnBook

PayFine

Synchronize

What about crosscutting concerns?

The object-oriented paradigm modularises based on class/object, interfaces and methods

Where behaviour impacts multiple different classes and methods, (and therefore is crosscutting) it is not possible to encapsulate that behaviour using standard OO languages

Crosscutting concerns are not well encapsulated by OO languages

Simple tracing example: the entry to and exit from each operation called is traced:

Structurally, design elements handling tracing can be separated and classes requiring trace behaviour simply have to add a relationship

Trace

- trace

+ traceEntry(String)+ traceExit(String)

File

What about crosscutting concerns? Crosscutting behaviour must be specified wherever required

Trace

- trace

+ traceEntry(String)+ traceExit(String)

File

X

+ foo()+ bar()+ op1()+ op2()

:X :Trace

}

op2()

basic op2() behaviourgoes here

traceEntry(op2.name)

traceExit(op2.name)

Y

+ op_a()+ op_b()+ op_c()+ op_d()

:Y :Trace

}

op_a()

basic op_a() behaviourgoes here

traceEntry(op_a.name)

traceExit(op_a.name)

:Y :Trace

}

op_b()

basic op_b() behaviourgoes here

traceEntry(op_b.name)

traceExit(op_b.name)

:Y :Trace

}

op_c()

basic op_c() behaviourgoes here

traceEntry(op_c.name)

traceExit(op_c.name)

:Y :Trace

}

op_d()

basic op_d() behaviourgoes here

traceEntry(op_d.name)

traceExit(op_d.name)

Problems with the suggested design

Any new operation requiring trace behaviour must specify an interaction model indicating this.

Changing or elimination the trace behaviour design requires changes to all operation interaction models.

Reuse of this design in a different system is not straightforward. From a structural perspective, reuse may be reasonably

straightforward – in this case, the classes and methods relating to trace have been separated.

However, reuse of the behavioural specification is less easy. We have to examine the interactions, and extract the relevant pieces.

Theme

Theme: approach and tools to identify and handle aspects from requirements to implementation: Theme represents a feature of the system Theme/Doc tool: a set of heuristics for visualization and

analysis of software requirements documentation. Theme/UML method: design and modeling (using standard

UML editors), including a way to write aspects as UML.

The process: Find themes – using Theme/Doc Design themes – using Theme/UML Compose themes – using Theme/UML

Major steps in using Theme/Doc and transfer to Theme/UML (Phase 1)

Identify crosscutting (aspectual) actions and entities being used (removing non-crosscutting actions)

Create Clipped Action View that shows the crosscutting hierarchy

Define Actions used in the requirements (done manually)

Creation of Action View that shows actions usage by the requirements (by lexical analysis of the requirements by the tool)

Phase 2

Major steps in using Theme/Doc and transfer to Theme/UML (Phases 2-4)

Create Theme Views for the crosscutting actions to model the themes identified in the previous steps

Use Theme/UML to incorporate the crosscutting actions and identified entities into the design as classed, methods, etc.

Augmentation of the Theme Views to help in verifying that the design choices made align with the requirements

Phase 1

Implications of Theme/UML thematic design

Overlapping specifications supported: various requirements that have impact on the same core concepts are handled separately and then combined together using composition capabilities of the model.

Crosscutting specifications supported: the decomposition approach helps to design these concerns separately and later these are integrated with the rest of the system.

Design patterns: Theme/UML model defines a mechanism to reuse various solutions made for crosscutting concerns.

Theme/UML as general purpose design language

Implementation language independence Design-level composability

Designers may check the result of composition prior to implementation, for validation purposes

Support for non-aspect-oriented design models. Compatibility with existing design approaches

Back to our Library example…

AddResource

RemoveResource

OrderResource

SearchResource

BorrowBook

ReturnBook

PayFine

Synchronize

Order

Borrower

Fine

ResourceManager

Resource

Book Periodical

Location

CopyNoGenerator

CopyCourse

Theme/UML: Decomposition based on Requirements Specification

AddResource

RemoveResource

OrderResource

SearchResource

BorrowBook

ReturnBook

PayFine

Synchronize

AddResource

RemoveResource

OrderResource

SearchResource

BorrowBook

ReturnBook

PayFine

Synchronize

Theme/UML: Decomposition of management resources into different design models

«theme»

Decomposing crosscutting requirements into a separate subject

«theme»

Composing Design Models:Composition Relationship

A new kind of design relationship Defined between design elements:

Indicates the elements that correspond (implicit, explicit) Specify how corresponding elements are to be integrated Specify how conflicts in corresponding elements are reconciled Specify composition patterns for crosscutting requirements. Specify the real elements to replace “placeholders” in patterns

Particularly useful for composing “cross-cutting” behaviour patterns.

Combination of composition semantics and UML templates

Merging behaviours from different modelsSpecified with a composition relationship which details the elements to be merged.

Composition semantics uses delegation to merge corresponding operations from different models

match[name]X

+ op1()

X

+ op1()Matching criteria on the compositionrelationship defines the operationsto be merged.

S1 S2

X

+ op1()- S1_op1()- S2_op1() S2_op1()

S1_op1()

op1():X

S1S2

Capturing crosscutting behaviour in a composition pattern

A “Composition Pattern” (CP) is a package that contains the design models required to specify crosscutting behaviour

A CP may be composed with other design models, merging those design models with the crosscutting behaviour.

A CP does not contain a reference to any particular design element its aspect may crosscut.

These properties of CPs present two important requirements for a design language: Merge semantics for crosscutting behaviours The ability to reason about elements it may crosscut without

explicit reference

Reasoning about elements to be crosscut

The UML has a notion of templates which are described as “parameterised model elements”, with formal parameters which may be “bound” by actual model elements.

CPs extend the UML notion of templates, allowing a package to have multiple pattern classes with template parameters within those pattern classes

AClassT, i:Integer

BClass

«bind» (BClass, 24)

Trace

- trace

+ traceEntry(String)+ traceExit(String)

File

TracedClass

+ tracedOp()- _tracedOp()

:TracedClass :TracetracedOp()

traceEntry(tracedOp.name)

traceExit(tracedOp.name)

_tracedOp()

<TracedClass, _tracedOp()>Trace

Binding composition pattern to a base design

CPs also build on the UML notion of a template binding relationship by extending composition relationships to include the ability to bind multiple real elements to the parameters

Any class from the base design that replaces a pattern class has the specification of the pattern class merged with it.

Crosscutting behaviours are merged as defined by the interactions – one is generated for each of the operations that replace the template

bind[ <{*}, {*}> ]

<TracedClass, _tracedOp()>

LibraryTrace

Another example - Observer Aspect

The observer pattern defines interactions between multiple pattern classes - subjects whose changes in state are of interest to observers

Vector

Subject

+ aStateChange()-_aStateChange()- notify()+ addObserver(Observer)+ removeObserver(Observer)

1 observersObserver

+ update()+ start()-_start()+ stop()- _stop()

*subjects

:aSubject

aStateChange()

_aStateChange()

notify()

:anObserver

update()

action aSubject :: notify()

post all observers in aSubject.observers

are sent update() event

< Subject, _aStateChange(..) >

< Observer, update(..), _start(.., Subject,..), _stop(..,Subject,..) >

Collab_ObserverPattern

«theme»

Observer

Observer aspect example – adding/removing observers

< Subject, _aStateChange(..) >

< Observer, update(..), _start(.., Subject,..), _stop(..,Subject,..) >

:anObserver

start(.., Subject,..)

_start(.., Subject,..)

:aSubject

addObserver(anObserver)

:anObserver

stop(.., Subject,..)

_stop(.., Subject,..)

:aSubject

removeObserver(anObserver)

«theme»

Observer

Pattern Binding

Bind BookCopy as a subject and ResourceManager as an observer.

bind[ < BookCopy, {meta:isQuery=false} > < ResourceManager, updateStatus() addView(), removeView()> ]

< Subject, _aStateChange(..) >

< Observer, update(..), _start(.., Subject,..), _stop(..,Subject,..) >

«theme»

Observer

Library

The final design – Library with Observer

Collab_ObserverPattern – borrow()

action: BookCopy :: notify()

post: all observers of BookCopy are sent updateStatus() event

«theme»

ObserverLibrary

Subjects

Vector +addObserver(in Observer)+removeObserver(in Observer)+borrow()-Library_borrow()+return()-Library_returm()+notify()

Book Copy

+getName()+getAuthor()+getISBN()

-+name-+author-+ISBN

Book

+updateStatus()+addView(in BookCopy)-Library_addView(in BookCopy)+removeView(in BookCopy)+add(in Book)+remove(in Book)+search(in Book)-Library_removeView(in BookCopy)

ResourceManager

+addBook()+removeBook()

-+roomNumber-+shelfNumber

Location

1 Observers

*

*Copies

:BookCopy :ResourceManager

borrow() Library_borrow()

notify()

updateStatus()

Composition Pattern as reusable aspect design

CPs do not explicitly refer to any actual design elements they work with. As such, they may be composed with any design model.

bind[ < BookCopy, {meta:isQuery=false} > < ResourceManager, updateStatus() addView(), removeView()> ]

bind[ < Room, { book(), cancel() } > < Reservations, update(), add(Room), remove(Room) > ]

< Subject, _aStateChange(..) >

< Observer, update(..), _start(.., Subject,..), _stop(..,Subject,..) >

Library

«theme»

Observer

Hotel

Specification of composition at design stage Two options for composition:

Implement individual designs – then compose

Traceability, with extensibility benefits

Reusable implementations

Need similar compositional language (e.g. AspectJ, Hyper/J)

Compose designs, and then implement

Lose traceability with code – inherent extensibility difficulties

Code is not reusable

Can write code using favourite OO language

Theme/UML within the software lifecycle Compose the designs vs. map to an implementation language

Algorithm for Mapping to AspectJ

Two main approaches: Represent both a crosscutting theme and its

composition specification as a single aspect. Lack of reusability and evolvability Crosscutting theme has to be reimplemented for every

composition specification. Maintain the separation of a reusable crosscutting

theme from composition specification Reusable and flexible solution

Map Theme/UML to AspectJ

AspectJ Programming Elements (a very short reminder) A joint point is an identifiable point in the execution of a

program. A pointcut is a program construct that selects join points and

collects context at those points. Advice is the code to be executed at a join point that has

been selected by a pointcut. Advice can execute before, after, or around the join point.

The introduction is a static crosscutting instruction that introduces changes to the classes, interfaces, and aspects of the system.

The aspect is the central unit of AspectJ. It contains the code that expresses the weaving rules for both dynamic and static crosscutting.

Mapping AspectJ Program Elements to Theme/UML

AspectJ Element

Theme/UML

AspectA crosscutting theme is a design equivalent to an aspect.

PointcutOperation template parameters maybe defined and references within interaction specifications, denoting that they are join points for crosscutting behavior. These templates maybe replaced by actual operations multiple times and are therefore equivalent to pointcuts.

AdviceWithin an interaction diagram, crosscutting behavior may be specified on template operation calls. This behavior is equivalent to advice code.

IntroductionDesign elements that are not template elements may be defined within crosscutting themes. These may be classes, attributes, operations, or relationships and are equivalent to an introduction.

Mapping Uncomposed crosscutting themes to abstract aspects Pattern classes become interfaces within the abstract aspect.

For instance, each BookCopy would implement SubjectI interface.

Non-template operations become introduced methods on those interfaces. For instance, notify() operation is introduced into SubjectI

interface, thus providing concrete classes with the method. Template operations without supplementary behavior

become methods on those interfaces. Template operations with supplementary behavior become

abstract pointcuts plus advice. We need to wrap the original behavior with the template

behavior.

Mapping Uncomposed crosscutting themes to AspectJ (The algorithm)

Mapping Composition specifications to concrete aspects

Concrete classes bound to pattern classes require parents declarations in the concrete aspect. The concrete class should become a subtype of the pattern class.

Thus, if Subject is represented by SubjectI interface, then BookCopy which is a subject should implement SubjectI.

Concrete operations bound to template operations without supplementary behavior require introduction of delegating methods on concrete classes. Each template interface declares template operations that must

be implemented by the concrete class. The signature of the methods could differ (for instance,

updateStatus() in BookCopy and update() in the aspect), so the concrete aspect must delegate one call to the other.

Concrete operations bond to template operations with supplementary behavior require concrete pointcuts. Each abstract pointcut corresponds to a template operation.

Here’s the design just before the binding

bind[ < BookCopy, {borrow(), return()} > < ResourceManager, updateStatus() addView(), removeView()> ]

< Subject, _aStateChange(..) >

< Observer, update(..), _start(.., Subject,..), _stop(..,Subject,..) >

«theme»

Observer

Library

Let’s have some Java, shell we? public abstract aspect Observer {

//Type declarations protected interface SubjectI { } protected interface ObserverI { public void update(); }

//Introductions private Vector SubjectI.observers; private Vector ObserverI.subjects;

private void SubjectI.notify() { /* post: all observers in SubjectI.observers are sent update() event */ }

//Pointcuts abstract pointcut aStateChange(SubjectI s); abstract pointcut start(ObserverI o, SubjectI s); abstract pointcut stop(ObserverI o, Subject s);

//Advices after(SubjectI s) : aStateChange(s) { s.notify(); } before(ObserverI o, SubjectI s) : start(o, s) { s.observers.add(o); } after(ObserverI o, SubjectI s) : stop(o, s) { s.observers.remove(o); }}

Concrete Library Observer implementation

public aspect LibraryObserver extends Observer {

//Declarationsdeclare parents: BookCopy implements SubjectI;declare parents: ResourceManager implements ObserverI;

//Introductions public void ResourceManager.update() {

//for each BookCopy bc in subjects updateStatus(bc) }

//Pointcutspointcut aStateChange(SubjectI copy): target(copy) && args(..) &&

(execution(* BookCopy.borrow(..)) || execution(* BookCopy.return(..)));

pointcut start(ObserverI o, SubjectI s): target(o) && args(s) && execution(* ResourceManager.addView(BookCopy));

pointcut stop(ObserverI o, SubjectI s): target(o) && args(s) && execution(* ResourceManager.removeView(BookCopy));

}

Theme development lifecycle

So far we’ve covered phases 2-3.

Let’s get back to phase 1 and talk a little about phase 4.

Theme/Doc - Finding Aspects in Requirements

Allows to refine views of (textual) requirements to reveal which functionality in the system is crosscutting;Assumes that if two behaviors are described in the same requirement then they are related (coincidently, hierarchically or crosscutting)

Allows to identify aspects from interrelated behaviors of Functional Requirements, not just aspects from Non-Functional Requirements as most of other methods identify

Themes are divided into bases-themes (non-crosscutting) and crosscutting-themes

Actions are good starting point for finding themes (only major enough actions are modeled separately as themes)

Example - Course Management System

The CMS is a very small system, with nine requirements. Identifiedactions are in bold, entities in italics (Actions are taken from a listpre-defined by the developers) : R1. Students can register for courses. R2. Students can unregister for courses. R3. When a student registers then it must be logged in their record. R4. When a student unregisters it must also be logged. R5. Professors can unregister students. R6. When a professor unregisters a student it must be logged. R7 When a professor unregisters a student it must be flagged as

special. R8. Professors can give marks for courses. R9. When a professor gives a mark this must be logged in the

record.

Theme/Doc Action View

No actions are isolated from the rest

Identify aspects by examining shared requirements

Isolate groups of actions and requirements into base and cross-cutting

Clipped Action View

Crosscutting hierarchy

Base Actions

Crosscutting Action

Requirements snipped from Base Actions and left with Crosscutting only

Theme/Doc and Theme/UML for register

Action translated to Method

Entity translated to Class

Read from top to bottom

Theme/Doc and Theme/UML: logged

Non Crosscutting. Unique to logged

Behaviors that are crosscut by the logged behavior

Entity translated to Database

Template Method (handle method for base behaviors)

Augmented View (register and logged)

Theme/Doc Augmentation:Align a theme with thedesign decisions to verifythat design choices arealigned with requirements

Augmented Associations

Augmented Method

UML metamodel extensions

The UML is a standard language for object-oriented analysis and design specifications using metamodel. The metamodel defines the syntax and semantics of the UML. The metamodel is described in a semi-formal manner, using the views: Abstract syntax: This view is a UML class diagram showing

the metaclasses defining the language constructs (e.g. Class, Attribute, Operation, Association etc.), and their relationships.

Well-formedness rules: A set of well-formedness rules that describe constraints on instances of metaclasses, i.e. the usage of the UML language constructs.

Semantics: The meanings of the constructs in the language are described using natural language.

Composable elements

ComposableElement defines which model elements may participate in a composition relationship

Primitives are defined as elements whose full specifications are composed with other primitives.

Composites may contain composites and primitives, and therefore may be considered as a standard tree structure.

Theme

Composition Relationship

Override Integration metamodel

Some examples of well-formedness rules for override integration are: Within the context of a single composition, a composable element may only

participate in one composition relationship as the overridden element.

The overriding and overriden elements are different:

Override Integration semantics

For each element in the overridden theme, the existence of a corresponding element in the overriding theme results in the specification of that element to be changed to that of the corresponding element in the composed result.

Elements in an overridden composite that are not involved in a correspondence match remain unchanged, and are added to the composed result.

Elements that are components of an overriding composite and are not involved in a correspondence match are added to the composed result.

Overriding elements may not result in name clashes in the resulting subject – renaming will occur.

The resulting theme must conform to the well-formedness rules of the UML.

Summary

Current design approaches lead to design models that are difficult to extend, change and reuse.

Theme/UML supports independent, reusable designs, including designs of crosscutting behaviour with composition patterns.

CPs may be composed with non-pattern designs, and multiple designs may be composed together.

Mapping Theme/UML decomposed models to compositional implementation languages supports: traceability of the designs to code ease of initial implementation and evolution of crosscutting and

base code.

References

Generic Aspect-Oriented Design with Theme/UML – Clarke, Walker

Extending Standard UML with model composition semantics – Clarke

Theme: An Approach for Aspect-Oriented Analysis and Design - Clarke

Towards a Standard Design Language for AOSD - Clarke Early Aspects - Overview of Some Approaches - David

Bar-On AspectJ in Action – Ramnivas Laddad