seminário 01 - modelling software development methodologies - a conceptual foundation

www.elsevier.com/locate/jss

The Journal of Systems and Software 80 (2007) 1778–1796

Modelling software development methodologies:A conceptual foundation

Cesar Gonzalez-Perez *, Brian Henderson-Sellers

Department of Software Engineering, Faculty of Information Technology, University of Technology, Sydney, P.O. Box 123,

Broadway NSW 2007, Australia

Received 8 August 2006; received in revised form 23 February 2007; accepted 24 February 2007Available online 12 March 2007

Abstract

Current modelling approaches often purport to be based on a strong theoretical underpinning but, in fact, contain many ill-definedconcepts or even contradictions leading to potential misinterpretation. Although much modelling in object-oriented contexts is focussedon the use of the Unified Modelling Language (UML), this paper presents a technology-agnostic approach that analyses the basic con-cepts of structural models and modelling in software engineering, using an approach based on representation theory. We examine thedifferent kinds of interpretive mappings (either isotypical, prototypical or metatypical) that are required in order to trace model entitiesback to the SUS (subject under study) entities that they represent. The difference between forward- and backward-looking models is alsoexplained, as are issues relating to the appropriate definition of modelling languages in general based on representation theory. The needfor product and process integration in methodologies is then addressed, leading to the conclusion that a mesh of verbal plus nominalnodes is necessary in any methodology metamodel. Finally, the need for a common, cross-cutting modelling infrastructure is established,and a solution proposed in the form of an ontologically universal modelling language, OOLang. Examples of the application of thesetheoretical analyses to the suite of OMG products (particularly SPEM, UML and MOF) are given throughout, with the hope that aware-ness of the importance of a better modelling infrastructure can be developed.� 2007 Elsevier Inc. All rights reserved.

Keywords: Modelling; Metamodelling; Software development methodologies; Theoretical basis

1. Introduction

From an intuitive point of view, modelling is usuallylinked to representing, describing and explaining conceptsand systems in the real world. Similarly, the idea of a modelis often related to the notions of reproduction, specificationand description. Although these instinctive connections areuseful for many everyday activities, software engineersoften need to go beyond them and into a more formalunderstanding of models and modelling. Current trendssuch as Model-Driven Architecture (MDA) (OMG,

0164-1212/$ - see front matter � 2007 Elsevier Inc. All rights reserved.

doi:10.1016/j.jss.2007.02.048

* Corresponding author. Address: Txinbo Kalea, 9, 2 A, Zamudio,Bizkaia 48170, Spain. Tel.: +34 677 024545.

E-mail addresses: [email protected] (C. Gonzalez-Perez), [email protected] (B. Henderson-Sellers).

2003a) or other model-centric approaches are positioningmodelling under the spotlight more than ever before(Davies et al., 2004; Bezivin, 2005).

This paper delves into what structural models are andhow structural modelling can be used to successfullydescribe software development methodologies,1 approach-ing it from a technology-agnostic perspective so thatunnecessary constraints are avoided. Works such as (Seide-witz, 2003) are valuable in their analyses, but their heavyand implicit reliance on specific solutions (the OMG gen-eral approach, or ‘‘strict metamodelling’’, in the cited case)makes their value a small fraction of what it could have

1 Our modelling discussion is not restricted to models of work products(Kuhne, 2005) but also includes models of process and people elements –together these constitute methodology models.

mailto:[email protected]



C. Gonzalez-Perez, B. Henderson-Sellers / The Journal of Systems and Software 80 (2007) 1778–1796 1779

been. In our work, we present a purely theoretical dis-course that establishes a basic conceptual set and a collec-tion of structural modelling needs, expanding significantlyon our previous work (Gonzalez-Perez and Henderson-Sellers, 2005a). However, although our examples predomi-nantly use OMG products, especially UML, SPEM andMOF, since these will probably be most familiar to thereader, the approach is not constrained to OMG-stylemodels. The modelling of dynamic or functional aspects(as opposed to structural) is not addressed by this paper.

Once this is clear, we proceed to the analysis of how exist-ing technologies can support the identified needs. The nextsection builds the basic modelling concepts and explainshow they are applied in software engineering. Section 3examines how models can be chained into multi-layer con-structs, while Section 4 introduces modelling languages andtheir role in modelling. Section 5 deals with the problem ofnodes and arcs, i.e. how relationships between concepts (asopposed to the concepts themselves) are dealt with in mod-elling languages. Section 6 presents the need for a semanticmesh, focussing on the need of integrating product and pro-cess issues in the context of software development method-ologies. Section 7 introduces the need for a modellinginfrastructure that is common to all the models in a model-ling stack, and Section 8 presents the conclusions.

2. Models and modelling

From a simplistic point of view, we could say that amodel is a statement about a given subject under study

(SUS), expressed in a given language. This definition is sim-ilar to that given by Seidewitz (2003) (‘‘a set of statementsabout some system under study’’), but it incorporates anexplicit reference to the language the model is expressedin. Also, it condenses ‘‘a set of statements’’ into ‘‘a state-ment’’, since a set of statements can be seen as a compositestatement. If we accept this definition, then the sentence‘‘today it’s raining’’ would be a model of the real world,since it is a statement about a given subject (my perceivedreal world), expressed in a given language (English). Sincetoday it’s raining (I can verify it looking through the win-dow), the statement expressed by the sentence can be eval-uated as being either true or false (true here!). Thus, theprospective model is a valid model. Fig. 1 shows a modeland the SUS that it represents.

We could call the sentence ‘‘today it’s raining’’ a model,but it would be of little use. The value of models usuallyresides in our ability to reason about the SUS by lookingat the model only; this is sometimes called abstraction. At

SUS Model

Fig. 1. A model and the SUS that it represents. A rectangular boxrepresents a model. A rounded rectangle box represents a SUS. The arrowcan be read as ‘‘represents’’.

the same time, we need to acknowledge that modelling isoften performed to fight complexity, which usually appearsin the form of SUSs that are not simple monolithic entitiesbut intricate composites. This applies to function (e.g. dif-ferent tasks in a workflow description, transaction againstan online shop) as well as structure (e.g. the parts of a car,the hierarchy in an organisation). Therefore, we can saythat the major reason that we need models for is to reasonabout the complexity of the SUS without having to dealwith it directly (see also Jackson, 2002). As a result, a suit-able model would have to exhibit the appropriate structurefor it to be useful. For this reason, we prefer to say that, fora statement about an SUS (expressed in a given language)to be a model, it needs to be homomorphic with the SUSthat it represents. This means that the structure of themodel and the structure of the SUS must coincide to somedegree, and the operations that are possible on the SUS arealso possible on the model. This use of the word ‘‘homo-morphic’’, i.e. meaning ‘‘related via a structure-preservingmapping’’, is not purely algebraic, and has been utilisedin this sense before in software engineering (Sabetzadehand Easterbrook, 2005) and other disciplines such as lin-guistics (Harkema, 1995). For example, consider a carand the parts it is made of. This is the subject under study(SUS). By looking at it, we can (albeit with a big effort)enumerate all its parts, sub-parts, etc. recursively in atree-wise fashion. A model that represents a car and itsparts should exhibit the same structure and allow for thesame operation, i.e. enumerate parts and sub-parts recur-sively (Fig. 2). If a model were not homomorphic with itsSUS, i.e. the structure of the SUS were not copied intothe model, then the model could not be used as a surrogatefor the SUS, thus violating a definitional property of mod-els. Therefore, models must be homomorphic with theirSUSs.

These characteristics of homomorphism, abstractionand purpose correspond to the three key features of map-ping, reduction and pragmatics of Stachowiak (1973) (seealso Ludewig, 2003; Kuhne, 2005).

At this point, some authors – especially those with lesspositivistic attitudes, such as (Lakoff, 1990) – would claimthat the particular structure of an SUS is but an artefactgenerated by the mere act of observation. This means thatwe create the structure of reality as we perceive it, asopposed to perceiving a pre-existing structure. If this istrue, then the structure of a model would replicate thestructure that our minds have created of the SUS, andother people’s models could well be completely different.Consequently, model homomorphism is not an absolute

SUS Model

Fig. 2. A model must be homomorphic with its SUS so the operationsthat are possible on the SUS are also possible on the model.

1780 C. Gonzalez-Perez, B. Henderson-Sellers / The Journal of Systems and Software 80 (2007) 1778–1796

concept but happens to varying degrees. To make thingsmore complicated, we could add to this the fact that amodel is often created as the result of a representation pro-cess, which, according to Gonzalez-Perez (2002, pp. 184–185), is conditioned by temporal, subjective and socio-cul-tural parameters. Such issues, however, are beyond thescope of this paper.

We have established that models represent SUSs. Thisstatement, however, raises two additional questions. Firstof all, what kind of entities are the model and the SUS?Secondly, what is the nature of this ‘‘representation’’? Inorder to answer the first question, we need to take intoaccount that the usual depiction of modelling activities thatis found in most software engineering works suffers from avery peculiar problem: they show the model as being a rep-resentation of a fragment of reality (whatever ‘‘reality’’means) and external to it. A very good example can befound in Martin and Odell (1992) (see Fig. 3).

Although this may seem a simple matter of notation, itreveals the underlying assumption that a model is differentto its SUS in a very particular way, namely, it does notbelong to the same realm. However, even the most simplis-tic thought experiment would show that, if an SUS is partof reality, then a model of it is also part of reality, as vividlyexplained by Meyer (1997, pp. 230–231). Therefore, modelsare not external to reality but components of it (Fig. 4),and, similarly, we (as modellers) are not outside reality,

OO Modelof Reality

OO Design

Code

Reality

Fig. 3. A model as an entity external to reality. Based on Fig. 5.1, p. 68 ofMartin and Odell (1992). Reprinted by permission of Pearson Education,Inc., Upper Saddle River, New Jersey.

reality

SUS Model

reality

SUS Model

Fig. 4. A model is part of the same reality as its SUS.

looking at it, but inside it (Lakoff, 1990, p. 261). Preciselybecause of this, we can create models that represent othermodels, thus creating a model chain, as will be discussedlater.

Answering our first question (what kind of entities arethe model and the SUS?), we can conclude that anythingthat can be observed can be an SUS, and that a model,once created, becomes part of reality and, therefore, is apotential SUS for further models. With regard to our sec-ond question (what is the nature of the connection betweena model and its SUS?), two different scenarios are oftenfound, as described by Seidewitz (2003). Sometimes amodel is created to describe an existing SUS and enablereasoning about the SUS in its absence. For example, atraining flight simulator is a model of a real aeroplane thatis better suited for training pilots than the SUS it models.Some other times, a model is created to specify an SUS thatdoes not exist but can be somehow envisioned. For exam-ple, blueprints of a building are created to define what thebuilding will look like and how it will be built. We will callthe former backward-looking models since they look back-ward (as far as temporality is concerned) to the SUS theymodel, and we will call the latter forward-looking models

since they look forward into the future (Fig. 5).Backward- and forward-looking models are sometimes

called descriptive and prescriptive, respectively, as in Bezi-vin (2005) and Ludewig (2003). Although it is true thatbackward-looking models usually describe a SUS and theirform is therefore constrained to some extent by the form ofthe SUS, whereas forward-looking models often prescribe aSUS that does not (usually) yet exist (few if any con-straints), these terms (‘‘descriptive’’ and ‘‘prescriptive’’)do not express a property of the models but of the usagethat is made of them. In addition, these properties arenot exclusive and can be combined in different proportions.For example, consider a use case model. One could arguethat it describes the dynamics of the application domain,but it is also true that it prescribes the functionality ofthe system to build. Is this model descriptive or prescrip-tive? In fact, it is inherently neither; it can, however, be used

for both purposes, i.e. to gain an understanding of theapplication domain and to serve as guide when developing

SUS Model

SUSModel

Fig. 5. On the top, a backward-looking model, which represents a pre-existing SUS. On the bottom, a forward-looking model, which representsan SUS that does not exist yet. Time is assumed to flow from left to right,and, therefore, the direction of the ‘‘represents’’ arrow depends on thekind of model.

SUSModel

Application Domain

FinalSystem

… ? ...

Model 2

Model n-1

Model 1

Model n

Fig. 6. Backward- and forward-looking models in a software developmentproject. At some point during the project, focus shifts from looking backto the application domain into looking forward to the final system beingbuilt. Note that all the models in this diagram are represented as slightlyrounded rectangles, meaning that they are models but also used as SUSsby other models.


the system. All we can say about the use case model is thatit has been created as a representation of the dynamics ofthe application domain, and, therefore, it is a backward-looking model. If this model has been created to explainthe dynamics of the application domain to third parties(but no system is ever developed from it), then its prescrip-tive dimension is non-existent. However, if some day a sys-tem is developed based on this use case model, then themodel is strongly prescriptive. It is clear that whether amodel is prescriptive or descriptive cannot be establishedby looking at the model; its usage over time needs to beconsidered. The backward/forward-looking concepts, onthe contrary, describe why the model was created (asopposed to how it was, is and will be used), which usuallycan be determined easily. This point of view coincides withthat expressed in Greenfield and Short (2004) with regardto system requirements.

Software development makes use of both kinds of mod-els – although they may well not be distinguished as such.At the beginning of a software development project, mod-els of an application domain are created. These models tryto represent an existing reality, and for this reason they arebackward-looking models. However, the last stages of aproject involve models that specify the final system to bebuilt and help us create it by detailing every single aspectof it. These are forward-looking models. Almost all themodels created through the whole lifecycle are used bothdescriptively and prescriptively to certain and varyingextent. At some point during the project, however, thefocus shifts from backward-looking to forward-looking(Fig. 6). We can observe this by realising that the main rea-son for creating backward-looking models is to get rid ofunnecessary detail so that the resulting model is simplerthan (but, hopefully, homomorphically equivalent to) thereal thing; on the other hand, the main reason why we cre-ate forward-looking models is to explicitly specify as muchdetail as possible about an SUS that we intend to create.Detail is actively removed when looking back, but activelyadded when looking forward. We may assume that the nat-ure of these two kinds of details is not the same. This issue,together with the mechanisms by which the back-to-for-ward shift happens, are certainly interesting topics bythemselves, and will be considered as the theme for furtherresearch.

For both types of models (backward- and forward-look-ing), homomorphism dictates that the structure of themodel must match the structure of the SUS at some rele-vant level of detail; in other words, for each relevant entityin the SUS there must be an entity in the model that playsthe same structural roles. At the same time, every entity inthe model must have some corresponding entity (perhapsmultiple) in the SUS; otherwise, the model entity wouldnot represent anything.2 What is the nature of the connec-

2 In a backward looking model, the SUS is (typically) reality whereas ina forward looking model the SUS is the target ‘‘system-to-be’’. In eithercase, entities in the model and entities in the SUS must be homomorphic.

tion between a relevant entity inside the SUS and its ‘‘sur-rogate’’, homomorphic entity inside the model? This mightbe too general a question as to have a single answer, butthere is something that we can say: whatever the natureof the connection, any model must have access to the infor-mation necessary to find out what the SUS entity is that isrepresented by a given model entity (please note that allmodel entities must be connected to SUS entities, but notall SUS entities need to be connected to a model entity).Without this information, interpretation of the model –as described by Seidewitz (2003) – is not possible and,therefore, the model is meaningless. We will use the term‘‘interpretive mappings’’ to refer to the collection of infor-mation that allows finding out these connections when nec-essary (Fig. 7).

Interpretive mappings are not always one-to-one rela-tionships as shown in Fig. 7. In fact, the ‘‘cardinality’’ ofthe mappings depends on the characteristics of the repre-sentation process employed to create the model. For exam-ple, an architectonic scale model of a building usuallycontains a simplified, small-scale version of each room ofthe real building. In this case, each small room in the modelis mapped to a real room in the real building; the cardinal-ity is one to one. If the same model contains a figurine toexemplify how people would interact with the building in

Fig. 7. Interpretive mappings between model entities and SUS entities,depicted by dotted-line arrows. For the sake of clarity, not all themappings are shown in this figure.

SUSModelpentagon

Fig. 8. Examples of isotypical, prototypical and metatypical interpretivemappings. A circle is shown to have an isotypical mapping. The shadedsquare on the model is an example (prototype) for any square in the SUS.The declaration of ‘‘pentagon’’ in the model is metatypically mapped to allpossible pentagons in the SUS.


the real world, this figurine does not correspond to anyparticular person in the SUS, but to the prototypical ideaof a person in the SUS interacting with the building. Anumber of persons in the SUS can play the structural rolethat the figurine plays in the model and, therefore, theinterpretive mapping between the figurine and the personsit represents is one-to-many. There is a second way inwhich an interpretive mapping can be one-to-many; con-sider a label attached to the above mentioned architectonicscale model that reads something like ‘‘persons walkthrough this way’’. Rather than incorporating a prototypeof potential SUS entities, this model entity declares whatkind of entities in the SUS are suitable for interpretivemapping. Summarising, we can identify three differentkinds of interpretive mappings:

• Isotypical mappings are those that map one model entityto one SUS entity. The model entity straightforwardlyrepresents the SUS entity.

• Prototypical mappings are those that map one modelentity to a set of SUS entities given by example, i.e.the model entity exemplifies the kind of SUS entities thatcan be mapped to it.

• Metatypical mappings are those that map one modelentity to a set of SUS entities given declaratively, i.e.the model entity is a description of the properties thatSUS entities must comply with in order to be mappedto it.

Fig. 8 shows examples of the three kinds. Notice that, inprinciple, there is nothing that prevents the three kinds tocoexist within the same model.

We can find these three kinds of mappings in softwaredevelopment methodologies. Consider a UML class dia-gram, for example. This diagram depicts a model and, assuch, can be thought of as a model of that model. Eachbox in the class diagram that a UML-aware expert identifiesas ‘‘a class’’ is really a representation of a class in the classmodel. The box on the paper is just a visual artefact that rep-resents a conceptual (i.e. cognitive or mental) construct (theclass). We must emphasise here that boxes on the paper arenot classes but represent classes. Therefore, each box on thediagram is isotypically mapped to the corresponding class inthe model. Because this is an isotypical mapping, the cardi-nality is one on the SUS side, i.e. there is exactly one SUSentity for any given model entity, and we often equate thebox on the paper to the class in the model, thus confoundingthe model and its representation.3 This is convenient butdoes not mean that the box and the class are the same thing.Now, each class in the model is a declaration of what kinds ofobjects can appear in the system being modelled; therefore,each class in the model is metatypically mapped to a numberof potential objects in the running system. At the same time,

3 This confusion is fostered by UML’s strong orientation towardsdiagramming and documentation rather than true modelling, as explainedby Greenfield and Short (2004, p. 215).

we could argue that each class in the model is isotypicallymapped to a class in the source code. Finally, let us considerwhat UML 1.5 (OMG, 2003b) calls object diagrams, i.e.structural diagrams in which objects can appear. A boxdrawn on a piece of paper that is identified by an expert as‘‘an object’’ is an ambiguous thing. Some people wouldinterpret it as a representation of a particular object in therunning system (an isotypical mapping) while others wouldinterpret it as an example of an object that may occur inthe running system (a prototypical mapping). Since the car-dinalities of these two mappings, as well as their semantics,are different, we claim that UML 1.5 is ambiguous in relationto object diagrams. UML 2 (OMG, 2004) removes the con-cept of Object as a model entity, and introduces InstanceSpe-cification. Indeed, the term ‘‘object’’ has driven some peopleto believe that the ‘‘objects’’ in UML 1.5 (a.k.a. 1.4.1) objectdiagrams are real objects (and the associated confusionrelated to objects being in the same layer together with theirclasses), when they are just a representation of objects. In thissense, the term ‘‘instance specification’’ is much better sui-ted, since it clearly reflects that the model element is just aspecification (i.e. an entity in a forward-looking model) ofan instance in the SUS. However, the same ambiguity thatwe found in UML 1.5 remains, since the definition, descrip-tion and semantics of InstanceSpecification in UML 2 (seeOMG, 2004, pp. 62–64), allow for both isotypical (‘‘Aninstance specification may specify the existence of an entityin a modeled system.’’) and prototypical (‘‘An instance spec-ification may provide an illustration or example of a possibleentity in a modeled system.’’) mappings. Whether this opendefinition enhances expressiveness or hinders interpretationis in practice something that only time will tell.

3. Model chains

We have pointed out in the previous section that amodel, once created, is part of the same ‘‘reality’’ (whateverthis means) as the SUS it represents. In other words, themodel is just one more entity in that reality and, therefore,is potentially available for further representation processes.This means that a second model can be built that representsthe first one. In this case, the first model acts as the SUS inthe second representation process (Fig. 9).

One of the first well-known examples of model chainingin software engineering is the ANSI X3.138 standard

SUS Model 1 Model 2

Fig. 9. A model that is the SUS for another model. Model 1 is a model ofSUS, and Model 2 is a model of Model 1. Recall that rounded rectanglesrepresent SUSs and rectangles represent models. In addition, slightlyrounded rectangles represent models that are also used as SUSs by othermodels.

MOF

UML

User Model

RunningSystem

Fig. 11. The four-layer OMG approach to model chaining. The top layer,MOF, is a self-model, i.e. it represents itself. Languages other than UMLmay appear under MOF and beside UML.


(ANSI, 1989; Dolk and Kirsch, 1987) introduced in 1988,which implemented a beautiful idea: rather than hard-cod-ing the schema of application data into a database (as mostsystems did and still do), X3.138 chose to store the schemaof application data as a changeable, forward-lookingmodel that specified the structure of any possible validset of data (Fig. 10).

In order to achieve this, X3.138 defined a structure oftwo ‘‘levels’’ of modelling in which each level was a modelof the level immediately to its right (or left, top or bottom,depending on the diagrammatic layout conventions used).Naturally, the leftmost and rightmost levels in this struc-ture were exceptions; X3.138 was not an SUS of any model(it was not formally specified by another model but by acollection of English descriptions) and the application datado not have to be a model of anything. Interpretive map-pings in X3.138 were always metatypical, i.e. X3.138declares what types of entities can exist in an applicationdata schema, and each application data schema, in turn,declares what types of application data may exist.

X3.138 was withdrawn by ANSI in 1997, but the samestructure is used today by more recent approaches suchas OMG’s MOF (OMG, 2002), UML (OMG, 2003b)and SPEM (OMG, 2005a). In the OMG world, a four-layerstructure is assumed, in which each layer is a model ofmodels in the layer immediately below it, except for thetopmost and bottom layers (Fig. 11). The top layer,MOF, is supposedly a self-model, i.e. a model of itself.

In general, we can say that OMG standards, as an exam-ple, use metatypical mappings between layers with only oneexception: InstanceSpecification in UML 2 (or Object inUML 1.5) can exhibit both isotypical and prototypicalmappings to user models, as explained in the previous sec-tion. In all the remaining cases, OMG’s products not onlyuse metatypical mappings but they choose a very specialkind of metatypical mapping, namely, instance-of relation-ships. As noted in the previous section, a metatypical map-ping is one in which the set of SUS entities that can bemapped to a given model entity is specified declaratively,

ApplicationDataX3.138 Application Data

Schema

Fig. 10. Model chaining applied to data structure definition in X3.138.The standard defined a forward-looking model useful to specify applica-tion data schemata which, in turn, would be forward-looking models ofthe application data.

i.e. the model entity is a description of the properties thatSUS entities must comply with in order to be mapped toit. A type (in the UML sense) is definitely a declarationof its instances, so an instance-of relationship between atype and its instances does establish a metatypical map-ping. However, other ways exist, but OMG’s line of prod-ucts does not use them: a subtype-of relationship between asubtype and its supertype also implements a metatypicalmapping, since the supertype can be seen as a specificationof what properties SUS entities must exhibit so that theycan be mapped to it. For example, consider an SUS thatcontains the classes Oak, Elm and Haystack. Considernow a model of that SUS that contains the class Tree.We can say that the semantics of Tree specify what otherclasses (in the SUS) can be mapped to it (i.e. what SUS ele-ments may be represented by Tree). Since the Tree class inour example states that trees have leaves and a root system,it is easy to find that Oak and Elm in the SUS do complywith such a specification and, therefore, they can be meta-typically mapped to Tree. Haystack, however, does notcomply, so it cannot be metatypically mapped to Tree.Consequently, it is our claim that subtype-of relationshipsare also a form of metatypical mapping, and that there isno reason why software engineering modelling structuresshould not use it.

Both instance-of and subtype-of relationships establishmetatypical mappings between model entities (the class orsuperclass, respectively) and the corresponding SUS enti-ties (the instances or subclasses, respectively). From a rep-resentational perspective, these two kinds of relationships(instance-of and subtype-of), consequently, share commonproperties that make them fall within the category of met-atypical mappings.

Furthermore, not only instance-of and subtype-of rela-tionships are valid implementations of metatypical map-pings; ‘‘exotic’’ relationships such as deep instantiation

Book

nameisAbstract

Class

nameisAbstract

ob1 : Class

book1 : Book

nameisAbstract

Class

book1 : Book

Book*

Fig. 12. On the left-hand side, Book is shown as a class that is also aninstance of Class, which is impossible within the conventional object-oriented paradigm; the asterisk signals this diagram as illegal. On theright-hand side, Book is shown as a class that is specified by the object ob1

through a forward-looking isotypical interpretive mapping (depicted as asolid arrow).


(Atkinson and Kuhne, 2001a) and powertype instantiation(Gonzalez-Perez and Henderson-Sellers, 2005b; Hender-son-Sellers and Gonzalez-Perez, 2005) have been recentlydefined in the literature. The latter combines both metatyp-ical mappings and thus provides (in an OMG context) atype/supertype relationship between ‘‘layers’’ not presentin OMG products.4

The need for these new, ‘‘exotic’’ relationships arisesfrom the fact that the concept of representation is transi-tive, meaning that a model of an SUS is also a model ofthe same SUS. On the other hand, when a number of mod-els (or indeed methodologies) are classified and representedby a model, transitivity is lost since the model-model rela-tionship is now one of instantiation.5 However, theinstance-of relationship, the only one adopted by OMG,not only is not transitive, but is also representation-blind,i.e. it is not aware of the representation process. This meansthat an instance-of relationship allows us to describe theproperties of an instance from the perspective of its type,but it cannot take into account further chained representa-tion processes that may involve the specified SUS entity ina forward-looking model. For example, consider the classClass in UML 2 (OMG, 2004; OMG, 2005b). Class has aname attribute (inherited from NamedElement) as well asan is Abstract attribute. Together with the semantics ofClass as described by the UML 2 specification, this is suf-ficient to metatypically map Class to any class in a usermodel (the SUS of UML 2, see Fig. 11). However, fromthe perspective of UML, a class in the user model (suchas Book) is just an instance-of Class, and therefore anobject (since Class is a class and therefore its instance –here Book – is an object). Let us call this object ob1. Asan object, ob1 will have a value for the name attribute(‘‘Book’’ in our example) and a value for the is Abstractattribute (false in our example). ob1 is not the class Book,but only a representation of the class Book, very much likean instance of the class Customer is not a customer but arepresentation of a customer; ob1 is not the actual bookclass. However, the purpose of creating a Book class is toinstantiate it into book objects in the running system, butsince UML can only generate an object that representsthe Book class, and not the Book class itself, this cannot(strictly speaking) be done.

The solution to this quandary comes from the fact thatthe object ob1 in our example is a specification of the classBook, and therefore can be associated to Book via an iso-typical mapping (Fig. 12).

Of course, software engineers are well accustomed to dothe mental trick of automatically navigating the isotypicalmapping between the object that represents the Book class(ob1), generated from UML, and the real Book class (itsSUS entity, synthesised on the fly). This means that werarely miss not having a real Book class, since its represen-

4 A deficiency noted to us by one of the anonymous reviewers.5 These two kinds of model linkages are called token models and type

models respectively in Kuhne (2005).

tation given by the ob1 object is enough for us to imagine,for all intents and purposes, the Book class. However, andfrom a formal modelling perspective, this is only a trickand, in our view, far from acceptable as part of the founda-tional ideas of an engineering discipline. The reasons aretwofold: first of all, UML (or any other approach that islimited to instance-of relationships as a means to imple-ment metatypical mappings) can only generate objects thatrepresent classes, as explained above. The real classes arenot derived from UML but from the objects derived fromUML, by developers that use their subjective judgement tosynthesize them as necessary. For example, when a devel-oper introduces the Book class into a model, supposedlyby instantiating the Class class in UML, an object repre-senting the Book class is actually created. The box in thediagram labelled ‘‘Book’’, strictly speaking, represents anobject that can be isotypically mapped to a class that doesnot yet exist. This class is created by the developer (or, evenworse, separately by each person that reads the diagram)on demand. For example, when some code needs to bewritten from the diagram, a real class (for example, a C#class) is created. This class, as we have explained, is notan instance of UML’s Class but a class that is isotypicallymapped to an instance of UML’s Class (Fig. 12). The sec-ond reason is that modelling tools implemented as softwaresystems (as most are) need to implement a fully formalisedmodelling infrastructure in order to support the necessaryfunctionality. In our experience as both modellers andmodelling tool implementers, using instance-of relation-ships only is not enough to achieve this, and additionalworkarounds must be added to traverse the ‘‘hidden’’ iso-typical mapping that we have described. We describe ourown experience in this area in Section 7.

4. Modelling languages

We started this paper by stating that a model is alwaysexpressed in some language. This section deals with the

6 A metamodel is often incorrectly defined as ‘‘a model of a model’’rather than (correctly) as ‘‘a model of models’’ (Favre, 2005).


issues of defining what modelling languages are, what theyare made of and how their properties can affect the result-ing models. We have repeatedly referred to models as beingcomposed of entities. These entities can be called, morespecifically, model units. A model unit is, therefore, anatomic component of a model, which represents a cohesivefragment of information in the SUS being modelled. Modelunits are the basic unit of homomorphism and can be clas-sified into different types; for example, consider the archi-tectonic scale model described in a previous section.Discrete entities in this model (i.e. model units), such asrooms, walls or stairs, can be mapped to entities in itsSUS. A room in the model can be mapped to a room inthe real building, and a wall in the model to a wall in thereal building. Several rooms can exist in the model, eachof them being mapped to a different room in the SUS.All the model rooms, however, can be said to belong tothe same model unit kind, since all of them are roomsand can be described by their commonalities. A model unit

kind, then, is a specific kind of model unit, characterised by

the nature of the information that it represents and the inten-

tion of using such a representation. In an architectonic scalemodel, we are likely to find model units of several kinds,such as Wall, Room or Door (we will show model unitkinds with an initial capital letter). It is sensible to say thatmany of these model unit kinds will appear in differentarchitectonic scale models or, expressed differently, modelsof a certain ‘‘kind’’ will make use of a common set of modelunit kinds. What do we mean by models of a certain kind?Intuitively, architectonic scale models form one ‘‘kind’’,while UML class models may form a different ‘‘kind’’. Itcould seem that the kind of model is given by the natureof the subject under study (i.e. models of buildings areone kind, models of software systems are a second kind),but this is not the case, since it is possible to construct aUML class model of a building and, as such, it will bemade of classes and associations rather than walls androoms. We can define a model kind as a specific kind ofmodel, characterised by its focus, purpose and level of

abstraction. Therefore, the ‘‘kind’’ of models is not givenby the nature of the subject being represented but by thecollection of model unit kinds being used, which definethe focus of the models that can be created, their purposeand their level of abstraction. For example, a model thatis made of instances of Wall, Room and Door will be anarchitectonic model regardless of the subject being mod-elled. Similarly, a model made of instances of Class, Asso-ciation and Attribute will be an object-oriented classmodel, no matter what the SUS is. Linking the definitionof model kind to a specific focus and purpose fits wellwithin the task-fit and user-fit dimensions of representation(Peterson, 1996, pp. 9–10); furthermore, linking the saiddefinition to a particular level of abstraction acknowledgesthe existence of basic-level and gestalt perception effects asdescribed by Lakoff (1990, pp. 37–38).

We can formalise our previous description (‘‘models of acertain kind will make use of a common set of model unit

kinds’’, see above) by saying that each model kind uses agiven set of model unit kinds. For example, architectonicscale models use Wall, Room and Door while UML classmodels use Class, Association and Attribute. Since modelunit kinds tend to appear in semantically cohesive clusters,we can name these clusters ‘‘modelling languages’’ or sim-ply ‘‘languages’’, and define a (modelling) language as an

organised collection of model unit kinds that focus on a par-

ticular modelling perspective. This is not too different fromthe idea of idealised cognitive models (Lakoff, 1990, chap-ter 4). For example, we can define an Architectonic Model-ling Language as the organised collection of Wall, Room,Door, etc., or the UML Class Modelling Language as theorganised collection of Class, Attribute, Association, etc.Since any model always belongs to a given model kind,and every model kind is related to a particular modellinglanguage, the set of model unit kinds that a model uses iseasy to determine (Fig. 13).

We must make three points here. First of all, a model-ling language is an organised collection of model unit kinds.By ‘‘organised’’, we mean that the model unit kinds thatform part of a language must be carefully related to eachother so that their semantics are valid. For example,UML defines how Class and Attribute are related to eachother, and that definition governs how UML class modelscan make use of model units of these kinds. Model unitkinds, in this sense, are not defined independently but usu-ally as a metamodel, i.e. a model of potential models.6

From this perspective, the specification of UML’s abstractsyntax (OMG, 2004, 2005b) is a metamodel. Secondly, alanguage does not need to be composed of words or otherconventionally-looking units; our architectonic exampledescribes a language composed of concepts such as Wall,Room, Door, etc. This is well illustrated by the pattern lan-

guage of Alexander described in Alexander et al. (1977).Finally, concrete syntax (also known as ‘‘notation’’, i.e.the visual or otherwise perceivable artefacts that depict ele-ments in the language) is not part of a modelling language.UML, and OMG’s suite of technologies in general, use adifferent definition of ‘‘language’’, one that often allowsfor the inclusion of concrete syntax as a component ofthe language. This, however, is different to the line of dis-course that we are following here. Indeed, many worksequate ‘‘notation’’ with ‘‘modelling language’’ (for exam-ple, Fowler and Kendall, 2000, p. 1, ‘‘The modelling lan-guage is the [. . .] notation that. . .’’) or do not differentiatebetween the abstract syntax of the language (i.e. the modelunit kinds) and its concrete syntax or true ‘‘notation’’ (forexample, Eriksson and Penker, 1998, p. 7). However, weneed to acknowledge two facts. Firstly, a language can befully specified by formalising its abstract syntax and seman-tics; notation is not necessary for this purpose (see Green-field and Short, 2004, chapter 6). In fact, there are good

ModelKind

Model ModelUnit

ModelUnitKindLanguage

* *

IsComposedOf

1 *

IsComposedOf

* 1

Uses

*1

Of

*

1

Of

Fig. 13. Model kinds, models, model units, model unit kinds and languages.

SUSModel 2 Model 1

Language 1 Language 2

Fig. 15. Each model uses a particular language. Languages are depicted asellipses. Curved lines between a model and a language can be read as ‘‘isexpressed in’’; for example, Model 2 is expressed in Language 2.


examples of modelling languages, such as ISO/IEC 24744(ISO/IEC, 2007), that exist without a notation. Secondly,multiple notations can be obtained that are capable ofdepicting the model unit kinds of a given language. Forexample, a UML class model can be shown as boxes andlines on a sheet of paper (one notation, eminently graphi-cal), or as a sequence of XML tags in a file (another nota-tion, textual). For these reasons, we prefer to consider theconcept of notation as separate from the concept of lan-guage, although closely related (Fig. 14). An analogy hereis that the same concepts may be expressed (or ‘‘notated’’)using different languages and even alphabets (e.g. Roman,Cyrillic).

Since every model belongs to a given model kind, whichin turn uses a particular language, we can state that everymodel uses a particular language (Fig. 15).

Furthermore, we must realise that a model is built bycreating and assembling model units of the appropriatemodel unit kinds. The available model unit kinds, ofcourse, are defined by the language associated with the cor-responding model kind (see Fig. 14). Each model unit inthe model, therefore, is ‘‘of’’ a given model unit kind. Thisrelationship, although shown in Fig. 14 as an association,has strong instance-of semantics. For example, it is easyto understand that each class in a class model is an instanceof a Class model unit kind, and each attribute in the samemodel is an instance of an Attribute model unit kind. Sim-ilarly, each door in an architectural scale model is aninstance of a Door model unit kind. Since the relationshipbetween model units and their associated model unit kindsis that of instance-of, we can say that a metatypical inter-pretive mapping between them can be established and,for that matter, model unit kinds in a language actually

ModelKind

Model

Languag

1

IsComposed

* 1

Uses

*1

Of

Notation

**

Supports

Fig. 14. The concept of notation has been ad

represent the associated model units in the model. As a con-sequence, we can state that a language not only serves toexpress models, but it also represents (metatypically) anypossible model of the associated model kinds (Fig. 16).

Different models in a model chain may use different lan-guages. For example, it is possible to construct a UMLclass model of a program that, in turn, is expressed inC#. The UML class model uses UML as its language,while the computer program uses C# as its (modelling) lan-guage. In this context, the C# program is the SUS of theUML class model, and also a model of the final system.We have established in Section 2 that a model and itsSUS must be homomorphic, so we should expect, in ourexample, that the UML model and its SUS, namely theC# program, are homomorphic too. This means that eachindividual structural element of the UML model must beunequivocally mapped to one or more structural elementsof the C# program. Since both the UML model and theC# program are models, we can argue that the structuralelements to consider in any homomorphism are, precisely,the model unit kinds that compose such models. Conse-quently, the homomorphism between the UML class modeland the C# program is given by a set of interpretive map-

ModelUnit

ModelUnitKinde

* *

IsComposedOf

*

Of

*

1

Of

ded to the concepts depicted in Fig. 13.

SUSModel 2Model 1

Language 2Language 1

Fig. 16. Languages represent the models that are defined in their terms, i.e. models of the language’s associated model kinds. Languages are forward-looking models of the models, as shown by the arrows pointing from language ellipses to model boxes. Note the subtle but important difference betweenthis figure and Fig. 15.

7 In different contexts, is-a can refer to either is-an-instance-of or is-a-kind-of (Atkinson et al., 2000). Clearly here it means the former.


pings from the model units of the UML class model andthe model units of the C# program. For example, an asso-ciation in the UML model could be mapped to a referencedobject in the C# program. Since model units can be classi-fied into model unit kinds, we can abstractly define theinterpretive mappings between these models by looking atthe model unit kinds that compose their respective lan-guages and by establishing the appropriate language-levelmappings between them. For example, we could state thatthe Association model unit kind of the UML modellinglanguage can be mapped to a ReferencedObject model unitkind of the C# language. We need to emphasise that theselanguage-level mappings are not interpretive mappings;they operate between model unit kinds rather than betweenmodel units. Specifically, the cardinalities of such mappingscan be many-to-one or many-to-many (i.e. multiple modelunit kinds in the model can be mapped to the same modelunit kind in the SUS). This does not mean that the lan-guage-level mappings are useless; quite the contrary, theyform the infrastructure on which code can be generatedfrom models or, more generically, models can be trans-formed into other models, perhaps automatically as pro-posed by MDA (OMG, 2003a).

A particularly interesting case of language-level map-pings is that of ‘‘seamless transition’’. This term has beenused in the literature (for example, Henderson-Sellers,1992, pp. 10–12; Meyer, 1997, pp. 22–23) to claim thatobject-orientation provides a seamless transition betweendevelopment phases, i.e. the same concepts (namely, objectand class) are used along the development process from thebeginning to the end of a project. If this claim is true, weshould be able to define Object and Class model unit kindsand make them components of every single language that isused along an object-oriented software development pro-ject. Again using our previous example, we can see, in fact,that both UML and C# incorporate the concepts of Classand Object. Having reached this point, we must ask, is theUML Class the same thing as the C# Class (ditto forObject)? In other words, do UML Class and C# Class havethe same semantics? If they do, the language-level mappingbetween them is straightforward, and the promised seam-lessness is achieved. However, it is easily shown that thisis not the case. Although a UML class and a C# class cor-respond roughly to the same idea, they differ significantlyin the details. As we have explained in this Section, modelunit kinds are not defined in isolation but in close relation-

ship to each other within a given language. Therefore, weshould expect that the semantics of any model unit kindare strongly conditioned by the neighbouring model unitkinds within that specific modelling language. For example,C# Class is related to C# Property, which does not have amatching concept in UML; therefore, C# Class is some-what different to UML Class. The necessarily cumulativeeffect of little differences like this makes the language-levelmappings between UML Class and C# Class non-trivialalthough not too complex either, since, as we have said,they correspond to the same overall idea. We must con-clude, therefore, that seamlessness in object-oriented mod-elling exists only at certain level of abstraction rather thanbeing an absolute truth. In this sense, seamlessness is a use-ful concept to illustrate the fact that most languages in anobject-oriented environment do incorporate a core of clo-sely related concepts, but it should not be used as a formalstatement at a more detailed level.

Another interesting issue related to modelling languagesis that of ‘‘logical’’ vs. ‘‘physical’’ representation (the terms‘‘logical’’ and ‘‘physical’’, in this context, are taken fromAtkinson and Kuhne (2002), although these contrastingnames are much, much older). Consider a book object ina library management system; is this object an instance ofthe Book class, or is it an instance of the Object class? Inother words: is the book object a book or an object? It iscorrect to say that the book object is a7 book, but it is alsocorrect to say that it is-an object (Fig. 17).

From a representational perspective, the book object isrepresented by two different model entities: the Book classand Object class. From a UML perspective, the bookobject seems to be an instance of two unrelated classes,which is illegal. To answer this apparent contradiction,we must realise that Book and Object do not belong tothe same model. Two different models are involved here:a physical model containing the Object class, plus a logicalmodel containing the Book class – as hinted at in Atkinsonand Kuhne (2003). Both models represent the SUS inwhich the book object exists (Fig. 18).

We have defined a model kind as a specific kind ofmodel, characterised by its focus, purpose and level ofabstraction. The two models involved in Fig. 18 have

+TitleBook

Id = 197Title = Alfanhuí

b

+IdObject

«instanceOf»«instanceOf»*Fig. 17. An object as instance of two classes. The object ‘‘b’’ is a book (ithas a title) and also an object (it as an object id). This is not a valid UMLdiagram, as indicated by the asterisk, since an object must be a directinstance of only one class.

Book Management System

PhysicalModel

Language 1

Language 2

LogicalModel

b

Object

Book

Fig. 18. An SUS entity represented by two different model entities. TheBook Management System is the SUS for two different models, PhysicalModel and Logical Model. The object ‘‘b’’ in this SUS is represented byone model entity in each of these two models.


PhysicalModel

Language 1b

Object


different purposes and different levels of abstraction, so wecan say that they are of different kinds. Physical modelsrepresent SUS ontologically, i.e. using model unit kindsthat correspond to the most generic and universal ideasthat we can think of, such as Object or Class, sometimescalled Entity and Category, arguably inherent to thehuman mind according to Barkow et al. (1992) and Lakoff(1990). On the other hand, logical models represent SUSepistemologically, i.e. using context-dependent anddomain-specific model unit kinds. The general idea ofobject (or entity) is widely applicable and perhaps univer-sal, while the idea of a book is dependent on a specificsocio-cultural environment and application domain.Notice that our use of the word ‘‘ontologically’’ is notrelated to the common use of ‘‘ontology’’ in computer sci-ence, which we (and most dictionaries) deem inappropri-ate,8 but rather to the definition of ontology as given bye.g. Bunge (1977, 1979).

Some observations can be made with regard to Lan-guage 1 and Language 2 in Fig. 18. Applying conventionalobject-oriented wisdom, we can see that the class Book inthe logical model can be expressed as a subtype of the classObject in the physical model. In fact, most object-orientedprogramming languages and class libraries contain a class(often called ‘‘Object’’ or something similar) that acts asthe default supertype of any other class possibly defined.What would be the implications of defining Book as a sub-type of Object? The most evident consequence would bethat the subtype-of relationship from Book to Objectdefines a metatypical interpretive mapping, which, in turn,suggests that the physical model represents the logicalmodel, which becomes a SUS of the former. This makessense, since the physical model has been described as onto-

8 Ontology refers to the being of the world as it exists, and independentlyof any perception or cognition that may be performed on it; epistemology,more correctly, refers to how humans perceive and conceptualise theobserved world. In other words, the ontology of the world would notchange had human beings never existed, whereas epistemology is tightlytied to human existence, perception and cognition. It can be argued thatother intelligent species would enjoy different epistemologies, but theirexistence (or inexistence) does not alter the ontology of the world. Incomputer science today, the word ‘‘ontology’’ is commonly used to mean aconceptual (and therefore human-mediated) model, a meaning that ismore closely related to epistemology than to true ontology.

logically universal and, therefore, we can assume that it iscapable of representing any possible SUS. Given this, thelogical model can, consequently, be represented by boththe physical model and Language 2 (Fig. 19).

Given that the physical model has been determined torepresent the logical model, the fact that it also representsthe SUS (the Book Management System in our example) isgiven by the transitiveness of the representation process.We must consider, at this point, whether the physicalmodel is not simply the same thing as Language 2. By reor-ganising the diagram in Fig. 19 it is shown that, in fact,Physical Model is just another name for Language 2(Fig. 20).

The problem of dual representation (i.e. physical vs. log-ical), explicitly exposed in the context of software develop-ment methodologies by several works, such as (Atkinson

LogicalModel

Language 2

Book

Fig. 19. Since Object is mapped to Book, Logical Model is represented byPhysical Model as well as Language 2. Notice that Logical Model is nowdepicted with slightly rounded angles, trying to convey the idea that it isalso a SUS (of Physical Model) as well as a model. This raises a questionregarding the relationship between Physical Model and Language 2, sinceboth represent the Logical Model.

LogicalModel


Language 1

PhysicalModel

b

Object

Book

Fig. 20. Physical Model is Language 2. The representation relationshipsand interpretive mappings given by transitiveness are not shown.


and Kuhne, 2002; Henderson-Sellers and Gonzalez-Perez,2005), is thus solved when we consider it in the light of rep-resentation theory since the physical model is not a modelof the SUS but is the language used to express the model ofthe SUS.

There is a final issue regarding modelling languages thatis worth considering. How are modelling languagesdefined? Usually, a modelling language is formally orsemi-formally specified as a forward-looking model thatrepresents any possible SUS that can be created with thelanguage. For example, UML is defined by the so-calledUML metamodel, which is simply a specification (a for-ward-looking model) of any potential valid UML usermodel (see Fig. 11). It should be noted that the UML meta-model is not a specification of UML, but is the UML lan-guage itself, like the phonetics, syntax, grammar, semanticsand pragmatics of English is not a specification of Englishbut English itself. If we want a specification of UML, weneed to look for a forward-looking model that representsUML; MOF is the supposed answer. MOF can be seenas either the language in which UML is expressed, or amodel of UML. In fact, it is both, since languages representthe models that they express, as we have shown above. Inturn, UML is both a model of UML user models and thelanguage in which they are expressed (Fig. 21), a languagethat will evolve by focussing on ‘‘the most pragmatic con-

MOF

UML

RunningSystemUser Model

Book

Class

Class

b

Fig. 21. MOF and UML as languages and models. Please compare withFig. 11.

cepts will survive and thrive, and those that are impracticalwill be garbage collected’’ (Kobryn, 2004).

Both MOF and UML contain a Class model unit kind.As we have established earlier, these two Class model unitkinds are different, although roughly associated with thesame ontological idea of a class. Some authors havepointed out that the fact that MOF contains a Class modelunit kind makes it an invalid metamodel of UML, sinceClass belongs to UML. We must emphasise here that thetwo Class model unit kinds are completely different entitiesand therefore this argument is not valid. We agree that, inboth cases, Class corresponds to the well-known concept ofa class in the object-oriented paradigm; however, their for-mal semantics are different and, consequently, they com-prise slightly different formal variations of such acommon, non-formalised object-oriented paradigm.

5. Nodes and arcs

We have described, in the previous section, how physicalmodels take an ontological view of the SUS that they rep-resent (see also Guizzardi et al., 2002). We can argue thatthe very basic core model unit kinds at this level are Object,Class, Association and Link. In general, Object is useful torepresent SUS entities isotypically or prototypically, whileClass is useful to represent them metatypically. We can alsosay that Link is useful to represent connections betweenSUS entities isotypically or prototypically, while Associa-tion can be used to represent connections between SUSentities metatypically. Put differently, the very basic onto-logical ideas that we need to model are those of ‘‘things’’(captured by the Object and Class model unit kinds) and‘‘connections between things’’ (captured by Link and Asso-ciation) (Lakoff, 1990). These four model unit kinds can begrouped into a universal object-oriented language tenta-tively called OOLang.9

Since OOLang is ontologically universal, we can arguethat anything can be represented by a model that usesOOLang. This means that any SUS can be represented asa collection of ‘‘things’’ and ‘‘connections between things’’.In other words, as a graph of nodes and arcs. Ontologicallyspeaking, we can say that relevant entities in the SUS arerepresented as nodes (either objects or classes), and rele-vant semantic connections between entities in the SUSare represented as arcs (either links or associations). But,what is a ‘‘relevant entity’’? Since any model has a purpose,we need to assess relevance on a case by case basis. Forexample, when constructing a library management system,the relevant entities that are detected may include books,clients and loans. In addition, relevant connections canbe identified, namely between books and loans and

9 OOLang is not a proposal for a new language. Neither have we tried toassess whether ER could be used instead. The label OOLang is givenmerely as a convenience for the group of ideas we are exploring in thecontext of this paper and the theory development i.e. OOLang is fictitiousand temporary.


between loans and clients. The three identified relevantentities can be represented in a model (let us assume weuse the UML language) by three classes, namely Book, Cli-ent and Loan, and the connections between them by theappropriate associations. An alternative way of modellingthe same SUS would be to consider only two classes, Bookand Client, and model Loan as an association betweenthem (Fig. 22).

Although software modelling best practices would per-haps advocate modelling loans as a class, the mere fact thatsome people consider the option of representing loans as anarc (rather than a node), while nobody would considermodelling books or clients as arcs, is significant. This differ-ence underscores that the decision of modelling a relevantentity as a node or as an arc is not entirely objective orcompletely pre-determined by the nature of the SUS entity.The focus, purpose and level of abstraction of the modelbeing constructed can, in fact, influence this decision.

This issue gets particularly complicated when specifyingmodelling languages. As we have seen in the previous sec-tion, a modelling language (let us call it the target) is spec-ified by using another modelling language, which representsthe target. For example, Fig. 21 shows how MOF specifiesUML. Some classes in UML, such as Class and Attribute,represent SUS entities that are unequivocally seen asnodes. Other UML classes, however, represent SUS entitiesthat are often referred to as ‘‘connections between things’’,such as Association and Generalization. The concept of anassociation, for example, clearly refers to the connectionbetween two things, but UML has chosen to represent itas a class (in the metamodel) rather than an associationbetween classes because it is of key relevance. Furthermore,Association in UML must be a ‘‘thing’’ rather than a ‘‘con-nection between things’’ because it must be connected toother things itself. MOF, the language in which UML isspecified, allows for a higher amount of detail in classesthan in associations, so it makes sense that key SUS entitiesare modelled by UML as classes rather than associations.Other ‘‘connections between things’’, such as the relation-ship between a class and each of its attributes, are notjudged as being so important as to deserve a class inUML, so they are represented by an association betweenthe involved classes. We must realise, at this point, thatmodels are often represented by graphical depictions, andsuch depictions are models themselves that represent thesaid models. For example, the UML diagram shown in

+TitleBook Loan

1 *

RefersTo

+TitleBook

*

HasLoa

Fig. 22. Two alternative ways (top and bottom) o

Fig. 22 is a representation of a UML model that residesin my mind. Note the emphasis on the words ‘‘diagram’’and ‘‘model’’. The UML model in my mind, in turn, isthe SUS of the UML diagram and, at the same time, rep-resents some other SUS. Diagrams also use the conceptsof nodes and arcs. For example, in the bottom half ofFig. 22, two nodes (the Book and Client class boxes) areshown, as well as an arc between them (the HasLoanOnassociation line). However, it would be wrong to think thatan arc in the diagram (or in the model, since the diagramand its SUS are isotypical) is always a representation of a‘‘connection between things’’ in the SUS. For example,all three model entities (the two classes plus the associa-tion) are represented in the UML specification by nodes,namely the classes Class and Association. Arcs in theUML specification (such as the association between Classand Association) are not explicitly represented in the dia-gram, but topology or location is used. For example, theassociation line corresponding to the HasLoanOn associa-tion touches the class boxes corresponding to Book andClient; this is implicit notation for the association, in theUML specification, between Class and Association.Although this is a matter of pure convention, UML tendsto use explicit graphical artefacts for nodes in its specifica-tion, while implicit notation is often used for arcs.

Finally, we must stress that the choice of arc vs. nodewhen representing an SUS entity pertains ultimately tothe language designer; it is not entirely given by the SUSbeing represented. By making decisions in this respect,the language designer injects a given bias into the languagethat makes it more (or less) appropriate for different pur-poses and levels of abstraction.

6. Integrating product and process

The term ‘‘metamodel’’ has been used so far in thispaper to mean ‘‘a model of models’’ (Favre, 2005). Thisis one of the two meanings often found in the literature,especially in the context of information modelling. The sec-ond meaning is usually found in the process modelling andmethod engineering literature, and roughly corresponds to‘‘a model of methodologies’’. An example of the first mean-ing is the UML metamodel (OMG, 2004); an example ofthe second, the OPEN metamodel (Firesmith and Hender-son-Sellers, 2002). In the context of software developmentmethodologies, metamodels are simply forward-looking

+NameClient

* 1

HeldBy

+NameClient

*

nOn

f modelling loans that clients have on books.


models that represent any possible methodology that canbe created. Like their model-oriented cousins (see firstmeaning of ‘‘metamodel’’, above), methodology metamod-els can be seen also as languages that can be used toexpress, in this case, methodologies. In any case, the con-tent of a methodology metamodel depends on what themetamodel authors understand by ‘‘methodology’’. Wewill adopt the definition that we proposed and justified(Gonzalez-Perez and Henderson-Sellers, 2006): a method-ology is a specification of the process to follow and the work

products to be generated, plus consideration of the people and

tools involved, during a software development effort. Since amethodology needs to consider both process and productaspects, and a methodology metamodel must be able torepresent any possible relevant methodology, then processand product aspects must be integrated within the meta-model (Atkinson and Kuhne, 2001b; Rolland, 2005). Theonly publicly available standard metamodel, as far as weknow, that achieves this, is ISO/IEC 24744 ‘‘SoftwareEngineering Metamodel for Development Methodologies’’(ISO/IEC, 2007) (Fig. 23) built on top of the AustralianStandard AS 4651-2004 ‘‘Standard Metamodel for Soft-ware Development Methodologies’’ (SA, 2004). The phi-

MethodologyElement

+Purpose+MinCapabilityLevel

WorkUnitKind

+DescriptionWorkProductKind

+DefinitionModelUnitKind

+NameTemplate

EndeavourElement

+StartTime+EndTime+Duration

WorkUnit

+CreationTime+LastChangeTime+Status

WorkProduct

ModelUnit

ProducerKind

+NameProducerStage

StageKind

Fig. 23. The core of ISO/IEC 24744. Most classes occur as pairings within powin a constructed methodology are thus clabjects (Atkinson, 1998), having boththe method domain as specifications for slot values in the endeavour domaReproduced with permission from ISO. The ISO/IEC 24744 international stan

losophy underpinning such integration is a linguisticsimile: meaningful messages are built by applying actionsto objects or, more specifically, complete sentences are con-structed by combining verbs and nouns. Verbs specify theactions that are performed, while nouns denote the authorsand receivers of the said actions. Verbs without nouns canonly specify actions, but an action needs a noun on whichto be performed; similarly, nouns without verbs can onlyspecify receivers or authors of actions, but not the actionsthemselves. Translating this into the methodology field, asoftware development process defines the actions to be per-formed when developing software, but these actions aremeaningless without a detailed definition of the producersthat execute the actions and the products that are involved.Similarly, products of software development (such as mod-els or documents) alone are not enough; an indication ofthe process appropriate to create and employ them isnecessary.

ISO/IEC 24744 is intended to be used by methodologistsin creating specific, tailored methodologies (see MethodDomain in Fig. 24). On the process side, ISO/IEC 24744offers classes that allow the methodologist to define kindsof activities, tasks, techniques and phases, among others

Resource

+NameLanguage

+NameNotation

+ExpressionConstraint

+Description+MinCapabilityLevel

Outcome

+DescriptionGuideline

ertype patterns (depicted by dashed lines) but some do not. Most elementsa class facet and an object facet. In this way, class facet attributes occur inin. Please see (Henderson-Sellers and Gonzalez-Perez, 2005) for details.dard can be obtained from the ISO web site, www.iso.org.

http://www.iso.org

endeavour

method

metamodelActivity

WorkUnit

Task Technique

* *

methodologies assessment quality tools

endeavourendeavour

methodmethod

metamodelmetamodelActivity

WorkUnit

Task Technique

* *

methodologies assessment quality toolsmethodologiesmethodologies assessmentassessment qualityquality toolstools

Fig. 24. Three domains of ISO/IEC 24744. These are aligned with industrial reality in that they represent (i) the domain in which people work in real timewith real projects; (ii) the method domain wherein all tools available to the development team are kept and (iii) the metamodel domain where the rules ofall contents of the method layer are formally defined.


(Metamodel Domain in Fig. 24). This falls within the samescope as OMG’s SPEM (OMG, 2005a). From the productside, ISO/IEC 24744 offers classes that allow the methodol-ogist to define model kinds, languages and model unitkinds. This falls within the same scope as OMG’s MOF(OMG, 2002). ISO/IEC 24744 defines associations betweenprocess-related classes and product-related classes. Conse-quently, the appropriate links can be defined between pro-cess and product elements in the methodology. Forexample, a methodologist could define a task kind named‘‘Write class code’’, which specifies what to do in orderto write the source code for any given class. This task spec-ification, however, is meaningless unless there is a clearunderstanding of what a class is. SPEM, for example,would allow the methodologist to define this task too,but since it does not integrate product modelling aspects,no meaningful link could be established between this taskand the concept of a class. In other words, the designermight (inadvertently) use a definition for Class that isincompatible, ambiguous or unintelligible to other users.With ISO/IEC 24744, on the other hand, the methodolo-gist could define a model unit kind named ‘‘Class’’ andattach the appropriate definition, and then link the ‘‘Writeclass code’’ task kind to the ‘‘Class’’ model unit kind toreflect the fact that the said task refers to the said modelunit kind. The capability of ISO/IEC 24744 to allow themethodologist to define both process and product aspectsdoes not imply that both must be defined every time amethodology is needed; a method engineering approach(Brinkkemper, 1996) guarantees that a significant reposi-tory of pre-defined methodology components is maintainedand re-used as necessary.

In contrast, the OMG suite of products would need tobe integrated at the most abstract level possible in orderto achieve a similar degree of power. MOF would seem

to be an appropriate candidate for such as integrationbut, unfortunately, MOF mixes together two different con-cerns: on the one hand, MOF tries to define the infrastruc-ture necessary to define modelling languages (such asUML); on the other hand, it tries to be a self-model so itcan fulfil its role at the top of the hierarchy. Our claim hereis that a true self-model should be minimal and as close aspossible to the ontologically universal OOLang languageintroduced in Section 5 or to the metametamodel of CDIF(ISO/IEC, 1998). If the self-model is not minimal (i.e. con-tains entities that are not used by the self-model itself), thenthese entities would not have any interpretive mappings toany SUS entities, which violates one of the premises in ourtheory (see Section 2). From this perspective, and for MOFto be a self-model, every class in it should have instancesthat are part of MOF itself. Since MOF is a language spec-ification, structural by nature, classes such as Operationand Exception cannot have instances that are part ofMOF. Therefore, we must conclude that it contains moreclasses than it needs to define itself. Of course, this maywell be a consequence of trying to offer the necessary infra-structure to represent modelling languages. A possiblesolution to this paradox would be to reduce the MOF toa minimal self-model, strongly ontological, and then createa methodology metamodel as an instance of MOF. Such ametamodel would justifiably focus on defining the languageelements necessary to specify methodologies, addressingboth process and product aspects. In this OMG-specificscenario, UML would be the product side of any method-ology, while a revised form of SPEM would comprisethe process side of the above mentioned metamodel(Fig. 25). UML and SPEM would become two looselylinked components as compared to the tight process/prod-uct integration of ISO/IEC 24744, as discussed in the pre-vious paragraph.

Methodology

MOF

User Model

RunningSystem

UML

Methodology Metamodel

ProductSide SPEM

Process Side

Fig. 25. Reorganising OMG’s product suite into a meaningful hierarchy. The box labelled ‘‘MOF’’ on top represents a ‘‘distilled’’ MOF that is a true self-model. Notice how SPEM and UML reside at different conceptual levels.


Finally, we must note that UML is a direct instance ofMOF, but it should not be; this becomes clear if we realisethat UML is one of many possible modelling languages,while SPEM is not one of many possible process specifica-tions but a (hopefully universal, within the OMG context)metamodel to build process specifications. In other words,whereas UML is just one possible modelling language andthe usage of others is contemplated, SPEM is, within theOMG context, the process metamodel to be used. UMLand SPEM, therefore, are not at the same conceptual level,having different foci and levels of abstraction, so integrationcannot be performed between them simply in the wayintended by the OMG. The fact that SPEM can be expressedas a UML profile confuses many authors into believing thatSPEM is intrinsically related to UML. This is not the case;the existence of a UML profile for SPEM only means thatSPEM can be expressed using UML, very much like SPEMcan be expressed in English or Spanish or any other suffi-ciently expressive language. SPEM is a network of conceptsand relationships, which can be denoted using the model unitkinds supplied by UML or those supplied by any otherappropriate language. The UML profile for SPEM is usefulto customise UML tools into drawing SPEM diagrams, butdoes not create a conceptual link between UML and SPEM.

7. Modelling infrastructure

We have shown that a true self-model should be minimaland only attempt to capture ontologically universal con-

cepts, as the fictitious OOLang does. We have also arguedthat a language like OOLang is capable of representingany conceivable SUS, given its ontological universalityand its independence from any particular applicationdomain. From this perspective, an ontologically universallanguage can be seen as the implementation of a paradigm;in our case, OOLang implements an extremely simple vari-ation of the object-oriented paradigm. Other languages thatimplement other paradigms (or even the same one) are, ofcourse, possible.

Since a language like this is capable of representing anySUS, we can think of it as a modelling infrastructure thatcan be used at any point in a multi-layered structure madeof chained models (see Section 3), such as OMG’s stack(Gonzalez-Perez and Henderson-Sellers, 2005a). This isexactly the approach that we have followed to design andconstruct Xome (weak acronym for ‘‘extended object mod-elling environment’’), a theoretical environment and toolsetthat looks at object-oriented modelling from an extremelygeneric point of view (Gonzalez-Perez, 2005). OOLang isused as an ontologically universal self-model, from whichthe Xome Modelling Infrastructure (XMIS) is defined.XMIS is a superset of OOLang that consists of the follow-ing conventional classes: Class, Attribute, Association,AssociationEnd, Object, Value and Tuple. These classescapture well-known semantics and should be self-explana-tory for the purpose of this work. The classes Class, Object,Association and Link map one-to-one to OOLang classeswith the same names. In addition, XMIS extends the

LogicalModel


XMIS

b

Object

Book

Fig. 27. Physical Model and Language 1 from Fig. 20 can be collapsedinto a single XMIS definition, given the universality of XMIS.


conventional object-oriented paradigm with some ‘‘exotic’’elements, which include PowertypePattern and Clabject. Apowertype pattern is basically a pair of classes in which oneis a powertype of the other (Henderson-Sellers and Gonz-alez-Perez, 2005). A clabject is a dual entity that has a classfacet plus an object facet, where both class and object rep-resent the same concept (Atkinson, 1998). A powertypeinstantiation mechanism is also introduced, and definedas the generator for the relationship that occurs betweena clabject and a powertype pattern. This relationship is acombination of a conventional instance-of relationship(from the object facet of the clabject to the powertype class)plus a conventional subtype-of relationship (from the classfacet of the clabject to the partitioned type of the power-type pattern). Powertype/clabject instance-of relationshipsalso establish metatypical mappings, like conventionalinstance-of and subtype-of relationships.

A model in Xome is expressed in terms of XMIS, i.e. asa collection of instances of the classes in XMIS. Not allmodels will contain instances of all the classes in XMIS;for example, a class model would not typically containobjects, values or tuples. In Xome, XMIS is the languagein which all models are expressed (Fig. 26), includingXMIS itself. XMIS is not a self-model since it is not mini-mal, but can represent itself since it is a superset ofOOLang.

At this point, we can reconsider our discussion fromSection 4 regarding physical vs. logical models, and partic-ularly the example in Fig. 20. We said that the physicalmodel was the language that specifies the logical model,and that the physical model, in turn, was specified by an

MethodologyMetamodel

XMIS

XMIS

XMIS

XMIS

OOLang

Fig. 26. A true modelling infrastructure. XMIS is th

anonymous language called Language 1. In the light ofXome and XMIS, we can conclude that the physical modelis XMIS and, since XMIS specifies itself, Language 1 is also

XMIS. Therefore, Fig. 20 can be redrawn as shown inFig. 27.

In this way, the dual representation problem of physicalvs. logical instantiation vanishes completely when using acommon modelling infrastructure such as XMIS.

8. Conclusions

This paper presents a technology-agnostic analysis ofthe concepts of model and modelling in software engineer-ing, using an approach based on representation theory. Ithas been shown that a model is always homomorphic withits subject under study (SUS), and that interpretive map-pings (isotypical, prototypical or metatypical) are requiredin order to trace model entities back to the SUS entities

Methodology

User Model

RunningSystem

XMIS

e language used to specify models at any level.


that they represent. The difference between forward- andbackward-looking models has been explained, and theissue of the shifts in focus identified. Modelling languageissues have also been considered, especially around theproblem of physical vs. logical representation. A solutionhas been proposed based on representational theory. Thechoice between nodes and arcs in models and languagespecifications has been discussed, and a clarification madebetween arcs in a language and arcs in the models createdwith it. The need for product and process integration inmethodologies has also been addressed, leading to the con-clusion that a mesh of verbal plus nominal nodes is neces-sary in any methodology metamodel. Finally, the need fora common, cross-cutting modelling infrastructure has beenestablished, and a solution proposed in the form of anontologically universal modelling language, OOLang, as asample of the kind of language required.

Having established the theory, a brief analysis of currentmodelling approaches, focused on the OMG’s suite ofproducts, has been made, significantly extending the dis-cussion of (Gonzalez-Perez and Henderson-Sellers,2005a). UML has been determined to be ambiguous withrelation to its Object or InstanceSpecification (dependingon the UML version) class, and a ‘‘hidden’’ isotypical map-ping has been identified (Fig. 12) that prevents softwaredevelopers from deriving real class models from UML.Also, OMG’s process standard (SPEM) and modellingstandard (UML) have been determined to be incompatibleas far as an integral process plus product methodologymetamodel is concerned. The ISO/IEC 24744 InternationalStandard, however, is considered valid and suggested as analternative.

With regard to future work, we plan to address the con-sequences of having a self-model (such as OMG’s MOF)with regard to homomorphism and interpretive mappings.We will also consider investigating the shift of focus frombackward- to forward-looking modelling that occurs some-where in the middle of software development projects andhow the research described here can be used to clarify thisswitch.

Acknowledgement

We wish to thank the Australian Research Council forproviding funding towards this project. This is contribu-tion number 06/05 of the Centre for Object TechnologyApplications and Research.

References

Alexander, C., Ishikawa, S., Silverstein, M., 1977. A Pattern Language.Oxford University Press, New York.

American National Standards Institute, 1989. X3.138. InformationResource Dictionary System.

Atkinson, C., 1998. Supporting and applying the UML conceptualframework. ‘‘UML’’ 1998: Beyond the Notation, LNCS 1618.Springer-Verlag, Berlin (Germany), pp. 21–36.

Atkinson, C., Kuhne, T., 2001a. The essence of multilevel metamodelling.‘‘UML’’ 2001: Modeling Languages, Concepts and Tools, LNCS 2185.Springer-Verlag, Berlin, Germany, pp. 19–33.

Atkinson, C., Kuhne, T., 2001b. Processes and products in a multi-levelmetamodeling architecture. Int. J. Software Eng. Knowledge Eng. 11,761–783.

Atkinson, C., Kuhne, T., 2002. Rearchitecting the UML infrastructure.ACM Trans. Model. Comput. Simul. 12, 290–321.

Atkinson, C., Kuhne, T., 2003. Model-driven development: a metamod-eling foundation. IEEE Software 20, 36–41.

Atkinson, C., Kuhne, T., Henderson-Sellers, B., 2000. To meta or not tometa – that is the question. J. Object-Oriented Programm. 13, 25–32.

Barkow, J.H., Cosmides, L., Tooby, J., 1992. The Adapted Mind:Evolutionary Psychology and the Generation of Culture. OxfordUniversity Press, New York.

Bezivin, J., 2005. On the unification power of models. Software Syst.Modell. 4, 171–188.

Brinkkemper, S., 1996. Method engineering: engineering of informationsystems development methods and tools. Inform. Software Technol.38, 275–280.

Bunge, M., 1977. Treatise on Basic Philosophy – Ontology I: TheFurniture of the World. Reidel, Boston, MA.

Bunge, M., 1979. Treatise on Basic Philosophy – Ontology II: A World ofSystems. Reidel, Boston, MA.

Davies, I., Green, P., Rosemann, M., Gallo, S., 2004. Conceptualmodelling – what and why in current practice. 23rd InternationalConference on Conceptual Modelling (ER 2004), 8–12 November2004. In: LNCS, vol. 3288. Springer-Verlag, pp. 30–42.

Dolk, D.R., Kirsch II, R.A., 1987. A relational information resourcedictionary system. Commun. ACM 30, 48–61.

Eriksson, H.-E., Penker, M., 1998. UML Toolkit. John Wiley & Sons,New York.

Favre, J.-M., 2005. Foundations of model (driven) (reverse) engineering:models; Episode I: Stories of The Fidus Papyrus and of The Solarus.In: Seminar 04101 ‘‘Language Engineering for Model-Driven SoftwareDevelopment’’, Dagstuhl Seminar Proceedings InternationalesBegegnungs.

Firesmith, D.G., Henderson-Sellers, B., 2002. The OPEN ProcessFramework. Addison-Wesley, London.

Fowler, M., Kendall, S., 2000. UML Distilled. Addison-Wesley, Reading,MA.

Gonzalez-Perez, C., 2002. Sistemas de Informacion para Arqueologıa:Teorıa, Metodologıa y Tecnologıas. Spring, Oxford, UK.

Gonzalez-Perez, C., 2005. Tools for an extended object modellingenvironment. 10th IEEE International Conference on Engineering ofComplex Computer Systems (ICECCS), 16–20 June 2005. IEEEComputer Society, pp. 20–23.

Gonzalez-Perez, C., Henderson-Sellers, B., 2005a. A representation-theoretical analysis of the OMG modelling suite. The 4th InternationalConference on Software Methodologies, Tools and Techniques, 28–30September 2005. In: Frontiers in Artificial Intelligence and Applica-tions, vol. 129. IOS Press, Amsterdam, pp. 252–262.

Gonzalez-Perez, C., Henderson-Sellers, B., 2005b. Templates andresources in software development methodologies. J. Object Technol.4, 173–190.

Gonzalez-Perez, C., Henderson-Sellers, B., 2006. A powertype-basedmetamodelling framework. Software Syst. Modell. 5, 72–90.

Greenfield, J., Short, K., 2004. Software Factories. John Wiley & Sons.Guizzardi, G., Herre, H., Wagner, G., 2002. On the general ontological

foundations of conceptual modelling. 21st International Conference onConceptual Modeling (ER), 7–11 October 2002. In: LNCS, vol. 2503.Springer-Verlag, pp. 65–78.

Harkema, H., 1995. Automatic detection and correction of syntax errorsin tutoring systems for language instruction. In: Sixth ComputationalLinguistics in the Netherlands Meeting. UIA Center for DutchLanguage and Speech, Antwerp, Belgium.

Henderson-Sellers, B., 1992. A Book of Object-Oriented Knowledge.Prentice-Hall, New York.


Henderson-Sellers, B., Gonzalez-Perez, C., 2005. The rationale of pow-ertype-based metamodelling. In: Second Asia-Pacific Conference onConceptual Modelling, 30 January–4 February 2005. AustralianComputer Science Communications, vol. 7, no. 6. Australian Com-puter Society, pp. 7–16.

International Organization for Standardization/International Electrotech-nical Commission, 1998. ISO/IEC 15474-1. CDIF Framework – Part1: Overview.

International Organization for Standardization/International Electrotech-nical Commission, 2007. ISO/IEC 24744. Software Engineering –Metamodel for Development Methodologies.

Jackson, M., 2002. Some basic tenets of description. Software Syst.Modell. 1, 5–9.

Kobryn, C., 2004. UML 3.0 and the future of modeling. Software Syst.Modell. 3, 4–8.

Kuhne, T., 2005. What is a model? In: Seminar 04101 LanguageEngineering for Model-Driven Software Development, DagstuhlSeminar Proceedings Internationales Begegnungs.

Lakoff, G., 1990. Women, Fire, and Dangerous Things. University ofChicago Press.

Ludewig, J., 2003. Models in software engineering – an introduction.Software Syst. Modell. 2, 5–14.

Martin, J., Odell, J., 1992. Object-Oriented Analysis and Design. Prentice-Hall, Englewood Cliffs, NJ.

Meyer, B., 1997. Object-Oriented Software Construction. Prentice-Hall,Upper Saddle River, NJ.

Object Management Group, 2002. Formal/2002-04-03. Meta ObjectFacility (MOF) Specification, version 1.4.

OMG, 2003a. MDA Guide, Object Management Group.Object Management Group, 2003b. Formal/03-03-01. Unified Modelling

Language Specification, version 1.5.Object Management Group, 2004. ptc/04-10-14. Unified Modelling

Language Specification: Infrastructure, version 2.Object Management Group, 2005a. formal/05-01-06. Software Process

Engineering Metamodel Specification, version 1.1.Object Management Group, 2005b. formal/05-07-04. Unified Modelling

Language Specification: Superstructure, version 2.Peterson, D. (Ed.), 1996. Forms of Representation, Intellect, Exeter, UK.Rolland, C., 2005. Modelling multi-facetted purposes of artefacts. The 4th

International Conference on Software Methodologies, Tools and

Techniques, 28–30 September 2005. In: Frontiers in ArtificialIntelligence and Applications, vol. 129. IOS Press, Amsterdam,pp. 3–17.

Standards Australia, 2004. Standard Metamodel for Software Develop-ment Methodologies.

Sabetzadeh, M., Easterbrook, S., 2005. An algebraic framework formerging incomplete and inconsistent views. 13th IEEE InternationalConference on Requirements Engineering. IEEE Computer Society,Paris, France.

Seidewitz, E., 2003. What models mean. IEEE Software 20, 26–31.Stachowiak, H., 1973. Allgemeine Modelltheorie. Springer-Verlag, Wien.

Cesar Gonzalez-Perez is a research project leader at the European SoftwareInstitute, where he leads research efforts in the areas of conceptual mod-elling, metamodelling and development methodologies. Previously, heworked over 3 years at the Faculty of IT of the University of Technology,Sydney. He is the founder and former technical director of Neco, a com-pany based in Spain specialising in software development support services,which include the deployment and use of OPEN/Metis at small and mid-sized organisations. Cesar has also worked for the University of Santiagode Compostela in Spain as a researcher in computing & archaeology, andgot his Ph.D. in this topic in 2000. Cesar has published over 30 academicpapers in software engineering and other areas.

Brian Henderson-Sellers is the Director of the Centre for Object Tech-nology Applications and Research and Professor of Information Systemsat the University of Technology, Sydney (UTS). He is the author or editorof 27 books and is well-known for his work in object-oriented and agent-oriented methodologies (MOSES, COMMA, OPEN, OOSPICE, FAME),object-oriented metrics and metamodelling. More recently, he has chairedworkshops on these topics at OOPSLA and AOIS (Agent-OrientedInformation Systems). He is Editor of the International Journal of Agent-

Oriented Software Engineering and on the editorial board of Journal of

Object Technology, Software and Systems Modeling and International

Journal of Cognitive Informatics and Natural Intelligence. In July 2001,Professor Henderson-Sellers was awarded a Doctor of Science (D.Sc.)from the University of London for his research contributions in object-oriented methodologies.

seminário 01 - modelling software development methodologies - a conceptual foundation

Documents