Theme/UML

1
Theme/UML

• Advanced Software Tools Seminar
• Maayan Goldstein, TAU
• December, 2004

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

3
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

4
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

5
Structural Mismatch Requirements - OO Designs
Scattering
6
Structural Mismatch Requirements - OO Designs
Tangling
7
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 Structurall
y, design elements handling tracing can be
separated and classes requiring trace behaviour
simply have to add a relationship
8
What about crosscutting concerns?
Crosscutting behaviour must be specified
wherever required
9
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.

10
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

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

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

• Identify crosscutting (aspectual) actions and
  entities being used (removing non-crosscutting
  actions)
• Create Clipped Action View that shows the
  crosscutting hierarchy

12
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

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

14
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

15
Back to our Library example
16
(No Transcript)
17
Theme/UML Decomposition based on Requirements
Specification
PayFine
18
Theme/UML Decomposition of management resources
into different design models
19
Decomposing crosscutting requirements into a
separate subject
20
Composing Design ModelsComposition 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

21
Merging behaviours from different models

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

22
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

23
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

24
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

25
Another example - Observer Aspect

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

26
Observer aspect example adding/removing
observers
27
Pattern Binding

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

28
The final design Library with Observer
29
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.

30
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

31
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

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

33
Mapping AspectJ Program Elements to Theme/UML
AspectJ Element Theme/UML
Aspect A crosscutting theme is a design equivalent to an aspect.
Pointcut Operation 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.
Advice Within an interaction diagram, crosscutting behavior may be specified on template operation calls. This behavior is equivalent to advice code.
Introduction Design 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.
34
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.

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

37
Heres the design just before the binding
38
Lets 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)
39
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)

40
Theme development lifecycle
So far weve covered phases 2-3. Lets get back
to phase 1 and talk a little about phase 4.
41
Theme/Doc - Finding Aspects in Requirements

• Allows to refine views of (textual) requirements
  to reveal which functionality in the system is
  crosscuttingAssumes 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)

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

43
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

44
Clipped Action View
45
Theme/Doc and Theme/UML for register
46
Theme/Doc and Theme/UML logged
Non Crosscutting. Unique to logged
47
Augmented View (register and logged)
48
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.

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

50
Composition Relationship
51
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

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

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

54
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