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

Download

Media
831-ubc_2006-0325.pdf [ 3.65MB ]
Metadata
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
831-1.0051588-fulltext.txt
Citation
831-1.0051588.ris

Full Text

Uniform Support for Modeling Crosscutting Struct by M a r i a A . Tkatchenko B . S c , University of B r i t i s h Columbia, 2004  A THESIS 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 THE REQUIREMENTS  FOR T H EDEGREE OF  M a s t e r of Science in T H E F A C U L T Y OF G R A D U A T E STUDIES (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 i n U M L by adding a simple join point model to the meta-model. T h i s supports built-in crosscutting 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 crosscutting structure, which can then be displayed or analyzed i n 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 .  ii  Contents Abstract  ii  Contents  iii  List of Tables  vi  List of Figures  vii  Acknowledgements  x  1  Introduction  1  2  Related W o r k  5  2.1  2.2  A d d i n g Support for A O P to U M L  5  2.1.1  Standard Extension Mechanisms  5  2.1.2  M e t a - M o d e l Changes  7  Composing Diagrams  9  3  Aspect-Oriented Programming  13  4  Introducing Examples  16  4.1  G r a p h i c a l Shapes E d i t o r Example  4.2  R S A Phone M o d e l Example  .  16 18  iii  5  M e t a - M o d e l Description 5.1  5.2  5.3  6  7  25  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  The J o i n Point M o d e l ( J P M )  36  5.2.1  J o i n Points  36  5.2.2  Means of Identifying J o i n Points  36  5.2.3  Semantic Effect at J o i n Points  37  M e t a - M o d e l 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  Implementation  41  6.1  E M F Framework  41  6.2  U M L 2 Framework  42  6.3  Model Editor  43  6.4  The Planner  44  6.4.1  Matching  45  6.4.2  Phases  46  Evaluation 7.1  7.2  50  Recommending Transitions for State Machines  51  7.1.1  Solution  51  7.1.2  W h a t W e Found i n Examples  53  7.1.3  Benefit  •  54  Composing Sequence Diagrams  54  7.2.1  55  Solution  iv  7.3  7.4  7.2.2  W h a t W e Found i n Examples  56  7.2.3  Benefit  57  Advice 7.3.1  Solution  59  7.3.2  Benefit  61  Discussion of Contributions 7.4.1  8  62  Show that a J P M - E n h a n c e d M e t a - M o d e l C a n Support Crosscutting Structure i n a U M L M o d e l  62  7.4.2  Traversing the M o d e l to Collect Crosscutting is Straightforward  63  7.4.3  The Above Help Modeling Tools to Access, A n a l y z e , and Display Crosscutting Relationships of Interest  63  Planner Tool  64  Feedback and Future W o r k  64  7.4.4 7.5  58  Conclusion  66  Bibliography  68  v  List of Tables Crosscutting relationships that are recorded by the planner between elements i n various U M L diagrams  vi  38  List of Figures 4.1  Class and sequence diagrams for the Graphical Shapes E d i t o r example. 17  4.2  Class and sequence diagrams for the Subject-Observer design pattern.  4.3  Sequence diagram for one user placing a call i n the R S A model example. 19  4.4  State machine diagrams for the Network and Phone classes i n the R S A example. S M stands for State Machine  4.5  17  20  Sequence diagram for the two-user call i n the R S A example. T h e diagram is split between this figure and Figure 4.6, w i t h the common link being the WirelessNetwork lifeline.  T h e circled numbers  "1" and "2" represent the places where the two diagram fragments link together. T h e messages following "1" i n 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 i n Figure 4.6 are inserted after W i r e lessNetwork.endCall i n the current  vii  figure  21  4.6  Sequence diagram for the two-user call i n the R S A example.  The  diagram is split between this figure and Figure 4.5, w i t h the common link being the WirelessNetwork lifeline.  T h e circled numbers "1"  and "2" represent the places where the two diagram fragments link together. T h e messages following "1" in this figure are inserted after the "1" (WirelessNetwork.initiateCall) i n Figure 4.5. Same for the circled "2": messages starting at PhoneDisplay.displayCalllnfo i n 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 superstructure document  5.2  27  Sequence diagram meta-model: lifelines and interactions. Figure 5.3 contains the other half of this meta-model.  F r o m the U M L super-  structure document 5.3  28  Sequence diagram meta-model: messages and interactions.  Figure  5.2 contains the other half of this meta-model. F r o m the U M L superstructure document 5.4  29  State machine diagram meta-model, from the U M L superstructure document  1  . .  30  5.5  E x a m p l e of a class diagram as shown w i t h U M L 2  32  5.6  E x a m p l e of a sequence diagram as shown w i t h U M L 2  34  5.7  E x a m p l e of a state machine diagram as shown w i t h U M L 2  35  6.1  Class diagram for the planner implementation, including the major classes and operations. H e l p e r / u t i l i t y classes and operations are omitted for clarity  7.1  47  Snippet of the output of the transition recommendation tool for state machines, as run on the R S A model example  viii  53  7.2  O u t p u t of the sequence composition tool on the Line.moveBy sequence from Figure 4.1, w i t h role bindings not included  7.3  O u t p u t of the sequence composition tool on the Point.moveBy sequence from Figure 4.1, including role bindings  7.4  57  57  G r a p h i c a l Shapes E d i t o r example class diagram, w i t h 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 w i t h me on this, b o t h when brainstorming ideas and w r i t i n g the submission for the conference. T h a n k s 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 w i t h your students' code despite all of your other responsibilities! T h a n k s to E r i c Wohlstadter, who generously agreed to be m y second reader when I came to h i m i n a panic after realizing that I needed one. I should also thank b o t h the employees and fellow C A S students at the I B M Ottawa P a l l a d i u m lab, who are too numerous to name here, and who shared w i t h me their feedback and ideas, which helped shape this project. Y o u made my time in Ottawa one of m y best summers away from Vancouver. Finally, thanks to m y parents, for always being there for me and encouraging me to go on and look for bigger and better things, both i n life and education. Thanks to all of my friends, and D a n , for your endless patience and your tireless attempts at distraction when I got too bogged down i n work. I'm glad you're all a constant presence i n my life. T h a n k s for all the fun times we had, and new sports you have introduced me to. M y time spent w i t h all of you has definitely been a rewarding experience i n its own right!  MARIA A . TKATCHENKO  The University of British Columbia April 2006  Chapter 1  Introduction T h e Unified M o d e l i n g 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 i n both diagrams, w i t h each diagram only partially specifying the element.  For example,  a sequence diagram can crosscut a class diagram, i n 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 w i t h new crosscutting modeling constructs such as aspects, advice, inter-type declarations (ITDs) and role bindings [1, 16, 20, 26, 32, 35, 39]. M o d e l i n g i n 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 frameworks 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 still has a number of strong drawbacks, i n particular the misalignment between the feature-oriented requirements and object-oriented design and code, as discussed by Clarke et. al. i n [5].  1  Aspect-oriented programming (AOP) is an area that focused initially on support 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 modeling, 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 pattern 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 A s p e c t J , this involves ensuring that advice runs when it should and inserting inter-type declarations at their target locations. T h i s is done i n 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 i n 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 w i t h each model element a set of all the other model elements w i t h 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 i n 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 — i n particular large, industrial-sized U M L models — are often difficult to work with, at least i n part due to the lack of information i n one diagram on the behaviour or structure defined i n another. W h a t we would like to see are tools that help the modeler see the big picture, and the place of specific elements w i t h i n it. T h i s 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 notation for showing crosscutting relationships; the crosscutting relationships exposed by our planner can be displayed i n any number of ways, and examining which is better is left to future work. T h e 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 straightforward, and (iii) the combination of (i) and (ii) makes it easy for modeling tool implementers to create tools that access, analyze and display crosscutting relationships 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  Chapter 2  Related W o r k There are two streams of research related specifically to our work. T h e first looks at explicitly adding aspects or A O P concepts to U M L , either by using the extension mechanisms provided i n 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 w i t h some forms of crosscutting.  2.1 2.1.1  Adding Support for AOP to U M L Standard Extension Mechanisms  T h e 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. T h e work deals w i t h both structural crosscutting i n the form of introductions, and behavioural crosscutting i n the form of advice. T h e behavioural crosscutting case is closest to our work, so we w i l l focus on it i n our discussion. T h e base (crosscut) and advice (crosscutting) behaviours,  5  specified by sequence diagrams, can be merged to display the final expected behavior. T h i s involves splitting apart the base sequences at the join points, and later composing the sequence w i t h the crosscutting behaviour included at each of the join points affected. T h e set of calls in a sequence may need to be totally ordered for weaving to guarantee preservation of behaviour, which is computationally expensive. T h e 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 i n an aspectoriented context.  Pointcut relations define crosscuts w i t h i n the program, linking  aspect-methods to points i n 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. T h e authors use built-in extension mechanisms i n U M L , namely stereotypes, tag values, and design pattern occurrences, to add non-functional information or crosscutting behavior to base model elements. T h i s 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 organized around the notions of quality of service contracts and aspects [15]. Contracts are modeled i n U M L using a small set of stereotypes, and specify non-functional  6  properties. Aspects are represented using parameterized collaborations and transformation rules, and specify how contracts can be implemented. Unlike the above work, the authors here take the approach that i n 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 Y a m a m o t o add new elements for the aspect and woven class using stereotypes, and reuse an existing element for the aspect-class relationship [38]. A n aspect is shown as a class w i t h an "aspect" stereotype, and may contain operations w i t h the stereotype "weave", which can represent either introductions or advice. T h e y use the realization relationship to represent the aspect-class dependency. Classes w i t h aspects woven into them are shown using the "woven class" stereotype. T h e m a i n 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 i n popular C A S E tools such as R a t i o n a l Rose and M a g i c D r a w .  2.1.2  M e t a - M o d e l Changes  T h e work discussed in this section uses extensions to the U M L meta-model to support aspects or aspect-oriented extensions. K a n d e argues that aspects need to be first-class elements i n U M L [16]. His work is important to us because it shows that others have considered, and successfully argued for, the approach of introducing weaving or crosscutting as a basic concept i n U M L , instead of using extension mechanisms. He claims that the composition of a standard U M L model w i t h an aspect model does not do a good job of modularizing the separate concerns — the elements i n the design model are coupled more than they would be i n the code. In addition, the composed model does not  7  communicate the ability to plug and un-plug aspects from the core functionality. He shows that the m a i n reason for this is that since U M L doesn't include the concept of weaving, the concerns that are well-separated i n the A O program end up being scattered throughout the design model. Thus, a new model element which encapsulates the specification of the aspect as well as models the interaction between all crosscutting objects may be needed. C i t i n g the restrictions that arise when using stereotypes and profiles to extend 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 i n 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. W e believe that the ability to provide modeling tool support for a modified meta-model, coupled w i t h 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 w i t h aspect-oriented modeling ( A O M ) [4]. T h e meta-model is modified in order to make explicit i n U M L diagrams what the authors consider to be the main notions i n A O P : component (base element), aspect (crosscutting element), join point, crosscutting, and weaving. T h i s proposal has similarities to the composition patterns approach, described i n the following section (Section 2.2). H a n 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 m a i n argument against heavyweight extensions to the U M L meta-model is that they are complex and costly to implement, especially when i n this case the authors are interested i n building an AspectJ-specific tool, and not a general C A S E tool. T h e y start by creating a simplified meta-model for the static structure of Java using the meta-object  8  facility  (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 between, 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, composition 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 relationships in the existing model(s). Clarke and Walker propose the use of composition patterns to specify crosscutting concerns [6]. Composition patterns are based on a combination of UML templates and the merge integration from subject-oriented design [5]. A composition 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 binding the parameters to model elements, they can specify composition of crosscutting behaviour with base designs in a reusable way. This approach requires explicit identification 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, i n order to validate the design of a composition pattern. However, the authors note that its also possible to maintain 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]. T h e main idea behind this approach is that a program can be decomposed i n any number of ways. A hyperspace represents the concern space, i n the form of a matrix where each axis represents a dimension of concerns, and each point a concern i n that dimension. E a c h 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. H y p e r J is a tool which allows the developer to use these concepts i n Java by allowing "identification, encapsulation and integration of multiple dimensions of concerns". T h e y suggest that their approach could be used at any stage of the software 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, P h i l i p p o w 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]. Variability common to product lines is implemented using feature driven decomposition (and composition) according to concerns, which correspond to features. T h e y 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 i n H y p e r / J . In [7], Georg et. al. develop a two-level structure of composition constraints to deal w i t h 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. E a c h template element specifies properties that w i l l be incorporated into the selected points i n the p r i m a r y model. Composition strategies and composition directives correspond to the two levels of constraints.  C o m p o s i t i o n strategies use  high-level heuristics to determine how aspects should be composed w i t h the primary model, while composition directives deal w i t h specific conflicts that arise i n the context of particular aspect and primary models. K a t a r a proposes building a refinement hierarchy for a class or sequence diagram [17]. E a c h concern is viewed as a collection of superposition steps that define it. T h e authors use the term aspect to refer to these concerns. A l l additional functionality 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 modeling can be extended to modular composition of features, as well. T h e behaviour of features is specified individually w i t h incomplete diagrams, which are then composed i n a way similar to many of the other approaches described i n 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 aspectoriented crosscutting. T h e y use U M L collaborations and interactions to specify the details of structural and behavioural crosscutting, respectively, i n a given decomposition [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 w i l l be crosscut; for behavioural cross-  11  cutting, the instructions specify the links in the base collaboration. T h e i r weaving mechanism for U M L generates standard U M L models from aspect-oriented models. The mechanism's adherence to A s p e c t J 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 i n U M L , and whether U M L has sufficient abstractions for this [36]. T h e 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. T h e crosscut and crosscutting elements, the composition strategy, and the join points can all be specified independently. T h e modeler is required to explicitly state all the crosscutting relationships and join points while designing the system.  12  Chapter 3  Aspect-Oriented P r o g r a m m i n g 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 i n multiple locations i n different modules.  T h i s 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 crosscutting concerns.  In ordinary object-oriented ( 0 0 ) or procedural programs such  crosscutting concerns lead to scattering and tangling i n 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 w i t h i n a single class. A O P enables modular implementations of such concerns. A s p e c t J [18] is one popular implementation of A O P . A O P addresses modularization issues by introducing new elements and constructs to the programming language. T h e 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. I T D s are placed i n 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 i n the execution of a program.  Pointcuts are frequently specified using type patterns, which match a  particular subset of points i n 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 i n addition to the existing code. Advice can therefore be before, after, or around. Finally, aspects encapsulate advice and I T D s , as well as pointcuts. T h e pointcut specifies the point(s) where the advice is applied, or the I T D s are introduced. These points are called join points, and are identified w i t h i n the ontology of a join point model ( J P M ) . J P M s are the central mechanism that supports crosscutting i n A O P [23]. A J P M can be described i n 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 A s p e c t J , dynamic join points are points i n 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 S p r i n g A O P [34], the dynamic join points are method invocations, the means of identification are pointcuts, similar to those i n A s p e c t J , and the means of semantic effect is for advice to run before, after, around the join point, or i n case the method throws an exception. Since pointcuts i n Spring are simple Java classes, it is possible to declare custom pointcuts simply by writing a new class. In A s p e c t J the static join points are fields, methods and the parents of a type. W i t h A s p e c t J , 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 coordinate the execution of advice w i t h join points. In current A s p e c t J implementations,  14  advice weaving happens at compile or load time, and is broken down into two stages: planning, and code munging. D u r i n g the planning stage, join point shadows [11] w i t h i n the code are analyzed to check whether they match the pointcuts associated w i t h advice.  T h e matching shadows are annotated w i t h each advice that could  apply at that point. D u r i n g 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 until runtime.  15  Chapter 4  Introducing Examples In this chapter, we introduce the example models we used to test our planner. These will be used i n Chapter 5 and Chapter 6 to explain some of the more complicated points of the meta-model and planner, respectively, and also i n Chapter 7 to evaluate our framework's ability to simplify the implementation of analysis tools. We will attempt to point out some interesting characteristics of each of the designs, which we w i 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 i n the seminal A O P papers [18, 19, 23]. T w o model fragments are shown i n Figures 4.1 and 4.2. B o t h contain a class diagram and sequence diagram(s). T h e top fragment models the m a i n functionality of the Display for Shapes, which include Points and Lines.  T h e b o t t o m fragment models the Subject-Observer design pattern.  The  bindings of the elements i n the top fragment to the elements of the design pattern are included i n 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 i n a more compact way. T h i s 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  *  Display refreshO  I :Llne I moveBypnt, in^ j  Shape  moveB  I end1:Pointl  lend2:Polntl  y ( i n t , int)  moveBy(int, int)  movBBy(int, int)  _L"  Point  Line  getxo  getPio  getYO setX(int) setY(int) moveByfint, int)  getP20 setP1 (Point) setP2(Point) moveByflnt, int)  I  Point  I  moveByfint, int) £setX(int) £setY(int)  I Dependency 1: I Client: Point I Supplier: Subject I Dependency 2: | Client- Point.setX(mt), Point.s , Supplier: Subject.changef) 1  . Dependency 1: , Client: Line I Supplier: Subject I Dependency 2: I Client: Line.setPI(Point). Line.setP2(Point] Supplier: Subject.changed 1  Figure 4.1: Class and sequence diagrams for the G r a p h i c a l Shapes E d i t o r example. I :Sub|ect I hObserverl Subject addObserve r(Observe r) re moveO bserve r(Ob server) updateObserversO changeO  *  Observer  changeQ  updateQ  updateQ  Figure 4.2: Class and sequence diagrams for the Subject-Observer design pattern.  17  the base design. T h i s 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. T h i s is also a classic A O P example, and w i 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 i n 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 R a t i o n a l Software Architect ( R S A ) group at I B M - O t t a w a , 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 w i t h U M L to create applications. A s such, this is the best example we have of realworld 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. T h e state machine diagram was slightly too complicated for our purposes, so we created two simple state machines based on the information found i n the sequence diagrams. T h i s example models a simple phone system, where b o t h the Network and the physical components of the Phone (namely K e y p a d and Display) are represented. A number of different sequence and state machine diagrams specify the behaviour of the system. These diagrams are shown i n Figures 4.3 — 4.7. In this document, we include only two of the three sequence diagrams we used i n testing. We do this i n 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. T h e first sequence diagram (Figure 4.3) specifies the interactions that take place when a user places a call. T h e second sequence diagram, one that we have omitted from this document, goes into slightly more detail of the same interaction, including operations like validation. The final sequence diagram (Figures 18  cm' n> £±  so «use case realization)* Place a call - Alternative Flow 2 : jFclsieTiUer^j^ •:':'::lv;V;';:. l:d«INumber :  phones Phone  • .{^phone cSsrjay5:Phonedisplay^= pssphonespeaker5:Phone speakers  ~ WrelessNetwbrtlWrelefl  ;  11: irt.j:rxi:; number).; ; >.;:';;i:!.!;.;::;:;: :  CO co CD  1.2: dfeplayNumbert number)::  C  1.3: beepx  CD  o  CD  Crq 1.4.1 ^putPhaneNumber ( phoneNumber) j  1.4.2: pfocessNumber ( phoneNumber)  O  {  f; ; : ; « r e t u r n » : : ' ' } \ -115: prctcessNumber (ptoneNumber)  CD  :  :  :  vi.6: sendCafllnfoGd, phooel^mber)  o  5' •• 1.7::validatePhoneNurriber( id, phoheNunter'''  o  ". ^ettxrT»:^;-;:1.;j:':;'-:w ;:::-!;:;.;!::•',•; • :l-.8: vafcdabPhoneNLmber( id;phoneMurnper.) •: :  1.9: sendEcraMessage  CD CO  : 'l;10:.pushEnd  1.10.1: displayMessage;.  :  o CD  X  3  :  . 1.10.2: inputEndCal;  (  Waiting  1  Call In Progress  PlacingCall Initiating  Validating sendCalllnfo 'alidatePhoneNumber  [else]  Processing  if [validated]  Network State Machine (NetworkSM)  < •  Inactive  hangup  EnteringNumber  Talking initiateCall  processPhoneNumber  Processing initiateCall validatePhoneNumber  Validating  Phone State Machine (PhoneSM)  Figure 4.4: State machine diagrams for the Network and Phone classes i n the R S A example. S M stands for State Machine.  20  wireless network:Wireless network'?  phone keypad:Pho..  CalienUserlj phono msmor..  PphohG^pGaker: Phb;,  IphonsidsplayiPhone display!  I phone: Phone;  :lnputbigit( number;)-:; :.:;displayisiurnb9r( number ) .  beep;:. : pushSend.; • |^ inputPhonGNumberf phoneisfcjmber)'  displayMessage ,  i.ihitiateCallC.id/; ^^eNumber;;).  © VpushEhd' [  InputEndCaN;  ,;V[1 ••• entiCall(id)  ;'disp!ayC^llInfo(phoneNumbGr/.lBhgth):-  storeCallInfo(PhoneNumber Length)' (  Figure 4.5: Sequence diagram for the two-user call i n the R S A example. The diagram is split between this figure and Figure 4.6, w i t h 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" i n Figure 4.6 (starting at Phone.checkForldle) are inserted after the "1" (WirelessNetwork.initiateCall) i n the current figure. Same for the circled "2": messages starting at PhoneDisplay.displayCalllnfo i n Figure 4.6 are inserted after WirelessNetwork.endCall i n the current figure.  21  (M.h—  :•*£:! • £  © Figure 4.6: Sequence diagram for the two-user call i n the R S A example. The diagram is split between this figure and Figure 4.5, w i t h the common link being the WirelessNetwork lifeline. T h e circled numbers "1" and "2" represent the places where the two diagram fragments link together. The messages following "1" i n this figure are inserted after the "1" (WirelessNetwork.initiateCall) i n Figure 4.5. Same for the circled "2": messages starting at PhoneDisplay.displayCalllnfo i n the current figure are inserted after WirelessNetwork.endCall i n Figure 4.5.  22  Phone speaker beepO nngp  Phone display displayMessageO displayCallerlnfo(id) displayCalllnfo(phoneNumber, length) displayNumber(phoneNumber) displayNumber(number) Phone  phoneNumber initiateCallO answerCallO hangUpO inputEndCallO sendErrorMessageO initiateCall(id, phoneNumber) processNumber(phoneNumber) inputDigit(number) validate PhoneNumber(phoneNu mber) checkForldle(id, phoneNumber)  Phone keypad dialNumberO pushTalkO pushSendO pushEndQ  User accountID phoneNumber  Wireless network Phone memory storeCalllnfb(phoneNumber, length)  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 i n a phone call. T h e sequence is split between the two diagrams, w i t h the common link being the WirelessNetwork lifeline. T h e model also contains state machine diagrams for the Phone and PhoneDisplay (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). T h i s model was originally used to test out the recommendation tool for state machine diagrams (discussed i n 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 diagrams, this example w i l l also be useful for testing the sequence diagram composition tool we describe i n Section 7.1.  24  Chapter 5  M e t a - M o d e l 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 initial 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. T h e 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 E M F - b a s e d 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 m a i n components. F i r s 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 w i t h a mechanism for intertype declarations.  Second, this subset of the U M L meta-model is extended w i t h  a J P M . Finally, we present a planner which coordinates crosscutting structure i n  25  models based on this meta-model. T h e extensions to the meta-model provide the foundation for the planner to record its results. In this chapter, we discuss the first two components. T h e next chapter deals specifically w i t h the planner implementation.  5.1  U M L Meta-Model  A model i n our system is formed from any number of class diagrams, sequence diagrams, and state machine diagrams.  A l l of the diagrams are consistent w i t h  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 w i t h which we are working, w i t h the J P M additions highlighted i n 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 i n U M L 2 are currently represented i n a simple tree format instead of a standard U M L graphical notation, since i n 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 w i t h 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 still 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) i n that they can be located i n one class, but actually define a member 26  2" 3 StructuralFesture  g  none shared composite  \Relat>onsh}p\  ICtessifier  2 Property <-memberEnd SsDerived: Boolean=false Association •association isReadOnly: Boolean=false isDerived: Boolean=false 2." 0..1 SsDerivedUnion: Boolean=false /default: String +ownedEnd +owningAssociation aggregation: AggregationKind=non£ /IsComposite: Boolean 0..1  cm  S3 p  o  |+subsettedPropertyi •/superclass  , +navigableOwnedEnd  Kf to  «enumeration» AggregationKind  o o  +class  o  0..1  CD  CD  xs CD  O  +class • 0..1  +ownedOperation isQuery: Boolean=false disordered: Boolean /isllnique: Boolean flower: Integer /upper: UnlimitedNatural largetClass: Class  •coveredBy  IntersctionFrsgment  1  Interaction  OccurrenceSpecification  •interaction • 1  •lifeline  •covered  1  1  Lifeline  Joinpoint  I Represents 0..1 CormectsbleBement (from interne!Structures}  0..1  •selector  OpaqueExpressicn (from Kernel)  Interaction  Statelnvariant  Behavior (from BasicBehaviors)  NamedElement (from Kernel)  cfosscultingJoinpoints X  V J. l O - ' l  0..1  •enclosinblnteraction  •covered  •covered r7  •fragment  Joinpoint  crosscuttin g J oin p o ints  NamedEtement  |<J-  5 Interaction 1 • -^-interaction  •^-message Message  0..1  /messageKind: MessageKind message-Sort: MessageSort  Q^  +sendEvent  Mess&geEnd  +receiveEvent  -•-message 0..1 ^-connector  •0..1 Connector  OccurrenceSipecirtcation -^signature  0..1  NamedElement  ^argument  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. F r o m the U M L superstructure document.  29  B era ts 1-1 t-i-  «enumerator» TransitionKind  Behavior  «enumerator» PseudostateKind  internal local external  CD  initial deepHistory shallowHistory ioin fork junction choice entryPoint exitPoint terminate  c+ £» CD  B  £» O  cr  3"  B B CD  o  o CD  Joinpoint ]°3crossc ttingJoinpolnt^ U  7T  •connectionPoint  •effect  0..1  CD  (•connectionPoint  Pseudostate kind: pseudostateKind +entry  0..1i  •0..1  State ^Composite: Boolean /IsOrthogonal: Boolean /IsSimple: Boolean /IsSubmachineDeep: Boolean  +state  +exit  CD  ^ ^  •entry  Behavior  0..1  0..1  •exit  0..1  0..1  t-doActivity  o 1-1  0..1  0..1  ConnectionPointReference  •connection  0..1  0..1  •state  0..1  Joinpoint L#J crosscuttingJoinpoints ^  CD O  o  •submachineState  •deferrableTr gger Trigger  FinalState  •trigger  of another class [2, 3], similar i n function to I T D s i n A O P . T h i s 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 i n which it is defined.  So, unlike A s p e c t J , 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. E a c h class that performs a role i n 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 i n two ways. First, they may refer to elements i n two different class diagrams. Second, they may mention elements i n different classes of a class diagram. Figure 5.5 shows the Shapes class diagram from Figures 4.1 and 4.2 as it appears i n U M L 2 .  We include this figure i n order to show the reader the kind of  interface available for creating models w i t h U M L 2 . Initially (in the E M F implementation that w i 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, w i t h roles modeled as ordinary classes and operations i n a separate class diagram. However, w i t h the introduction of collaborations i n 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]..,^.:,<I t tl0n> Subject. changeSDj: . =  ::  :  n  Erac  :EB^'^:'<Interaction>.Pomt.moveBya)'.--.v-.:. • .-ffl^-^-:-<Interaction> Une;moveBYSD'::-'--'  .•: B-,^"::<Interacbon>:Subject.addObserverSD: •.... Selection Parent List Tree Table • Tree with Columns Problems. Javadoc Declaration 1 Property Client ^J^entDependenCy • Name :Packageab!e: Element Supplier.::.: Template Parameter Visibility  Properties £3 \  • v  i  s  '•  \ i  b  i  l  i  t  _ • .'•: _ y s l  [.Value 1 <Operation> setY, <Operation> setX : •:•:. — .j •-. -• - :.:•:-: - x . • . • - ... ••:••_its _ g P u b l i c : •.'••:•:...•:••••, ,\;.<Operat)on >. change •' i s- Public  Figure 5.5: E x a m p l e of a class diagram as shown w i t h U M L 2 .  32  5.1.2  Sequence Diagrams  A sequence diagram is represented by an Interaction i n U M L 2 , where each interaction consists of Lifelines and Messages, as well as EventOccurrence and ExecutionOccurrence elements which are used to determine the ordering of messages i n the sequence. E a c h ExecutionOccurrence specifies the lifelines that are covered by the execution, as well as the events associated w i t h the sending and receiving of messages at the start and end of the execution. E a c h Lifeline also keeps track of all the E x 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 i n that a sequence diagram refers to operations i n multiple classes i n the corresponding class diagram. Figure 5.6 shows the Line.moveBy sequence diagram from Figure 4.1 as it appears i n U M L 2 .  5.1.3  State M a c h i n e Diagrams  A state machine is represented by a StateMachine element i n U M L 2 , which is capable 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 Transitions 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 i n Figure 4.7 looks like i n U M L 2 . We use this figure to show the presence of the "crosscuttingJoinpoint" field on the CallTrigger element.  33  [i/j Resource Set  .-. - ',- - •  .B:fi.platform:/re50urcE^ointExampte/src/ShapesSubjectObserver.uml2 B 4> <Model> Subj-Obs-design-Model. <rModel? ShapeCD m m > <Model> SubpbsCD <State Machine> observerStatesSM tti <State Machine?. changellpdateSMs ^Interaction? Subject.changeSD: . r+i •{Interaction?. Point.moveBySD . . <Interacbon> Line.moveBySD 3 <Life!ine? Initiator: $ ^Lifeline? Line • .<Lifeiine>Point:' • <Lifeline> Point :!-~:^-''<Message> Line.moveBy: ••. i + <Message> Point.moveBy •. •.•!.:>.: k-^:-:-<MeS5age>.PontmOVeBy '••:;::.:••:: • s <Event Occurrence > sendL. mB -e 1 -> ^Execution Occurrence? create-exl :  J  x  <• 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 ^Interaction? Subject.add0bserverSD :  Selection j Parent | List, Tree Table |Tree with Columns ;  Problems j Javadoc ^Declaration J"GsJ Properties £3 'Property Client Dependency • Covered Finish Exec Name Receive Message i Send Message : Start Exec To After To Before Visibility  :  Value  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 w i t h U M L 2 .  34  , 1 Resource Set • S"®J platfarrn:/re50Ltfce/Poait£x^ 3 «;Model>RSAPhoneModei l+J & <Modd>PnopeSystemC3 f+j <Interacbon > PlaceCaiilSD i+j <Inte<-acbon> PaceCa!32SD El <b <Inte<acbon^> t/'oUserCalSD a • <State Machine >PhoneSM ^ <Ca!iTngger> inputPhoneNurnber <Cail Trigger> vaiidatePhoneNumber-:-:--:'.:  i-i CD  en  H X  [  ,  4- <CaS!Tngger>nii3ateCaIi  CO  <^ <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 : ^Transition > rnitateCai!2 . • -ty <Transition> answerCail <Transiton>hangup <State Machine> PhoneDisplaySM <&•• <5tate Machino NetworkSM-"  o  :  CD & OP  Selection Parent List free j Table Tree with Columns Problerns j Javadoc j Dedaratjon = l£1 Properties -23 J\vsah  tr to  1  Property : Client Dependency Crosscutting Joinpoint: .:Name * • Operation Port •: Visibility-:-  Value ; -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 i n aspect-oriented programming [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 semantic effect at join points. Figures 5.1 — 5.4 circle i n red the changes we have made to the U M L meta-model i n order to support our join-point model, and a more detailed discussion of each element i n the ontology follows.  5.2.1  J o i n Points  T h e join points of our J P M are the selected model elements i n the various U M L diagrams. Every join point is a model element, but only the elements we mention below are join points. E a c h 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. F r o m class diagrams the join points are Class and Operation elements. From sequence diagrams the join points are Messages and Lifelines. F r o m state machines, the join points are States and CaHTriggers. Because all of our join points are model elements, we w i l l often refer to a join point as a model element i n the following discussion.  5.2.2  Means of Identifying J o i n 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. T h e 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 E d i t o r example, for the setX method i n the Point class, its name would be "setX", and its signature would be "Point.setX". T h e "targetClass" field is used to determine the class that appears i n the signature of an operation. Due to the presence of I T D s , 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. T h e matching of signatures is further complicated by the presence of collaborations, and is discussed i n detail in Section 6.4.1.  5.2.3  S e m a n t i c Effect at J o i n P o i n t s  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 w i t h i n the new framework. Each element records all 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 w i t h the question of how the crosscutting relationships w i l l be displayed, which is beyond the scope of this work. For research that deals more explicitly w i t h the issue of weaving, see [6, 7, 12]. Because our mechanism simply extends the existing meta-model and its semantics, it should be possible to incorporate this proposal into other meta-models, but we have not attempted this yet. T h i s would allow for the automated analysis of crosscutting i n 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 i n various U M L diagrams. Class D i a g r a m Class CD  Class Op  SD  Lifeline  Op  Sequence D i a g r a m  State Machine Diagram  Lifeline  State  CallTrigger X  X  X X  Message SM  Message  X  X  X  State CallTrigger  X X  ing languages), as long as the appropriate elements i n 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 J P M  Now that we have discussed b o t h the U M L meta-model we w i l l use, and the J P M we have designed, we can describe i n more detail the crosscutting relationships between model elements that we consider. We will look at each k i n d of diagram i n turn, and for each element i n the diagram that is a join point look at the other elements that can be i n its crosscut-by set. T h i s discussion is also summarized i n Table 5.1. T h e m a i n rule we used for establishing the crosscutting relationships to include i n 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 i n 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. T h e reason behind this rule is to make sure that the crosscut-by sets do not grow too large. If all the transitive relationships are added to these sets, they w i 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 i n . T h e m a i n 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 i n sequence diagrams, and CallTriggers i n state machines. These relationships are fairly intuitive — Messages refer to a call to a specific Operation, and CallTriggers are also associated w i t h a single Operation. One might say that Transitions and States, both i n state machine diagrams, can also be crosscut by operations and messages. However, we return to our rule i n 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 i n the crosscut-by set. Similar reasoning applies to States, as well. Classes crosscut Lifelines and CallTriggers. Lifelines i n sequence diagrams represent objects of the class' type during a particular interaction sequence, and so belong i n 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 i n a Class' crosscut-by set, because of possible I T D s . 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 Triggers.  Message-Operation crosscutting was already discussed.  Messages crosscut  other Messages if their compound signatures (discussed i n Section 5.2.2) match. This means that Messages crosscut each other either when multiple possible flows of execution are specified i n different sequence diagrams, or there are interactions for the role-operations performed by this operation that need to be accounted for. Triggers crosscut Messages i n the same basic way they do Operations.  5.3.3  State M a c h i n e Diagrams  W i t h i n state machines, States and CallTriggers are join points. In addition to a l 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  Chapter 6  Implementation In order to evaluate our proposal and the ease of exposing different kinds of crosscutting, we have implemented a simple planner tool. T h e implementation of the prototype evolved over the course of the project, i n order to take advantage of the advances i n modeling frameworks, as well as feedback from individuals familiar w i t h the field. O u r original implementation relied on the E M F framework, as discussed in Section 6.1. Following this, we introduce the current U M L 2 - b a s e d implementation.  6.1  E M F 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 display class diagrams.  Similar to U M L 2 , the drawback of E M F is that it is not  designed as a language i n 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 i n an ecore file. T h i s is another tree-based structure that specifies all elements i n the meta-model, and their various properties and associations. T h r o u g h 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 E M F - b a s e d J P M and planner can be found i n [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 i n any U M L diagram. T h e metamodel is once again stored i n an ecore file, and represents a l l the elements and relationships laid out i n 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 still manageable, even i n the tree format.  In addition to the model i n  tree format, we keep as a reference a separate model i n 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. T h e n , once the planner populates the crosscutby sets for a l l the elements i n the U M L 2 - b a s e d 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 i n 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 U M L 2 - b a s e d implementation (our second implementation), we decided to explore the crosscutting between different existing kinds of U M L d i agrams, instead of re-implementing support for advice. T h i s 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 initial misunderstanding of our approach, and so wanted to suggest a much wider applicability of our work than simply supporting aspects i n U M L .  6.3  Model Editor  This section describes the process of the editor implementation. T h e editor we use to create models based on our modified meta-model is designed as an Eclipse plugin. 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 a l 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. T h a t way, we were able to launch a new workbench from w i t h i n 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 i n 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 i n 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. T h e code for the plug-in came w i t h a completely specified meta-model (in an ecore file), which we modified as described in Chapter 5. W e 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 i n order to make the new fields show up properly i n the editor. However, these were minimal, and we were already familiar w i t h the process from our first (EMF-based) implementation. After this, launching the project as a separate workbench process i n 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 implementation is separated into a series of phases, each corresponding to a particular kind of crosscutting. T h e body of the new planner consists of approximately 1,000 loc i n 6 m a i n classes, as well as 4 additional utility classes. D u r i n g each phase, the planner records the crosscutting join points i n the crosscut-by set of the appropriate element. Before describing the phases i n detail, we say a couple of things about finding matching elements i n the presence of collaborations and dependencies. To provide feedback about crosscutting structure, we took advantage of our additions to the meta-model. A s mentioned before, i n Section 5.2, we added a new field to all join points, which keeps track of all the other join points which crosscut this element (the "crosscuttingJoinpoints"  field).  T h e 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 w i t h 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 i n 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 A s p e c t J , and incremental model-checking [21], so we hope to be able to apply similar techniques to develop an incremental planner.  6.4.1  Matching  Before describing the planner phases, it will 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 i n the presence of collaborations, and we elaborate on it here. The simplest form of element matching is purely name-based. T h e signatures (discussed i n Section 5.2.2) of the two elements are compared, and if they are equal the elements are said to match. The other k i n d of matching happens i n the presence of Collaborations. W i t h collaborations, classes and operations can perform the roles specified i n the collaboration.  In this case, two elements match if one performs the role of the other.  Using the Shapes E d i t o r example, any calls to Subject.change w i l l crosscut the operation Point.setX, since setX performs the role of change i n 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.  parameter lists or return types of operations.  45  We do not take into account  6.4.2  Phases  Our planner was designed to operate i n phases, as we gradually expanded the project from looking at interactions between two kinds of diagrams to three. T h i s also gives us the added benefit of being able to take out some of the phases if we are only interested i n exploring a particular kind of crosscutting relationship. Currently, there are four phases i n our planner: role b i n d i n g (collaborations), I T D s , sequence diagrams, and state machine diagrams, r u n i n that order. In addition, there is a set-up phase that precedes a l l of these, which simply prepares the models by clearing the crosscut-by sets of all model elements, so that the results from previous runs of the planner don't overlap w i t h the current results. This ordering of the phases also ensures that each new phase builds on the existing structure, recording crosscutting not only between elements i n the diagrams it adds, but also going back and recording crosscutting between elements of the new diagram and the existing ones. T h e results (the crosscut-by sets) are recorded by the planner i n the "crosscuttingJoinpoint" field of each model element that is a join point. Figure 6.1 shows a U M L class diagram of the m a i n classes and operations i n our implementation.  Role B i n d i n g (Collaborations) The role binding phase looks at a l l the CollaborationOccurrences i n the model, and records the associations they specify i n internal tables. Specifically, it looks at each of the Dependency elements i n 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, i n the corresponding tables) to a list of model elements (classes or operations) which perform that role i n some collaboration. These tables 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  ITDPhase introducedOpsPerClass: Hashtable introducedPropsPerClass: Hashtable  Planner  processlTDsQ  runO prepareModelsO roleBindingCCingPhaseO itdCrosscuttingPhaseO sdCrosscuttingPhaseO smCrosscuttingPhaseO  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. H e l p e r / u t i l i t y classes and operations are omitted for clarity.  47  match between two elements, to see whether an element performs some role i n a collaboration.  Inter-Type Declarations (ITDs) The I T D phase goes through the properties and operations i n a l l the classes i n the model. It checks the "targetClass" field (described i n 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 i n a table. There are two tables i n 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. T h e tables from both I T D and role binding phases are used during matching to identify a l l signatures that could refer to a given model element.  Sequence Diagrams T h i s next phase goes through the sequence diagrams, and records all the crosscutting that takes place between elements i n different sequence diagrams, and between elements i n sequence diagrams and class diagrams. First, the tool goes through all the Messages for each sequence diagram, and finds and records the matching Operations i n class diagrams, and matching Messages in other sequence diagrams. T h e n it iterates through the Lifelines, and finds the matching Classes for the objects represented by the lifelines.  State M a c h i n e Diagrams T h e final phase goes through the state machine diagrams, and records the crosscutting between elements i n different state machines, and also between those i n 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. T h e n it finds other matching C a l l Triggers by looking i n a l l the other state machine diagrams. For a l 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 a l l the triggers for its incoming transitions). Finally, this stage is completed by finding States i n different state machine diagrams that crosscut each other. T w o states crosscut each other if any of the incoming transitions for b o t h states share any operations i n 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  Chapter 7  Evaluation To validate our contributions, we use our J P M - e n h a n c e d meta-model and planner i n 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 i n the examples. Finally, we present a way to add support for advice to the J P M and planner, along w i t h a discussion of the differences of advice i n our system and i n standard A O P implementations like A s p e c t J . We have not implemented this addition due to time constraints, but a simple version of it was implemented for our original E M F - b a s e d meta-model and planner. This, coupled w i t h the fact that there are no major conceptual differences between the E M F - b a s e d and U M L 2 - b a s e d 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 w i l l be able to present the modeler w i t h 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 i n which these can be displayed to the modeler. T h e y 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 m a i n points at the end of this chapter.  7.1  Recommending Transitions for State Machines  W h e n designing a system, it is often necessary to be able to say which diagrams can/need to be specified before others.  Since multiple diagrams i n 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 i n a state machine, based on the interactions already specified i n sequence diagrams. In general, we believe this k i n d of analysis would be useful to those specifying the behaviour of a system, keeping efficiency and consistency of the model i n m i n d .  7.1.1  Solution  This first analysis tool is used to help w i t h the creation of state machines, provided all the sequence diagrams i n the model have already been specified. For a selected state, we'd like the tool to be able to make suggestions for possible outgoing transitions based on the sequence diagrams already specified i n the model. T h i s 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 i n a sequence diagram. T h e n we looked at the parent Interaction for each of those messages, m , to see what other 51  messages could occur i n sequence after m i n each of those sequence diagrams. Those messages are the ones whose corresponding operations could trigger a transition out of the state. T h i s simple tool can be written w i t h approximately 40 loc, on top of the planner implementation discussed i n 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 i n 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 i n sequence. A n extension of this approach would be to look at states i n other state machines which crosscut this state, and recommend messages for the outgoing transitions from those states, as well. We d i d not explore this approach because the problem as presented to us was how to provide help i n creating state machine d i agrams when some sequence diagrams were available, without knowing anything about other state machine diagrams. A small problem arises when looking at the initial message i n a sequence diagram. T h e recommendation tool is currently not complete i n that it could never recommend the first message i n 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 w i t h this, but it would not be as precise as the other recommendations made by the tool. T h e basic idea is to look at the signature of a message that is first i n a sequence, and determine what class the corresponding operation belongs to. T h e n , 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 w i t h model: RSAPhoneModel Working' w i t h SM: PhcmeSM Outgoing suggestions f o r s t a t e 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 M a t c h i n g 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 initiateCall M a t c h i n g 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 C u r r e n t t r i g g e r xa a n s w e r C a l l M a t c h i n g message PhoneKeypad.pu3hEnd Outgoing s u g g e s t i o n s f o r s t a t e EnteringFhoneNumber C u r r e n t t r i g g e r i s inputPhoneNumber M a t c h i n g message P h o n e D i s p l a y . d i s p l a y M e s s a g e M a t c h i n g message Phone.processNumber M a t c h i n g message P h o n e D i s p l a y . d i s p l a y M e s s a g e  Working w i t h SM:  PhoneDi3playSM  Outgoing suggestions f o r s t a t e displayingCallerlnfo Current t r i g g e r i s displayCallerlnfo M a t c h i n g message P h o n e S p e a k e r . r i n g  Done.  Figure 7.1: Snippet of the output of the transition recommendation tool for state machines, as r u n on the R S A model example.  7.1.2  W h a t W e Found i n 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. O n l y the signatures of recommended messages are shown, but the tool gets a reference to the message itself. T h i s would be useful if the analysis tool were extended w i t h 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, i n 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. T h e second transition already appears i n the P h o n e S M , which is a good check to make sure that the sequence diagram and state machine are i n agreement.  53  If the state machine hadn't been  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 i n the P h o n e S M state machine diagram, PhoneDisplay. display Caller Info can cause a transition out of the state, since the user may want to know who they're talking to. Also, P h o n e K e y p a d . p u s h E n d can cause a transition, 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  T h e J P M and planner have simplified the implementation of this analysis tool by exposing the crosscutting relationships we are interested i n , and collecting them i n 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 w i 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 will 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 w i t h behaviour i n 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.  T h e design pattern is "applied" to the base design through the use  of collaborations, which mark operations i n the base design as performing roles (of classes or operations) i n the pattern model. T h e 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 w i t h 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 a l l the flows that the call to this operation can invoke. T h i s k i n d of analysis tool would be useful to anybody wanting to verify the behaviour of a system, and whether it behaves as expected i n 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 t r y i n g to find out, for example, how to implement a particular operation — they would need to see a l l the possible executions i n order to understand exactly what the operation is responsible for.  7.2.1  Solution  T h i s second k i n d of analysis tool can help a modeler w i t h overall understanding of the behaviour of a system, where different parts of the behaviour are specified i n different sequence diagrams. W e propose an analysis tool that w i 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. T h e 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, i n the Shapes E d i t o r E x a m p l e (Section 4.1), Figure 4.1 shows two sequence diagrams, both of which include a call to Point.moveBy. W h a 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 still be useful to see the composed diagram, where all possible flows of execution would be indicated.  55  T h e other case deals w i t h behaviour i n the presence of collaborations, where a role performed by a class or operation can introduce new behaviour. In particular, we are interested i n operations that have their execution specified by a sequence diagram, and are also covered by a collaboration, w i t h 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, i n order to detect any unexpected interactions that the collaboration may introduce. Sequence diagram composition for both of these approaches can be accomplished by finding all messages i n the sequence diagram of interest that are crosscut by any message, m , i n some other sequence diagram, and inserting the sequence of messages following m into the original sequence. For the first case, we are only interested i n looking at crosscutting messages that have the same signature as the message of interest. For the second case, we are interested i n looking at crosscutting messages w i t h a different signature, which w i 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 w i l l be present i n the crosscut-by set of the message of interest. T h i s tool can be written w i t h approximately 50 loc, on top of the planner implementation.  7.2.2  W h a t W e Found in Examples  In this section, we show the results of running the analysis t o o l on the G r a p h i c a l Editor E x a m p l e model. W e present two examples which correspond to the two cases we introduced i n Section 7.2.1. Figure 7.2 shows output from running the tool on the first example, where we are interested i n 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 P o i n t . m o v e B y sequence is affected i n the presence of the change role  56  Working with model: Subj-Obs-design-Model Line.moveBy : from Line.moveBySD Point.moveBy : from Line.moveSySD P o i n t . s e t X : front Point.moveBySD P o i n t . s e t Y : from Point.moveBySD P o i n t .moveBy : from L i n e . moveBySD P o i n t . s e t X : from Point.moveBySD P o i n t . s e t Y : from Point.moveBySD Point.moveBy : from Line.moveBySD Done.  Figure 7.2: O u t p u t of the sequence composition tool on the Line.moveBy sequence from Figure 4.1, w i t h role bindings not included.  Working w i t h model: Subj-Obs-design-Model Point.moveBy : from P o i n t .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: O u t p u t 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 w i t h the design, which can be fixed during implementation by using A O P techniques  7.2.3  [18].  Benefit  We believe this k i n d of analysis should help verify composed system behaviour i n the presence of design patterns or advice (discussed i n Section 7.3). For example,  57  w i t h respect to design patterns implemented as collaborations, this could be used to check whether the role behaviour applies i n all 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. T h i s 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, b o t h to the metamodel and planner. W e consider advice (from A O P ) as another k i n d of modeling element, which can crosscut other (existing) model elements. In particular, advice can be crosscutting i n that it may apply to multiple elements i n different diagrams in the model. For an introduction to advice and other A O P concepts, please see Chapter 3. T h i s discussion is more abstract than the previous two, since we have not actually implemented this problem i n our U M L 2 - b a s e d meta-model and planner. However, we d i d have support for this i n the original E M F - b a s e d 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 metamodel and planner, we consider how the advice elements we propose are different from the concept of advice i n A O P languages such as A s p e c t J . In particular, we noticed that advice i n A s p e c t J can only be applied to methods and calls, whereas w i t h our meta-model and J P M advice can be applied to any element i n the model that is identified as a join point w i t h i n the J P M . O f course, this also involves coming up w i t h a more general definition for what it means for an element to be advised. T h e first part of this discussion should be of particular interest to those inter58  *  Display  »  refreshO  Shape moveByfint, int)  Advice  after  1  Point  ,2  getxo getvo setX(int) setY(int) moveByflnt, int)  operation(Shape+.moveByO) I operation(Shape+.set*0): "should be change"  Line getPIO getP20 setP1 (Point) setP2(Point) moveBy(int, int)  Figure 7.4: G r a p h i c a l Shapes E d i t o r example class diagram, w i t h an example of advice.  ested i n t r y i n g 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 willing to try to import new paradigms from programming to modeling. T h e second part of this discussion w i l l be more appealing to those interested i n exploring the nature of advice i n 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.  F i r s t , we add the new advice [18] element to the meta-model,  which makes it possible to advise other model elements.  Advice i n 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 righthand side i n Figure 7.4. T h e syntax used i n the figure serves only to illustrate the meaning, and is not a concrete proposal for advice syntax. Advice can be crosscutting i n that it may apply to multiple elements i n different diagrams i n 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 w i t h after-advice that makes calls to Display.update. A more 59  thorough discussion of this example can be found i n [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 i n 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 i n the operation pointcut (methods are called operations i n U M L diagrams). T h e operation pointcut is pretty straightforward — it picks out operations which match the signature specified in the pointcut. We use AspectJ-like syntax i n the pointcut expressions. T h e symbol "+" refers to subclasses, and "*" is used as a wildcard. So, for example, the first pointcut specifies all m o v e B y operations i n subclasses of Shape, while the second refers to all operations i n subclasses of Shape whose name starts w i t h "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 w i t h 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. T h i s w i l l involve either adding a new phase, if we're dealing w i t h a completely new kind of crosscutting, or modifying an existing phase, if we're adding an element i n a diagram for which we already provide some support. In general, the addition of a new k i n d of crosscutting model element requires a new phase of processing if the element is not subsumed by any of the phases described i n Chapter 6. In addition, the position of the new phase i n 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 w i l l need to add a new phase to handle the processing of advice, since it's a completely different kind of crosscutting.  60  T h e presence of advice i n our modeling language, i n addition to collaborations and inter-type declarations (ITDs), leads to an interesting semantic question. We would like I T D s and advice to be able to depend on role bindings when appropriate. 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 i n the role. Similarly, we would like pointcuts to be able to depend on collaborations and I T D s . T h i s semantics is easy to achieve w i t h a simple linear processing of model elements i n which collaborations are handled before I T D s , which are handled before advice.  T h i s would mean that the advice phase would run after a l l the existing  phases.  B u t if we also wanted role bindings to be able to depend on I T D s , then  we would have to adopt some sort of a fixed-point approach i n our planner. So far, we have been unable to come up w i t h a sufficiently compelling example that would require the more complex semantics.  7.3.2  Benefit  T h e 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 i n U M L . A O P is i n increasing demand right now, and there is a need for support for the process throughout its lifecycle. There are a number of approaches, discussed i n Chapter 2, that advocate either the support for A O elements i n 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 k i n d 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 k i n d of element being added, only on the crosscutting relationships it has w i t h other model elements. T h i s can be done for other diagrams i n U M L , or domain-specific models for certain  61  applications. T h i s 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 A s p e c t J elements to the meta-model, the advice described in Section 7.3.1 differs from the advice usually discussed i n the context of A s p e c t J . In particular, i n A s p e c t J advice applies to points i n 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, i n that advice can apply to any model element which can be identified i n 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 i n Chapter 1, and justify them w i t h 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 M e t a - M o d e l C a n Support Crosscutting Structure i n 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 i n 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 structure (model elements) w i t h less work than would be required w i t h established modeling 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 support for these elements to our meta-model and planner w i t h a couple of weeks worth of work, while there is still no support i n R S A for advice, regardless of the increasing 62  interest i n aspect-oriented implementation and design. F r o m m a k i n g 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. T h e implementation was straightforward, as is access to the elements i n 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 i n their implementation.  7.4.2  Traversing the M o d e l to Collect Crosscutting is Straightforward  Once the J P M was added to the meta-model, the planner tool implementation was fairly straightforward, as discussed i n Chapter 6. T h e staged implementation allowed us to concern ourselves only w i t h specific diagrams during each of the passes. A l l model elements of interest have signatures which can be compared i n order to determine whether elements match or not, and we have devised matching rules that are applied i n the case of roles from collaborations, which complicate the matching process.  7.4.3  T h e A b o v e H e l p M o d e l i n g Tools to Access, A n a l y z e , and Display Crosscutting Relationships of Interest  Sections 7.1 and 7.2 discussed simple automatic tools we have implemented that help w i t h analysis of existing crosscutting structure.  Section 7.3 dealt w i t h 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. T h i s ended up not being the m a i n focus of the project, so we d i d not explore the issues involved i n creating a graphical display. Deciding how each k i n d of crosscutting relationship w i l l be represented graphically  63  is another b i g issue, and we thought it may be too general of a question to address in our work.  7.4.4  Planner Tool  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, w i t h respect to implementation of b o t h a planner and analysis tools. B o t h 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 i n Section 7.1, on the use of messages i n sequence diagrams to recommend possible transitions i n state machines, is a direct result of feedback from Susan M c l n t y r e , 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 i n sequence diagrams could be used to help w i t h 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 collaboration diagrams were among those recommended to us, i n particular by B r a n Selic, who has a long history w i t h real-time modeling. Another question that was raised is whether there is a distinction between design-time crosscutting (what we are dealing w i t h here) and run-time crosscutting (addressed by A O P approaches). Advice, discussed i n Section 7.3 can be used as an example of this, since just where 64  advice can apply, and what it means, is different i n A s p e c t J 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, w i t h the same kinds of benefits. Finally, it was discussions w i t h 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  Chapter 8  Conclusion We propose bottom-up support for crosscutting structure i n U M L by adding a simple J P M to the U M L meta-model. T h i s 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. U s i n g our meta-model, adding new I T D constructs was a fairly straightforward 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 effectively expose the crosscutting between model elements i n various diagrams. T h i s 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 i n Chapter 7. T h r o u g h 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 i n Chapter 5. In terms of implementation, we present a self-contained J P M - e n h a n c e d U M L meta-model, and an easily extensible planner tool. B u i l d i n g 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 w i t h i n a single model. We propose an advice semantics i n which any k i n d of join point can be advised, including not just method calls, but also transitions, classes, states, and others, as discussed i n 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 initial implementation. We would also like to see the analysis tool suite extended w i t h 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 i n this thesis. We believe that adding a J P M to a meta-model is promising both i n terms of support for existing kinds of crosscutting, as well as addition of support for new kinds of crosscutting, like aspects and advice. O u r proof-of-concept implementation demonstrates this. W e 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] A s p e c t J T e a m . T h e aspectj programming guide,  http://eclipse.org/aspectj/,  2005. [3] H . Cannon. Flavors: A non-hierarchical approach to object-oriented programming. Technical report, Symbolics Inc., 1982. [4] C . Chavez and C . Lucena.  A metamodel for aspect-oriented  modeling.  Workshop on Aspect-Oriented Modeling with UML at AOSD2002,  In  Enschede,  The Netherlands, A p r i l 2002. [5] S. Clarke, W . Harrison, H . Ossher, and P. Tarr. Subject-oriented design: Towards 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 Software 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 . H a n , 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 i n Java and  aspectj. In Proceedings of OOPSLA '02, ACM SIGPLAN Notices, 2002. [10] S. Herrmann. Composable designs w i t h ufa. In Aspect-Oriented Modeling with  UML workshop at the 1st International Conference on Aspect-Oriented Software Development, Enschede, T h e Netherlands, A p r i l 2002. [11] E . Hilsdale and J . H u g u n i n . Advice weaving i n aspectj. In International Con-  ference on Aspect-Oriented Software Development (AOSD), pages 26-35. A C M Press, 2004. [12] W . - M . H o , J . - M . Jezequel, F . Pennaneac'h, and N . Plouzeau. A toolkit for weaving aspect oriented u m l designs. In Proceedings of the 1st international  conference on Aspect-oriented software development, pages 99-105, Enschede, T h e Netherlands, 2002. A C M Press. [13] I B M .  Rational  software  architect  (rsa).  http://www-  128.ibm.com/developerworks/rational/products/rsa/, 2005.  [14] I. Jacobson and P . - W . N g . Aspect-Oriented Software Development with Use Cases. A d d i s o n Wesley Professional, 2004. [15] J . Jezequel, N . Plouzeau, T . Weis, and K . Geihs. F r o m contracts to aspects i n  u m l designs. In A sped-Oriented Modeling with UML workshop at AOSD, 2002. [16] M . M . K a n d e , J . Kienzle, and A . Stohmeier. F r o m aop to u m l - a bottom-up  approach. In Aspect-Oriented Modeling with UML workshop at the 1st International Conference on Aspect-Oriented Development, 2002.  69  [17] M . K a t a r a and T . M i k k o n e n .  Refinements and aspects i n u m l .  In Aspect-  Oriented Modeling with UML Workshop at UML Conference, 2002. [18] G . Kiczales, E . Hilsdale, J . Hugunin, M . Kersten, J . P a l m , and W . G . Griswold.  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 . M e z i n i . Aspect-oriented programming and modular reasoning. 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. K r i s h n a m u r t h i , K . Fisler, and M . Greenberg. Verifying aspect advice modularly. 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. E x t e n d i n g 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 . M a s u h a r a and G . Kiczales. Modeling crosscutting i n aspect-oriented mechanisms. In European Conference on Object-Oriented Programming (ECOOP), pages 2-28. Springer, 2003. [24] O M G . Unified modeling language (uml), version 1.5.  http://www.uml.org,  2004. [25] H . Ossher and P. Tarr.  H y p e r / 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 . F l o r i n , F . Legond-Aubry, L . Seinturier, L. Martelli.  A u m l notation for aspect-oriented software design.  and  In Aspect-  Oriented modeling with UML workshop at AOSD, Enschede, T h e Netherlands, 2002. [27] I. P h i l i p p o w , M . Riebisch, and K . Boellert. T h e h y p e r / u m l approach for feature based software design. In The 4th AOSD Modeling with UML Workshop, San Francisco, C A , 2003. [28] C . Prehofer. Feature interactions i n statechart diagrams or graphical composition 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.  Uml  2.0  metamodel  implementation  (uml2).  h t t p : / / w w w . e c l i p s e . o r g / u m l 2 / , 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 u m l for modeling complex real-time systems. Compilers, and Tools for Embedded Systems: ACM  In Languages,  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 . U n l a n d . Designing aspect-oriented  crosscut-  ting i n u m l . In Workshop on A sped-Oriented Modeling with UML at AOSD, Enschede, The Netherlands, 2002. [36] D . Stein, S. Hanenberg, and R . U n l a n d .  Position paper on  aspect-oriented  modeling: Issues on representing crosscutting features. In Workshop on AspectOriented Modeling at AOSD, 2003. [37] G . Straw, G . George, E . Song, S. Ghosh, R . B . France, and J . M . B i e m a n . M o d e l composition directives. In Conference on the Unified Modeling Language, Lisbon, Portugal, 2004. [38] J . Suzuki and Y . Yamamoto. Extending u m l w i t h aspects: Aspect support i n the design phase. In ECOOP Workshop on AOP, 1999. [39] T . T a m a i , N . Ubayashi, and R . Ichiyama. A n adaptive object model w i t h dynamic 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 Software 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  

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

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"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0051588/manifest

Comment

Related Items