Multi-Level Constraints Tony Clark1 and Ulrich Frank2 1 Aston University, UK, [email protected] 2 University of Duisburg-Essen, DE, [email protected] Abstract. Meta-modelling and domain-specific modelling languages are supported by multi-level modelling which liberates model-based engi- neering from the traditional two-level type-instance language architec- ture. Proponents of this approach claim that multi-level modelling in- creases the quality of the resulting systems by introducing a second ab- straction dimension and thereby allowing both intra-level abstraction via sub-typing and inter-level abstraction via meta-types. Modelling ap- proaches include constraint languages that are used to express model semantics. Traditional languages, such as OCL, support intra-level con- straints, but not inter-level constraints. This paper motivates the need for multi-level constraints, shows how to implement such a language in a reflexive language architecture and applies multi-level constraints to an example multi-level model. 1 Introduction Conceptual models aim to bridge the gap between natural languages that are required to design and use a system and implementation languages. To this end, general-purpose modelling languages (GPML) like the UML consist of concepts that represent semantic primitives such as class, attribute, etc., that, on the one hand correspond to concepts of foundational ontologies, e.g., [4], and on the other hand can be nicely mapped to corresponding elements of object-oriented programming languages. Since GPML can be used to model a wide range of systems, they promise at- tractive economies of scale. At the same time, their use suffers from the fact that they offer generic concepts only. Domain-specific modelling languages (DMSL) address this limitation by providing concepts drawn from a particular domain of interest. Thus, modellers are not forced to find ways of representing specific con- cepts in terms of more general modelling element types, but can reuse (hopefully) thoroughly specified concepts that come with a DSML. While DSMLs promise clear advantages with respect to productivity and model quality, their construction and use are compromised by serious challenges. First, the designer of a DSML must decide whether a concept should be part of the language or be modelled using the language. In many cases there are no clear criteria that would support such a decision. Second, the design of a DSML requires dealing with a trade-off between range of reuse and productivity of reuse (see figure 1). y n y i t n i t l a i o Motor i l i i n G t b b o name: String a a i e y r a t t t s t i g torque: Integer p a u v p e r i a e t a t g ... d R n c d e I A t f u A f f n o d f I o o o o e f r l y e o c a e P g s c l n e n a S a e g i a i E t n c R i a n f f e R t E o P Product name: String desc.: String Degree of Specificity Class Device Laser-Printer n i a G e y t s i u v i e t R c f u o d o e r l a P c l S a i t n e t o P Degree of Specificity introduction of new languagestraction at features. the A type-level DSMLnumber of and language classification as designer levels. a This needsticulars, feature they consequence this, all is provides share important a a because fewWhile mechanism essential it the properties. for supports various First, approaches they ab- the to allow for multi-level an modelling arbitrary differ with2 respect to par- Multi-Level Modelling in arange Nutshell over multiple type-levels. are attached to meta-types4. We in demonstrate order the utility tothis of purpose. express MOCL domain-specific A for MLM MOCLa semantics in particular is that section meta-architecture defined 5 called where asplaces XCore constraints a requirements that language on we extension asponding believe to modelling language is XCore architectures, language ideally and in architecture suitedof demonstrates section - to multi-level the section modelling need 3 for into MOCLs. describes section its MLM 2 XCore serves meta-kernel.pose. to The The illustrate MOCL paper requirements has is beenlanguage for structured (MOCL). implemented corre- in In as the this follows. XModeler paper,[12]. A [8,6,7] However, we in brief as present there a an overview is MOCL extension no that agreement could on serve a thisinstances). unified pur- multi-level object constraint are classes) and thecan instances be of attached itsstructure instances to of (which a the maystraints be meta-class instances are classes and of not or those therefore sufficient, ground arbitrary classes. number apply since of In they to classification a levels. are its As multi-level attached a instances to model, consequence, traditional classes (which constraints OCL and con- constrain the There are various approaches to multi-level modelling (e.g., [2], [10], [11], [1], Multi-level modelling is suited to overcome these challenges by allowing an Fig. 1. Principal Conflict between Range of Reuse and Productivity of Reuse HardwareComponent Location suited_for 1 price: Float protected: Boolean 0 partPrice: Float tempControl: Boolean M4 M2 0,* 1,* 1 introduced: Date availPower: Integer 0 installed: Date 0 positioned_at 0 emergencyGen: Boolean energyCon: Float 1 1,1 0 volume: Integer actEnergyCon: Float 0,* 0 0 id: String 1 operationCosts: Float noOfMetaTypes: Integer() 2 noOfModels: Integer() Computer 1 compatible 1 PeripheralDevice mobile: Boolean ServerRoom 1 internalMemory: Integer 0,* 0,* 0 positioned_at 0 price: Float 1 persistentMemory: Integer volume: Integer id: string M3 M1 0,* .... 0 connected_to 0 0 additionalIntMem: Integer 0,* 1,1 0 2 noOfModels() 0 additionalPersMem: Integer 0,* 0,* 1 cpuSpeed: Integer 1 WLAN: String BusinessProcess requires 1 automated: Boolean coreComp: Boolean 0,* 1 maxDuration Scanner Printer 0 startTime name: String name: String Laptop 0 finishTime models = 14 Desktop Server resolution: Integer screenSize: Integer pagePerMinute: Integer pagePerMin: Integer screenResVert: Integer resolution: Integer TWAIN: Boolean screenResHor: Integer salesPrice: Float name: String 0 serialNo: String 0 partSalesPrice: Float revenues() : Float mobile: false noOfModels: 12 CPL-844 pagePerMinute = 40 M1 resolution = 600 salesPrice: 199.00 serialNo: String partSalesPrice: Float ps32-3: CPL-844 M0 partSalesPrice = 189.00 serialNo = ps32-3 Fig. 2. Example of Multi-Level Model but we would argue that a conventional modeller would find this attractive too in order to introduce new meta-concepts in a structured way. Second, every class, no matter on what level, is an object at the same time. This is important if technologies are to be reusable with respect to models that have an arbitrary number of type-levels. In addition, new type-levels imply that new types are defined including the ability to specify additional properties at the type-level. As we shall see, it is natural to introduce new properties for types and to treat them as objects by accessing and updating the property values. Third, MLM approaches support deferred or deep instantiation, which means that attributes of a class do not have to be instantiated with the direct instances of that class, but only later in instances of instances. The example class dia- gram in figure 2 illustrates the construction of a multi-level model. The class HardwareComponent is located on M4. Its specification should include everything we know about its instances, and instances of those instances etc. in order to achieve reuse and to prevent redundant specification on lower levels. For exam- ple, we know that every hardware component has a sales price which is defined on the level of a particular product type, that is, on M1. The intended instantiation level of a property (attribute, operation, associa- tion) is represented as an integer printed white on a black rectangle next to the property. We also know that any hardware component (represented on M3) may be suited for a certain type of location. In addition, it is obvious that a particu- lar exemplar of a hardware component is located at a particular location, both represented by objects on M0. As the example shows, associations are possible between classes on different levels. The diagram shows that there is need for constraints that span various lev- els. For example, the definition of an attribute like price that is supposed to be instantiated only a few instantiation levels further down the instantiation chain requires a constraint that applies to all affected instances. The deferred instanti- ation of the association positioned_at requires a constraint that is dynamically adapted on every instantiation level up to M0. At the level where it is defined, the class attached to the association end of positioned_at typed Computer is un- known since at M0 the corresponding link must be an instance of an instance of Computer (for example a lap-top or a desktop). With every instantiation, the range of possible choices is narrowed. Hence, a MOCL should allow for specify- ing constraints that applies to the entire range of a meta-class, that is, all its instances and instances of its instances. To this end, the MOCL must be based on a multi-level language architecture that enables multiple classification levels. More information about MLM, including features such as deep, struct, po- tency, clabjects and formalisation can be found in [5,13]. 3 Foundations: XCore with Single Level Constraints Fig. 3. Abstraction: Two Dimensions Model based engineering involves hierarchy in two dimensions: inheritance and types, as shown in figure 3.