Using objects and patterns to implement domain ontologies

SPECIAL ISSUE ON SOFTWARE ENGINEERING

Using objects and patterns to implement domain ontologies

Giancarlo Guizzardi^{I, II}; Ricardo de Almeida Falbo^II; José Gonçalves Pereira Filho^II

^ICentre for Telematics and Information Technology, University of Twente, Enschede, The Netherlands, [e-mail]

^IIDepartamento de Informática, Universidade Federal do Espírito Santo, Vitória - ES - Brazil, {falbo, zegonc}@inf.ufes.br

ABSTRACT

Ontologies are becoming an important mechanism to build information systems. Nevertheless, there is still no systematic approach to support the design of such systems using tools that are common to information systems developers. In this paper, we propose an approach for deriving object frameworks from domain ontologies and then we show the application of this approach in the software process domain.

Keywords: Ontologies, Objects, Framework, Design Patterns

1 Introduction

An Information System cannot be written without a commitment to a model of a relevant world, i.e., commitments to entities, properties, and relations in that world. Data structures and procedures implicitly or explicitly make commitments to a domain ontology [1].

Several projects in Artificial Intelligence have focused on using ontologies to promote knowledge sharing, and to substitute the usual database or object-oriented schema with an ontology, which offers a semantically richer model of the domain [2]. This trend has also acquired followers in the Software Engineering community. However, one of the major drawbacks to a wider use of ontologies in this area is the lack of approaches to insert ontologies in a more conventional software development process.

Since the current leading paradigm in Software Engineering is the object technology, we claim that we need a systematic approach to derive object models from ontologies in order to put ontologies in practice. In this paper we propose an approach to derive reusable object artifacts from domain ontologies. This approach comprises a spectrum of techniques, namely, a set of mapping directives, transformation rules and design patterns. In section 2, we briefly discuss some aspects of ontology development, including a method and a graphical language, and a past experience of developing ontologies in the software process domain. In section 3 we present a formalism to represent ontologies and a framework that implements the theoretical foundation of this language. In section 4, we present our approach to derive object models and frameworks from domain ontologies, showing its application to the software process domain. In section 5, related works is discussed. Finally, in section 6, we report our conclusions.

2 Ontologies

It is impossible to represent the real world, or even a part of it, with all its details. To represent a phenomenon or part of the world, which we call a domain, it is necessary to focus on a limited number of concepts that are sufficient and relevant to create an abstraction of the phenomenon at hand. Thus, a central aspect of any modeling activity consists of developing a conceptualization: a set of informal rules that constrain the structure of a piece of reality, which an agent uses to isolate and organize relevant objects and relations [3].

According to Guarino [4], "an ontology is a logical theory accounting for the intended meaning of a formal vocabulary, i.e., its ontological commitment to a particular conceptualization of the world". Based on such definition, an ontology consists of concepts and relations, and their definitions, properties and constrains expressed as axioms. An ontology should not be only an hierarchy of terms, but a fully axiomatized theory about the domain [5].

One of the main benefits of the use of ontologies in software development is the opportunity to adopt a reuse-based approach to the requirements engineering (RE). In traditional Software Engineering, for each new application to be built, a new conceptualization is developed. This reflects on how the RE is currently employed: for each new application, an elicitation phase is accomplished almost always from scratch, focusing on all particularities of the system at hand. This approach is extremely expensive since elicitation is the activity that requires most effort in the software development. Experts are scarce and costly resources but they are essential to this activity, so they should be better used. Therefore, it is important to share and reuse the captured knowledge.

In an ontology-based approach, requirement elicitation and modeling can be accomplished in two stages. First, the general domain knowledge should be elicited and specified as ontologies. These ontologies are used to guide the second stage of the RE, when the particularities of a specific application are considered. This way, the same ontology can be used to guide the development of several applications, diluting the costs of the first stage and allowing knowledge sharing and reuse.

In [5], we have proposed the representation language LINGO (Graphical Language for Expression Ontologies) and a systematic approach for ontology engineering. In the RE, the use of a graphical representation is essential in order to facilitate the communication between requirement engineers and experts. In ontology building, such representation is basically a language representing a meta-ontology. Hence, this language has basic primitives to represent a domain conceptualization. In its simplest form, its notations represent only concepts and relations. Nevertheless, some types of relations have a strong semantics and, indeed, hide a generic ontology. In such cases, specialized notations have been proposed. This is the striking feature of LINGO and what makes it different from other graphical representations: any notation beyond the basic notations for concepts and relations aims to incorporate a theory. This way, axioms can be automatically generated. Figure 1 shows the main notations of LINGO and a partial specification of the axioms imposed by parthood relations. These axioms form the core of the mereological theory as presented in [6]. The irreflexivity (AM1), asymmetry (AM2) and transitivity (AM3) axioms denote necessary properties for all kinds of whole-part relations. Axiom (AM6) denotes a special kind of part-of relation with non-sharable parts (composition). The remaining axioms complement the theory by defining suitable ontological distinctions. Both language and method have been used in the development of complex information systems in areas such as Software Process [7], Port Management, and Media on Demand Management [8]. Although they have proven to be useful, we identify a great concern from the developers: how to put those ontologies in practice, that is, how ontologies can support actual software development? To show our approach to deal with this problem, we discuss in the next subsection the case of a software process ontology.

2.1 Software Process Ontology

In [7], we have developed a software process ontology which has been further employed to promote knowledge integration in a Software Engineering Environment (SEE). Part of this ontology is presented in figure 2.

In this model, cardinality constraints are used to specify the number of concept instances that can be involved in a relation. The cardinality (0,n) does not impose any restriction and, for that reason, it is not graphically represented. Other cardinality possibilities include (0,1), (1,1) and (l,n). Whenever used, these cardinalities incorporate new axioms to the model.

In figure 2, cardinality (l,n) in the relation output implies that ("a)(activity (a) ® ($s)(output(s,a)). Cardinality (1,1) stills adds that ("s,a₁,a₂) (output(s,a₁) Ù output(s,a₂) ® a₁ = a₂).

Although the examples presented above represent only binary relations, the formalism used is expressive enough to model relations of any arity. Likewise, reflexive relations (relations between instances of the same concept) and conditional relations (AND and XOR tight relations) can also be represented.

Besides the axioms that are automatically incorporated by the use of the graphical notation, it is common that an ontology representation requires additional axiomatization. Axioms in a ontology can present two different forms and purposes: consolidation axioms (CA) and derivation axioms [5]. The former aims to impose constraints that must be satisfied for a relation to be consistently established. The latter intends to represent declarative knowledge that is able to derive knowledge from the factual knowledge represented in the ontology. Derivation axioms can have root in the meaning of the concepts and relations or in the way these concepts and relations are structured. When axioms are defined to show constraints imposed by the way concepts are structured, they are called epistemological axioms (EA). When they describe domain signification constraints, they are called ontological axioms (OA) [5]. Cardinality constraints, as discussed above, are examples of epistemological axioms.

Several axioms were defined in this ontology. Table 1 shows some of them, indicating their type. It is important to notice that the axioms (EA4) and (EA5) are directly derived by the usage of the whole-part relation between activities.

Since the SEE was implemented using objects, we had to derive an object model from the domain ontology. This represented a design problem that was informally solved. More recently, other developers have experienced the same problem. The methodology presented in this paper has been proposed to address this issue, i.e., the systematic object-oriented implementation of domain ontologies.

3 A Hybrid Formalism to Support Ontologies-to-Objects Mapping

As shown in Table 1, we have used first-order logic as the language to specify the axioms of the formal theory. First-order logic is widely known for being highly expressive and for its ontological neutrality, therefore adding minimal ontological commitments. However, due to the goals of this work, it is convenient to adopt a formalism that lies at an intermediate abstraction level, between first-order logic and object-orientation. For this purpose, we used a hybrid approach based on pure first-order logic and, predominantly, set theory.

The choice to create a language mainly based on set theory was highly motivated by an important issue: set theory is a complementary extensional perspective to the intentional nature of first-order logic and, at the same time, a natural option as a conceptual model for reasoning about objects. To clarify this point, the following example is used: let the intention of the concept mortal be "A mortal is an entity whose life ceases in a point of time". The logic predicate mortal(x) states that x is a mortal and, therefore, the characteristics defined by the intention of this concept applies to x. It also (implicitly) states that x Î Mortal, i.e., to the set of all the elements of the considered world to which the intention of the concept applies. In an object-oriented perspective, if x is an instance of mortal, it means that x belongs to the mortal class, i.e. to the set of all instances that share the same properties and the same definition.

Because of the aforementioned characteristics of set theory, a model built using the proposed set-based language is a convenient step in a systematic translation between the logic and the object paradigms. Moreover, the language preserves the expressive power of the first-order logic without adding significant ontological commitments, therefore, being suitable to play the same role in the axiomatization process. Although formal, the language is kept as simple as possible, defining only what is absolutely necessary to accomplish its goals.

Finally, it is essential to explain our decision for defining a new set-based formalism instead of using an existent one, for instance Z [9]. The reasons motivating this choice are both philosophical and practical. From a practical point of view, Z has a complicated mathematical notation that contains some language constructs that are unnecessary for ontology specification, e.g. the primitives for method specification. As a consequence of this, practitioners normally find these notations hard to use, mainly if their rather complex textual syntax is the only vehicle to produce specifications. From a philosophical point of view, the language primitives do not offer all the necessary means to express important ontological distinctions. An example of the latter is the fact that the language considers relations between concepts and properties as equivalent constructs. This consideration holds true from a mathematical perspective but not from an ontological one. In other words, we claim that Z's set of primitives is neither sufficient nor necessary for ontological formal representation. For a deep discussion about the ontological distinctions between concept relations, roles and properties please refer to [10].

In the next sub-session, the theoretical foundation for our formalism is briefly presented. It is also discussed how the primitives of this formalism are related to the LINGO building blocks.

3.1 Theoretical Foundation for a Set-based language

Sets are collections of zero or more elements whose members are unique and their order is immaterial. Sets can be finite or infinite. Finite sets with a small number of elements are usually represented by the enumeration of their members. Otherwise, they are represented by formation rules or by the definition of the characteristics and properties that all their members must have in common (intention). In our approach, concepts are defined as sets and, as mentioned before, the statement x Î Mortal commits x to the concept Mortal, both intentionally and extensionally.

Another fundamental building block in the LINGO meta-ontology is the primitive relation. This primitive represents a semantic link that exists among a set of (one or more) concepts. In our approach, relations are mapped to the synonymous primitive in set theory. In set theory, a n-ary relation can be defined by the n-tuple R =(C₁,C₂,...,C_n, p(x₁,x₂,...,x_n)), where each C_¡represents a different set involved in the relation and p(x_i,) is a functional predicate open in n variables that maps each element from the cross-product C₁´ C₂´ ... C_n in a true or false value. In this case, the set R* (solution set) is the subset of C₁´ C₂´... C_n whose members e_i all satisfy the predicate p(e_i).

Figure 3 shows an example of a binary relation that links the concepts Person and Organization in a context of Enterprise Modeling. The equivalent description in set theory is contract = ((Organization, Person, contract(x,y)).

Figure 3

From now on, the propositional function p(x,y) will be used as synonym of the n-tuple that defines the relation, assuming that the function is defined in some cross-product C₁´ C₂´ ... C_n.

In set theory, some essential operations are defined to express the relations between sets (Í - proper-subset or Ì - subset; È - Union; Ç - Intersection; \ - set difference; Ã - power set), properties of sets (# - cardinality), restriction on relations (~ - inverse relation,; - relation composition) and relations between sets and their members (Î - Membership) [11]. In addition to this, we use the basic logic operators (Ù - conjunction; Ú - disjuntion; Å - exclusive disjunction; Ø - negation; ® - conditional; « - biconditional) and quantifiers (" - universal; $ - existential; $! -exists one and only one) to form the core of the formalism employed in this work.

In order to extend this core formalism, some additional functions are defined. The two most important among them are the functions set relational Image (Im) and the element relational image (Im₊). These functions play a fundamental role in the specification of derivation axioms and solution sets to competency questions [8]. The definitions¹ of Im and Im₊are given as follows:

Using the relation of figure 3 as an example, a possible valid image set could be: Im₊(Org₁, contract) = {John, Paul, Mary} and, consequently, Im₊(John,contract~) = {Org1}. It is important to notice that axiom (AL3) specifies that the set Im function distributes over the element Im₊function, i.e., Im({John,Mary},contract) = Im₊(John, contract) È Im₊(Mary, contract).

The use of cardinality constraints of type (1,1) in this example implies that " p: Person #Im₊(p,contract) = 1 and cardinality constraints of type (l,n) implies that "o:Organization #Im₊(o,contract) > 1.

The axiom (AL4) completes the formal definition of our set-based language providing the semantics of the selection operator in this context. In this definition we assume the set F as the superset of all basic types, such as, À, Â Boolean, Strings, and so on.

The selection operator takes as parameters: (i) a set X (e.g. Person); (ii) a property (function) existent between X and the a subtype of F (e.g. age, where the subtype of F is À); (iii) a relation (operation) defined for the specific subtype of F (e.g., >); (iv) and an instance value of F (e.g.,24).

3.2 The Set Framework

Figure 4 shows a support framework that plays a fundamental role in our ontology-to-Java objects mapping process. This framework implements the mathematical properties described by the theoretical foundation presented above (i.e., our meta-ontology). The methods of the Set class are summarized in table 2.

The Set class is a generic container that is able to hold extension sets for all kinds of concept instances. To be accessible, each member of a set must have a unique identifier. The SetElement interface deals with this requirement, providing an identification mechanism through the getKey method. For an instance of any class to be held in a Set, it must implement the SetElement interface. Consequently, the Set class is actually a set of SetElement instances. The primary key for these elements is typed as Object, which is the top-most class in the Java hierarchy. This is done in order to give the application classes total freedom regarding implementation decisions.

The framework also defines two other classes: PersistentSet and Member Set, both sub-types of Set. The former is a set that is able to handle its permanent storage in total transparency from the perspective of the class users. When the store () method is invoked in a PersistentSet, the class performs the serialization of all its members. The original state of the objects (as well as their relations) can be afterwards restored by the invocation of the retrieve ( ) method.

Finally, persistent sets can be used as an interesting alternative to implement databases [8]. Using this paradigm, a database can be seen as a family Á (set of sets), which contains all the sets existing in the application. Since, in this case, each set will be a member of another set, they must also be univocally identifiable. The Member Set is, thus, provided to for this purpose.

4 Using Objects and Patterns to Implement Domain Ontologies

The problem of consistently generating computational infrastructures from conceptual models has been known for a long time by the software engineering community as the so-called Impedance Mismatch Problem (IM) [12]. In the scope of this work, the conceptual models are domain ontologies and the computational infrastructures are object-oriented frameworks. The use of domain ontologies to realize the domain analysis activity in a software engineering process contributes with innumerous benefits [8]. However, the impedance mismatch problem is amplified: instead of performing just one step to translate between two levels of abstraction (conceptual models to computational infrastructures), two steps are necessary. The first step is to translate from an ontological level model (domain axiomatized theory) to an epistemological conceptual model (conceptual view of class diagrams) without loosing the explicit representation of knowledge. The second step is the translation between the domain model to its computational concretization - an activity that, in domain engineering terms, is called domain design.

Our systematic approach to address this two-level IM problem is composed of a set of directives, design patterns and transformation rules. The directives are used to guide the mapping from the epistemological structures of the domain ontology (concepts, relations, properties and roles) to their counterparts in the object-oriented paradigm. Contrariwise, design patterns and transformation rules are applied to the mapping process of consolidation and ontological axioms, respectively. The rational application of these conceptual tools supported by the Set framework is able generate consonant Java implementations for the ontology axiomatizated theory. In section 4.2 the mapping directives are discussed. The Design Patterns and the transformation rules are presented in sections 4.3 and 4.4. The following subsection shows the formalization of the ontology depicted in figure 2.

4.1 Ontology formalization using the set-based language

The first step in our approach for mapping domain ontologies to objects is the complete axiomatization of the domain theory using the set-based formalism. Besides the derivation (epistemological and ontological) and consolidation axioms, we need definition axioms to express concepts and relations. Given the model of Figure 2, the following definition axioms can be derived. The notational convention used is: (CD) - concept definition axioms, and (RD) - Relation definition axioms.

(CD1) P = Process

(CD2) A = Activity

(CD3) R = Resource

(CD4) S = Artifact

(CDS) M = Management Activity

(CD6) C = Construction Activity

(CD7) Q = Quality Assurance Activity

(RD1) procAggregation = (Process, Activity, procAggregation(p,a))

(RD2) subActivity = (Activity, Activity, subActivity (a₁,a₂))

(RD3) usage = (Activity, Resource, usage(a,r))

(RD4) input = (Artifact, Activity, input(s,a))

(RD5) output = (Artifact, Activity, output(s,a))

The following axioms translate the epistemological (EA) and ontological (OA) axioms shown in Table 1 and those derived from cardinality constraints (EA8 to EA10) to the Set-based formalism:

(EA1) C Ì A

(EA2) M Ì A

(EA3) Q Ì A

(EA4) "a:Activity (a Ï Im₊(a,subActivity))

(EA5) "a₁,a₂,a₃:Activity (a₁Î Im₊(a₂,subActivity)) Ù(a₂Î Im₊(a₃,subActivity)) ® (a₁Î Im₊(a₃,subActivity))

(EA6) "a₁,a₂:Activity (ai Î Im₊(a₂,subActivity)) ® (a₂Ï Im₊(a₁,subActivity))

(EA7) "a₁,a₂:Activity, p:Process (a₁ e Im+(a₂,subActivity)) Ù (a₂Î Im₊(p,procAggregation)) ® (a₁Î Im₊(p,procAggregation))

(EA8) " s:Artifact #Im₊(s,output) = 1

(EA9) " a:Activity #Im₊(a,output~) > 1

(EA10) " p:Process #Im₊(p,procAggregation) > 1

(OA1) " a:Activity atomicActivity(a) «Im₊(a,subActivity) = Æ

(OA2) "a:Activity compoundActivity(a) «Ø atomicActivity(a)

(OA3) "a:compoundActivity, r:Resourceusage(a,r) « r Î Im₊(Im₊(a,subActivity),usage)

4.2 Mapping directives

Once defined the Set-based axioms, we can initiate the object mapping. Concepts and relations are naturally mapped to classes and associations in an object model, respectively. Properties of a concept shall be mapped to attributes of the class that is mapping the concept. Although this approach works well in most cases, it is worthwhile to point some exceptions that we have found:

• some concepts can be better mapped to attributes of a class in an object model because they do not have a meaningful state in the sense of an object model;

• some concepts should not be mapped to an object model because they were defined only to clarify some aspect of the ontology, but they do not enact a relevant role in an object model;

• relations involving a concept that is mapped to an attribute (or that is not considered in the mapping) should not be mapped to the object model.

A class defines a formation rule for its instance and, therefore, can be seen and manipulated as a set in a meta-level architecture. Consequently, the classification relations in the formalism do not require any specific implementation, i.e., relations such as a Î A, are totally resolved by the programming language typing mechanism through the creation of an object a of type A.

For the mapping of relations, there are some issues that still must be discussed. Figure 2 shows a relation output between the concepts Activity and Artifact. In our approach, this relation is translated to an association between the corresponding two classes in the object model and both classes have a method output (). In this case, with the invocation of method output () in an object a₁ of type Activity, it is possible to have access to all the artifacts produced by a₁. This resulting set is formally specified by the formula Im₊(a₁,output~)). Likewise, the method invocation in an artifact instance s₁ returns its producer activity, or, Im₊(s₁,output). The returned type of the relation methods depends directly on the cardinality axioms associated to the relation. For instance, since in the scope of the output relation an Activity may produce several artifacts, output is mapped to a Set variable in the Activity class and, hence, this is the type returned by the invocation of the synonymous method on this class. When a relation has a cardinality axiom imposing an inferior limit equal to 1, this constraint is reflected in the class constructors ensuring the establishment of the relation.

Like classification, subsumption does not require any additional implementation, i.e., subtype-of relations among concepts can be directly mapped to generalization/specialization relations among classes. An axiom like M Ì A states that the concept ManagementActivity is a subtype of Activity (intentionally and extensionally). Since all elements contained in M also belong to the set A, every Management activity (m Ì M) is an activity as well. We assume here that subsets of a concept always model partitions of that concept inside that domain. For example, there is no element in the set Activity that does not belong either to ManagementActivity, QualityAssuranceActivity or ConstructionActivity. For this reason, the concept that represents a super-type is always mapped to an abstract class.

Finally, the directives also consider non-trivial mappings, e.g., n-ary relations, relation properties and conditional relations [8].

4.3 Consolidation Axioms

Considering consolidation axioms, we identified two cases to address. Consolidation axioms that concern to object types, do not need any mapping since we are working with a strongly typed language - Java. This is the case of axioms (CA1) and (CA2), shown in Table 1. Nevertheless, there is another type of consolidation axioms which purpose is to describe preconditions that must be satisfied or properties that must hold so that a relation could be established between two elements. Examples of this type of axiom can be found in the part-whole theory presented in Figure 1. For a composition relation to be set between a compound and a candidate part three properties predicates must hold for this relation: irreflexivity (AM1), asymmetry (AM2) and exclusivity (AM6). Moreover, according to the transitivity axiom (AM3), asymetry must be reified recursively. In other words, let x be a compound, for y to be set as a part of x the following relation properties must hold: (i) x cannot be equal to y; (ii) x cannot be a part of y or be a part of any part of y; (iii) y cannot already have a relation established with another whole. The following formula (AM7) specifies the conjunction of these property: "x,ycomposition(x) Ù (y Î partOf(x)) ® asymetric_partwhole(x,y) Ù ("z (y Î partOf(z)) ® (partOf(z,x) Ú partOf(x,z))).

Generally speaking this type of consolidation axiom will have the form "x:X, y:Y r₁(x,y) ® (preCondition₁) Ù (preCondition ₂) Ù ... Ù (preCondition_n). This generic form can be transposed to a pattern that should guarantee the evaluation of each of the preconditions before a relation can be established. Figure 5 shows this Consolidation Pattern (left) and its application to the (AM7) axiom (right).

The Consolidation Pattern uses the pattern Template Method defined in [13]. In this case the template method is the method setr₁and hook methods are the methods responsible for evaluating the fulfillment of the preconditions.

The Whole-Part Relation

Figure 1 presents the theory (mereology) embodied by a generic whole-part relation. Notwithstanding, the underlying axioms implied by the proposed notation are not well mapped to aggregations in an object model, i.e., UML notation for aggregation does not guarantee the fulfillment of the imposed constraints. Since this theory is valid in any type of whole-part relations, a generic strategy defining a solution pattern can be modeled. Figure 6 depicts our Whole-Part ontological pattern. This pattern is built using the Precondition pattern described in the previous section and the Delegation pattern presented in [13]. By using these patterns the Whole class is able to guarantee to its associated concrete class (A) the verification of the suitable set of constraints before a relation between A and its candidate parts can be established. This service is offered to the concrete class through a delegated method (setPart).

To be able to derive the setPart method through the usage of the Precondition pattern another axiom had to be created. The following axiom (AM8) extends axiom (AM7) to generic whole-part relations:"x,y (y Î par-tOf(x)) ® asymmetric_partwhole(x,y) Ù specificCon-straint(x,y). For the composition relation the predicate specificConstraint represents the exclusivity property (AM6). Conversely, for an aggregation relation, it must assure that the part does not aggregate any whole disjoint to this one and therefore specificConstraint represents the axiom (AM4).

The Whole class is a handler that maintains a reference to the parts associated to this whole. It also encapsulates the consolidation axioms of the generic whole-part theory. Additionally, it is hierarchically divided in two subclasses, namely Aggregation and Composition, each of them encapsulating specific consolidation constraints represented by the predicate specificConstraint in the axiom (AM8). One can observe in figure 6 that the method setPart in this class was generated by the application of the Precondition pattern on the axiom (AM8). The specConstraint method is declared abstract on class Whole. Its concrete implementations are provided by the subclasses Aggregation and Composition.

The interfaces Iwhole and IPart must be implemented by the concrete classes (A and B). The methods whole ( ) and part ( ) on these interfaces provide to the concrete classes the access to its respective handlers (Whole and Part). The guarantee of implementation of these methods allows the handlers to perform precondition verification tasks in a generic way.

4.4 Ontological Axioms

Finally, it is necessary to map ontological axioms to the object model. These axioms are formalized to answer to the competency questions of the ontology. The axiom (OA3), for instance, answers to the following question: for a given compound activity a₁, which resources are used by this activity? The solution set for this question must be returned by the invocation of the method usage () in an object a₁ of the Activity class. However, for this type of methods to be derived from ontological axioms, a set of transformation rules were defined. These transformation rules are presented below.

This rule states: if for each instance x of type X, x is engaged with all instances y from set C (and only instances of this set) in a relation r1, the set returned by the function Im(x, r1) will be exactly C. The type returned by the method that implements the function in the derived class depends on the cardinality of the relation. Hence, if x is related to only one instance of Y, the returned value shall be of type Y, otherwise, it shall be of type Set, in the case a set of Y.

Let D be a subset of C in which all its elements y_¡ have an attribute wsatisfying a specific relation with an given expression exp. This expression can denote an attribute value of x_¡ (instance of X with which C is associated through the relation r₁) or a constant value. An example of the former case is presented as follows: Let the concept HumanResource be a subtype of Resource. Suppose that an instance of human resource is used by an activity if: (i) the resource is allocated to the same process that the activity belongs; (ii) the "experience required" to perform the activity is lower then the "level of experience" property of the human resource. Then

In this case the set returned by the function Im₊(h,usage~) will be exactly the set (Im(Im₊(a,procAggregation~),allocation)) after the application of the selection funtion. Like in the previous rule, the type returned by the method usage ( ) implemented in the class HumanResource depends directly on the cardinality of the relation.

A relation r₁ between two concepts X and Y is mapped in the classes that represent these concepts to methods named after the relation. For instance, given an instance x, the invocation x.r1() returns the set of objects from Y associated to x in the relation r₁.

This rule deals with the translation between the essential set theory operations (section 3.1) and the corresponding method implemented in the Set class. For instance, the set theory expression A Ç C is translated to A. intersection (C) , where A and C are instances of the class Set.

The rules T7 and T8 promote the replacement of the mathematical functions Set Relational Image and Selection by the correspondent syntaxes through which they are implemented in the Set class. The method select (that implements the selection operator) receives as the operator parameter a String whose value follows the convention described below:

(i) The operands are two objects: = (equals), ¹(not_equals)

(ii) The operands are two basic types: =, ¹, >(GTET), <(LTET), <(LT), >(GT)

(iii) The operands are an object and a set: Î (in), Ï(not_in)

Finally, this last rule directly translates the axiom written in its left side to the implementation correspondent syntax in the chosen programming language. All the references to the instance x existent in the scope of set C (to which x belongs) are replaced by the Java reserved word this, so that references to methods of the same class will be made.

The code fragment below shows the derivation process for the axiom (OA3), and also its implementation in the Activity class.

Figure 7 depicts the class diagram derived from the process ontology presented in Figure 2. It is important to notice that the cardinality convention used by UML has exactly the opposite direction to the one used by LINGO. The reasons for that are explained in [5].

5 Related Work

The Peirce project is an international collaborative effort to build a conceptual graphs workbench [14]. To accomplish interoperation among the different tools produced in the context of the project, a mathematical ontology was proposed and a software library was derived. The ontology contains taxonomic hierarchies for mathematical objects such as sets, groups, categories, relations, functions, preorders, partial orders and lattices. In [14] a specification for a Set class is formalized in several languages (Z, KIF, Conceptual Graphs - CG) and a set of C++ contracts is derived, showing pre/pos-conditions for the operations of the type. However, due to the focus of this project, the emphasis is on the object-oriented implementation of a CG processor and not on how to create object-oriented artifacts from a conceptual model.

Another interesting approach to address the impedance mismatch between the ontology and object-oriented abstraction levels is the use of design patterns. In [15] a set of design patterns for constraint representation in JavaBeans components is presented and computation reflection mechanisms are used to evaluate these constraints at run-rime. Likewise, in [16], three design patterns are used to promote Java implementation for ontologies represented in the OKBC knowledge model [17]. In this case, ontology concepts are either represented by reflection-backed JavaBeans classes, by an Active Object-Model (AOM), or by a mixed approach based on extending the classes from the AOM.

Constraints are equivalent to what we call consolidation axioms. These axioms represent only a subset of the knowledge that the must be made explicit at the ontological level. Constraints basically define pre-conditions that must be satisfied for a relation to be consistently established. Our approach to implement these axioms is also based on design patterns.

Finally, in [18], one finds an approach to create object models such as CORBA IDLs and Java classes and interfaces from Geographic Information Systems (GIS) Ontologies. The papers suggest the automatic generation of interfaces and IDLs from Ontolingua models. These interfaces constitute ontology skeletons that are, afterwards, complemented by implementation code written in Java. Ontology editors, such as Ontolingua, have the ability to create CORBA IDL headers automatically, however, in this case, the behavior implementation for the interface methods would still rely on an ad-hoc translation process. Moreover, interfaces alone are not expressive enough to incorporate the knowledge related to all kinds of consolidation axioms, let alone, ontological derivation axioms.

6 Conclusions

Since Aristotle's theory of substance (objects, things and persons) and accidents (qualities, events and process) ontologies have been used in philosophy as a foundation for representing theories and models of reality. Their main purpose is to formally make explicit the semanticm distinctions existent in portion of the world, accounted as a domain. Hayes [19] introduced the use of ontologies in Computer Science (more specifically in Artificial Intelligence). Since then, ontologies have been employed in areas such as computational linguistics, knowledge engineering, information integration and multi-agent systems. In addition to that, ontologies have been used in application areas such as enterprise modeling [20] and GIS [19], among several other examples.

In the software engineering realm, domain ontologies have been used to model the foundation over which meta-environments can be constructed [5]. Moreover, they contribute to the domain engineering phase, promoting a reuse-based practice in the requirements engineering level [8].

Nevertheless, few of the ontology construction methodologies lead to executable code and, there was still no systematic approach to fully promote their integration to the object-oriented software development practice. For this reason, most of the object-oriented implementations of domain ontologies rely on informal derivation procedures.

In this paper a contribution to address this problem is presented: a methodology through which object-oriented frameworks can be systematically derived from domain ontologies. To accomplish this goal, we also proposed a formal representation language. The mathematical foundation of this language (set-theory) highly contributed to the feasibility of our approach. This is mainly due to its suitability to bridge the conceptual and implementation abstraction levels, respectively represented by first-order logic axioms and object models.

The derivation methodology proposed comprises a spectrum of techniques, namely, directives, design patterns and transformation rules. This paper shows how these conceptual tools together with the supporting Set framework can establish a sound path between our formally axiomatized theories and a related consonant implementation in Java classes. Nonetheless, we do not claim our set of transformation rules as exhaustive and complete. However, we do advocate that transformation rules can establish an orderly procedure to generate, in object-oriented entities, methods able to explicitly represent the knowledge elicited by ontological derivation axioms.

We use the Software Process Ontology as an example to illustrate the methodology. The ontology presented was over-simplified due to the lack of space. In despite of that, the methodology has been tested in several case studies, ranging from software process [5,6] to video on demand management [8]. In all these experiments, we found the methodology effective, mainly because of: (i) its ability to capture the domain knowledge without imposing additional ontological commitments; (ii) its ability to successfully derive object frameworks capable of answering the relevant competency questions.

Finally, our methodology is highly focused on the structural issues. Consequently, a natural extension of this work is to develop an approach that also accounts for dynamic aspects of the represented domains.

• [1] B. Chandrasekaran, J.R. Josephson, V. R. Benjamins. What are Ontologies, and Why Do We Need Them?, IEEE Intelligent Systems, pp. 20-26, January/February 1999.
• [2] A. Valente, T. Russ, R.MacGregor, W. Swartout. Building and (Re)Using an Ontology of Air Campaign Planning, IEEE Intelligent Systems, pp. 27-36, January/February 1999.
• [3] N. Guarino. Understanding, building and using ontologies. Int. Journal Human-Computer Studies, 46(2/3), February / March 1997.
• [4] N. Guarino. Formal Ontology and Information Systems, In N. Guarino (Ed.), Formal Ontologies in Information Systems, IOS Press, 1998.
• [5] R.A. Falbo, C.S. Menezes, A.R.C. Rocha. A Systematic Approach for Building Ontologies. In Proceedings of the 6^th Ibero-American Conference on AI, IBERAMIA'98, Lisbon, Portugal, Lecture notes in artificial intelligence, vol. 1484,1998.
• [6] W.N. Borst. Construction of Engineering Ontologies for Knowledge Sharing and Reuse. PhD Thesis, University of Twente, Enschede, The Netherlands, 1997.
• [7] R.A. Falbo. Integração de Conhecimento em um Ambiente de Desenvolvimento de Software. Doctoral Thesis, COPPE/UFRJ, December 1998.
• [8] G. Guizzardi. Desenvolvimento para e com reuso: Um estudo de caso no domínio de Vídeo sob Demanda. Masters Thesis, Universidade Federal do Espírito Santo, July 2000.
• [9] J.M. Spivey. Understanding Z: A specification language and its formal semantics. Cambridge University Press, 1988.
• [10] N. Guarino. The Ontological Level. In R. Casati, B. Smith and G. White (eds.), Philosophy and the Cognitive Sciences, Vienna, Holder-Pichler-Tempsky, 1994.
• [11] J. Roitman. Introduction to modern set theory. Wiley-Interscience, New York, 1990.
• [12] S.N. Woodfield. The impedance Mismatch between Conceptual Models and Implementation Environments. In International Conference on Conceptual Modeling (ER'97), Workshop on Behavioral Models and Design Transformations: Issues and Opportunities in Conceptual Modeling, Los Angeles, California, Nov, 1997.
• [13] E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design patterns: elements of reusable object-oriented software. Addison-Wesley, 1995.
• [14] G. Ellis, S. Callaghan. A specification of a Set Class in Peirce. http://citeseer.nj.nec.com/29926.html, October, 1995.
• [15] H. Knublauch, M. Sedlmayr, T. Rose. Design Patterns for the Implementation of Constraints on JavaBeans, NetObjectDays2000, Erfurt, Germany, 2000.
• [16] H. Knublauch. Three Patterns for the Implementation of Ontologies in Java. In OOPSLA'99 Metadata and Active Object-Model Pattern Mining Workshop, Denver, USA, 1999.
• [17] W. Grosso. Knowledge Modeling at the Milennium (The Design and Evolution of Protégé-2000). Knowledge Aquisition Workshop, Banff, Canada, 1999.
• [18] F. Fonseca, M. Egenhofer. Knowledge Sharing in Geographic Information System. In P. Scheuerman (Ed.), The Third IEEE International Knowledge and Data Engineering Exchange Workshop, Chicago, 1999.
• [19] P. Hayes. The Naive Physics Manifesto. In D. Ritchie (Ed.) Expert Systems in Microeletronics age. Edinburgh University Press, pp 242-270, 1978.
• [20] M. Gruninger, M.S. Fox. The Role of Competency Questions in Enterprise Engineering. In Proceedings of the IFIP WG5.7 Workshop on Benchmarking -Theory and Practice, Trondheim, Norway, 1994.

1

One shall notice that the symbol <=> (used as in A<=>B) is a meta-mathematical construct that represents the set of existent relations between the sets A and B. Differently, the symbol <->, represents the logical biconditional. Moreover, although the symbol –> is used both for functions definition and for logical implication, its semantics shall be made clear by the usage context.

Publication Dates

• Publication in this collection
  12 Jan 2004
• Date of issue
  July 2002