metarole-based modeling language (rbml) - CiteSeerX

METAROLE-BASED MODELING LANGUAGE (RBML) SPECIFICATION V1.0

ROBERT FRANCE Associate Professor Computer Science Department Colorado State University Fort Collins, CO 80523

DAE-KYOO KIM Computer Science Department Colorado State University Fort Collins, CO 80523

EUNJEE SONG Computer Science Department Colorado State University Fort Collins, CO 80523

SUDIPTO GHOSH Assistant Professor Computer Science Department Colorado State University Fort Collins, CO 80523

Computer Science Department Colorado State University Fort Collins, CO 80523, USA

Table of Contents

List of Figures

vii

1. RBML INTRODUCTION 1 Design Patterns 2 Model Families 3 Related Work 3.1 UML-based Pattern Formalization 3.2 Roles 3.3 The UML Notion of Roles 3.4 Model Families 3.5 Model Refactoring

1 1 3 4 4 4 5 5 7

2. RBML CONCEPTS 1 Roles Models 1.1 Static MetaRole Models (SRMs) 1.1.1 Classifier Roles 1.1.2 Relationship Roles 1.1.3 Proof Obligation 1.2 Interaction MetaRole Models (IRMs) 2 UML Metamodel View 3 Realization 4 Role Generalization/Specialization 5 MetaRole Model Generalization/Specialization 6 Pattern-Based Model Refactoring 6.1 Supporting Systematic Model Refactoring 6.2 Refactoring Using the Abstract Factory Pattern

9 9 10 10 12 15 16 17 18 19 20 22 22 23

3. RBML NOTATION 1 MetaRole Model Expression 1.0.1 Role Hierarchies

27 27 27

4. RBML EXAMPLES 1 MetaRole Models 1.1 Abstract Factory 1.2 Visitor 1.3 Checkin-Checkout (CICO)

31 31 31 36 39 v

vi

METAROLE-BASED MODELING LANGUAGE

2

1.3.1 CICO SRM 1.3.2 CICO IRMs Realizations 2.1 Abstract Factory 2.2 Visitor 2.3 Checkin-Checkout (CICO) 2.4 Library Model

40 42 42 42 44 46 48

Index 51

List of Figures

1.1 1.2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 3.1 3.2 3.3 3.4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14

An Example of Pattern-Based Model Refactoring Roles at the Metamodel Level Structure of a SRM Role SRM for Simplified Observer Pattern A Realization of the Simplified Observer Pattern IRM for the simplified Observer pattern UML Metamodel view of the simplified Observer pattern SRM UML Metamodel view of the factory part of Abstract Factory SRM An Example of Role Specialization Specialized Abstract Factory MetaRole Models Source SRM for an Abstract Factory Refactoring Target SRM for an Abstract Factory Refactoring Maze Game adapted from the GoF book Maze Game refactored with Abstract Factory pattern MetaRole Model Expression A Role Hierarchy Simplifying A Role Hierarchy An Abbreviated SRM The GoF Abstract Factory Pattern The GoF Abstract Factory Pattern Folded Abstract Factory SRM Abbreviated Abstract Factory SRM Detailed Abstract Factory SRM Folded Visitor SRM Abbreviated Visitor SRM Detailed Visitor SRM Visitor IRM A folded SRM of CICO System Abbreviated Item Role Hierarchy in Unfolded Form An IRM for a CheckOut Scenario A Realization of the CICO SRM: Library Model Abstract Factory Realizations

vii

2 6 12 13 14 16 17 18 20 21 23 24 25 26 27 28 29 30 32 32 33 34 35 36 36 37 38 39 41 43 44 45

viii

METAROLE-BASED MODELING LANGUAGE

4.15 4.16 4.17 4.18

A Realization of the Visitor SRM Object Structure used in Fig. ?? A Realization of the Visitor IRM A Realization of the Library CheckOut IRM

46 46 47 49

Chapter 1 RBML INTRODUCTION

1.

Design Patterns

Design patterns (e.g., see [?, ?, ?]) are intended to capture high-quality design experiences in a form that facilitates their reuse. Conceptually, a typical design pattern consists of two major parts: A part consisting of usage guidelines (including descriptions of the family of problems addressed by the pattern), descriptions of solution quality attributes (or “non-functional” properties) and principles, examples that describe the situations in which the pattern can be applied, consequences and trade-offs associated with the use of the pattern, and implementation concerns (e.g., see the Intent, Motivation, Applicability, Consequences, Implementation, and Sample Code parts of the GoF (“Gang of Four”) patterns [?]). We will refer to this part of a pattern as the usage context. A description of behavioral and structural aspects of the solutions characterized by the pattern (e.g., the Structure, Participants, and Collaborations parts of the GoF pattern descriptions [?]). We will refer to this part of a pattern as the pattern specification. While it may not be possible (or desirable) to formally express all aspects of a pattern’s usage context, it is possible to formally express a pattern specification when the structural and behavioral properties embodied by the pattern are well-understood. In this paper, a design is said to realize a design pattern if the design possesses the properties expressed in the pattern specification. Such a design is called a realization of the pattern. A pattern can be viewed as a loose characterization of its realizations. In general, it may not be possible, feasible, or desirable to formally characterize all possible realizations of a pattern because it may not be possible or fruitful to envisage all possible realizations. However, in such cases, it may be useful to formally characterize well-defined subsets of pattern realizations in order to support systematic application of patterns in situations in which the realizations are applicable. Such characterizations determine patterns that are specializations of more general patterns. Design patterns are intended to capture some of the best software design practices and principles in a form that facilitates their reuse. Work on patterns aims to provide developers with artifacts that, when applied appropriately, will result in designs that leverage the best available expert experiences. Support for precise representation of properties encapsulated by patterns and for rigorous realization of patterns can be beneficial in the following situations:

1

2

METAROLE-BASED MODELING LANGUAGE

Clear communication: Domain engineers and pattern users are able to communicate without ambiguity. Pattern selection: Precise descriptions of behavioral and structural properties of generic solutions characterized by patterns can help developers determine the appropriateness of applying patterns to meet design goals. Verifying conformance to a pattern: When a developer is required to verify that a design possesses the qualities encapsulated by a pattern, a precise notion of pattern conformance is needed. Analyzing behavioral and structural consequences of using patterns in a design: Rigorous application of patterns can help identify situations in which the use of one or more patterns in a design results in undesirable emergent properties. For example, bad interference among patterns can occur when a design element that plays roles in multiple patterns has its behavior in one pattern context significantly impaired by its behavior in another pattern context. Using patterns as aspects: Aspects are encapsulations of concerns that cross-cut system functionality (e.g., data persistency, fault tolerance, security). Given an aspect, its effect on system functionality is a result of ”weaving” the aspect into a specification of essential system functionality. Some aspects can be described as patterns of behavior and structure (e.g., the Command and Visitor patterns). Precise descriptions of patterns and weaving strategies pave the way for the building of tools that support aspect-oriented development. Precise forms of pattern specifications pave the way for the development of systematic patternbased model refactoring techniques. Model refactoring occurs when a design model is transformed to improve specific qualities (e.g., flexibility, understandability, reusability). Incorporating a pattern into a design to improve design quality attributes is called pattern-based model refactoring. An example of pattern-based model refactoring is shown in Fig. 1.1. abstract class

Display

Refactoring

displayed_on

Display

ImageImpl1

displayed_on Image

ImageImp implemented_by

(applying the Bridge Pattern)

ImageImpl1

Figure 1.1.

An Example of Pattern-Based Model Refactoring

In the example, a design in which a Display class is associated with a class defining a specific image implementation type (ImageImpl1) is transformed, using the GoF Bridge pattern [?], to one in which the Display class is associated with an image class structure that allows the image implementation to be varied. Precise pattern specifications can help one determine the transformations needed to incorporate a pattern into a design. In general, precise forms of pattern specifications can enhance understanding, selecting, and using patterns to create and improve designs. In this paper we present a notation for precisely expressing pattern specifications, and illustrate its utility by applying it to the GoF Visitor design pattern [?]. In developing the precise forms of the GoF pattern specifications we utilize the usage contexts of the patterns to gain insights into

RBML Introduction

3

the structural and behavioral aspects of the patterns. In our work, a design pattern is a propertyoriented characterization of its realizations, where the realizations are design models expressed in the Unified Modeling Language (UML) [?]. Structural and behavioral properties of a pattern are specified using MetaRole-Based Modeling Language (RBML), where a MetaRole Model described in RBML is a characterization of a family of UML design models.

2.

Model Families

Cost-effective development of large, integrated computer-based systems can be realized through systematic reuse practices. Advantages of incorporating such practices into a development environment are widely known. Arango and Prieto-Diaz [?] show that reuse of domain-specific experiences can significantly enhance development productivity and quality. There is a growing realization that development cycle time can be significantly shortened if reuse opportunities are exploited in all phases of software development, not just in the coding phase [?, ?, ?]. In the past, a barrier to the reuse of experiences above the code level was the lack of widely-accepted notations for representing requirements and design artifacts. The advent of the Unified Modeling Language (UML) [?] as a de-facto industry object-oriented (OO) modeling standard has the potential to remove this barrier. Our reuse-related research focuses on developing mechanisms that facilitate timely development of UML models in well-defined domains through reuse of domain-specific modeling experiences. In this paper we present a technique for precisely characterizing UML models for a family of systems. The technique uses a notation, called the Role-Based Modeling Language (RBML), to create a domain-specific modeling framework (i.e., domain characterizations from which application-specific models can be produced). Application developers within the domain can use such a framework to produce an initial set of models for the applications they develop. A characterization of model families is expressed in terms of MetaRole Models described in MetaRole-Based Modeling Language (RBML). A modeling framework is thus a collection of MetaRole Models that characterize a domain from a variety of perspectives (e.g., static and dynamic). A MetaRole Model determines a specialization of the UML meta-model, that is, a sub-language of the UML. The concepts used in our work relate to concepts defined at the UML metamodel level (M2 level). UML tools can thus be used as a base for building tool suppport for RBML. The RBML supports the creation of MetaRole Models (modeling frameworks) that support flexible model reuse. Reusability is achieved by “realizing” a MetaRole Model. Realzations of a MetaRole Model are application-specific UML models that possess the properties specified in the MetaRole Model. The realization mechanism makes use of parameterized templates included in MetaRole Models to produce application-specific model elements. The realization process is flexible in that the application developer can include additional properties in the model elements produced by the MetaRole Models. In this paper, we focus on reusable artifacts that characterize families of logical solutions (logical design models), but the technique can also be used to create frameworks that produce models at higher (requirements) and lower (detailed design) levels of abstractions. We illustrate our approach by using the RBML to create a modeling framework for a Checkin-Checkout (CICO) application domain. Applications within this domain include video-rental applications, car rental applications and library systems. In this application domain, items are checked out by users and returned (checked in) after use. The applications need to maintain a collection (or inventory) of the items. We use the RBML to characterize a subset of designs within this domain in terms of common

4

METAROLE-BASED MODELING LANGUAGE

structural and behavioral design properties. We also illustrate how the CICO modeling framework can be used to produce an application-specific model.

3. 3.1

Related Work UML-based Pattern Formalization

Lauder and Kent [?] propose an approach to presenting patterns precisely and visually using graphical constraint diagrams. In their work, patterns are described in terms of three layers of models: role-model, type-model and class-model. A role-model describes the essential aspects of a pattern in terms of highly abstract state and behavior elements. A type-model is a refinement of a role-model in that it refines the role-model state and behavior elements in terms of types that abstractly specify domain realizations of the role-model. A class-model is a deployment of a type-model in terms of concrete classes. In their work, pattern realization is viewed as a refinement process in which a high-level pattern description is refined to a model realization. Establishing that a model conforms to a pattern (as expressed by a role-model) involves defining refinement relationships across the model levels. The authors use a graphical form of constraints that is appealing but is not currently integrated with the UML and it is not clear how tools can support the notation. Guennec et al. [?] use a metamodeling approach in which pattern properties are expressed in terms of meta-collaborations that consist of roles that are played by instances of UML metamodel classes. They accurately point out deficiencies in the UML notion of role models and provide an alternative representation in terms of meta-collaborations that utilize a family of recurring properties initially proposed by Eden in [?]. Unfortunately, their paper does not describe how properties (other than hierarchical structures of classifiers) are specified, nor is there a clear notion of what it means for a model to realize a role model. The precise forms of pattern specifications we developed are characterizations of pattern realizations. Like the Lauder and Kent work, type models can realize our pattern specification MetaRole Models and they can be refined to produce more concrete realizations. One can also create realizations of our MetaRole Models that are more concrete than type models. Unlike the Lauder and Kent work, our MetaRole Model properties are expressed in terms of constraints on the UML metamodel and constraint templates that determine application-specific properties expressed in the Object Constraint Language (OCL) [?]. Like the Guennec et al. [?] work, our approach is based on the UML metamodel. Our work also includes notation for precisely expressing role properties. Our MetaRole Models determine a sub-language of the UML as defined by the UML metamodel. Our previous work on MetaRole Models focused on precisely expressing structural pattern properties [?]. The Static MetaRole Models described in this paper are an extension of the MetaRole Models developed in our early work. We also describe a type of MetaRole Model that characterizes UML interaction diagrams in this paper.

3.2

Roles

There has been considerable work on object-based notions of roles. These works have focused on the use of roles for describing the properties needed by an object in order for it to participate in a particular behavior. An object-based role specifies properties that objects in the run-time environment must have if they are to play the role. Riehle et al. [?] propose a role-based modeling

RBML Introduction

5

approach to specifying design frameworks. In their approach, a role is specified by a role type, where a role type specifies behavioral aspects of class instances. In the OOram method [?], a role is defined in terms of attributes and actions. Our MetaRole Models are intended to support pattern-based model refactoring, thus our roles are played by model elements (e.g., classes, dependencies, associations), not by objects. The MetaRole Models described in this paper determine a specialization of the UML metamodel. The difference between our model-based notion of roles and object-based notions of roles is discussed further in the following subsection.

3.3

The UML Notion of Roles

The UML is defined as one of the layers in a four-layer metamodel architecture [?]: Level M3 defines a language for specifying metamodels, level M2 defines the UML in terms of a metamodel, level M1 consists of UML models (i.e., instances of the M2 metamodel) and level M0 consists of instances of the models at level M1. In the UML, a collaboration role (i.e., a UML classifier role, a UML association role, or a UML association end role) is a M1 level construct (i.e., a modeling construct) that is a restricted view of a UML class, association, or association end (the role base). A UML collaboration role defines the properties needed by an instance of its base to participate in a particular behavior (a collaboration). Our notion of a role differs from the notion of collaboration role defined in the UML (and other object-based notions of role), in that our roles characterize instances of UML metamodel classes. UML collaboration roles are restricted views of elements at the UML model level (level M1), and are played (realized) by run-time instances (elements at level M0), and thus are defined in the context of a particular application. The differences between our notion of roles and UML collaboration roles are illustrated in Fig. 1.2. In the diagram, an example of a type of MetaRole Model described in this paper is shown at level M2. The realizations of this type of MetaRole Model are UML static structural diagrams (e.g., Class Diagrams). The two class diagrams shown at level M1 are partial realizations of this MetaRole Model. The association role Assc1 in the MetaRole Model shown at level M2 determines a subset of UML association constructs (i.e., it determines a specialization of the metamodel class Association). Similarly, the role R1 determines a specialization of the Class metamodel class. At the model level (M1), ClassB and ClassC are both realizations of the R1 role in the MetaRole Model shown at level M2, and ClassA is a realization of the role R2 in the MetaRole Model shown at level M2. The UML classifier role RoleA (at level M1) is a view of ClassA, that is, RoleA consists of a subset of ClassA properties (attributes, operations, associations). Objects of ClassA (at level M0) can play the role of RoleA. In summary, our roles characterize modeling elements at level M1, while UML collaboration roles are defined at level M1 and are characterizations of instances at level M0.

3.4

Model Families

The work on patterns (e.g., see [?, ?]) and architectures (e.g., see [?, ?, ?]) holds much promise, but very little attention has been paid to incorporating such experiences into system development environments (i.e., into notations, tools, and techniques used to develop systems). The Catalysis method [?] is notable in that it attempts to incorporate reusable experiences into modeling notation by providing syntactic support for representing architectural, design, and refinement patterns, called frameworks, in UML models. A problem with the Catalysis method is that the semantic aspects of these structures are described informally.

6

METAROLE-BASED MODELING LANGUAGE M2

UML meta−model AssociationEnd

Association

AssociationEnd

SRM /Assc1

Assc1

AsscEnd2

1



AsscEnd1

role base

1

1 /AsscEnd1

1 /AsscEnd2

0..1

*

1 Class

R2

R1



M1

/R2



UML Class Diagram (2)

UML Class Diagram (1) ClassB

1

/R1

UML Collaboration Role Model



ClassA

/RoleA:ClassA

collaboration role base ClassC

ClassD

/RoleD:ClassD

ClassP



M0

Figure 1.2.

objD:ClassD

Roles at the Metamodel Level

Work on domain-specific languages [?] focus on providing language interfaces for assembling code components into programs. These languages focus on downstream development phases (detailed design and implementation in code) and are more appropriately called domain-specific programming languages (DSPLs). Other forms of reusable experiences packaged for vertical reuse are frameworks [?] and domain-specific architectures (e.g., see [?, ?, ?, ?]). There is a considerable body of work on domain engineering processes and domain modeling notations (e.g. see [?, ?, ?, ?, ?]). Pattern languages (e.g, see [?, ?]) have been developed to describe Business Resource Management that covers applications including patterns for resource rental, trading and maintenance. In [?], Braga et al. use Class Diagrams to describe three patterns related to resource rental, trade and maintenance. They use the diagrams to stamp out models (which are also Class Diagrams) for various situations, such as library service, medical attendance, video rental, real estate rental and show box office. Their approach is purely syntactic. Apart from the basic structures, it is not clear what aspects of the pattern are described and how the pattern may be realized. Moreover, unlike Braga et al., we describe families of models at a higher level of abstraction. Other work on precisely defining pattern properties include those of Lauder and Kent [?], and Guennec et al. [?]. Lauder and Kent [?] use graphical constraint diagrams for precise visual presentation of patterns. Guennec et al. [?] use a metamodeling approach that is based on the UML metamodel. Their approach provides an alternative representation in terms of meta-collaborations that utilize a family of recurring properties initially proposed by Eden [?]. Pattern properties are expressed in terms of meta-collaborations that consist of roles played by instances of UML metamodel classes. The paper does not, however, describe how properties other than hierarchical structures of classifiers are specified. Nor is there a clear notion of what it means for a model to realize a role model.

RBML Introduction

7

Work has been done on developing object-based notions of roles (e.g., see [?, ?]). An object-based role specifies properties that objects in the run-time environment must have if they have to play the role. Our RBML require that roles be played by model elements (e.g., classes and associations), and not by objects.

3.5

Model Refactoring

There has been considerable work on object-based notions of roles (e.g., see [?, ?]). An objectbased role specifies properties that objects in the run-time environment must have if they are to play the role. Our MetaRole Models, which are intended to support pattern-based model refactoring, require that roles be played by model elements (e.g., classes and associations), and not by objects. There has also been some work on precisely defining pattern properties. Lauder and Kent [?] use graphical constraint diagrams for precise visual presentation of patterns. Guennec et al. [?] use a metamodeling approach that is based on the UML metamodel. Their approach provides an alternative representation in terms of meta-collaborations that utilize a family of recurring properties initially proposed by Eden [?]. The paper does not, however, describe how properties other than hierarchical structures of classifiers are specified, nor is there a clear notion of what it means for a model to realize a role model. Refactoring code has been considered an important part of the evolution of object-oriented software and has gained importance particularly with the acceptance of eXtreme Programming techniques [?, ?]. Tokuda and Batory [?, ?] proposed a refactoring approach to support design patterns as target states for software restructuring efforts. Butler and Xu [?] extend the concept of refactoring to other models, such as the feature model, use case model, and architecture, of an object-oriented framework. Our refactoring approach uses precise forms of design patterns (expressed in UML terms) as the basis for refactoring models.

Chapter 2 RBML CONCEPTS

1.

Roles Models

The following concerns guide our work on developing a notation for precisely expressing pattern specifications: To support the use of patterns in model refactoring (e.g., see Fig. 1.1), pattern specifications should be capable of describing solution characteristics in modeling terms. The use of the UML in industry is growing, thus we are interested in developing precise pattern specifications that characterize UML designs. In order to leverage UML tools, the pattern specification notation should be based on the UML infrastructure where possible. The concepts used in our work relate to concepts defined at the UML metamodel level (level M2). We also use UML graphical notation to represent role structures, thus UML tools can be used to build the graphical forms of our pattern specifications. In our work, a pattern specification consists of MetaRole Models, where a MetaRole Model is a characterization of a family of UML design models. A MetaRole Model determines a specialization of the UML metamodel, that is, it determines a sub-language of the UML. All models that can be expressed in the sub-language are considered to be realizations of the pattern (see Section 3.3). A MetaRole Model is a structure of roles, where a role specifies structural and behavioral properties. Each role is associated with a UML metamodel class (e.g., Class, Generalization) called its base. The properties defined in a role determine a subset of the role’s base instances (elements at level M1), for example, a role with the Class base determines a subset of class constructs. An instance of a role’s base that has the properties specified in a role can play the role, that is, it is a realization of the role. A Role Model realization is a model (e.g., a static structural diagram, sequence diagram) that consists of realizations of the roles in the MetaRole Model. Role : A role is a property-oriented specification that determines a subset of the instances of its base metamodel element. MetaRole Model : A MetaRole Model is a structure of roles that is a property-oriented characterization of a family of UML models. We have developed two types of MetaRole Models that can be used in a pattern specification:

9

10

METAROLE-BASED MODELING LANGUAGE

Static MetaRole Models (SRMs) : A SRM is a characterization of a family of UML static structural models, that is, models that depict classifiers (e.g., UML classes, interfaces, and types) and their relationships with each other (e.g., UML associations, dependencies, and generalizations). Interaction MetaRole Models (IRMs) : An IRM is a characterization of a family of interaction diagrams (e.g., collaboration and sequence diagrams).

1.1

Static MetaRole Models (SRMs)

The base of a role in a SRM is a metamodel class whose instances are elements of UML static models, thus a SRM role characterizes a set of UML static modeling constructs (e.g., class, association, generalization elements). For example, a SRM classifier role (i.e., a SRM role with the metamodel class Classifier as a base) defines properties that classifiers (e.g., classes, interfaces) must have if they are to realize the role, while a SRM relationship role defines properties that UML relationships (e.g., associations, generalizations) must have if they are to realize the role.

1.1.1

Classifier Roles

Two types of properties can be specified in a SRM classifier role: Metamodel-level constraints are well-formedness rules that determine the form of UML metamodel class instances that can realize the role. Specifically, the UML well-formedness rules and the metamodel-level constraints defined in a SRM role determine the form of model constructs that can play the SRM role. Like the UML metamodel well-formedness rules, metamodellevel constraints are expressed using the Object Constraint Language (OCL) [?]. Feature roles are characterizations of application-specific properties. A feature role consists of a name, a realization multiplicity, and an optional property specification expressed as a constraint template. A realization multiplicity specifies the number of realizations a feature role can have in a single realization of the enclosing SRM role. In this paper, we do not show feature role realization multiplicities if it is “1..*” (a commonly occurring case in the patterns we worked with). The constraint template of a feature role determines a family of application-specific properties. Features (e.g., attributes, operations) of model constructs that play a SRM role realize feature roles of the SRM role. There are two types of feature roles: –

Structural roles specify state-related properties that are realized by attributes or valuereturning operations in a SRM role realization. An example of a structural role that can be realized by class attributes is given below (see Fig. 2.1(b)): CurrentValue 1..1 {[[CurrentValue]] excludes(s) post: [[Element]] = [[Element]]@pre -> including(s)} The name of the above property is Attach. The realization multiplicity following the name (1..1) indicates that there must be exactly one behavior that realizes this role in a realization of the SRM role containing this feature role. The specification of the behavior references a value s that is an instance of a realization of a SRM role called Element. The constraint template consists of pre-condition and post-condition templates. The pre-condition template states that before execution of a behavior realizing Attach, s is not in the set of element objects (instances of an Element realization) known to the object that performs the Attach behavior. The post-condition template states that the effect of a realization of Attach is to include s in the set of element objects known to the performing object. The expression x • pre in the OCL refers to the value of x before execution of an operation. Substituting the names of realizations for the (feature or SRM) role names enclosed in the double square brackets ([[,]]) results in an application-specific property, called a modellevel constraint, expressed in the OCL. For example, substituting Sensor (a realization of Element) for Element in the Attach constraint template results in the following model-level constraint: Attach(s:Sensor) {pre:Sensor -> excludes(s) post: Sensor = Sensor@pre -> including(s)} Establishing that a model element realizes a SRM role involves proving that the constraints associated with the model element imply the model-level constraints obtained by suitably instantiating the role’s constraint templates, and determining that the realization multiplicities associated with the feature roles are not violated. The structure of a SRM role is shown in Fig. 2.1(a). The top compartment consists of three parts: A role base declaration of the form  BaseRole , where Base is the name of the role’s base (i.e., the name of a metamodel class). An example of a role base declaration is  Classifier Role . Only instances of the base can realize the role. A role name declaration of the form /RoleName, where RoleName is the name of the role. An optional realization multiplicity that specifies the number of realizations that can exist for the role in a realization of the SRM that includes the role. In this paper, the multiplicity is omitted if it is “*” (i.e., when there is no restriction on the number of realizations the role can have in a SRM realization) and when the multiplicity can be inferred from other information in the SRM. The role name and role base declaration could be expressed more concisely as /RoleName : Base, but we felt that the resulting syntactic similarity with the UML collaboration role could cause confusion. For this reason we place the base in a role stereotype symbol.

12

METAROLE-BASED MODELING LANGUAGE Base Role Stereotype

p

/RoleName

Role realization multiplicity (not shown if it is "*")

Constraints on form of base elements OCL metamodel constraints

Structural role properties

Feature roles

Behavioral role properties

SRM Role Structure

(a) /Monitor {self.isAbstract = true} /CurrentValue 1..1 /Threshold 1..1 {[[CurrentValue]] excludes(s) post:[[Element]] = [[Element]]@pre−>including(s)}

TempMonitor cv:Int {cv < th} th:Int ready:Int SensorAttach (s:TempSensor) {pre:TempSensor−>excludes(s) and ready =1 post:TempSensor = TempSensor@pre−>including(s)}

Feature roles



/Detach 1..1 (s:[[Element]]) {pre:[[Element]]−>includes(s) post:[[Element]] = [[Element]]@pre−>excluding(s)}

SensorDetach (s:TempSensor) {pre:TempSensor−>includes(s) and ready =1 post:TempSensor = TempSensor@pre−>excluding(s)} Activate () {pre:ready = 0 post:ready = 1} ...

Example of a SRM Role and a Realization

(b)

Figure 2.1.

Structure of a SRM Role

The second compartment consists of metamodel-level constraints that determine the (syntactic) form of the base instances that can realize the role. The realization multiplicity given in the top compartment can be expressed as a metamodel-level constraint using the OCL allInstances feature, but the result is a more complex metamodel-level constraint. The third compartment consists of feature roles. Structural roles are placed in the section headed  StructuralRole , and behavioral roles are placed in the section headed  BehavioralRole .

1.1.2

Relationship Roles

A role can be associated with another role, indicating that the realizations of the roles are associated in a manner that is consistent with how the bases of the roles are associated in the UML metamodel. For example, a Class role can be directly associated with an AssociationEnd role, but not with an Association role because the UML metamodel does not directly associate the Association metamodel element with the Class metamodel element. We use the UML form of association to represent role associations. Like UML associations, role associations can be named and can have multiplicities associated with their ends. A SRM for a simplified Observer pattern is shown in Fig. 2.2. The SRM consists of two class roles, Observer and Subject, an association role, Observes, and two association end roles, AssocEndObs and AssocEndSub. The Observer role characterizes classes

13

RBML Concepts /Subject

1..*

{self.isAbstract = false} /AssocEndSub

/SubjectState 1 /Attach (s:[[Observer]]) {pre:[[Observer]]−>excludes(s) post:[[Observer]]@pre−>including(s)} /Detach (s:[[Observer]]) {pre:[[Observer]]−>includes(s) post:[[Observer]]@pre−>excluding(s)} /GetState():[[T]] {pre: true post: result = [[Function]]([[SubjectState]], ...)} /Notify()

1..*

{multiplicity = *} 1

1 /Observes 1

/Observer 1 /AssocEndObs

{self.isAbstract = false} 1..*

{multiplicity = * and isNavigable = true}

Figure 2.2.

1..*

1

/ObserverState /Update (s:[[Subject]]) {pre: true post:[[ObserverState]] = [[Function]](s.[[SubjectState]], ...)}

SRM for Simplified Observer Pattern

of objects (observers) that monitor other objects called subjects, and the Subject role characterizes subject classes. The association between subject and observer classes in a realization of the Observer pattern is captured in the pattern by Observes. The form of the association ends of a realization of Observes are constrained by the two association end roles shown. AssocEndSub states that the subject end of an Observes realization must have a multiplicity of 0 or more (*), while AssocEndObs states that the observer end must be navigable and must have a multiplicity of 0 or more. The SRM thus characterizes models in which subject objects can attach themselves to one or more observer objects, and an observer object can monitor one or more subject objects. The multiplicities on the association between the Subject role and the AssocEndSub role indicate that a realization of the Subject role (a class) must have at least one association end that realizes AssocEndSub, and that a realization of AssocEndSub must be associated with exactly one class that realizes the Subject role. The other role associations shown in the SRM are interpreted in a similar manner. The realization multiplicities shown in the SRM require that a realization of the SRM must have at least one realization of Subject and at least one realization of Observer , and each realization of Subject is associated with at least one Observer , and each Observer realization is associated with at least one Subject realization via Observes realizations. The smallest models that can realize this SRM consist of a realization of Subject and a realization of Observer connected by a realization of Observes. Note that the “1..*” realization multiplicity for Observes (not shown) can be inferred

14

METAROLE-BASED MODELING LANGUAGE

from the realization multiplicities of Subject and Observer and the multiplicities on the associations between the roles. Realizations of the Observer role must be concrete classes (self .isAbstract = false), have at least one realization of ObserverState, and have behaviors that realize Update. The model-level post-condition obtained from Update requires that the realization of the ObserverState be updated with a value that is a defined function of a subject state (a realization of SubjectState) and possibly other arguments. The [[Function]] parameter must be instantiated with the name of a function that defines how the subject state is used to calculate a new value for the observer state. The bracketed expression following [[Function]] shows the parameters that must be passed into the function (the “...” indicates that other parameters not explicitly listed may be present). Realizations of the Subject role must be concrete classes (self .isAbstract = false), have at least one realization of SubjectState, and have behaviors that realize Attach, Detach, GetState, and Notify. The behavioral model-level constraints that must be satisfied by realizations of Subject are obtained by instantiating the parameters of the SRM role’s behavioral role (i.e., Attach, Detach, GetState, Notify). A realization of the Attach behavior attaches an observer to the subject, and a realization of the Detach behavior removes an observer from the subject. A realization of GetState returns a value (indicated by result) of type indicated by the parameter T , that is a function of the current value of the state realizing SubjectState, and possibly other values. There are no preand post-conditions on Notify (i.e., there are no restrictions on the effect this operation has on the state of a subject). TempObs

Kiln

currentHighTemp: Temp

kilntemp: Temp kilnpressure: Press ...

*

GetKilnTemp(): Temp GetKilnPress(): Press DetachObs(s:KilnObs) AttachObs(s:KilnObs)

*

*

obsTemp

KilnObs

PressureObs

obsPress

NotifyTemp() NotifyPress() ...

Update(k:Kiln) ...

*

currentLowPress: Press Update(k:Kiln) ...

Figure 2.3.

A Realization of the Simplified Observer Pattern

A realization of the simplified Observer pattern is shown in Fig. 2.3. In this paper, a stereotype with a role name (e.g.,  Subject ) in a model construct is used to indicate that the model

RBML Concepts

15

construct is an intended realization of the role. These stereotypes are printed in bold to distinguish them from other UML- and user-defined stereotypes. The class Kiln is a realization of the Subject role, while TempObs and PressureObs are realizations of the Observer role, as indicated by the stereotypes. The attributes kilntemp and kilnpressure each play the role of SubjectState. GetKilnTemp returns the current value of kilntemp, and GetKilnPress returns the current value of kilnpressure. These operations each realize the GetState behavior. The DetachObs and AttachObs operations are intended to realize the Attach and Detach feature roles, respectively. The behaviors specified by the model-level constraints obtained by appropriately instantitiating the parameters of the Attach and Detach constraint templates are implied when TempObs or PressureObs objects are passed as parameters to both DetachObs and AttachObs. In TempObs, the currentHighTemp attribute realizes ObserverState in the Observer role. The Update operation compares k .kilntemp to currentHighTemp and assigns k .kilntemp to currentHighTemp if the k .kilntemp value is greater, else currentHighTemp is left unchanged. This behavior implies the following model-level constraint obtained by appropriately instantiating the parameters of the Update behavioral role in the Observer role: {pre: true post: let F(t:Temp, c:Temp): Temp = if c >= t then c else t endif in currentHighTemp = F(k.kilntemp,currentHighTemp)} In summary, a model is said to realize a SRM if the following holds: The model constructs that are intended to realize SRM roles do realize the roles. This means that (1) the model elements satisfy the metamodel-level constraints of the role, and (2) the constraints expressed in the realizing model (e.g., pre- and post-conditions for operations, and constraints on attributes) imply the model-level constraints obtained by instantiating the parameters of the feature roles. The model conforms to constraints expressed across roles or their realizations (e.g., realization multiplicities, role association multiplicities). Pre-defined constraints across roles and role realizations will be introduced when used in this paper.

1.1.3

Proof Obligation

Establishing that TempMonitor is a realization of Monitor requires proving that the constraints associated with TempMonitor imply the model-level constraints obtained by instantiating the parameters of the Monitor feature roles, that is, the following proof obligations must be discharged: Structural Property Proof Obligation : cv < th ⇒ (cv