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

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

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

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

8. :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

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

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

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

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

17. «theme» Theme/UML: Decomposition of management resources into different design models

18. «theme» Decomposing crosscutting requirements into a separate subject

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

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

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

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

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

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

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

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

27. «theme» ObserverLibrary Collab_ObserverPattern – borrow() Subjects action: BookCopy :: notify() post: all observers of BookCopy are sent updateStatus() event The final design – Library with Observer

28. «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.

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

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

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

32. Mapping AspectJ Program Elements to Theme/UML

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

34. Mapping Uncomposed crosscutting themes to AspectJ (The algorithm)

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

36. «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

37. 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); } }

38. 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)); }

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

40. 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)

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

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

43. Requirements snipped from Base Actions and left with Crosscutting only Crosscutting Action Crosscutting hierarchy Base Actions Clipped Action View

44. Read from top to bottom Entity translated to Class Action translated to Method Theme/Doc and Theme/UML for register

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

46. 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)

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

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

49. Composition Relationship

50. 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: