An Ontology-Based Approach for Multiperspective Requirements Traceability between Analysis Models

Namfon Assawamekin School of Science, University of the Thai Chamber of Commerce, Bangkok 10400, THAILAND

Phone: +66(0) 2697-6506, Fax: +66(0) 2277-7007 namfon_ass@utcc.ac.th, namfona@gmail.com

Abstract

The traceability of multiperspective software artifacts has been recognized as an important task, particularly in requirements change management. The heterogeneity of multiperspective software artifacts makes it difficult to perform tracing, verification and merging of the requirements among various system developers. In view of that, ontology is used as a knowledge management mechanism to represent multiperspective software artifacts in a common way for interoperability and traceability purposes.

Our multiperspective requirements traceability (MUPRET) framework was firstly proposed for tracing the textual requirements to resolve the heterogeneity problems found in multiperspective requirements artifacts. In this paper, the enhancement of MUPRET framework is proposed to automatically generate traceability relationships of multiperspective software artifacts expressed in terms of typical analysis models (i.e., class diagram and entity relationship diagram). We emphasize on tracing multiperspectives in the analysis phase of software development process. An illustrative example of the extended applications is also discussed.

Keywords: Requirements traceability, Multiperspective software development, Ontology, Analysis model, Knowledge management

1. Introduction

Multiperspectives stem from the development of most large and complex systems, which inevitably involve with a variety of stakeholders in a software development life cycle. A perspective represents a way in which each system developer independently expresses or models the artifacts of the system under his/her own consideration. These artifacts result in multiperspective software artifacts. The problems of multiperspectives, arising from using different

representation styles, notations, points of view, development methodologies and vocabularies, can be extremely heterogeneous and open-ended in a software development process. Broadly speaking, heterogeneity in multiperspective software artifacts has regularly been discussed as a challenging problem, especially in the areas of requirements traceability [1].

Doctor Investigation System Class Diagram

Patient RecordSystem Requirements

System Developer 2

In-Patient RegistrationSystem ER Diagram

In-Patient Payment System Requirements

System Developer 4

System Developer 1

System Developer 3

Figure 1. Multiperspective software artifacts and their traceability relationships

In Figure 1, four stakeholders, each of whom is labeled as System Developer, want to collaborate with each other by sharing the artifacts of four systems which are parts of a hospital information system. These artifacts are overlapping and generated with respect to different perspectives. Multiple sets of vocabularies may be used in the requirements descriptions. In other cases, system developers may express or model the artifacts of the system by using different representation styles and methodologies (e.g., conventional and object-oriented analysis). To facilitate requirements traceability among various system developers, it is necessary to find an automated process to help detect the overlapping for interoperability and traceability purposes.

The rest of this paper is organized as follows. Section 2 presents some existing research related to our work. In Section 3, we propose the enhancement of

9th IEEE/ACIS International Conference on Computer and Information Science

978-0-7695-4147-1/10 $26.00 © 2010 IEEE

DOI 10.1109/ICIS.2010.43

673

multiperspective requirements traceability (MUPRET) framework. Section 4 illustrates an example of how to match the concepts between two requirements ontologies by using ontology matching technique and to automatically generate different types of traceability relationships. Finally, we conclude the paper with the discussion of our contributions and ongoing work in Section 5.

2. Related Work

A number of research efforts emerged during the last decade have been carried out to tackle the requirements traceability problems. There are few works regarding the traceability of multiperspective software artifacts. Moreover, the existing approaches and tools for requirements traceability still encounter the following problems when they are applied to multiperspective context:

Firstly, the granularity of traceability is typically too coarse-grained or medium level. From the literature, various approaches focus on either coarse-grained level (e.g., commercial tools [2], REMAP [3], RETH [4], RADIX [5] and TOOR [6]) or medium level (e.g. EBT [7]). To resolve heterogeneity for tracing, verifying and merging multiperspective software artifacts effectively, the relationships between the artifacts should be identified at fine-grained level in terms of semantic links of requirements or model elements expressed differently in various perspectives.

Secondly, automated solutions to requirements traceability face a difficult challenge due to the need to handle the overlapping among multiperspective software artifacts, as well as the large number of traceability relationships existing between them. Most of existing approaches generate traceability links manually (e.g., commercial tools [2], REMAP [3], RETH [4], RADIX [5] and TOOR [6]) or semi-automatically (e.g., EBT [7], VBRT [8] and Trace Analyzer [9]). Defining large number of traceability relationships manually can be a tedious, labor-intensive and time-consuming task.

Lastly, although there are previous attempts in applying various techniques to automatically establish traceability links of software requirements, some problems still remain. For example, the works which apply information retrieval (IR) approach to requirements traceability, such as the works in [10], [11], [12], Poirot:TraceMaker [13, 14], RETRO [15, 16] and Trace Retrieval [17], typically ignore structural and semantic information that can be found in the requirements, therefore limiting both their precision and applicability. Spanoudakis et al. [18] apply rule-based approach to automatically generate and maintain traceability links between requirements artifacts but the traceability rules specify the ways of matching

syntactically related terms in the textual parts of a requirements statement or use case with related elements in the object model. Although those existing approaches as reviewed above tackle traceability relationships at fine-grained level, they handle the software artifacts defined or expressed by various developers by using same set of vocabularies or same perspective. Accordingly, the openness and shared vocabulary restrict the freedom in expressing multiperspectives.

From our review on requirements traceability approaches and tools, it can be argued that our main contribution clearly addresses the lack of effective support for automatic generation of traceability relationships of multiperspective software artifacts at fine-grained level. More importantly, we support a truly multiperspective development environment by allowing developers to express their artifacts with the freedom of using multiple sets of vocabularies, different representation styles or methodologies.

3. Our Approach

The crucial goal of this work is to automatically generate traceability relationships of multiperspective software artifacts at fine-grained level for any software requirements domain. In order to achieve our goal, a multiperspective requirements traceability (MUPRET) framework adjusted from our previous works [19-21] is depicted in Figure 2.

In this framework, we obtain a set of software artifacts expressed in terms of typical analysis models from various developers. Model elements generator(MEG) module automatically extract model elements from the software models. Requirements ontology constructor (ROC) module attaches the model elements into a base ontology, constructed in base ontology constructor (BOC) module, to automatically construct requirements ontology of each developer as a common representation for knowledge interchange purposes. Ontology matcher (OM) module applies ontology matching technique for automatically generating different types of traceability relationships between two requirements ontologies.

4. Generating Traceability Relationships from Ontology Matching

This paper rigorously focuses on the BOC, ROC and OM module as discussed in Section 4.1 and 4.2. To automatically generate traceability relationships, the illustrative example of ontology matching between two requirements ontologies is presented in Section 4.3. These details will be explained in the following subsections respectively.

674

Ontology Matcher

Matched Concepts

Pre-Process of Multiperspective Requirements Traceability Automated Multiperspective Requirements Traceability Process

Base Ontology

Requirements Ontology

Constructor

Requirements Ontology

Constructor

Requirements Ontology 1

Base Ontology Requirements

Ontology 2

Base Ontology Constructor

IEEE Std 830-1998

ESA PSS-05-03

Traceability Relationships

Model Elements

Model Elements

SoftwareModel

SoftwareModel

Ontology Engineer

ModelElements

Generator

Model Elements

Generator

Developer 2

Developer 1

SoftwareArtifacts

SoftwareArtifacts

Figure 2. Enhancement of MUPRET framework for multiperspective software artifacts

4.1. Automatic Construction of RequirementsOntology

A base ontology was originally constructed and described in our previous works [19-21]. We extend the base ontology to trace between requirements text and the class diagram in [22]. The main interest of this paper is to automatically trace between the class diagram and the entity relationship (ER) diagram. As a result, the model elements of the ER diagram are added to the base ontology as illustrated in Figure 3.

data data relation function

requirement artifact

NL:object

functional requirement non-functional requirement

data specification process specification control specification

NL:relationship

NL:process

CLD:relationship

ER:entity

ER:attribute

CLD:operation

CLD:class

CLD:attribute

ER:relationship

Figure 3. A graphical representation of a base ontology

In our work, we represent each construct in the ontologies by using the first-order logic (FOL) representation for machine-readable and the visualization view for the users. The graphical notations of the visualization view are defined in Figure 4. Note that some notations are enhanced from

unified modeling language (UML)-like but they have more specific meaning used in this work.

Aggregation relationship (partOf)

Attribute relationship (attributeOf)

Generalization/Specialization relationship (isA)

Actor relationship (actorOf)

Input relationship (inputOf)

Output relationship (outputOf)

Equivalence relationship (sameAs)

Association relationship (associatedWith)

Property relationship (propertyOf)

Ontology RelationshipsGraphical Notations

Figure 4. Graphical notations of ontology relationships

4.2. Ontology Matching Technique

Before matching the concepts between two requirements ontologies takes place, we apply some rules to automatically discover implicit relationships from existing explicit relationships found in the ontologies. The implicit relationships are produced by using the inheritance, transitive and pseudo-transitiverules detailed in [19-21].

We then match the concepts between two requirements ontologies in the software requirements domain by applying S-Match [23] approach. The S-Match algorithm is organized in four macro steps. For element matching (step 3), we use external resources

675

(i.e., domain knowledge, WordNet [24]) and string matching techniques (i.e., prefix, suffix, edit distance, n-gram) with threshold 0.85. Lexical relations provided by WordNet are converted into semantic relations. For node matching (step 4), each concept is converted into a propositional validity problem. Semantic relations are translated into propositional connectives using the rules as described in Algorithm 1. We extend the overlapping relation in this algorithm.

The criterion for determining whether a relation holds between concepts is the fact that it is entailed by the premises. Thus, we have to prove that this formula (axioms) � rel(context1, context2) is valid. A propositional formula is valid iff its negation is unsatisfiable. A SAT solver [25] run on the formula fails.

Algorithm 1. The node matching algorithm

1. String nodeMatch(String axioms, context1, context2)

2. String formula = And(axioms, context1, Not(context2));

3. String formulaInCNF = convertToCNF(formula); 4. boolean isLG = isUnsatisfiable(formulaInCNF); 5. formula = And(axioms, Not(context1), context2); 6. formulaInCNF = convertToCNF(formula); 7. boolean isMG = isUnsatisfiable(formulaInCNF); 8. if (isMG && isLG) then 9. return “=”; 10. endif 11. if (isLG) then 12. return “�”;13. endif 14. if (isMG) then 15. return “�”;16. endif 17. formula = And(axioms, context1, context2); 18. formulaInCNF = convertToCNF(formula); 19. boolean isOpposite =

isUnsatisfiable(formulaInCNF);20. if (isOpposite) then 21. return “�”;22. endif 23. formula = And(axioms, Or(Not(context1),

Not(context2)), Or(Not(context1), (context2)), Or((context1), Not(context2)));

24. formulaInCNF = convertToCNF(formula); 25. boolean isOverlap =

isUnsatisfiable(formulaInCNF);26. if (isOverlap) then 27. return “�”;28. else 29. return “idk”; 30. endif

The pseudo code of a basic solution for the node matching algorithm is provided in Algorithm 1. In lines 2 and 5, the nodeMatch function constructs the formulas for testing the less general and more general relations. In lines 3 and 6, it converts them into conjunctive normal form (CNF), while in lines 4 and 7, it checks the formulas in the CNF for unsatisfiability. If both relations hold, then the equivalence relation is returned (line 9). Otherwise, the less general relation is returned (line 12) or the more general relation is returned (line 15). Finally, the same procedure is

repeated for testing the disjointness and overlap relations. If all the tests fail, the idk relation is returned (line 29).

We use types of overlap relations defined in [26] to generate traceability relationships in our work. The traceability relationships can be generated when a match is found in the requirements ontologies. Thus, the semantic relations will be mapped into traceability relationships as shown in Table 1.

Table 1. Conversion of semantic relations into traceability relationships

Semantic Relations Traceability Relationships Equivalence (=) overlapTotally (=) More or less general (�,�) overlapInclusively (�,�)Mismatch (�) noOverlap (�)Overlapping (�) overlapPartially (�)

4.3. An Illustrative Example: Multiperspective Requirements Traceability

This section provides an example to illustrate how the enhancement of MUPRET framework can resolve the heterogeneity problems found in multiperspective software artifacts efficiently. We demonstrate that two different developers (System Analyst 1 and 2) produce Doctor Investigation System (DIS) and In-Patient Registration System (IPRS) expressed in terms of the class diagram and the ER diagram respectively. They want to collaborate with each other by sharing their artifacts of two overlapping systems which are parts of a hospital information system.

Artifact 1: (DIS perspective)

Nurse

Patient

admit

hospital number name

Doctor

first name initial last name

Staff

identification number name

676

Artifact 2: (IPRS perspective)

Staff

IDname

address

Nurse Physician

Surgeon

Both artifacts are overlapping and generated with respect to different perspectives. They are passed into the MEG and the ROC module to automatically construct DIS and IPRS requirements ontology as depicted in Figure 5 (exclude a base ontology).

staff

nurse doctor

firstname

lastname

initial name

staff

nurse physician

name address

surgeon

ID

identificationnumber

patient admit

hospital number

name

CLD: class

CLD: relationship

ER: entity

IPRS Requirements OntologyDIS Requirements Ontology

ER: attribute

CLD: attribute

Figure 5. DIS and IPRS requirements ontology

We use the standard DPLL-based SAT solver [25] to check the unsatisfiability of a propositional formula done by the OM module. The following cases exemplify how to match the ontology concepts for generating different types of traceability relationships as defined in Table 1.

Case 1: Equivalence relation (overlapTotally)

From the example in Figure 5, trying to prove that doctor1 in DIS requirements ontology is less general than physician2 in IPRS requirements ontology, requires constructing the following formula.

((staff1 � staff2) � (doctor1 � physician2)) �(staff1 � doctor1) � �(staff2 � physician2)

The above formula turns out to be unsatisfiable, and therefore, the less general relation holds. It is noticeable that if we test for the more general relation between the same pair of concepts, the corresponding formula would be also unsatisfiable. As a result, the final relation for the given pair of concepts is the equivalence.

Case 2: Subsumption relation (overlapInclusively)

From the example in Figure 5, trying to prove that first_name1 of nurse1 in DIS requirements ontology is

less general than name2 of staff2 in IPRS requirements ontology, requires constructing the following formula.

((staff1 � staff2) � (nurse1 � nurse2) �(first_name1 name2)) �

(staff1 � nurse1 � first_name1) �(�(staff2 � name2) �

�(staff2 � nurse2 � name2) ��(staff2 � physician2 � name2) ��(staff2 � surgeon2 � name2) �

�(staff2 � physician2 � surgeon2 � name2))

We use the implicit rules to inherit all attributes from super concept to sub concepts for generating implicit relationships. Hence, name2 is also an attribute of nurse2, physician2 and surgeon2 in IPRS requirements ontology. The above formula turns out to be unsatisfiable, and therefore, the less general relation holds between two concepts.

Case 3: Mismatch relation (noOverlap)

From the example in Figure 5, trying to prove that admit1 in DIS requirements ontology mismatches physician2 in IPRS requirements ontology, does not need to construct the propositional formula. Since admit1 and physician2 have different types of concepts based on using a base ontology, the mismatch relation is generated immediately for this case.

Another example in Figure 5, trying to prove that name1 of patient1 in DIS requirements ontology mismatches name2 of staff2 in IPRS requirements ontology, the idk relation holds between two concepts. However, both concepts have different hypernyms of the same synset, called homonym. As a result, the final relation for the given pair of concepts is the mismatchby doing the post-process of ontology matching for this case.

Case 4: Overlapping relation (overlapPartially)

From the example in Figure 5, trying to prove that doctor1 in DIS requirements ontology is overlapping with nurse2 in IPRS requirements ontology, requires constructing the following formula.

((staff1 � staff2)) �(�(staff1 � doctor1) �(staff2 � nurse2)) �(�(staff1 � doctor1) (staff2 � nurse2)) �((staff1 � doctor1) �(staff2 � nurse2))

The above formula turns out to be unsatisfiable, and therefore, the overlapping relation holds between two concepts.

677

5. Conclusions and Ongoing Work

The key contribution of this paper is to propose the enhancement of MUPRET framework for tracing multiperspective software artifacts expressed in terms of typical analysis models (i.e., class diagram and ER diagram) based on using rule-based approach and ontology-based approach. The traceability relationships are identified by deriving semantic analogy of ontology concepts representing model elements.

Although the current stage of the MUPRET framework focuses on tracing requirements artifacts represented in terms of natural language or plain English text together with software artifacts expressed in terms of typical analysis models, it is possible to extend the framework to cover multiperspective software artifacts expressed in terms of other modeling. This can be done by adding the semantics of those model elements to the base of the MUPRET’s requirements ontology. Additionally, we also aim at exploring further how to apply our MUPRET framework to support traceability throughout a complete software development process.

6. References [1] O.C.Z. Gotel and A.C.W. Finkelstein, “An Analysis of the

Requirements Traceability Problem”, Proceedings of the 1st International Conference on Requirements Engineering (ICRE 1994), Colorado Springs, Colorado, U.S.A., April 18-22, 1994, pp. 94-101.

[2] “SE Tools Taxonomy - Requirements Traceability Tools”, International Council on Systems Engineering (INCOSE), Available at http://www.incose.org/productspubs/products/setools/tooltax/reqtrace_tools.html, September 22, 2004.

[3] B. Ramesh and V. Dhar, “Supporting Systems Development by Capturing Deliberations During Requirements Engineering”, IEEE Transactions on Software Engineering, Vol.18, No.6, June, 1992, pp. 498-510.

[4] H. Kaindl, “The Missing Link in Requirements Engineering”, ACM SIGSOFT Software Engineering Notes, Vol.18, No.2, April, 1993, pp. 30-39.

[5] W.D. Yu, “Verifying Software Requirements: A Requirement Tracing Methodology and Its Software Tool - RADIX”, IEEE Journal on Selected Areas in Communications, Vol.12, No.2, February, 1994, pp. 234-240.

[6] F.A.C. Pinheiro and J.A. Goguen, “An Object-Oriented Tool for Tracing Requirements”, IEEE Software, Vol.13, No.2, March, 1996, pp. 52-64.

[7] J. Cleland-Huang, C.K. Chang, and M. Christensen, “Event-Based Traceability for Managing Evolutionary Change”, IEEE Transactions on Software Engineering, Vol.29, No.9, September, 2003, pp. 796-810.

[8] M. Heindl and S. Biffl, “A Case Study on Value-Based Requirements Tracing”, Proceedings of the 10th European Software Engineering Conference Held Jointly with 13th ACM SIGSOFT International Symposium on Foundations of Software Engineering (ESEC-FSE 2005), Lisbon, Portugal, September 5-9, 2005, pp. 60-69.

[9] A. Egyed, “Supporting Software Understanding with Automated Requirements Traceability”, International Journal of Software Engineering and Knowledge Engineering (IJSEKE), Vol.15, No.5, 2005, pp. 783-810.

[10] G. Antoniol et al., “Recovering Traceability Links between Code and Documentation”, IEEE Transactions on Software Engineering, Vol.28, No.10, October, 2002, pp. 970-983.

[11] A. Marcus and J.I. Maletic, “Recovering Documentation-to-Source-Code Traceability Links using Latent Semantic Indexing”, Proceedings of the 25th International Conference on Software Engineering (ICSE 2003), May 3-10, 2003, pp. 125-135.

[12] R. Settimi et al., “Supporting Software Evolution through Dynamically Retrieving Traces to UML Artifacts”, Proceedings of the 7th International Workshop on Principles of Software Evolution (IWPSE 2004), 2004, pp. 49-54.

[13] J. Cleland-Huang et al., “Utilizing Supporting Evidence to Improve Dynamic Requirements Traceability”, Proceedings of the 2005 13th IEEE International Conference on Requirements Engineering (RE’05), August 29-September 2, 2005, pp. 135-144.

[14] J. Lin et al., “Poirot: A Distributed Tool Supporting Enterprise-Wide Automated Traceability”, 14th IEEE International Requirements Engineering Conference (RE 2006), 2006, pp. 356-357.

[15] J.H. Hayes, A. Dekhtyar, and S.K. Sundaram, “Improving After-the-Fact Tracing and Mapping: Supporting Software Quality Predictions”, IEEE Software, Vol.22, No.6, November-December, 2005, pp. 30-37.

[16] J.H. Hayes, A. Dekhtyar, and S.K. Sundaram, “Advancing Candidate Link Generation for Requirements Tracing: The Study of Methods”, IEEE Transactions on Software Engineering, Vol.32, No.1, January, 2006, pp. 4-19.

[17] X. Zou, R. Settimi, and J. Cleland-Huang, “Phrasing in Dynamic Requirements Trace Retrieval”, Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC 2006), Vol.1, September, 2006, pp. 265-272.

[18] G. Spanoudakis et al., “Rule-Based Generation of Requirements Traceability Relations”, Journal of Systems and Software, Vol.72, No.2, 2004, pp. 105-127.

[19] N. Assawamekin, T. Sunetnanta, and C. Pluempitiwiriyawej, “Automated Multiperspective Requirements Traceability Using Ontology Matching Technique”, Proceedings of the Twentieth International Conference on Software Engineering and Knowledge Engineering (SEKE 2008), Hotel Sofitel, Redwood City, San Francisco Bay, C.A., U.S.A., July 1-3, 2008, pp. 460-465.

[20] N. Assawamekin, T. Sunetnanta, and C. Pluempitiwiriyawej, “Resolving Multiperspective Requirements Traceability Through Ontology Integration”, Proceedings of the Second IEEE International Conference on Semantic Computing (ICSC 2008), Santa Clara Marriot Hotel, Santa Clara, C.A., U.S.A., August 4-7, 2008, pp. 362-369.

[21] N. Assawamekin, T. Sunetnanta, and C. Pluempitiwiriyawej, “MUPRET: An Ontology-Driven Traceability Tool for Multiperspective Requirements Artifacts”, Proceedings of the 8th IEEE/ACIS International Conference on Computer and Information Science (ICIS 2009), Pine City Hotel, Shanghai, China, June 1-3, 2009, pp. 943-948.

[22] N. Assawamekin, T. Sunetnanta, and C. Pluempitiwiriyawej, “Deriving Traceability Relationships of Multiperspective Software Artifacts from Ontology Matching”, Proceedings of the 10th ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing (SNPD 2009), Catholic University of Daegu, Daegu, Korea, May 27-29, 2009, pp. 549-554.

[23] F. Giunchiglia, M. Yatskevich, and P. Shvaiko, “Semantic Matching: Algorithms and Implementation”, Journal on Data Semantics IX, 2007, pp. 1-38.

[24] G.A. Miller, “WordNet: A Lexical Database for English”, Communications of the ACM, Vol.38, No.11, November, 1995, pp. 39-41.

[25] D.L. Berre, “A Satisfiability Library for Java”, Available at http://www.sat4j.org, June 15, 2006.

[26] G. Spanoudakis, A. Finkelstein, and D. Till, “Overlaps in Requirements Engineering”, Automated Software Engineering,Vol.6, No.2, April, 1999, pp. 171-198.

678