2. Using Ontologies in Software Engineering and Technology

Transcription

1 2. Using Ontologies in Software Engineering and Technology Francisco Ruiz ALARCOS Research Group. Dept. of Information Technologies and Systems, Escuela Superior de Informática, University of Castilla-La Mancha, Spain, José R. Hilera Computer Science Department, University of Alcalá, Spain, 2.1 Introduction In this chapter, the state of the art on the use of ontologies in software engineering and technology (SET) is presented. The chapter is organized into four parts. In the second and third sections, serving as a supplement to Chap. 1, 29 a wide review of the distinct kinds of ontologies and their proposed uses is presented respectively. In the fourth section, we offer a taxonomy for classifying ontologies in SET, in which two main categories are distinguished: (1) SET domain ontologies, created to represent and communicate agreed knowledge within some subdomain of SET, and (2) ontologies as software artifacts, with proposals in which ontologies play the role of an additional type of artifact in software processes. On the one hand, the former category is subdivided into those ontologies included in software engineering and those referring to other software technologies. 29 Readers can find a more detailed study on the ontology notion in the books Ontological Engineering by Gómez-Pérez et al. [38] and Ontologies: A Silver Bullet for Knowledge Management and Electronic Commerce by Fensel [30].

2 50 Francisco Ruiz, José R. Hilera On the other hand, the latter category is subdivided into development time and run time proposals according to the moment when ontologies are used. Then, in the last section, we analyze and classify (based on our taxonomy) a large number of recently published works. We also comment on and classify works which will be presented in later chapters of this book. 2.2 Kinds of Ontologies Although the term ontology was introduced in the eighteenth century to refer to the general science of being ( onto in ancient Greek), Ontology as a discipline has been practiced by philosophers since the dawn of history (previously a part of metaphysics). Etymologists may define ontology as the knowledge of beings, that is, all that relates to being. Just as we call those who study students, we use the term entity to describe all things which are. From this point of view, stones, animals or people are entities. Mathematical objects, even those that are merely imagined, are also considered beings (be they fictitious or unreal). All sciences and knowledges refer to or examine a type of entity: some are physical, as in the physical sciences, others abstract or mental, as in mathematics and the vast majority of the computational sciences, and still others living, as in biology. In the scope of the computational sciences and technologies (computer science, software engineering, information systems, etc.), ontology has boomed as a field of research and application since the latter part of the twentieth century. Perhaps the principal cause of this boom has been the key role that it plays in the new generation of the advanced Web (Semantic Web). Focusing exclusively on the scope of this publication, that is, SET, the first known proposals were presented by Gruber [40, 41], whereby ontologies are an explicit specification of a conceptualization. Conceptualization is understood to be an abstract and simplified version of the world to be represented: a representation of knowledge based on objects, concepts and entities existing within the studied area, as well as the relationships existing among them. By explicit we mean that the concepts used and the restrictions applied to them are clearly defined. Later authors have considered it important to add to this definition two new requirements: that the said specification be (1) formalized and (2) shared. By formalized it is meant that a machine can process it. By shared it is understood that the knowledge acquired is the consensus of a community of experts [38]. In regards to this last requirement, common ontologies are used to describe ontological commit-

3 2. Using Ontologies in Software Engineering and Technology 51 ments for a set of agents (people or artificial systems) so that they can communicate and interact with a domain of discourse. Additionally, an agent commits to an ontology if its observable actions are consistent with the definitions of the ontology. This idea of ontological commitments was proposed by Newell [68] from a knowledge-level point of view. Some SET researchers view ontologies as a vocabulary for a specific domain representing conceptual elements and the relationships existing between them. However, the ontology is not the vocabulary itself, but what the vocabulary represents, since the translation of this vocabulary into another language will not change the ontology [16]. Other researchers defend the need for ontologies to be viewed as a theory, that is, a formal vocabulary with a set of defining axioms. These axioms express new relationships between concepts and limit the possible interpretations [75, 98]. However, many experts have concluded that ontologies of the software systems application domain, or of its design and construction processes, are of great assistance in avoiding problems and errors at all stages of the software product life cycle: from the initial requirements analysis (facilitating the analyst client interaction), through the development and construction phase, and finaly with the maintenance stage (assuring greater understanding of the modification requests, better understanding of the maintained system, etc.). Additionally, numerous authors have viewed ontologies from distinct vantage points. Therefore it is not surprising that in the literature we find diverse classifications of ontologies with different focuses. According to the generality level, Guarino considers that the following ontology types exist [43]: High level ontologies: Describe general concepts such as space, time, material, object. They are independent of a specific domain or problem. Their purpose is to unify criteria between large communities of users. Domain ontologies: Describe the vocabulary related to a generic domain (for example, information systems or medicine), by means of the specialization of the introduced concepts of high level ontologies. Task ontologies: Describe the vocabulary related to a generic task or activity (for example, development or sales), by means of specialization of the introduced concepts of high level ontologies. Application ontologies: Describe concepts belonging simultaneously to a domain and a task, by means of specialization of the concepts of domain ontologies and task ontologies. They generally correspond to roles played by the domain entities when executing an activity.

4 52 Francisco Ruiz, José R. Hilera On the other hand, Fensel [30] established the following alternative classification: Generic or common-sense ontologies: Capture general knowledge of the world. They provide basic notions and concepts for space, time, state, events, etc, and are valid for a variety of domains. Representational ontologies: Do not belong to any particular domain. They offer entities without establishing what they might represent. Therefore, they define concepts which express knowledge in an objector framework- oriented approach. Domain ontologies: Capture the knowledge valid for a particular type of domain (for example, electronics, medicine, etc.). Method and task ontologies: The former offer terminology specific to problem resolution methods, while the latter provide terms for specific tasks. Both offer a reasonable point of view as to the knowledge of the domain. In our opinion, the two previous authors classifications may be aligned according to the following model as shown in Fig Fig Kinds of ontologies according to the generality level In accordance with the type of conceptualization structure, Van Heijst and colleagues established the following kinds [94]: Terminological ontologies: Specify terms to be used to represent the knowledge of a studied domain. Then try to obtain a unified language

5 2. Using Ontologies in Software Engineering and Technology 53 related to a specified field. An example of this type would be the ULMS (Universal Medical Language System). Information ontologies: Specify the structure of database records, determining a framework for the standardized storage of information. An example is the framework for modeling medical patient clinic records. Knowledge representation ontologies: Specify knowledge conceptualizations with an internal structure that exceeds those of the previous ones. They tend to be focused on a description of a particular knowledge use. Another possible way of classifying ontologies is according to the nature of the real-world issue that is to be modeled. In this manner, Jurisica et al. have identified the following classes [55]: Static ontologies: Describe things that exist, their attributes and the relationships existing between them. This classification assumes that the world is made up of entities which are gifted with a unique and unchangeable identity. In these, we use terms such as entity, attribute, or relationship. Dynamic ontologies: Describe the aspects of the modeled world which can change with time. To model these it may be necessary to use finite state machines, Petri nets, etc. Process, state, or state transition are examples of terminology commonly included in this category. Intentional ontologies: Describe the aspects of the world of motivations, intentions, goals, beliefs, alternatives and elections of the involved agents. Some typical terms in these types of ontologies are aspect, object, agent, or support. Social ontologies: Describe social aspects such as organizational structures, nets or interdependences. For this reason they include terms such as actor, position, role, authority, responsibility or commitment. Some authors believe that this linear way of classifying ontologies based on only a sole criterion does not allow for adequate reflection of the problem s complexity. Along these lines, Gómez-Pérez et al. [38] suggest a bidimensional classification, taking into account two criteria: the richness of the internal structure, and the subject of the conceptualization. The former criterion is based on a proposal of Lassila and McGuinness [59]. The latter proposes an extension of the Van Heijst et al. [94] classification previously described.

6 54 Francisco Ruiz, José R. Hilera In this bi-dimensional proposal, every ontology belongs to one of the following categories, based on the level of richness of its internal structure: Controlled vocabularies: Formed by a finite list of terms. Glossaries: Lists of terms with their definitions offered in natural language. Thesauruses: Differentiated from the previous categories in that they offer semantic additions to the terms, including synonyms. Informal hierarchies: Hierarchies of terms which do not correspond to a strict subclass. For example, the terms rental vehicle and hotel could be modeled informally under the hierarchy travel as they are considered key parts of traveling. Formal hierarchies: In this case, a strict is-a relationship exists between instances of a class and of its corresponding superclass. For example, a teacher is-a people. Its objective is to exploit the inheritance concept. Frames: Ontologies which include such classes as properties, which can be inherited by other classes in lower levels of a formal is-a taxonomy. Ontologies with value constraints: Include value constraints. The most typical case is that of constraints dependent on the data type of a property (for example, a day of the month must be lower than 32). Ontologies with generic logical constraints: These are the most expressive ontologies which permit specific constraints between the terms of the ontology using first-order logic. Simultaneously, depending on the subject of the conceptualization, an ontology falls into one of the following types: Knowledge representation ontologies: Capture representation primitives used to formalize knowledge under a concrete paradigm of knowledge representation. Common or generic ontologies: Represent common-sense knowledge reusable in distinct domains, for example, vocabulary related to things, events, time, space, etc. High-level ontologies: Describe very general concepts and notions by which they can be related to root terms of all ontologies. An unresolved problem is that many of these high-level ontologies differ in their way of classifying general concepts. This makes it difficult to integrate and exchange ontologies.

7 2. Using Ontologies in Software Engineering and Technology 55 Domain ontologies: Reusable ontologies of a particular domain (for example, medicine, engineering, etc.). They offer a vocabulary for concepts related to the domain and its relationships. Task ontologies: Describe the vocabulary related to some generic activity. They provide a systematic vocabulary of terms used to solve problems that may or may not belong to the same domain. Domain task ontologies: Unlike the previous ontologies, these are reusable in a given domain, but not among different domains. Method ontologies: Provide definitions of relevant concepts and their relationships. They are applicable to a reasoning process specifically designed to carry out a particular task. Application ontologies: Are dependent on the applications. Often, they extend and specialize the vocabulary of one domain ontology or task ontology for a particular application. In the bibliography of ontologies, the adjectives formal, informal and semi-formal are also used. In this case, the formality of the language used to represent the ontologies is being indicated. This way, the ontologies expressed using natural language are considered to be totally informal, whereas those represented using first-order logic are formal [92]. In an intermediate situation, there is the ontology represented using UML class diagrams, as UML is considered semi-formal. In this case, the level of formality may be raised using OCL to model constraints. In relation to languages and techniques used to represent ontologies, SET experts may be interested in reading Modeling ontologies with software engineering techniques and Modeling ontologies with database techniques, both of which are sections included in the first chapter of the book by Gómez-Pérez et al. [38]. These numerous and varying ways of thinking about ontologies have been clarified by some researchers who have looked for an integral definition which would serve for the different fields of application (knowledge engineering, databases, software engineering, etc.), and so as to be understood by non-experts. In this manner, Uschold and Jasper elaborated the following characterization (not definition) [92]: An ontology may take a variety of forms, but necessarily it will include a vocabulary of terms, and some specification of their meaning. This includes definitions and an indication of how concepts are interrelated which collectively impose a structure on the domain and constrain the possible interpretations of terms.

8 56 Francisco Ruiz, José R. Hilera With the same goal, Gómez-Pérez et al. [38] conclude that ontologies aim to capture consensual knowledge in a generic way, and that they may be reused and shared across software applications and by groups of people Heavyweight Versus Lightweight Ontologies In the ontological engineering community it is common to hear of lightand heavyweight ontologies. This distinction is a simplification of the classification based on the level of richness of their internal structure (as previously commented), whereby lightweight ontologies will be principally taxonomies, while heavyweight ontologies are those which model a certain knowledge in a deeper way and provide more restrictions on domain semantics [38]. The former include concepts, concept taxonomies, relationships between concepts, and properties that describe these concepts. The latter add axioms and constraints, in order to clarify the meaning of the terms. In Fig. 2.2 we have represented linearly the continuum from lightweight to heavyweight ontologies. In the upper part of the line, we find the lightweight ontologies which include controlled vocabularies, glossaries, and thesauruses; while at the bottom we find the heavyweight ontologies with value constraints and general logic constraints. In between are the informal hierarchies, formal hierarchies and frames. These intermediates have some of the characteristics of the heavyweight ontologies but not all authors consider them to fall within this general category. Fig A continuum from lightweight to heavyweight ontologies

9 2. Using Ontologies in Software Engineering and Technology 57 This continuum from lightweight to heavyweight can be viewed as the two arms of a balance. The first has the advantage of being simple and the second, of being powerful. It is not possible to possess both advantages at the same time, and there is no way of determining which is better than the other, lightweight or heavyweight. It all depends on one s goals and necessities based on the particular case at hand. For example, the lightweight ontologies are more useful when the objective is, simply, to share knowledge of one domain between people. On the other hand, if it is necessary to execute some sort of logical inference or automatic calculation, it will be necessary to utilize the heavyweight ontologies. In any case, the following advice might serve the SET stakeholders: use the lightest ontologies possible which can serve the necessities of the project at hand. 2.3 A Review of the Uses in SET Of the utilities of ontologies in any field of human activity, we recognize the following to be principal: Clarify the knowledge structure: During the ontological analysis the domain concepts and relationships between them are defined in such a way that the adequate execution of this step eases the clear specification of the nature of the concepts and terms being used, with respect to the body of knowledge that is to be constructed [15]. Reduce conceptual and terminological ambiguity: Ontological analysis provides a framework for the unification between people (and/or agents-systems) with differing necessities and/or points of view, depending on their particular context [91]. Allow the sharing of knowledge: By means of an appropriate ontological analysis, it is possible to achieve a set of conceptualizations of a specific domain, and the set of terms which support it. With an adequate syntax, these conceptualizations and the relationships between them are expressed and codified in an ontology, which can be shared with any agent (person or system) having similar needs for the same domain [59]. Focusing exclusively on the scope of this book, many authors have studied and categorized the possible uses of ontologies in the software engineering and information systems disciplines. In these fields, it is possible to use ontologies of varying levels of generality. For example, the domain-level ontologies are especially useful for the development of reusable, high-quality software, as they provide a unambiguous terminology which can be shared

10 58 Francisco Ruiz, José R. Hilera by all the development processes. Furthermore, thanks to ontologies, the eliciting and modeling of the requirements phase can be carried out in two steps [35]: in the first, general knowledge of the domain is elicited and specified in one or more ontologies. In the second step the obtained ontologies are used as inputs to develop the specified applications. The constructed ontology also serves as the basic vocabulary to speak about the domain and is a base for the development of the specific conceptualizations for the applications that are to be constructed. Next we will summarize the results of some of the best known surveys. For Pisanelli et al. the most important characteristics that ontologies offer the field of software engineering are [75]: 1) an explicit semantic and taxonomy; 2) a clear link between concepts, their relationships, and generic theories; 3) lack of polysemy within a formal context; 4) context modularization; 5) minimal axiomatization to pinpoint differences between similar concepts; 6) a good politic of name choice; and 7) a rich documentation. Uschold, Gruninger and Jasper identified the following functions [91, 92]: Communication: Ontologies allow for the reduction of conceptual and terminological ambiguity, as they provide us with a framework for unification. They allow us to share knowledge and facilitate the communication between people and/or systems as even those having differing necessities and viewpoints, a function of their contexts and particular interests. Furthermore, in any organization, there is implicit knowledge (for example, the normative models and the network of relationships between people) that can be made explicit through ontological means. Ontologies also permit an increased consistency, eliminating ambiguity and integrating distinct user viewpoints. For person-to-person communication, an informal, unambiguous ontology may be sufficient. Interoperability: When different users or systems need to exchange data or when different software tools are used, the concept of interoperability has some important repercussions. In this sense, the ontologies can act as an interlingua, that is, they can be used to support the translation between different languages and representations, as it is more efficient to have a translator for each part involved (with an exchange ontology) than to design a transla-

11 2. Using Ontologies in Software Engineering and Technology 59 tor for each pair of involved parts (languages or representations). A paradigm case would be the use of ontologies in the Semantic Web to look for irrelevant language factors, that is, to obtain the same results when using the term author or autor (in Spanish). System/software engineering: The application of ontologies to support the design and development of systems, specifically software, may have the following objectives: Specification: The role that ontologies play in specification depends on the level of formality and automization within the methodology of the system design. From an informal perspective, ontologies assist in the requirements identification process and in the understanding of the relationships between components. This is particularly important when there are different sets of designers working in different domains. From a formal perspective, an ontology offers a declarative specification of a system, allowing designers to argue over why the system is being designed instead of how to support its functionality. Confidence: The informal ontologies can improve the confidence of the system by serving as a basis for the manual checking of the design, while the formal ontologies allow for the semi-automized consistency check of a software system with respect to the declarative specification that the ontology presumes. Reusability: To increase its usefulness, an ontology should be able to support the import and export of modules (parts of the ontology). By characterizing the domain classes and tasks within these subdomains, the ontologies can provide a framework to determine the aspects of the ontology that can be reused between different domains and tasks. The objective is, therefore, to achieve libraries of ontologies that are reusable and adaptable to different classes of problems and environments. Search: An ontology can be used as metadata, serving as an index for a repository of information. Reliability: The consistency checking may be (semi-)automatic if a formal representation of knowledge exists. Maintenance: One of the main efforts made during the software system s maintenance phase is the studying of the system. For this reason, using ontologies allows an improvement of the documentation and a reduction in maintenance costs. Maintenance effort is also reduced if an ontology is used as a neutral authoring language because

12 60 Francisco Ruiz, José R. Hilera it only has to be maintained in one site instead of in multiple places, one for each target language. Knowledge acquisition: In the process of building knowledge-based systems, speed and reliability may be increased when an existing ontology is used as the starting point and guide for the knowledge acquisition. Several years after its publication, a study was re-performed by Gruninger and Lee. Greatly abbreviating, the results were the following [42]: Communication: Between computer systems, for example, in the exchange of data between distinct software tools. Between humans, for example, for the acquisition of a vocabulary that unifies concepts of a specific domain. Between humans and computer systems, for example, an ontology may be deployed in a window so that the user can use it to better and more easily understand the vocabulary used in the application. Computational inference: For the internal representation and management of plans and planning information. For analysis of internal structures, algorithms, system inputs and outputs, in conceptual and theoretic terms. Knowledge reuse and organization: For the structuring and organization of libraries or repositories of plans, and planning and domain information. In addition to these previous possible uses of ontologies, Uschold and Jasper [92] have described scenarios for applying ontologies. These scenarios are abstractions of specific applications of ontologies following the same idea of Jacobson s use cases. Each scenario includes an overview with the intended purpose of the ontology, the role of the ontology, the main actors and the supporting technologies. These authors have established four categories which include all of the identified scenarios: Neutral authoring: An information artifact is authored in a single language and is converted into a different form for use in multiple target systems. Knowledge reuse, improved maintainability and long-term knowledge retention are the main benefits of this scenario. Specification: An ontology is created and/or used as a basis for specification and possibly also for the development of some software.

13 2. Using Ontologies in Software Engineering and Technology 61 Benefits of this scenario include documentation, maintenance, reliability and knowledge reuse. Common access to information: When information is required by one or more persons or systems, but is expressed using unfamiliar vocabulary or in an inaccessible format, an ontology can help to render the information intelligible by providing a shared understanding of the terms, or by mapping between sets of terms. Interoperability and more effective use and reuse of knowledge resources are the main benefits of this scenario. Search: An ontology is used for searching an information repository for desired resources (for example, documents, Web pages, names of experts). The chief benefit of this scenario is faster access to needed information resources. The technology of the Semantic Web has this same goal, using the entire Web as a repository. Because of this, ontologies play a key role in this new technology. Other authors have studied the impact of ontologies on information systems (ISs). For example, Guarino identified two dimensions that should be considered [43]: a temporal dimension, concerning whether an ontology is used at development or at run time (that is for an information system or within an information system), and a structural dimension, concerning the particular way an ontology can affect the main IS components. With respect to the moment in which they are utilized, the use of the ontologies can take place during the development stage or during run time. On the one hand, when the ontology is used by the IS at run time, it is referred to as an ontology-driven information system proper. On the other hand, when it is used during development time, it is referred to as an ontology-driven development of the information system. By using ontologies at development time, two situations might occur: (1) that we have a set of reusable ontologies organized in libraries of domain or task ontologies; or (2) that we have a generic ontology (with less detailed distinctions at a domain level between the basic entities, and meta-level distinctions as for class and relationships types), with a more limited reusability grade. In the first case, the semantic content of the ontologies can be converted into a system component, reducing the cost of analysis and assuring the ontological system correctness (given that the ontology is correct). In the second scenario, which is more realistic, the quantity of ontological knowl-

14 62 Francisco Ruiz, José R. Hilera edge available is more limited, but its quality may assist the designer in the conceptual analysis task. When using an ontology at run time, one must distinguish between an ontology-aware information system and an ontology-driven information system. In the first case, a system component has knowledge of the existence of a potential ontology and may make use of it with a specific proposal, while in the second case, the ontology is an additional component (generally, local to the system) which cooperates at run time in order to achieve the system s goals and functionality. One reason why ontologies are used at run time is to ease the communication between software agents, which communicate by means of messages containing expressions elaborated in accordance with the ontology. With respect to the structural dimension, the three principal component types analyzed by Guarino for their impact are [43]: Components of database: To use an ontology at development time for the database component seems to be the most obvious use, because, in practice, an ontology has a great likeness to a database schema. In fact, some authors have created proposals whereby the ontologies play a key role during the phases of analysis and conceptual modeling [94]. The resulting conceptual model can be represented in a format understood by a computer and from there be projected to a concrete platform. During run time, there are various ways in which ontologies and databases can work together. For example, the explicit ontologies availability as an information resource is basic in the mediation-based focus of information integration. Components of user interface: In this type, the ontologies have been used successfully in order to generate interfaces based on forms that perform data control by means of type violation constraints. Another example of use, in this case during run time, consists of deploying an ontology in a help window so that the user may use it as part of the system, for example, to understand the given vocabulary. Components of application program: The application programs tend to have much implicit knowledge about the domain, for example, in the type or class declarations, in regards to business rules or policies, etc. At development time, it is possible to generate the static part of a program with the help of an ontology. Further, ontologies which are integrated with linguistic resources may be used to assist in the development of object-oriented software, as expressed with the databases. At run time, it is possible to represent in explicit form (with an ontology) the knowledge that the program holds implicitly,

15 2. Using Ontologies in Software Engineering and Technology 63 converting the program into a knowledge-based system. This could improve the maintenance, the extensibility and the flexibility of the system. In the following sections of this chapter, we present a state of the art review in which the reader can find the most developed examples of these and other ways to use ontologies in SET Ontology Versus Conceptual Model In the SE and IS communities, perhaps due to the historical importance of conceptual modeling, there is frequent confusion between ontology and conceptual models. In some sense, an ontology has a similar function to a database schema because the first provides meta-information that describes the semantics of the terms or data, but there are several important differences between these concepts [44, 63]: Languages for defining and representing ontologies (OWL, etc.) are syntactically and semantically richer than common approaches for databases (SQL, etc.). The knowledge that is described by an ontology consists of semistructured information (that is, texts in natural language) as opposed to the very structured data of the database (tables, classes of objects, etc.). An ontology must be a shared and consensual conceptualization because it is used for information sharing and exchange. Identifiers in a database schema are used specifically for a concrete system and do not have the need to make an effort to reach the equivalent of ontological agreements. An ontology provides a domain theory and not the structure of a data container. With didactic intention, Mylopoulos [67] explains with samples that an ontology is not a conceptual schema. This researcher uses the following sample situation. On one hand, there may be a university ontology defining and associating concepts such as student, course, lectures, etc. On the other hand, a conceptual schema, say, for the scholarship IS at the University of the World, may use these concepts but they are specialized in meaning. For example, the student concept may be meant to have as instances only University of the World students. An ontology is meant to be reusable, whereas a conceptual schema is less so.

16 64 Francisco Ruiz, José R. Hilera Spyns et al. [86] establish that the main difference between the data models and ontologies is that while the former are task specific and implementation oriented, the latter should be as much generic and task independent as possible. In this manner, to the benefits of reusability and reliability mentioned by Ushold and King [93] when ontologies are used in software and system engineering, we can also add shareability, portability and interoperability. These characteristics are identified as the common notion of genericity Ontology Versus Metamodel There also exists some confusion between ontologies and metamodels, which in our opinion is motivated principally because of the fact that both are frequently represented by the same languages, although their characteristics and goals are different. Bertrand and Bezivin [7] have analyzed the relationship between low-level ontologies and metamodels, and have arrived at the conclusion that while metamodels look to improve the rigor of similar but different models, an ontology does the same but for knowledge models. Devedzic [24] noted another difference: without an ontology, different knowledge representations of the same domain can be incompatible even when using the same metamodel for their implementation. The existing confusion is also generated due to the lack of agreement as to the definition of both terms. In the case of ontologies, we have already commented sufficiently on this fact. Similarly, for metamodels there exists no other universal consensus than the mere etymological description that a metamodel is a model of models. In our opinion, if one uses the definition of ontology proposed by Gruber [40] and the Object Management Group definition of metamodel, proposed in the Model-driven Architecture [71], the clearest distinction between them is that of intention: while an ontology is descriptive and belongs to the domain of the problem, a metamodel is prescriptive and belongs to the domain of the solution. In Chap. 9 of this book, the reader is provided with a detailed proposal of the different roles played by ontologies and metamodels in the framework of a model-driven engineering paradigm. Also, a new idea, that of the megamodel, is introduced.

17 2. Using Ontologies in Software Engineering and Technology Ontologies in Software Engineering Environments Other application fields for ontologies are the SEE (SEEs), which integrate diverse types of tools in order to assist the engineers in completing the software engineering processes. To begin with, in the SEE, knowledge is embedded in one or various tools or assistants but this makes it virtually impossible to be shared or reused. The exchange of knowledge between humans is one of the major problems in software engineering projects. It has been shown that this is due in great part to the fact that the project participants have distinct domains of problem knowledge and/or use different languages, both problems which could be mitigated by using ontologies. This is why some authors have proposed the use of ontologies as the backbone of the tools and SEE [22]. For the same reason, there exist proposals of SEE architectures based on ontologies [28]. Two of these proposals will be commented on in the following subsections MANTIS Environment An MANTIS is extended Software Engineering Environment for the management of software maintenance projects. By using the nomenclature extended SEE the intention is to emphasize the idea of integrating and widen the concepts of methodology and SEE [79]. All the MANTIS components are considered as tools of three different categories: conceptual, methodological and technical (CASE tools). A summary of the components that make up the MANTIS environment is shown in Fig Conceptual tools are used in MANTIS to represent and to manage the inherent complexity of software maintenance projects. A level-based conceptual architecture is necessary to be able to work with different abstract levels. A software life cycle process framework is useful for knowing which are the other software processes related to the maintenance process. To make sure that all the concepts are correctly defined, used and represented, a set of ontologies was defined. The Maintenance Ontology represents the static aspects. They describe the concepts related to maintenance and consist of a subontology for products, another for activities, a third for processes and the fourth for describing the different agents involved in the maintenance process [79]. The intentional and social aspects are considered within the same subontology, Agents, since they are closely related. The dynamic part is represented by an ontology called Workflow Ontology, where three relevant aspects of the maintenance process are defined: decomposition of activities, temporal constraints between activities, and control of the execution of ac-

18 66 Francisco Ruiz, José R. Hilera tivities and projects during the process enactment. A third ontology called a Measure Ontology represents both static and dynamic aspects related to the software measurement. This ontology was included because of the importance of measurement within the software process. Fig Ontologies as conceptual tools in the MANTIS environment The uses of the ontologies proposed in the MANTIS environment are two of the three identified by Gruninger and Lee [42]: communication (especially between humans participating in maintenance projects, and between humans and the software system of the MANTIS environment), and knowledge reuse and organization. On the other hand, the computational inference has not

19 2. Using Ontologies in Software Engineering and Technology 67 been included in this SEE. The importance of ontologies use as a support for maintenance activities (particularly for the sharing and reuse of knowledge about the product and its characteristics) has been recognized by other authors as well [21]. In MANTIS the ontologies have been represented using an adaptation of the REFSENO method (see later section) TABA Workstation TABA Workstation is a meta-see, capable of generating, by means of instancing, specific SEEs adequate for the particularities of a software process, of an application domain or of a specific project [28]. Given that the meta-environment, the created SEE instance and the tools in the TABA Workstation need to handle knowledge of the software development process, this system includes an ontology whose end is to support the acquisition, organization, reuse, and sharing of Software Process knowledge. This software development process ontology consists of various subontologies: of activities, of procedures and of resources. For the graphic representation of these ontologies, GLEO (Graphical Language for Expressing Ontologies) is used along with a set of axioms defined in first-order logic. Also, for each ontology, the vocabulary used is defined in a table created by two columns, one with the concept name, the other with descriptions of its function and relationship with other concepts Representing Ontologies Using Software Engineering Techniques There are many languages, techniques and tools for the representation, design and construction of ontologies (see Chap. 1). But the great majority of these have been created for and by the knowledge engineering community. Because of this, the use of ontologies by SET professionals and researchers can be seen as an additional learning experience, and in some cases, of considerably great effort. To avoid this problem, UML has been proposed and analyzed as a language of ontological representation in software engineering [97]. Further, the ontological fundamentals of this option have been studied by Guizzardi et al. [45]. Other potential advantages of this choice is that the extension possibilities of UML can be used: descriptive or restrictive stereotypes, and regular or restrictive extensions of the UML metamodel [82].

20 68 Francisco Ruiz, José R. Hilera For more detail regarding the use of UML as a representation language of ontologies, the reader may refer to Modelling ontologies with software engineering techniques in Chapt. 1 of the book Ontological Engineering [38] REFSENO Some SET researchers have made an effort to approximate previous proposals in the area of artificial intelligence, to the software engineering community. A significant case of this type is that of REFSENO (Representation Formalism for Software Engineering Ontologies) [90], a proposal created by the Fraunhofer Institute for Experimental Software Engineering (IESE) in Germany, which includes a methodology in order to develop the ontologies, together with a guide for their representation, through tables and diagrams. REFSENO provides constructs (primitives) to describe concepts where each concept represents a class of experience items. Besides concepts, its properties (named terminal attributes) and relationships (non-terminal attributes) are represented. One relevant feature of REFSENO is that it enables us to describe similarity functions, which are used for similaritybased retrieval. In this way, the implementation of retrieval components is facilitated. This similarity extends the formalism of Ostertag et al. [73] by additional integrity rules and by clearly separating the schema definition and characterization. On the other hand, REFSENO also incorporates integrity rules such as cardinalities and value ranges for attributes, assertions and preconditions. In the hope of better adapting the characteristics and interests of software engineers, and in contrast with the usual codified knowledge in knowledge-based systems, REFSENO represents the knowledge in the form of documents having a set of templates of tables and diagrams. This election is based on the studies of Althoff et al. [1] in which an important reduction in learning effort is achieved by the storage of experiences in the form of documents. The methodology proposed by REFSENO is an improved adaptation of METHONTOLOGY [29, 37], which imitates the software life cycle proposed by the IEEE 1074 standard. Consequentially, the main steps are: 1. Planning. 2. Specification of the ontology requirements. 3. Conceptualization. This stage is similar to the phase of design in a software system, so it is not the ontology itself.

21 2. Using Ontologies in Software Engineering and Technology Implementation. This refers to the representation and storage of the previous conceptualization through use of computer tools. REFSENO has been used for the creation and representation of diverse ontologies. For example, in [80] an ontology for software maintenance projects management, developed by a group of software engineers and researchers, is represented using REFSENO, changing specific diagrams for UML class diagrams and with other minor adjustments. According to the authors, they chose REFSENO for the following reasons: It allows for the modeling of software engineering knowledge in a precise and complete manner, by using alternate representations. The ontologies specified using REFSENO are precise, since the semantic relationships are defined and are complete, in the sense that all conceptual knowledge necessary to instantiate an experience base are provided. It has a clear terminology, differentiating between conceptual and context-specific knowledge, thus enabling the management of knowledge from different contexts. It guarantees a consistent ontology since consistency criteria must be fulfilled Experiences and Lessons Learned in Software Engineering Research In this section we present some lessons learned about the usefulness of the ontologies in software engineering research. In these, we have reflected on the experience of the Alarcos Research Group (University of Castilla-La Mancha, Spain), which has been achieved through the development of various research and development (R&D) projects. In our opinion, these conclusions and commentaries can be extended to ISs and database research, and in part to the professional work of the software engineer. At the origin of the use of these conceptual tools were two challenges encountered in the research projects: the integration of knowledge and the automation-oriented approach by means of software tools. The first challenge arose from the common daily difficulties in human relationships (between memberships of our group, other groups and other stakeholders), causing a waste of time and energy, due to lack of explicit or tacit shared knowledge. The second challenge arose because the great majority of projects confronted involved the design of advanced support

22 70 Francisco Ruiz, José R. Hilera tools for software engineering activities, which should offer the greater functionality that is possible at lower development cost. In facing these challenges, the following two questions arose: 1. How can we achieve proposals, methods, or tools which offer more general solutions, that is, more useful for all, in research problems? 2. How can we more easily share knowledge of the different participants (researchers, groups, clients, users, managers, etc.)? The conceptual architectures including meta-metamodels and ontologies have been the two conceptual tools best answering these questions. The second question had the best solution when using ontologies. Of the many applications of ontologies that are identified in the bibliography [42], and that have already been commented on, for our software engineering R&D project they have been especially useful in: 1. Sharing problem domain knowledge and allowing the use of common terminology between all stakeholders (and not just the researchers). 2. The filtering of knowledge upon defining the models and metamodels. This first use is evident, but its importance was considerable in the problems faced. This importance arose due to the need for communication as a main activity (in duration and importance) in R&D projects (as well as in any other type of work in software engineering or computer science) and because the ambiguity of the natural language implies errors, misunderstandings and unproductive efforts. It has been shown that this is due in great part to the project participants having differing knowledge of the domain of the problem, as well as the use of different languages, both problems which an ontology can mitigate. The second more important use that we have found with ontologies is the filtering of knowledge (Fig. 2.4). The models and metamodels (models of models) are representations or images of reality that, by definition, only include a part of this reality. However, this is not a problem, but an assistance, as this precise factor allows for the filtering capability of undesired characteristics. In this sense, an ontology is also of assistance in deciding what should be taken out of the real systems in order to construct the model(s) of a system (correspondents at the M1 level in a conceptual architecture such as that defined in MDA-MOF [71]), or what should be taken into account in order to define metamodels (level M2 of MDA-MOF).

23 2. Using Ontologies in Software Engineering and Technology 71 Although a formal and implemented ontology in a computer-adapted format may serve for knowledge inference, the characteristics of our R&D projects (with software engineering and not knowledge engineering goals) have led us to limit the use of ontologies to those of knowledge sharing and filtration. Therefore, the decision to use lightweight and non-formal (or semi-formal) ontologies has been due to the scope of projects which have been undertaken until today. ontology O real-world system S is based on is a representationof model M Fig Ontologies as filters of knowledge when defining models and metamodels Examples In the Alarcos Research Group we have carried out several R&D projects for software maintenance. For example, several years ago, we developed, in collaboration with the international company Atos ODS (previously Sligos), the MANTEMA methodology [76], specifically for the maintenance of software. In these projects, it was very useful to define an ontology for managing project maintenance [80] that solved previous misunderstanding and discussions due to, for example, not all participants (researchers, clients, maintainers) having equal understanding of the modification request concept. On the other hand, in 2003, various groups from Spain and diverse countries of America held a meeting in order to define a metamodel which would permit the representation and implementation or any type of software measure. After several days of debating, it was evident to all that there did not even exist any agreement on the concepts and terms that the different researchers or groups used. Without this prior step, it was very difficult to con-