Fig 2 - uploaded by Daniel Amyot
Content may be subject to copyright.
Source publication
In November 2008, the User Requirements Notation (URN) was approved as Recommendation Z.151 by the Standardization Sector
of the International Telecommunication Union (ITU-T). URN is the first and currently only standard that supports both goal-oriented
and scenario-based modeling for requirements engineering activities. The Aspect-oriented URN (Ao...
Contexts in source publication
Context 1
... limited to establish trace- ability by relating tasks (i.e., possible solutions) or actors in goal models to their representation in the UCM model (e.g., maps, responsibilities, and stubs or com- ponents that further describe the linked GRL elements). For example, the GRL Customer stakeholder in Fig. 1 is linked to the UCM Customer component in Fig. 2. Finally, URN allows the definition of metadata (<<MetadataName>>) for any URN modeling element, thus providing an extension mechanism that permits the definition of profiles for URN. The most comprehensive URN tool available to date is the Eclipse plug- in jUCMNav [11]. jUCMNav is a full editor for GRL and UCM models that ensures that ...
Context 2
... Earn/Redeem Movie Points use case impact the goal model ( Fig. 3.b and Fig. 3.c), and how the new Security NFR concern impacts the use cases ( Fig. 3.d). Note that the tasks defined on the pointcut graphs of the use case concerns have URN links to UCM elements (e.g., Process online and send by mail is linked to processOrder and sendMovie shown in Fig. 2). Furthermore, a reusable aspect graph of the Security NFR concern is shown in Fig. 4, explaining how security can be generally achieved by modeling knowledge from the security domain. concern with the application-specific goal model of the online DVD store. The pointcut expression matches any two tasks with a dependency link as long ...
Context 3
... base elements. Contrary to AoGRL, a UCM aspect marker is not just an annotation but is rather a kind of stub that links the base model with a submap, i.e., the aspect map. Bindings between the aspect marker and the aspect map are created automatically by AoURN's composition mechanism. Figure 8 shows the aspect markers added to the use case from Fig. 2 because the pointcut expression in Fig. 7 matches selectMovie and processOrder in this use case. Fig. 8 also shows the AoView for the aspect markers, highlighting the portion of the Communication aspect map that is inserted. When the first aspect marker is reached during the Buy Movie scenario, the scenario continues with the aspectual ...
Context 4
... these small aspects relate to each other. Intertwined use cases are a very common phenomenon. AoUCM uses interleaved composition to address this problem by allowing multiple pointcut stubs to be defined for a single aspect map. A requirements engineer can understand the ERMP use case simply by look- ing at its definition, i.e., the aspect map in Fig. 12. First, a member form must be filled if the customer is not yet signed up, then movie points may be redeemed if enough points are available, and finally movie points may be earned if the member did not redeem movie points in the same transaction. In addition, the pointcut stubs identify how the BM use case is interleaved with the ERMP ...
Context 5
... shown in the pointcut expression in Fig. 12, interleaved composition is achieved with a series of UCM paths, established by connecting together grey end and start points. Pairs of grey end and start points are ignored by the matching algorithm and the pointcut expression is therefore easily matched against the Buy Movie use case described in Fig. 10. The additional grey end and ...
Context 6
... pointcut map. All examples until now featured only pointcut maps with one grey start and one grey end point and aspect maps with only one pointcut stub. The binding to the pointcut stub on the aspect map was therefore straightforward -the in-path of the pointcut stub is connected to the grey start point and the out-path to the grey end point. In Fig. 12, the processOrder pointcut stub is connected to the first path segment of the pointcut expression, the payForMovie pointcut stub to the second path segment, and the sendMovie pointcut stub to the third and last path segment. Note how the causal relationship of the individual steps of the Earn/Redeem Movie Points use case are clearly ...
Similar publications
This study summarizes the available information on the technical characteristics and costs of those sulphur abatement technol¬ogies in operation at present or coming into operation in the near future. Relying on disaggregated source data and using engineering cost functions and various technical and economic assumptions, the least cost curves of su...
Thermophoretic deposition is an important technique for particle removal. The thermophoretic force of the particles under an appropriate temperature gradient can achieve a good particle removal effect. At present, there have been many studies on the deposition mechanism of ultrafine particles under the action of thermophoresis. In this chapter, the...
This chapter summarizes the common-coil dipole research and development program at the Brookhaven National Laboratory (BNL). The program goals included: (a) the development of accelerator-quality dipoles based on the common-coil design concept; (b) the demonstration of “react-and-wind” technology for high field collider dipole magnets; and (c) the...
In recent years, nonparametric predictive inference (NPI) has been developed as a frequentist statistical framework which requires only few modelling assumptions and considers one or more future observations instead of a population. NPI uses lower and upper probabilities for uncertainty quantication, and has strong consistency properties within the...
This MD note summarizes the actions carried out during the MD 2485 on Active halo control using narrowband and colored noise excitations. The goal of the MD was to repeat some promising cases already tested in the past and introduce a new excitation type based on applying a colored noise. Although we were able to repeat some cases using a narrowban...
Citations
... Another interesting contribution is the work presented in [16], which proposes to use the Aspect Oriented User Requirement Notation (AoURN) [22] at the requirement analysis phase of SPL life cycle. AoURN is a modeling and reasoning framework that combines goal-oriented, scenario-based, and aspect-oriented techniques for requirements engineering. ...
Multi-agent systems have proved to be a suitable technology for developing self-adaptive Internet of Things (IoT) systems, able to make the most appropriate decisions to address unexpected situations. This leads to new opportunities to use multi-agent technologies to develop all kinds of cyber–physical systems, which usually encompass a high diversity of devices (e.g., new home appliances). The heterogeneity of devices and the high diversity of the available technology, demand the explicit modeling of all kinds of variability for ultra-large systems. However, multi-agent systems lack mechanisms to effectively deal with the different degrees of variability present in these kinds of systems. Software Product Line (SPL) technologies, including variability models, have been successfully applied to different domains to explicitly model variability in hardware, system requirements or user-intended goals. In addition, current market trends are unpredictable, imposing novel technologies, new requirements and goals that must be incorporated immediately into the running systems without damaging them. In this paper, we combine goal-driven and SPL approaches to develop and drive the evolution of multi-agent systems in the context of cyber–physical systems. We propose an SPL process and an evolution process that define a set of models (iStar 2.0 for goals and CVL models for variability) and algorithms to automatically propagate changes to agents running in multiple heterogeneous devices, each of them with a different configuration. We illustrate the proposal in the context of a home energy management system. Finally, we have tested the scalability and performance of the proposal using randomly generated models. The results show that with our approach it is possible to manage huge iStar models of 10000 elements in seconds.
... In this section, we introduce the AoUCM features and modeling elements that are relevant to our proposed availability extensions. For a complete description of the Aspect-oriented Use Case Maps language, interested readers are referred to [11][12][13][14]. AoUCM builds on the UCM language. ...
... Aspect-oriented UCM (AoUCM) [11][12][13][14] adds three core aspect-oriented concepts concerns, composition rules, and pointcut expressions to UCM. A concern is a new unit of encapsulation that captures everything related to a particular idea, e.g., availability. ...
Non-functional requirements such as availability, reliability, and security are often crucial in designing and implementing distributed real-time systems. As a result, such non-functional requirements should be addressed as early as possible in the system development life-cycle. The widespread interest in dependability modeling and analysis techniques at the requirements elicitation and analysis stage provides the major motivation for this research. This paper presents a novel approach to describe high-level availability requirements using the Aspect-oriented Use Case Maps (AoUCM) language. AoUCM adds aspects-oriented concepts to the Use Case Maps (UCM) language, part of the ITU-T User Requirements Notation (URN) standard. The proposed approach relies on a mapping of availability architectural tactics to reusable AoUCM models, allowing availability tactics to be encapsulated early in the software development life-cylce. Initial tool support for the resulting availability extensions, is provided by the jUCMNav tool. We demonstrate the applicability of our approach using a case study of Lawful Intercept (LI), an IP router feature.
... We are planning to model the entire bCMS using CDD, including non-functional requirements, design variations, and communication protocol. Although the focus of our work is at design phase, we model the requirement-level concerns using AoURN [13]. AoURN is a notation that uses the use case maps, allowing the modeller to capture the interaction scenarios that a system supports as well as the impact these scenarios have on high level goals. ...
Model Driven Engineering (MDE) has achieved success in many areas of software development. However, despite its success, MDE faces some key challenges in practice. One of these challenges is model reuse. Modellers usually build models from scratch instead of reusing existing models. This makes modelling a more difficult task than coding, since modern programming languages provide libraries facilitating code reuse. This paper presents concern-driven software development - a new development process that focuses on concerns as primary artifacts. A concern groups related models serving the same purpose, and provides interfaces to facilitate reuse. We discuss the vision of concern driven development and discuss how concerns can be modelled at the design phase. We also discuss how we plan to address the challenge of model reuse in concern-driven development, by using concern libraries and tool support.
... The Aspect-oriented User Requirements Notation (AoURN) (Mussbacher et al. 2010a;Mussbacher and Amyot 2009;Mussbacher 2010) extends URN with aspect-oriented concepts, allowing modelers to better encapsulate crosscutting concerns that are hard or impossible to encapsulate with URN models alone. AoURN adds aspect concepts to URN's sublanguages, leading to and integrating Aspect-oriented GRL (AoGRL) and Aspect-oriented UCM (AoUCM). ...
Software Product Line Engineering concerns itself with domain engineering and application engineering. During domain engineering, the whole product family is modeled with a preferred flavor of feature models and additional models as required (e. g., domain models or scenario-based models). During application engineering, the focus shifts toward a single family member and the configuration of the member's features. Recently, aspectual concepts have been employed to better encapsulate individual features of a Software Product Line (SPL), but the existing body of SPL work does not include a unified reasoning framework that integrates aspect-oriented feature description artifacts with the capability to reason about stakeholders' goals while taking feature interactions into consideration. Goal-oriented SPL approaches have been proposed, but do not provide analysis capabilities that help modelers meet the needs of the numerous stakeholders involved in an SPL while at the same time considering feature interactions. We present an aspect-oriented SPL approach for the requirements phase that allows modelers (a) to capture features, goals, and scenarios in a unified framework and (b) to reason about stakeholders' needs and perform trade-off analyses while considering undesirable interactions that are not obvious from the feature model. The approach is based on the Aspect-oriented User Requirements Notation (AoURN) and helps identify, prioritize, and choose products based on analysis results provided by AoURN editor and analysis tools. We apply the AoURN-based SPL framework to the Via Verde SPL to demonstrate the feasibility of this approach through the selection of a Via Verde product configuration that satisfies stakeholders' needs and results in a high-level, scenario-based specification that is free from undesirable feature interactions.
... Such concepts do not exist in conventional use case notations. Aspect-oriented User Requirements Notation (AoURN) [12] extends the conventional use case modelling technique to enable localizing of aspects. The primary goal of AoURN is to model any functional or non-functional concern of the system under development that can be expressed with scenarios.Fig. 2 depicts the AoURN scenario model for the Authentication concern. ...
The last decade has seen the development of diverse aspect-oriented modeling (AOM) approaches. This paper presents eight different AOM approaches that produce models at different level of abstraction. The approaches are different with respect to the phases
of the development lifecycle they target, and the support they provide for model composition and verification. The approaches are illustrated by models of the same concern from a case study to enable comparing of their expressive means. Understanding
common elements and differences of approaches clarifies the role of aspect-orientation in the software development process.
... We propose an aspect-oriented approach encompassing general purpose requirements models and business process design models as a first step towards a larger, iterative, end-to-end concern– driven software engineering process that ensures the encapsulation of (crosscutting) concerns through all software development phases. We implement this vision with a tool-supported, automatic transformation of aspect-oriented requirements models expressed with the Aspect-oriented User Requirements Notation (AoURN) [15] into aspect-oriented business process models expressed with Adore [11]. Sect. 2 introduces AoURN, Adore, and the PicWeb case study which will be used to demonstrate the feasibility of our proposed approach throughout this paper. ...
... The Aspect-oriented User Requirements Notation (Ao- URN) [7, 15, 16] supports the elicitation, analysis, specification , and validation of requirements in an aspect-oriented modeling framework for early requirements with the help of goal and scenario models. AoURN's scenario models are defined with Aspect-oriented Use Case Maps (AoUCM) and consist of a path that begins at a start point ( , e.g., get pictures inFig. 1 ) and ends with an end point ( , e.g., displayed ). ...
... As AoURN uses standard URN diagrams to describe pointcut expressions and composition rules, it is only limited by the expressive power of URN itself as opposed to a particular composition language. For more information about AoURN's matching and composition algorithms , the interested reader is referred to [15, 16]. Finally, aspects may depend on or conflict with each other. ...
Aspect-oriented approaches are available for various phases of software development such as requirements, design, and implementation. Yet, moving from one phase to the next with aspects remains a challenge seldom studied. In this paper, we present an iterative, concern-driven software en- gineering approach that is based on a tool-supported, semi- automatic transformation of scenario-based, aspect-oriented requirements models into aspect-oriented business process design models. This approach is realized by a mapping from Aspect-oriented Use Case Maps (AoUCM) to Adore busi- ness process models, allowing for the continued encapsula- tion of requirements-level concerns in design-level artifacts. Problems detected during the design phase can be rectified in the requirements models via several feedback loops that support iterative model development. We discuss the trans- formation process and illustrate, as proof-of-concept, our contribution on the PicWeb case study, a SOA–based imple- mentation of business processes for pictures management.
... We propose an aspect-oriented approach encompassing general purpose requirements models and business process design models as a first step towards a larger, iterative, end-to-end concerndriven software engineering process that ensures the encapsulation of (crosscutting) concerns through all software development phases. We implement this vision with a tool-supported, automatic transformation of aspect-oriented requirements models expressed with the Aspect-oriented User Requirements Notation (AoURN) [15] into aspect-oriented business process models expressed with Adore [11]. Sect. 2 introduces AoURN, Adore, and the PicWeb case study which will be used to demonstrate the feasibility of our proposed approach throughout this paper. ...
... The Aspect-oriented User Requirements Notation (Ao-URN) [7,15,16] supports the elicitation, analysis, specification, and validation of requirements in an aspect-oriented modeling framework for early requirements with the help of goal and scenario models. AoURN's scenario models are defined with Aspect-oriented Use Case Maps (AoUCM) and consist of a path that begins at a start point ( , e.g., get pictures in Fig. 1) and ends with an end point ( , e.g., displayed). ...
... As AoURN uses standard URN diagrams to describe pointcut expressions and composition rules, it is only limited by the expressive power of URN itself as opposed to a particular composition language. For more information about AoURN's matching and composition algorithms, the interested reader is referred to [15,16]. ...
Aspect-oriented approaches are available for various phases of software development such as requirements analysis, design, and implementation. Yet, moving from one phase to the next with aspects remains a challenge seldom studied. In this paper, we present an iterative, concern-driven software engineering approachbased on a tool-supported, semi-automatic transformation of scenario-based, aspect-oriented requirements models into aspect-oriented business process design models. This approach is realized by a mapping from Aspect-oriented Use Case Maps (AoUCM) to Adore business process models, allowing for the continued encapsulation of requirements-level concerns in design-level artifacts. Problems detected during the design phase can be rectified in the requirements models via several feedback loops that support iterative model development. We discuss the transformation process and illustrate, as proof-of-concept, our contribution on the PicWeb case study, a SOA-based implementation of business processes for pictures management.
... Aspect-oriented User Requirements Notation (AoURN) [12] supports conventional concepts of use case and workflow modelling techniques but also enables localizing of aspects. The primary goal of AoURN is to model any functional or non-functional concern of the system under development that can be expressed with scenarios. ...
Model-driven software engineering community faces the problems related to the growing complexity of system models and their rapid evolution. These problems are similar to the problems of programming. Driven by the ideas of Aspect-Oriented Programming many modelling techniques were revised in attempts to find their ways to deal with model complexity and evolution. This paper presents an analysis of existing semantic groups of modelling approaches, their goals, pros and cons, advantages and restrictions. It is aimed to show the deep reason of the fact that particular composition semantics combined with the elegant idea of aspect weaving leads to heavy verification procedures after any change in the AOM model. This analysis reveals the elements of modelling semantics that simplify the verification procedures in AOM.
... We present a taxonomy of pattern matching techniques that can be used to i) assess and classify existing AOM techniques and ii) guide future research initiatives. Wherever possible, we demonstrate already existing and future pattern matching techniques with the help of the Aspect-oriented User Requirements Notation (AoURN) [16], an aspect-oriented requirements modeling technique based on ITU-T Recommendation Z.151 [1,11]. The taxonomy is meant to name and categorize various pattern matching techniques, so that language designers can i) become aware of their existence, ii) name them, and iii) assess, compare, and potentially complete pattern matching mechanisms in an aspect-oriented modeling language. ...
... AoURN [16] unifies goal-oriented, scenario-based, and aspect-oriented modeling in one framework to support the elicitation, specification, analysis, and validation of requirements. AoURN extends ITU-T's User Requirements Notation with aspect concepts for its two sublanguages, namely the Goal-oriented Requirement Language (GRL) and Use Case Maps (UCM). ...
Aspect-oriented modeling (AOM) techniques have become increasingly popular over the last decade, as they enable improved modularity,
separation of concerns, and reusability over conventional requirements and design modeling techniques. However, AOM notations
typically employ pointcut matching mechanisms based solely on syntactic elements. In order to make aspects more generic and more robust to changes and to different modeling styles, semantic matching must be better exploited. We present a taxonomy that aims to classify matching mechanisms based on how syntactic
or semantic information is used during the matching process, thus defining levels of sophistication for matching mechanisms
from simple syntactic approaches to complex semantic approaches. We are particularly investigating how schema matching techniques
developed in the database research community are applicable in this context. We illustrate the feasibility and potential benefits
through examples based on the Aspect-oriented User Requirements Notation (AoURN).
... In this paper, we leverage principles of Aspect-oriented Modeling (AOM)[7]to address this issue. AOM has been successfully applied for the encapsulation of crosscutting concerns in several requirement formalisms like use cases[12], problem frames[16], URN[18], and UML models[21]. By applying these principles, we therefore aim at enabling better understandability, maintainability, and scalability of feature models. ...
Software Product Lines (SPLs) have emerged as a promi- nent approach for software reuse. SPLs are sets of soft- ware systems called families that are usually developed as a whole and share many common features. Feature mod- els are most typically used as a means for capturing com- monality and managing variability of the family. A partic- ular product from the family is congured by selecting the desired features of that product. Typically, feature mod- els are considered monolithic entities that do not support modularization well. As industrial feature models tend to be large, their modularization has become an important re- search topic lately. However, existing modularization ap- proaches do not support modularization of crosscutting con- cerns. In this position paper, we introduce Aspect-oriented Feature Models (AoFM) and argue that using aspect-oriented techniques improves the manageability and reduces the main- tainability eort of feature models. Particularly, we advo- cate an asymmetric approach that allows for the modular- ization of basic and crosscutting concerns in feature models.
