Ontology-driven Model for Knowledge-based Software Engineering

Ontology for Software Engineering Process Automation Thaddeus S*, Kasmir Raja S.V+ *

Department of Computer Science, Sacred Heart College, Tirupattur, India +

SRM Institute of Science and Technology, Chennai, India

Abstract Research in the field of software process engineering has propagated many process models. These models depict process elements in a descriptive or prescriptive manner. Though process modeling techniques enhance software engineering activities, process adherence in a project needs continuous monitoring and audit due to human enactment of the process. Process engineering automation can create an environment, which renders itself to software process execution, evaluation, improvement and remodeling. Formal specification of processes using ontologies facilitates automated reasoning and can support automation. Web Ontology Language (OWL) provides a formalism to represent process and infer its enactment at every state of a project in execution by its innate nature of sound decidability and semantic completeness. This approach is illustrated by building ontology for Rational Unified Process (RUP), drawing its conceptual model from Software Process Engineering Metamodel (SPEM). Keywords: Ontology, Software Engineering, Process Automation, Knowledge Representation and Artificial Intelligence Application

1. Introduction The right selection of software process and strict adherence to it is important in the realm of software engineering. The software process is tailored according to project characteristics and environment with its specific set of activities, roles and work products. The existing software process models like SOCCA [1], ALF [2], PMDB [3] or Unified Process [4] facilitate tailoring the software process to a project context. However, they need enhancement to provide the organizational environment, which enables process automation and drives the developers in process adherence. Adding formal specification to a process model can improve the project environment by automating the sequence of activities to be done for every role, providing a framework to audit the state of process discipline and to improve the process model based on the difficulties encountered in its enactment. Formal specification refers to description of a system and its properties using mathematically defined syntax and semantics. It is a precise and concise specification of the system considering only the essentials, which includes internal structure, functional behavior, timing behavior or performance characteristics [5]. This specification supports understanding of the system before design, facilitates the automation of system development activities and enables verification of the system in a formal way. Formal methods such as Z [6], VDM [7] and Larch [8] are used today to construct complex software and hardware systems. These methods provide a platform to describe complex systems, reason about systems and support system development. The formal methods and its specification languages are applied in different stages of software engineering such as requirements specification [9], design [10] and testing [11]. But, the application of formal methods to software process modeling and evaluation is scarce. In our earlier work [12], we have established a framework for knowledge-based software engineering representing the product and process ontologies in OWL. As formal specifications deal with description of concepts and their relations in a system, ontologies can provide the

required formalism in an effective and practical manner. Describing a software process as an ontology-using OWL can establish formal specification of a process because OWL is built on formal logic. Using reasoning services on the defined ontology enables automated processengineering activities. With OWL as the formal specification language, developing a process ontology based on SPEM v1.1 for Rational Unified Process v7 that can automate process definition, execution, evaluation and improvement in the context of a software project is the focus of this paper. Section 2 positions the principles of formal methods in the context of ontologies and OWL is shown as a suitable language for formal specification. Section 3 covers the state of art in process modeling and evaluation with a need for formal specification. Software Process Engineering Metamodel is introduced as a template to build up the ontology for software process. We present the formal specification of Rational Unified Process V7 using OWL in section 4, borrowing its concepts and relations from SPEM. Section 5 presents enactment of this process in a project environment.

2. Formal Methods and Ontologies Formal methods are making a transition from academic research to industrial practices due to the growing need for complex system development in short span with high quality [5]. Formal methods include formal specification, formal proofs, model checking and abstraction. The key to formal specification is abstraction, to abstract data objects, which specify the system and considering only the properties of the objects that relate various objects of the system [7]. This abstraction of objects and relating them via their properties is the basic principle of ontology development. And so, ontology representation languages with formal logic can be considered for formal specification. Ontology is much spoken of within Artificial Intelligence research community due to ever growing need for knowledge representation, integration, sharing and reuse in every organization. Deviating from its original philosophical roots, in the context of Computer Science, the term ontology stands for ‘formal explicit specification of a shared conceptualization’ [13]. Ontologies provide a common understanding of a domain that can be communicated between people and application systems. It facilitates agents (users) to establish communication at the knowledge level in a formal manner using specific languages and protocols, enabling knowledge sharing and reuse. [14] In Computer Science, ontologies are used in the field of knowledge management/engineering and conceptual modeling of information and knowledge systems [15]. Software Engineering is a field where conceptualization plays a major role in design and development of new systems, integration of existing systems and software components. Ontologies can be used to represent knowledge in product or process domain. There are many ontology representation languages such as SHOE, OIL, DAML+OIL, RDF and RDF(S) [16]. OWL (Web Ontology Language) is a consolidation of its preceding languages and is an accepted standard for knowledge representation by World Wide Web Consortium. OWL provides a rich set of constructs to define classes as named or anonymous using property restrictions, logical operations or class axioms [17]. OWL-DL is an offshoot of the family of Description Logics, which is a derivative of First Order Predicate Logic, offering high expressivity with sound and decidable reasoning facility. The family of Description Logics (DL) languages [18] is a formal language for knowledge representation and reasoning. It is effective in a domain where knowledge can be easily organized along a hierarchical structure based on ‘is-a’ relationship. The basic building blocks of DL are

atomic concepts (unary predicates), atomic roles (binary predicates), and individuals (constants). The expressive power of the language is realized using a set of constructors to build complex concepts and roles. Depending on the list of constructors attached, the Description Logic takes different variants. OWL-DL is a syntactic variant of the SHOIN(D) description logic (DL). A SHOIN(D) knowledge base (T, R, A) consists of a TBox T , an Rbox R, and an ABox A. The Tbox (the terminology) holds the vocabulary of an application domain, while the ABox contains a finite set of concept and role assertions C(a) and R(a,b) respectively where a and b are individuals. The Rbox consists of a finite set of transitivity axioms, and role inclusion axioms of the form R⊆S, where R and S are roles. Implicit knowledge about concepts and individuals are inferred automatically with the help of inference services such as subsumption and satisfiability.

3. Software Process Engineering Software process engineering refers to principles and techniques used in modeling, evaluation and improvement of software process towards greater productivity and quality in software development. Software process is a set of activities, methods and practices concerned with the design, development and maintenance of software product. Numerous techniques and notations are proposed to model software process. Yet, unlike other branches of engineering, software engineering is deficient in terms of scientific theory, mathematical modeling and rigorous quality control [19]. Curtis et al [20] studied five categories of modeling techniques and asserted that the boundary of software process modeling needs to be fixed because human persons enact the software process. He described process model as a conceptual framework of structures and relationship of process elements where process steps, process states, actors and work products are the functional, behavioral, organizational and informational views respectively. The automated prescriptive models such as SOCCA, ALF and Unified Process adapt this representation criterion. However, they do not provide a formal methodology for process enactment[19]. The Unified Process describes the process elements using UML notation and integrates human roles with the work products and process activities. It does not provide a system to ensure the actual enactment of the process in a project environment. Formal specification can be added to a matured software process like Unified Process to ensure automated monitoring and evaluation of process system in real-time software projects. Formal specification of software can be expressed as ontology described in OWL. Here process elements such as activities (tasks and steps), artifacts (both input and output), roles and guidance are mapped as concepts. The structures and relationship between these concepts referring to various stages of software engineering are shown as roles (relations). The enactment of the process for every project using formal specification can be realized in three levels of project initiation, execution and closure. At the inception of a project and at the first level, the software process is tailored to the project environment by modifying the ontology of the organizational process in such a way that ontology (with its concepts and roles) formally specifies the process for the target project. A process framework is instantiated from the ontology with data items to capture process metrics as data sets using a process automation CASE tool, developed based on formal specification of process ontology. Based on this framework, process evaluation and assessment can be done during process execution at the second level. This leads to automation of software process because the result of process enactment is obtained instantly and corrective measures can be taken when there is non-conformity. At the third level, process improvement is done at the project closure based on process deviations obtained from the assertions of process ontology.

Figure1. Levels of Modeling

Ontology development for any domain is a cumbersome task because the essential concepts of a domain cannot be aptly identified and structured. The Software Process Engineering Metamodel from OMG [21] is a fitting reference to match the concepts and their relations in software process domain. The conceptual model for process ontology is borrowed from SPEM, a metamodel to describe a software development process. The modeling is given in four layers by SPEM as shown in figure 1. The layer M1 that represents the process model is presented in formal specification using OWL in our approach. The layer M0 gives the actual enactment of this model in a project using Tbox, Rbox and Abox components of Description Logic represented in OWL. Abox contains the standard process elements as individuals along with the actual data of process enactment in a project as assertions.

4. Ontology for Unified Process Ontology for the software process is created using Protégé as the ontology editor [22]. The development of ontology depends much on the scope of its application. The objective of process ontology is to enact the process in a project environment such that adherence to the process in various software engineering activities are tracked and monitored. Process data are captured to evaluate process performance in the projects and improve the process in turn. The Unified Process from IBM Rational (referred as RUP henceforth) is a software development process framework with process building blocks namely phases, discipline, activity, process role and artifacts. RUP is not merely a process framework but suggests the best practices, concepts, guidance and templates for software development. RUP can be tailored to any software development process irrespective of the software size be it small, medium and large and so any software organization can follow RUP framework for its finiteness. RUP is represented in a formal manner using UML notations. By adding further formal specification in ontological representation, it can lead to its enactment in an automated manner. Most of RUP elements map with SPEM specification as shown in table 1. The process element task (not included in SPEM 1.1) is added as a subclass of activity and activity is further defined as a subclass of Work Definition (from SPEM). All activity related process elements of RUP namely life cycle, phase, activity, task and step are treated as subclasses of the concept Work Definition (in SPEM) defined as an abstract concept in OWL. Each specification in Unified Process related to the above process elements is created as separate concept. This facilitates tailoring of the process according a project’s characteristics. Similarly, each work product (grouped under Work Product Kind) and each role (grouped under Process Performer) are handled as separate classes. The relationships between various concepts such as activity, role and artifact elements are established using OWL object properties. To facilitate gathering of process data in the production of various artifacts and the performance of the roles, OWL data properties (date of creation, author, current-state and version) are included for instantiation during project

execution. Having multiple instances for every project artifact, each version of the artifact can be tracked and process adherence can be monitored. Table 1. Mapping RUP and SPEM Elements RUP 7 Basic Method Elements Role Work Product/Artifact Task Step Process Related Activity Iteration Phase Delivery Process Categorization Discipline Work Products Kinds Roles Guidance Types Guideline Concept Whitepaper Checklist Tool Mentor Template Example Supporting Materials

SPEM 1.1 Process Role Work Product Activity Step Work Definition Iteration Phase (Process) Discipline Work Product Kind Process Performer Guideline

Checklist Tool Mentor Template

The organization of RUP elements into concepts in ontologies with their related properties linking various concepts is shown in figure 2. Each of these except ProcessPerformer, GuidanceKind and Work Product has multiple classes to accommodate all process concepts in each category. Guidance types (such as Concepts, Checklists, Guidelines …) are created as separate classes and the available guidance resources are included as individuals as they serve merely as reference resources in project execution. The description of concepts in Tbox using SHOIN(D) DL syntax is illustrated here for selected concepts in table 2 (for an activity), table 3(for a task) and table 4 (for a work product). All process elements are described in the same manner and axioms are defined in such a way that inference procedures can be applied on them.

5. Process Enactment The enactment of the process in a project is obtained by creating the appropriate ontology, representing the formal specification of the process, which is given as an input to CASE tool that is driven by the program logic to implement, capture and monitor the process state in a project. This tool may be integrated with any software engineering CASE tools for requirements, analysis and design or change management. For instance, if a software configuration management tool is integrated with the process automation tool, as and when an artifact is baselined, its status can be automatically updated by the role performer.

Figure 2. A Scheme for Unified Process Ontology based on SPEM

The project environment for a new software project is created by defining the process ontology for it by merging and/or editing one or more existing process ontologies of previous, similar projects. This is done in such a manner that the required formalism to automate the sequence of activities, tracking of work products and monitoring of roles is incorporated. The process engineer does this ontology engineering as part of process environment setup. The tailoring of a process to a project is addressed very much when the project lifecycle is defined with the inclusion of all its phases. Each phase of the process includes the activities and the objectives for the successful completion of it. In RUP, the phases (inception, elaboration, construction and transition) are well-defined with unique objective for each phase. These objectives are realized by tracking the state of the related artifacts. Preconditions and exit conditions as goals (mapped from SPEM) for each artifact are defined and the realization of the phase is tracked by monitoring the state of artifacts. Presently, OWL does not provide full support for rules with decidability. Hence, the automated monitoring of the state of artifacts can be done using programming logic incorporated into the CASE tool that drives the process automation. The definition of the iteration phase for a sample project with the necessary activities and artifacts having entry and exit conditions is shown in table 5. Table 2. Example for a Concept in TBox (Activity) Analyze the Problem C ≡ ∀ hasTask (Capture_Common_Vocabulary ∨ Find_Actors_and_Use_Cases ∨ Develop_Vision) ⊆ Activity ⊆ ∃ hasTask Develop_Vision

⊆ ∃ hasTask Find_Actors_and_Use_Cases ⊆ ∃ hasTask Capture_Common_Vocabulary

Table 3. Example for a Concept in TBox (Task) C ≡ ⊆ ⊆ ⊆ ⊆ ⊆ ⊆ ⊆

Find Actor and Use-case ∀ hasOutput (Use_Case_Model ∨ Use_Case ∨ Actor) Task ∃ hasMandatoryInput Iteration_Plan ∃ hasMandatoryInput Stakeholder_Requests ∃ hasOptionalInput Vision ∃ hasOptionalInput Glossary ∃ hasOutput Actor ∃ hasRole System_Analyst

Table 4. Example for a Concept in TBox (Work Product) Actor C ≡ ∀ isOutputFrom (Find_Actors_and_Use_Cases ∨ Prioritize_UseCases ∨ Detail _Software_ Requirements) ⊆ Work_Product_Kind ⊆ hasGuidanceKind ∋ CL-Actor ⊆ hasGuidanceKind ∋ Requirements ⊆ hasRole ∋ Requirement_Specifier ⊆ hasWorkProductKind ∋ Model_Element ⊆ ∃ isContainingWorkProduct Use_Case_Model ⊆ isModifiedBy ∋ System_Analyst ⊆ ∃ isOutputFrom Detail_Software_Requirements ⊆ ∃ isOutputFrom Find_Actors_and_Use_Cases

During the execution of the project, the transformation of each artifact from its original state to final state is captured. This is done by the process tool, which integrates various activities such as baselining in configuration management or reporting of the roles in project management. The axioms and relations of various concepts in the driving ontology will warn the process performer on any deviation if it occurs and can also block the execution of activities. Deviations from the specified process, needs to be recorded before the tool allows the process performer to continue. At the project closure, all deviations are recorded and the data captured is consolidated to set in process improvement for future enactments. Table 5. Example for Phase Definition Artifact Vision Software Development Plan Risk List Iteration Plan Development Process Development Infrastructure Glossary Use-Case Model Prototypes Domain Model

6. Conclusion

Phase: Inception Entry Condition Goals Domain Model Drafted (Available) Vision(Drafted) & Objectives(Identified) Iteration Plan (Drafted) Resource(Estimated) Vision(Drafted) Develop. Process

Prepared Drafted & Reviewed

(Reviewed)

Vision(Drafted) Nil Vision(Drafted) Vision(Drafted) & Use-Case(Drafted) Nil

Documented & Reviewed Reviewed Drafted & Reviewed Actors(Identified) & Use-cases(Identified) Prepared Documented & Reviewed

In this paper, a technique to provide a formal specification for process as OWL based ontologies is proposed. The proof-of-concept is established by mapping RUPv7 (whose conceptual model is adopted from SPEMv1) is shown. We need to improve the process ontology by rigorously applying elements such as dependencies, constraints and others from SPEM Foundation and Extension packages. The well-formedness rules of SPEM must also be tightly integrated with OWL classes using rule specification [23] so that process automation is realized. Ongoing research is being carried to develop the process tool using Jena kit [24], a framework for semantic web applications and Pellet [25] as OWL reasoner to realize the effects of this technique. Though OWL is posed as ontology representation language for Semantic Web applications, the semantic and decidability nature of the language opens itself to wider artificial intelligence applications. Here we have adopted it to realize a formal specification language for software process. The application of Semantic Web syntax and semantics in software process specification can provide new options for process adherence and automation especially when software developments occur at distributed locations across the globe.

Acknowledgement University Grants Commission of the Government of India under Faculty Improvement Programme of Teacher Fellowship (Fellow Code: XTFTNMD094) has supported this work.

References [1] Edmund M. Clarke, Jeannette M. Wing, et. Al, “Formal methods: State of the Art and Future Directions”, ACM Computing Surveys, 28(4) pp. 626-643, 1996. [2] Jonathan Bowen, “Formal Specification and Documentation using Z: A Case Study Approach”, International Thomson Computing Press (ITCP), Thomson Publishing, pp. 3-10, 2003. [3] Cliff B Jones, “Systematic Software Development Using VDM”, Second Edition, Prentice Hall International, 2004. [4] Guttag, J. and Horning, J., “Larch: Languages and Tools for Formal Specification”, Springer-Verlag New York, Inc, Written with S.J. Garland, K. D. Jones, A. Modet, and J. M. Wing, pp. 250, 1993. [5] Girish Keshav Palshikar, “Applying Formal Specifications to Real-World Software Development”, IEEE Software, November/December 2001. [6] Cameron Maxwell, Artem Parakhine and John Leaney, “Practical Application of Formal Methods for Specification and Analysis of Software Architecture”, IEEE Proceedings of the 2005 Australian Software Engineering Conference (ASWEC’05), 2005. [7] Grégory Lestiennes and Marie-Claude Gaudel, “Testing Processes from Formal Specifications with Inputs, Outputs and Data Types”, IEEE Proceedings of the 13th International Symposium on Software Reliability Engineering (ISSRE’02), 2002. [8] G. Engels and L. Groenewegen, “SOCCA: Specifications of coordinated and cooperative activities”, Software Process Modeling and Technology, Chap. 4, Research Studies Press, pp. 71-102, 1994. [9] G. Canals, N. Boundjlida, J. C. Derniame, C. Godart and J. Lonchamp, “ALF: A framework for building process-centred software engineering environments”, Software Process Modeling and Technology, Chap. 7, Research Studies Press, pp.153-185, 1994. [10] M. H. Penedo and C. Shu, “Acquiring experiences with the modeling and implementation of the project lifecycle process: The PMDB work”, Software Engineering Journal 6, No. 5, pp. 259-274, September 1991. [11] http://www-306.ibm.com/software/awdtools/rup/ [12] http://www.w3.org/TR/owl-guide/ [13] Tim Berners-Lee, James Hendler and Ora Lassila, “The Semantic Web,” Scientific American, 284(5) pp. 3542, May 2001 [14] Gruber T.R., “A Translation Approach to Portable Ontology Specifications”, Knowledge Acquisition, Vol. 5, pp.199-220, 1993.

[15] Vladan Devedzi´ c, “Understanding Ontological Engineering”, Communication of the ACM, Vol. 45, No. 4, pp. 136-144, April 2002. [16] Imad Eldin Ali Abugessaisa and Dr Åke Sivertun, “Ontological Approach to Modeling Information Systems”, IEEE Proceedings of the Fourth International Conference on Computer and Information Technology (CIT’04), 2004. [17] Horrocks, P. F. Patel-Schneider, and F. van Harmelen. “From SHIQ and RDF to OWL: The making of a Web Ontology Language”, Journal of Web Semantics, 1(1), pp. 7–26, 2003. [18] Diego Calvanese, Deborah McGuinness, Daniele Nardi, Peter Patel-Schneider, Edited by Franz Baader, “The Description Logic Handbook: Theory, Implementation and Applications”, Chap. 2 Cambridge University Press, pp. 51-53 2003. [19] Silvia T Acuna, Angelica de Antonio, Xavier Ferre, and Martia Lopez, “The Software Process: Modeling, Evaluation and Improvement”, In the Handbook of Software Engineering & Knowledge Engineering, Vol. 1 Fundamentals, World Scientific Publishing, pp. 200-210, 2001. [20] B. Curtis, M. Kellner and J. Over, “Process modeling”, Communication of the ACM, Vol. 35, No.9, pp. 7590, September 1992. [21] “Software Process Engineering Metamodel Specification”, Version 1.1, An Adopted Specification of the Object Management Group (OMG), Inc., formal/05-01-06, January 2005. [22] Gennari, J., et al., “The Evolution of Protege: An Environment for Knowledge-Based Systems Development”, Stanford University,http://protege.stanford.edu., 2002. [23] Horrocks, “OWL Rules: A Proposal and Prototype Implementation”, Journal of Semantic Web, Feb 2005. [24] Carroll, J.J., et al., “Jena: Implementing the Semantic Web Recommendations”, Digital Media Systems Laboratory, HP Laboratories Bristol, 2004. [25] “Pellet OWL Reasoner”, Maryland Information and Network Dynamics Lab, 2003. http://www.mindswap.org/2003/pellet/. Thaddeus, S. and Kasmir Raja, S.V. (2006) “Ontology-driven Model for Software Engineering Environment”, Proceedings of the Eighteenth International Conference on Software Engineering and Knowledge Engineering, San Francisco, California, July.