Refering to the domain of IT management, this paper demonstrates conceptual strengths and economic bene ts of multilevel modeling. In the past, IT management was primarily focussed on technical aspects of IT infrastructures. In recent years, more and more organizations became aware of the pivotal relevance their IT infrastructures has for staying competitive. Therefore, IT managers are expected to not only provide IT services, but also to justify investments and costs with respect to the bene t the IT creates. On the one hand this responsibility demands for methods that allow for reducing the complexity of both, the IT infrastructure and the business. On the other hand, it is required accounting for interdependencies between these two areas. Specialized frameworks for IT management provide guidelines for specifying, managing and controlling IT services. Enterprise architectures or enterprise models support the alignment of IT and business by integrating models of the IT infrastructure and of enterprise software systems with models of the organizational action system. Against this background, speci c requirements of modeling IT infrastructures will be looked at in more detail. It will then be demonstrated that a multilevel language architecture and a corresponding meta-modeling and programming facility represent a powerful foundation for the development of advanced tools for IT management.
Multilevel modeling o ers a number of clear advantages over the traditional
modeling paradigm. In general, it enables additional abstractions that foster reuse
and exibility. It also allows for using concepts that correspond more directly
to the technical terminology in certain domains instead of overloading two-level
languages, which is likely to jeopardize system integrity by causing accidental
complexity [
This paper addresses both obstacles. First, it will be shown that the domain of IT management is in need of conceptual models that support the analysis of a increasingly complex subject and that foster sense-making and communication between di erent stakeholders. While IT management faces some particular challenges, its need for models is not idiosyncratic, but applies to any developed professional domain. Certain aspects of IT management are especially suited to illustrate modeling problems that cannot be satisfactorily solved within the traditional paradigm. Against this background, it will be demonstrated that a family of multilevel DSMLs is suited to o er a solution that promotes model integrity, modeling productivity and economies of scale. For this purpose a meta-modeling language is presented that allows for an unbounded number of meta levels and for the speci cation of so called intrinsic features. Second, an extension of a meta-modeling and -programming environment will be presented that is based on a recursive and re ective language architecture. It allows for the common representation of models and code and, thus, enables versatile decision support tools for IT management. They are suited to not only foster user empowerment by combining (meta) modeling features with customizable monitoring capabilities, but also to better integrate IT management with other management functions to make it more e ective and more e cient. 2
IT
In the early days of data processing, IT departments in many companies had a predominant technical focus. Software development and maintenance as well as dealing with the intricacies of hardware components were top priorities. As a consequence, the typical employee of an IT department had a technical background, often enough without an advanced quali cation in software engineering. Over the years, many IT infrastructures developed into a \zoo" of heterogeneous applications. While the \horrors of the past" and the ever increasing complexity of IT infrastructures kept IT departments busy, IT did not only turn into the backbone of business operations, but became more and more a potential enabler of future business models and, hence, a matter of survival. At the same time, IT budgests were still growing, while IT projects often did not deliver and the bene t of investments was hard to tell. Against this background, IT departments underwent a substantial change. Most companies abandoned inhouse development, which required employees who were able to deal with vendors and external service providers. Line managers who realized the potential of IT to improve their operations, developed business cases that required the adaption of IT systems. The growing need for collaboration between business people and IT professionals, the ever growing relevance of IT for the business and the complexity of IT infrastructures led to the emergence of a specialized management function. IT management should not only provide the required support to the business. It should also identify new opportunities of using technology to improve the business. Furthermore, it is supposed to control IT costs and organize IT departments to become more e cient. At the same time, IT management should overcome tradtional cultural barriers between IT experts and business professionals. The transition to IT management requires new organizational structures, new skills, and methods that support the introduction of appropriate structures and processes. To address the wide range of IT management tasks, methods and tools are needed that account for both, the peculiarities of IT infrastructures and the needs of businesses that will often have to adapt quickly to a changing environment. With regard to the pivotal economic relevance of IT management, it is not suprising that various vendors and initiatives responded do those needs. In the following we shall look at di erent approaches that are aimed at supporting IT management. This is to serve two purposes. On the one hand, it will underline the pivotal relevance of concepts and conceptual models. On the other hand, it will help to identify requirements that are not su ciently satis ed so far. 2.1
The vast amount of software artefacts and hardware systems that form an IT infrastructure creates the need for tools that support inventory management, version management, con guration management, software installation, etc. A database that represents all IT resources together with relevant inderdependencies, often referred to as \con guration management database (CMDB)", is an obvious choice to provide a common foundation for such tools. However, designing a database schema for that purpose requires skills and resources that go beyond the capabilities of many organizations. Furthermore, individual solutions would impede the use of tools that rely on a database. Therefore, it seems a reasonable approach to de ne a common schema for CMDBs and to standardize it in order to foster protection of investment. The \Common Information Model (CIM)", promoted by an industry consortium of large hardware and software vendors, the \Distributed Management Task Force (DMTF)" is the most relevant attempt of this kind. It de nes a schema that is documented as a set of UML class diagrams which are structured into three layers. The \core model" includes basic classes that are referred to in the \common model" which includes models CIM_ManagedSystemElement (See Core Model)
CIM_LogicalElement (See Core Model)
CIM_Col ectedSoftwareElements CIM_EnabledLogicalElement (See Core Model) CIM_System CIM_Service (See Core Model) (See Core Model)
CIM_ApplicationSystem Distribution: uint16 (enum} EnabledState: uint16 (enum, override) StartupTime: datetime ServingStatus: uint16 (enum) LastServingStatusUpdate: datetime StartApplication():uint16 StopAp*plication():uint16 *
CIM_ManagedElem (See CoreenMtodel)
CIM_MemberOfCol ection CIM_Col ection *
CIM_Instal edProduct
ProductIdentifyingNumber:string {Key, Propagated} CIM_Instal edProductImage * PPPSCNrrryoaoooslmdddteeeuuucm:ccctitttsoIVVNDtnreeai:InrnDmssgdt:ieroosi:nnrst:rg:tsisrnti{tnrgrKiignne{ggK{yK}e{{KeKyye}e,yyP,,PoPrrrpooappgaaaggtaaettdee}dd}} w** 1
CIM_Product (See Core Model)
CIM_Col ectedSoftwareFeatures CIM_SoftwareFeatureSAPImplementation 1 * SSVNooeaffrmttswwieoaa:nsrree:tsrEEitnrlligeeCnmmgI{MKee{e_KnnyStteIS,DoytO}fa:tswvtteera:irnurreigidnEet{1lKe}6emy{eK}nety, Enum} * EClIeMm_eSnotfCtwoam*reponent * IVVPdreeeornnsddtiuioof*cynrti::nNsstgtarrNiminCnuggeImM:{{sKb_KtreeSeinryoy:g,s,ftPtPw{rKirrnaooe*grppeya{a,FKggPeaeaartyotete,upddPra}e}rgoapteadg}ated} TargetOperatingSystem:uint16 {Key, Enum} CIM_SoftwareFeatureSoftwareElemen*tsName:string {Key, Override} OtherTargetOS:string Manufacturer:string BuildNumber:string SerialNumber:string CodeSet:string IdentificationCode:string LanguageEdition:string * CIM_ApplicationSystem
SoftwareFeature for representing application systems, hardware devices, networks, etc. Finally, \extension schemas" are included to de ne possible extensions to the common models. Figure 1 shows an excerpt of the CIM that is focused on application systems. *
To enable adaptations of schemas that go beyond prede ned extensions, the CIM is supplemented with a metamodel (see gure 2) which can be used to de ne customized schemas. If tools are not only constructed to handle the CIM, but also instances of the metamodel, user may de ne new schemas and still use a standard tool. However, apparently the metamodel is generic as it includes general purpose concepts only. Therefore, it is not possible to build tools that can make sensible use of any possible instance of the metamodel. The DMTF seems to be aware of this limitation, because the range of feasible instances is restricted to \new conformant models" (http://www.dmtf.org/standards/cim).
A reliable industry standard that de nes a schema for con guration management databases promises e ective support for managing IT infrastructures. It also promotes protection of investment and vendor independence. At the same time, it may create a problematic lock-in e ect. The introduction of IT management requires the de nition of responsibilities, services, processes and controls. Two frameworks for establishing IT manageCommon Information Model (CIM) Metamodel
CIM metamodel This clause normatively defines the semantics, attributes, and behaviors of the elements that comprise the CIM Metamodel. CIM Metamodel is specified as a UML user model (see the Unified Modeling Language: Superstructure specification). The principal elements of the CIM Metamodel are normatively shown in Figure 1. 901
Fig.F2ig.uMree1ta–mOovdeervlioewftohfeCCIMIMMe(ta[8m],odpe.l30 ment have achieved a remarkable dissemination. They both emerged from prac3t0ice. ITIL (\Information TechnoloDgMyTIFnSfrtaansdtarrudcture Library") orginateVserfsrioonm3.0a.1 project launched by the British government. It is supposed to describe \the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure." (http://www.itlibrary.org/). To this end, ITIL proposes a managerial perspective on IT that rests on two main pillars. On the one hand, the IT infrastructure is encapsulated toward the business with services. The speci cation of services is supported by comprehensive guidelines. On the other hand, the design of an IT organisation is supported by the de nition of core functions such as incident management, con guration management, change management, etc. For each of these functions, subjects, roles, processes and checklists are de ned that provide hand-on guidelines for establishing IT management practices. ITIL offers various certi cates that enable organizations and employees to demonstrate their IT management maturity.
\Control Objectives for Information and Related Technology (COBIT)" is a framework that originates in auditing. Similar to ITIL it is supposed to support companies with establishing a professional IT management. However, it has a di erent focus. Its main emphasis is on the introduction and continuous improvement of IT governance. For this purpose, COBIT provides a framework of responsibilities, rules and high level activities that aim among other things at improving the alignment of IT and business, at improving the qualitiy of IT services and at more reliable predictions of IT costs. The framework also includes the de nition of corresponding metrics that serve to measure and control IT management practices. Like ITIL, COBIT o ers training courses and certi cates. There is one further aspect that is shared by both frameworks. Even though they do not include any conceptual model that was designed with an explicit modeling language, the backbone of both framework consists of a conceptual foundation in the form of technical languages that allow to structure the subject and the responsibilities of IT management in a purposeful way. Figure 3 shows a reconstruction of concepts de ned in ITIL in comparison to those that are used in COBIT. The colour green marks concepts that are shared by both approaches, that are, however, clearly more comprehensively de ned in ITIL. Blue indicates that corresponding concepts are de ned in similar detail in both frameworks, while red marks those concepts that are not accounted for in COBIT. Yellow marks common concepts that are described in more detail in COBIT.
The lack of precise metamodels may be related to the business models behind ITIL and COBIT. Both promote training and consulting to help users develop appropriate interpretations that t their needs. At the same time, both frameworks were not designed to serve as a foundation for building software tools. 2.3
IT management is more and more regarded as a pivotal management function that does not only manage IT resources, but supports the business more directly and contributes to the strategic development of a rm. As a consequence, IT managers are supposed to have a clear understanding of how IT should support the business and how it may contribute making a company more competitive. At the same time, they should be able to e ciently communicate with users, line managers and top management, similar to consultants. The idea of an enterprise architecture, which was introduced by Zachman, an IBM sales representative who aimed at improving communication with customers, intends to provide a representation of the enterprise and its IT infrastructure that re ects the basic building blocks and relevant dependencies. An enterprise architecture mainly targets management audiences. For this reason, it stresses a high level Ansätze auf die Ein‐ und Ausgabeparameter der Prozesse ein, wobei diese in ITIL weniger explizit spezifiziert sind als in CobiT. Die Betrachtung der technischen Infrastruktur ist so‐ wohl in CobiT als auch in ITIL recht abstrakt. Die Begriffe Infrastructure und Application (Co‐ biT) bzw. Hardware und Software (ITIL) als IT‐Ressourcen (Resource) werden zwar eingeführt, aber kaum vertieft. Rollenbeschreibungen für die Mitarbeiter einer IT‐Organisation sowie die Kundenmetapher enthalten ebenfalls beide Ansätze. Auch die Sicherheit von IT ist jeweils grundlegend behandelt.
Configuration
Management Database
Security n i d e goal for trso
Configuration part of Release partof partof Hardware Software s e r u s n e Capacity implies has supports isa Availability includes
Business Process produces consistsof measures participates in
Activity Control s e s u a c Known Error d e lr a c e d Problem causes Incident necessitates
Service Desk requests adresses informs
Customer negotiates
Service Level Agreement / u Operational Level Agreement ses defines necessitates s e n if e d
has needs affects
Service supports requiredfor
Gemeinsame Konzepte – Größere Detaillierung in CobiT
Anhand der im Vergleich zu Abbildung 44 geringen Anzahl an grün dargecstdeleltteani lKs.oIntzeips‐
of abstraction (\ballpark view") and does not account for speci
tesnu pinp Aosbebdildung 43 lässt sich bereits schließen, dass die Detaillierung der meisten gemein‐
to represent essential aspects of the business, such as goals and
busisanmesesn Konzepte auf Seiten von CobiT weniger ausgeprägt ist. Dies isatn voIrT dienmfr Hasitnrtuercgtruurned
processes, and to integrate them with those aspects of
dtehr aZtielsetzung von CfoorbiT zu sehen, idme cViseirognleimcha kzuin gan.dIetren IrTe‐gMaradnaegdemenat‐Apnivsäottzaeln
are relevant managerial is as
eitnoeo glrföoßrerpe rAombdoetciknugngI Tderb Dusoimneäsnse zu leimsteenn,t w,afos rvomr aalkleinmg bIeTzogmeno raeufe diec iPernotz,esasnddo‐
align
kfuomr esnutpatpioonr tiinn gwsetnriagteer gkicon(kITre)tem Vaonrgaagbeemn ernetsu[1lt0ie]r.t.T Loeedmigplichha sdiziee Btehsechimreipbourntga ndceer oInf‐
fodremvaetlioopnienng (,Indfoorcmuamtioenn)t sinowg,iec Aomspmekutne idceast iCnogntarnoldlinegnsf o(Crcoinntrgola) nweeinsetner ipnr CisoebiaTr cehinitee hco-‐
hteu Dree,taiitllhiearusnbge eanufp. Lroeptzotesreeds tmoainnitfreostdieurct esiachd iendsibceastoenddemrea nina egienmere rnetlaftuivn cgtriooßne.nE Anntzearh-l
anp rvisoergaerscchhliategcetnuenre KmPIasn (aKgeeym Peenrftorimsannocet Iinndtiecantdore)d zutor ÜrebpelrawcaechITunmg adnera gveemrscehnite,dbenuetn
Pirsozreastshe.e r seen as one of the core functions of IT management. While enterprise
architectures are still often created with generic drawing tools only, there are
Gemeinsame Konzepte – Größere Detaillierung in ITIL
various attempts to provide a more formal foundation for designing enterprise
Daar cdhieit eITcItLu‐rDeosk(uem.ge.n,ta[1ti1o]n, [im12 ]B)e.rOeicnhe dleasn gSueravgicee‐tMo amnaogdeemleenntst eirmp rViseergalericchhi tzeuc tCuorbeisT
eihnaesn hgöahineeredn rDeemtaairlgkraabdl eauafwtteeinstt,i ofinn,depnr osibcha bi nly Aablbsioldbunecga 4u4s meeihtrh garsünb deacrogmeseteplltaer tIToILf‐
TOGAF (http://www.opengroup.org/subjectareas/enterprise), a framework for
enterprise architecture management that is characterized by similar claims as
ITIL and COBIT. Archimate [
The di erent approaches to support IT management share two common properties. First, they emphasize a pragmatic approach, either by using mainstream technology such as CIM, or by preferring sketchy de nitions over elaborate conceptualizations such as ITIL, COBIT, and to a lesser extent, Archimate. Second, they allow for adaptations and, in that respect, put more emphasis on exibility than on integrity. While Archimate claims to be a modeling language, it hardly quali es as a DSML. The viewpoint de nitions are not metamodels that allow for specifying types. Instead, viewpoints and the models that correspond to them are characterized by a subtle overloading of concepts. The lack of su ciently clear semantics makes it virtually impossible to use Archimate models for generating code. Although there is some overlapping between the di erent approaches, integrating them into one comprehensive, multi-perspective approach would be bene tial. However, the lack of clear conceptual foundations makes it di cult to accomplish such an integration. 3
Our work on DSMLs for modeling IT infrastructures was at rst motivated by
our long-standing research on enterprise modeling. In the early days of enterprise
modeling, it was assumed that companies need support for software development.
Accordingly, there was emphasis on integrating software design languages, such
as object-oriented modeling languages. Later, it became apparent that software
development was of less concern for most companies than managing the often
huge IT infrastructures that have emerged over the years. Therefore, we decided
to add a language for modeling IT infrastructures [
It took some time to convince the seasoned software developers in the company
that a DSML that is integrated with other DSMLs for enterprise modeling could
serve as a powerful foundation for future IT management tools. However, a
modeling tool alone would not be su cient for that purpose. Apart from conceptual
support for analyzing the IT and the business, IT managers also need to know
the state and the state history of particular objects, for example the availability
of a particular server or the maintenance costs of an application system. They
also need to be informed about certain events like attempts from external
intruders to get access to sensitive data. In addition, decision making requires
various kinds of statistical analysis on sets of data. Most companies
appreciate general frameworks for IT management, because they do not want to start
from scratch, but simulaeously, they do not want to be restricted too much.
Against this background a vision of a future tool was developed that was based
on three main components. First, an existing method and toolset for creating
and managing enterprise models should be used to address the need for
integrating representations of the IT with those of the organizational action system.
Second, an existing DSML for modeling IT infrastructures that was already part
of the enterprise modeling method should be re ned to better satisfy the needs of
prospective customers [
The enthusiasm we had developed for the vision of an advanced IT management
tool was soon contrasted by the sobering insights that an implementation of
the vision was confronted with serious obstacles. They include general problems
with the design of DSMLs that became especially apparent with the design of
a language for modeling IT infrastructures, and more speci c problems that are
related to peculiarities of the subject. In general, the design of a DSML is
confronted with the decision whether a certain concept should become part of the
language or rather be de ned with the language. Take, for example, the following
terms: Software, Operating System, ERP-System, DBMS, RDBMS, Middleware,
Printer, Laser-Printer. How could one decide whether to take the more generic
or the more speci c term|or both? Criteria to support this decision have been
proposed in [
A further, related problem is suited to cause frustration, too. The analysis of domain concepts often results in a hiearchy of concepts where more general, but still domain-related terms are re ned step by step to more speci c terms. Figure 6 shows a typical example of this problem that seems to be rather the rule than an exception. Obviously, such a hierarchy leads to the question whether the re nement represents an instantiation relationship or rather a specialization relationship. Looking at the hierarchy of terms on the left only may inspire an R ffE
Product name: String desc.: String
Degree of Specificity n i a
G seu ity lfaeeoR itrcvPduo cS li a t n e t o P
Class
Device
Laser-Printer
Degree of Specificity ontological discussion with an uncertain outcome. One can also take a more pragmatic approach by adding properties such as attributes and operations that are characteristic for the pictured terms. The hierarchy on the right represents a corresponding view. Its analysis leads to a sobering result. Even though it is an iron law of conceptual modeling that there is a clear dichotomy between instantiation and specialization, the example indicates that it may make sense to combine both. We know that every peripheral device has a sales price. This is the case for any printer, too. Therefore, the attribute salesPrice should be inherited to Printer. However, the operation numberOfModels is to be used by Printer, which would suggest to instantiate it from PeripheralDevice. Similarily, the attribute resolution in Printer is instantiated in classes that represent particular models, while the attribute serialNumber should be inherited from Printer to classes that represent a model. One could argue that it is not appropriate to assign an attribute like salesPrice to PeripheralDevice, because it is instantiated only with speci c models. However, that would result in conceptual redundancy, because it would imply to introduce a corresponding attribute for each kind of peripheral device again and again. There are some obvious lessons to be learnt from examples like that. First, there are cases where a strict dichotomy of instantiation and specialization (or rather inheritance) is dissatisfactory. Second, instantiation of attributes may sometimes be deferred to a lower level. Note that this may be the case for operations, too. An operation like numberOfDevices could be speci ed with PeripheralDevice already, which would replace redundant operations like numberOfPrinters in the example. Third, classes as well as metaclasses may have a state and may execute operations. Therefore, they should be regarded as objects. Unfortunately, all of these lessons are in clear contrast to the dominant modeling paradigm, which means that they cannot be expressed accordingly in a traditional one level (M1) object model.
A further challenge results from the idea to integrate a modeling environment with dashboard software. A dashboard is supposed to present data related to concepts speci ed in models. Integration implies among other things that it should be possible to navigate from the dashsboard to a model et vice versa. However, as shown in g. 7, there is a serious obstacle that prevents a satisfactory integration. Classes that represent a model (or a metamodel respectively) have to be represented as objects on M0 in a modeling environment, because mainstream object-oriented programming languages do not allow to treat classes as objects, nor do they allow for metaclasses. Hence, \classes" in a model editor cannot be instantiated any further. Therefore, the approach of choice is to generate code from models. Unfortunately that approach is hardly satisfactory. It would require synchronizing models and code, which is a notorious problem that does not allow for a satisfactory solution. It would also require a sophisticated middleware system to establish references between the modeling environment and the dashboard system that enable navigation at runtime. Furthermore, generating code from a model that was speci ed with a DSML to a general-purpose programming language can be a demanding task. 4
To cope with the obstacles outlined above, we supplemented our MOF-like
language architecture ([
Management instance of cosrurelsptonidns toa satisfactory solution. Instead, it became more and more apparent that the challenges we experienced cannot be overcome without leaving the traditional paradigm. While multiMle0vel languages seemed to be much better suited as a foundation for a convincing solution, implementing multilevel models for being used at runtime was not possible without painful trade-o s. The solution that is presented below became possible only through the availability of a multilevel language engineering facility. 4.1
The idea of recursive language architectures has probably become popular by
the \golden braid" metaphor Hofstadter used for his sophisticated praise of
recursion [
The golden braid architecture in general, XCore in particular are based on concepts that may be perceived as confusing, since they seem to violate well known principles of meta-modeling. XCore makes use of a circular relationship: The central metaclass Class, which is associated with a meta attribute, a meta operation and a meta association is an instance of itself. At the same time, class inherits from Object. Hence, every class is an object and can be executed. Object itself is instantiated from Class. Furthermore, every instance of Class can inherit from every other instance of Class. For a more detailed description see [20], especially p. 23 . The lean recursive structure of XCore allows for creating an unbounded number of classi cation levels but not without e ort. As a default, every class that is instantiated from Class is located on M1. If a metaclass on a higher level of classi cation is required, one would specialize a class that was instantiated from Class from Class at the same time. That would result in lifting it up to M2, because it would inherit the instantiation capability of the original metaclass. Instantiating the new class and having the resulting instance inherit from the original metaclass would result in lifting the instance up to M2 and, as a consequence, its classi cation level, which was previously M2 up to M3. Since the lifting procedure can be repeated inde nitely, language hierarchies with any number of classi cation levels can be realized. XMF provides all the exibility that is required for developing a satisfactory solution for the implementation of the outlined IT management support tool. In particular, it allows for a common representation of models and code. Classes, no matter on what level, are objects at the same time. They can be represented in the tool on the intended classi cation level. They can also be instantiated and executed within the Xmodeler. However, XCore lacks two features that are useful for modeling and implementing multilevel DSMLs. First, XCore does not provide direct support for deferred instantiation. Second, from a conceptual viewpoint it is important to know the classi cation level of a class, because it makes a clear di erence whether a class is on level n or on level m with n 6= m. However, classes in XMF are not explicitly assigned to a classi cation level upon instantiation. Furthermore, the level of a class may be contingent in the sense that the level may change during the lifetime of the class. The level of a class at a particular point in time can be determined dynamically through step-by-step instantiation only. It is also possible that a class is level-agnostic, which means that it may be interpreted as being on di erent levels at the same time. This is in particular the case for Class the instances of which may reside on any level above M0 which implies that Class may virtually reside on many levels above M1 simultaneously. While being level-agnostic is a prerequisite for the positioning of classes on multiple classi cation levels, it is hardly acceptable from a conceptual point of view, because it would remain unclear what kind of concept the class represents in the end. Conceptually, contingent classi cation is questionable, too, because the classi cation level is a pivotal aspect of a concept's semantic.
Against this background, we decided to specify a meta-modeling language,
the F M M Lx (\Flexibile and Executable Meta-Modeling Language") that, like
XCore, enables an unbounded number of classi cation levels. However, for
every model created with the F M M Lx, each class is assigned a level. In
addition to that, the F M M Lx supports intrinsic features. An intrinsic feature is an
attribute, an association, or an operation that is de ned on a level n, but is
instantiated only on a level m, with m < n - 1. The F M M Lx was created by
extending XCore and by introducing a speci c concrete syntax for
representing multilevel models. Figure 8 illustrates the use of intrinsic features and the
concrete syntax of the F M M Lx. The level of a class is indicated by the colour
of the background a class name is printed on. To indicate the class, a class is
instantiated from, the name of the metaclass is printed above the classname.
Intrinsic features are marked by the instantiation level that is printed in white on
a black rectangle. Intrinsic associations may have two, possibly di erent
instantiation levels assigned to them. The model in gure 10 includes a corresponding
example: the class HardwareComponent on M4 is associated with the class
Location on M2. Intrinsic features correspond widely to \deep instantiation" and
\potency" ([
^Product^
CompoundProduct 1 salesPrice : Float 1 weight : Float 1 unitsInStock : Integer 0 serialNo : String
averagePricePerUnit() : Float 1 totalUnitsInStock () : Integer 1 averagePricePerBike() : Float intrinsic operation, instantiated in classes on M1
M3
^Process^
BusinessProcess corpRelevance: Score maturity : Score 0 startTime : Time 0 stopTime : Time aveTotalExecTime(): Duration averageExecTime(): Duration intrinsic attribute, instantiated in objects on M0
M2 0,* 0,* ^OrganisationalUnit^
Position uin charge of skillLevel : Score
1,* cmoisntAPvearMilaibni:litFylo:aStcore 0 umanages 0 0 posID : String
1,1 averageAvailability (): Duration intrinsic association, instantiated between objects on M0
Fig. 8. F M M Lx: Illustration of Concrete Syntax
As illustrated in gure 9, the F M M Lx is a monotonic extension of XCore. On the one hand, that means that existing models of XCore will not be affected by the extension. On the other hand, it allows to preserve the exibility provided by contingent levels for those cases where it is needed. The extension comprises two parts. First, the meta-attributes isInstrinsic and instLevel are added to Attribute, CompiledOperation, and End. The meta-attributes allow for de ning attributes, operations and associations as intrinsic. Second, a metaclass, CompiledOperation, is de ned that allows to instantiate level-aware classes. For this purpose, the instantiation method new() had to be overriden. It could not, however, be overriden in Class without side-e ects on previous models of XCore. Therefore, an intermediate class, MetaAdaptor, was introduced. It includes the attribute level, which enables to assign a level to every class. It is also used to re-implement new(). A class can be instantiated from MetaClass on any level.
Hence, the level of metaclass itself is contingent. It is, however, possible to dene a level for Class, through the attribute level speci ed in MetaAdaptor, that is supposed to be invariant for a certain model.
CollectionMult lowerBound: Integer upperBound: Integer hasUpperBound: Boolean
End name: String isIntrinsic: Boolean instLevel: Integer isNavigable: Boolean isCore: Boolean2,2 0,1 0,1 2,2 1,1
Association type: AssocType inherits from u
C2 0,* 0,*
Class isA1b,s1tract: Boolean isRole: Boolean 0,* 1,1 new() 0,*
Object get(name: String): Object set(name: String, value: Object): Object copy(): Object save(fileName: String): Object
C2 context Class @Constraint nonCyclicInheritance
not self.allParents().includes(self) end 0,* 0,* 0,* 0,* upart of
0,*
Attribute name: String type: Classifier isIntrinsic: Boolean instLevel: Integer isCore: Boolean upart of
Doc 0,* doc: String
id: String upart of upart of
Constraint body: String id: String
0,* 0,* CompiledOperation name: String codeBox: Element traced: Element isIntrinsic: Boolean instLevel: Integer isCore: Boolean FMMLx XCore (simplified) C1
extended features Interface Layer Mn C1
A model editor for the F M M Lx was implemented within the Xmodeler. It allows to create models and modeling languages simultaneously. Every class that is created above M2 is a language concept that is immediately added to the palette and can be subsequently used to create new instances (see gure 10).
To demonstrate the potential of a multilevel approach to solve the problems
discussed in 3.2, an existing language for modeling IT infrastructures (ITML)
[
Each class in the model shown in gure 10 is an object the operations of which can be executed. The enlarged representation of three selected classes in gure 11 illustrates this feature. The class Printer on M2 executes two operations which are de ned with its metaclass PeripheralDevice. Whenever the number of printer models changes, the operation is anewly executed and the resulting value is presented in the diagram. The Sister200 on M1 stores the values that specify a particular printer model such as the resolution or the speed. It also executes operations that collect data from its instances, such as costs or pages printed in a certain period. Finally, particular printers are represented on M0. The state of each object, no matter on what level of classi cation, can be changed interactively. Hence, a diagram turns into a multilevel representation. Furthermore, the speci cation of classes can be modi ed, too. If attributes or operations are added, they are, as a default, available not only with newly created instances, but also with already existing ones. However, other policies may be de ned. Deleting attributes will, as a default, still allow access to existing slot values. This is similar for deleting operations which still allows executing those operations with existing objects, but of course not with those that were instantiated after the removal of an operation. Again, di erent policies for deleting properties may be de ned. Adding and deleting intrinsic features requires more complex operations.
Apparently, a multilevel object model is at the same time a multilevel software system, which could be directly used to store and calculate all data required for a dashboard system. Users of a dashboard system will probably prefer other representations than diagrams. This can be accounted for by regarding the model as a model in a MVC architecture, which is in fact supported by the Xmodeler.
Any kind of visualisation could be de ned with one or more corresponding views a 1,* ion an olean ger Boolean er 0 positioned_at 01,1 0ivdo:lusStmreirenv:geInrRteogoemr ktop
Server
Fig. 10. Screenshot of Xmodeler with Excerpt of Multilevel ITML that would support user-speci c interfaces. Figure 12 shows a GUI of a dashboard system that represents a view of the multilevel model in gure 10. 5
IT management is an example out of many domains that are characterized by the need for an elaborate technical terminology in order to support advanced decision making. In addition to that, it also requires the management of particular resources. While the use of DSMLs is promising to model domains of this kind, traditional language architectures with one classi cation level only are confronted with serious problems, both with respect to the design of proper conceptual models and the realization of corresponding software systems. In this paper it was demonstrated that a multilevel language architecture that integrates
Fig. 11. Enlarged Excerpt of Multilevel Model a (meta-) modeling environment with a (meta-) programming facility is suited to e ectively address those problems. It does not only enable more expressive models that promote reuse and exibility, it also provides the foundation of a new class of application systems that are integrated with conceptual models of themselves at runtime. Such self-referential systems are suited to empower users, because they do not only provide users on demand with information about the conceptual foundation of the system they work with, but may also enable users to modify the system by editing those parts of the models they are authorized to change.
To further promote the eld of multilevel modeling and multilevel software construction, it seems useful to develop languages, models and applications for further domains, and compare the results to traditional approaches (for a further
Fig. 12. Illustration of Dashboard analysis of this kind see [23]). That does not only contribute to demonstrating the practical bene ts of multilevel approaches, it also leads to new requirements for foundational meta-languages and language engineering facilities. The integration of an application system with multiple meta levels increases its exibility substantially. At the same time, it adds complexity and raises speci c challenges to integrity. Therefore, more research is needed on specifying and ensuring integrity constraints in multilevel systems. The design of multilevel domain models is in part still unknown territory. So far, there is only little methodical support ([24] and, in part, [25]). Therefore, future research needs to aim at the further development of speci c design and analysis methods. So far, research on multilevel modeling was mainly restricted to static abstractions. A multilevel approach to process modeling may be suited to reduce the remarkable lack of abstraction and reuse in current process modeling languages [26]. 20. Tony Clark, Paul Sammut, and James Willans. Applied Metamodelling: A Foundation for Language Driven Development. Ceteva, 2 edition, 2008. 21. Tony Clark and James Willans. Software language engineering with xmf and xmodeler. In Marjan Mernik, editor, Formal and Practical Aspects of Domain-Speci c Languages, pages 311{340. Information Science Reference, 2012. 22. Bernd Neumayr, Manfred A. Jeusfeld, Michael Schre , and Christoph Schutz. Dual deep instantiation and its conceptbase implementation. In Matthias Jarke, John Mylopoulos, Christoph Quix, Colette Rolland, Yannis Manolopoulos, Haralambos Mouratidis, and Jennifer Horko , editors, Advanced Information Systems Engineering: 26th International Conference, CAiSE 2014, Thessaloniki, Greece, June 16-20, 2014. Proceedings, pages 503{517. Springer International Publishing, Cham, 2014. 23. Alessandro Rossini, Juan De Lara, Esther Guerra, and Nikolay Nikolov. A comparison of two-level and multi-level modelling for cloud-based applications. In Gabriele Taentzer and Francis Bordeleau, editors, Modelling Foundations and Applications: 11th European Conference, ECMFA 2015, pages 18{32. Springer International Publishing, Cham, 2015. 24. Juan De Lara, Esther Guerra, and Jesus Sanchez Cuadrado. When and how to use multilevel modelling. ACM Trans. Softw. Eng. Methodol., 24(2):12:1{12:46, 2014. 25. Ulrich Frank. Domain-speci c modeling languages - requirements analysis and design guidelines. In Iris Reinhartz-Berger, Aron Sturm, Tony Clark, Yair Wand, Sholom Cohen, and Jorn Bettin, editors, Domain Engineering: Product Lines, Conceptual Models, and Languages, pages 133{157. Springer, 2013. 26. Ulrich Frank. Specialisation in business process modelling: Motivation, approaches and limitations.