Apart from sharing common concepts, current approaches to multi-level modelling differ with respect to specific features and the terminology. Both are an obstacle for the further development of the field. This paper presents a selection of possible requirements for advanced multi-level modelling languages. It is intended as a contribution to a broader discussion of requirements and to the development of a common research agenda.
Various languages and tools have been proposed to support multi-level
modelling [
sensus on requirements than on the comparative evaluation of existing artefacts – at least as long as the creators of these artefacts are involved.
This paper is intended to serve as a contribution to starting a community initiative on discussing requirements for future, possibly unified multi-level modelling languages that go beyond the common concepts outlined above. The requirements resulted from analysing limitations experienced with the use of the multi-level modelling language FMMLx F[lo7at], as well as from dMisonceyussions during various workshops and meetings. The requirements are illustrated in part with diagrams that were created with the FMMLx . Fig. 1 gives an overview of essential elements of the concrete syntax. Colors are used to represent classification levels.
Metaclass ^MetaClass^
PeripheralDevice name: String 1 salesPrice: Float 0 serialNo: String 0 partSalesPrice: Money totalRevenues() : Money models() : Integer 1 totalUnitsInStock() : Integer 1 revenues() : Money intrinsic operation, instantiated in classes on M1
M3 pnaagmeeP^:ePSrteMrriinipnPghuretinera:telIDnretevgiceer^ M2 ^OrganPiozastitioionnalUnit^ r01esssoaelulreitasiloPNnroi:c:IenS:ttMerignoegnrey 0,*uresponsible f1o,*r scmkoiisnlltLAPevevareMilla:ibSnic:lioFtryloe:aStcore tr0oevtpaealnUrutnSeiatss(leI)ns:SPMtroioccenk:e()My: oInnteeyger 0,*0 uuses 01,1 a0veproasgIDeA:Svtariilnagbility(): Duration rstaoaclteaeslR=Perivtcreeune=uefas(ls)e= € 7399.00 ibnetrtiwnesiecnaosbsjoeccitastioonn,Min0stantiated models() = 13 intrinsic attribute, instantiated in objects on M0 object state object returned by operation
M1 ^Printer^
CPL-844 0 serialNo: String 0 partSalesPrice: Money pagePerMinute = 40 resolution = 600 salesPrice = 199.00
language. Additional requirements that concern the size of a language, or the management and analysis of models are not accounted for. To stay within the space limitations, various requirements had to be omitted. Some of those will be mentioned in the conclusions. Every class specified in the FMMLx has to be assigned an explicit classification level. There is a good reason for this constraint, sometimes referred to as “strict multi-level modelling” [6, p. 28]. With respect to the semantics of a class, it makes a clear difference whether it is meant as a class on M1 or on any Mn with n > 1. In natural language we can cope with the ambiguity of terms like “Product”, which can be used to refer to a particular product, a type of product or even to the set of all kinds of product types. In conceptual modelling it is preferable to avoid ambiguity. Nevertheless, there are cases where the need to assign a strict, invariant level to a class is problematic, because it prevents an abstraction that would be useful, e.g., to increase reusability. The appropriate number of classification levels does not only depend on the variety of the subject, but also on the need to express variety. Sometimes, the design of two classification hierarchies of similar objects results in a top level meta class that makes sense for both hierarchies, but that would be located in one hierarchy on a level different from the one needed in the other hierarchy. The example in fig. 2 illustrates this problem.
on M3 and into Desk on M2. According to the experience gathered during the last years this is not an exotic exception, but occurs regularly.
M4 M3 M2 M1 M0
^Product^
PeripheralDevice 1 salesPrice: Float 0 serialNo: String 0 partSalesPrice: Float writeOnly: Boolean hasIdentity = true ^PeripheralDevice^
Printer 1 salesPrice: Float 0 serialNo: String 0 partSalesPrice: Float resolution: Integer writeOnly = true ^Printer^
PX_66 0 serialNo: String 0 partSalesPrice: Float salesPrice = 89.99 resolution = 600 ^PX_66^
P_73992S sPe_r7ia3l9N9o2S= P_73992S partSalesPrice = 79.99 ^MetaClass^
Product 1 salesPrice: Float 0 serialNo: String 0 partSalesPrice: Float hasIdentity: Boolean ^Product^
Desk 1 salesPrice: Float 0 serialNo: String 0 partSalesPrice: Float depth: Float width: Float hasIdentity = true ^Desk^
Nomad 0 serialNo: String 0 partSalesPrice: Float salesPrice = 179.99 depth = 605.000 width = 140.00 ^PX_66^
DN_9455T serialNo = DN_9455T partSalesPrice = n.def.
Fig. 2. Illustration of problem produced by strict levels R1 In addition to having classes with a definite level, it should be possible to define classes with a contingent level. A contingent level allows for adapting the concrete level of a class to different contexts of use. Rationale: It happens that two classes on different classification levels could be classified by the same meta class. However, this can be achieved only, if the meta class does not have a definite classification level. Instead, its level would have to be contingent with respect to the instantiation context.
pact on a model’s integrity. It is not necessarily the case that an attribute defined in a contingent class can be instantiated on any level. If, for example, an attribute is intended to store the average customer satisfaction with a certain bicycle model or bicycle type, it would make sense only to instantiate om M1 or above.
2.2
“Classless” classes Like with any object-oriented models, the design of multi-level models requires the creation of classes. In traditional, one-level models, a class is implicitly instantiated from one specific meta-class. In multi-level models, a new class is instantiated from a class that exists in the model already. As a consequence, the design of a multi-level model requires a top-down approach, that is, one has to start with classes on the topmost classification level. Then, classes on lower levels have to be added step by step. There are cases where it may be perceived as inappropriate to be forced to a top-down approach. Sometimes, the topmost classes are not known in advance. Instead, they may result through an act of abstraction from lower level classes. In other words, it would be helpful, if a topdown approach was supplemented by a bottom-up approach. That would require allowing for the preliminary creation of classes without an explicit meta-class.
2.3
Distinction of instantiation levels within associations
Position are both located on M2, that is, they are supposed to be instantiated into process types and position types. The intrinsic association between both is to express that a particular process instance on M0 is assigned to a particular instance of a position type, also on M0. This is indicated by the zero printed in white on the black square next to the association name. It is not a rare exception that an association should be instantiated on different levels with both associated classes. The example in fig. 3 includes the association “responsible for”. It is to express that a particular position instance on M0 is responsible for a type of platform on M1.
Employee lastName: String firstName: String 1,1
Location name: String airCon: Boolean protected: Boolean 0,* 0 size: Integer 1,1 requires placed at
Platform name: Boolean processor: String
OS: String 0,* fpiorsrttUabseled::BBoooolleeaann
0 acquired: Date 0,* 0 serialNo: String numOfExemplars() : Integer 1 responsible for 0 0,* 0 uses 0 0,* fills 0 Position 1,1 name: String
description: String 1,1 m0ifnilSeadlSairnyc:eF:loDaatte
0 salary: Float 1,* averageSalary() : float R3 Intrinsic associations should allow the specification of different instantiation levels for both participating classes. Rationale: It is common in natural language to link two concepts (or object references) on different classification levels in one sentence. Accordingly, it can be a relevant requirement to link two objects on different classification levels in an multi-level model. If the association can be defined on a higher level already, that is, if the association is intrinsic, it follows directly that it must be possible to support different instantiation levels.
the Xmodeler and proved to be very useful.
2.4
Avoiding redundant specification It happens that classes within a classification hierarchy share the same properties, that is, the same attributes, operations, or associations. A frequent example is an attribute like “name”, which may be required for a class, its instances and all further instances down the instantiation line. Further examples comprise operations that perform statistics on object populations. It might be required for every class within a classification hierarchy to provide methods that calculate the number of direct instances or the cumulated number of all instances of instances of a class (see example in fig. 4). ^PeripheralDevice^
Printer
inherited to its instances.maRxRaest:Iinotengerale: Inheriting features where it is appro1 serialNum: String priate enables preventing redundancy.
voltage = 220
trinsic property is not directly instantiated where it is defined, but only at the specified instantiation level. An inh^Perirntietr^ied property can be part of many classes.
be explicitly inherited, since exa0pvasliplaiebcciilfiiittcyW:Lieenivgehhlt: eFloraittance of intrinsic properties would be redundant and would therefore compromise the comprehensibility of a model.
alloy = „2011" In an ideal case, the implemencotrarotdeiso=nfaolsef operations can be inherited, too (as it would be the case with the example in fig. 4).
plicitly. Certain properties, such as the attribute name, are defined with the central class Class in Xcore. Every class that is defined with the FMMLx inherits through MetaClass from Class. However, this approach works only for properties that are generic enough to be inherited to all classes of an entire system. 2.5
Support for the specification of association types
Current languages do not provide specific support for the specification of association types. If an association is characterized by specific semantics, it has to be expressed by additional constraints. Table 1 gives an overview of general association types. name interaction aggregation composition delegation delegation to class description semantics variants behaviour no specific semantics none, restricted to state depen- transparent crecardinalities dency, e.g. mar- ation of links riage, sex particular objects special case of inter- state depen- transparent crethat are part of an- action dency; depen- ation of links other object, e.g. a dent on correwheel that is part of sponding coma particular car position an abstraction over similar to aggrega- state depen- transparent creaggregation, e.g. the tion, however, on dency, e.g. any ation of links construction of a car a different level of type of wheel including ownmodel may allow for abstraction (a type that is certified ership, require1 .. * wheel types is an aggregation of for a certain ments for MLM other types) speed transparently access special case of in- state depen- transparent credata or behaviour of teraction; delegator dency, e.g. age, ation of links; another object delegates behaviour qualification, object creation; (and, hence, state) authorization message disto delegatee patch transparently access similar to delega- delegation may transparent credata or behaviour tion, however on be restricted ation of links; that is common to a different level of to classes that object creation; all instances of a abstraction. Dele- are marked as message disclass, e.g. a price of gatee (object) dele- delegatees patch; requires a product exemplar gates behaviour to rules to define that is specified with its class dispatch order; the corresponding MLM requireclass ments
In addition to general association types, there are domain-specific association types. Their semantics depends on domain-specific requirements, which may vary. Hence, the language should offer meta-association types that allow the creation of various association types of the same kind. Also, the semantics of a domain-specific association type may depend on properties of the associated classes. Table 2 illustrates the idea of domain-specific association types with a few examples.
R5 The language should provide generic association types. At best, these types would be provided as instances of an association meta type. Rationale: Including generic association types promotes modelling productivity and model name married to holds kinds of classes description variations Person, Person marriage depends on cer- different constraints on tain requirements, e.g. sex, sex, multiplicities, age age Person, Driving Li- holding a driving licence constraints on min. and cence requires people to satisfy max. age, gender, different certain requirements types of driving licences
Table 2. Examples of domain-specific association types integrity. Meta association types provide modellers with more flexibility, since they allow to vary the semantics of generic association types.
cover the variance of domain-specific association types, it could be helpful, if a language provides meta-association types on a higher level, that would allow the instantiation of meta-association types. Rationale: The specification of domain-specific association types promotes model integrity.
2.6
Semantic enrichment of properties Properties of a class in a multi-level system may serve different purposes. An attribute that is instantiated in a class may represent properties of that class, a property value shared by all instances of the class, or constraints on possible property values in instances. The example in fig. 5 illustrates this issue with respect to attributes. The attribute minQualityLevel is instantiated with all instances and serves the specification of a constraint on possible values of instances of these instances (all types of printers in that system). The attribute serialNum, though being an intrinsic attribute, is supposed to be instantiated in individual values for each instance (particular printers). Finally, attributes like pagesPerMin are to be instantiated into values that are shared by all instances of the class a particular value was assigned to.
by corresponding access operations would represent corresponding aspects. Associations may also be used to create links between an object (e.g. representing a country) and a class (e.g. representing a specific product type), where the link is semantically shared by all its instances.
R7 A language should allow for clearly distinguishing between attributes that are regularly instantiated into individual values of instances, that are instantiated into values of instances that actually represent common values of their instances, and those that serve the specification of constraints on attribute values. At the same time, corresponding access operations should be qualified accordingly. Rationale: These different kinds of properties have specific semantics that would be lost, if there was no way to express it somehow, which in turn could compromise the integrity of systems.
include instantiation, read access, write access, update or release.
3
Despite its undisputed benefits, multi-level modelling has still not reached the mainstream of conceptual modelling and software engineering. Therefore, it would be important to bundle resources and to start a collaboration beyond existing approaches. That recommends not only focussing on "main open questions in multi-level modeling" [10, p. 54] including the appropriate size of a language, but also on requirements for future extensions of multi-level modelling languages. These activities are suited to foster the evolution of a common research agenda and a unified terminology – even though some of the requirements are already satisfied by existing approaches. The requirements presented in this paper are only a starting point. Various requirements had to be omitted because of space limitations. To name two examples only: it would be useful to allow for the specification of attributes with classes above M1, and, more important, there is need for a multi-level object constraint language.