This paper encompasses a elements study of knowledge representation founded on ontologies that have Linux test as target domain. The study aims demonstrating that once knowledge is formalised, it is possible to reuse, to perform inference, to process it through computers, and, what is more relevant, it becames enable to be communicated between people and software. Towards that, three ontologies have been developed: OSOnto (Operating System Ontology) which represents concepts of the operating system domain, SwTO (Software Test Ontology) which deals with the software testing domain, and SwTOI (SwTO Integrated) which represents concepts of both domains in an integrated way. For implementing the ontologies, OWL DL as ontology speci cation language, Protege as ontology editor and Racer as the main reasoner, have been used. A quantitative and qualitative evaluation of the SwTOI ontology has been performed as well.
One of the most challenges that the Software Engineering faces is: who does build software in a good quality with the reduced cost, time and e ort? Several technological solutions are aimed as answers for this asks. One of them is the Free Software that seeks to contribute with its collaborative projects substantiated in the knowledge liberty and the intellectual property. Among the several free software projects, the Linux3 is detached to have been one of the pioneers and for grouping a signi cant number of collaborators and users. The project maturity and the technical group, formed by people that participate actively, are interesting points to be observed. However, the quality of the Linux is much more observed and felt by users than actually veri ed by scienti c procedures. Linux has been inserted in the business domain, then its quality needs to be actually veri ed. This fact results in a union between communities and interested
companies, giving rise to the Linux Test Project (LTP)4. The objective of this project is assurance the Linux quality through systematic tests. This project behaves as a repository with scripts, tools and more of 3.000 test cases. The LTP documentation is de cient and there is not an e cient record of the designers knowledge in the tests elaborations. These di culties inside the Linux test community is common in many others projects and this has motivated the research and it has awakened the interest to o er an ontological contribution based in Description Logic, at least reducing these di culties of the Linux test knowledge, which is maintained and recorded in a formality scarce approach, such as e-mail lists, source-code documentation and web forums. Towards that, three ontologies have been developed: OSOnto (Operating System Ontology) which represents concepts of the operating system domain, SwTO (Software Test Ontology) which deals with the software testing domain, and SwTOI (SwTO Integrated) which represents concepts of both the above domains in an integrated way. For implementing the ontologies, OWL DL as ontology speci cation language, Protege as ontology editor and Racer as the main reasoner, have been used. SwTOI is used by TeSG (Test Sequence Generator) Tool to create some tests for LTP. An evaluation of the SwTOI has been performed and some results has been included in this paper. 2
A research of existing ontologies for the identi ed domains was carried out with
the objective to reuse knowledge. For the operating system domain, the more
signi cant ontology found was BLO (Basic Linux Ontology )5, which includes
concepts of a Linux introductory course of the Leeds University [
Linux has several subsystems, like network, memory, le system, etc. The research was delimited in a deliberate sample of the Virtual File System (VFS)
OWL-Lite and the Protege. This ontology is part of a bigger project called SWALE. because the LTP contains several test cases for those subsystems and the VFS is strategic for the Linux kernel6. Nevertheless, the VFS has four objects that can be investigated (inode, superblock, dentry and le) among the which we have selected le. The initial analysis of the Linux test domain was deed through bibliographical researches and meeting with specialists. Through the elaboration of a diagram of the conceptual model was possible to visualize the presence of two distinct domains, software test and the operating system. By a decision of project, we opted by developing an ontology for each one of the identi ed domains, permitting in this way modulate them. The OSOnto (Operating System Ontology) concentrates in the domain of operating system, the SwTO (Software Testing Ontology) concentrates in the software test domain. However, those domains are able to be integrated, what gave rise to the SwTOI (Software Test Ontology Integrated)7. In this way, the knowledge about the Linux test forms a possible one ABox for the SwTOI , which is discussed in the following section. 4
The software test method proposed in [
The use cases are textual documents, described in natural language. For they can be interpreted and processed computationaly, it is necessary to describe them formally. Transcribing use cases of a natural language for a computational language is not su cient. Generating test sequences with probability to nd errors or software bugs, it is necessary to unite the designer knowledge about the software test theory and associate it with test cases elaboration. This union between knowledge representation and its instanciation can be obtained through formal ontologies. This bene t did with TeSG considered ontologies as an adequate formality to be utilized in the problem solution.
The research carried out in [
The rst stage consists in representing narrative uses cases to formal use cases as instances of SwTOI . In this case we have part of UseCase formalization illustrated subsequently in Figures 1 and 2:
UseCase: it is a documentation, which each use case has one or more settings to de ne how the system should interact with its actors for attending an objective or a task realization.
Su cient and Necessary Condition: (i) Individuals are inferred like a UseCase instances if they will be instances of Expanded class or HighLevel class since the subclasses are disjoin.
UseCase
Expanded t HighLevel (1)
(ii) Individuals of the UseCase class relate itself through hasActor property with individuals of the Actor class. (iii) Individuals of the UseCase class relate itself through hasActor property with at least one individual of the class Actor.
UseCase v DesignDocumentation
UseCase v 8 hasActor:Actor
UseCase v 9 hasActor:Actor Among several Necessary Condition of this class we have: (i) UseCase is subclass of DesignDocumentation.
Properties: (i) hasActor is an inverse object property of the isActorOf, whose domain is UseCase and range is Actor.
hasActor
hasActor 2 PO isActorOf > v 8 hasActor : UseCase
hasActor :! > v 8 Actor (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) This property has integer values de ned by owl:oneOf constructor. It can have priority from 1 until 5, where 1 means lower priority and 5 high priority. f 1; 2; 3; 4; 5 g v hasUseCasePriority Disjoin: (i) UseCase class is disjoin of the EventSequence, Actor, ImportanceRanking, ExternalBehavior, SoftwareRequirement, Event and Frontier. These classes do not share instances.
0 : EventSequence; 1 B : Actor; C
BB : ImportanceRanking; CC Event v BBB : ExternalBehavior; CC
B : SoftwareRequirement; CC B@ : Event; CA
: Frontier; Instances of the Use Case: isGeneratedBy(ftest01; IBM TestCaseGenerationProcess) isTestDocumentationOf(ftest01; LinuxTestProcess) hasInputSpecification(ftest01; lseek) hasInputSpecification(ftest01; read) hasInputSpecification(ftest01; write) hasInputSpecification(ftest01; truncate) hasInputSpecification(ftest01; ftruncate) hasInputSpecification(ftest01; fsync) hasInputSpecification(ftest01; sync) hasInputSpecification(ftest01; fstat) hasOutputSpecification(ftest01; ag 0 for unexpected exit)
Testing le input hasPurpose(ftest01; output operations ) hasProcedure(ftest01; read) hasProcedure(ftest01; write) hasProcedure(ftest01; remove) canBeMappedInto(ftest01; ReadFile) canBeMappedInto(ftest01; WriteFile) canBeMappedInto(ftest01; RemoveFile)
The second stage consists in, using Jena8 Framework, manipulate the source code of SwTOI with all speci cations and instances to generate a schema. The TeSG uses this schema to manipulate TBox and ABox of SwTOI.
Developed in Java, TeSG uses a genetic algorithm as an heuristic approach to combine events between related use cases. SwTOI concentrates this knowledge about \Who has relation with" and \What is the use case priority". The Figure 1, extracted from Protege, presents logical conditions of UseCase class.
The Figure 2 presents the properties that describes UseCase class. For this description is possible to observe: { The properties hasGoal, hasPostCondition, hasUseCaseIdNumber, hasUseCaseName, hasUseCasePriority and hasDocumentationVersion are datatype properties.
The third stage is generating a test sequence according to [
The evaluation's purpose aims the quality of an ontology. Some works
concentrate in the development and approaches studies, for so much, there are some
proposed tools to support this activity, but they are not much utilized [
The SwTOI evaluation was based on two strategies in parallel: quantitative and qualitative evaluations.
The quantitative evaluation was based on the approach described in [
Quantitative Evaluation The ontologies are used to represent knowledge of the most varied domains. They can present components in common as concepts, instances, attributes (of concepts or instances), relations that can be hierarchical (all-part and is-a) or not and restraints about concepts and relations in the form of axioms. The analysis of those components of an ontology can reveal information and important characteristics , such as, the level of ontology formality according to the explicit speci cation. Informal ontologies contemplates concepts, instances, relations and attributes. Formal ontologies, beyond contemplate the same components of the informal ontologies, also represent restrictions about concepts and relations in the form of axioms.
The approach proposed in [
In OWL DL a property is a binary relation. In this work we have considered two kinds of properties: object properties(PO) and datatype properties(PD). The quantitative evaluation was based on ve indicators: (i) quantity of classes nominated, (ii) Medium of the properties PO, (iii) is-a relation levels of the Ontology, (iv) class bigger rank of the is-a relation and (v) class bigger rank of the all-part relation. The isolated analysis of each one of those indicators does not lead to conclusive results. It is necessary to observe them together. The indicators will be detailed bellow.
Quantity of Nominated Classes - The quantity of nominated classes can supply an indicator of the ontology size and domain represented. SwTOI has 194 nominated classes. However, this indicator is not conclusive. To evaluate the detail level of an ontology it is necessary other indicators. Average of the Properties PO - An object properties re ects a relation between instances of two classes. The reasoners carry out inferences about object properties like the veri cation of restrictions about properties and the veri cation in domain/range axiom. A datatype properties re ects a relation between an instance and a XMLSchema type. The datatype properties are treated separately by the reasoners. Generally, ther is an inference machine separated for kinds of datatypes. Due to \open world assumption" logical premise of the reasoners utilized in OWL, the average analysis of the object properties regarding the total of nominated classes gives an idea of the representative distribution among the instances of the classes. SwTOI has 142 PO and 51 PD.
In the following equation, MPO means the average of the ontology object properties; PO is the total object properties; n is the total of ontology nominated classes.
M P O =
PO n The average of SwTOI in relation of the nominated classes total is 0,73. This indicator can help the ontology engineers evaluates the abundance of relations among classes. Is-a Relation Levels of the Ontology - Upon observing the ontology structure, it is possible do an analogy with the graph's theory where a class corresponds to a node and the relation between classes (is-a or all-part) corresponds to an edge. The graphs are rich in properties and many information can be extracted from its analysis. From only one ontology, several graphs can be generated. If we consider the relation is-a between the classes, we have a tree and if an ontology imports another one, we have a forest. From this kind of graphs, it is possible to identify the ontology depth level, starting from the concept of the highest level or root concept until arrive the leaf concepts.
The Figure 3 generated by Jambalaya plug-in illustrates the classes tree and relations is-a of the SwTOI . By this tree, it is possible to observe that this ontology has seven levels since the root to the leafs being that the fth level of the root for the leafs has more density, with bigger quantity of classes. This indicator contributed with the ontology size evaluation, revealing the proportions of the root/leafs and the ontology depth through its hierarquical structure. The table 1 presents the total of classes by level and detaches the fth one as the common level that concentrates the biggest quantity of classes. Class Rank of the is-a Relation - From the graph discussed in the previous section, it is possible to extract the class rank of the ontology. This indicator can reveal the Level SwTOI 1 1 2 2 3 17 4 48 5 70 6 38 7 18
Classes Total 194
Table 1. SwTOI Classes Total classes that possess bigger connection (IS-A) with other and contribute to the project decisions as much as for the SwTOI improvement and for other application that have the intention of reuse it. SwTOI has SoftwareTest as a class with 11 IS-A relation. The SwTOI 's domain is the software test, then it is expected that an important class for domain has the greatest number of relations is-a. Class Rank of the all-part Relation - The relation all-part also establishes a kind of hierarch among the individuals of a class. As an example for this kind of relation, suppose that a car is instance of the class vehicle and the car is composed by the following parts: motor, chassis, etc. This kind of relation enrich a representation sets out of a domain informing the part of an all. For elaborating a graph of the relation all-part, it is important to consider the characteristics assumed by the properties like inverse, for example. SwTOI has SoftwareTestProcess as a class with 20 ALL-PART relation. The Table 2 summarizes the indicator discussed in this Section and presents the results found for the SwTOI . The SwTOI 's expressivity was identi ed by Protege Metrics as SHOIQ(D). This means that ontology contemplate transitive rules, intersection between classes, negation (complement of a class), full universal and existential quanti cation, and disjunction between classes. Also there is hierarch of properties, value restriction, inverse properties, symmetrical properties, well like cardinality restrictions. 5.2
Qualitative Evaluation The qualitative evaluation was based on three criterias: consistency, completeness and conciseness.
In the purpose of an ontology, a determined de nition is consistent if there is not contradictory knowledge inferred from axioms. The consistency criteria aims results of inferences carried out by a racer about the theory represented by the ontology.
If all of the concepts of a determined domain will be represented by an ontology and such representation will be veri ed by a test of completeness, this ontology is dictated complete. An ontology is an explicit speci cation of a conceptualization, that is going to o er an abstract and simpli ed vision of the world that it desires represent for some purpose. Represent all concepts can become impracticable for certain domains. The completeness criteria evaluates the explicit representation of the concepts and it aims an analysis of the ontology completeness.
An ontology is considered concise when: (i) does not store unnecessary definitions, (ii) does not exist redundancy between terms de nitions , (iii) redundancies are not inferred of other de nitions. The conciseness criteria evaluates each one of those points and aims an analysis of the conciseness of the ontology.
RacerPro supports the consistency and conciseness criteria only. Inferences were carried out in the ontology through the interface DIG (Description Logic Implementers Group), which works like a protocol of communication, allowing the reasoner interacts with the environment Protege and consequently, with the source code of the ontology. Consistency Criteria - The reasoners help the consistency veri cation in three forms: (i) verifying some de nite condition results in contradictory conclusions, (ii) inferring hierarchy of classes and subclasses and (iii) computing the instances inferred. The Protege, used in partnership with a reasoner also helps this veri cation showing the hierarchy de ned by the ontology engineer (asserted hierarchy) and after execution of the reasoner, the Protege shows inferred hierarchy. If some class was reclassi ed, i. e., if superclass changes, the editor will detach in blue the hierarchy inferred. If the class is unstable, will be detached in red. The computation of the inferred instances, carried out by the reasoner, also can be visualized by the Protege, which shows the instances associated to each class.
The RacerPro concluded that SwTOI is consistent since no de nite condition resulted in contradictory conclusions. This same consistency veri cation was carried out for the OSOnto and SwTO. Both also they are consistent. Right away was carried out the veri cation of the taxonomia.
The class Agent is subclass of the union between OSOnto:Person and OSOnto:Software. This speci cation results in a reclassi cation of class Agent like subclass of OSOnto:OperatingSystemDomainConcept. The class GrayBox is a software test technique equivalent the union of other two test techniques disjoin among themselves, to BlackBox and to WhiteBox. In the de nite hierarchy those three classes are sisters, but in the inferred hierarchy, BlackBox and WhiteBox are subclasses of textitGrayBox. The class GrayBox is equivalent to a cover axiom, de ned that all instances belong also to one of its subclasses, i. e., all technical GrayBox will be exclusively BlackBox or WhiteBox. The Figure 4 presents an alert of the Protege for the inferred reclassi cation. The Racer also contributed with the instances classi cation of each class. All the presented instances in the ontology were classi ed correctly. Completeness Criteria The classes can be classi ed as primitive or de ned. A primitive or partial class is one which has only necessary conditions. The de ned or complete classes are those which have at least a su cient and necessary condition. All class that is not de ned as primitive since all class will have at least a necessary condition (all class will be subclass of some class, neither that be of owl:Thing). Evaluating the quantity of classes in an ontology that do not possess de nitions beyond its position in the hierarchy, it is possible to observe the level of incompleteness of each class and arrive to a conclusion about the completeness criteria.
The second criteria of the qualitative evaluation, completeness, was based on total of primitive classes, considered of simple descriptions, without detailed axioms. From 194 classes nominated, 166 are primitives. This corresponds to 85% of the classes in the ontology. Those 194 classes, only 57 classes are really vague in its description, representing 30% of the total of classes of the SwTOI . The Table 3 presents this analysis. All of SwTOI , 30% of the classes can be better represented. They are classes like TestPattern, OSOnto:UserDocumentation and OSOnto:TechnicalDocumentation, which were not detailed due to the initial work delimitation. However, those classes are subject to detailment.
Conciseness Criteria - The conciseness criteria of the ontology was analyzed of subjective form, considering the revisions, observations detached by the specialists of the research group and the reasoner conclusion concerning in redundancy veri cation between de nitions terms and redundancies that can be inferred of others axioms.
To verify if the ontology had unnecessary de nitions, the specialists of the research group carried out several revisions and detected some de nitions as class Author, that represented the creators of a software, hardware or virtual community. Second the evaluation of the specialists, the creators of a hardware or virtual community are outside of the ontology purpose. During the development of the SwTOI , SwTO and OSOnto the unnecessary de nitions aimed by the specialists represented a total of 33% regarding all the de nitions of the ontologies that properly were removed and in the nal version, these unnecessary de nitions are not present any more. 6
A formal representation of the knowledge supported by an ontology can aggregate many bene ts for the Linux development process that is found in continuous evolution. Three important bene ts can be noticeable. The rst one is going to supply a formal domain vocabulary of the Linux test that represents the group consensus. The second one is the semantic record of the systematic tests elaboration criteria. The third one is the semantic record of the test designers knowledge. The bene ts cited are aligned with the present needs of the Linux test community, which waits for contributions to optimize this process.