UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Uniform support for modeling crosscutting structure Tkatchenko, Maria A. 2006

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata


831-ubc_2006-0325.pdf [ 3.65MB ]
JSON: 831-1.0051588.json
JSON-LD: 831-1.0051588-ld.json
RDF/XML (Pretty): 831-1.0051588-rdf.xml
RDF/JSON: 831-1.0051588-rdf.json
Turtle: 831-1.0051588-turtle.txt
N-Triples: 831-1.0051588-rdf-ntriples.txt
Original Record: 831-1.0051588-source.json
Full Text

Full Text

Uniform Support for Modeling Crosscutting Struct by Mar i a A . Tkatchenko B . S c , University of Br i t i sh Columbia, 2004 A T H E S I S S U B M I T T E D IN P A R T I A L F U L F I L L M E N T O F T H E R E Q U I R E M E N T S F O R T H E D E G R E E O F M a s t e r of Science in T H E F A C U L T Y O F G R A D U A T E S T U D I E S (Department of Computer Science) The University of British Columbia A p r i l 2006 © M a r i a A . Tkatchenko, 2006 Abstract We propose bottom-up support for modeling crosscutting structure in U M L by adding a simple join point model to the meta-model. This supports buil t- in cross-cutting modeling constructs such as class and sequence diagrams, collaborations, and state machines. It also facilitates adding new kinds of crosscutting modeling constructs such inter-type declarations and advice. A simple planner tool produces a uniform representation of the crosscut-ting structure, which can then be displayed or analyzed in a variety of ways. We demonstrate a couple of simple automated analysis tools which take advantage of the exposed crosscutting structure. We also discuss how support for advice could be added to the meta-model and planner, and the semantic differences between advice in U M L and Aspect J . i i Contents Abstract i i Contents i i i List of Tables vi List of Figures vii Acknowledgements x 1 Introduction 1 2 Related Work 5 2.1 Add ing Support for A O P to U M L 5 2.1.1 Standard Extension Mechanisms 5 2.1.2 Meta-Model Changes 7 2.2 Composing Diagrams 9 3 Aspect-Oriented Programming 13 4 Introducing Examples 16 4.1 Graphical Shapes Edi tor Example . 16 4.2 R S A Phone Mode l Example 18 i i i 5 Meta-Mode l Description 25 5.1 U M L Meta-Model 26 5.1.1 Class Diagrams 26 5.1.2 Sequence Diagrams 33 5.1.3 State Machine Diagrams 33 5.2 The Join Point Mode l ( J P M ) 36 5.2.1 Jo in Points 36 5.2.2 Means of Identifying Join Points 36 5.2.3 Semantic Effect at Join Points 37 5.3 Meta-Model Enhanced W i t h the J P M 38 5.3.1 Class Diagrams 39 5.3.2 Sequence Diagrams 39 5.3.3 State Machine Diagrams 40 6 Implementation 41 6.1 E M F Framework 41 6.2 U M L 2 Framework 42 6.3 Mode l Edi tor 43 6.4 The Planner 44 6.4.1 Matching 45 6.4.2 Phases 46 7 Evaluation 50 7.1 Recommending Transitions for State Machines 51 7.1.1 Solution 51 7.1.2 W h a t We Found in Examples 53 7.1.3 Benefit • 54 7.2 Composing Sequence Diagrams 54 7.2.1 Solution 55 iv 7.2.2 W h a t We Found in Examples 56 7.2.3 Benefit 57 7.3 Advice 58 7.3.1 Solution 59 7.3.2 Benefit 61 7.4 Discussion of Contributions 62 7.4.1 Show that a JPM-Enhanced Meta-Model C a n Support Cross-cutting Structure in a U M L Model 62 7.4.2 Traversing the Mode l to Collect Crosscutting is Straightforward 63 7.4.3 The Above Help Modeling Tools to Access, Analyze, and Dis-play Crosscutting Relationships of Interest 63 7.4.4 Planner Tool 64 7.5 Feedback and Future Work 64 8 Conclusion 66 Bibliography 68 v List of Tables Crosscutting relationships that are recorded by the planner between elements in various U M L diagrams 38 v i List of Figures 4.1 Class and sequence diagrams for the Graphical Shapes Edi tor example. 17 4.2 Class and sequence diagrams for the Subject-Observer design pattern. 17 4.3 Sequence diagram for one user placing a call in the R S A model example. 19 4.4 State machine diagrams for the Network and Phone classes in the R S A example. S M stands for State Machine 20 4.5 Sequence diagram for the two-user call in the R S A example. The diagram is split between this figure and Figure 4.6, wi th the com-mon link being the WirelessNetwork lifeline. The circled numbers "1" and "2" represent the places where the two diagram fragments link together. The messages following "1" in Figure 4.6 (starting at Phone.checkForldle) are inserted after the "1" (WirelessNetwork.initiateCall) in the current figure. Same for the circled "2": messages starting at PhoneDisplay.displayCalllnfo in Figure 4.6 are inserted after Wire-lessNetwork.endCall in the current figure 21 vii 4.6 Sequence diagram for the two-user call in the R S A example. The diagram is split between this figure and Figure 4.5, wi th the common link being the WirelessNetwork lifeline. The circled numbers "1" and "2" represent the places where the two diagram fragments link together. The messages following "1" in this figure are inserted after the "1" (WirelessNetwork.initiateCall) in Figure 4.5. Same for the circled "2": messages starting at PhoneDisplay.displayCalllnfo in the current figure are inserted after WirelessNetwork.endCall i n Figure 4.5. 22 4.7 Class diagram for the R S A model example 23 5.1 Class diagram and collaboration meta-model, from the U M L super-structure document 27 5.2 Sequence diagram meta-model: lifelines and interactions. Figure 5.3 contains the other half of this meta-model. From the U M L super-structure document 28 5.3 Sequence diagram meta-model: messages and interactions. Figure 5.2 contains the other half of this meta-model. F rom the U M L su-perstructure document 29 5.4 State machine diagram meta-model, from the U M L superstructure document 1 . . 30 5.5 Example of a class diagram as shown wi th U M L 2 32 5.6 Example of a sequence diagram as shown wi th U M L 2 34 5.7 Example of a state machine diagram as shown wi th U M L 2 35 6.1 Class diagram for the planner implementation, including the ma-jor classes and operations. Helper/ut i l i ty classes and operations are omitted for clarity 47 7.1 Snippet of the output of the transition recommendation tool for state machines, as run on the R S A model example 53 vi i i 7.2 Output of the sequence composition tool on the Line.moveBy se-quence from Figure 4.1, wi th role bindings not included 57 7.3 Output of the sequence composition tool on the Point .moveBy se-quence from Figure 4.1, including role bindings 57 7.4 Graphical Shapes Edi tor example class diagram, wi th an example of advice 59 ix Acknowledgements There are many people without whose support this would not have been possible, or at least would have taken much longer than it has. First and foremost, I 'm grateful to my supervisor, Gregor Kiczales, for all the time and effort he has put into working wi th me on this, both when brain-storming ideas and wri t ing the submission for the conference. Thanks for giving me the opportunity to work on this project, and present it at conferences — this was definitely an educational and rewarding experience. I hope you keep finding time to play wi th your students' code despite al l of your other responsibilities! Thanks to Er ic Wohlstadter, who generously agreed to be my second reader when I came to h im in a panic after realizing that I needed one. I should also thank both the employees and fellow C A S students at the I B M -Ottawa Pal ladium lab, who are too numerous to name here, and who shared wi th me their feedback and ideas, which helped shape this project. Y o u made my time in Ottawa one of my best summers away from Vancouver. Final ly, thanks to my parents, for always being there for me and encouraging me to go on and look for bigger and better things, both in life and education. Thanks to all of my friends, and Dan, for your endless patience and your tireless attempts at distraction when I got too bogged down in work. I 'm glad you're all a constant presence in my life. Thanks for all the fun times we had, and new sports you have introduced me to. M y time spent wi th all of you has definitely been a rewarding experience in its own right! M A R I A A . T K A T C H E N K O The University of British Columbia April 2006 Chap te r 1 Introduction The Unified Model ing Language ( U M L ) provides support for modeling a system from different perspectives [24]. Some of these perspectives have a hierarchical relationship to each other, such as package and class diagrams. Others have a crosscutting relationship [19, 23], whereby a given element may appear in both diagrams, wi th each diagram only partially specifying the element. For example, a sequence diagram can crosscut a class diagram, in that it may include calls to methods from multiple classes [14, 10]; collaboration diagrams can crosscut class and sequence diagrams [33]; statecharts can crosscut all the others. There have also been proposals to extend U M L wi th new crosscutting modeling constructs such as aspects, advice, inter-type declarations (ITDs) and role bindings [1, 16, 20, 26, 32, 35, 39]. Model ing in U M L has gotten a boost from the adoption by the O M G of standards for the specification of notation and semantics, and the development of open-source modeling frameworks such as E M F [29] and U M L 2 [30]. Such frame-works enable the creation of more task-specific, less bloated modeling tools than what is generally available commercially. Despite the growing popularity of U M L , it s t i l l has a number of strong drawbacks, in particular the misalignment between the feature-oriented requirements and object-oriented design and code, as discussed by Clarke et. al. in [5]. 1 Aspect-oriented programming (AOP) is an area that focused initially on sup-port for crosscutting in code. In code, crosscutting can cause a single concept to have to be implemented in multiple classes and multiple locations in code, because of the way the system has been modularized. AOP enables such concerns to be implemented in a modular rather than scattered and tangled fashion. With mod-eling, we take scattering to mean that the model-level implementation of a single concept is spread across multiple diagrams of the same kind (e.g. many methods in a class diagram). But because UML already provides crosscutting diagram kinds, crosscutting structure can already be modularized in UML (e.g. a sequence diagram and a class diagram can modularize concerns that crosscut each other). Our work was partially motivated by observing the difficulty of adding pat-tern composition support to existing UML tools. Prior work in AOP has shown that many patterns are easier to implement using Aspect J [9]. We show how we can achieve the same kind of benefits from aspect-orientation for patterns during modeling by introducing a join point model (JPM) to the UML meta-model. We also present a way in which we can support other forms of crosscutting structure in UML. So rather than using modeling to support AOP [15, 16], our focus is on using the central mechanism of AOP to support modeling. In this work we show that the modeling of crosscutting relationships within UML diagrams such as those mentioned above can be supported by using a join point model. We propose bottom-up support for crosscutting in UML, by adding a simple JPM to the UML meta-model. Our enhanced meta-model supports display and automated analysis of both pre-existing and new forms of crosscutting structure between elements in UML diagrams. We implement a simple tool (which we call the planner) which exposes the crosscutting structure in the model. Through a number of examples, we show how the JPM makes crosscutting structure explicit and simplifies implementation of analysis tools. In AOP, weaving is defined as the coordination of interactions between the 2 crosscutting concerns. In A O P languages like AspectJ , this involves ensuring that advice runs when it should and inserting inter-type declarations at their target locations. This is done in two phases, the planner followed by the munger — the planner identifies the actual join points at which the concerns crosscut, and the munger implements the interaction (e.g. by modifying execution, modifying code, or modifying the model). In this thesis, we present a planner tool that provides simple coordination of crosscutting structure in U M L models. B y providing a uniform representation of the interactions between crosscutting elements, our planner makes it easier to implement model analysis and display tools. The planner records its results by associating wi th each model element a set of all the other model elements with which it crosscuts. Once the pair-wise crosscutting structure is collected into these sets, it can be analyzed and presented in a variety of ways. In order to understand crosscutting relationships as they occur in modeling, and how they affect the design of the system as a whole, we need to be able to represent the relationships between diagrams in a more coherent way. U M L models — in particular large, industrial-sized U M L models — are often difficult to work with, at least in part due to the lack of information in one diagram on the behaviour or structure defined in another. What we would like to see are tools that help the modeler see the big picture, and the place of specific elements wi th in it. This work presents a framework and a planner tool that would simplify implementation of analysis tools that would help the modeler see the big picture. We also discuss two simple analysis tools that we have implemented. We do not propose a graphical no-tation for showing crosscutting relationships; the crosscutting relationships exposed by our planner can be displayed in any number of ways, and examining which is better is left to future work. The contributions of this work are to show that (i) the crosscutting structure of several traditional modeling relationships, as well as newer aspect-oriented mod-3 eling relationships, can be supported by a meta-model enhanced with a simple JPM, (ii) traversing the model to collect the crosscutting structure (planning) is straight-forward, and (iii) the combination of (i) and (ii) makes it easy for modeling tool implementers to create tools that access, analyze and display crosscutting relation-ships of interest. We also present (iv) a planner tool which exposes the crosscutting structure in the model for use by the tools mentioned in (iii). The rest of this document is structured as follows. Chapter 2 goes into detail about the related work, setting up the context for our work. Chapter 3 provides a background on AOP and explains the major concepts that will be used in this thesis. Chapter 4 introduces a couple of examples, used in the subsequent chapters. Chapter 5 describes the additions we made to the meta-model, as well as the reasons behind these choices. Chapter 6 talks about the implementation of our planner tool. Chapter 7 uses the examples introduced in Chapter 4 to show how our planner would help answer some questions we thought would be pertinent to model analysis. Chapter 8 concludes the discussion with a summary and some suggestions for future work. 4 Chap te r 2 Related Work There are two streams of research related specifically to our work. The first looks at explicitly adding aspects or A O P concepts to U M L , either by using the extension mechanisms provided in U M L , or by changing the U M L meta-model directly. The second looks at improving the design process by allowing the modeler to decompose the design into independent components, and then providing means to compose the different components or diagrams, which helps alleviate problems associated with some forms of crosscutting. 2 . 1 Adding Support for AOP to UML 2.1.1 S t a n d a r d E x t e n s i o n M e c h a n i s m s The following proposals use the standard extension mechanisms provided by U M L to support aspects or aspect-oriented extensions. Stein et al. [35] introduce the concept of weaving to the extended meta-model of U M L through the use of stereotypes. The work deals wi th both structural crosscutting in the form of introductions, and behavioural crosscutting in the form of advice. The behavioural crosscutting case is closest to our work, so we wi l l focus on it in our discussion. The base (crosscut) and advice (crosscutting) behaviours, 5 specified by sequence diagrams, can be merged to display the final expected behav-ior. This involves split t ing apart the base sequences at the join points, and later composing the sequence wi th the crosscutting behaviour included at each of the join points affected. The set of calls in a sequence may need to be totally ordered for weaving to guarantee preservation of behaviour, which is computationally ex-pensive. The authors use stereotypes to imitate the advice and pointcut constructs of Aspect J , and explicit weaving instructions to specify composition of behaviours, thus forcing the modeler to think at a lower level of abstraction. Pawlak presents a U M L notation for designing aspect-oriented applications [26]. In this work, he introduces three new concepts to U M L : groups, pointcut relations, and aspect-classes. Groups are used to specify base objects in an aspect-oriented context. Pointcut relations define crosscuts within the program, l inking aspect-methods to points in the base class. Aspect-classes implement extensions of the base program semantics at points denoted by pointcut relations, and contain both regular and aspect-methods. Stereotypes are used to support the use of all of these new modeling elements. Ho and Jezequel present a toolkit for building application-specific weavers for generating detailed design models from high-level aspect-oriented U M L models [12]. These weavers are implemented as model transformations — each weaving step is a transformation applied to a U M L model. Transformations are specified by the designer by explicitly composing a set of operators available from the toolkit. The authors use buil t- in extension mechanisms in U M L , namely stereotypes, tag values, and design pattern occurrences, to add non-functional information or crosscutting behavior to base model elements. This information is then read by the appropriate weaver, and applied during the relevant weaving step. Jezequel and Plouzeau discuss how features of a U M L model can be orga-nized around the notions of quality of service contracts and aspects [15]. Contracts are modeled in U M L using a small set of stereotypes, and specify non-functional 6 properties. Aspects are represented using parameterized collaborations and trans-formation rules, and specify how contracts can be implemented. Unlike the above work, the authors here take the approach that in order for aspects to be reusable, the join points have to be specified separately. Now there are three entities: the target model, aspect, and join point definition. O C L is used to specify the transformations that take place during weaving. Suzuki and Yamamoto add new elements for the aspect and woven class us-ing stereotypes, and reuse an existing element for the aspect-class relationship [38]. A n aspect is shown as a class wi th an "aspect" stereotype, and may contain op-erations wi th the stereotype "weave", which can represent either introductions or advice. They use the realization relationship to represent the aspect-class depen-dency. Classes wi th aspects woven into them are shown using the "woven class" stereotype. The main contribution of this work, however, is the development of the U X F / a , an extension to the U X F ( U M L eXchange Format), an X M L - b a s e d language for describing U M L models. W i t h U X F / a a modeler can add aspect information to models, and the authors have developed translators that allow U M L aspect models to be shown in popular C A S E tools such as Rational Rose and MagicDraw. 2.1.2 M e t a - M o d e l Changes The work discussed in this section uses extensions to the U M L meta-model to sup-port aspects or aspect-oriented extensions. Kande argues that aspects need to be first-class elements in U M L [16]. His work is important to us because it shows that others have considered, and suc-cessfully argued for, the approach of introducing weaving or crosscutting as a basic concept in U M L , instead of using extension mechanisms. He claims that the com-position of a standard U M L model with an aspect model does not do a good job of modularizing the separate concerns — the elements in the design model are coupled more than they would be in the code. In addition, the composed model does not 7 communicate the abili ty to plug and un-plug aspects from the core functionality. He shows that the main reason for this is that since U M L doesn't include the concept of weaving, the concerns that are well-separated in the A O program end up being scattered throughout the design model. Thus, a new model element which encap-sulates the specification of the aspect as well as models the interaction between all crosscutting objects may be needed. Ci t ing the restrictions that arise when using stereotypes and profiles to ex-tend U M L , Lions proposes introducing A O P into U M L at the meta-model level [22]. His argument is that given a meta-model, it is relatively easy to provide tool support for models created based on the meta-model. Since in our work we are modifying the meta-model for U M L by introducing support for crosscutting, it is helpful to know that the question of tool support has been considered by others. We believe that the ability to provide modeling tool support for a modified meta-model, coupled wi th our meta-model's uniform support for various kinds of crosscutting, supports our view that extending the U M L meta-model to include A O concepts should be done from the bottom-up. Chavez and Lucena also address the issue of extending the U M L meta-model to cope wi th aspect-oriented modeling ( A O M ) [4]. The meta-model is modified in order to make explicit in U M L diagrams what the authors consider to be the main notions in A O P : component (base element), aspect (crosscutting element), join point, crosscutting, and weaving. This proposal has similarities to the composition patterns approach, described in the following section (Section 2.2). Han et. al. also argue that a formal meta-model w i l l simplify tool support, and so propose a meta-model for Aspect J [8]. Their main argument against heavy-weight extensions to the U M L meta-model is that they are complex and costly to implement, especially when in this case the authors are interested in building an AspectJ-specific tool, and not a general C A S E tool. They start by creating a sim-plified meta-model for the static structure of Java using the meta-object facility 8 (MOF), then extend it to include the AOP concepts specific to Aspect J. All the major elements of AspectJ are added as either subclasses of, or associations be-tween, the Java meta-model classes. The authors claim that interoperability with other MOF-based tools for Java and AspectJ is guaranteed, however that would require that everyone adopt the same meta-model for Java and AspectJ. 2.2 Composing Diagrams This section deals with works which provide some ability to compose diagrams or models which were specified separately, and are possibly incomplete. Straw et. al. look into composing primary and aspect class diagrams [37]. In their mechanism, conflicts and undesirable emergent properties can be identified either during composition, or during analysis of the composed model. Composition directives can be used to resolve conflicts during composition. However, composi-tion directives require developers to already be aware of the potential conflicts in the model, both within the base and aspect models, which would reduce the ability to develop these models independently. Instead, we believe that a system should help modelers discover this information through simple analysis of crosscutting re-lationships in the existing model(s). Clarke and Walker propose the use of composition patterns to specify cross-cutting concerns [6]. Composition patterns are based on a combination of UML templates and the merge integration from subject-oriented design [5]. A composi-tion pattern describes the design of a crosscutting requirement independently from any design it may crosscut, and so may be reused wherever it is applicable. By using the parameters in UML templates, which also provide a mechanism for bind-ing the parameters to model elements, they can specify composition of crosscutting behaviour with base designs in a reusable way. This approach requires explicit iden-tification of aspects and binding specifications, and can produce composed diagrams, which show the result of bindings applied to the base design. The main focus of this 9 approach is on composition during the design phase, in order to validate the design of a composition pattern. However, the authors note that its also possible to main-tain the separation through the code phase, using an appropriate implementation model. In particular, the authors consider mappings from composition patterns to Aspect J programming constructs. Ossher and Tarr present Hyper J [25], a tool which supports multi-dimensional separation of concerns [40]. The main idea behind this approach is that a program can be decomposed in any number of ways. A hyperspace represents the concern space, in the form of a matrix where each axis represents a dimension of concerns, and each point a concern in that dimension. Each partial decomposition, relating to a particular concern, is known as a hyperslice, and hyperslices can be composed into hypermodules using composition rules to take care of any conflicts that may arise. HyperJ is a tool which allows the developer to use these concepts in Java by allowing "identification, encapsulation and integration of multiple dimensions of concerns". They suggest that their approach could be used at any stage of the soft-ware development life cycle, but do not describe an implementation of the approach for modeling. In their H y p e r / U M L approach, Phil ippow et. al. create a nice continuation to the previous work, by extending the Hyperspace approach to U M L , and use it for the development of product lines [27]. Variabil i ty common to product lines is implemented using feature driven decomposition (and composition) according to concerns, which correspond to features. They argue that this may allow a higher degree of automation during development. In addition to U M L , models and relations are partly defined by the O C L . Components are modeled using H y p e r / U M L and are implemented in H y p e r / J . In [7], Georg et. al. develop a two-level structure of composition constraints to deal wi th conflicts that may occur during composition of aspect and primary models. A n aspect model consists of U M L template diagrams which describe the 10 pattern. Each template element specifies properties that w i l l be incorporated into the selected points in the primary model. Composition strategies and composition directives correspond to the two levels of constraints. Composit ion strategies use high-level heuristics to determine how aspects should be composed wi th the primary model, while composition directives deal wi th specific conflicts that arise in the context of particular aspect and primary models. Ka t a r a proposes building a refinement hierarchy for a class or sequence dia-gram [17]. Each concern is viewed as a collection of superposition steps that define it. The authors use the term aspect to refer to these concerns. A l l additional func-tionality crosscuts the starting model, so each is an aspect, even though it is part of the core functionality of the final model. It is possible to merge sequence diagrams to see the composed behaviour of a number of sequences. Prehofer's work [28] addresses the merging of state chart diagrams in much the same way as we treat sequence diagrams. He aims to show that statechart mod-eling can be extended to modular composition of features, as well. The behaviour of features is specified individually with incomplete diagrams, which are then com-posed in a way similar to many of the other approaches described in this section. Hierarchical statechart diagrams (composite states) and parallel composition using concurrent states are used extensively to remove conflicts during composition. Stein and Hanenberg demonstrate how U M L can be extended to show aspect-oriented crosscutting. They use U M L collaborations and interactions to specify the details of structural and behavioural crosscutting, respectively, in a given decom-position [35]. U M L collaborations are seen as inherently crosscutting elements, since they are only guaranteed to describe the roles that model elements perform in certain situations. Interactions are used because the link used to communicate a message can be seen as the point where crosscutting behaviour can be added. Weaving instructions specify the model elements being crosscut. For structural crosscutting, they define base classes that wi l l be crosscut; for behavioural cross-11 cutting, the instructions specify the links in the base collaboration. Their weaving mechanism for U M L generates standard U M L models from aspect-oriented models. The mechanism's adherence to AspectJ semantics allows for a smoother transition from modeling to development. In another work, the same authors address the question of the design of crosscutting features in U M L , and whether U M L has sufficient abstractions for this [36]. The authors focus on graphical representations of the details of crosscutting features, instead of trying to find the best matching representation for crosscutting features on some meta-level. The crosscut and crosscutting elements, the composi-t ion strategy, and the join points can all be specified independently. The modeler is required to explicit ly state al l the crosscutting relationships and join points while designing the system. 12 Chap te r 3 Aspect-Oriented Programming Aspect-oriented programming ( A O P ) emerged from the observation that programs often contain concerns which are difficult to fit into any particular modularization. Because of the way modules encapsulate behaviour and structure, there often are concerns that don't belong to a single module, but instead are implemented in multiple locations in different modules. This is similar to modeling, where each diagram can be thought of as a particular module, and the design of a single concept is spread across many modules (diagrams). A O P focuses on providing support for modular implementation of cross-cutting concerns. In ordinary object-oriented ( 0 0 ) or procedural programs such crosscutting concerns lead to scattering and tangling in the code. Scattering occurs when the implementation of a single concept is scattered across multiple locations in the code, while tangling implies that the implementations of multiple concerns are interwoven wi thin a single class. A O P enables modular implementations of such concerns. AspectJ [18] is one popular implementation of A O P . A O P addresses modularization issues by introducing new elements and con-structs to the programming language. The main concepts introduced by AspectJ-like languages are advice, aspects, join point model, and inter-type declarations (ITDs). Inter-type declarations (ITDs) allow for defining fields or operations of a 13 class, from outside the class. ITDs are placed in an aspect, but define fields or methods of a target class. For example, if method Foo.bar() is defined using an I T D in an aspect, then the method bar() belongs to class Foo, and calls to barQ can be made on objects of type Foo. Pointcuts are expressions which can pick out points in the execution of a program. Pointcuts are frequently specified using type patterns, which match a particular subset of points in the program's execution. Advice is a mechanism that allows a programmer to modify the behaviour of existing base code, by specifying the code to be executed instead of or in addition to the existing code. Advice can therefore be before, after, or around. Finally, aspects encapsulate advice and ITDs, as well as pointcuts. The pointcut specifies the point(s) where the advice is applied, or the ITDs are introduced. These points are called join points, and are identified wi th in the ontology of a join point model ( J P M ) . J P M s are the central mechanism that supports crosscutting in A O P [23]. A J P M can be described in terms of three characteristics: the nature of the join points, a means of identifying the join points, and a means of affecting semantics at join points. In AspectJ , dynamic join points are points in the program's execution, they're identified by pointcuts, and the means of semantic effect is for advice to run before, after, or around the join point. In Spr ingAOP [34], the dynamic join points are method invocations, the means of identification are pointcuts, similar to those in AspectJ , and the means of semantic effect is for advice to run before, after, around the join point, or in case the method throws an exception. Since pointcuts in Spring are simple Java classes, it is possible to declare custom pointcuts simply by writ ing a new class. In AspectJ the static join points are fields, methods and the parents of a type. W i t h AspectJ , you can add fields, methods, or interfaces to classes, while Spring only allows introduction of interfaces to objects. A O P implementations such as AspectJ rely on a weaving process to coordi-nate the execution of advice with join points. In current AspectJ implementations, 14 advice weaving happens at compile or load time, and is broken down into two stages: planning, and code munging. Dur ing the planning stage, join point shadows [11] wi th in the code are analyzed to check whether they match the pointcuts associated wi th advice. The matching shadows are annotated wi th each advice that could apply at that point. Dur ing the munging stage calls to advice methods are added at the matched shadows. Runtime residual tests can also be added to guard the execution if the advice w i l l match only under certain conditions, which won't be known unti l runtime. 15 Chap te r 4 Introducing Examples In this chapter, we introduce the example models we used to test our planner. These wi l l be used in Chapter 5 and Chapter 6 to explain some of the more complicated points of the meta-model and planner, respectively, and also in Chapter 7 to evaluate our framework's ability to simplify the implementation of analysis tools. We wi l l attempt to point out some interesting characteristics of each of the designs, which we wi l l focus on during our analysis. 4.1 Graphical Shapes Editor Example The model we use is an adaptation of the original graphical shapes example used in the seminal A O P papers [18, 19, 23]. Two model fragments are shown in Figures 4.1 and 4.2. B o t h contain a class diagram and sequence diagram(s). The top fragment models the main functionality of the Display for Shapes, which include Points and Lines. The bottom fragment models the Subject-Observer design pattern. The bindings of the elements in the top fragment to the elements of the design pattern are included in the upper class diagram. Note that this is not standard U M L format for representing collaborations, and we're just using this shorthand representation to simplify the figure, and show the dependencies in a more compact way. This example is interesting mainly because of the application of a pattern to 16 i Dependency 1: i Client; Shape j Supplier; Subject j Dependency 2: , Client; Shape.moveBy(int, int) i Supplier: Subject.changed _L" Point getxo getYO setX(int) setY(int) moveByfint, int) Display * Shape refreshO movBBy(int, int) Line getPio getP20 setP1 (Point) setP2(Point) moveByflnt, int) I Dependency 1: I Client: Point I Supplier: Subject I 1 Dependency 2: | Client- Point.setX(mt), Point.s , Supplier: Subject.changef) . Dependency 1: , Client: Line I Supplier: Subject I Dependency 2: I Client: Line.setPI(Point). Line.setP2(Point] 1 Supplier: Subject.changed I :Llne I I end1:Pointl lend2:Polntl moveBypnt, in^ j m o v e B y ( i n t , int) moveBy(int, int) I Point I moveByfint, int) £setX(int) £setY(int) Figure 4.1: Class and sequence diagrams for the Graphical Shapes Editor example. I :Sub|ect I hObserverl Subject * Observer addObserve r(Observe r) re moveO bserve r(Ob server) updateObserversO changeO updateQ changeQ updateQ Figure 4.2: Class and sequence diagrams for the Subject-Observer design pattern. 17 the base design. This w i l l allow us to use the sequence diagram composition tool (Section 7.2) to analyze the behaviour of the final system, which reveals interesting information about the behaviour of the composed system. This is also a classic A O P example, and wi l l be familiar to many of the interested readers when we discuss the possible applications of our J P M and planner to aspect-oriented modeling in Section 7.3. 4.2 RSA Phone Model Example The second model is more of a real-world example. It is part of a model that we obtained from the Rat ional Software Architect (RSA) group at IBM-Ot tawa , and is one the examples used during their own user testing of R S A product. R S A is an Eclipse-based design and development tool which uses model-driven development with U M L to create applications. As such, this is the best example we have of real-world tasks required of users, as compared to the other designs we've used. We used the class diagram and sequence diagrams provided to us as they were. The state machine diagram was slightly too complicated for our purposes, so we created two simple state machines based on the information found in the sequence diagrams. This example models a simple phone system, where both the Network and the physical components of the Phone (namely Keypad and Display) are represented. A number of different sequence and state machine diagrams specify the behaviour of the system. These diagrams are shown in Figures 4.3 — 4.7. In this document, we include only two of the three sequence diagrams we used in testing. We do this in order to save space, and also because the interaction sequence for the omitted sequence diagram is just a more detailed version of the first sequence diagram. The first sequence diagram (Figure 4.3) specifies the interactions that take place when a user places a call. The second sequence diagram, one that we have omitted from this document, goes into slightly more detail of the same in-teraction, including operations like validation. The final sequence diagram (Figures 18 cm' n> £± CO co CD C CD o CD Crq O CD o 5' o CD CO o CD X 3 so «use case realization)* Place a call - Alternative Flow 2 : jFclsieTiUer^j^ • .{^phone cSsrjay5:Phonedisplay^= pssphonespeaker5:Phone speakers •::':':;:lv;V;';:. l:d«INumber phones Phone ~ WrelessNetwbrtlWrelefl 11: irt.j:rxi:; number).; ; >.;:';;i::!.!;.;::;:;: 1.2: dfeplayNumbert number):: 1.3: beepx 1.4.1 ^putPhaneNumber ( phoneNumber) j 1.4.2: pfocessNumber ( phoneNumber) { f; : ; : : ; « r e t u r n » : : : ' ' } \ -115: prctcessNumber (ptoneNumber) vi.6: sendCafllnfoGd, phooel^mber) •• 1.7::validatePhoneNurriber( id, phoheNunter''' ". ^ettxrT»:^;-;:1.;j:':;'-:w ;:::-!;:;.;!::•',•; •::l-.8: vafcdabPhoneNLmber( id;phoneMurnper.) •: 1.9: sendEcraMessage ::'l;10:.pushEnd 1.10.1: displayMessage;. : . 1.10.2: inputEndCal; ( Waiting 1 Call In Progress PlacingCall Initiating sendCalllnfo Validating [else] Processing 'alidatePhoneNumber if [validated] Network State Machine (NetworkSM) < • Inactive hangup Talking initiateCall initiateCall EnteringNumber processPhoneNumber Processing validatePhoneNumber Validating Phone State Machine (PhoneSM) Figure 4.4: State machine diagrams for the Network and Phone classes in the R S A example. S M stands for State Machine. 20 CalienUserlj phone keypad:Pho.. wireless network:Wireless network'? phono msmor.. PphohG^pGaker: Phb;, IphonsidsplayiPhone display! I phone: Phone; : pushSend.; :lnputbigit( number;)-:; :.:;displayisiurnb9r( number ) . beep;:. • |^ inputPhonGNumberf phoneisfcjmber)' displayMessage , i.ihitiateCallC.id/; ^ ^eNumber;;). © VpushEhd' [ InputEndCaN; ••• entiCall(id) ;'disp!ayC l^lInfo(phoneNumbGr/.lBhgth):-,;V[1 storeCallInfo(PhoneNumber( Length)' Figure 4.5: Sequence diagram for the two-user call in the R S A example. The dia-gram is split between this figure and Figure 4.6, wi th the common link being the WirelessNetwork lifeline. The circled numbers "1" and "2" represent the places where the two diagram fragments link together. The messages following "1" in Figure 4.6 (starting at Phone.checkForldle) are inserted after the "1" (Wireless-Network.initiateCall) in the current figure. Same for the circled "2": messages starting at PhoneDisplay.displayCalllnfo in Figure 4.6 are inserted after Wireless-Network.endCall in the current figure. 21 (M.h— :•*£:! • £ © Figure 4.6: Sequence diagram for the two-user call in the R S A example. The dia-gram is split between this figure and Figure 4.5, wi th the common link being the WirelessNetwork lifeline. The circled numbers "1" and "2" represent the places where the two diagram fragments link together. The messages following "1" in this figure are inserted after the "1" (WirelessNetwork.initiateCall) in Figure 4.5. Same for the circled "2": messages starting at PhoneDisplay.displayCalllnfo in the current figure are inserted after WirelessNetwork.endCall in Figure 4.5. 22 Phone speaker beepO nngp Phone phoneNumber initiateCallO answerCallO hangUpO inputEndCallO sendErrorMessageO initiateCall(id, phoneNumber) processNumber(phoneNumber) inputDigit(number) validate PhoneNumber(phoneNu mber) checkForldle(id, phoneNumber) Phone memory storeCalllnfb(phoneNumber, length) Phone display displayMessageO displayCallerlnfo(id) displayCalllnfo(phoneNumber, length) displayNumber(phoneNumber) displayNumber(number) Phone keypad dialNumberO pushTalkO pushSendO pushEndQ User accountID phoneNumber Wireless network endCall() endCall(id) sendCalllnfo(phoneNumber) sendCalllnfo(id, phoneNumber) validatePhoneNumber(phoneNumber) validatePHoneNumber(id, phoneNumber) initiateCall(id, phoneNumber) Figure 4.7: Class diagram for the R S A model example. 23 4.5 and 4.6), shows the specification of the behaviour of both the users involved in a phone call. The sequence is split between the two diagrams, wi th the common link being the WirelessNetwork lifeline. The model also contains state machine diagrams for the Phone and PhoneDis-play (Figure 4.4), detailing the states objects of these classes may enter during their use, as well as a class diagram for the system (Figure 4.7). This model was originally used to test out the recommendation tool for state machine diagrams (discussed in Section 7.1), where, given sequence diagrams and a (possibly incomplete) state machine, the tool recommends which transitions are possible out of each state, based on the messages that can be sent according to the sequence diagram. Since there are a number of reasonably involved sequence dia-grams, this example wi l l also be useful for testing the sequence diagram composition tool we describe in Section 7.1. 24 Chap te r 5 Meta-Model Description We have developed a simple realization of our meta-model on top of the U M L 2 modeling framework [30], which is an implementation of the U M L 2.0 meta-model for the Eclipse platform. It is based on the Eclipse Modeling Framework ( E M F ) [29]. Our ini t ia l implementation actually used E M F , and the meta-model it provides, as a basis for our tool, and we briefly discuss the differences between the two frameworks and the reasons for the switch at the start of the following chapter. We would like to draw the reader's attention to the distinction between U M L 2 and U M L 2.0. The two terms are very similar, but mean different things. U M L 2.0 refers to version 2.0 of the U M L language specification, maintained by the O M G . U M L 2 refers to an EMF-based implementation of the U M L 2.0 meta-model for the Eclipse platform. So, U M L 2.0 is a specification while U M L 2 is a complete implementation of this specification. Our implementation has three main components. Firs t , we take a subset of the meta-model of the U M L modeling language, which includes core elements of class diagrams, sequence diagrams (represented by Interactions), and state machine diagrams. In addition, the class diagrams are extended wi th a mechanism for inter-type declarations. Second, this subset of the U M L meta-model is extended with a J P M . Finally, we present a planner which coordinates crosscutting structure in 25 models based on this meta-model. The extensions to the meta-model provide the foundation for the planner to record its results. In this chapter, we discuss the first two components. The next chapter deals specifically wi th the planner implementa-tion. 5.1 UML Meta-Model A model in our system is formed from any number of class diagrams, sequence diagrams, and state machine diagrams. A l l of the diagrams are consistent wi th the U M L 2.0 meta-model, since we use the U M L 2 framework to create our models. Figures 5.1 — 5.4 show the subset of the U M L meta-model wi th which we are working, wi th the J P M additions highlighted in red and circled. A l l of these figures are taken from the U M L superstructure document, available from the O M G website [24]. The diagrams in U M L 2 are currently represented in a simple tree format instead of a standard U M L graphical notation, since in fact U M L 2 is a framework that is intended for use as a basis for modeling tool implementation, and not for the creation of models. However, since ours is a proof-of-concept tool, we do not concern ourselves wi th a proper visual display at the moment. A s far as we are aware, there are also no mature projects that would enable us to create a graphical editor/display for an arbitrary meta-model. The G E F project [31] under Eclipse presents one possibility, but it is sti l l in the early stages of development. 5.1.1 Class Diagrams In class diagrams we support class and interface elements, which can also have properties (fields) and operations. We support generalization relationships, but at the moment we don't support relationships such as dependency, aggregation, realization, etc. We allow operations and properties to be inter-type declarations (ITDs) in that they can be located in one class, but actually define a member 26 to 2" 3 g 2 cm S3 p o o o o CD CD xs CD O StructuralFesture •/superclass Kf |+subsettedPropertyi +class «enumeration» AggregationKind none shared composite \Relat>onsh}p\ ICtessifier Property SsDerived: Boolean=false isReadOnly: Boolean=false SsDerivedUnion: Boolean=false /default: String aggregation: AggregationKind=non£ /IsComposite: Boolean <-memberEnd •association 2 . " 0..1 +ownedEnd +owningAssociation 0..1 , +navigableOwnedEnd Association isDerived: Boolean=false 0..1 +class • 0..1 +ownedOperation isQuery: Boolean=false disordered: Boolean /isllnique: Boolean flower: Integer /upper: UnlimitedNatural largetClass: Class •coveredBy IntersctionFrsgment Interaction •interaction • 1 •lifeline •covered 1 •fragment 0..1 OccurrenceSpecification •covered Statelnvariant 1 1 •covered Lifeline r7 cfosscultingJoinpoints X V J. lO - ' l I Joinpoint Represents 0..1 0..1 CormectsbleBement (from interne!Structures} NamedElement (from Kernel) •selector OpaqueExpressicn (from Kernel) Interaction •enclosinblnteraction Behavior (from BasicBehaviors) Joinpoint crosscuttin g J oin p o ints NamedEtement |<J-5 Interaction 1 • -^ -interaction •^ -message Message 0..1 +sendEvent /messageKind: MessageKind message-Sort: MessageSort Q ^ +receiveEvent -•-message -^connector •0..1 Connector 0..1 0..1 Mess&geEnd -^ signature OccurrenceSipecirtcation NamedElement a^rgument UessageO ecu rrencsj Specification v/alu&Spectficatiod +event «enumeration» MessageSort synch Call asynchCail asynchSignal «enumeration>> MessageKind complete lost found unknown MessageEvent Figure 5.3: Sequence diagram meta-model: messages and interactions. Figure 5.2 contains the other half of this meta-model. From the U M L superstructure document. 29 o B era ts 1-1 t-i- CD c + £» CD B £» O cr 3" B B CD o CD CD CD o 1-1 CD O o Behavior «enumerator» TransitionKind internal local external «enumerator» PseudostateKind initial deepHistory shallowHistory ioin fork junction choice entryPoint exitPoint terminate •connectionPoint Pseudostate kind: pseudostateKind +entry 0..1 0..1 +exit (•connectionPoint •0..1 +state ConnectionPointReference •connection 0..1 •state •submachineState 7T 0..1 Joinpoint ]°3crossc U tt ingJoinpolnt^ 0..1i State ^Composite: Boolean /IsOrthogonal: Boolean /IsSimple: Boolean /IsSubmachineDeep: Boolean ^ •entry 0..1 0..1 ^ •exit 0..1 0..1 t-doActivity 0..1 0..1 FinalState •effect Behavior •deferrableTr gger Joinpoint L#J crosscuttingJoinpoints ^ Trigger •trigger of another class [2, 3], similar in function to ITDs in A O P . This is accomplished through the introduction of a "targetClass" (see Figure 5.1) field to the meta-model elements representing properties and operations. If the "targetClass" field is empty, the element is assumed to be a regular property/operation, and semantically belong to the class in which it is defined. So, unlike AspectJ , there is no special I T D element, but rather each attribute or operation can be either a regular element or an I T D , depending on the value of the "targetClass" field. Collaborations describe the application of a design pattern to a base model, by declaring the binding between classes or between methods. Each class that per-forms a role in a pattern declares its own CollaborationOccurrence, which contains a number of Dependency elements. Each Dependency element specifies the binding of either a class or an operation to one of the suppliers of roles (class or operation) in the collaboration. Collaborations also model crosscutting structure, and can be crosscutting in two ways. First , they may refer to elements in two different class diagrams. Second, they may mention elements in different classes of a class diagram. Figure 5.5 shows the Shapes class diagram from Figures 4.1 and 4.2 as it appears in U M L 2 . We include this figure in order to show the reader the kind of interface available for creating models wi th U M L 2 . Initially (in the E M F implementation that wi l l be discussed at the start of the following chapter), we used special role binding elements, which were a new construct we added to the E M F implementation of the partial U M L meta-model to represent the collaboration relationships. Role bindings declared the binding of a class to a role or of an operation to a role-operation, wi th roles modeled as ordinary classes and operations in a separate class diagram. However, wi th the introduction of collaborations in U M L 2 , this construct became redundant. 31 •t£j Resource Set H-^) :: platform :/resource/PointExample/src/ShapesSub]ectObserver.uml2 B-«S*: <Model> SubJ-Obs-design-Model ;,:: , . fcl <• <Model> ShapeCD Ei -> <Class> Shape : : 1+1 •• ^Collaboration Qccurrence> shapeBindings : : ; (B <Opr»(ation> moveBy B > <Class>Wint <Generalization> Shape • B-^ :<Collaboration.Occurrence> po.ntS1nd.ng5 <& <Dependency> Subject 4f <Property> xCoordinate <Property>.yCoordmate. . . B "S* <Opeiaton> sett P <Operabon> setY i ty-.^ <Operaton> moveBy ,...;•!: •:[=i-.^ .-.<ClaSS>:Line .;•:::> • . i :<Generalizabon> Shape . ^ s B. ^ Collaboration Occurrence > lineBindings <Property> ptl <Property> pt2 m 4- <Operabon>setPl i: :<Operabon> setP2: : : ::B"'^ :-<Operation>nioveBy : Eb 4> +class > Display til <Model> SubjObsCD <State Machine> observerStatesSM FR <> estate Machme> changeUpdateSM , ::g]..,^.:,<IntE r a ctl0n> Subject. changeSDj: . :EB^'^:'<Interaction>.Pomt.moveBya)'.--.v-.:. • .-ffl^-^-:-<Interaction> Une;moveBYSD'::-'--' .•: B-,^ "::<Interacbon>:Subject.addObserverSD: •.... Selection Parent List Tree Table • Tree with Columns Problems. Javadoc Declaration Properties £3 \ '• 1 Property [.Value Client 1 <Operation> setY, <Operation> setX J^^ entDependenCy • • \ _ • .'•: : •:•:. — .j •-. -• - :.:•:-: - x . • . • - ... ••:••_-Name _ its _ :Packageab!e: Element v i s i b i l i t y s l g P u b l i c : Supplier.::.: •.'••:•:...•:••••, ,\;.<Operat)on >. change •' Template Parameter Visibility i s- Public Figure 5.5: Example of a class diagram as shown wi th U M L 2 . 32 5.1.2 Sequence Diagrams A sequence diagram is represented by an Interaction in U M L 2 , where each inter-action consists of Lifelines and Messages, as well as EventOccurrence and Execu-tionOccurrence elements which are used to determine the ordering of messages in the sequence. Each ExecutionOccurrence specifies the lifelines that are covered by the ex-ecution, as well as the events associated with the sending and receiving of messages at the start and end of the execution. Each Lifeline also keeps track of all the Ex -ecutionOccurrences which cover it, and so all the messages that can be sent to and by the object that this lifeline represents. Sequence diagrams crosscut class diagrams in that a sequence diagram refers to operations in multiple classes in the corresponding class diagram. Figure 5.6 shows the Line.moveBy sequence diagram from Figure 4.1 as it appears in U M L 2 . 5.1.3 State Machine Diagrams A state machine is represented by a StateMachine element in U M L 2 , which is ca-pable of representing orthogonal regions, as well as composite states inside a given state machine. A state machine can be specified by a series of States and Transi-tions between them, where each transition may be triggered automatically or by a CallTrigger. State machines model class states and transitions, which crosscut the class and sequence diagrams since they refer to operations/messages on multiple classes/lifelines in the corresponding diagrams. Figure 5.7 shows what the state machine for the Phone class in Figure 4.7 looks like in U M L 2 . We use this figure to show the presence of the "crosscuttingJoin-point" field on the CallTrigger element. 33 [i/j Resource Set .-. - ',- - • .B:fi.:platform:/re50urcE o^intExampte/src/ShapesSubjectObserver.uml2 B 4> <Model> Subj-Obs-design-Model. m <rModel? ShapeCD m J> <Model> SubpbsCD tti <State Machine> observerStatesSM s <State Machine?. changellpdateSM-r+i I^nteraction? Subject.changeSD: . •{Interaction?. Point.moveBySD . . 3 <Interacbon> Line.moveBySD <Life!ine? Initiator: $ ^Lifeline? Line • .<Lifeiine>Point:' • <Lifeline> Point :!-~:^ -''<Message> Line.moveBy: ••. i + <Message> Point.moveBy •. •.•!.:>.: k-^:-:-<MeS5age>.PontmOVeBy '••:;::.:••:: • sx <Event Occurrence > sendL. mB -e 1 -> ^Execution Occurrence? create-exl <• Ki'fl'.'iil«f«'.»'ri!W!viWrf.'JB!3ra '> <Execubon Occurrence? L.mBcall-exZ .!..;-•:4^ sEventOccurrence?.receiveP.mBl-senoP.mB2-e3 >> ^Execution Occurrence? P.mBl-ex3 i-.-«5» <Event Occurrence? receiveP.mB2-e4 " • C- «.'Lxecuticn Occurrence? P.rr\32-ex4 EB - I^nteraction? Subject.add0bserverSD: Selection j Parent | List, Tree Table |;Tree with Columns Problems j Javadoc ^ Declaration J"GsJ Properties £3 'Property : Value Client Dependency • Covered Finish Exec Name Receive Message i Send Message : Start Exec To After To Before : Visibility i <Execution Occurrence? L,mBcall-ex2 <i2sendP.rrrBl-e2 I ^ : <Message ?: Line. moveBy :;^ -<Message? Point. moveBy : iXExecubon Occurrence? P.mBl-ex3 >S Public Figure 5.6: Example of a sequence diagram as shown wi th U M L 2 . 34 CO i-i CD en H X o CD & O P tr1 to , 1 Resource Set • S"®J: platfarrn:/re50Ltfce/Poait£x^ 3 «;Model>RSAPhoneModei l+J & <Modd>PnopeSystemC3 f+j <Interacbon > PlaceCaiilSD i+j <Inte<-acbon> P[aceCa!32SD El <b <Inte<,acbon^ > t/'oUserCalSD a • <State Machine >PhoneSM ^ <Ca!iTngger> inputPhoneNurnber <Cail Trigger> vaiidatePhoneNumber-:-:--:'.-4- <CaS!Tngger>nii3ateCaIi <^  <Ca!lTngcer> hangup <Ca!iTrigcer> answerCall B ^ <Region> phoneStates <Pseudostate>infta!;;; ^ <State> Inactive •*>. <State> Talfong •-ty <State> EntenngPhoneWumber%-%\\-<State>.Validating. • V: . -fy, <Siate> Processing..;.::'::.::'; .:<Transtion> entry;::: ;•• K"4*:.<Transtoon>inputP^ ^ .-.;'":; • .•§>. •:• <Transition > validatEPhoneHumber;'.;: -4- <Transit3on> processNumber ':; .ty. :<Transition> sratsateCaSI 1 : T^ransition > rnitateCai!2 . • -ty <Transition> answerCail <Transiton>hangup <State Machine> PhoneDisplaySM <&• <5tate Machino NetworkSM-" Selection Parent List free j Table Tree with Columns Problerns j Javadoc j Dedaratjon = l£1 Properties -23 J\vsah Property Value : Client Dependency Crosscutting Joinpoint: .:Name * • Operation Port •: Visibility-:-; -4" <Operation> processNumber( <Message> Phone.processNumber : £=| processNumber <Operation>processNumber-: •J^ Public 5.2 The Join Point Model (JPM) J P M s are the central mechanism that supports crosscutting in aspect-oriented pro-gramming [23]. A J P M can be described in terms of three characteristics: the nature of the join points, the means of identifying the join points, and the means of seman-tic effect at join points. Figures 5.1 — 5.4 circle in red the changes we have made to the U M L meta-model in order to support our join-point model, and a more detailed discussion of each element in the ontology follows. 5.2.1 Join Points The join points of our J P M are the selected model elements in the various U M L diagrams. Every join point is a model element, but only the elements we mention below are join points. Each join point also maintains a field, named "crosscuttingJoinpoints", which maintains the crosscut-by set — the list of all the other join points which crosscut this one. From class diagrams the join points are Class and Operation elements. From sequence diagrams the join points are Messages and Lifelines. From state machines, the join points are States and CaHTriggers. Because al l of our join points are model elements, we w i l l often refer to a join point as a model element in the following discussion. 5.2.2 Means of Identifying Join Points Our proposal includes several means of identifying join points. A l l model elements can be identified either directly by name, or by a compound signature. The name-based identification is straightforward — elements are matched on their name and also on the name of any of the roles that they perform, as specified through collaborations. For example, an operation has a basic name, which is the name of the operation model element. It also has a signature, which is a combination 36 of the target class of the operation, and the name of the operation. So, using the Shapes Edi tor example, for the setX method in the Point class, its name would be "setX", and its signature would be "Point.setX". The "targetClass" field is used to determine the class that appears in the signature of an operation. Due to the presence of ITDs , the class containing the operation declaration may be different from the class on which the operation is actually implemented. These compound signatures, which can be used to label each of the model elements, are used to match other elements which crosscut it. Equivalent signatures for two different model elements signify that they refer to the same underlying concept, and thus crosscut each other. The matching of signatures is further complicated by the presence of collaborations, and is discussed in detail in Section 6.4.1. 5.2.3 Semantic Effect at J o i n Points Our system preserves the original declaration semantics of each model element. Since we are adding a J P M to the existing U M L meta-model, where crosscutting is already present (although implicit) , our J P M does not define any new semantic effect — it simply accounts for the existing semantic effect wi th in the new framework. Each element records al l the other model elements which crosscut it. A s mentioned before, this corresponds to the planning stage of an A O P weaver — the information is recorded without any explicit modifications made to the model. Performing the actual weaving would necessitate dealing wi th the question of how the crosscutting relationships wi l l be displayed, which is beyond the scope of this work. For research that deals more explicitly wi th the issue of weaving, see [6, 7, 12]. Because our mechanism simply extends the existing meta-model and its se-mantics, it should be possible to incorporate this proposal into other meta-models, but we have not attempted this yet. This would allow for the automated analysis of crosscutting in models based on any meta-model (e.g. language/area specific model-37 Table 5.1: Crosscutting relationships that are recorded by the planner between elements in various U M L diagrams. Class Diagram Sequence Diagram State Machine Diagram Class Op Lifeline Message State CallTrigger C D Class X X Op X X SD Lifeline X Message X X S M State X CallTrigger X ing languages), as long as the appropriate elements in the meta-model were labeled as join points, and semantics established as to which elements could crosscut which other elements. 5.3 Meta-Model Enhanced With the JPM Now that we have discussed both the U M L meta-model we wi l l use, and the J P M we have designed, we can describe in more detail the crosscutting relationships between model elements that we consider. We wi l l look at each kind of diagram in turn, and for each element in the diagram that is a join point look at the other elements that can be in its crosscut-by set. This discussion is also summarized in Table 5.1. The main rule we used for establishing the crosscutting relationships to in-clude in the crosscut-by set is as follows: we make the relationship explicit, by adding the appropriate elements to each other's crosscut-by set, if it's not already explicit in the model, and moreover, only if it is a direct relationship. We provide examples of this rule throughout the discussion of each of the diagrams below. The reason behind this rule is to make sure that the crosscut-by sets do not grow too large. If al l the transitive relationships are added to these sets, they wi l l have to somehow be filtered when being displayed, as the amount of information presented directly would be too much for the modeler to take in . The main intent 38 of the crosscut-by sets was to make the direct crosscutting relationships explicit, while the transitive relationships can be established when needed by following the appropriate crosscut-by sets, instead of doing a global search. 5.3.1 Class Diagrams W i t h i n class diagrams, Operations and Classes are join points. Operations crosscut Messages in sequence diagrams, and CallTriggers in state machines. These relationships are fairly intuitive — Messages refer to a call to a specific Operation, and CallTriggers are also associated wi th a single Operation. One might say that Transitions and States, both in state machine diagrams, can also be crosscut by operations and messages. However, we return to our rule in this case: since triggers are already crosscut by operations, and triggers cause a transition, this is no longer a direct relationship. Operations that transitively crosscut a transition can be established by looking at the trigger for the transition, and so don't need to be made explicit in the crosscut-by set. Similar reasoning applies to States, as well. Classes crosscut Lifelines and CallTriggers. Lifelines in sequence diagrams represent objects of the class' type during a particular interaction sequence, and so belong in this list. Classes crosscut triggers because the execution of an operation on this class can cause the trigger to fire. Transitions and states can also be said to crosscut the class, but again, this relationship can be established transitively through the trigger. Similarly, one might consider whether Operations and Properties should be in a Class' crosscut-by set, because of possible ITDs. We argue that this relationship is already made explicit through Collaborations and Dependencies, and so falls outside the rule established above. 5.3.2 Sequence Diagrams W i t h i n sequence diagrams, Lifelines and Messages are join points. 39 Lifelines are crosscut by CallTriggers and Classes. We've already discussed the Lifeline-Class crosscutting relationship. Lifelines and CallTriggers crosscut each other because an event is triggered by a message being sent to the object represented by the lifeline. Messages can be crosscut by other Messages, as well as Operations and Trig-gers. Message-Operation crosscutting was already discussed. Messages crosscut other Messages if their compound signatures (discussed in Section 5.2.2) match. This means that Messages crosscut each other either when multiple possible flows of execution are specified in different sequence diagrams, or there are interactions for the role-operations performed by this operation that need to be accounted for. Triggers crosscut Messages in the same basic way they do Operations. 5.3.3 State Machine Diagrams W i t h i n state machines, States and CallTriggers are join points. In addition to al l the other crosscutting mentioned above, States can crosscut other States when the transitions into the states match each other. CallTriggers can crosscut other triggers, when the signatures match. This relationship is useful when establishing the crosscutting between transitions or states. 40 Chap te r 6 Implementation In order to evaluate our proposal and the ease of exposing different kinds of cross-cutting, we have implemented a simple planner tool. The implementation of the prototype evolved over the course of the project, in order to take advantage of the advances in modeling frameworks, as well as feedback from individuals familiar wi th the field. Our original implementation relied on the E M F framework, as discussed in Section 6.1. Following this, we introduce the current UML2-based implementation. 6.1 EMF Framework The original prototype implementation of our planner tool was based on the Eclipse Modeling Framework ( E M F ) version 2.0.0 [29], which allowed us to create and dis-play class diagrams. Similar to U M L 2 , the drawback of E M F is that it is not designed as a language in which you can create models, but rather as a framework for building tools based on a structured meta-model. E M F provides a partial implementation of a U M L meta-model, stored in an ecore file. This is another tree-based structure that specifies al l elements in the meta-model, and their various properties and associations. Through extensions to the E M F implementation of the partial U M L meta-model, we added support for simple sequence diagrams, role bindings, inter-type declarations, and advice, as well 41 as support for the J P M . A more detailed description of the EMF-based J P M and planner can be found in [41]. 6.2 UML2 Framework The current prototype implementation is based on the Eclipse U M L 2 framework, version 2.0.0 [30]. U M L 2 doesnt provide direct support for visually creating and editing U M L diagrams, its purpose being similar to that of E M F , but it supports all of the semantic elements that might be viewed in any U M L diagram. The meta-model is once again stored in an ecore file, and represents al l the elements and relationships laid out in the O M G ' s U M L superstructure specification document [24]. W i t h U M L 2 , simple diagrams may be created, viewed and edited only in tree form, which makes understanding the relationships between diagram elements a lot more difficult. However, the models we use for testing are small enough that they are s t i l l manageable, even in the tree format. In addition to the model in tree format, we keep as a reference a separate model in standard (graphical) U M L notation, which represents the same design. In the graphical model, we can see the relationships between elements more clearly, while the tree format contains all the exposed crosscutting relationships. Then, once the planner populates the crosscut-by sets for al l the elements in the UML2-based model, we can look at the graphical model to see whether the relationships shown by the planner exist, as well as check for any relationships the planner may have missed. U M L 2 is a great gain over E M F , where only class diagrams were supported easily, and the meta-model had to be extended in order to add support for other kinds of diagrams or role binding. W i t h U M L 2 , sequence diagrams are supported natively, and binding between model elements can be performed through the use of Collaborations. Already, this new implementation has enabled us to explore the crosscutting between two more kinds of diagrams (sequence and state machine), as 42 well as create a simple implementation of our planner. In our current UML2-based implementation (our second implementation), we decided to explore the crosscutting between different existing kinds of U M L di-agrams, instead of re-implementing support for advice. This was motivated by the desire to explore new kinds of crosscutting, as well as to differentiate our work from those that simply add aspect-specific support to U M L . In talking to members of the modeling community we often found an ini t ial misunderstanding of our approach, and so wanted to suggest a much wider applicability of our work than simply sup-porting aspects in U M L . 6.3 Model Editor This section describes the process of the editor implementation. The editor we use to create models based on our modified meta-model is designed as an Eclipse plug-in. We had to do surprisingly little work to obtain a simple editor that would fit our requirements, due to the editor generation facilities provided by U M L 2 . First of al l , we obtained the U M L 2 plug-in and installed it into our Eclipse development environment. We also checked out the code for the plug-in from the Eclipse C V S , and added it as a project to the environment. That way, we were able to launch a new workbench from within Eclipse, where any changes that we made to the code for the editor would be visible. A t the same time, since we had the plug-in installed in our environment, we could use its editing and generation tools when making changes to the meta-model. We thought reusing the existing U M L 2 editor implementation would be the most practical since the U M L 2 editor provided most of the functionality we desired (as described in Chapter 5), and since our changes to the meta-model were limited in scope, we believed that only small modifications to the editor would be necessary. The code for the plug-in came with a completely specified meta-model (in an ecore file), which we modified as described in Chapter 5. We then used the installed 43 plug-in's generation facilities to re-generate code for the editor tool from the new meta-model specification, which added the code for the entry and display of the additional model elements. The generation facilities are not complete, and required a couple of additional changes to the code in order to make the new fields show up properly in the editor. However, these were minimal, and we were already familiar wi th the process from our first (EMF-based) implementation. After this, launching the project as a separate workbench process in Eclipse allowed us to open an editor that recognized the modified model elements, as well as showed the fields for the crosscut-by sets. After this, we were able to create our test models using the editor, and after running the planner over each model were able to view the resulting crosscut-by sets. 6.4 The Planner In this section, we describe the implementation of the planner tool. Its implemen-tation is separated into a series of phases, each corresponding to a particular kind of crosscutting. The body of the new planner consists of approximately 1,000 loc in 6 main classes, as well as 4 additional uti l i ty classes. Dur ing each phase, the planner records the crosscutting join points in the crosscut-by set of the appropriate element. Before describing the phases in detail, we say a couple of things about finding matching elements in the presence of col-laborations and dependencies. To provide feedback about crosscutting structure, we took advantage of our additions to the meta-model. As mentioned before, in Section 5.2, we added a new field to al l join points, which keeps track of all the other join points which crosscut this element (the "crosscuttingJoinpoints" field). The planner adds references to the crosscutting elements to each element's crosscut-by set, and this list is then simply displayed by the U M L 2 - editor, along wi th all the other properties of the model element. 44 Currently the planner is not optimized for speed, so we require the user to explicitly trigger it when needed, rather than having it run automatically after every change to the model. If the planner were to run incrementally, we would have to take another approach. One possibility is to take note of the elements that have changed, and only consider those elements when updating the crosscut-by sets in the model. In addition, the appropriate planner passes would have to be repeated for the elements that were added, and elements that were deleted would have to be removed from the affected crosscut-by sets. This problem is similar to the problem of incremental weaving for AspectJ , and incremental model-checking [21], so we hope to be able to apply similar techniques to develop an incremental planner. 6.4.1 M a t c h i n g Before describing the planner phases, it wi l l be useful to talk about how the planner identifies matching elements. Section 5.2 mentioned briefly the distinction between pure name-based matching and matching in the presence of collaborations, and we elaborate on it here. The simplest form of element matching is purely name-based. The signatures (discussed in Section 5.2.2) of the two elements are compared, and if they are equal the elements are said to match. The other kind of matching happens in the presence of Collaborations. W i t h collaborations, classes and operations can perform the roles specified in the collab-oration. In this case, two elements match if one performs the role of the other. Using the Shapes Edi tor example, any calls to Subject.change w i l l crosscut the op-eration Point.setX, since setX performs the role of change in the context of the Subject-Observer pattern. In the current implementation, we rely only on the name of the operation and type of the object when matching signatures. We do not take into account parameter lists or return types of operations. 45 6.4.2 Phases Our planner was designed to operate in phases, as we gradually expanded the project from looking at interactions between two kinds of diagrams to three. This also gives us the added benefit of being able to take out some of the phases if we are only interested in exploring a particular kind of crosscutting relationship. Currently, there are four phases in our planner: role binding (collaborations), ITDs , sequence diagrams, and state machine diagrams, run in that order. In ad-dition, there is a set-up phase that precedes al l of these, which simply prepares the models by clearing the crosscut-by sets of all model elements, so that the re-sults from previous runs of the planner don't overlap wi th the current results. This ordering of the phases also ensures that each new phase builds on the existing struc-ture, recording crosscutting not only between elements in the diagrams it adds, but also going back and recording crosscutting between elements of the new diagram and the existing ones. The results (the crosscut-by sets) are recorded by the plan-ner in the "crosscuttingJoinpoint" field of each model element that is a join point. Figure 6.1 shows a U M L class diagram of the main classes and operations in our implementation. Role Binding (Collaborations) The role binding phase looks at al l the CollaborationOccurrences in the model, and records the associations they specify in internal tables. Specifically, it looks at each of the Dependency elements in the CollaborationOccurrence, each of which specifies a binding between classes or operations. There are two tables: one for recording bindings for classes, and another for operations. B o t h of the tables are implemented as a Hashtable that maps a role element (class or operation, in the corresponding tables) to a list of model elements (classes or operations) which perform that role in some collaboration. These ta-bles are then referred to during the following phases, when the tool checks for a 46 RoleBindingPhase operationRoleBindings: Hashtable classRoleBindings: Hashtable process Role BndingsO processCollaborationOccurrenceO addOperationRolesO addClassRolesQ Planner runO prepareModelsO roleBindingCCingPhaseO itdCrosscuttingPhaseO sdCrosscuttingPhaseO smCrosscuttingPhaseO ITDPhase introducedOpsPerClass: Hashtable introducedPropsPerClass: Hashtable processlTDsQ SequenceDiagramsPhase process SequenceOiagramsO process SequenceDiagramO StatemachinesPhase processStatemachinesO process StatemachineO interSMCrosscuttingO Figure 6.1: Class diagram for the planner implementation, including the major classes and operations. Helper /ut i l i ty classes and operations are omitted for clarity. 47 match between two elements, to see whether an element performs some role in a collaboration. Inter-Type Declarations (ITDs) The I T D phase goes through the properties and operations in al l the classes in the model. It checks the "targetClass" field (described in Chapter 5) of each of these, and if that doesn't match the parent class of the element it records the I T D association in a table. There are two tables in this phase as well, one for recording the introduced operations, and another for introduced properties. B o t h of the tables are implemented as a Hashtable which maps a class to a list of introduced operations or properties. The tables from both I T D and role binding phases are used during matching to identify al l signatures that could refer to a given model element. Sequence Diagrams This next phase goes through the sequence diagrams, and records all the crosscut-ting that takes place between elements in different sequence diagrams, and between elements in sequence diagrams and class diagrams. First , the tool goes through all the Messages for each sequence diagram, and finds and records the matching Operations in class diagrams, and matching Messages in other sequence diagrams. Then it iterates through the Lifelines, and finds the matching Classes for the objects represented by the lifelines. State Machine Diagrams The final phase goes through the state machine diagrams, and records the crosscut-ting between elements in different state machines, and also between those in state machines and class and sequence diagrams. It is necessary to go back to look at the class and sequence diagrams at this stage because the information about state 48 machine elements would not have been available during the previous stages. For each state machine, the tool first iterates through the CallTriggers, and finds the matching Operations and Messages. Then it finds other matching Cal l -Triggers by looking in al l the other state machine diagrams. For al l the CallTriggers in the state machines, the planner finds Classes and Lifelines that crosscut them (for a state which is entered after the trigger is set off, this set could be calculated as a combination of the sets of al l the triggers for its incoming transitions). Finally, this stage is completed by finding States in different state machine diagrams that crosscut each other. Two states crosscut each other if any of the incoming transi-tions for both states share any operations in their crosscut-by sets. In other words, this happens when two transitions happen on a call to the same operation, i.e. the transitions crosscut each other. 49 Chap te r 7 Evaluation To validate our contributions, we use our JPM-enhanced meta-model and planner in the implementation of a couple of simple automated analysis tools. In this chapter, we discuss two such tools, providing examples of their use as well as a discussion of their implementation. We point out a couple of the more interesting crosscutting relationships that our tools uncovered in the examples. Final ly, we present a way to add support for advice to the J P M and planner, along wi th a discussion of the differ-ences of advice in our system and in standard A O P implementations like AspectJ . We have not implemented this addition due to time constraints, but a simple version of it was implemented for our original EMF-based meta-model and planner. This, coupled wi th the fact that there are no major conceptual differences between the EMF-based and UML2-based approaches, leads us to believe that implementation of such a tool for the current framework would be fairly straightforward. We argue that analysis or display tools using our framework w i l l be easier to implement, and wi l l be able to present the modeler wi th more information about the model than R S A [13] or E M F [29] provide. Once the crosscutting relationships are made explicit by the planner, there are any number of ways in which these can be displayed to the modeler. They can also be used as input to automated analysis tools that check for consistency or completeness of the model. 50 In terms of our contributions, we would like to explicitly outline how each of these was achieved, and what benefits were obtained from accomplishing each task. We highlight some of the benefits during the discussion of each of the problems, and summarize the main points at the end of this chapter. 7.1 Recommending Transitions for State Machines When designing a system, it is often necessary to be able to say which diagrams can/need to be specified before others. Since multiple diagrams in U M L can be used to specify similar things — for example, behaviour for sequence and state machine diagrams — it is important to keep the behaviour specified by both kinds of these diagrams consistent throughout the model. The need for such an application was brought to our attention through talking to some of the people doing usability testing on R S A , whose customers had told them that it would be beneficial to see the transitions available out of a given state in a state machine, based on the interactions already specified in sequence diagrams. In general, we believe this k ind of analysis would be useful to those specifying the behaviour of a system, keeping efficiency and consistency of the model in mind. 7.1.1 Solution This first analysis tool is used to help with the creation of state machines, provided all the sequence diagrams in the model have already been specified. For a selected state, we'd like the tool to be able to make suggestions for possible outgoing transi-tions based on the sequence diagrams already specified in the model. This feature was implemented as follows: for each State that we would like recommendations for, we looked at the CallTriggers for each of the transitions coming into the state. We then looked at the crosscut-by sets of each of the CallTriggers, and picked out only those join points that were typed as Messages in a sequence diagram. Then we looked at the parent Interaction for each of those messages, m, to see what other 51 messages could occur in sequence after m in each of those sequence diagrams. Those messages are the ones whose corresponding operations could trigger a transition out of the state. This simple tool can be written with approximately 40 loc, on top of the planner implementation discussed in Chapter 6. One interesting question is whether to use the message which immediately follows m, or to look a couple of messages down the interaction sequence. One idea we have is to look at the next message to the same object (lifeline) as m, instead of the next message in sequence. It would be necessary to talk to modelers directly, or run experiments on more sample models, to find out which approach would be more useful, before choosing the final implementation. For now, we chose to use the next message in sequence. A n extension of this approach would be to look at states in other state machines which crosscut this state, and recommend messages for the outgoing tran-sitions from those states, as well. We did not explore this approach because the problem as presented to us was how to provide help in creating state machine di-agrams when some sequence diagrams were available, without knowing anything about other state machine diagrams. A small problem arises when looking at the ini t ia l message in a sequence diagram. The recommendation tool is currently not complete in that it could never recommend the first message in any sequence diagram, since it is never preceded by other messages that would be picked out from the crosscut-by set of the CallTrigger. We have one suggestion for dealing wi th this, but it would not be as precise as the other recommendations made by the tool. The basic idea is to look at the signature of a message that is first in a sequence, and determine what class the corresponding operation belongs to. Then, to check whether the class crosscuts the state we're making recommendations for — if so, then we can add the message to the list of recommended messages. 52 f i l e : / C : /TeEtp/test -workspace/PointExample/src Working wi th model: RSAPhoneModel Working' wi th SM: PhcmeSM Outgoing suggest ions f o r s ta te T a l k i n g Current t r i g g e r i s i n i t i a t e C a l l Matching me33age P h o n e D i s p l a y . d i s p l a y C a l l e r l n f o Current t r i g g e r i s i n i t i a t e C a l l Matching message P h c n e D i s p i a y . d i s p l a y C a l i e r l n f o Current t r i g g e r xa answerCall Matching message PhoneKeypad.pu3hEnd Outgoing suggest ions for s tate EnteringFhoneNumber Current t r i g g e r i s inputPhoneNumber Matching message PhoneDisplay.displayMessage Matching message Phone.processNumber Matching message PhoneDisplay.displayMessage Working wi th SM: PhoneDi3playSM Outgoing suggest ions for s tate d i s p l a y i n g C a l l e r l n f o Current t r i g g e r i s d i s p l a y C a l l e r l n f o Matching message PhoneSpeaker.ring Done. Figure 7.1: Snippet of the output of the transition recommendation tool for state machines, as run on the R S A model example. 7.1.2 Wha t We Found in Examples In this section, we show the results of running the tool on the R S A example model. Figure 7.1 shows part of the output of the tool. Only the signatures of recommended messages are shown, but the tool gets a reference to the message itself. This would be useful if the analysis tool were extended wi th a graphical interface, and then the tool would be able to show direct links to the recommended messages, or even create the recommended transitions automatically. For the state EnteringPhoneNumber, in the P h o n e S M (state machine), the sequence diagrams recommend that transitions out of the state could happen on calls to PhoneDisplay.display and Phone.processNumber. The second transition already appears in the PhoneSM, which is a good check to make sure that the sequence diagram and state machine are in agreement. If the state machine hadn't been 53 complete, we would know that at least one of the recommendations made by the tool was the one that was chosen by the designers. For the state Talking, also in the PhoneSM state machine diagram, PhoneDis-play. display Caller Info can cause a transition out of the state, since the user may want to know who they're talking to. Also, PhoneKeypad.pushEnd can cause a transi-tion, which makes sense since a conversation needs to be ended after it 's started, and the caller can do this by pushing the "end call" button on their phone. 7.1.3 Benefit The J P M and planner have simplified the implementation of this analysis tool by exposing the crosscutting relationships we are interested in, and collecting them in an easily-accessible list. We anticipate benefits from such an analysis tool itself, but those are outside the actual scope of this project. For example, the design of state machines wi l l be easier and less error-prone if there is already information available about transitions possible out of each state when they are being created. O n the basis of this, it wi l l also be easier to check for consistency between state and sequence diagrams. In fact, this analysis tool is already a step towards that - transitions based on information from sequence diagrams are recommended, but their use is not enforced. 7.2 Composing Sequence Diagrams Another challenge when working wi th behaviour in design models comes from using design patterns. Ideally, the design pattern and its behaviour are specified separately from the base design, or even a design pattern model supplied by someone else is reused. The design pattern is "applied" to the base design through the use of collaborations, which mark operations in the base design as performing roles (of classes or operations) in the pattern model. The challenge comes when trying to understand the composed behaviour of the system. A number of papers have 54 addressed this issue already [17, 35], and we discuss here how our approach can also be used to deal wi th this situation. In a more general sense, there are other cases when you want to compose multiple sequence diagrams, and see the resulting behaviour. One such instance is when there are multiple possible flows of execution for the same operation, and you want to see al l the flows that the call to this operation can invoke. This k ind of analysis tool would be useful to anybody wanting to verify the behaviour of a system, and whether it behaves as expected in the presence of roles. In the case of collaborations, this would probably be the person adding the pattern implementation to the base design. Also, the second scenario might be interesting to anybody trying to find out, for example, how to implement a particular operation — they would need to see al l the possible executions in order to understand exactly what the operation is responsible for. 7.2.1 Solution This second kind of analysis tool can help a modeler wi th overall understanding of the behaviour of a system, where different parts of the behaviour are specified in different sequence diagrams. We propose an analysis tool that wi l l compose two crosscutting sequence diagrams, and display the resulting sequence diagram. There are two major cases where we think this kind of analysis would be useful. The simplest case is when there are multiple sequence diagrams that share some calls, and we would like to see a composed sequence diagram. For example, in the Shapes Edi tor Example (Section 4.1), Figure 4.1 shows two sequence diagrams, both of which include a call to Point.moveBy. Wha t would the complete execution look like if Line.moveBy was called? Another variant of this case is where the sequence diagrams specify different alternative executions. In this case, it would st i l l be useful to see the composed diagram, where all possible flows of execution would be indicated. 55 The other case deals wi th behaviour in the presence of collaborations, where a role performed by a class or operation can introduce new behaviour. In particular, we are interested in operations that have their execution specified by a sequence diagram, and are also covered by a collaboration, wi th a separate sequence diagram specifying behaviour for the role-operation. In this case, it would be beneficial to see the composed sequence diagram which includes both of these behaviours, in order to detect any unexpected interactions that the collaboration may introduce. Sequence diagram composition for both of these approaches can be accom-plished by finding al l messages in the sequence diagram of interest that are crosscut by any message, m, in some other sequence diagram, and inserting the sequence of messages following m into the original sequence. For the first case, we are only interested in looking at crosscutting messages that have the same signature as the message of interest. For the second case, we are interested in looking at crosscutting messages wi th a different signature, which wi l l be the messages for the role-operation the corresponding operation may perform. Since roles are taken into account when creating the crosscut-by sets, role-messages wi l l be present in the crosscut-by set of the message of interest. This tool can be written wi th approximately 50 loc, on top of the planner implementation. 7.2.2 W h a t W e F o u n d in Examples In this section, we show the results of running the analysis tool on the Graphical Editor Example model. We present two examples which correspond to the two cases we introduced in Section 7.2.1. Figure 7.2 shows output from running the tool on the first example, where we are interested in seeing the full execution flow of the Line.moveBy sequence, without looking at roles. Figure 7.3 shows output from running the second example, where we want to see how the Point .moveBy sequence is affected in the presence of the change role 56 Working with model: Subj-Obs-design-Model Line.moveBy : from Line.moveBySD Point.moveBy : from Line.moveSySD Point.setX : front Point.moveBySD Point.setY : from Point.moveBySD Point .moveBy : from Line . moveBySD Point.setX : from Point.moveBySD Point.setY : from Point.moveBySD Point.moveBy : from Line.moveBySD Done. Figure 7.2: Output of the sequence composition tool on the Line.moveBy sequence from Figure 4.1, wi th role bindings not included. Working with model: Subj-Obs-design-Model Point.moveBy : from Point .moveBySD Observer.update : from Subject.changeSD Point.setX : from Point.moveBySD Observer.update : from Subject.changeSD Point.3etY : from Point.moveBySD Observer.update : from Subject.changeSD Done. Figure 7.3: Output of the sequence composition tool on the Point .moveBy sequence from Figure 4.1, including role bindings. on the moveBy, setX, and setY operations of Point. In particular, we can see that multiple calls would happen to Display, up date if all of these operations perform the change role. This is obviously undesirable — in fact, we would like an update to happen only once for each sequence that involves one or more changes. In this case, the tool did a good job of pointing out a possible problem wi th the design, which can be fixed during implementation by using A O P techniques [18]. 7.2.3 Benefit We believe this k ind of analysis should help verify composed system behaviour in the presence of design patterns or advice (discussed in Section 7.3). For example, 57 with respect to design patterns implemented as collaborations, this could be used to check whether the role behaviour applies in al l the places where you would expect it to apply, or whether some operations were missed when dependencies were being specified. Implementers could also use this approach to figure out exactly where the control flow could go from a given operation, and know exactly which functionality the operation is responsible for. This could also help them catch any discrepancies between design and specifications/headers for operations given to them. 7.3 Advice This section looks at adding support for new crosscutting elements, both to the meta-model and planner. We consider advice (from A O P ) as another k ind of modeling element, which can crosscut other (existing) model elements. In particular, advice can be crosscutting in that it may apply to multiple elements in different diagrams in the model. For an introduction to advice and other A O P concepts, please see Chapter 3. This discussion is more abstract than the previous two, since we have not actually implemented this problem in our UML2-based meta-model and planner. However, we did have support for this in the original EMF-based version, and were able to implement a couple of simple analysis tools on the basis of it [41]. In addition to describing how support for advice can be added to our meta-model and planner, we consider how the advice elements we propose are different from the concept of advice in A O P languages such as AspectJ . In particular, we noticed that advice in AspectJ can only be applied to methods and calls, whereas wi th our meta-model and J P M advice can be applied to any element in the model that is identified as a join point within the J P M . Of course, this also involves coming up with a more general definition for what it means for an element to be advised. The first part of this discussion should be of particular interest to those inter-58 Display * » Shape refreshO moveByfint, int) 1 Point ,2 Line getxo getvo setX(int) setY(int) moveByflnt, int) getPIO getP20 setP1 (Point) setP2(Point) moveBy(int, int) Advice after operation(Shape+.moveByO) I operation(Shape+.set*0): "should be change" Figure 7.4: Graphical Shapes Editor example class diagram, wi th an example of advice. ested in t rying out modeling of new paradigms, not just specifically A O P . Because if we can show that support for any kind of element can be added to the meta-model and the planner, people may be more wil l ing to try to import new paradigms from programming to modeling. The second part of this discussion w i l l be more appealing to those interested in exploring the nature of advice in aspect-oriented systems. 7.3.1 Solution As mentioned before, three changes need to be made: to the meta-model, the J P M , and the planner. Firs t , we add the new advice [18] element to the meta-model, which makes it possible to advise other model elements. Advice in this context simply means that there is some sort of a note attached to the advised element, and it contains the body of the advice. A n example advice is shown on the right-hand side in Figure 7.4. The syntax used in the figure serves only to illustrate the meaning, and is not a concrete proposal for advice syntax. Advice can be crosscutting in that it may apply to multiple elements in different diagrams in the model. Advice can be of three different kinds — before, after, and around. For example, the moveBy and setter methods of Point and Line can be advised wi th after-advice that makes calls to Display.update. A more 59 thorough discussion of this example can be found in [41]. • In addition to advice elements, we also need to add support for pointcut elements, which specify where the advice can apply. There are many different kinds of pointcuts already present in A O P systems, and some would have to be added in order to pick out each of the model elements identified as a join point. But for the purpose of this example, we are only interested in the operation pointcut (methods are called operations in U M L diagrams). The operation pointcut is pretty straightforward — it picks out operations which match the signature specified in the pointcut. We use AspectJ-like syntax in the pointcut expressions. The symbol "+" refers to subclasses, and "*" is used as a wildcard. So, for example, the first pointcut specifies al l moveBy operations in subclasses of Shape, while the second refers to all operations in subclasses of Shape whose name starts wi th "set". Pointcuts that can be used to include/exclude messages in certain cases (like enow) provide much more finer-grained control over where advice can apply than can be accomplished with collaborations. Second, we update the J P M — the definition of join points needs to be expanded to include the new elements, although the means of identifying join points and the semantic effect should remain the same. T h i r d , we need to modify the planner. This wi l l involve either adding a new phase, if we're dealing wi th a completely new kind of crosscutting, or modifying an existing phase, if we're adding an element in a diagram for which we already provide some support. In general, the addition of a new kind of crosscutting model element requires a new phase of processing if the element is not subsumed by any of the phases described in Chapter 6. In addition, the position of the new phase in the ordering has to be determined. None of the other existing phases should need to be modified to accommodate this change. In this case, we wi l l need to add a new phase to handle the processing of advice, since it's a completely different kind of crosscutting. 60 The presence of advice in our modeling language, in addition to collabora-tions and inter-type declarations (ITDs), leads to an interesting semantic question. We would like ITDs and advice to be able to depend on role bindings when appro-priate. Specifically, we would like an I T D onto a role element to have the same effect on classes performing the role as members defined directly in the role. Similarly, we would like pointcuts to be able to depend on collaborations and ITDs . This semantics is easy to achieve wi th a simple linear processing of model elements in which collaborations are handled before ITDs , which are handled before advice. This would mean that the advice phase would run after al l the existing phases. Bu t if we also wanted role bindings to be able to depend on ITDs , then we would have to adopt some sort of a fixed-point approach in our planner. So far, we have been unable to come up with a sufficiently compelling example that would require the more complex semantics. 7.3.2 Benefit The addition of support for a new kind of crosscutting element to the meta-model and planner has a number of benefits. First , most directly, it w i l l benefit those trying to do aspect-oriented modeling in U M L . A O P is in increasing demand right now, and there is a need for support for the process throughout its lifecycle. There are a number of approaches, discussed in Chapter 2, that advocate either the support for A O elements in modeling, or support for A O development, from design through to implement ation. A second, more indirect benefit of making these changes is to show that support for any new kind of crosscutting element can be added to the meta-model, as well as the planner. Since the treatment of all the crosscutting elements is generic, we can see that the implementation of the planner doesn't rely on the kind of element being added, only on the crosscutting relationships it has wi th other model elements. This can be done for other diagrams in U M L , or domain-specific models for certain 61 applications. This also supports our decision to separate the planner into phases, as the addition of support for new crosscutting elements makes the least possible impact on existing phases. Because we layer a join point model, which is an aspect-oriented concept, on top of the U M L meta-model, instead of simply adding direct support for AspectJ elements to the meta-model, the advice described in Section 7.3.1 differs from the advice usually discussed in the context of AspectJ . In particular, in AspectJ advice applies to points in the execution of the program. W i t h modeling, we have much more freedom than that, and the semantics of the advice we introduce is different, in that advice can apply to any model element which can be identified in our system, i.e. any model element that is a join point. 7.4 Discussion of Contributions In this section, we look at each of the contributions we claimed in Chapter 1, and justify them wi th respect to the examples we've discussed above. 7.4.1 Show that a J P M - E n h a n c e d Meta -Mode l C a n Support Cross-cutting Structure in a U M L M o d e l Our planner makes the existing crosscutting structure explicit in the model, relying on the additions we have made to the meta-model, as discussed in Chapter 5. In particular, we make use of the "crosscuttingJoinpoints" field of a Joinpoint to record the crosscut-by set for each element. Our framework also enables the addition of new kinds of crosscutting struc-ture (model elements) wi th less work than would be required wi th established mod-eling tools like R S A . Section 7.3 addresses this exact issue, where we discuss how support for advice and pointcuts can be added. We believe that we could add sup-port for these elements to our meta-model and planner wi th a couple of weeks worth of work, while there is s t i l l no support in R S A for advice, regardless of the increasing 62 interest in aspect-oriented implementation and design. From making the changes to the meta-model, as well as the implementation of the planner, we saw that crosscut-by sets are a good way of supporting and exposing crosscutting structure. The implementation was straightforward, as is access to the elements in the set after the planner has made its passes. A l l the different kinds of crosscutting elements are treated the same, which allows analysis tools to be more generic in their implementation. 7.4.2 Traversing the M o d e l to Collect Crosscutting is Straightfor-ward Once the J P M was added to the meta-model, the planner tool implementation was fairly straightforward, as discussed in Chapter 6. The staged implementation allowed us to concern ourselves only with specific diagrams during each of the passes. A l l model elements of interest have signatures which can be compared in order to determine whether elements match or not, and we have devised matching rules that are applied in the case of roles from collaborations, which complicate the matching process. 7.4.3 The Above Help Model ing Tools to Access, Analyze, and Display Crosscutting Relationships of Interest Sections 7.1 and 7.2 discussed simple automatic tools we have implemented that help wi th analysis of existing crosscutting structure. Section 7.3 dealt wi th the issue of adding support for new crosscutting elements, to the meta-model, J P M , and planner. There is less we can say about the display of crosscutting relationships, at least in terms of graphical display. This ended up not being the main focus of the project, so we did not explore the issues involved in creating a graphical display. Deciding how each kind of crosscutting relationship wi l l be represented graphically 63 is another big issue, and we thought it may be too general of a question to address in our work. 7.4.4 P l a n n e r T o o l The planner we implemented as part of this thesis was a good proof-of-concept tool to show that using a J P M can help support modeling, wi th respect to imple-mentation of both a planner and analysis tools. Bo th versions of the planner were straightforward to implement, and allowed us to more thoroughly explore the J P M , in particular how it helps simplify the development of different automated analysis tools. 7.5 Feedback and Future Work We have had a number of opportunities to present this work to other researchers and members of industry, and have had some useful feedback, as well as a number of ideas for the directions we could take the project. In particular, the problem discussed in Section 7.1, on the use of messages in sequence diagrams to recommend possible transitions in state machines, is a direct result of feedback from Susan Mclntyre , who quoted some of her customers as saying that when creating state machine diagrams, help from the tool would be desirable, especially if behaviour already specified in sequence diagrams could be used to help wi th this. After implementing the first stages of the planner for class and sequence diagrams, we were curious as to what other kinds of diagrams are considered the most interesting (and used most frequently) by modelers. State machine and col-laboration diagrams were among those recommended to us, in particular by Bran Selic, who has a long history wi th real-time modeling. Another question that was raised is whether there is a distinction between design-time crosscutting (what we are dealing wi th here) and run-time crosscutting (addressed by A O P approaches). Advice, discussed in Section 7.3 can be used as an example of this, since just where 64 advice can apply, and what it means, is different in AspectJ and our framework. Maged Elaasar, a P h D student also working at I B M , brought to our attention the idea that since our approach is so general, the J P M concept could also be applied to other meta-models, for example domain-specific languages or meta-models. A planner tool similar to ours could then be implemented for the new domain, wi th the same kinds of benefits. Finally, it was discussions wi th other researchers that convinced us to switch from E M F to U M L 2 as the basis for our implementation, in particular B r a n Selic and K e n Hussey, the main developer behind U M L 2 . 65 Chap te r 8 Conclusion We propose bottom-up support for crosscutting structure in U M L by adding a simple J P M to the U M L meta-model. This modified meta-model simplifies implementation of tool support for exposing and analyzing crosscutting structure, as well as addition of new kinds of crosscutting structure. It also makes models of crosscutting structure more declarative. Using our meta-model, adding new I T D constructs was a fairly straightfor-ward exercise. A l l the existing U M L model elements, as well as the I T D constructs, were integrated smoothly into the J P M . The planner we implemented was able to ef-fectively expose the crosscutting between model elements in various diagrams. This makes us optimistic that we w i l l be able to support other kinds of crosscutting model structure, such as advice, for which the proposed steps were discussed in Chapter 7. Through design of the J P M , as well as the planner, we have also gained a better understanding of the crosscutting relationships that are possible between different model elements, which we summarised in a table in Chapter 5. In terms of implementation, we present a self-contained JPM-enhanced U M L meta-model, and an easily extensible planner tool. Bui ld ing on that foundation we present simple automated model analysis tools, which can provide further task-specific helpful information to the modeler. These tools rely on the output from 66 the planner to perform their analysis. These tools would be most useful for analysis that relies on information from multiple models, or multiple diagrams within a single model. We propose an advice semantics in which any kind of join point can be advised, including not just method calls, but also transitions, classes, states, and others, as discussed in Section 7.3. We would like to see the existing J P M and planner expanded by adding support for other U M L diagrams, as well as providing support for the elements of existing diagrams that we excluded during our ini t ial implementation. We would also like to see the analysis tool suite extended wi th tools similar to the two we've already implemented. Following one of the suggestions we discussed in Section 7.5, it would also be interesting to apply the approach we presented to a different meta-model, by following the steps for designing a J P M and implementing a planner, which we described in this thesis. We believe that adding a J P M to a meta-model is promising both in terms of support for existing kinds of crosscutting, as well as addition of support for new kinds of crosscutting, like aspects and advice. Our proof-of-concept implementation demonstrates this. We have also presented ideas for future work, as well as possible automated tools that would take advantage of the crosscutting structure exposed by the planner. 67 Bibliography [1] E . P . Andersen and T . Reenskaug. System design by composing structures of interacting objects. In Proceedings of ECOOP, pages 133-152, London, U K , 1992. Springer-Verlag. [2] AspectJTeam. The aspectj programming guide, http://eclipse.org/aspectj/ , 2005. [3] H . Cannon. Flavors: A non-hierarchical approach to object-oriented program-ming. Technical report, Symbolics Inc., 1982. [4] C. Chavez and C . Lucena. A metamodel for aspect-oriented modeling. In Workshop on Aspect-Oriented Modeling with UML at AOSD2002, Enschede, The Netherlands, A p r i l 2002. [5] S. Clarke, W . Harrison, H . Ossher, and P. Tarr. Subject-oriented design: To-wards improved alignment of requirements, design and code. In Proceedings of the conference on Object-Oriented Programming: Systems, Languages, and Applications, pages 325-339. A C M Press, November 1999. [6] S. Clarke and R . J . Walker. Composition patterns: an approach to designing reusable aspects. In Proceedings of the 23rd International Conference on Soft-ware Engineering, pages 5-14, Toronto, Ontario, Canada, 2001. [7] G . Georg, R . France, and I. Ray. Composing aspect models. In The 4th AOSD Modeling with UML Workshop, October 2003. 68 [8] Y . Han, G . Kniesel, and A . Cremers. Towards visual aspectj by a meta model and modeling notation. In 6th International Workshop on Aspect-Oriented Modeling, 2005. [9] J . Hannemann and G . Kiczales. Design pattern implementation in Java and aspectj. In Proceedings of OOPSLA '02, ACM SIGPLAN Notices, 2002. [10] S. Herrmann. Composable designs with ufa. In Aspect-Oriented Modeling with UML workshop at the 1st International Conference on Aspect-Oriented Software Development, Enschede, The Netherlands, A p r i l 2002. [11] E . Hilsdale and J . Hugunin. Advice weaving in aspectj. In International Con-ference on Aspect-Oriented Software Development (AOSD), pages 26-35. A C M Press, 2004. [12] W . - M . Ho, J . - M . Jezequel, F . Pennaneac'h, and N . Plouzeau. A toolkit for weaving aspect oriented uml designs. In Proceedings of the 1st international conference on Aspect-oriented software development, pages 99-105, Enschede, The Netherlands, 2002. A C M Press. [13] I B M . Rat ional software architect (rsa). h t tp : / /www-128.ibm.com/developerworks/rational/products/rsa/, 2005. [14] I. Jacobson and P . -W. N g . Aspect-Oriented Software Development with Use Cases. Addison Wesley Professional, 2004. [15] J . Jezequel, N . Plouzeau, T . Weis, and K . Geihs. From contracts to aspects in uml designs. In A sped-Oriented Modeling with UML workshop at AOSD, 2002. [16] M . M . Kande, J . Kienzle, and A . Stohmeier. From aop to uml - a bottom-up approach. In Aspect-Oriented Modeling with UML workshop at the 1st Inter-national Conference on Aspect-Oriented Development, 2002. 69 [17] M . Ka ta r a and T . Mikkonen. Refinements and aspects in uml . In Aspect-Oriented Modeling with UML Workshop at UML Conference, 2002. [18] G . Kiczales, E . Hilsdale, J . Hugunin, M . Kersten, J . Pa lm, and W . G . Gris-wold. A n overview of aspectj. In European Conference on Object-Oriented Programming (ECOOP), pages 327-355, Budapest, Hungary, 2001. Springer. [19] G . Kiczales and M . Mezin i . Aspect-oriented programming and modular reason-ing. In ACM International Conference on Software Engineering, M a y 15-21, 2005. [20] D . - K . K i m , R . France, S. Ghosh, and E . Song. A role-based metamodeling approach to specifying design patterns. In Proceedings of COMPSAC, pages 452-457, 2003. [21] S. Krishnamurthi , K . Fisler, and M . Greenberg. Verifying aspect advice modu-larly. In ACM SIGSOFT International Symposium on Foundations of Software Engineering, pages 137-146, 2004. [22] J . M . Lions, D . Simoneau, G . Pitette, and I. Moussa. Extending opentool/uml using metamodeling: A n aspect oriented programming case study. In Workshop on Aspect-Oriented Modeling with UML at the UML Conference, 2002. [23] H . Masuhara and G . Kiczales. Modeling crosscutting in aspect-oriented mech-anisms. In European Conference on Object-Oriented Programming (ECOOP), pages 2-28. Springer, 2003. [24] O M G . Unified modeling language (uml), version 1.5. ht tp: / /www.uml.org, 2004. [25] H . Ossher and P. Tarr. Hyper / j : Multi-dimensional separation of concerns for java. In International Conference on Software Engineering, pages 734-737. A C M Press, 2000. 70 [26] R . Pawlak, L . Duchien, G . Flor in , F . Legond-Aubry, L . Seinturier, and L . Mar te l l i . A uml notation for aspect-oriented software design. In Aspect-Oriented modeling with UML workshop at AOSD, Enschede, The Netherlands, 2002. [27] I. Phi l ippow, M . Riebisch, and K . Boellert. The hyper /uml approach for feature based software design. In The 4th AOSD Modeling with UML Workshop, San Francisco, C A , 2003. [28] C . Prehofer. Feature interactions in statechart diagrams or graphical compo-sition of components. In Workshop on A sped-Oriented Modeling with UML at the UML Conference, 2002. [29] Eclipse Project. Eclipse modeling framework (emf). http://www.eclipse.org/emf/, 2005. [30] Eclipse Project. U m l 2.0 metamodel implementation (uml2). ht tp: / /www.eclipse.org/uml2/ , 2005. [31] Eclipse Project. Graphical editing framework (gef). http://www.eclipse.org/gef/, 2006. [32] D . Reifer. Doubts and hopes for aop. In Communications of the ACM, volume 45-3, pages 11-12, 2002. [33] B . Selic. Using uml for modeling complex real-time systems. In Languages, Compilers, and Tools for Embedded Systems: ACM SIGPLAN Workshop LCTES, Montreal , Canada, 1998. [34] Spring. Spring framework, http://www.springframework.org/docs/reference/aop.html, 2005. 71 [35] D . Stein, S. Hanenberg, and R. Unland. Designing aspect-oriented crosscut-ting in uml . In Workshop on A sped-Oriented Modeling with UML at AOSD, Enschede, The Netherlands, 2002. [36] D . Stein, S. Hanenberg, and R. Unland. Position paper on aspect-oriented modeling: Issues on representing crosscutting features. In Workshop on Aspect-Oriented Modeling at AOSD, 2003. [37] G . Straw, G . George, E . Song, S. Ghosh, R . B . France, and J . M . Bieman. Mode l composition directives. In Conference on the Unified Modeling Language, Lis-bon, Portugal, 2004. [38] J . Suzuki and Y . Yamamoto. Extending uml wi th aspects: Aspect support in the design phase. In ECOOP Workshop on AOP, 1999. [39] T . Tamai , N . Ubayashi, and R . Ichiyama. A n adaptive object model wi th dy-namic role binding. In Proceedings of the International Conference on Software Engineering (ICSE '05), St. Louis, M O , 2005. [40] P. Tarr, H . Ossher, W . Harrison, and S . M . Sutton. N degrees of separation: multi-dimensional separation of concerns. In International Conference on Soft-ware Engineering (ICSE), pages 107-119. I E E E Computer Society Press, 1999. [41] M . Tkatchenko and G . Kiczales. Uniform support for modeling crosscutting structure. In The Eighth International Conference on The Unified Modeling Language, UML 2005, pages 508-522, Montego Bay, Jamaica, October 2005. Springer. 72 


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items