An Ontology-Based Reference Model for the Software Systems Domain with a Focus on Requirements Traceability/ Bruno Borlini Duarte. An Ontology-Based Reference Model for the Software Systems Domain with a Focus on Requirements Traceability.
Context and Motivation
Many proposals and techniques to support and improve the performance of the requirements traceability process have emerged in the literature. One of the most promising approaches suggests the use of reference models to support requirements traceability.
Research Hypothesis
OSDEF is focused on representing the concepts of failures and defects that exist in the software process and are directly related to software change/evolution. This is especially true for OSDEF, which was created to conceptualize a very specific part of the software system domain.
Research Objectives
ROSS focuses on different types of requests with distinct granularity levels and other related objects. Because of this, ROSS and OSDEF were designed to integrate with other software-related ontologies that are part of the Software Engineering Ontology Network (SEON) (RUY et al., 2016), in order to represent other types of software objects.6 In fact,.
Research Method
In relation to the relevance cycle, the research opportunity was to work on the development of an ontology-based theory of requirements traceability based on well-founded domain ontologies about the software domain. Specifically, the body of knowledge related to requirements traceability used to develop this research is based on the results of two Systematic Literature Reviews (SLRs) (KITCHENHAM; CHARTERS,2007) on requirements traceability.
Published Work
For the Design Cycle, the main artifacts produced in this thesis are the two domain ontologies, ROSS and OSDEF, created to improve the reference models already existing in the literature, proposed by Zave, Jackson and Wang. Furthermore, as a proof of concept, we also conducted an empirical evaluation of the ability of ROSS and OSDEF to be used as requirements traceability tools, using data from a prototype ATM system.
Organization
This chapter presents concepts and proposals in both the Requirements Engineering and Requirements Traceability domains that were relevant to the development of this thesis. The chapter is structured as follows: Section 2.1 presents an overview of the Requirements Engineering domain with a focus on the development of software systems.
Requirements Engineering for Software Systems
Zave and Jackson’s model
On the other hand, the specification (S), which derives from the requirement, is responsible for describing the behavior of the machine.2. 1 The concept of environment used by Zave and Jackson denotes a part of the real world in which the system of interest will operate to produce an output.
W represents knowledge of the world, R represents system requirements; S indicates system specification; P is a program that is an implementation of S for M, theMachine. In addition, van Lamsweerde proposes the concept of a domain property, which is used to extend the original formula from (JACKSON; ZAVE, 1995), as an intrinsic domain property that is not invariant.
Wang et al.’s model
However, in doing so, he does not take into account the formula proposed in (GUNTER et al., 2000). For example, in case of an error in a software system due to an assumption-used by the developers, which does not hold when the software system is in operation.4.
Requirements Traceability
In fact, the relationships that exist between the requirements themselves and other artifacts in the software process, and their classification, is an important part of the research field of requirements traceability.6. One of the most accepted classifications proposes a separation between horizontal and vertical traceability of requirements (LINDVALL; SANDAHL, 1996).
Chapter Summary
This chapter presents the ontological foundation that was used as the foundational theory for this thesis.
Ontologies
Domain ontologies describe concepts that are related to a specific domain, such as Requirements Engineering or Economics. They are usually created with languages that are focused on expressiveness and adequacy for the domain.
UFO
On the other hand, individuals are entities that constitute universal beings and possess a unique identity. For example, the red color of the leather (a quality of the leather) on the throne, or they may have a tendency to manifest because of an event.
Operational Ontologies, Linked Data and the Semantic Web
RDF framework and SPARQL
The SPARQL query language can be used to query data from various data sources that follow the RDF data model. The query works by searching the data sources for triples that match the format shown in the query (usually after the WHERE clause).
SPARQL (W3C,2013), is a query language for RDF that is used as an evaluation tool for the ontologies presented in this thesis. For illustration purposes, Figure 14 presents a simple SPARQL query based on the triple depicted in Figure 13 that searches for the birthplace of Sir Tim Berners-Lee.
SABiO – A Systematic Approach for Building Ontologies
Furthermore, CQs help to improve ontology scope and can also be used in the ontology verification process. Its objective is to transform the specification of the reference ontology, produced in the second phase, into the specification of an operational ontology.
SEON - the Software Engineering Ontology Network
- Software Process Ontology - SPO
- Software Process Ontology - SwO
- Reference Software Requirements Ontology - RSRO
- Ontology of Assumptions
The third is the Reference Software Requirements Ontology (RSRO) (DUARTE et al., 2018), an ontology that addresses software requirements in the context of a software process. These relationships had to be addressed to develop an Implementation Requirements Ontology (RRO) (DUARTE et al., 2018).
Chapter Summary
ROSS is a domain reference ontology (GUIZZARDI, 2007), a conceptual artifact that aims to represent the domain of software systems in the best possible way. CQ6: What types of assumptions are important in the context of the software system.
ROSS Business Sub-ontology
Since world assumptions are statements, they represent the propositional context of the intentions of the organization about the software system. 6 A historical dependency is a non-descriptive relationship where the truthmaker of the relationship is an Event.
ROSS Systems Sub-ontology
In this context, software systems are intended to implement SyRS and intended to fulfill the System Requirements described in SyRS. In other words, in order for SyRS to be created, it depends on assumptions about the environment and about the machine.
ROSS Machine Sub-ontology
The result is that the source code as a sequence of symbols can be changed without changing the identity of the program. As in the original formulation proposed by Zave and Jackson (1997), the program specification is strongly related to the assumptions that exist in the machine context.
Related Works
Goal Oriented Requirements Ontology (GORO)
Core Ontology of Requirements
Due to its concepts inextricably linked to the domain of Goal-Oriented Requirements Engineering and its support for DOLCE, CORE was adopted as a conceptualization for the creation of the GORE language Techne (BORGIDA et al., 2009). However, CORE is grounded in DOLCE (MASOLO et al., 2003), although a part of DOLCE similar to the conceptualization presented in UFO.
Chapter Summary
The concepts of the core ontology are Goal, Soft Goal, Quality Constraint, Plan and Domain Assumption. Moreover, CORE was adopted for the development of the GORE modeling language Techne (BORGIDA et al., 2009).
Motivation and Requirements
OSDEF is a domain reference ontology that presents an ontological analysis of software system bugs, defects, errors, and failures, often collapsed into the commonly used term software anomaly, usually used to denote a situation where a software system deviates from its expected behavior. Finally, CQ 8 was raised due to the necessity that the ontology represents not only the subtypes of software system errors, but also the other entities related to these subtypes.
OSDEF Reference Model
Unlike intrinsic moments that are always manifest, i.e. qualities (e.g. the color of a wall), defects and vulnerabilities can never be activated and therefore never manifest in failures. In this case, the erroneous user action itself is the cause of the error.
Related Works
- Del Frate’s Ontology of Failure Engineering Artifacts
- Kitamura and Mizoguchi’s Ontology of Faults
- Avizienis Taxonomy of Faults
- Common Ontology of ValuE and Risk (COVER)
The Common Ontology of Value and Risk (COVER) (SALES et al., 2018) provides a rigorous ontological analysis of events, objects, qualities, situations and relationships that can be used to define the concept of risk. In addition, the authors present and discuss different types of value and risk based on these intrinsic properties.
Chapter Summary
SABiO prescribes that ontologies must go through ontology verification and validation techniques, in a process analogous to the verification and validation of software systems. Based on these normatives, we discuss in the following sections the verification and validation techniques applied for ROSS and OSDEF.
Ontology Verification
CQ7 Business Requirement Specification describes a set of Business Requirements based on World Assumptions, which are Propositions about the World Behavior. Program requirement specification describes a set of program requirements based on machine assumptions, which are statements about the machine behavior.
Ontology Validation
Consequently, the users of the system (the Value Subjects for the owners of the Spamhaus project) had also compromised their intention to continue using the system. The heart of the Patriot defense system was the computer that controlled the radar and was responsible for detecting incoming threats.
Ontology Design and Implementation
Figure 38 shows the terms Program Requirement, System Requirement, Stakeholder Requirement, and Business Requirement, all subtypes of Requirement in Protégé (left) and in the original Turtle syntax (right). Analogous to the implementation of ROSS, Figure 39 shows part of the concepts of OSDEF in the graphical tool Protégé (left) and in the original Turtle syntax (right).
Chapter Summary
Additionally, although not shown in Figures 38 and 39, we also imported and reused the object and data properties defined in gUFO. In this chapter we present our approach to using operational ontologies and SPARQL queries (see Section 3.3) as tools for restoring traceability links and reasoning about the requirements data with the ontologies proposed in this thesis.
From Ontologies to Traceability Reference Models
As a result, the concept of Trace is implicit in the relationships between concepts that are part of the reference models. In this context, Figure 40 depicts a graphical representation of the ontologies used in the SPARQL queries reported in this chapter.
ATM System Scenario
ATM System Scope and Objective
It is important to clarify that a real ATM system is very complex, mainly because of the security protocols adopted to avoid fraud. Besides that, it is important to clarify that the data used in this proof of concept is based on the different types of requirements of the ATM system and on the connections that.
ATM System Requirements Data
The card reader driver must be natively compatible with the operating system installed in the ATM machine. The peripheral driver must be natively compatible with the operating system installed in the ATM machine.
Traceability and Information Recovery as SPARQL queries
The results are a list of Stakeholder Requirements,5 that have been refined from Business Requirement6 BREQ002. In addition, SPARQL also allows the user to query in the reverse direction of relations (Object Properties) that are defined in the ontology.
Prototype Tool: Requirements Tracker
The edges in the graph represent the relationship being refined from what exists between Business and Stakeholder requirements. The edges in the graph represent the indirect relationship that exists between Business Requirements and Programs.
Related Works
- Traceability Reference Model
- Traceability Meta-Model
- Semantic Traceability Model
- Infrastructure for Semantic Document Management
Furthermore, it is important to explain that we choose to show the requirements management sub-model instead of the other models proposed because it is focused on the relationships that. The semantic annotation is made based on the conceptualization of the Software Requirements Ontology (NARDI; . FALBO, 2008).
Chapter Summary
In fact, a very important aspect of this work is that it can be customized based on the user's needs with little effort. For example, the concept of Change Request in Query 4 was not originally part of the models of ROSS and OSDEF.
Research Contributions
This final chapter summarizes the main contributions of this thesis to the state of the art in the conceptual modeling of the software systems domain in Section 8.1. For example, this type of query enables an extended perspective of the data, in e.g.
Research Limitations
A study has shown (SHITJE; GUIZZARDI, 2015) that anti-models are repeated even in the models produced by experienced researchers, due to the increasing complexity of the models that are created. In this context, adding a supporting process for anti-pattern detection and handling after SABiO phase 2, Ontological Capture and Formalization, can improve the overall quality of the patterns generated based on the method.
Future Work
Formal Ontology in Information Systems: Proceedings of the First International Conference (FOIS'98), June 6-8, Trento, Italy. Grounding software domain ontologies in the unified foundation ontology (UFO): The case of the ODE software process ontology.
