text:
MODELS The first two chapters of the thesis build the scientific context for the thesis by means of a comprehensive literature survey. Since it is hoped that some of this material can be used for textbook and/or course curriculum purposes, the aim is to have a somewhat greater inclusivity and level of detail than normally found in doctoral theses. This chapter deals with the current state of enterprise modelling; the following chapter shall discuss the various reference disciplines contributing to the frameworks relevant to the thesis. This chapter explores therefore with the basic terminology and scientific foundations of enterprise models: what a model is, model uses, types of models, the role of modelling in information systems, enterprise models, model representation and meta-modelling. The latter two topics are of great importance to the development of the framework and are therefore discussed in greater detail. What Are Models? Modelling is done in many disciplines, by many researchers from different philosophical backgrounds and in many different contexts. Hence the word model has acquired many meanings and definitions, resulting in what some authors refer to as the "model muddle" [EDMO99]. For purposes of this research, the following definition will be adopted: "A model is an abstract representation of reality that excludes details of the world which are not of interest to the modeller or the ultimate users of the model." [PRES97] In principle it is almost possible to use anything as a model of anything else; e.g. "cutlery on a table may represent the disposition of troops at the Battle of Waterloo" [ROBI97]. The "reality" that is modelled is usually referred to as the object domain and may be physical (e.g. the solar system), abstract (e.g. modelling social relationships in a group) or a combination (e.g. an organisation which consists of physical artefacts, legal entities, individuals, structure etc.). In most sciences, informational constructs rather than a physical representation (such as a scale model) are used to build the model. These constructs are then represented themselves by means of symbols, e.g. a UML diagram. This creates in effect a triad: from the real world (domain) one builds (by means of perception and conceptualisation) the conceptual model and, by means of signs or language, finally creates a representation of the model [SALT93]. This is illustrated in the meaning triangle below (fig 1) which is adapted and elaborated from [SOWA00]. V2: Conceptual Model (mental / "subject") P1: Perceive P2: Encode Abstract Codify Structure Write down … … V3: Model V1: Object Domain P3: Represent Representation (physical / "real") Signify Symbolize (symbolic) … Figure 1: The Meaning Triangle, adapted from [SOWA00]. Note that the conceptual model V2 reflects the model semantics (or meaning); and the model representation V3 is the model syntax. In practice, when referring to "the" model, the amalgam of both conceptualisation and representation is generally implied. Sometimes, a stricter interpretation is used, e.g. as in Presley's definition, may refer to V3 only. The meaning triangle can be a useful framework to position the various disciplines dealing with modelling (most of these will be discussed in the next chapter). Consider the following Methodology engineering will look more closely at building frameworks (modelling) of the processes or activities between the vertices V1 to V3, as well as at what form the representation should take. Meta-modelling can be seen as adding a second "meaning triangle" to the right of the first triangle, by taking the symbolic model representation as its object domain i.e. it models the modelling constructs used in the model representation: V3 of the first triangle is V1 of the second. Note that it is possible to chain a third triangle (meta-meta-modelling). The executable models used in enterprise integration blur the distinction between the represented model V3 and reality V1 i.e. the model becomes an intricate part of the object domain and V3 is conflated into V1. Deductive models, as e.g. developed in ontology research, integrate the conceptual model V2 (semantics) and representation layers V3 i.e. a modelling notation with extremely rich semantics is used so that V3 and V2 are conflated. Some general notes about modelling can also be illustrated by means of specific elements of the meaning triangle. The following deserve some further discussion. V1: The real domain/object. A real object does not need to be material, and can even be fictitious. Although some objects are purely physical (a river, the physical world, a molecule, a virus), many objects modelled in the social sciences include a fair amount of conceptual or non-material elements: the economy, an enterprise, or a war. Similarly, an object does not necessarily need to exist to be modelled: virtual reality games model non-existing castles, life forms and planets; toy shops sell plastic models of the starship Enterprise. V3: Model representation. Engineers and architects often build physical models to represent a model. In some cases a physical model is used in V3 e.g. a small-scale model of a building. One can even construct a physical model of a conceptual object domain such as the Dutch coloured- fluids-in-pipes model (physical V3) of the Dutch economy (abstract V1). P2: The abstraction relationship. This conscious process is referred to as modelling the object. There are various methodologies and guidelines available, depending on the discipline. E.g. mathematical modelling of physical phenomena as opposed to, say the theoretical models of socio- economic objects. The modelling process actually forms the main body or purpose of entire disciplines such as statistics, the cognitive sciences or econometrics. P3: The representation relationship. The model is not an exact duplicate of the real object, which implies a partial fit or projection relationship. Many of the model's qualitative attributes refer to this relationship: simplicity, accuracy, completeness and time lag. P3 is a bi-directional relationship. The modeller represents his/her mental model V2 by means of V3. The representation V3 then serves as a communication tool for the reader to "reconstruct" the mental model V2 in the reader's mind, hopefully as close as possible to the mental model V2 held by the modeller. A close correspondence between V1 and V3 lessens the cognitive effort required in reconstructing the mental model V2 e.g. in a scale model, photograph or graphic film scene. Modelling is a natural human activity through which we make sense of the world around us [DEME83]. Without building mental (internal) models of the world, we could not function: we expect a hammer to fall when we release it and a ball to roll when we kick it. We know that a container can hold water but a flat surface will not. We expect the sun to rise in the morning and we know what to do when we walk into a restaurant. However, this does not imply that our models are necessarily correct (does the sun revolve around the earth?) or that we share common models (what a Roman Catholic sees as "a priest celebrating Mass" was described by Sartre as "a man drinking wine in front of women on their knees"). Scientists construct models of complex phenomena in an attempt to understand or predict the "real world". In the social sciences, these models are akin to theories, in the sense of e.g. building a model of human cognitive visual perception. By contrast, a much clearer distinction between theories and models is drawn in the physical sciences [EDMO99]. In the information and business sciences, models are used for analysis, design and decision making, and hence geared at presenting the model user with the information necessary for that task, while omitting other irrelevant or detail information [WHIT98d]. Models range from simple, e.g. Newton's law of gravitational force, to complex , e.g. an econometric input/output analysis model of a country's economy. [BEER99] points out that models are necessarily limited, because of the limits of our sensation or perception (an epistemological limitation), and subjective "because individuals differ in acuity of perception and in pattern penetration". In addition, reality is often richer than the number and variety of constructs used in building the model i.e. the expressiveness of the modelling language limits the model [SALT93]. A distinction that is often overlooked, but quite important when discussing generic enterprise models, is the distinction between a model of an object and of the class of those objects. In some cases, the distinction is vague because the model of the class can easily be instantiated to apply to a specific case. E.g. a general macro-economic model can be tested and applied to a specific country's economy by estimating the parameters for the given country, though the estimation is not necessarily a trivial exercise. On the other hand, an organisation theorist may build a theoretical model of organisations in general e.g. how organisational structure affects communication efficiency. The model of the organisation theorist is probably fairly useless for anyone wishing to analyse a specific organisation because its object is (the class of) "organisations", not "an" (individual) organisation. A slightly finer distinction is found in physics: physicists are not interested in modelling a specific physical mass, molecule, atom or fundamental particle, just the generic molecule. Luckily for the physicist, (instances of) fundamental particles are perfectly interchangeable. When dealing with more complex objects, we have the additional burden of the variability between class instances e.g. not every patient's body will react in the same way to a drug, not every group of first year students is the same as another one of similar size etc. Model Attributes Inasmuch a model is about another object or entity, it shares many of the attributes of any information or data item [VANB99]. Accuracy: how well does the model represent its object? Although the final accuracy of, say, a prediction is a function of accuracy, completeness and reliability, the accuracy attribute refers to the intrinsic variables and functions within the confines of the model. Reliability: how dependable is the abstraction? Often an important criterion for the predictive capacity, it refers more to the process by which the abstraction was conducted. One can use a statistically large enough sampling, but the sampling frame may be inappropriate. Completeness: how many of the domain objects' attributes, dimensions or views are incorporated in the model? Verifiability: to what extent can the correctness or validity of the model be checked? A model needs to contain variables which can be checked through direct observation (empirical verification) i.e. comparison with the real world object. Validity: how well does the model correspond to the real world? This issue is expanded below. Relevance: how pertinent is the model with respect to the context of the use for which the model was developed? Models are often unfairly criticized to be inaccurate or too simplistic without taking into consideration the original motivation for the development of the model. Simplicity: how complex is the model? This refers to the number of dimensions or attributes that has been incorporated, and to the relationships between them. A simpler model is easier to communicate and verify but may be less accurate. This dimension is almost but not completely the opposite of completeness. Compactness: refers to the reduced number of elements in the model when compared to the object i.e. the degree of compression. Fewer model elements often imply a more compact model but not always: the classic Newtonian model of the physical universe was simpler but Einstein's more complex general relativity model more compact because it combines several different sets of laws into one set. Timeliness: what is the time lag between changes in the underlying object and the corresponding model? Modelling the global weather to a great degree of accuracy would be slower than waiting for the weather to happen; the time lag is due to the model complexity itself. Modelling the economy suffers from the problem of time lags in measuring some of its variables; as does the actual accounting model of many organisations. Cost: how many resources need(ed) to be invested to develop and maintain the model? This refers primarily to financial and human resources, but can be extended to computational (algorithmic and storage) requirements. Note that these attributes are not fully orthogonal e.g. model cost may correlate (to a degree) with accuracy, timeliness with relevance, completeness with reliability and compactness with simplicity. The Philosophical Bias of Models The presence of a modeller guarantees that there is no such thing as an absolute, perfect model. All modelling remains a subjective activity since the modeller, because of her Weltanshauung, introduces bias into the (conceptual) model. There are two extreme viewpoints. The subjectivists will argue that much of what is called "reality" (V1 is in the meaning triangle) is really a social construct and hence all models of complex phenomena are intrinsically subjective. At the opposite end of the spectrum is the naïve realist claiming the existence of an observer-independent physical world which can be perceived and modelled to whatever degree of accuracy [HIRS89]. Constructivism is very prominent in the social sciences whereas physical scientists tend to have realist leanings. Thus this philosophical debate rages especially strong in IS, which draws its roots from both disciplines. The soft systems methodologists (SSM) claim that "models are not would-be descriptions of parts of the world. They are abstract logical machines for pursuing a purpose, defined in terms of declared worldviews, which can generate insightful debate when set against actual would-be purposeful action in the real world" [CHEC92]. This is in sharp contrast to the often unspoken conviction of many systems engineers (often of the so- called "hard modelling" school), who may believe that there is such a thing as a best or most accurate domain model [FORB95]. My personal position is somewhere in the middle of the spectrum, though with strong Platonic-realist leanings. As [FLYN96] points out: "organisations [are] socially constructed phenomena, whose many aspects may be perceived differently by different observers, but which are able, by negotiation, discussion or some other method, to formulate a common view for a period of time, containing a minimum of inconsistencies." On the other hand, there seem to be sufficient commonalties across organisations and the members of the social groups studying these, that a large number of generalities, common perceptions and collective vocabulary has been established. The use of different model views (see below) can, to a certain extent, help reduce the subjective bias in models. I think that my realist's position, especially in respect of data models, is strengthened by Avison and Fitzegerald's "admission" that the theoretical subjectivist arguments may not necessarily apply it in practice (my italics): "The assumption in data analysis that it is possible to model reality is questionable […] The data model can only be a model and not the model of that part of the real world being investigated. In cannot reflect reality completely and accurately for all purposes. Even if data analysis has `gone according to plan', the resultant data model cannot objectively represent the organization. It is a subjective view distorted by the perceptive process. Having said this, however, the data model derived from data analysis usually proves in practice to be suitable for the purpose of building a database." [AVIS95] Why Do We Model in Information Systems? Before building a sizeable information system, it is necessary to develop a model; just like one needs a blueprint as the basis for the construction of a large building. The IS model serves a number of different purposes: [WHIT98d, PRES97, LAND87] Modelling assists in the analysis of the enterprise and the subsequent design of the physical systems. It helps our understanding of the complex system; in part because it reduces the complexity by breaking the system into smaller pieces. It allows us to communicate a common understanding. It can be used to obtain stakeholder buy-in, especially if all interest groups have a say in building the model. It can serve as a documentation mechanism e.g. for ISO9000, quality control etc. Some types of models provide simulation and forecasting decision support. These can assist decision makers in controlling, predicting and optimising decisions. The increasing scope and complexity of information systems (such as data warehouses, ERPs and on- line distributed applications), and developments in system development methodologies (OO, CASE, IDEs, UML), are driving the transition from code-centred to model-centred systems development [BEZI99], also claimed to be heralding the paradigm shift from OOT to MOT (model-oriented technology [BEZI98a]. Types of Models There are many typologies for the classification of models. Edmonds [1999] lists a large number of generic classification schemes, e.g. according to the medium in which they are expressed: physical (e.g. a scale model of an aeroplane), mathematical (e.g. structural equations model), computational (e.g. a computer program) or linguistic (using natural language). After listing many more, he concludes that it is impossible to make a comprehensive list of model typologies. [LYTT96] distinguishes the following types, depending on the representation used to describe the model: iconic (looks like the reality it is intending to represent, e.g. a scale model); analogue (similar in relations but using different entities e.g. a map); symbolic (uses abstract symbols e.g. a decision- making model); schematic (uses a diagram or chart to represent the model state); mathematical (uses mathematical symbols e.g. equation model); verbal (English description) or conceptual (theoretical explanation). The following are some model typologies of relevance to information systems models. Conceptual versus data model. The conceptual model captures all relevant static and dynamic aspects, i.e. all rules and laws etc. of the universe of discourse. The data model describes what data should be captured by the information system [OLLE93]. Viewable and executable models. Some models are used for communicating views of the system during the analysis and design stage of an IS whereas others, e.g. those expressed in programming language or similar formal notations, are directly executable by the computer [VANH99]. Active and passive models. Once a passive model is created, it is independent of its subject (or domain). Subsequent changes in the domain are not (automatically) reflected the model. This is typically the case for most system development methodologies. In an active model, the relationship between the model and its subject is maintained so that the model reflects the current state of its subject. This synchronisation, typical of control systems, does not have to be immediate [GREE98]. An active model is similar to the "living model" of [WHIT97a]. Static or dynamic models. Static models give a static representation of a (usually dynamic) system e.g. the types of objects in the system and their flow paths through the system. Dynamic representations describe the behavioural aspects of the system and are typically used in a predictive manner e.g. by means of "what-if" scenario analysis [WHIT98]. Views and Layers in Models Views: Modelling from Different Perspectives Modelling the real world involves abstraction and subjective perspective. Ask a farmer, an economist, a biologist, an artist painter and a chef to describe a strawberry and each will most likely produce a radically different description. Or, in an enterprise context, consider the widely different conceptualisations of a production process as made by the shop floor worker, cost accountant, production manager, PERT analyst, maintenance engineer, psychologist, Marxist philosopher and BPR consultant. In order to describe an organisation from as many perspectives and as completely as possible, models adopt the structuring concept of model views. Views accommodate the different needs of the model users, as well as the different types of information available about the enterprise. Model views are based on subsets of modelling concepts: "A single model […] would be overwhelming in complexity. Therefore, we need a way to separate concerns such that we can check consistency between alternate specifications of the same system." [FARO97] Hence, the viewpoint concept - each viewpoint looks at the whole system, but uses modelling concepts specific to a defined subset of modelling concerns. The different viewpoints are not necessarily different levels or layers in the model, but different, often complementary, aspects or abstractions of the same model. This can means that a single concept in one view may be represented by multiple concepts in another view. Views must have some overlapping modelling concepts to enable users to relate the models to each other. If the common ground between the views is too small, it may create cognitive problems. Exactly how many views are necessary for modelling organisations is not evident [FRAN99a] and almost appears to be more a matter of academic taste. The following serves purely to give a flavour of the breadth in the number and types of views that are possible. Modellers in the early days of programming used process flowcharts only. Relational database modelling often restricts itself to two views: dataflow and entity-relationship modelling. The ARIS (Architecture of Integrated Information Systems) methodology [SCHE94, SCHE98, SCHE99] uses four viewpoints: data, function and organisation as the three fundamental views and a fourth view which is the resource view when modelling the information systems or the control view in the business system context. These views are similar in nature (though slightly different in implementation) to those defined in the CIMOSA (Computer Integrated Manufacturing Open Systems Architecture) framework [BERN96a]. The ARRI (Automation & Robotics Research Institute) adopted five views: resource, activity, process, organisational and business rule [WHIT98]; though they are very different to the five used by the ODP- RM (Open Distributed Processing Reference Model): enterprise, information, computational, engineering and technology. The Zachman framework [ZACH87, SOWA92] requires six "dimensions" to be considered: data, process, network, people, time and purpose. Bubenko proposes the use of eight interrelated sub-models or views to model the enterprise: objectives (why), concepts (what), activities (how), actors (who), functional and non-functional requirements, configuration and information system [BUBE00]. In the WORKS approach, which is based on the CommondKads knowledge-based systems modelling, nine views are introduced: organisation structure, organisation processes, staff, working tools, data view, communication and cooperation, expertise, (knowledge) sources, and strength/weakness view. [DECK97]. The UML (Unified Modelling Language) allows for at least ten different types of diagrams: use-case, class, object, sequence, collaboration, statechart, activity, component, deployment, and the package diagram [BOOC99, HALP99], though no methodology uses all diagram types in any given situation. Note that the discussion above refers to conceptual views. In database theory, another hierarchical set of views or perspectives called "schema" is introduced. As an extension of the CODASYL framework, [HAY00] mentions the following four perspectives in reference to corporate data models. The conceptual schema representing the organisational or "full" view of the data. The external schema being the individual user's view of the data, depending on the user's function or data needs. This is a subset of the conceptual schema. The logical schema represents the view of the DBMS of the data, typically in terms of tables, columns, network segments etc. The internal schema represents the physical data structure as stored internally on the computer system. For purposes of this research, only the conceptual schema or perspective will be of relevance when discussing modelling views, unless indicated otherwise. Layers: Modelling at Different Levels of Detail or for Different Purposes An equally important issue is to model, not only from different viewpoints, but also at the appropriate level of detail. Typically, a model should be available at different levels or layers of detail (by means of an "explosion" or "zoom" facility) whereby the scope of the model increase or decreases. Some of the literature refers, confusingly, to these layers as views, whereas, in fact, model detail level is orthogonal to the views dimension. This means that a model may simultaneously have a number of different views, each at different levels. Sometimes, the system is not modelled in more detail, but for a different type of user/purpose, e.g. a shift from conceptual to implementation. Although the latter "layer" will require more detail, there is also a shift in emphasis or purpose. This may lead differences in the model that are not just a matter of detail. Systems engineering has traditionally recognised two different scopes in its models: the business model as opposed to the system model, although the latter can then be further specified into analysis and design or, as in ARIS, requirements, design and implementation models. MEMO (Multi Perspective Enterprise Modelling) differentiates between three levels (confusingly referred to as "perspectives"): strategy, organisation and information, though each perspective needs to be structured according to four aspects (structure, process, resources and goals), thus requiring a total of 3 x 4 = 12 foci to be considered [FRAN99a]. CIMOSA proposes three different levels: generic, partial and particular (each structured in the four views organisation, resource, information and function), leading to 12 cells. Zachman's six dimensions are to be modelled at six different levels (ballpark view, owner's view, designer's view, builder's view, detailed representation and functioning system), creating a potential 36 different sets of models [COOK96]. Problems with Views and Levels The only consensus in the "methodology jungle" is that there should at least two views: a static data or information-oriented view, and a dynamic activity or process-change view. Similarly, there is widespread agreement that there needs to be different levels of models, at least for sufficiently complex domains, ranging from the high-level overall view of the enterprise which is technology and system independent, down to a much more detailed low-level technical implementation. However, there is still no consensus on the kinds of views, nor on the number of layers of detail required. The use of views and levels results in a key issue in modelling theory: the integration and correspondence of these different levels and views. Although correspondence can be enforced to a certain extent by the modelling tools, a number of practical and conceptual problems remains [FRAN99a]. Whitman identifies four key issues with respect to the synthesis of views: [WHIT97d] Potential gaps in view: since each view omits certain aspects, any single view is not sufficient for an analysis of the domain. E.g. to model a process in UML requires either extending (customising) one type of diagram or bringing together the information contained in several different diagrams. Artificial wrappers: in order to populate higher or intermediate levels of enterprise models, some abstract(ed) entities (which are to be broken down in more detail at the lower levels) are often necessary, but these are not necessarily readily recognised by individuals familiar with the real domain. An example could be the failure of a line employee to understand the concept of "party role" (representing both customer and supplier), or the accountant's term "asset" to describe machinery, instruments, furniture, buildings and parts. Differences in structure: some views may allow certain structures which cannot be accommodated easily or naturally in other structures. Both activity and process views facilitate hierarchical decomposition whereas the data view does not necessarily allow this. Model ambiguities: concepts that are easy to represent in one view of the model may require additional information, different or additional constructs, or force artificial decomposition to represent in other views. Another important problem is that of context: within an organisation, different departments may refer by the same name to different concepts, or use different names for the same concept [HICK99]. Many of these issues have not been resolved by the current generations of modelling and CASE tools, as discussed more fully in [HAY00]. The Process of Modelling Despite the best efforts and claims of methodology and systems engineers, modelling remains as much an art as a science. Modelling a domain requires a combination of aptitude, training and experience. Many guidelines exist to assist the aspirant modeller, but the modelling process is often a subjective, personal experience. Formalising the Modelling Process Methodologies attempt to structure the system development process, of which the modelling activity forms an important part. A methodology generally prescribes a set of steps or activities, along with the adoption of specific modelling tools or representations. Many large organisations, and IT consulting companies in particular, will develop or enforce their own brand of systems development methodology, which will lay down specific modelling activities, deliverables and notations. Other organisations may adopt off-the-shelf methodologies, often in conjunction with a specific tool e.g. the Rational Process with Rational Rose for UML [BOOC99]. The main purpose of a methodology is to obtain consistency and maintain minimum quality standards. This is often linked to project management, metrics collection and quality assurance programs. Where quality assurance programs are to be formally accredited, much heavier demands are placed and the degree of formalization increases dramatically, as is the case for e.g. ISO9000-3 compliance or, for a model more specifically adapted to information systems environment, the CMM (Capability Maturity Model) of the SEI (Software Engineering Institute). The latter specifies five levels to characterise the maturity of an organisation's software development process. Already from the second level there is the requirement to have formal policies in place to ensure repeatable processes. See [MULL97] for an interesting suggestion on how the CMM can be specifically applied to a (data) model. Nevertheless, even expert modellers will often model the same domain in different ways, suggesting that no one optimal model for a given domain exists. Although methodologies are discussed elsewhere, a couple of general issues are worth mentioning. Iterative Process and Holistic Approach Many methodologies assume or imply that modelling is a linear activity. In reality, it is an iterative process whereby the domain is explored by means of initial "rough" models, which are gradually refined and amended [LUKO96]. This is particularly advisable when modelling a vague domain [MENZ96]. Unfortunately, a "first-cut" model often tends to stifle novel approaches and conditions the modeller's mind into a set pattern. Frequent interaction with other domain modellers and users is therefore imperative to prevent "straight-jacket thinking", especially in the early stages of the model. This exploratory stage of modelling often benefits from one of the many creative thinking approaches, such as brainstorming sessions. Additionally, it must be acknowledged that modelling a large and complex domain requires a holistic approach. "It is common experience that attempts to solve one piece of a problem first, then others, and so on, lead to endless solutions. You no sooner solve one aspect of a thing than another is put out of joint. And when you go back to correct that one, something else goes wrong… This is the great argument against attempt to solve [modelling] problems piecemeal." [WITT94, p.15] Similarity of Modelling to Other Development Processes A number of authors has pointed out the similarity between the model development process and other processes. For instance in [WORT00], the following five similarities of product development with enterprise model development (and model life cycle management): Both require a versioning mechanism. It is essential to describe both from different viewpoints (possibly requiring the use of different formalisms), depending on purpose. The development status needs to be tracked until the design is satisfactory. There needs to be a way to record commonalities and differences if more than one variant of a particular product is to be designed. A hierarchy or decomposition mechanism is essential to hide or expose complexity, usually by means of both a zoom in/out facility as well as a "BOM" recursive component type approach. (as discussed in the section on model "levels") In a similar vein, the Zachman framework was initially derived for the construction engineering sciences using architecture principles [ZACH87], but was then applied to the field of IS architectures. Some Modelling Principles Many of the following modelling principles find their origin - or equivalent - in the world of object- oriented world. E.g. OO models will tend to "inherit or import" an object's intrinsic high cohesion from the real world into the model. The two fundamental principles in the design of complex models are [WITT92]: Loose coupling/high cohesion. Cohesion refers to closely related concepts which must be grouped together, often in a single higher-level concept. This allows the use of information hiding or "black boxes" where the detailed, closely interrelated information can be hidden into one single package. The loose coupling refers to the opposite principle i.e. the grouping of concepts in such a way that the relationships between concept chunks are minimized. This has the advantage of relative design/analysis independence, easier conceptual understanding and quicker model evaluation. The generous use of abstraction, especially in the high-level design. There are many abstraction mechanisms available, such as looking for common attributes, the creation of complex objects and the identification of strong cohesion or one-to-one relationships. Other suggestions on how to structure and classify objects rely on the use of structured reference sets wherever possible, e.g. controlled word lists, ontologies, taxonomies, and thesauri [NETW96]. A final point of note, perhaps better labelled as an "anti-principle", is the fact that modellers often tend to overemphasize the discreteness and static nature of the real world. It must be realized that there are often unclear boundaries between different concepts, a phenomenon known as gradience, fuzziness, impreciseness, vagueness or fluidity [HONK98a]. Many "discrete" concepts really refer to a continuum of situations or objects. This is not limited to intrinsically fuzzy concepts such as quality, taste or preference. A common example is the definition of a customer which may or may not include any of the following. A prospect who made an enquiry. Someone who requested a quote. Someone who first accepted a quote verbally but never confirmed the order in writing. Someone who placed an order but cancelled it. Someone who placed an order for an out-of-stock or unavailable item. Someone who placed an order but never received delivery. Someone who received a delivery but returned it. Someone who received a delivery but never paid for it. Someone who has bought but since moved out of the organisation's operations area e.g. someone who emigrated to Japan. Someone who has not ordered anything for a "long time" (how long?) e.g. someone who hasn't bought nappies in the last 10 years. Someone who ordered in the past but has no reasonable ground to order in the future (due to changes in life style, purchasing power, status etc.) e.g. someone who has decided to manufacture your products herself. Someone who made a formal decision to switch suppliers to the competition (an important legal or status issue if the customer was the Queen of England or the US Department of Defence). Related is the tendency of many modellers, especially those from the "hard modelling school", to over- emphasize the static aspects of reality. The world is then often described into entities and relationships between entities, losing sight of the more problematic dynamic changes in reality which are much more difficult to model. The attempt to attach a single verbal "one-to-one" label to real-world entities that are slowly changing their identity, presents more than just philosophical problems. It is perhaps not surprising that some authors suggest that models should not start with a domain data model but with user interactions or system goals analysis [KAAS96; LARM98]. Model Validation and Verification An important activity in the modelling process is that of model verification and validation [CHEN98]. Indeed, this introduces a strong ethical dimension: an invalid or incorrect model - especially if it is used for subsequent system design - has the ability to impact very negatively on the profitability and hence survival and growth of an organisation, as well as the quality of (work) life of its employees and other stakeholders. Therefore modelling is a serious and responsible activity, and choosing the correct methodology as well as ensuring proper model validation is "as much an ethical consideration as a rational one" [JAYA94]. Model verification focuses on the syntactic level: it is the activity that checks that no modelling rule has been violated e.g. illegal constructs, incorrect use of symbols, inconsistencies between different model views etc. With the increased use of integrated and sophisticated modelling and CASE tools, much if not most of the verification is automated. Model validation is checking that the model is a true (or at least valid) representation of the real world. This involves both semantic (what do the modelled concepts really mean) and pragmatic (will the model be used and interpreted properly) issues. Model validation is often an informal process [BERG00]. Several techniques can used such as paraphrasing the model in natural language, using graphical tools, simulation of the model, explanation generation techniques, various user-oriented graphical visualisation tools and translation into user-defined concepts. Because many of the stakeholders have a limited knowledge of modelling, this process is often not very satisfactory [FLYN96]. As Bergholtz points out, it is difficult even for experienced designers to validate a model. Indeed, there is a dearth of concrete, usable research findings in the area of model validation. Model validation is the major thrust of this research project and will therefore be discussed at much greater length further on in chapter 5. Enterprise Models The models of interest to this research are enterprise models. This section discusses the nature of, reason for, and the current state of enterprise modelling Definition of Enterprise Model and Corporate Data Model The definition of an enterprise model in the proposed ISO 14258 standard Industrial Automation Systems - Concepts and Rules for Enterprise Models is [WINC99]: "a representation of what an enterprise intends to accomplish and how it operates, which is used to improve the effectiveness and efficiency of the enterprise". The definition is elaborated on by means of the following note: "An enterprise model is an abstraction that identifies and represents the basic elements of an enterprise and their decomposition to any necessary degree that is used to improve the effectiveness and efficiency of the enterprise. It also specifies the information requirements of these elements, and provides the information needed to define the requirements for integrated information systems." Since the ISO standard is concerned mainly with automated systems, the enterprise models kept in mind by the standard setters are not necessarily representative. An enterprise model may have different purposes and uses e.g. documentation, standard setting, data warehousing, information architecture planning and the like. Hence a more inclusive definition is preferred. [FOX93b] defines an enterprise model as follows: "a computational representation of the structure, activities, processes, information, resources, people, behaviour, goals and constraints of a business, government, or other enterprise." The model can be either descriptive - describing an existing situation - or prescriptive - describing a desirable goal. This definition makes it clear that both static and dynamic aspects need to be captured in the model. A typical enterprise model will therefore include a number of views. A subset of the enterprise model is the corporate data model: "an abstract representation of the information requirements of all or part of an organisation, independent of functional boundaries with an organisation and implementation technology" [BRAN86]. The focus of the corporate data model is on the static information aspects, leaving out dynamic aspects of the enterprise such as processes, activities and behaviour. Some authors refer to the corporate data model as the organisational or enterprise data model. The literature is divided on the exact differences between the concepts of enterprise, corporation and organisation although it appears that the main difference is on the emphasis. The following descriptions are an attempt to summarize common usage as reflected in the literature and a number of dictionaries. It must be stressed that no description is meant to be definitive or even universally recognized (see the discussion of "concept gradience" above). Also, most of the terms have multiple meanings. Business: a private organisation aimed at making a profit from commercial activities. A close synonym is "firm". Can be very small in size as in a one-man business or small partnership. Enterprise: an undertaking or business activity. The emphasis is on the activity, not necessarily formalized and not necessarily but most often for profit. A close synonym is "venture". Can be used where the life is fairly short as in "virtual enterprises" (in the meaning of different businesses partners working together for one specific project). Corporation: a group of people formally acting as a single individual, especially in business. This stresses the independent (legal or formal) status and external identity. In many contexts, corporation refers to a specific legal statute in terms of company legislation. A close synonym is "company". Often carries a connotation of ""largeness" or "big size". Organisation: an structured body of people, an controlled and planned system. The emphasis is on the structure and relationships of the group, usually closely tied to the overall goal or purpose for which the group is organised. Often used when there is no legal status in local company law; also used for the many non-profit organisations. The notion of an organisation encompasses all of the previous concepts and more: e.g. a church or a sports club, except that it typically requires a group i.e. a number of persons. It is therefore not typically used for small or one-man businesses. In what follows, the distinctions - if any - between organisational, corporate and enterprise models will be ignored although a business model is perhaps more restrictive in that it may have a specific implied goal to generate profit. [WORT00] suggests the following historical evolution in enterprise modelling: Late sixties and early seventies: the development of modelling frameworks, especially defining modelling constructs and notations e.g. structured analysis and design techniques or IDEF. Seventies and early eighties: the development of (mainly academic) methodologies and project management environments for enterprise modelling such as GRAI or GERAM (see enterprise integration). Eighties and nineties: impact of enterprise modelling on commercial, practical methodologies and tools e.g. those used in the development of Enterprise Resource Planning systems: ARIS (for SAP R/3) and DEM (for BAAN). The Level of Detail in, and Size of, an Enterprise Model An enterprise model or a corporate data model does not require the same amount of detail as a system model. In a corporate data model, for instance, many detail attributes, subtype entities and domain could be omitted. Attempts to include too much detail doomed many enterprise modelling efforts and hampered the understanding and verification of the ones that were completed [SMIT98]. Indeed, the problem of representing large models is seen as one of the more serious challenges facing the modelling community. This is especially the case for the "flat models" still employed widely in the data modelling community where it has become known as the database comprehension problem [CAMP96]. Newer modelling approaches try to alleviate this problem by providing grouping constructs, such as the UML "package", and modelling tools commonly have multi-level model support by means of zoom in/out and expansion facilities. Thus the use of different levels when building an enterprise model is advocated. [INMO99] suggest the following three levels in the context of a corporate data model: The high-level model containing very broad definitions and all major categories i.e. the major entities, their definitions and the relationships between them. The mid-level model includes the details of each subject area, including keys, and attributes. The low-level data model contains the information about specific data design, possibly including physical characteristics such as data types and indexes. The debate about whether to include the low level in an enterprise model will depend on the purpose and context of the model. When defining an enterprise architecture, the first two levels will suffice; whereas the building of an ERP or data warehouse (which forms the background to Inmon's approach) will require a fully-fledged low-level model. In many models, additional levels are used so as to limit the number of concepts in any one sub-model approximately to the magic 7 plus or minus 2 entities - supposedly representing a human cognitive short term capacity limit. It is generally accepted that design or implementation-specific concerns such as keys, data types, interface objects and the like are not normally necessary in the enterprise model [SMIT98; BECK00] although a special exception is often made for relationship entities resulting from data normalisation. Perhaps a more practical guideline than Inmon's about the inclusion of keys and attributes in the mid- level model is based on the following taxonomy of entity attributes (with examples) [NEWT96]: Identifying: name, context, identifier, version, registration authority, synonyms. Definitional: define, explain and/or illustrate the concept. Relational: classification scheme, keywords, related data, type of relationship. Representational: representation category, form of representation, data type of data element values, range and domain of data element values, layout of representation. Administrative: responsible organisation, registration status, submitting organisation, comment. Based on this, I would propose that a high-level model should include only the definitional and relational attributes, along with those identifying attributes that are of a semantic nature (i.e. name, context, synonyms). Because of their scope, enterprise models tend to be huge and rather unwieldy. For example, the corporate data model of Saskatchewan Wheat Pool, a large North-American agro-business, consisted of about 500 entities (conflated into 300 tables) with about 10,000 objects. The entire repository comprises about 6 megabytes [LOCH98]. As will be seen, this is fairly representative of a typical enterprise model. The Purpose and Use of an Enterprise Model Many enterprise models have been developed with a single specific purpose in mind e.g. BPR (Business Process Reengineering), ISO 9000 certification, a data warehousing or systems analysis project. These "throw-away" enterprise models [WHIT97a] tend to lose accuracy and relevancy quite quickly, due to the fast-changing nature of the enterprise and its environment. ISO 14258 states the purpose of enterprise models as follows: "[enterprise] models can be constructed to analyze, guide the engineering of, and manage the operation of enterprises." [WINC99] Note that this was in the context of enterprise engineering. More generally, [KIRI00] states the uses of enterprise models as follows: Business analysis: problem detection. Business process re-engineering: defining new processes or developing new systems. Requirements engineering: facilitates the definition of the requirements specification. Organisational learning and knowledge management: forms the basis of knowledge propagation and amplification. Whitman ascribes the following (additional) uses to enterprise models. [WHIT97a] An enterprise model: Facilitates communication by providing a common language and understanding of processes. Serves as a baseline for the continuous improvement of existing processes (BPI). Documents existing processes and structures (e.g. for new staff induction, ISO 9000 certification etc.) Facilities the control of the real world business (management, optimisation, simulation, what-if scenario building). Can be used to integrate the information resources, systems and procedures of merging organisations. Is a starting point for information systems development including operational systems, database design, data warehouses, decision support system (DSS) and executive information systems (EIS). Corporate data models, more specifically, are claimed to result in the following benefits [LOCK98; VANS00] Better data architecture and database structure. Less data duplication/redundancy and fewer system interfaces leading to lower system coupling. Lower system development cost. Faster processing speed (due to less data fragmentation and higher system integration). Better quality data due to standardised data formats and reduced data redundancy (allowing better data update control). Reduced technology mix and resultant smaller spread in skills requirements. How Do Enterprise Models Differ From Other Domain Models? The most obvious fact is the domain scope of the enterprise model: the entire organisation. Since the domain is large, dynamic and complex, the resultant model is equally large and complex. This is unlike many engineering and computer science models of artefacts which are more controllable and exhibit predictable behaviour and more stable internal structures: although the solar system (as seen through an astronomer's eye) is physically much larger, it is arguably a far less complex system than your local small corner shop since the former can be modelled in a few sophisticated but deterministic mathematical equations. Some of the issues of size and complexity have already been dealt with in the section on model views and levels. The dynamic aspect - the continually changing domain - requires that the enterprise model must be continually updated to remain representative. The term living enterprise model has been suggested to describe the type of active model that remains current, auditable, and hence valid. The following are the main characteristics of a living enterprise model: maintainable, dynamic, expandable, de- compositional (multiple levels), consistent with enterprise metrics, driven directly from actual enterprise data, simulation capability and capable of accommodating non-standard activities [WHIT97a]. Another peculiar aspect of the enterprise model is that it can become part of the system it is modelling, either indirectly as an information repository which forms part of the information resources and flows in the organisation, or much more directly where the model participates in the organisational processes. This latter type of model is referred to as model enactment or executable model. Automated factories, supported by sophisticated CIM systems, are the textbook example. In fact, the entire discipline of "enterprise integration" (as discussed in the next chapter) is devoted to developing the necessary frameworks and constructs to drive this development. The self-referential aspect of executable or self- enacting models introduces unique modelling challenges (see e.g. [BRUN97]). Halfway between the descriptive and executable models are the "intelligent" models: (usually formal) models which possess logical ability and allow shallow or deep reasoning. For instance, given that an organisation's structures, roles, goals and resources are modelled, a specific person's resource allocation could be deduced automatically given his or her role in the organisation [FOX98]. Many of this models feature in the ontology discipline. A final key difference between "ordinary" and enterprise models concerns the introduction of a number of abstract, organisation-specific modelling constructs. Although each modelling method has its own set of modelling constructs (refer to the sections on meta modelling and semantic relativism below), many authors propose an additional set of more specific modelling constructs to aid enterprise modelling specifically. An example is the set of concepts introduced by Marshall in his high-level organisation model [MARS98; MARS00] as illustrated in figure 2 below. Although he uses three fundamental types of business objects in his model implementation (purpose, process and entity), his meta-model is based on three types (role, state and activity), which are orthogonal to the three aspects rule, plan and act. Role State Activity Contract define Purpose specify Pol icy Rule agree hold instantiate enact Entity Party schedule Objective to achieve Process Plan achieved by Actor perform guide affect Artifact Result Step Act effect cause Figure 2 Marshall's High-level Organisational Model [MARS00] Other authors similarly introduce their own sets of enterprise specific high-level concepts, such as the Inspired Frameworks Process Architecture [MCLE01]. Many others will be introduced in the main research discussion. Although these constructs, as abstract object types, can be seen as the upper-end of the enterprise model, an alternative is to see them as a kind of meta-model. It is hereby suggested that perhaps the best way to describe them is the term "mesa-model" i.e. at a domain-specific intermediate level between model and meta-model. Some Typical Problems with Enterprise Models The following problems are typically encountered with enterprise models; though perhaps not specific to enterprise models, these problems are often more pronounced in the context of the model size and scope [HUBE94; BROD82]. The development of the model is not documented, in particular the reasons or motivations for particular classifications and generalisations. After the initial information gathering phases, concepts are consolidated, standardised, abstracted and generalised, necessitating the use of new terms and concepts not readily understood or accepted by the user departments that were initially involved. Often the cross-referencing of the new "unified" terminology to the user terms is not documented explicitly in the model. This problem is exacerbated in larger organisations where the same term is given different meanings by different departments (e.g. asset, cost centre, order etc.) An "ideal" model is developed but takes the point of view of the IT department. The focus is on optimising processes or the automated information processing potential. This is linked with the "missionary" bias of the IT staff where 1 or 2 percent of the organisation's staff tends to "dictate" the terminology use for the rest. The excellent graphical capabilities of today's sophisticated tools make it easy to create copious volumes of nicely formatted documents. This great volume overwhelms users and the quality of the document presentation may disguise bad modelling or weak methodologies. There are still some gaps in modelling theory, which manifest themselves when modelling complex real-world domains such as enterprises. In particular, there are still unresolved issues in respect of modelling dependencies, incomplete knowledge, exceptions, anomalous information etc. Reference Models, Generic Models, Templates and Frameworks The purpose of a reference model is to serve as a guide for developing specific systems. Its main purpose is the stimulation of ideas and to provide a structure with pre-built components which can be used as is, changed or omitted. Often reference models represent generalisations or sub-sets of concepts [BAUE98]. Whereas an enterprise model refers to a specific organisation, a reference enterprise model has the "typical organisation" as its referant. For purposes of this research, no distinction will be made between reference and generic models. There appears to be an academic distinction in that reference models have a connotation of authority or standardisation and hence a more prescriptive flavour. With a generic model, the emphasis appears to be on the commonality between specific models or the sub-set of universal model elements. From the literature survey, it appears that this semantic distinction is all but ignored by practitioners or in the model content. Reference models differ from model templates in that a template is usually derived from previous modelling experiences and therefore at a fairly detailed level, often focussing on one particular area or situation. (Reference) frameworks, on the other hand, are at a higher level of abstraction. A framework is mostly concerned with the modelling environment, approach and process, and provides guidance on how to model in specific circumstances. A reference modelling framework may be concerned with how many and which views to adopt, what meta-model to use and how to go about the modelling process. This is in contrast to a reference model which is typically coded using a particular model notation and often restricted in applicability to a fairly specific modelling domain. Modelling Languages and Knowledge Representation The issue of model representation - the third vertex of the meaning triangle in fig 2.1 - is an extremely important one: what language is used to express the model and what are the allowable modelling constructs. The representation of a(n enterprise) model in a specific language has to do with the model syntax - as opposed to the model semantics which denotes the meaning of the model. ISO14258 defines the model syntax as referring "to the permissible arrangements of the representations of the elements and to the permissible kinds of relations". The representation (language) of a model fulfils a number of different roles or purposes [DAVI93]. It is a surrogate: we can reason with or manipulate the model instead of having to take action within the (real world) enterprise. It is a set of ontological commitments: a decision is made on what can be seen in the real world (and how it is seen) i.e. like "a strong pair of glasses that determine what we can see, bringing some part of the world into sharp focus, at the expense of blurring other parts." This has the disadvantage that certain aspects are left out (unavoidable, since abstraction necessitates it) but also the advantage of reducing the real world's complexity by allowing us to focus on the important or relevant aspects of real world. It is the medium for model computation (e.g. automatic deduction or code generation). Generally there is a trade-off between the computational efficiency (an important pragmatic consideration) and the expressive power of a modelling language. It serves the purpose of communicating the model to or between humans. The ease of interpretation is an important issue since model validation is primarily done by humans. These roles will form a thread through the remainder of this discussion. Modelling Language Taxonomy A model could be represented using the UML, first-order logic (FOL) or English. Each of these languages prescribes a particular vocabulary as well as rules of grammar that lay down how to construct "well-formed sentences" i.e. legal combinations of vocabulary words. English has a very large vocabulary (although most words carry many different meanings) and a very flexible grammar, whereas FOL uses a very restricted set of "key-words" and mathematical symbols with a very precise grammar. The UML uses a variety of graphical symbols as its "vocabulary" (e.g. a rectangle to denote a class or object instance) which can be combined only in a specified way (the "grammar" rules e.g. a generalisation (subtype/supertype) relationship arrow is a connector between two classes or two relationships, but not two comments or a relationship with a class). UML also specifies the meaning of the generalisation relationship i.e. in terms of inheritance of attributes. As an illustration of the variety that is possible, I have attempted to model the same model fragment (the fact that employees are persons) in a number of commonly used modelling languages in Table 1. Table 1: Different representations of "Employees are persons" "Employees are persons" (statement) English or "if an entity is an employee, it must be a person" (rule) Dutch Een personeelslid is een persoon. <complexType name="person"> </complexType> XML (Extensible <complexType Mark-up name="employee" Language) base="person" derivedBy="extension"> </complexType> FOL ( x ) ( employee (x) person (x) ) (First-order logic) KIF (Knowledge (forall (?x) Interchange (=> (member ?x employees) Format) (member ?x persons))) public class Person { … } JAVA public class Employee extends Person { … } persons employees Set theory (Venn diagram) Person UML Employee Myers proposed three well-know taxonomies of programming and specification techniques: one for programming systems, one about program visualisation and one for specification techniques. The latter is of particular interest to modelling and [MYER90] lists the following techniques. Textual languages Flowcharts Flowchart derivatives Petri nets Data flow graphs Directed graphs Graph derivatives Matrices Jigsaw puzzle pieces Forms Iconic sentences Spreadsheets Demonstrational The following discusses some important aspects with respect to the options and choice of a suitable modelling representation. Graphical Versus Textual Representation A continuing debate in the area of modelling is whether modelling languages should take a graphical form or a linear/text form [SARR96]. For the interface with humans, the so-called external representation of a model, graphical languages seem to have a strong intuitive appeal and, although not everyone is equally adept at interpreting two- dimensional graphical representations, there is evidence that this skill is at least partially an acquired one [KREM98]. There are a number of important psychological advantages in favour of using visual languages: Human abstract reasoning appears to be pictorial in nature; and some authors claim that most thought processes may be transformations of pictures. In any case, pictures appears to be computationally much more efficient for human computation than linear text. Visual organisation of data is a way to increase the limit of the capacity of short term memory by using the chunking mechanism. The human mind can store sensory data in great detail. It must be noted, however, that these claims are not necessarily shared by all researchers. For example, [JARV88] claims that "most of the proponents of graphics have never tested their claims. Further, when those tests are performed, the results are contradictory and inconclusive." Some tests have indeed indicated that especially novices may have more difficulty in interpreting visual data than textual expressions. [GREE91] reports that a number of tasks took longer when subjects were given graphical instead of textual expressions. More recent research is less critical, although [KELL98] still points out the lack of empirical evidence. Perhaps the evolution of computer technology (faster hardware with more sophisticated GUIs) has swung the balance conclusively in favour of graphics? Graphical model representation remains thus the most popular mechanism for documenting and specifying models to humans. In fact, considerable research is underway to investigate the use of three- dimensional (3D) modelling notations. [KENT97] argues that one single 3D model can integrate all the information of several types of two-dimensional diagrams: "indeed, it appears that the 2D UML diagrams are simply projections of the 3D model". Formality of Model Specification In contrast to the "human interface", computer storage and processing of any model is normally facilitated by means of an appropriate internal representation language which is non-graphical in nature. Computer science has the entire sub-discipline of Knowledge Representation (KR) devoted to the study of the philosophical foundations, expressive power, computational efficiency and design issues of languages for the computer processing of knowledge. Sarris puts it as follows: "from ways to conceptually model enterprise semantics in the form of objects, processes, relations and rules, languages and fundamental constructs for integrating heterogeneous models, to CASE and data dictionary/repository technologies for effective model management and reuse, each challenge emphasizes a different aspect of the same underlying problem: knowledge representation" [SARR96]. A more recent, quite comprehensive overview of KR can be found in [SOWA00]. It must be noted that, for our purposes, the important issue is not the technical one of internal memory representation of knowledge (i.e. the binary code) but the "apparent" internal representation used to ultimately mediate the model to the user (although normally through an additional "top layer" front-end user-interface, which is often GUI-based) or as used to interchange data between modelling tools. The main concern with a computer-centred modelling language is its degree of formalism. The following distinctions can be made, although in reality these form part of a continuum [LUKO96]. Formal techniques: have a formal syntax and semantics. They are typically based on a mathematical theory such as set theory or logic algebra. Examples are KIF, PIF, KL-ONE, etc. Semi-formal notation: has a formal syntax but informal semantics. Examples are Conceptual Modelling Language (CML) or UML (without OCL annotation; [GEIS98] argues that it can be considered as a formal language if OCL is added, see also [EHRI99]). Informal notation: has an intuitive syntax and semantics. Examples are natural language (English), Object Role Modelling (ORM) [BECK98] and mind maps. In theory, a formal technique will, given the appropriate deduction engine, not only allow for fully automated deduction abilities - including automatic code generation and database interrogation, but it can also serve as the foundation of a fully executable model [EHRI99]. In fact, the development of a model-equivalent computer programming language has been argued i.e. where the same language is used to analyse as well as implement (or code) the system. [LIDD95] discusses some of the theoretical difficulties including Turing completeness and impedance mismatches (e.g. conflicts between variables, type and classes; persistent versus transient data; imperative/declarative processing conflicts etc.). The trade-off for the power and precision of a formal language is the fact that formal model specification appears to be a tedious, error-prone and labour-intensive process, judging from the many person-years of labour that have gone into e.g. the development in enterprise ontologies. Arguments in favour of formal methods notwithstanding (see e.g. the "seven myths of formal methods" [HALL90] and "seven more myths of formal methods" [BOWE95]), formal specification techniques have not made major inroads yet into the enterprise modelling world. [DAVI93] argues that the selection of the KR language (and its degree of formality) should match the "spirit" of the language with the domain at hand, rather than the forced use of one specific "use-for- everything" language which necessitates the invention of all sorts of creative work-arounds, extensions and ad-hoc constructs. Since enterprise models are often meant to bridge between an informally stated purpose (the requirements) and a (formal) system implementation, it is perfectly acceptable for a model to be specified using a semi-formal notation. Expressiveness and Semantic Relativism of Modelling Language The representation ability of a modelling language is composed of two elements [SALT93]. Its semantic relativism: the degree to which it can represent different conceptions of the same world. Its expressiveness: the degree to which it can directly model any particular real world concept. The semantic relativism of a graphical language is directly related to the number of different views supported by the modelling language, e.g. the UML has 9 or 10 different diagrams, each modelling a particular model view whereas an ERD or DFD each represent only one specific view. For modelling enterprises, it is necessary to be able to model dynamic as well as static aspects; an ERD or class diagram does not allow for the dynamic aspects. General KR languages with (a few) very primitive constructs (e.g. node, link, slot, grouping) are much more relativistic from a semantic viewpoint. The expressiveness of a language relates to specific language constructs (or primitives) that support the modelling of a particular domain. For instance, if one models an enterprise, it helps if the modelling language provides enterprise-specific constructs. Table 2.2 below lists some typical primitives (and their variants) against which [MORA94] evaluated a number of KR languages. Including more primitives into a KR language increases its expressive power and makes for much more succinct models. [GOGI95] specifically compares and evaluates the expressiveness of KR symbolisms in terms of their "representational succinctness" i.e. how short they can represent a model. The trade-off lies in the computational overhead as well as the increased complexity of the modelling language. Also, an increase in primitives often allows multiple alternative ways of modelling a given situation, an attribute which makes model translation, inspection and validation much more difficult. Table 2: Some enterprise modelling primitives in KR languages [MORA94]. Primitive Variants of primitive Activity Plans; business processes; events Goals Task; options; goal; business concern; requirements; problem; objectives Agent relationship Responsibilities; delegation; authority; agreements; commitments Resource Agents; place; space Time Organisation Culture; policy; groupings Uncertainty With respect to the modelling language expressiveness and semantic relativism, there is a choice between the following modelling paradigms. A combination of classic systems engineering modelling techniques. Classic SE techniques such as DFD, ERD, etc represent one particular modelling view and use a number of generic, i.e. non-enterprise specific, modelling constructs. Many traditional methodologies combine several techniques to provide multiple perspectives. This necessitates specific verification procedures to ensure consistency between the model views. An object-oriented approach of which UML is perhaps the most representative and popular example. Although it allows many different views, its expressiveness with respect to the enterprise domain is rather low. To increase the expressiveness, many enterprise modellers have extended UML with enterprise-specific constructs such as contracts, resources, goals, activities. Refer to the "meso-models" by e.g. [MCLE01; MARS00]. A knowledge representation approach which allows for a higher degree of expressiveness. Many KR languages have been designed specifically for modelling within an organisational context and incorporate explicitly a number of the modelling primitives listed in the table above. An example is MEMO (Multi Perspective Enterprise Modelling) [FRAN99a]. Natural language. This is the most expressive knowledge representation language but generally not considered formal (specific) enough for modelling purposes. Whilst it may initially appear that the most expressive languages are preferable, the issue is not quite as simple. It is generally accepted that the new OO paradigm is much more natural and powerful than earlier RDBMS-oriented techniques. There is often a fairly easy migration e.g. from an ERD to an Object Class diagram. [CHU97] points out that OO allows a much more natural modelling approach and that it is easy to add additional complexity to the model. [SALT97] also discusses how OO models are more expressive than relational and extended ER models. [YEO96] argues that OO is not only a better paradigm for the "external" representation of enterprise models, but also motivates that the internal representation (i.e. within the modelling tool) should be OO-based. However, [HAY00] points out that the benefits are not automatic. In defence of his generic (ER- grounded) data models, he points out that many object modellers do not necessarily apply the necessary discipline to make use of the specific benefits of OO. E.g. "where an E/R model would represent the employment of a person by a company, an object model might simply show an employee". This criticism, however, is more in respect of the (incorrect) use of OO rather than the intrinsic expressiveness of the OO paradigm. One remaining theoretical problem is that of closure: in the relational data model, applying relational operations to relations always produces relations; hence its conceptual model is mathematically closed [BROD82]. This is not true for the object-oriented model whose logical foundations are still not fully worked out. Finally, there tends to be a higher number of object types in OO than the equivalent ER data model, mainly due to the creation of abstract super types. However, these criticisms have not stopped the OO paradigm from making steady but certain inroads in the enterprise modelling world. The real debate at the moment is whether to adopt a KR or an OO approach; and here the issue is far from settled. By far the dominant paradigm used by IS practitioners is the OO model, typically by means of UML diagrams. However, it is felt by many researchers that OO is not powerful enough to represent models. The following argument is made in defence of CML (Conceptual Modelling Language): "We consider that pure rule representation as well as an object-modeling language, data dictionaries, entity-relationship diagrams, among other methods are considered no longer sufficient neither for the purpose of system construction nor for that of knowledge representation. We believe that knowledge is too rich to be represented with the above-mentioned methods. This requires stronger modelling facilities." [CAIR98] Two specific arguments are mentioned by [HULL90]: OO models do not have the rich type constructors of e.g. semantic models (e.g. the grouping constructor which builds a finite powerset of existing elements of an existing subtype) and the different types of inheritance (e.g. in semantic models, inheritance is behavioural, not structural, so that seemingly unlike types can inherit methods). [PARP98] compares conceptual graphs (CGs) against OO networks and states that, since CGs map directly to FOL, it is much easier to prove the correctness of CG models. Most of the criticism is levelled, not necessarily against OO but more specifically against UML. It appears indeed that a substantial amount of "UML" conference papers (see e.g. the OOPSLA conference series) deal with how to extend UML for specific modelling situations. Despite its many different diagram types, there is still a strong feeling that some model views are missing: e.g. (enterprise) process models [MCLE01]. UML models can be extended to some extent e.g. by means of the stereotype construct, as suggested by e.g. [MARS98; BERG00; HALP01]. On the other hand, modelling in a more expressive language requires more computational overhead, poses the modeller and model user/validator with significant cognitive complexity, and introduces redundancy by providing many alternatives to model the same situation. As mentioned before, it may not be necessary to require such a high degree of formalism or to capture the domain in all its complexity [MENZ98]. In fact, in the particular case of ontology modelling languages, [CRAN99] discusses a number of commonly used KR languages such as KIF and KL-ONE and argues that a combination of UML and OCL (Object Constraint Language) has the same richness as any other KR system but without their steep learning curve and "relative obscurity outside the AI laboratories". A final observation is that the data/meta-data distinction becomes more and more blurred as one moves from the relational model (which has an extremely clear separation between the data structure and the data contents - the so-called intensional and the extensional information) to the OO model and then to the KR languages which often store meta-data and data together using the same constructs. It is my view that the model-driven approach will, in time, force a shift from the OO modelling approach to the even more expressive KR modelling paradigm. Some Typical Enterprise Modelling Languages A large number of representation languages are used for enterprise modelling. As part of the PSL (Process Specification Language) standardization effort, a detailed inventory of the following twenty- six process representations was made [KNUT98]: ACT: a domain-independent formalism to specify knowledge about activities to generate and/or execute plans A Language for Process Specification (ALPS): aimed at discrete-process manufacturing. AP213: the application protocol for sharing STEP (Standard for the Exchange of Product model data - an ISO 10303:1992 standard) data. Behaviour diagrams: describe system functionality for systems engineering (SE) software. Core Plan Representation (CPR) for planning systems support. Entity-Relationship Diagram (ERD) models information primarily for relational database model implementation. Functional Flow Block Diagrams (FFBD) charts system functionality and sequencing. Gantt Charts graph projects and schedule resources and activities. Generalised Activity Network (GAN): a PERT-like but more general chart representing activities as links between states. Hierarchical Task Networks (HTN): used for AI planning systems. IDEF0 is a SADT inspired standard for functional modelling. IDEF3 describes the behavioural aspects of as system using process flows and object states. <I-N-OVA> (Issues, Nodes, Ordering, Variable and Auxiliary constraints) models tasks, plans, processes etc. as constraints on system behaviour. Knowledge Interchange Format (KIF) aims at sharing knowledge using a standard FOL-like but ASCII-based syntax. Has a linear and tree-like version. Program Evaluation and Review Technique (PERT): a network analysis technique for projects with uncertainty. Petri Nets: a graphical language for modelling nets with concurrent, interdependent events. Has many variants for specific applications. Process Interchange Format (PIF) supports the exchange of enterprise process models between systems. The others mentioned by Knut are: O-Plan, OZONE, PAR-2, PART49, PFR, Quirk, VPML. He also includes a number of "supporting representations", namely the AND/OR graphs, Data Flow Diagrams (DFDs), Directed Graphs, State Transition Diagrams and Tree Structures. A large number of other KR languages exist, many not geared specifically to process modelling. Not all have necessarily been used in an organisational context. [LUKO96] and [MORA94] evaluate also ML, KARL, KADS and CommonKADS, LOOM, OMOS, NIAM, INFO-MOD, Model-K for enterprise modelling suitability. A more recent paper [VERN98] reviews the following commonly used languages for enterprise modelling, and compares them on the basis of a list of essential requirements for enterprise modelling: The CIMOSA language: part of a reference framework for enterprise modelling and integration. ARIS ToolSet language: developed as part of a comprehensive enterprise modelling tool set which served as the basis for developing SAP R/3. ER models / EXPRESS: EXPRESS is a more formal data description language, based on the ERD model, with particular support for STEP entities. GRAI nets: static descriptive models for enterprise integration. IDEF suite of models - produced by the ICAM project. In addition to IDEF0 and IDEF3, IDEF1x is a type of ERD and IDEF2 provides a graphic, dynamic model based on the SLAM simulation language. IEM: another reference architecture for enterprise modelling which mostly covers the function and information views using an OO perspective. OOA / OMT: Object-oriented graphical notations (now superseded by/incorporated in the UML). Petri nets: see above. SA/RT a semi-formal system analysis and design technique dedicated to real-time and reactive systems More recently, unification efforts in the software engineering field have led to the increasing acceptance of UML as a graphical tool for enterprise modelling [BRUNO97; MARS00]. UML consists of a number of formalisms, some of which are specifically geared towards models for software development, whilst others are generic modelling tools. As a lingua franca for the exchange of models between modelling tools, it appears that there is a move away from CDIF (CASE Data Interchange Format) [LEME98] to the XML-based standard XMI (XML Metadata Interchange) [COVE01]. The de facto standard for exchange of data between KR systems is still KIF although XML-based proposals have been floated, notably OIL (Ontology Inference Layer; and its derivatives) and XOL: XML-based Ontology exchange Language [DIMI00]. Modelling Tools An important pragmatic aspect of enterprise modelling concerns the selection of the appropriate modelling tool. Since many of the modelling tools are used in the context of information system development, the rapid changes in the technology environment are reflected in a very dynamic and volatile tool market. The intention of this section is therefore not to discuss individual tools but rather give a quick overview of the concerns related to tool selection viz. a broad categorization of enterprise modelling tools and the criteria one should consider prior to selecting an appropriate modelling tool. Tool Classification There used to be fairly precise distinctions between the various classes of tools. Technological developments have blurred these boundaries to a very large extent, so the following list has become more of a set of reference points on a modelling tool continuum. Graphical Modelling Tools. Many pure "model diagram drawing tools" were developed during the 1980s. Since these tools require an internal diagram repository anyway, the surviving tools have extended their capabilities to include at least superficial code (e.g. "stub" generation i.e. class and attribute definitions only) or database schema generation, and more substantial documentation abilities. For example http://www.methods- tools.com/tools/modeling.html lists 74 (mostly UML) graphical modelling tools (many also IDE & CASE) of which only four remained pure graphical tools: GOOFEE diagrammer, MagicDraw UML, Playground and VisualThought. All others tools incorporate some degree of code generation. In the KR field, there are still a number of graphics-only tools for generation of e.g. conceptual graphs or Petri-nets. CASE tools. Computer-Aided Software Engineering tools are specifically designed to support a model-driven system development process. Some CASE tools are therefore integrally tied to specific methodologies, though many of today's tools support multiple methodologies or allow methodology customisation. A distinction used to be made between [VANB99]: o upper-CASE (U-CASE): focussing on the analysis stage i.e. requirements modelling and prototyping; o lower-CASE (L-CASE): concentrating on the design stage i.e. code generation, testing and implementation (i.e. not useful for enterprise modelling); and o integrated-CASE (I-CASE): supporting the entire SDLC, usually adding comprehensive project management tools. This distinction is now also rapidly becoming obsolete since most contemporary CASE tools support most stages of the SDLC, though not all tools feature full project management support. A recent list (available from http://www.objectsbydesign.com/tools) mentions 601 CASE tools (as of 20 July 2001) although some entries reflect different tools from a single vendor I-CASE tool suite. The competitiveness between these tools is pretty fierce: http://www.cetus-links.org/oo_ooa_ood_tools.html lists 58 downloadable tools - some full, others limited versions - and some market shake-out is to be expected. Some of the higher-end tools (as opposed to the CASE "toys") are Cayenne, IBM UML Designer, Sapiens and Stirling's suite of COOLGen/Spec/Jex [MCLE01]. Integrated Development Environments (IDEs). Initially used for stand-alone programming GUI applications (akin to single user L-CASE tools), IDEs have grown into multi-user environments with sophisticated database capabilities and (often UML) diagramming tools, thus blurring the distinction between the high-end IDEs and CASE tools. Examples are Jade, PowerBuilder, Delphi. Meta-modelling tools. These tools are not modelling tools per se but allow one to define or specify one's own modelling elements and diagrams thus generating customized (integrated or stand-alone) modelling tools. Examples are Meta-Edit/Meta-CASE, MethodMaker (Mark-V) and IPSYS tool-builder [MART96]. KR tools. The KR discipline concerned with the development and specification of specific KR languages developed its own set of tools for each of the KR languages. One might claim (not quite wholly tongue-in-cheek) the number of these tools is at the rate of one tool per KR researcher or doctoral student. Examples are METIS, CommonKADS, LOOM editor and many more with esoteric names such as GRAIL, KRIS, CRACK, RACE etc. The tools most relevant to enterprise modelling are the ontology editors such as OntoEdit, Kactus, OntoBroker, ODE (Ontology Design Environment). [BRAZ98] developed a framework for the evaluation of the suitability of KR tools for knowledge modelling and compared the following tools: Desire, CommonKADS, Protégé, Mike, Vital and Task. Knowledge Management Repositories. KM repositories are extremely flexible databases geared towards the customized storage and management of diverse knowledge. These interesting tools can and have been used for corporate model management. The following examples will give a feel for the differences in approach and implementation: ConceptBase ("a deductive object manager for meta databases"; http://www-i5.informatik.rwth- aachen.de/CBdoc/); Principia ("a configurable data repository usable for corporate data modelling"; http://www.principia.co.uk); k42 ("a knowledge structuring tool for semantically connecting data is disparate heterogeneous data sources by means of Topic Maps"; http://k42.empolis.co.uk) and Archi ("a web-based knowledge repository suitable for enterprise architecture management"; http://www.inspired.org/html/archi.htm). In addition, there are a number of miscellaneous tools such as external metrics collectors (though usually taking code as input e.g. Resource Standard Metrics; http://www.m2tech.net and McCabe IQ2; http://www.mccabe.com), validators (to set and enforce syntactic and semantic naming standards in models; e.g. Kismeta [ORLI99b]) or IKARUS/ClearTalk (a knowledge management system with a semi-controlled structured English natural language front-end; http://www.site.uottawa.ca/~kavanagh/Ikarus/IkarusInfo.html). Criteria for Selecting Tools There are many criteria which could be considered for evaluating a modelling tool. I suggested the following criteria in a student assignment to evaluation UML modelling tools: price, availability, local & internet support, market share (difficult), availability of a demo version, which UML (and non- UML) diagrams are supported, how pure OO is it, maturity of the tool, scalability, class libraries provided, open/proprietary and Corba/DCom compatibility, checking & testing support, code generation (and, if so, which languages), user-interface, ease of use & learning curve, integration with other tools, running platform (and required hardware specifications), delivery platform, methodology, project management & group support, documentation. In the context of enterprise modelling, the following additional criteria could be added: degree of model verification, specific business process re-engineering functionality, model simulation capability, architecture modelling support, collaborative web development, pattern support, reference models provided, formal language support (KIF?), full model life-cycle management, meta-modelling capability, model metrics provided, HTML & MS-Office documentation, intranet support, prototyping/RAD (Rapid Application Development), reverse engineering, repository technology, CDIF and XMI export/import. Meta Modelling This section introduces the concept of meta-modelling. Due to its importance to the research, it is dealt with in some more detail. What is Meta-modelling? Any modelling process, by necessity, implies another modelling system at a higher level [LYYT99]. This higher system, one level up, is called the meta-model, and specifies how the modelling process must happen and/or what the model can look like. Meta is a common Greek-derived prefix that means "about" and typically entails a recursive or self- referential relationship. Meta-data (or metadata) is data that describes other data (data about data). A Meta-language is a language used to describe other languages. A metafile is a file that contains other files. The HTML META tag is used to describe the contents of the web page in which it is embedded. The concept of "meta" is also used extensively in the context of IS modelling. Meta-data: data about data e.g. used in data warehousing, CASE tool data dictionaries, database administration, XML specifications, … Some examples of meta-data standards are the Dublin Core (web resource discovery), GILS (government information) and FGDC (geographic data sets). Meta-modelling: a model of a model, modelling language or modelling process e.g. used for explaining or defining modelling concepts, for developing very high-level models, for the design of pure OO tools and languages, … Meta-CASE: a CASE tool to create CASE tools e.g. MetaEdit+ [MART96], Alfabet, Objecteering, Paradigm Plus, sBrowser [BEZI98] The following explains the connections between a model and its meta-model. A model is a collection of artefacts assembled during modelling of a system such as a software system. Typical concepts found in a model are, for example, "Customer", "Order", "StreetAddress", but also "default is 5.7 seconds" and "Z may never happen before X and Y have both happened". A meta-model is an information model for the information that can be expressed during the modelling process or in the model. Typical concepts found in a meta-model are, for example, "Class", "Process", "Constraint" or "Method". Finally, in order to create a meta-model, one needs a language in which this meta-model can be expressed. The meta-meta-model is that language. The reason for its name is that a meta-meta-model relates to a meta-model the same way was a meta-model relates to a model. In a number of cases, the meta-level and lower level are not clearly separated. This is not only the case in many KR languages but also in a number of "pure" OO languages where a class of classes is treated in a similar way as an instance of that class [GEIS98]. The distinction between meta-model and meta-meta-model is reflected in the four-layer architecture in table 2.3, as in e.g. [OMG99; GEIS98; BEZI98a]. This conceptual framework for meta-modelling explains the relationships between meta-meta-model, meta-model, model and (not entirely correctly named) "user data". Together they form four layers on top of each other. Table 3: Four-layer architecture of meta-models. Level Type Example contents M3 Meta-meta-model "MetaEntity"; "Package" and "MetaRelationship" M2 Meta-model "Process"; "Class"; "Method" and "Attribute" M1 Model "Customer"; "Calculate.Pay"; "OrdersFrom"; "Account.Balance" and "Employee.Name" M0 Data "Invoice # 92432"; "US$500" and "John Doe" Note that the meta-meta-model also requires a (modelling) language to express its model. Hence there is a risk of infinite regress. In practice, a meta-meta-model typically uses a very small number of "intuitive" modelling concepts: e.g. three [LEME98], four [NISS95] or five [VANH99]. Alternatively a meta-meta-model defines itself in a recursive nature, as has been done in UML and MOF: "For a meta-modeling framework to be useful, some way must be found of terminating the meta-hierarchy. […] This submission borrows a neat trick from CDIF […] The trick is to make the entities at the top of the meta- hierarchy instances of other entities at the same [meta-meta-]level, possibly even themselves. Although this has the flavor of creating something from thin air (like particles in the `soup' of quantum mechanics) it does neatly terminate the meta hierarchy." [PLAT97] [VANH99] discusses two criteria for choosing an appropriate meta-modelling language: consonance and no-loss, which basically translate to a balance between richness and simplicity, representative of the tension between semantic relativism and expressiveness of any modelling language. His theoretical criteria seem to be ignored by practitioners who seem to prefer to use the relatively complex and rich UML class diagram / OCL combination for their meta models (see below). An interesting observation from meta-model analysis is that the strict distinction between concepts and relationships is actually quite spurious. What is considered a relationship in one context can easily be constructed as an entity in another and vice versa [RUDL96]. This is true on the low level for any relationship that can carry attributes (if a customer orders a product, the order will normally become an entity in its own right). Similarly, an association between two entities can legitimately be viewed as an attribute of any of the two entities or become an entity itself [HAMM90; AVIS95]. As an example: the manager of a business unit has been modelled as a relationship between the entities of managers and business units, as an attribute of the entity business unit, or conversely, the business unit that is being managed could be an attribute of the manager entity. The object-orientated approach has not solved this issue because there are several ways of modelling the "role" concept [MARS00]. At the model level it is clear that what is a flow (relationship) in a DFD often becomes an entity in an ERD and the process (node) in the DFD is often reflected via a relationship in an ERD. Similarly, a message (relationship) between classes in a UML sequence diagram would have to become an (informational) entity when modelling the physical network, whereas the nodes on each entity life line are in fact processes which could be modelled as relationships in that entity's UML statechart-diagram. Since meta-models are models, generic modelling tools can be used to develop and document them. This will be the case if an existing modelling language such as e.g. the UML is used as the meta-meta- language. Specific meta-modelling tools such as Meta-Edit, ConceptBase, MethoModeller or ToolBuilder (see above) and meta-modelling methodologies such as MEMO [FRAN99a] or GOPPR [VANH99] have also been developed. Why Use Meta-Models There are a number of situations for which meta-models are highly useful [VANH99 ; FRAN98a]. Meta-models can serve as conceptual schematas for repositories that hold software engineering and related data as well as to develop flexible modelling software such as CASE tools. Meta-models have been used to define certain modelling languages e.g. IDEF and UML. This is also useful in defining the extensibility of a language. Meta-models are an essential part of technologies (together with a transfer mechanism such as a file format) that allow interoperability of modelling tools. This is illustrated by their use in the model interchange standards CDIF and XMI. Meta-models can be a tool to help to understand the relationships between concepts in different modelling languages, since a meta-model identifies a usually small number of core concepts. Meta-modelling can be used as a general technique for integrating and comparing models from different domains, but also to identify overlaps between models from the same domain [GEIS98]. This research will examine the meta-models of the different generic enterprise models as part of its model evaluation framework. As an example of practical meta-model use, take a systems integrator faced with the challenge to integrate multiple modelling and other tools in a way that they more or less appear like one tool to the user. In order to do this, she needs to know what tool supports which concepts, and how each concept of each tool relates to the concepts of another tool. A meta-model analysis provides a list of concepts and their relationships. The resultant meta-model can be used to decide which data is to be kept where, and how tools are supposed to talk to each other. Types of Meta-Models There are a number of different types of meta-models. Process. Process meta-models describe the modelling process or activity e.g. how to go about analysing and modelling an enterprise. These are used e.g. in methodology engineering and evaluation see e.g. [VANH99] Model. By far the most prevalent meta-model, however, is concerned with meta-modelling the product of a modelling activity: it is a model of a model. This category also includes most meta-meta-models. This category can be subdivided into three types of meta-models: those that describe the modelling notations or symbols ("rectangle with rounded corners, arrow with a diamond head"), those that define the modelling concepts that are used ("class", "relationship") and those that describe both. Domain. Some meta-models describe the modelling domain using high-level, abstract concepts e.g. an enterprise meta-model could introduce the concepts of resource, agent, goal, plan etc. Many authors consider this as a high-level model rather than a meta-model, hence my earlier suggestion of the name "mesa-model" for this type of model. The distinguishing attribute of a domain meta-model is that all the entities in the "mesa-model" are abstract classes. Most meta-models are based on the semantics of the underlying model elements. However, it is also possible to take a purely syntactic stance and derive a meta-model purely based on the generalisation of syntactic similarities e.g. according to attribute domain rules, allowable values or data types. This applies especially to the "domain meta-models", where it increases the flexibility and usability of the derived models. This is analogous to the practice in domain modelling of generating super-classes based on syntactic rather than semantic considerations: "Although Santa Claus is not likely to be considered in the same semantic category as the Eiffel Tower, theoretically, we could build a data model where they are both valid examples of the same entity." [HO99]. Some Examples of Meta-models and Meta-Meta-models The following serves to give a representative sample of publicly available meta-models for modelling notations: DFD: an example of a meta-model of the DFD using NIAM as the meta-modelling language is given by [TERH96]. UML: OMG has relied extensively on meta-models to specify each of the UML 1.3 modelling constructs [OMG99]. As an example, the UML meta-model for the class-diagram model element of "relationships" is given in Fig 2.3. Note that the UML meta-models are also drawn using the UML itself: they use UML Class diagrams to define the meta-entities and OCL to describe their well-formedness constraints [GEIS98b]. CDIF: CDIF has been defined by the CDIF Division of the EIA, an industry standards committee, by means of meta-models. CDIF is also being standardized at an international level through ISO/IEC JTC1/SC7/WG11. See http://www.cdif.org. PROMPT: This frame-based KR model has a meta-model consisting of classes, slots (attributes), facets (named ternary relations) and instances (members of classes) [NOY99]. Note that meta-models are not necessarily limited to describing other modelling techniques: the HL7 v.3.0 (Health Level Seven) clinical data interchange format prepared by the JWG-CDM [http://www.mcis.duke.edu/standards/HL7/]; a proposed Data Element Registry model [GILL97]; and the LTM - Legacy Transition Meta-model for the repository of current and target IS [http://www.systemtransformation.com] have all been defined using meta-models. A large number of meta(or mesa?)-models for enterprise domain modelling can be found in the literature. Here are some examples: Marshall's meta-model [MARS00] was already given in figure 2.1. Note that Marshall extends UML with the following four enterprise stereotypes to facilitate enterprise modelling: <<purpose>>, <<process>>, <<entity>> and <<organisation>>. He uses these as high-level (abstract) business objects in his BOMA model. The basic meta-model of business modelling concepts according to [ERIK00] consists of the following entities (the relationships between them have been omitted): problem, goal, process, event, state change, interface, rule (constraint, derivation or existence) and resource (information or thing, with thing being physical (e.g. people) or abstract). The meta-model for the ODP enterprise viewpoint, as given by [STEE00], uses the concepts of behaviour, action, role, objective, community, contract, actor, artefact, principal, policy, constraint and object. His meta-model is also in UML. [LOCH98] employs the following four meta-classes: LEGAL ENTITY (players, actors); COMMODITY (products, services, resources); EVENT (process steps, acts) and INSTRUMENT (objects, tools). Note the limited correspondence to Marshall's meta-model. However, there is a much closer correspondence with the four primitive classes of PSL v.10: OBJECT, ACTIVITY, ACTIVITY_OCCURENCE and TIMEPOINT. Figure 3: The UML meta-model for "relationship" [OMG99]. Finally, there are a number of meta-meta-models. It is interesting to note the commonality between the meta-meta-constructs: [MANS96] describes the meta-meta-model for a CASE repository which consists of nodes, links, groupers, diagrams and properties. [GERBE96] describes a very generic meta-meta-model for any knowledge representation system, but based on conceptual graphs theory. The following concepts are used: concept (specialised into individual, generic and universal concepts), conceptual relationship, conceptual graph and the definition of concept type, relation type and cardinality. [NISS95] states that the following four concepts suffice: nodes, links, assertions and classification. [LEME98] uses a meta-meta-model with only the three concepts of "concept", "relationship" and "modularity" to compare the MOF, CDIF and sNets formalisms. [FRAN98a] similarly compares the three meta-meta-models of MEMO, CDIF and UML but uses a total of 27 different meta-meta-model concepts in his comparison. Many of these concepts, however, appear only in the UML meta-meta-model and Frank, quite correctly, expresses some reservations about their appropriateness at the meta-meta-level. A very detailed meta-meta-model (several hundreds of pages long) can be found in Platinum Technology's submission for an Object Analysis and Design Facility to the OMG/OA7D RFP (see http://www.planinum.com/clrlake). The Meta Object Facility (MOF) as described by OMG is also in the form of a fairly detailed meta-meta-model, described by a combination of UML notations, CORBA interfaces and OCL [GEIS98; CRAW97] An obvious question is whether any meta-meta-meta-models and even higher-order models exist? Generally, infinite regress is avoided by defining meta-meta-model concepts in their own language. Although this introduces the problem of tautological or reflexive definitions, in practical terms the meta-meta level concepts are seen as intuitively understandable and the benefit of closure is seen to outweigh any philosophical problems.
Pages to are hidden for
"MODELS - DOC"Please download to view full document