Concern-Driven Development with jUCMNav Daniel Amyot
Stéphane Leblanc
Jason Kealey
Jörg Kienzle
EECS University of Ottawa Ottawa, Canada
[email protected]
EECS University of Ottawa Ottawa, Canada
[email protected]
JUCM Software Inc.
SCS McGill University Montréal, Canada
[email protected]
Abstract—The User Requirements Notation (URN) enables the graphical modeling of requirements with goals and scenarios, and jUCMNav is a free, Eclipse-based tool that supports modeling and analysis with URN. Concern-Driven Development (CDD) enables requirements engineers to encapsulate and reason about concerns, whether they are crosscutting (i.e., aspects) or not. However, to truly capitalize on the benefits promised by CDD, concerns need to be encapsulated across software development phases, i.e., across different types of models at different levels of abstraction. Recently, URN was extended to support aspect-oriented concepts. This demonstration focuses on the new concerndriven modeling features of jUCMNav, together with its capabilities to compose aspects together, and to transform aspectual scenario models into design models in the Reusable Aspect Models notation. jUCMNav is hence one of the few tools that enable CDD from requirements to design.
Gatineau, Canada
[email protected]
URN models [8]. jUCMNav is now at its fifth major release in the past seven years (the current version being 5.1). URN was recently enhanced with aspectual concepts to form the Aspect-oriented URN (AoURN) [10] and support concern-driven development (CDD), with the aim to explore whether CDD’s promises would hold in a goal/scenario context. In particular, CDD is believed to improve productivity, reusability, and maintainability, as high-level concerns that are important to stakeholders are encapsulated regardless of how these concerns are distributed over the system structure. This paper introduces three major contributions to jUCMNav for supporting CDD in that context: i) support for modeling with AoURN, ii) aspect weaving of AoURN scenarios, and iii) transformation of AoURN models to aspectoriented design specifications in the Reusable Aspect Models (RAM) notation.
Keywords-aspects; concerns; jUCMNav; Reusable Aspect Models; User Requirements Notation; Use Case Maps
I.
INTRODUCTION
The User Requirements Notation (URN), standardized by the International Telecommunication Union, targets the modeling and analysis of requirements in the form of goals and scenarios [5]. To this end, URN combines the Goaloriented Requirement Language (GRL) with the Use Case Map (UCM) notation. This combination has proven to be useful and successful for many requirements engineering activities, in academia and industry, for over a decade [3]. One major contributor to this success is the availability of the jUCMNav tool, a free, open-source, Eclipse-based environment for creating, navigating, analyzing, and transforming
AoURN Model (in jUCMNav)
II.
NEW JUCMNAV CAPABILITIES
In order to support AoURN modeling, jUCMNav’s metamodel was extended with the concepts of concern (a collection of UCM diagrams), pointcut expressions (a UCM map used for pattern matching against base models), pointcut stubs ( , to represent aspectual UCMs with advices, and to include pointcut expressions), and various types of aspectual markers ( , to indicate where aspects have been composed with base models). The tool’s GUI was also enhanced with a Concerns View (to manage concerns-diagrams relationships), a new tool palette for AoURN-specific elements, and contextual pop-menus for localized transformations. Figure 1 (left) gives a bird’s eye view of the tool, whose details are not meant to be readable but can however be seen online [8].
Step View (in GraphViz)
RAM Model (in RAM tool)
Figure 1: Partial AoURN model in jUCMNav (left), one of its generated steps views in Graphviz (middle), and extract of the resulting RAM model (right)
An AoURN model may contain many concerns, and some may be crosscutting (i.e., the aspects). In jUCMNav, aspects can selectively be weaved (i.e., composed) with the other concerns, according to the composition algorithms introduced by Mussbacher [10]. The result is a composed AoURN model with aspect markers being inserted at the locations matched by the aspect’s pointcut expression. Aspect markers also link to the aspect’s advices, providing endto-end scenario relationships across concerns. The third major contribution is an automated AoURN-toRAM transformation, useful for reactive systems development in general. This transformation, informally described in [11], enables high-level workflows and concerns to be specified with AoURN while the workflow details are specified with RAM (a UML-based notation which excels in the specification of structural and behavioral design models). The input of the transformation is an AoURN model where some of the scenario responsibilities ( ) are stereotyped with input and/or output. The transformation’s outputs include i) a skeleton RAM model (i.e., an aspect-oriented UML model with package, class, and sequence diagrams), where some identifiable parts are meant to be completed manually (e.g., by adding code for managing data types, which are not modeled in AoURN), ii) step view diagrams (where a step captures part of the scenarios/aspects between an input and an output) that highlight which parts of the model require coding from the RAM designer, and iii) Java instantiation code. The transformation, available as a jUCMNav plug-in [2], is actually composed of five sub-transformations, all implemented with Kermeta [9]: 1. AoURN to the Intermediate Workflow Model (IWM), whose purpose is to filter out irrelevant details from the AoURN model and turn stereotyped responsibilities into first-class modeling elements. 2. IWM to IWM, to add implicit input/output elements (according to heuristics) and to decompose steps. 3. IWM to dot, Graphviz’s language [6], in order to generate the step view, one of which is shown in the middle part of Fig. 1 (what is in grey requires the attention of the RAM designer). 4. IWM to RAM (one RAM aspect per step, and one folder of related RAM aspects per concern). One aspect model is illustrated in Fig. 1 (right) and can be manipulated with a multi-touch RAM tool [1]. 5. IWM to Java, for generating code necessary to instantiate the RAM Workflow Execution Environment (under development), and the main program. In the above, transformations 1 and 2 are done in sequence, and then transformations 3, 4, 5 are done from the same IWM source model. III.
supports the scenario part of AoURN (the goal/GRL part is left for future work) and aspect weaving at that level. The AoURN-to-RAM transformation is also quite unique. Over the past decades, many researchers have explored transformations from various scenario notations, used at the requirements level, to different state machine formalisms, used at the design level [12]. However, none involves crosscutting concerns or aspects explicitly. In addition, work that takes crosscutting concerns at various development phases into account such as Aspect-Oriented Software Development with Use Cases [7] does not address automated transformations, whereas the work that includes automation such as Model-Driven Theme/UML [4] does not address transformation from requirements models. We believe that jUCMNav now offers a platform suitable to further explore the promises of CDD at the requirements level, and across development phases. In particular, a RAM Workflow Execution Environment is currently being developed, and our transformation essentially targets this environment. This should enable the simulation of AoURN models (a feature currently missing in jUCMNav), as well as the deployment of reactive/workflow systems developed with AoURN and RAM. ACKNOWLEDGMENT This work was supported by NSERC. We are also indebted to G. Mussbacher for his contributions to this work. REFERENCES [1]
[2] [3]
[4]
[5]
[6] [7] [8] [9] [10] [11]
CONCLUSIONS
This paper gave an overview of three recent and major additions to jUCMNav targeting Concern-Driven Development with AoURN. jUCMNav is currently the only tool that
[12]
W. Al Abed, V. Bonnet, M. Schöttle, O. Alam, and J. Kienzle, “TouchRAM: A Multitouch-Enabled Tool for Aspect-Oriented Software Design”, (unpublished). AoUrnToRam website, http://jucmnav.softwareengineering. ca/ucm/bin/view/ProjetSEG/AoUrnToRam D. Amyot and G. Mussbacher, “User Requirements Notation: The First Ten Years, The Next Ten Years”. Journal of Software (JSW), Vol. 6, No. 5, 2011, pp. 747–768. A. Carton, C. Driver, A. Jackson, and S. Clarke, “ModelDriven Theme/UML”, Transactions on Aspect-Oriented Software Development VI, LNCS vol. 5560, Springer, 2009, pp. 238–266. International Telecommunication Union (ITU-T), “Recommendation Z.151 (11/08): User Requirements Notation (URN) - Language Definition”, November 2008. Graphviz website, http://www.graphviz.org/ I. Jacobson and P.-W. Ng, “Aspect-Oriented Software Development with Use Cases”, Addison-Wesley, 2005. jUCMNav website, http:// softwareengineering.ca/jucmnav Kermeta website, http://www.kermeta.org/ G. Mussbacher, “Aspect-oriented User Requirements Notation”, Ph.D. thesis, University of Ottawa, Canada, 2010. G. Mussbacher, J. Kienzle, and D. Amyot, “Transformation of Aspect-oriented Requirements Specifications for Reactive Systems into Aspect-oriented Design Specifications”, Proc. 1st MoDRE Workshop, 2011, IEEE CS, pp. 39–47. H. Liang, J. Dingel, and Z. Diskin, “A comparative survey of scenario-based to state-based model synthesis approaches”, in 5th Int. Workshop on Scenarios and State Machines: Models, Algorithms, and Tools (SCESM'06), ACM, 2006, pp. 5-12.
