Modeling Interdependent Concern Behavior Using Extended Activity Models.

Abstract

Software engineering considers many assets relevant for developing a software system, ranging from requirements to source code. In this context, a concern is a particular goal, concept, or area of interest that needs to be considered throughout a number of these assets. Even though the concerns in a software system usually have many interdependencies among each other, specifying the interdependent behavior of concerns is not a focus of today's (concern) modeling approaches. In this paper, we present an approach to model interdependent concern behavior using extended UML2 activity models. Within these concern activity models, we directly support the separation of interdependent concerns. In addition, we provide bindings of the concern activity models to UML class and interaction models to enable a detailed specification of concern behavior.

An approach for the systematic development of domain‐specific languages

“…To enable a thorough definition of DSL-to-platform-transformations, we thus need to map our DSL artifacts (including the behavior definition) to the functions provided by xoRBAC. Figure 16 shows an excerpt of Figure 13 that includes concernSpec stereotypes for the ConcernStart nodes of the Role and the Permission concerns (see also [66]). In particular, these concernSpecs define that the behavior of the corresponding concerns is implemented through the Role and Permission classes of xoRBAC, respectively.…”

“…Moreover, for the RBAC DSL it is not sufficient to simply transform a certain XML-based DSL expression to a corresponding executable model element of the xoRBAC platform. Instead, the transformations, or, to be more precise, the generator applying the transformations, must have a certain knowledge of the RBAC domain to produce executable models that conform to the semantics specified for the DSL (see also [64,65,66]). For the above reasons, we decided to implement a generator component which reads the concrete syntax of our RBAC DSL and produces conforming executable xoRBAC models.…”

“…For the RBAC DSL, we especially used extended UML activity diagrams (see [66]) to model DSL behavior and the interaction of different concerns in the DSL. In a subsequent step, these activity models are further refined through UML interaction diagrams.…”

The aspect-oriented user requirements notation

“…Zdun and Strembeck [140] [162] extend UML activity diagrams with nodes for start and end points of concerns to model interdependent concern behaviors and to visualize concerns in a composed system with the help of concern-specific swimlanes. Another approach to aspect-oriented modehng of activity diagrams is described by Zhang et al [164], who define aspectual properties and pointcut expressions in separate models.…”