Notation Criteria

These criteria look at the notations adopted by methodologies, supporting tools and usability (Figure 4.11). These criteria are important because sometimes the notation adopted could establish the methodology’s success. In particular:

• Notation specifies the type of notation adopted by the methodology.

• Easy to understand specifies if the notation adopted is easy to understand for the new users.

• Usability specifies the degree of usability of the methodology.

• Supporting tool specifies if exist one ore more tools that support the methodology. Figure 4.11 summarises the results about the notation criteria of the methodologies presented in this chapter.

Gaia, Tropos, MESSAGE and INGENIAS adopt an ad hoc notation for expressing the outcomes of the development steps, while the other methodologies use a standard notation like UML and AUML (Agent-UML). The kind of notation influences the “easy to understand” criterion, in fact the methodologies that adopt a standard notation are easier to understand than the others—except for Gaia, that has an high level of understanding. This because for new users that typically come from the object-oriented field it is easier to understand the standard UML or its variant for agent than to learn a new notation. Obviously also the usability of the methodology is influenced by the notation adopted. In fact, the methodologies that adopt a standard notation are more usable than the other because the startup time – composed by the time to learn methodology plus the time

to learn its notation – is typically higher in those methodologies that adopts an ad hoc notation where the time for learning a new notation becomes relevant.

Finally, only Gaia and MaSE have not a supporting toolkit. This could be a limitation because a methodology without a supporting tool is less usable than a methodology supported by a tool.

4.3.3

Summing up

This section has presented a comparison of the AO methodologies presented in Section 4.2. As for software development, individual methodologies are often created with specific purposes in mind [85]: particular domains or particular segments of the lifecycle. However users often make the assumption that a methodology in not in fact constrained but, rather, is universally applicable. This can easily lead to methodology failure, and to the partial rejection of methodological thinking by software development organisation. As highlighted in Subsection 3.2.2, the creation of a single universally applicable methodology is an unattainable goal. The question is how could we create a methodological environment in which the various demands of different software developers might be satisfied altogether. So, the decision about the best methodology should depend on the target application. Each application entails a different set of requirements that indicate which evaluation criteria are the most important and should be supported by the chosen methodology.

As a final remark, the comparison presented here has the following limitations: • the comparison is solely based upon the available documentations of the method-

ologies and their documented case studies;

• some evaluation criteria are subjective in nature, particularly the usability and understandability of the methodologies;

• the criteria adopted do not cover all the possible methodologies’ key features, but only those considered relevant in the context of this chapter. In fact two other comparisons are provided in Chapters 8 and 12 respectively about how method- ologies supports the design of the environment and manege the complexity of the representation.

5

Meta-models & Languages

This chapter introduces the concept of meta-model and the different types of languages for describing meta-models. In particular Section 5.1 presents several definition of the meta-model, the level of abstraction inducted by meta-models, and illustrates the key role that meta-models play in the context of methodologies and their evaluations and integrations. Section 5.2 presents different types of meta-modelling languages. Like other modelling languages, meta-modelling languages focus on specific aspects of the domain to be modelled, and therefore lead to different types of representations. For example the meta-models that represent the abstractions adopted by methodologies are different from those meta-models that represent the software development processes. This means that different kinds of meta-modelling languages are necessary in order to capture the distinctiveness of each domain that requests a meta-model.

The meta-modelling technique could be very useful also for representing the abstrac- tions supported by infrastructures in order to both study the deep infrastructure semantics and evaluate the gap between methodologies and infrastructures. There is the need to study the different AO infrastructures, to compare their abstractions, rules, relationships, and the process they follow, and to have a comprehensive view of this variety of infras- tructures (Section 10.5). So, Section 5.3 presents how to meta-modelling infrastructures. The use of a meta-model formalism helps to compactly and precisely express each methodology and infrastructure and provides a basis for analysing and comparing them. It also helps to study the existing gap between AO methodologies in general and AO infrastructures, and provides a starting point for developing methodologies together with their counterpart AO infrastructures.

Finally a summary follows in Section 5.4.

5.1

Meta-Models

Software development processes and methodologies have always been described in terms suitable for use by the developer [88]. They talk about what tasks and techniques should

be used, what sort of lifecycle is appropriate (e.g. waterfall) and how these process

a manual or published as a book that the project manager and his/ her team of developers follow closely. Previous comparisons of OO processes for software development have been undertaken, for example, by Henderson-Sellers et al. [88] and by Hull et al. [93].

With the advent of CASE tools it became necessary to create a rule base within each tool that would support these processes. These rules would say whether it was appropriate to, for example, sequence two activities, three techniques and then four roles (an occurrence that should be prevented since it is nonsensical). These rules are currently commonly captured in a meta-model. In its most general acceptation, a meta-model is defined as

Wikipedia (1) Meta-modeling is the analysis, construction and development of the frames, rules, constraints, models and theories applicable and useful for the model- ing in a predefined class of problems.

(2) meta-modelling is the construction of a collection of concepts (things, terms, etc. . . ) within a certain domain. A model is an abstraction of phenomena in the real world, and a metamodel is yet another abstraction, highlighting properties of the model itself. This model is said to conform to its metamodel like a program con- forms to the grammar of the programming language in which it is written. Common uses for meta-models are:

• As a schema for semantic data that needs to be exchanged or stored, • As a language that supports a particular method or process,

• As a language to express additional semantics of existing information.

Metamodels.com A meta-model is a precise definition of the constructs and rules needed for creating semantic models.

Bernon et al. The process of designing a system (object or agent-oriented) consists of instantiating the system meta-model that the designers have in their mind in order to fulfill the specific problem requirements. In the agent world this means that the meta-model is the critical element because of the variety of methodology meta-models [10].

Gonzalez-Perez et.al A meta-model is a model of a methodology or, indeed, of a family of related methodologies [80].

Brian Henderson-Sellers A meta-model describes the rules and constraints of meta- types and meta-relationships. Concrete meta-types are instantiated for use in regu- lar modelling work. A meta-model is at a higher level of abstraction than a model. It is often called a model of a model. It provides the rules/ grammar for the mod- elling language itself. The modelling language consists of instances of concepts in the meta-model.

Project

Methodology

Meta-model

constrains

constrains

Figure 5.1: Level of abstractions in the Meta-models

It’s also important to understand that meta-models are always made for a particular purpose. Do not ever attempt to use a meta-model without understanding the particular goal that the authors had in mind when they created the meta-model.

Although it is possible to describe a methodology without an explicit meta-model, for- malising the underpinning ideas of the methodology in question is valuable when checking its consistency or when planning extensions or modifications. A good meta-model should address all of the different aspects of methodologies, i.e. the process to follow and the work products to be generated. In turn, specifying the work products that must be devel- oped implies defining the basic modelling building blocks from which they are built. The importance of meta-model becomes clear when it is necessary to study the completeness and the expressiveness of a methodology, and when comparing different methodologies. Meta-models are extremely important for integrating methodologies, too. Integrating methodologies without such a formalism might lead to two kinds of errors: assuming an existence of differences of concerns when none exists, and the wrong assumption of con- cerns similarity. The first type of errors might lead to repetition and consequently an unnecessarily large methodology that is hardly understood and acceptable by developers. The second type of errors will lead to inconsistency because of the false assumption of concerns interpretation similarity.

Meta-models are often used by methodologists to construct or modify methodologies. In turn, methodologies are used by software development teams to construct software

products in the context of software projects. Meta-model, methodology and project

constitute, in this approach, three different areas of expertise that, at the same time, correspond to three different levels of abstraction and three different sets of fundamen- tal concepts (Figure 5.1) [88]. As the work performed by the development team at the project level is constrained and directed by the methodology in use, the work performed

Figure 5.2: The OMG’s layers

by the methodologist at the methodology level is constrained and directed by the chosen meta-model (Figure 5.1).

Traditionally, these relationships between modelling layers are seen as instance-of re- lationships, in which elements in one layer are instances of some elements in the layer above. Most object-oriented process meta-modelling approaches define a metamodel as a model of a methodology that a software development team may employ. Following this conventional approach, classes in the meta-model are used by the methodologist to cre- ate instances in the methodology layer and thus generate a methodology. However, these objects in the methodology layer are often used as classes by the development team to create elements in the project layer during methodology enactment. An example is the Meta Object Facility an OMG standard (Figure 5.2) [142]. MOF is designed as a four- layered architecture. It provides a meta-meta model at the top layer, called the M3 layer. This M3-model is the language used by MOF to build meta-models, called M2-models. The most prominent example of a Layer 2 MOF model is the UML [143] meta-model, the model that describes the UML itself. These M2-models describe elements of the M1- layer, and thus M1-models. These would be, for example, models written in UML. The last layer is the M0-layer or data layer. It is used to describe the real-world. MOF is a closed meta-modeling architecture; it defines an M3-model, which conforms to itself. MOF allows a strict meta-modelling architecture; every model element on every layer is strictly in correspondence with a model element of the layer above. MOF only provides a means to define the structure of a language or of data.