Developing ontology-driven conceptual data models

Developing Ontology-Driven Conceptual Data Models Mohammed Odeh University of the West of England Bristol, UK 44-117-344-3700 [email protected]

Haya El-Ghalayini Petra University Amman, Jordan 962-6-57155552 [email protected]

Richard McClatchey University of the West of England Bristol, UK 44- 117-328-3176 [email protected]

ABSTRACT The use of formal ontologies during the process of information modeling is gaining acceptance. Since a given domain ontology captures a formal and explicit representation of the consensual knowledge within a domain, deriving ontology-driven conceptual data models can participate in developing better conceptual data models for understanding the problem domain. This paper demonstrates an approach to derive a conceptual data model from domain ontology. The main result is a formal framework that explains mapping rules between domain ontology and a conceptual data model.

Taking a broader view, it is often necessary to clarify the meaning of the entities and their properties for a specific domain of interest, particularly to aid understanding, communication and facilitate eventual system integration. These entities represent real world concepts and their properties. The basic description of what actually exists in the world along with both their nature and their essential properties is referred to as an Ontology (with an uppercase O), whereas “a shared and common understanding of a domain that can be communicated between people and across application systems” [2] is what the artificial intelligence community calls an ontology (with a lower-case o).

Categories and Subject Descriptors

The main focus of this research work is related to utilizing ontologies in deriving ontology-driven conceptual data models. The mapping rules between a domain ontology and a conceptual data model are demonstrated, including a formal description of ontology, conceptual data model, and the mapping rules. The implementation of such mappings can facilitate the development of conceptual data models, since ontologies can provide a more precise set of concepts. Definitions of conceptual data models that describe their importance and role in requirements analysis are provided in Section 2. Section 3 provides some definitions of ontologies and explains their potential advantages. Section 4 presents the formal framework for developing ontology-driven conceptual data models. Finally, the conclusion and future work are presented in Section 5.

[Requirements/Specifications], D.2.1 Methodologies.

Elicitation

method.

General Terms Theory, Algorithms, Design.

Keywords Domain ontology, conceptual data models, developing data models.

1. INTRODUCTION For information systems to deliver the information associated with end user and domain requirements, it is necessary to clarify the meaning of the problem domain. This can be accomplished during the phase preceding the system design process, namely the requirements engineering phase. Among the main outcomes from this phase is a set of functional and non-functional requirements that describe a system for different stakeholders including endusers and system designers [1]. Among the models that are normally developed to represent functional requirements, there are often other conceptual data models that are concerned with capturing the semantics of the problem domain in terms of its basic entities and their relationships. The development of a conceptual data model of an information system begins during the requirements elicitation and is developed during the requirements analysis activity for further validation in the remaining phases of the system development life cycle.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ISWSA’10, June 14–16, 2010, Amman, Jordan. Copyright 2010 ACM 978-1-4503-0475-7/06/2010…$10.00.

2. CONCEPTUAL DATA MODELS Conceptual data models can be considered as the blue-prints for representing specific data views related to a particular problem domain. Slightly differing definitions have been introduced by some researchers, who use the term conceptual schema in place of conceptual data model, and use the term conceptual model to refer to the language used in representing the conceptual data model. One of the most self-explanatory definitions of a conceptual data model is the one proposed by Loucopoulos [3] in which he stated that “the important functional part of a requirements specification usually takes the form of a conceptual schema, defined according to some conceptual model, incorporating static as well as dynamic properties and rules of the application domain. The primary use of a conceptual schema is in understanding a specific application domain...“[3]. In this definition, Loucopoulos highlighted the functionality, components, and main purpose of conceptual data models; note however, that the definition uses the term conceptual schema instead of conceptual data model and conceptual model instead of conceptual modeling language. Atzeni et al. [4]emphasized that representing “…the description of the organization of data on a higher level of abstraction, without taking into account the implementation aspects“ is an important feature of conceptual data models. Also, Elmasri and Navathe [5]

highlighted that conceptual data models provide “…concepts that are close to the way many users perceive data…”. One major conclusion from the above definitions is that conceptual data models play a central role in defining user requirements and developing information systems [6]. Their function is to understand and formally document an application domain to facilitate communication between stakeholders [7]. In this regard, conceptual data models represent some high level conceptualization of information requirements. Such requirements need to be specified in some abstract representation in relation to a particular real world application domain. In other words, a conceptual data model represents all relevant application domain entities and their relationships captured during the requirements engineering process. This implies that conceptual data models are closely coupled to their application domains which in turn are associated with end-user and domain requirements. Also, the models focus on describing the abstraction of the problem domain independently from any implementation details.

3. WHAT IS ONTOLOGY? In the last decade, ontologies have been considered as the backbone technology in most knowledge-based applications. As ontologies have become more common, their applicability has ranged from artificial intelligence areas such as knowledge representation and natural language processing to different fields such as information integration and retrieval systems, requirements analysis, and lately in semantic web applications. What is an ontology? This question may be answered from two viewpoints: philosophical and computing. From the philosophical viewpoint, Ontology (with an upper case ‘O’) is an ancient branch of enquiry, initiated by the Ancient Greeks and continued through the Middle Ages till the Modern Age. Ontology is the study of what exists in the world: beings, their nature, and essential properties. In Ontology, philosophers try to answer questions such as what are things or beings, and how things can be classified. The second viewpoint of ontology (with a lower case ‘o’) has been emerging into the discipline of computer science during the last 10-20 years. Ontology was initially proposed by the artificial intelligence community to model declarative knowledge for knowledge-based systems and shared with other systems. Recently, the utilization of ontologies attracted attention in the development of information systems [8]. Also, the evolution of the semantic web has encouraged the development of ontologies. This is because an ontology represents the shared understanding and the well-defined meaning of a domain of interest, thereby enabling computers and people to collaborate better [9]. The most popular definition of ontology was proposed by Gruber (1993), who defined it as “…a formal, explicit specification of a shared conceptualization”. In this definition, Gruber placed emphasis on formalizing the specification of concepts and relations, which in turn allows for knowledge representation and sharing among different agents. Studer et al. [10] analyzed this definition, and identified four main concepts: formal, explicit, shared, and conceptualization. The term formal means that an ontology should be machine readable; explicit implies that all concepts and constraints used are explicitly defined; shared indicates that an ontology should capture consensual knowledge accepted by the communities involved; and conceptualization

refers to an abstract model of phenomena in the real world arrived at by identifying the relevant concepts of those phenomena. Another relevant definition of an ontology was introduced by Guarino [8]: “a set of logical axioms designed to account for the intended meaning of a vocabulary”. In this definition, Guarino highlighted the role of logic theory as a means of representing an ontology. Uschold [11] proposed a general working definition describing the main characteristics of an ontology as: ”An ontology may take a variety of forms, but it will necessarily include a vocabulary of terms, and some specification of their meaning. This includes definitions and an indication of how concepts are inter-related which collectively impose a structure on the domain and constrain the possible interpretations of terms”. Noy and McGuinness [12] in their definition highlighted the main elements of an ontology. They defined an ontology as: “…a formal explicit description of concepts in a domain of discourse (classes (sometimes called concepts)), properties of each concept describing various features and attributes of the concept (slots (sometimes called roles or properties)), and restriction on slots (facets (sometimes called role restrictions))”. A further prevalent definition in the semantic web community was proposed by Hendler [13], who described an ontology as ”a set of knowledge terms, including the vocabulary, the semantic interconnections, and some simple rules of inference and logic for some particular topic”. A conclusion that may be drawn from the above definitions is that ontologies formalize the semantics of the domain explicitly by describing their elements; and thus, they consist of concepts that describe the internal features of the concepts, and the properties that describe the relationships between these concepts. It is, however, important to observe here that although conceptual data models apparently share (to some extent) domain concepts, ontologies are based on a shared and consensual domain knowledge agreed by a community, whereas conceptual data models represent specialized concepts of a particular problem domain.

4. OVERVIEW OF THE FORMAL FRAMEWORK The consensual knowledge about an interested domain provided in domain ontologies is the main rationale behind investigating the extent that domain ontologies can participate in developing ontology- driven conceptual data models. This section proposes a set of definitions of: domain ontology, conceptual data model, and the mapping algorithm. These definitions can be used as a theoretical basis for deriving ontology-driven conceptual data models.

4.1 A Formal Framework for Domain Ontologies The ontology defined in the framework is a domain type ontology, which specifies definitions and axioms related to the concepts in some given domain [14]. The definitions below are consistent with Guarino’s [8] and Noy and McGuinness’s [12] definitions of an ontology. On the one hand Noy and McGuinness highlighted the main concepts in building or developing an ontology. On the other hand Guarino’s definition highlighted the logic theory for representing the intended meaning in an ontology, i.e. “.. an

ontology corresponds to a logical theory” [15] (Patel-Schneider and Horrocks, 2006). Definition 4.1.1. An ontology consists of a set of concepts used to describe a specific domain. The concepts are structured by means of two kinds of properties or links, the one (subsumption property) indicating the subtype relation (or in other words that one concept is more general than another), the other (domain properties) indicating the relationships between domain concepts. Also a set of axioms, expressed in a suitable logic theory such as Description Logic (DL), are added to the domain concepts and properties to constrain their intended interpretation. Thus an ontology of Ω is a pair of [C, P], where C = {C1, C2, C3… Cn} is a non-empty set of concepts, and P = {P1, P2, P3… Pn} is a nonempty set of properties for a certain domain. Definition 4.1.2. An ontology concept is a triplet of (CN, CD, CA) where Concept Name-CN is a string of characters containing the name of the concept. Concept Definition-CD is a set of definitions that describe the meaning of any concept in C with respect to other concepts and properties. Therefore, the definition set of Ci is defined as: cn1

CiD =

U

CiDk

k =0

where cn1 is the number of definitions in the CiD; CiDk:Ci*α→Cj is a function from the Ci concept and the property of α to any concept in C, where α ∈ P ∪ {subsumption ( ⊆)}. Concept Axiom-CA is a set of axioms associated with the concept of Ci which is defined as: cn 2

CiA =

U

CiAk

where pn1 is the number of definitions in the definition set of Pi and each property is defined either as a mutual property and PiDk: C→ C is a function from the set of concepts to itself, or Pi is defined as an intrinsic property and PiDk: C→Defined Data Type is a function from the set of concepts to defined data types. Property Axiom-PA is a set of axioms associated with the property of Pi and can be defined as: pn 2

PiA =

U

PiAk

k =0

where pn2 is the number of axioms in PiA and PiAk asserts further characteristics on the meaning of the domain properties. These axioms can be represented using the underlying notions of a logic theory such as DL that restrict the intended meaning of the domain properties such as domain and range axioms.

4.2 A Formal Framework for Conceptual Data Models The definitions below have been composed according to the common elements of conceptual modeling that have been introduced in Section 2. Definition 4.2.1. A conceptual data model of ϑ for a certain Universe of Discourse1 (UoD) is a pair of [E, R], where E = {E1, E2, E3…En} is a set of entity types, and R = {R1, R2, R3, …Rn} is a set of relationships related to a certain UoD. Definition 4.2.2. An entity type of Ei is a pair of (Ei N, Ei A), where Entity Name- Ei N is a name of the entity type consisting of a string of characters. Entity Attributes- Ei A is a set of intrinsic properties (attributes) that describe an entity type of Ei independently of any other entities. Thus,

k =0 ak

Where cn2 is the number of axioms in CiA; CiAk asserts further characteristics that account for the intended meaning of domain concepts. These axioms can be represented using the underlying notions of a logic theory such as DL so as to restrict the relationships that can hold between domain concepts such as existential quantifier (∃), universal quantifier (∀), intersection logical operator (∩), or union logical operator (∪). Definition 4.1.3. An ontology property is a triplet of (PN, PD, PA) where Property Name-PN is a string of characters containing the name of the property. Property Definition-PD is a set of definitions that describe the meaning of the property of Pi. Therefore, the definition set of Pi is defined as:

Ei A =

U

aj

j =0

where ak is the number of attributes associated with Ei and aj is a triplet of (attribute name, defined data type, constraints),i.e., each triplet describes the attribute name with its data type and a set of associated constraints. Definition 4.2.3. A relationship of Ri is a triplet of (RN, RP, RC), where Relationship Name- RN is a name of the relationship consisting of a string of characters. Relationship Property- RP is a mutual property that describes a relationship between two entity types and RP: Ei → Ej is a function from the set of entity types to itself and RP belongs to the relationship set = {generalization/specialization, association}.

pn1

PiD =

U k =0

PiDk

1

Hirschheim et al. [16] define the Universe of Discourse (UoD) as a selected portion of the world that is known to the information system and information system users.

Relationship Constraint- RC is a set of constraints that restricts existence of the entity type individuals such as multiplicity, or multi-valued.

4.3 A Formal Framework for Developing Ontology-Driven Conceptual Data Models From the previously defined definitions, a Mapping Rules for developing ontology-driven conceptual data models can now be formally expressed. Definition 4.3.1. A Mapping Rules (Ξ ) is a function that maps ontology elements to conceptual data model elements with the following algorithm: Begin //Mapping Rules Algorithm DO is a given domain ontology; //Initialize CDM E = ∅; R = ∅; For every Ci ∈ C in the DO Add a new Ei to E in the CDM; //map a concept name to an entity type name Ξ(CiN, EiN); ∀ cd ∈ CiD in the DO Domain concept = Ci; Range concept = Cj; If α is a mutual property { // map the property name of α to relationship name

a

Add a new relationship Ri to R in the CDM where Ξ (Pα N, Ri N); RiPα is defined as an association type relationship; // where Ei represents the source entity type of Ri relationship; Ξ(Domain concept, Ei); // where Ξ(CiN, EiN) and Ej represents the // target entity type of Ri relationship Ξ(Range concept, Ej); Ξ ({Ci A, PαA}, RiC); } If α is an intrinsic property { // where Ei represents an entity type, and // Ξ(CiN, EiN) Ξ(Domain concept, Ei); Add a new attribute ai to Ei A in the CDM where Ξ (PαN, name); Ξ(Domain data type, attribute data type); Ξ (PαA, attribute constraints); } If α is a subsumption property { Add a new relation Ri to R in the CDM where RP is defined as a generalisation /specialisation type relationship; Ξ(Domain concept, Ei); // where Ei represents the sub entity type of Ri relationship

Ξ(Range concept, Ej); // where Ξ(CjN, EjN) and //Ej represents the super entity type of Ri relationship Ξ ({Ci A, PαA}, RiC); } For every Pα ∈ P in the DO ∀ pαd ∈ PD Domain concept = pd(Ci); Range concept = pd(Cj); If Pα is a mutual property { Add a new relationship Ri to R in the CDM where Ξ (P αN, RiN); RiP is defined as an association-type; // where Ξ(CiN, EiN) and // where Ei represents the source entity type of Ri relationship Ξ(Domain concept, Ei); Ξ(Range concept, Ej); // where Ξ(CiN, EjN) and // Ej represents the target entity type of the Ri relationship Ξ ({PαA}, RαC); } If Pα is an intrinsic property { // where Ei represents an entity type and // Ξ(CiN, EiN) Ξ(Domain concept, Ei); Add a new attribute ai to EiA entity type in the CDM where { Ξ (Pα N, attribute name); Ξ(Domain data type, attribute datatype); Ξ (Pα A, attribute constraints); } } End; // Mapping Rules Algorithm

4.4 Central Dogma Example The following is a simple ontology (Ω Ω) about the central dogma of molecular biology domain. The elements of the central dogma ontology are defined using the above formal definition of ontology; however, some of the Description Logics constructs are used in defining their axioms in order to clarify the meaning of the concepts. The axiom constructs are related to: {existential quantifier (∃), universal quantifier (∀), intersection logical operator (∩), union logical operator (∪)}. The central dogma describes the flow of protein synthesis from genes. DeoxyriboNucleic Acid (DNA) is a long thread of specific base-pairs in a specific sequence that carries inherited information and is divided into coding regions (i.e. genes), regulatory regions adjacent to the genes that determine when a gene should be expressed, and junk DNA, whose function is almost completely unknown. The gene sequence (nucleotide polymers) is transcribed into RiboNucleic Acid (RNA), in a form of a message. This messenger-RNA (m-RNA) is then translated into protein (aminoacid polymers) to carry out biological functions in the cell [17, 18]. The central dogma ontology (Ω Ω ) is a pair of [C, P] and is defined as follows:

C = {Molecule, Compound, MacroMolecularCompound, Gene, RegulatoryRegion, JunkDNA, DNA, mRNA, Protein, AminoAcid} P = {TranscribedTo, MolecularWeight} •

TranslatedTo,

PolymerOf,

The ontology concepts can be defined as follows:

C1 = (Molecule,∅ ∅, ∅); The concept name (C1N) is Molecule where the concept definition (C1D) and the concept axioms (C1A) are empty sets.

P3 = (PolymerOf, ,∅ ∅, ∅); P4 = (MolecularWeight, {P4D1: C3→ REAL}, ∅); MolecularWeight is defined as an intrinsic property of the MacroMolecularCompound concept of REAL data type. Having described the formal definition of the central dogma ontology, the central dogma ontology-driven conceptual data model after applying the proposed mapping rules is illustrated in Figure 1. Compound

Molecule

C2 = (Compound, ∅, ∅); C3= ( MacroMolecularCompound,

{C3D1:C3*⊆ ⊆→C1,

Macromolecular-Compound

C3D2:C3*⊆ ⊆→ C2}, {(∩ ∩ C3D1, C3D2)}); This means that the concept name (C3N) is MacroMolecularCompound. C3 is described using two concept definitions (C3D1 and C3D2). The concept definitions of C3D1 and C3D2 link between the concept of C3 and the concepts of Molecule and Compound using the subsumption relation. Also, the concept axiom of C3 is defined as an intersection between the concept definitions of C3D1 and C3D2.

DNA

JunkDNA

Gene

RegulatoryRegion

TrnascibedTo

C4 = (Gene, {C4D1:C4*P1→ C8}, {(∩ ∃ C4D1) (∀ ∀ C4D1)})); ∩(∃ C5 = (RegulatoryRegion ON, ∅, ∅);

1..n m-RNA

Thus, DNA is a sub-concept of a MacroMolecularCompound (C3N). DNA can be classified into: Gene (C4N), RegulatoryRegion (C5N), JunkDNA (C6N). The (C7A1) axiom is described using the union logical construct between C7D1, C7D2, and C7D3. ∩(∃ ∃ C8D1) (∀ ∀ C8D1)}); C8= (mRNA, {C8D1:C8*P2→ C10}, {(∩ This means that the concept of mRNA is described by the concept definition of C8D1 which links the concept of mRNA to Gene using the property of TranslatedTo. However, the concept axiom restricts the property of TranslatedTo on mRNA because one Gene may translated to more than one mRNA, i.e., to more than one Protein. This axiom has been described using intersection, universal and existential quantifier constructs. C9 = (AminoAcid,∅ ∅,∅ ∅); C10 = (Protein, { C10D1:C10*P3→ C9},{(∩ ∃ C10D1) (∀ ∀ C10D1)}); ∩(∃ This means that the concept of Protein is described by the concept definition of C10D3. Also, the C10D1 links the concept of Protein to the concept of AminoAcid using PolymerOf property where this property is restricted to have at least one value of the AminoAcid concept. The concept axioms for the Protein concept are described using union, universal and existential quantifier constructs. •

The ontology properties can be defined as follows:

P1 = (TranscribedTo, {P1D1: C8 → C9}, ∅); The name of P1 is TranscribedTo and is defined as a mutual property from the Gene concept to mRNA concept. P2 = (TranslatedTo, {P2D1: C10→ C4, P2D2: C10→ C8}, ∅);

PolymerOf Protein 1..n

C6 = (JUNK-DNA, ∅, ∅); C7= (DNA, {C7D1:C7*⊆ ⊆→ C3, C7D2:C7*⊆ ⊆→C4, C7D3:C7*⊆ ⊆→ C5 , C7D4:C7*⊆ ⊆→ C6}, {(∪ ∪ C7D1, C7D2, C7D3)} );

TranslatedTo

Amino-Acid 1..n

Figure 1: Central Dogma ontology-driven conceptual data model

5. SUMMARY The development of conceptual data models is a critical activity compared to other activities during the information systems development process. By this activity, the modeler describes the main aspects of the problem domain in a structured, precise and complete representation. The output of the conceptual modeling activity is closely coupled with the degree of success in understanding the problem domain; therefore, communication between users and modelers is an essential task to express the problem domain in terms easily understood by ordinary humans. For this reason, developing a set of mapping rules offers an opportunity to improve the development of ontology-driven conceptual data models. This opportunity stems from the fact that ontology describes a formalization of the knowledge in the domain [19]; in other words it captures and represents real world knowledge, thereby enabling modelers to understand the basic terms and relations for a certain problem. This paper has presented the theoretical framework for reverse engineering domain ontologies. The developed framework has introduced a set of formal definitions that can be used for mapping between domain ontologies and conceptual data models. From the concepts presented in this paper, an implementation tool that brings automation to the important area of semantic data models has been developed. This approach can facilitate the development of ontology-driven conceptual data models, especially in complex or unfamiliar domains, for example, it can minimize the knowledge gap between users and modelers. Also, it can assist in developing robust conceptual data models where more semantics and

constraints of the same domain applications are captured with less modeler effort, i.e., the general knowledge semantics of these models can be captured independently of any application problem domain.

6. REFERENCES [1] Sommerville, I. 2007. Software engineering. Eighth edition. Addison-Wesley. [2] Gruber, T. 1993. A translation approach to portable ontologies. Knowledge Acquisition, 5(2), pp. 199-220. [3] Loucopoulos, O. 1992. Conceptual modelling. In: P., Loucopoulos and R., Zieari, eds. Conceptual Modelling Databases, and CASE: an Integrated View of Information system development. John Wiley and Inc Sons, pp. 1-26. [4] Atzeni, P., Ceri, S., Paraboschi, S., and Torlone, R. 1999. Database systems: Concepts languages and architectures. London: McGraw-Hill. [5] Elmasri, R. and Navathe, S. 2000. Fundamentals of database systems. Third edition, Reading, Ma: Addison-Wesley. [6] Moody, D. 2005. Theoretical and practical issues in evaluating the quality of conceptual models: current state and future directions. Data and Knowledge Engineering, 55, pp. 243-276. [7] Siau, K. 2004. Informational and computational equivalence in comparing information modelling methods. Journal of Database Management, 15(1), pp. 73-86. [8] Guarino, N. 1998. Formal ontology and information systems. In: N. Guarino, ed. Formal Ontology in Information Systems. Amsterdam, Netherlands: IOS Press, pp. 3-15. [9] Gómez-Pérez, A., Fernandez-Lopez, M., and Corcho, O. eds. (2004). Ontological engineering: with examples from the areas of knowledge management, e-Commerce and the semantic web. London: Springer-Verlag. [10] Studer, R., Benjamins, V., and Fensel, D. 1998. Knowledge engineering: principles and methods. Data and Knowledge Engineering, 25, pp. 171-197.

[11] Uschold, M. 1998. Knowledge level modelling: Concepts and terminology. Knowledge Engineering Review, 13(1), pp. 5-29. Proceedings of the 17th Annual ACM Symposium on User interface Software and Technology (Vancouver, Canada, November 02 - 05, 2003). UIST '03. ACM Press, New York, NY, 1-10. DOI= http://doi.acm.org/10.1145/964696.964697 [12] Noy, N. and McGuinness, D. 2001. Ontology development 101: A guide to creating your first ontology. Technical Report No. KSL-01-05, Stanford University. [13] Hendler, J. 2001. Agents and the semantic web. IEEE Intelligent Systems, 17(2), pp. 30-36. [14] Smith, B. 2003. Ontology. In: L. Floridi, ed. Blackwell Guide to the Philosophy of Computing and Information. Oxford: Blackwell, 2003, pp. 155–176. [15] Patel-Schneider, P. F. and Horrocks, I. 2006. Position paper: a comparison of two modelling paradigms in the Semantic Web. In: Proceedings of the Fifteenth International Conference on World Wide Web. Edinburgh, Scotland, May 23 - 26. WWW '06, ACM Press, New York, NY, pp. 3-12. [16] Hirschheim, R., Klein, H. K., and Lyytinen, K. 1995. Information Systems Development and Data Modeling: Conceptual and Philosophical Foundations. Cambridge University Press. [17] Gibas, L. and Jambeck, P. 2001. Developing Bioinformatics Computer Skills. Sebastopol, California: O'Reilly and Associates. [18] Dennis, C., Gallagher, R. eds. 2001. The human genome. New York: Palgrave. [19] Siricharoen, W. 2009. Ontology Modeling and Object Modeling in Software Engineering. International Journal of Software Engineering and Its Applications, 3(1), pp.43-59.