Upload
lawrence-ashton
View
12
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
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