Incremental Software Design Modelling

Download PDF
0 downloads 0 Views 663KB Size Report
Comment
provide additional, alternative or complementary properties to ... also called a use case map. An initial ..... different design alternatives provided by the model.
Incremental Software Design Modelling Omar Alam and Jörg Kienzle School of Computer Science, McGill University, Montreal, QC H3A E09, Canada [email protected], [email protected]

Abstract In this paper we investigate how a software designer can build a complex software design model incrementally by exploiting model interfaces and information hiding to encapsulate different design concerns within model increments. Each model increment either extends or customizes the model it is applied to. When using model extension, each increment adds modelling elements to the existing model to provide additional structure and behaviour. When using model customization, each increment adds modelling elements to adapt the general structure and behaviour of the model to a specific need. We discuss how incremental modelling fits with software development processes, and show how different model composition techniques, i.e. class merge, subclassing, operation inlining and advising, support the incremental extension and customization of models. Finally, we explain how to generate the complete software design in the end. Practically, we present how we extended the Reusable Aspect Models (RAM) approach to support incremental modelling and show details of an incremental design of a workflow middleware product line.

1

Introduction

In practice, software design modelling faces one important challenge: scalability. Models of complex real-world applications tend to grow in size, to a point where the design models are not readily created, understood or analyzed anymore. Fortunately, model transformation languages and tools have matured, and as a result it has become easy to manipulate models in an automated way. In particular, c Copyright �2013 Omar Alam and Jörg Kienzle. Permission to copy is hereby granted provided the original copyright notice is reproduced in copies made.

model transformations can be used to combine several smaller models to yield a bigger model. Such an approach has the potential to decrease design complexity for the modeller: if the model composition capabilities of the modelling language are such that they fully support separation of concerns, the designer can focus on each concern separately and express the design in small, concise models, and later on focus on concern interactions and dependencies when specifying how the concerns are to be composed. This paper investigates how incremental software design modelling is done: we discuss different ways of approaching incremental software design from a process point of view and describe how model increments are generally of two different natures, namely customizations and extensions. The paper provides insight about how to model complex systems incrementally using existing compositional modelling techniques. To demonstrate the practicality of modelling with increments, we discuss how to create incremental software designs of considerable size with the Reusable Aspect Models (RAM) [9, 10] approach . The ideas presented in the paper are a result of investigating incremental software designs for more than 3 years, working on several large systems: the AspectOPTIMA transaction middleware [11] (37 features/increments), two crisis management systems (23 and 31 features/increments) [12] and the workflow middleware (6 features/increments) [2]. Some of the final woven models contain more than 500 classes. The simplified models shown in the paper are aimed at concisely illustrating the approach; the detailed models are provided in [1]. The outline of the paper is as follows. We show how standard and aspect-oriented model composition techniques can be used to combine a hierarchy of small models to create a complex software design model in Section 2. These ideas are then

illustrated by presenting the incremental design of a product line of workflow execution middlewares in Section 3. Section 4 explains how we extended the Reusable Aspect Models to support incremental modelling, and the composition techniques our approach is based on. Section 5 discusses some insights on the importance of incremental modelling. Section 6 mentions related work and the last section draws some conclusions.

2

What is Incremental Modelling?

To address the problem of scalability, incremental modelling proposes to build large software design models specifying complex structure and/or behaviour by incrementally putting together models of smaller size. In the context of incremental modelling, models are named base models if they are self-contained, i.e. they can fulfill their purpose as is, whereas so-called model increments have to be applied to some base model to fulfill their purpose. Therefore, by its nature, model composition in the context of incremental modelling is asymmetric, i.e., we obtain an incremented model by composing a base model with a model increment.

2.1

Incremental Modelling and the Software Design Process

Incremental modelling integrates very well with modern software design processes such as prototyping, iterative methodologies or the Unified Process [16]. These methodologies design and implement an application in phases. First, a simple version of the application is developed that only provides core functionality and services. Detailed and additional functionalities are added in subsequent iterations. Vertical Decomposition of Design: Within each iteration, software design typically follows a topdown and/or bottom-up strategy, depending on whether the focus is to first elaborate high-level abstractions and functionality, or rather to initially flesh out certain important low-level details of parts of the design. For instance, if detailed functional requirements for the software under development have been elaborated, the initial design phase might begin with deciding on a high-level architecture for the system, and how the required functionality is

to be decomposed into subfunctionalities and allocated to different components. On the other hand, if a certain subfunctionality is crucial to the functioning of the software under development, or if reusing an existing software artifact such as a middleware is mandatory or highly cost-effective, then low-level details of a specific required functionality might be designed first in order to determine if the design is actually feasible. To enable such top-down or bottom-up design, abstraction and information hiding are key to tame the inherent complexity of a system [22, 23]. Information hiding is the activity of consciously deciding what parts of a software module should be exposed to the outside, i.e., the “rest” of the software under development, and what parts should be hidden from external use. To allow a modeller to state what is internal and what is external to a model, the modelling language must provide constructs to define a model’s interface. The interface of a software design model describes an abstraction of the actual model. Only the structural and behavioural properties that are relevant to use the model and its provided functionality are shown in the interface. The design details pertaining to how this functionality is provided are not relevant to the user. Horizontal Decomposition of Design: When transitioning from one iteration of the software design to the next, it is typical to consider additional functionality. As a result, the core parts of the existing design are complemented with additional functionality, or new components are introduced that take care of providing the additional functionality and the existing design is adapted to integrate the new components. To make incremental modelling useful in this context, the modelling language and composition techniques used to combine models needs to support adaptation and extension of existing model interfaces. Feature-Oriented Decomposition of Design: Finally, incremental modelling also integrates well with software product line (SPL) engineering, a software development methodology in which a family of applications is developed that share common functionality. In SPLs it is common practice to specify the variability in terms of features that an application might have separately from the associated artifacts that provide implementations of the features. If incremental modelling is applied in an SPL context, mandatory features would be designed in base models, whereas optional features

would be designed in model increments. To obtain a software design model for a specific application (commonly called product in SPL terms), the base models would be composed with all the model increments that correspond to the selected features for the product.

2.2

Properties of Design Model Increments

In this subsection we comment on properties that, according to our experience, a good design model increment should have. Size: Each individual model increment should be small, as it has been shown in psychological studies that the active working memory of a human is limited [17]. When an individual undertakes a mental task (e.g. attempting to analyze a model or answer questions about a model) that exceeds their working memory capacity, errors are likely to occur [28]. Examining or building a model of a system induces a certain mental effort on the modeller, which corresponds to the amount of working memory a certain task utilizes [21]. This value depends on model-specific factors, one of which is model size. Completeness: What is even more important than size though is coherent modularization. Each model increment specifies a logical step towards the final model, and therefore needs to contain all the structural and/or behavioural elements pertaining to that logical step. This is important for two reasons: • Internal Consistency: Having all model elements pertaining to a logical increment in one place is useful for reasoning about the increment itself. It also simplifies making coherent changes to the structure and/or behaviour modelled by the increment. • Consistent Use: Since the model contains all relevant model elements of the logical increment step, the result that is obtained when applying the increment to the self-contained base model is also self-contained. Kind/Type of Increment: Because of the way incremental modelling is used within the software design process, there are essentially two kind of model increments: model extensions and model customizations.

When using extension increments, the modeller’s intent is to add additional structural and/or behavioural model elements to the base model that provide additional, alternative or complementary properties to what already exists in the base model. The extension increment augments the interface of the base model with additional structure and behaviour. In a sense, an extension increment specifies a horizontal model transformation that maintains the level of abstraction of the base model. The incremented model can still fulfill the same purpose as the base model did, and can be used for additional purposes that are introduced as a result of the extension as well. Consequently, the model elements exposed in the interface of the incremented model can stem from both the base and the incremented model. Regardless of where they stem from, all the model elements in the interface are equally relevant to the outside. A customization increment is useful when a modeller’s intent is to adapt the structure and behaviour provided by a base model to be useful in a specific context. Within a customization increment, a modeller alters or augments existing base model properties to render them useful for a new purpose. In a sense, a customization increment specifies a vertical model transformation that produces an incremented model that is at a different level of abstraction than the base model. The incremented model fulfills a new purpose, where part of the structure and/or behaviour is provided by the customized base model elements. The model interface of the incremented model exposes only elements produced as a result of customization. These model elements and properties can stem from the model increment or from the base that is altered/augmented by the increment. The fact that the incremented model is based on the base model, and details of the design of the base, are hidden to the outside.

3

Incremental Design of Workflow Middleware

a

To illustrate the ideas described in Section 2, this section describes how we incrementally elaborated a design model of a product line of workflow execution engines. A workflow is a depiction of a set of operations that need to be completed in a certain order to fulfill a goal or task. For exam-

ple, workflows have been used in software development to describe how a system under development is supposed to interact with its environment. A well-known modelling formalism that can be used to describe general workflows is UML Activity Diagrams [19]. Another example is the User Requirements Notation (URN) [8], a visual language standardized by the International Telecommunications Union (ITU) intended for modelling interaction scenarios between a system under development and its environment. In [2] we have presented an initial aspectoriented design of a workflow execution engine that provides the user with the functionality to define URN workflows and execute them. In this section we show how we redesigned that workflow middleware following the guidelines of incremental modelling presented in the previous sections.

3.1

Incremental Modelling Process for Workflow Middleware

The requirements for our workflow middleware were clear: all the workflow constructs defined in the URN standard must be supported. That way, our workflow engine would be able to execute any workflow defined within a URN scenario model, also called a use case map. An initial top-down decomposition of the design was suggested by the URN standard, as the language defines many different workflow nodes, such as start and end nodes, conditional nodes, timers, synchronization nodes, etc. However, it quickly became apparent that this decomposition would not yield complete/self-contained models. After careful analysis we grouped all essential structure and behaviour necessary for defining and executing the most basic workflows within a base model that we named WorkFlow. It contains the structure and behaviour necessary for supporting start nodes, activities and end nodes, sequential composition, as well as execution infrastructure implementing token-passing semantics for these base constructs. We then designed the more sophisticated workflow constructs of URN as extension increments of Workflow: ParallelExecution (and-fork in URN terms), ConditionalExecution (or-fork in URN terms), Synchronization (andjoin in URN terms), ConditionalSynchronization, TimedSynchronization, and Nesting. Some URN constructs, for example the or-join, did not exhibit

any behaviour not already covered by Workflow, and therefore did not need to be modelled at all. The left-hand side of Figure 1 shows the featureoriented view of the workflow middleware SPL, which specifies that all workflow middlewares are based on the design Workflow, and optionally can be configured with any of the 6 extensions. When elaborating the internal design of each model, we used a bottom-up approach: whenever possible, we tried to reuse already existing design models that we had created for other designs in the past. These reuse dependencies are shown on the right hand side of Figure 1. The dashed arrows show customization dependencies and the solid arrows show the extension dependencies. We were able to customize the design of the singleton design pattern (Singleton), copying functionality (Copyable), naming functionality (Named), counting functionality (KeyCounter), as well as common data structures such as Lists (ZeroToMany), and hash tables (Map). We also discovered that both synchronization and nesting nodes(which are the workflow nodes that are used in URN to represent entire subworkflows within a workflow), share a common property: both nodes need to be able to handle multiple incoming paths. We therefore encapsulated the structure and behaviour needed to support multiple incoming paths in a model increment named Inpath, which both Synchronization and Nesting extend. Likewise, or-forks, and-forks, timers and stubs are all URN workflow nodes that have more than one outgoing path. We designed a model increment Outpath to provide this functionality, and made ConditionalExecution, ParallelExecution, TimedSynchronization and Nesting extend it further.

3.2

Properties of the Model Increments of the Workflow SPL

Size: The sizes of the model increments in the workflow SPL design are small. The biggest model increment is the Workflow model with 10 classes and 11 public operations, the smallest models are Copyable and Named with 1 class and 2 public operations. This remains within the cognitive capacity of a modeller according to [21]. Completeness: All the model increments include all the structural and/or behavioural elements needed to define workflows with the desired functionality and to execute the workflow with the cor-

Workflow

TimedSynchronization

Conditional Execution

Conditional Synchronization

Parallel Execution Synchronization

Legend extension increment customization increment

ConditionalSynchronization Nesting

Synchronization

Timed Synchronization

Inpath

Nesting

ParallelExecution

ConditionalExecution

Outpath Workflow

Legend or choice

KeyCounter

Copyable

ZeroToMany

Named

Map

Stack

Singleton

Figure 1: Feature View (left) and Model Increments (Right) of the Workflow Design rect semantics. Kind of Increment: The layout of the dependency graph shown in the right hand side of Figure 1 is such that all dependencies that reach below Workflow represent customization increments (i.e., the interfaces of the base models are hidden). The Workflow model and the models above serve a specific purpose, and internally used more general design models by customizing them to their needs. All models above Workflow represent extension increments (i.e. they all extend the interface provided by Workflow). They all are useful for workflow specification and execution, and simply provide different variants of workflow constructs.

4

Incremental Software Design Modelling

This section illustrates how incremental software design modelling can be done. We briefly describe our own modelling technique called Reusable Aspect Models (RAM) [10], which allows a modeller to specify the structural and behavioural properties of software designs using class and sequence diagrams and encapsulate the design behind a welldefined model interface. We then explain how we explored the possibility of incremental modelling in RAM. We first show how incremental modelling is possible in the context of RAM using model transformation and composition techniques such as inheritance and class merge for structural design modelling, and overriding and advising for behavioural design modelling. Then, we show how we extended RAM to support extension and customization increments, and outline the result-

ing composition algorithm for structural and behavioural views. All presented concepts are illustrated with example models from the workflow SPL case study.

4.1

Background on Reusable Aspect Models

Aspect-orientation modelling (AOM) is a modelling paradigm that has been successfully used to identify and modularize crosscutting concerns within software models. AOM also draws special attention to the composition of concerns, which allows the modeller to focus on the intricacies of concern interactions and conflicts. Since increments are special kinds of concerns, it is natural to use AOM techniques as a tool to enable incremental model composition. In [14, 10] we proposed RAM, an aspectoriented multi-view modelling approach that describes the structure and behaviour of a software design concern using class diagrams, sequence diagrams and state diagrams. For space reasons, the RAM design models presented in this paper are smaller than the real ones: the class diagrams are slightly simplified, only some sequence diagrams and no state diagrams are presented. The full models of the workflow middleware design can be downloaded from [1]. Figure 2 depicts the RAM model of our base model Workflow, which defines the essential model elements for any kind of workflow execution middleware. The structural view shows that a workflow is composed of WorkflowNodes, which can be sequence or control flow nodes. StartNode and |CustomizableNode are sequence nodes,

aspect Workflow depends on ZeroToMany structural view

|CustomizableNode |execute

Thread next 0..1 next 0..1

WorkflowExecutor   ~ spawnExecution (StartupNode start) + scheduleNextNode(WorkflowNode n) - setNext(WorkflowNode next) + run()

SequenceNode

ControlFlowNode

+ depositToken() + addNextNode   (WorkFlowNode n)

WorkFlow   - Set getNodes() + addStartupNode(StartupNode n) - Set getStartupNodes() + launch(c) Instantiations: ZeroToMany:

WorkFlowNode + depositToken() + addNextNode(WorkFlowNode n)

StartupNode

+ depositToken() + addNextNode(WorkFlowNode n) + Set chooseNextNodes()

|CustomizableNode

EndNode

+ |execute()

|Data → Workflow; |Associated → WorkflowNode; getAssociated → getNodes; add → addNode

message view SequenceNode.depositToken caller: WorkflowExecutor

WorkflowExecutor

target: SequenceNode

depositToken()

scheduleNextNode(next)

message view launch

caller: Caller

target: Workflow

launch(c)

           startNodes               := getStartupNodes()

WorkflowExecutor

loop [n within startNodes] spawnExecution(n, c)

Message views for scheduleNextNode, spawnExecution, chooseNextNode, depositToken for ControlFlowNode and | CustomizableNode and run have been omitted for space reasons...

Figure 2: The Base Workflow Model the EndNode is a control flow node. The class WorkFlow has methods to add nodes and startup nodes. WorkflowExecutor defines the methods to spawn the execution of a workflow and to schedule the next node in the execution sequence. Figure 2 shows the behaviour of two methods using sequence diagrams: the depositToken method of SequenceNode , and the launch method of Workflow. The most important concepts of RAM that are relevant in the context of incremental modelling are model interfaces and aspect model hierarchies. Every RAM model has a well-defined model interface [9], which makes it possible to group a generic design concern in such a way that it is easy to use within other models. The interface has two parts: the usage interface and the customization interface. The usage interface is comprised of all the public model elements, i.e., the structural and behavioural properties that the classes within the

model expose to the outside. These usable elements are highlighted in the model with a + modifier. The customization interface designates the model elements that are only partially defined, i.e., the generic structural and behavioural elements that need to be adapted or composed with other model elements when a model is used. The names of these customizable elements are prefixed with a |, and they are grouped together in a template parameter box on the top right corner of the aspect model. The customization interface of Workflow , for example, specifies that |CustomizableNode and |execute are a generic class and a generic method, respectively, that need to be customized in order for the model to be useful. RAM allows a modeller to build complex models of any size by putting together many interdependent, simple models. This is achieved through model hierarchies. In RAM, a model C can depend on one or several models Bi , which in turn

can depend on models Ai j , etc. Instantiation directives in the upper model specify how the elements in the lower model have to be combined with the model elements of the higher model. Using these directives, the RAM weaver tool recursively combines all models of the hierarchy following a depthfirst traversal of the dependency tree. The Workflow model shows only one such dependency in the instantiations compartment: it customizes the general ZeroToMany model to link an instance of the class Workflow to many workflow nodes. How this is done technically is explained in the following subsections.

4.2

Structural Increments

Class Merge: RAM provides class merge as a way to share structural model elements between classes. In RAM, if an aspect B wants to define a class ClassB that needs, among others, the properties of a class ClassA defined by some other aspect A, then B can depend on A. In this case, class merge (sometimes also called class diagram composition) is used to merge the model elements in each of the models according to the instantiation directives defined by the modeller. Because of the asymmetry of model increments, the directives are defined in the increment model, and specify how the elements of the base are mapped to elements in the increment. In aspect-oriented terms, the mapping specifies how A is woven into B. Figure 3 shows InPath, an extension increment of Workflow. It provides structure and behaviour to allow control flow nodes to have multiple, named incoming paths. Since InPath extends Workflow, all model elements in InPath that have the same name as model elements in Workflow are automatically merged (see subsection 4.4). Using this mechanism, InPath adds a new method addNextNode to all WorkFlowNodes. Similarly, the WorkflowExecutor is augmented with an association to a InPathNode, which is used to remember through which path a node was reached during execution. InPathNode also customizes |Named, a class provided by the base model Named that provides the structure and behaviour to associate a name in form of a String with a class. The class |Named is merged with InPathNode as specified in the instantiation compartment. In a similar way, InPath also customizes the Map model to map Strings to InPathNodes.

Inheritance: Inheritance, or generalizationspecialization as defined by the UML [19], is a well-known concept of object-orientation that makes it possible to share structural properties among objects. Concretely, common structure is defined in what is called a superclass. Any subclasses that inherit from it also have the same structural properties, and can define additional properties, if needed. In RAM, incremental modelling with inheritance in class diagrams is supported as illustrated in the InPath aspect shown in Figure 3. InPath extends Workflow, and defines a subclass |CFNWithInPaths that inherits from the class ControlFlowNode, which is defined in Workflow. Likewise, a new kind of SequenceNode is defined called InPathNode. Structural Weaving: The model transformation technique our RAM tool uses in order to combine the structural elements of two aspects A and B, regardless of whether they use inheritance or class merge, is based on the class composition technique published by France et al. [25]. In the case where B specifies an instantiation mapping, the mapping is first used to change the names of all model elements in A to the corresponding model elements in B. Then, our tool combines A and B by moving for each pair of model elements (classes, associations, operations, parameters), i.e., (ma, mb) | ma ∈ A ∧ mb ∈ B ∧ ma.name = mb.name all properties attached to ma to mb . The result is a new self-contained model which can therefore be used as a base for further increments.

4.3

Behavioural Increments

Overriding: Operation overriding is an objectoriented technique that is used in the context of inheritance that allows a subclass B1 to replace the behaviour of an operation o provided by a superclass A1 by providing a new definition of o. Often though, since B1 shares structural properties with A1, the behaviour of o for B1 – the overriding operation – needs to include the behaviour defined for o in A1 – the overridden operation. If that is the case, the overriding operation invokes a special operation called super, which results in executing the overridden operation in the superclass. If super is invoked, then the overriding operation can be seen as a behavioural increment of the overridden operation.

aspect InPath extends Workflow depends on Map, Named structural view

|CFNWithInpaths

WorkflowNode

ControlFlowNode

  + addNextNode    (|CFNWithInPaths succ, String inPathname)

|CFNWithInpaths   ~ addInPath(NodeConnection newCon,    String pathName)

SequenceNode InpathNode

WorkflowExecutor

  + InpathNode create(String pathname) + String getName() ~ depositToken(LocalContext c)

Instantiations: Map:                   Named:

0..1 previous

  + InpathNode getPrevious() + setPrevious(InpathNode)

|Data → |CFNWithInpaths; |Key → String; |Value → InpathNode; add → addInpath; getValue → getInpath |Named → InpathNode; getName → getName

message view depositToken WorkflowExecutor

target: InpathNode

caller: WorkflowExecutor depositToken(c)

e := getCurrentExecutor()

e: WorkflowExecutor

setPrevious(target)    super(c)

Figure 3: The Inpath Extension Increment aspect Nesting extends Inpath, Outpath depends on ZeroToMany, … structural view

StartupNode

Binding

- boolean local + StartupNode create    (.., boolean local, ..) ~ boolean isLocal()

1 plugin

Workflow - boolean locallyLaunched    := false  ~ launchLocal(LocalContext c)

WorkflowExecutor   + pushToStubHierarchy    (StubNode s) + StubNode    popFromStubHierarchy()

Nesting

Instantiations: ZeroToMany:             |Data → StubNode; |Associated → Binding

message view Workflow.launch affected by globalSpawning message view globalSpawning caller: Workflow

WorkflowExecut or

Advice caller: Workflow

n: StartupNode local := isLocal()

spawnExecution(n,c)

Pointcut

WorkflowExecutor

opt [not local] spawnExecution(n, c)

Figure 4: The Nesting Extension Increment All workflow nodes in Figure 2 provide the operations addNextNode and depositNode which define shared behaviour. depositNode encapsulates the behaviour of the node within the workflow, and it is triggered by the workflow executor when it traverses the workflow. SequenceNode, |CustomizableNode and ControlFlowNode each provide different behaviour for depositToken. SequenceNode simply schedules the execution of the following node as shown in the depositNode message view in Figure2. Figure 3 shows how the behaviour of operation depositToken in SequenceNode is overridden by the model increment InPath simply by spec-

ifying a new message view for depositToken (with the same signature) as the one that is to be overridden. The behaviour shown specifies that the workflow executor first remembers the inpath node it came from before executing the original behaviour provided by SequenceNode. Advising: Besides overriding, RAM also provides a way for a model increment to specify a modification to the behaviour of an operation provided by a base model. This technique is often referred to as advising. It allows a model increment to define new (partial) behaviour with a sequence diagram, and specify at which point in the base behaviour this new behaviour should be inserted. To

enable advising, sequence diagram weaving technology is used to combine the two behaviours (see below). To illustrate this, Figure 4 presents Nesting, another extension increment of Workflow. Nesting provides the structure and behaviour to allow workflows to be nested. According to the URN specification, nesting has an impact on what is supposed to happen when a workflow is launched. Without nesting, execution should begin concurrently at all startup nodes in the workflow. Nested workflows, however, can specify startup nodes to be local or global. When launching a nested workflow, execution should only begin at the startup nodes marked as global. To realize this change in semantics, Nesting uses advising. The message view globalSpawning defines a pointcut sequence diagram that detects calls to operation spawnExecution on instances of Workflow. The message view then states that for each detected call, it checks whether the StartupNode is local, and calls spawnExecution only if the startup node is not local. After weaving Nesting with Workflow, the message view launch in Workflow will be augmented with the messages found in the advice part of spawnExecution. Behavioural Weaving: The model transformation technique our RAM tool uses in order to combine the behavioural elements of two aspects A and B, regardless of whether they use overriding or advising, is based on the sequence diagram weaving approach published by Klein et al. [13]. In the case where B specifies an instantiation mapping, the mapping is first used to change the names of all model elements in A to the corresponding model elements in B. Then all message views of A are moved to aspect B. Next, we process any advising specified in B. To do that, for each message view oa coming from A that is advised by a message view mb in B, replace the match(es) of the pointcut sequence diagram of mb in the sequence diagram of oa with the advice sequence diagram of mb. Finally, we process standard and overridden operation invocations as follows: for each message view mb in B, replace in the sequence diagram mb any call to operations oa originally specified in A or call to super with the sequence diagram specified in the message view oa that came from A respectively with the message view mb coming from A1 . 1 It should be noted that this last step is optional and should be executed only if the modeller wants to show the details of the called operation behaviour in the message view where the

4.4

RAM Extension to Support Model Increments

To support extension and customization increments in RAM, we introduced two types of dependencies between models: extends and depends on. The type of dependency affects the way the model weaver performs the weaving of the involved models. Extension Increments: Extension increments should use the extends dependency. If a model increment B extends a base model A, no mapping of model elements of A to model elements of B need to be specified by the modeller. All model elements of A are automatically visible in B. It is as if B was part of A, and hence classes in B can access properties of classes in A that are not part of A’s usage interface. In particular, B can use inheritance and overriding to extend the structure and behaviour provided by A. Since B is an extension increment, A is likely to define core design concepts that B wants to provide alternatives for. To do this, B can use classes defined in A as a superclasses for new classes introduced in B to extend the structure. To extend base behaviour with additional functionality, overriding of operations naturally complements inheritance. Exploiting polymorphism, the extensions to A introduced through inheritance in B can collaborate with the other core classes defined in A. Note that in the case where the structure and behaviour provided by A needs to be adapted in order to work correctly with the behaviour introduced by B, the modeller can also additionally use class merge and advising when specifying an extension increment. Of course this means that instantiation directives that map elements of A to elements of B need to be provided. The workflow design example given in Section 4 illustrates such a case. Finally, when the weaver combines an extension increment A with a base model B, it combines the aspect interfaces of A and B by performing a union operation: the interface of the incremented model contains all model elements of A and B and exposes all public operations defined in A and B. As a result, the user of the incremented model is given the alternative to either instantiate core (super) classes provided by A or alternative, extended (sub) classes provided by B. In other words, the user can access behaviour is called.

core functionality provided by A or rely on alternative functionality modelled in B. Customization Increments: Customization increments should use the depends on dependency. When a model increment B customizes a base model A, only the public model elements of A are directly visible in B. To specialize the structure of a class provided by A, B typically defines a new class with additional properties and then uses the instantiation directives to perform class merge between the two. To specialize the behaviour of a class in A, advising is used. This way it is possible for B to define more specialized replacements of classes of A. When the weaver combines a customization increment with a base model, the interface of the incremented model is defined solely by the interface of B. In other words, the visibility of model properties that were part of the interface of A are changed from public to package during the weave process. As a result, the base model is hidden within the customization increment. This is important in the context of top-down / bottom-up design, as a higher-level design model should not expose lower-level design choices. This is in line with the information hiding principle advocated by [22]. In the case where A provides properties that directly correspond to properties that B wants to expose, B has to redefine them as public (optionally changing their name as well to reflect the change in abstraction), and map them explicitly from A to B with corresponding instantiation directives.

4.5

Generating the Complete Design Model

To better illustrate the generation of a complete design model based on many model increments, Figure 5 presents very simplified versions of the structural view of additional model increments of the workflow middleware SPL. A SynchronizationNode as defined in Synchronization is a node that blocks all incoming executors until it has received a token on each incoming path. The instantiation directives show that |CFNWithInPaths from InPath is merged with SynchronizationNode. The behavioural specialization of depositNode is not shown here for space reasons. Some nodes in a workflow are not just connected to one following node. Figure 5 shows an in-

crement OutPath that extends the WorkFlow base model to provide an alternative control flow node that can have multiple outgoing paths. Again, inheritance is used to provide this alternative. ParallelExecution is an increment based on OutPath that defines a control flow node that executes all following nodes in parallel. The ConditionalExecution aspect shows how the designer can increment OutPath in a different way to define another alternative control flow node that represents conditional execution. To make this work, an alternative to OutPathNode called OutPathWithCondition is added to the model with an associated Condition. Given all the model increments, we are now ready to generate a complete software design model. Figure 6 illustrates the power of incremental modelling when combined with a SPL approach. The user of the workflow middleware is presented with a feature model (see left hand side of Figure 1), from which he is to select the desired functionality of the workflow design that is to be generated. The top half of Figure 6 (A) shows the generated design model when the features ConditionalExecution, ParallelExecution, Synchronization and Nesting are chosen by the user. Because we used alternatives in the increments that designed the individual control flow nodes, a user of the middleware can instantiate the subset of the nodes it needs. For example, one work flow instance can be composed of SequenceNode, EndNode, ConditionalExecutionNode and OutPathNode only, whereas another work flow instance can use a different subset, e.g. SequenceNode, EndNode, SynchronizationNode and InPathNode. However, if all workflows that the workflow middleware needs to support do not use one kind of node, then a new design model can be generated by selecting only the required features. Figure 6 (B) illustrates a generated design model in which only the ConditionalExecution feature was selected, and hence only the ConditionalExecution increment (and indirectly also OutPath) were composed with Workflow.

5

Discussion

We believe that incorporating the properties discussed in Section 2.2and defining model composition operators would help a potential modelling

aspect OutPath extends WorkFlow SequenceNode

|CFNWithOutPath

aspect Synchronization extends InPath SynchronizationNode

ControlFlowNode

OutPathNode

|CFNWithOutPath

String pathName

+ WorkFlowNode    findNextNode(String outPathname)

+ Set chooseNextNodes()

Instantiations: InPath:

|CFNWithInPath → SynchronizationNode

aspect ConditionalExecution extends OutPath aspect ParallelExecution extends OutPath ParallelExecutionNode + Set chooseNextNodes()

Instantiations: OutPath:

ConditionalExecutionNode + Set    chooseNextNodes()

Condition |CFNWithOutPath → ParallelExecutionNode Instantiations: OutPath:

myConditon 0..1

OutPathNode OutPathNodeWith Condition + setCondition(Condition c)

|CFNWithOutPath → ConditionalExecutionNode OutPathNode → OutPathNode

Figure 5: Synchronization, OutPath, Parallel- and ConditionalExecution approach to enable support for incremental modelling. We intend to apply the ideas presented in this paper in other modelling approaches to validate this claim. We showed in this paper how existing compositional techniques (inheritance, class merge, overriding and advising) can be used to support incremental modelling in RAM. In addition to addressing scalability, our approach reduces the modelling complexity and cognitive load for the designer. The most significant reduction of modelling complexity is obtained when using customization increments, because customization creates layers of abstraction. A designer is only required to know about the public interface of the customized base model. Extension increments require the modeller to know about the base model. However, our approach still reduces the cognitive load, since the modeller typically does not need to understand all the other extension increments that fork from the base. For example, if A extends a base model M, and the modeller wants to introduce another extension of M called B, the modeller does not need to worry about A, unless there is a feature interaction between A and B (our approach supports conflict resolution models, but this is out of the scope of this paper). It is important to note that conflicts do not happen between a base and extensions, since an extension has access to the base and can change its behaviour. In addition to their role in incremental modelling, the characteristics of extension and customization increments are essential to introduce yet another unit of structuring into software design that, based on our experience, can be used to fur-

ther reduce the design complexity. We call this additional unit of design structuring a concern [3]. A concern groups related models together, i.e., models that reside at the same conceptual level of abstraction. This is typically what happens when extension increments are used. Extension increments are created to extend functionality provided by a base with additional, related functionality, or for introducing alternative functionality that serves the same or a similar purpose. From a reuse perspective, it makes sense to group these models within a concern, so that when a modeller needs a certain functionality she has access to all the available models related to that functionality. Ideally, a concern should come with a feature model-like interface that expresses the relationships among the different design alternatives provided by the model extensions. The workflow middleware we presented in Section 3 is a good example of a concern. ConditionalExecution, ParallelExecution, Synchronization, ConditionalSynchronization, TimedSynchronization, Nesting, Inpath and Outpath are all extension increments of the base Workflow model, and hence are all part of the concern. The modeller that wants to use workflows in her design can choose a subset of the features exposed in the feature model attached to the concern (see Figure 1), to produce a woven design model that fits her exact needs as we have seen in Figure 6. In the workflow example, the models KeyCounter, Copyable, ZeroToMany, Named, Map, Stack and Singleton are not part of the workflow concern. They reside at a different level of abstraction, unrelated to the workflow domain. and simply customized by the models that

0..*

WorkFlow

WorkFlowNode

SequenceNode

InPath Node

WorkflowExecutor

ControlFlowNode

OutPath Node

EndNode

Nesting

OutPathNode myCondition WithCondition 0..1 WorkFlow

Thread

0..*

Parallel Execution Node

Conditional Execution Node

Condition

A

WorkFlowNode

SequenceNode

OutPath Node

Synchronization Node

Thread

ControlFlowNode

EndNode

OutPathNode myCondition WithCondition 0..1

B

Workflow Executor

Conditional Execution Node Condition

Figure 6: Two Possible Final Models are part of the Workflow concern in a workflowspecific way.

6

Related Work

To the best of our knowledge, the current stateof-the-art in modelling, and in particular aspectoriented modelling, does not provide adequate support for incremental modelling. The current modelling approaches do not have the properties of model increments discussed in Section 2.2. The RAM approach presented here integrates class diagram weaving as defined by [25] and sequence diagram weaving as defined by [13]. As a result, RAM inherits the strengths of these techniques, such as flexible renaming of structural model elements, and semantic-based behavioural weaving. However, the aforementioned techniques only focus on combining two models, and not on building complex models out of many small model increments. Also, the nature of the increment, i.e. with what intent two models are woven, and how this intent impacts visibility is not considered. The same argument can be made for UML’s package merge [18]. Our work has similarities to the research in model-driven software product lines. In [29] Trujillo et al. introduces feature-oriented model

driven development which uses model transformation techniques to add features to base models (the authors call them constants). Their models are represented using XML and Java code. Their process starts with specifying a platform-independent state chart and then they use a series of transformations to finally obtain executable code. The concept of adding features to constants is similar to extending a base model in our approach. In [26], Schaefer introduces the concept of delta modelling, in which a product is represented by a core model and a set of delta models that incorporate the alternative features to the core. The core is modified when a delta is applied to it. However, the research in SPL does not talk about model interfaces, support for dependency hierarchies, or distinguishes extension and customization increments. Other AOM approaches for software design, such as the Aspect-Oriented Design Model [27], the JAC Design Notation [24], the Theme/UML Approach [5], and the AOSD Profile [7], have not been applied to design complex models with multiple interdependent aspects. It is therefore not clear how such approaches would support incremental modelling. The Motorola WEAVR Approach [6] is used in industry to create executable models of large software designs. Since the approach is based on the Specification and Description Lan-

guage (SDL), the models are quite low-level, and we have not found any evidence that WEAVR supports interfaces and information hiding as required by incremental modelling. The interested reader is referred to [9] for an in-depth comparison between RAM and the aforementioned AOM approaches. At the programming language level, several approaches have been proposed recently that provide concepts that are close to the features that RAM provides for incremental modelling. For instance, package templates [15] are a programming level construct that allow sets of classes and methods to be parameterized together. When a package template is instantiated, a mapping needs to be provided that maps template parameters to concrete Java classes and methods. This mapping also allows to specify class merging and method renaming. The power provided by this mapping is similar to the power provided by the instantiation directives in RAM. We therefore believe that the idea of extension and customization increments can be implemented in package templates. However, since advising is not supported, the customization possibilities of lower-level operations are limited. Similar arguments can be made about Scala [20] or advanced feature-oriented programming languages [4].

7

Conclusion

In this paper we described how to build complex models of significant size by composing models incrementally: we discussed how incremental modelling fits within the software design process, argued that the model formalism needs to support model interfaces and model hierarchies, and presented two different kinds of model increments, extensions and customizations. We also showed how the kind of an increment affects the way visibility is handled by the model composition: in case of extensions, the resulting model interface should be the union of the composed models, whereas for customizations, only the interface of the increment should be visible. We explained how existing compositional techniques can be used to support incremental modelling. We illustrated incremental modelling by explaining how we extending the Reusable Aspect Models approach to support the properties of incremental modelling with class and sequence diagrams. We defined two dependency relationships

for models, extends and depends on. In extension increments, the modeller should use mainly inheritance and overriding to provide alternative structure and behaviour. Customization increments should use depends on, which instructs the model composition to hide the interface of the base model. The modeller typically uses class merge and advising to customize the structure and behaviour of the base elements. As a result, the customized model elements specified in the increment replace the generic elements provided by the base. In the future, we would like to explore how other modelling approaches can be extended to support incremental modelling. All of the above was illustrated by presenting the incremental design of a workflow middleware SPL. A base Workflow aspect that only allows to define sequential workflows is extended with increments that provide more elaborate control flow structures, i.e., conditional execution, parallel execution, synchronization, and nested workflows. A feature-oriented view allows a user to generate a complete software design model of a customized workflow execution middleware simply by selecting the desired features.

8

About the Authors

Omar Alam is a PhD student at the School of Computer Science, McGill University. His broad area of interest is software engineering. His current interests include Model-Driven Software Engineering, Aspect Oriented Software Development Process, Aspect-Oriented Modelling, and Concern-Driven Software Development. Jörg Kienzle is an associate professor at the School of Computer Science of McGill University in Montreal, Canada, where he is leading the Software Engineering Laboratory. He holds a Ph.D. from the Swiss Federal Institute of Technology in Lausanne (EPFL). His current research interests include model-driven software development, aspectorientation, and software fault tolerance.

References [1] Workflow middleware design, http://www.cs.mcgill.ca/˜joerg/ wf_ram_models.pdf

[2] Alam, O., Kienzle, J.: Designing with inheritance and composition. In: Proceedings of the 3rd international workshop on Variability and Composition. pp. 19–24. VariComp ’12, ACM, New York, NY, USA (2012) [3] Alam, O., Kienzle, J.: Concern-oriented software design. In: Proceedings of the ACM/IEEE 16th International Conference on Model Driven Engineering Languages and Systems. Springer (to be published) [4] Apel, S., Kästner, C.: An overview of featureoriented software development. Journal of Object Technology 8(5), 49–84 (2009)

[13] Klein, J., Hélouet, L., Jézéquel, J.M.: Semantic-based weaving of scenarios. In: AOSD. pp. 27–38. ACM Press (2006) [14] Klein, J., Kienzle, J.: Reusable Aspect Models. In: 11th Aspect-Oriented Modeling Workshop, Nashville, TN, USA, Sept. 30th, 2007 (September 2007) [15] Krogdahl, S., Møller-Pedersen, B., Sørensen, F.: Exploring the use of package templates for flexible re-use of collections of related classes. Journal of Object Technology 8(7), 59–85 (2009)

[5] Clarke, S., Baniassad, E.: Aspect-Oriented Analysis and Design: The Theme Approach. Addison Wesley (2005)

[16] Larman, C.: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process. Prentice Hall, 3nd edn. (2002)

[6] Cottenier, T., Berg, A.V.D., Elrad, T.: The Motoroal WEAVR: Model Weaving in a Large Industrial Context. In: AOSD’06. ACM, Bonn, Germany (2006)

[17] Miller, G.: The magical number seven, plus or minus two: some limits on our capacity for processing information. Psychological review 63(2), 81 (1956)

[7] Elrad, T., Aldawud, O., Bader, A.: Expressing aspects using uml behavioral and structural diagrams. Aspect-Oriented Software Development (2005) [8] International Telecommunication Union (ITU-T): Recommendation Z.151 (11/08): User Requirements Notation (URN) Language Definition (2008) [9] Kienzle, J., Abed, W.A., Fleurey, F., Jézéquel, J.M., Klein, J.: Aspect-Oriented Design with Reusable Aspect Models. Transactions on Aspect-Oriented Software Development 7, 272 – 320 (2010) [10] Kienzle, J., Al Abed, W., Klein, J.: AspectOriented Multi-View Modeling. In: AOSD 2009. pp. 87 – 98. ACM Press (March 2009) [11] Kienzle, J., Duala-Ekoko, E., Gélineau, S.: Aspectoptima: A case study on aspect dependencies and interactions. T. Aspect-Oriented Software Development 5, 187–234 (2009) [12] Kienzle, J., Guelfi, N., Mustafiz, S.: Crisis management systems: A case study for aspect-oriented modeling. T. Aspect-Oriented Software Development 7, 1–22 (2010)

[18] Object Management Group: Unified Modeling Language: Infrastructure (v2.4.1) [19] Object Management Group: Unified Modeling Language: Superstructure (v 2.4.1) [20] Odersky, M., Altherr, P., Cremet, V., Dragos, I., Dubochet, G., Emir, B., McDirmid, S., Micheloud, S., Mihaylov, N., Schinz, M., Spoon, L., Stenman, E., Zenger, M.: An Overview of the Scala Programming Language. Tech. rep. (2006) [21] Paas, F., Tuovinen, J., Tabbers, H., Van Gerven, P.: Cognitive load measurement as a means to advance cognitive load theory. Educational psychologist 38(1), 63–71 (2003) [22] Parnas, D.L.: A technique for software module specification with examples. Communications of the Association of Computing Machinery 15(5), 330–336 (May 1972) [23] Parnas, D.L.: Designing software for ease of extension and contraction. In: Proceedings of the 3rd international conference on Software engineering. pp. 264–277. ICSE ’78, IEEE Press, Piscataway, NJ, USA (1978)

[24] Pawlak, R., Duchien, L., Florin, G., LegondAubry, F., Seinturier, L., Martelli, L.: A uml notation for aspect-oriented software design. In: First Workshop on Aspect-Oriented Modeling with UML (AOSD’02) (The Netherlands, March 2002) [25] Reddy, Y.R., Ghosh, S., France, R.B., Straw, G., Bieman, J.M., McEachen, N., Song, E., Georg, G.: Directives for composing aspectoriented design class models. Transactions on Aspect-Oriented Software Development I, 75–105 (2006) [26] Schaefer, I.: Variability Modelling for ModelDriven Development of Software Product Lines. In: Fourth International Workshop on Variability Modelling of Software-intensive Systems (VaMoS 2010) (2010) [27] Stein, D., Hanenberg, S., Unland, R.: Expressing different conceptual models of join point selections in aspect-oriented design. In: AOSD 2006. pp. 15–26. ACM Press (2006) [28] Sweller, J.: Cognitive load during problem solving: Effects on learning. Cognitive science 12(2), 257–285 (1988) [29] Trujillo, S., Batory, D., Diaz, O.: Feature oriented model driven development: A case study for portlets. In: ICSE 2007. pp. 44 –53 (may 2007)