Theme uml
This presentation is the property of its rightful owner.
Sponsored Links
1 / 53

Theme/UML PowerPoint PPT Presentation


  • 86 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Theme/UML

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Theme uml

Theme/UML

Advanced Software Tools Seminar

Maayan Goldstein, TAU

December, 2004


Introduction

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.


Object oriented paradigm

Employee

Company

Object – Oriented Paradigm

Most basic units of decomposition:

object, and class

salary

Object encapsulates additional units

  • Structural: attributes and relationships

addEmployee()

  • Behavioural: operations, interfaces, methods


Example library management system

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

Pay

Fine

Borrow

Book

Order

Resource

Add

Resource

Search

Resource

Remove

Resource

Return

Book

Synchronize

ResourceManager

CopyNoGenerator

Resource

Order

Location

Periodical

Book

Course

Fine

Borrower

Copy

Structural Mismatch Requirements - OO Designs : Scattering


Structural mismatch requirements oo designs tangling

Pay

Fine

Borrow

Book

Order

Resource

Add

Resource

Search

Resource

Remove

Resource

Return

Book

Synchronize

ResourceManager

CopyNoGenerator

Location

Periodical

Copy

Course

Book

Resource

Fine

Borrower

Order

Structural Mismatch Requirements - OO Designs : Tangling


What about crosscutting concerns

Trace

- trace

+ traceEntry(String)

+ traceExit(String)

File

What about crosscutting concerns?

Crosscutting concerns are not well encapsulated by OO languages

  • 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

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


What about crosscutting concerns1

:Y

:Y

:Y

:Y

:X

:Trace

:Trace

:Trace

:Trace

:Trace

op_c()

op_b()

op_a()

op2()

op_d()

traceEntry(op_b.name)

traceEntry(op2.name)

traceEntry(op_a.name)

traceEntry(op_d.name)

traceEntry(op_c.name)

X

}

}

}

}

}

basic op2() behaviour

goes here

basic op_c() behaviour

goes here

basic op_a() behaviour

goes here

basic op_d() behaviour

goes here

basic op_b() behaviour

goes here

+ foo()

+ bar()

traceExit(op_a.name)

traceExit(op_c.name)

traceExit(op2.name)

traceExit(op_d.name)

traceExit(op_b.name)

+ op1()

+ op2()

Y

Trace

+ op_a()

+ op_b()

+ op_c()

+ op_d()

- trace

+ traceEntry(String)

+ traceExit(String)

File

What about crosscutting concerns?

Crosscutting behaviour must be specified wherever required


Problems with the suggested design

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

  • 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

Phase 2

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)


Theme uml

Phase 1

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


Implications of theme uml thematic design

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

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

Pay

Fine

Borrow

Book

Order

Resource

Add

Resource

Search

Resource

Remove

Resource

Return

Book

Synchronize

ResourceManager

CopyNoGenerator

Resource

Order

Location

Periodical

Book

Course

Fine

Borrower

Copy

Back to our Library example…


Theme uml decomposition based on requirements specification

Pay

Fine

Borrow

Book

Order

Resource

Add

Resource

Search

Resource

Remove

Resource

Return

Book

Synchronize

OrderResource

AddResource

ReturnBook

Synchronize

BorrowBook

SearchResource

RemoveResource

Theme/UML: Decomposition based on Requirements Specification

PayFine


Theme uml decomposition of management resources into different design models

«theme»

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


Decomposing crosscutting requirements into a separate subject

«theme»

Decomposing crosscutting requirements into a separate subject


Composing design models composition relationship

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 models

S1

S2

match[name]

X

X

Matching criteria on the composition

relationship defines the operations

to be merged.

+ op1()

+ op1()

Composition semantics uses delegation to merge corresponding operations from different models

S1S2

:X

X

op1()

S1_op1()

+ op1()

- S1_op1()

- S2_op1()

S2_op1()

Merging behaviours from different models

Specified with a composition relationship which details the elements to be merged.


Capturing crosscutting behaviour in a composition pattern

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

T, i:Integer

AClass

BClass

«bind» (BClass, 24)

Trace

<TracedClass, _tracedOp()>

Trace

:TracedClass

:Trace

TracedClass

tracedOp()

- trace

traceEntry(tracedOp.name)

+ traceEntry(String)

+ traceExit(String)

+ tracedOp()

- _tracedOp()

_tracedOp()

traceExit(tracedOp.name)

File

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


Binding composition pattern to a base design

Library

Trace

<TracedClass, _tracedOp()>

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

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


Another example observer aspect

< Subject, _aStateChange(..) >

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

«theme»

Observer

Collab_ObserverPattern

Subject

:anObserver

:aSubject

  • + aStateChange()

  • _aStateChange()

  • - notify()

  • + addObserver(Observer)

  • + removeObserver(Observer)

aStateChange()

_aStateChange()

notify()

*

update()

subjects

Observer

observers

1

Vector

  • + update()

  • + start()

  • _start()

  • + stop()

  • _stop()

action

aSubject :: notify()

post

all observers in aSubject.observers

are sent update() event

Another example - Observer Aspect

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


Observer aspect example adding removing observers

< Subject, _aStateChange(..) >

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

«theme»

Observer

:anObserver

:aSubject

start(.., Subject,..)

_start(.., Subject,..)

addObserver(anObserver)

:anObserver

:aSubject

stop(.., Subject,..)

removeObserver(anObserver)

_stop(.., Subject,..)

Observer aspect example – adding/removing observers


Theme uml

< Subject, _aStateChange(..) >

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

«theme»

Observer

Library

bind[ < BookCopy, {meta:isQuery=false} >

< ResourceManager, updateStatus()

addView(), removeView()> ]

Pattern Binding

  • Bind BookCopy as a subject and ResourceManager as an observer.


The final design library with observer

«theme»

ObserverLibrary

Collab_ObserverPattern – borrow()

Subjects

action: BookCopy :: notify()

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

The final design – Library with Observer


Composition pattern as reusable aspect design

«theme»

Observer

< Subject, _aStateChange(..) >

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

Library

bind[ < BookCopy, {meta:isQuery=false} >

< ResourceManager, updateStatus()

addView(), removeView()> ]

bind[ < Room, { book(), cancel() } >

< Reservations, update(),

add(Room), remove(Room) > ]

Hotel

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.


Theme uml within the software lifecycle

Theme/UML within the software lifecycle

Compose the designs vs. map to an implementation language

  • 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


Algorithm for mapping to aspectj

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

Map Theme/UML to AspectJ

  • AspectJ Programming Elements (a very short reminder)

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

Mapping AspectJ Program Elements to Theme/UML


Mapping uncomposed crosscutting themes to abstract aspects

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 Uncomposed crosscutting themes to AspectJ (The algorithm)


Mapping composition specifications to concrete aspects

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

«theme»

Observer

< Subject, _aStateChange(..) >

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

Library

bind[ < BookCopy, {borrow(), return()} >

< ResourceManager, updateStatus()

addView(), removeView()> ]

Here’s the design just before the binding


Let s have some java shell we

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

Concrete Library Observer implementation

public aspect LibraryObserver extends Observer

{

//Declarations

declare parents: BookCopy implements SubjectI;

declare parents: ResourceManager implements ObserverI;

//Introductions

public void ResourceManager.update() {

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

}

//Pointcuts

pointcut 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

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

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

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 studentregisters then it must be logged in their record.

    • R4. When a studentunregisters it must also be logged.

    • R5. Professors can unregisterstudents.

    • R6. When a professorunregisters a student it must be logged.

    • R7 When a professorunregisters a student it must be flagged as special.

    • R8. Professors can give marks for courses.

    • R9. When a professor givesa mark this must be logged in the record.


Theme doc action view

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

Requirements snipped from Base Actions and left with Crosscutting only

Crosscutting Action

Crosscutting hierarchy

Base Actions

Clipped Action View


Theme uml

Read from top to bottom

Entity translated to Class

Action translated to Method

Theme/Doc and Theme/UML for register


Theme uml

Behaviors that are crosscut by the logged behavior

Template Method (handle method for base behaviors)

Entity translated to Database

Theme/Doc and Theme/UML: logged

Non Crosscutting. Unique to logged


Theme uml

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

Augmented Associations

Augmented Method

Augmented View (register and logged)


Theme uml

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.


Theme uml

Composable elements

Theme

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

Composition Relationship


Theme uml

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:


Theme uml

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

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

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


  • Login