METAMODEL Metamodeling, or meta-modeling in software engineering and systems engineering among other disciplines, is the analysis, construction and

development of the frames, rules, constraints, models and theories applicable and useful for modeling a predefined class of problems. As its name implies, this concept applies the notions of meta- and modeling

"Metamodeling" is the construction of a collection of "concepts" (things, terms, etc.) within a certain domain. A model is an abstraction of phenomena in the real world; a metamodel is yet another abstraction, highlighting properties of the model itself. A model conforms to its metamodel in the way that a computer program conforms to the grammar of the programming language in which it is written. ommon uses for metamodels are! As a schema for semantic data that needs to be e"changed or stored As a language that supports a particular method or process As a language to e"press additional semantics of e"isting information #ecause of the "meta" character of metamodeling, both the pra"is and theory of metamodels are of relevance to metascience, metaphilosophy, metatheories and systemics, and meta-consciousness. $he concept can be useful in mathematics, and has practical applications in computer science and computer engineering%software engineering, which are the main focus of this article.

M&$A'() &**

Meta-process modeling is a type of metamodeling used for the analysis and construction of models applicable and useful to some predefined problems. Meta-process modeling supports the effort of creating fle"ible process models. $he purpose of process models is to document and communicate processes and to enhance the reuse of processes. $hus, processes can be better taught and e"ecuted. (esults of using meta-process models are an increased productivity of process engineers and an improved +uality of the models they produce Meta-process modeling focuses on and supports the process of constructing process models. ,ts main concern is to improve process models and to ma-e them evolve, which in turn, will support the development of systems../0 $his is important due to the fact that 1processes change with time and so do the 'rocess Models underlying them. $hus, new processes and models may have to be built and e"isting ones improved2../0 1$he focus has been to increase the level of formality of process models in order to ma-e possible their enactment in process-centred software environments2..30 referring to!.40 A process meta-model is a meta model, 1a description at the type level of a process model. A process model is, thus, an instantiation of a process meta-model. ...0 A meta-model can be instantiated several times in order to define various process models. A process meta-model is at the meta-type level with respect to a process.2 ./0

$here e"ists standards for several domains! *oftware &ngineering *oftware 'rocess &ngineering Metamodel (*'&M) which is defined as a 'rofile (5M6) by the )b7ect Management 8roup. $here are different techni+ues for constructing process models. 1 onstruction techni+ues used in the ,nformation *ystems area have developed independently of those in *oftware &ngineering. ,n information systems, construction techni+ues e"ploit the notion of a meta-model and the two principal techni+ues used are those of instantiation and assembly. ,n software engineering the main construction techni+ue used today is languagebased. 9owever, early techni+ues in both, information systems and software engineering were based on the e"perience of process engineers and were, therefore, ad-hoc in nature.2 ./0

Ad-hoc
1$raditional process models are e"pressions of the e"periences of their developers. *ince this e"perience is not formalised and is, conse+uently, not available as a fund of -nowledge, it can be said that these process models are the result of an ad-hoc construction techni+ue. $his has two ma7or conse+uences! it is not possible to -now how these process models were generated, and they become dependent on the domain of e"perience. ,f process models are to be domain independent and if they are to be rapidly generable and modifiable, then we need to go away from e"perience based process model construction. learly, generation and modifiability relate to the process management policy adopted (see 5sage :orld). ,nstantiation and assembly, by promoting modulari;ation, facilitate the capitalisation of good practice and the improvement of given process models.2 ./0

Assembly
$he assembly techni+ue is based on the idea of a process repository from which process components can be selected. (olland <==> ./0 lists two selection strategies! <. 'romoting a global analysis of the pro7ect on hand based on contingency criteria (&"ample ?an *looten <==@.A0) /. 5sing the notion of descriptors .@0 as a means to describe process chun-s. $his eases the retrieval of components meeting the re+uirements of the user % matching with the situation at hand..B0

(&"ample 'lihon <==A.>0 in CA$5(& (.=0) and repository of scenario based approaches accessible on ,nternet in the (&:* pro7ect .<D0.<<0) Eor the assembly techni+ue to be successful, it is necessary that process models are modular. ,f the assembly techni+ue is combined with the instantiation techni+ue then the meta-model must itself be modular../0

Instantiation
Eor reusing processes a meta-process model identifies 1the common, generic features of process models and represents them in a system of concepts. *uch a representation has the potential to FgenerateF all process models that share these features. $his potential is realised when a generation techni+ue is defined whose application results in the desired process model.2 ./0 'rocess models are then derived from the process meta-models through instantiation. (olland ./0 associates a number of advantages with the instantiation approach! <. $he e"ploitation of the meta-model helps to define a wide range of process models. /. ,t ma-es the activity of defining process models systematic and versatile. 3. ,t forces to loo- for and introduce, in the process meta-model, generic solutions to problems and this ma-es the derived process models inherit the solution characteristics. 1$he instantiation techni+ue has been used, for e"ample, in CA$5(&,.=0 (olland <==3,.<0 (olland <==4,.</0 and (olland <==@.<30. $he process engineer must define the instances of conte"ts and relationships that comprise the process model of interest.2./0 (olland <==> ./0 lists numerous languages for e"pressing process models used by the software engineering community! &3 .40 ?arious 'rolog dialects for &')* .<40, )i-os .<A0, and '&A & .40 '*-Algol for ':, .40) as well as further computational paradigms! 'etri nets in &')* .<40 and *'AG& .<@0 (ule based paradigm in M&(6,C .<B0 A6E .<>0 Marvel .<=0 &')* .<40 $riggers in AG&6& ./D0 and M?'-6 .40). 6anguages are typically related to process programs whereas instantiation techni+ues have been used to construct process scripts../0