Paper Web Semantic Rabnawaz

  • Uploaded by: rabnawaz
  • 0
  • 0
  • December 2019
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Paper Web Semantic Rabnawaz as PDF for free.

More details

  • Words: 2,322
  • Pages: 4
Efficient Software Maintenance with Semantic Web Rab Nawaz, Dr. Mudassar Ilyas Qazi COMSATS Institute of Information Technology, Abbottabad [email protected]

Abstract Software maintenance is an important phase of software engineering process. For efficient performing maintenance, maintainer should know first about the components and information about them i.e. Metadata or data dictionary. One of the important information that needs to be known by the maintainers first of all is the versioning information. In this paper software components and information about them means that metadata about those components should be represented in OWL Ontology. After creation of OWL, this created Ontology is then mapped with Software Engineering Concept Ontology (SEC Ontology). After this SPARQL Query Languages are used to query the RDF graph in order to extract useful information about software components. The proposed methodology empowers the software maintainers, to perform software maintenance with little efforts as for time and cost is concerned.

1. Introduction Software maintenance is the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment [1]. It is the important phase of software engineering life cycle. This phase is consulted only when there are newly elaborated requirements in the organization or some modification in the existing software. Software maintenance can be classified into four main categories [2]. The first one is corrective maintenance dealt with reactive modification of a software product performed after delivery to correct discovered problems. It is just only deal with the to fixed the identified error. The second one is the adaptive maintenance which is performed only when there is a need of modification in the software product performed after delivery to keep a software product usable in a changed or changing environment. Modification of a software product after delivery to improve performance or maintainability comes in perfective maintenance. This maintenance is done only when there is new requirements are elaborated. This maintenance is carried out most of the time [3]. Modification of a software product after delivery to detect and correct latent faults in the software product

before they become effective faults, this is done in the preventive maintenance. The maintenance process can be well illustrated from the following Fig. 1.

Fig. 1 Software Maintenance Process. Whenever a problem is found then there is a try to fix it. The problem found may be in the form of new elaborated requirements in the organization or any other modification in the software [2]. It is notify that the total cost of system maintenance is estimated to comprise at least 50% of total life cycle costs [2]. So maximum cost is estimated on the maintenance. In this paper one thing is address that how to empower the software maintainers that performs software maintenance very effectively with less time and cost. Once a software is handed over to any developer or programmer for maintenance, he/she first consult with the documentation of the software that contains all the information about the software component and information about them which means the function and non functional requirements. If this type of information is not available at that time, then it is bit difficult for that developer or programmer to perform maintenance efficiently. So maintenance is concerned with time and cost. Both these factors are directly proportional to each other. If time increases, cost automatically increases. In this paper one thing is addressed how to decrease cost of the maintenance. Basically this comes across when there is divergence between software components and information about them. This divergence is due to loss of coupling between software components and information about them. Totally a new methodology is adopted in this paper for software maintenance using semantic web.

For this purpose three main elements of the semantic web is use. In [4], RDF (Resource description Framework), Ontology Web Language (OWL-DL) and SPARQL Query Languages.The Resource Description Framework (RDF) is a family of World Wide Web Consortium (W3C) specifications, originally designed as a metadata data model, which has come to be used as a general method of modeling information through a variety of syntax formats. SPARQL stands for SPARQL Protocol and RDF Query Language. This is used on the RDF graph in order to extract useful information regarding the state of the software system [4]. And OWL-DL is used here to represent the meaningful relationships between the software components.

2. Web Semantic Technique. Software systems and information about them diverge quickly in time. Basically this divergence is due to loss of coupling between the software components and information about them. According to this technique capturing the system metadata coupling it with software components and then relating it to software engineering concept ontology and maintaining it over time. Metadata basically includes function and non functional requirements documentations, metrics and success or failure of tests.

3. Software Engineering Concept Ontology (SEC) Software Engineering Concept ontology is available on the internet in a standard (OWL-DL0 format just only to facilitate its potential reuse [7]. SEC ontology describes the relationship between the object oriented software components. This has the similarity to java and other object oriented languages like C++ or C# etc. Software tests, metrics and requirements are also represented in OWL and their relationship defined to various components. Two types of tests are represented here, unit tests and integration tests. Tests have results; discuss the success or failure of the last run. Tests are associated with software components and are themselves implemented as software components. Descriptions about every software components are held in a generic rdfs: comment annotation property. Each software component basically represents some requirement, and these requirements can be encoded by one or more object oriented classes. A particular method may be designated as an “entry point” for the requirements. An entry point provides a clue as to where to begin tracing the implementations in the source code. The key to using the SEC ontology is capturing when information changes. This is done via an object owl property “LastModifiedAt”, a date time property that may be used on any software component, tests, metrics

and requirements and denotes when it was last modified. The entire SEC ontology is available at [14]. The SEC ontology is different from other modeling languages, such as UML or OCL, as for as implementation is concerned [4]. The SEC ontology has only one way to represent relationship between two object oriented classes. Those classes may have different set of methods that can implement other methods in other classes such as parent class relationships. The direct relationship between classes can be inferred but are not explicitly stated. The SEC ontology was created on SWOOP ontology editor [11], whose ontology debugging features [16] are highly useful. The debugging features are based on Pallet OWL-DL reasoned [17]. The online version of Pallet [15] was used to validate the design of the ontology by performing SPARQL against it. HTML documentation for the ontology is created using the Protégé ontology editor with its OWL plug-in [12] and OWLDoc Plug-in [7]. The generated OWLDoc for SEC ontology is available online at [9]. The SEC ontology is used to represent the generic software engineering concepts in order to facilitate its potential reuse.

4. Example Data The example data based on SEC ontology and available online at [10]. The example data represents a small portion of a real world software package of the JRDF project, http://rdf.sourseforge.net. The example data consists of two object oriented classes having four methods. They belong to a package, which belongs to a program. Each class has an associated unit test. A simple metric is associated with one of its class. Each class has a requirement associated with it to implement. The OWLDoc for the example data is available at [13]. The example data was loaded into Redland Application Framework [5] and SPARQL Queries made against it. The SQPARQL queries are just only to use to answer the following questions as in [4]. 1. Whether or not the requirements are currently validated? 2. Which of the requirements require revalidation? 3. which tests have failed/ 4. Which are the requirements that are associated with the failed tests? 5. Which object oriented class had associated tests? The success of these queries show that the semantic web technique can be used to implements relational navigation of software collaboration graphs and system metadata as described in [14]. The SPARQL can also be run through the Pallet OWLDL reasoner. A portion of the example data is shown in the following graph. At the center a java class from the JRDF project called DefaultSparqlConnection. It is of type OOClass which is from SEC ontology. It has one method called ExecuteQuery (). The has method

relationship also shown in the graph. The OOClass has an associated requirement REQ1001 and a unit test also.

Output retrieves the four classes and two associated tests with them. The OWL classes and properties that constitute the SEC ontology were analyzed whether the proposed approach can be implemented within integrated development environments or project management tools [3].

6. Proposed idea

Fig. 2. RDF graph on the example data In the above Fig 2. a relationship Methodof exists from the ExecuteQuery () method to its parent class DefaultSparqlConnection. Only one such relationship is shown here for clarification.

For software maintenance versioning information of the actual platform on which the software is developed, is most important to know for the actual maintainer. So providing versioning information of the platform in the ontology is most critical. Once the software is handed over to the programmer or developer, the first thing to know by the actual developer is the versioning or the information about the application on which the actual software is developed. The following Fig. 3 shows the proposed model.

5. SPARQL Query Example. The following is made against the example data to show only those classes which have associated tests. Basically this query returns two columns defined in the SELECT command, one for the Class and other for the associated test. The Syntax of the query is as follow as described in [4]. Prefix sec: Prefix rdf: SELECT? Class? test WHERE { ?class rdf: type sec: OOClass. OPTIONAL {? test sec: isTestOf? class} } After executing the query, results will be as follows,

Fig. 3 Proposed Model All the relevant information about the software components, it will capture from the metadata. Means that requirements (Functional and Non Functional) and information about them. The work done in this methodology focusing on the metadata and coupling this metadata with SEC ontology, but no information about the application framework is mentioned out. Information about the software components and information about the application framework, both these things are represented in OWL and then relating this ontology to already built-in SEC ontology. This will help the maintainer to know about the original software that is going to be modified with addition to the application framework on which this software is developed. During maintenance the first thing to know by the maintainer before going to metadata, is of the versioning information about the framework on which the software is developed. The proposed technique empowers the maintainers for better understandability of the software components and other all relevant information.

7. Conclusion Software system and information about them diverge quickly in time; understandability is difficult in such scenarios. The proposed methodology empowers the software maintainers in every aspect of software understandability and maintaining them.

The created ontology separate software engineering domain knowledge from software components and system metadata, and make the domain assumptions explicitly. Software Engineering Concept (SEC) ontology is used in this paper to represent generic software engineering concepts in order to facilitate its potential reuse. This technique can be applied to existing systems during re engineering, reverse engineering or routine maintenance. This proposed technique can be used at any time during software system’s life cycle. The technique discussed in this paper may be implemented in an integrated development environment or project management tool. Little human efforts required to do the maintenance using this technique.

References 1. IEEE Standard Glossary of Software Engineering Terminology. New York, NY: Institute of Electrical and Electronic Engineers (1990) 2. http://en.wikipedia.org/wiki/Software_maintenance

3. Prof. Stafford, Kagan Erdil, Emily Finn, Kevin Keating, Jay Meattle, Sunyoung Park Deborah Yoon,” Software Maintenance As Part of the Software Life Cycle” Comp180: Software Engineering, December 16, 2003. 4. D. hyland, D. Carrington and S. Kaplan “Enhancing Software Maintenance by Using Semantic Web Technique”. 5. Beckett, D.: The Redland RDF Application Framework, http://librdf.org/ (updated 2006).

6. Bontas, E., Mochol, M., Tolksdorf, R.: Case Studies on Ontology Reuse, Proc. 5th International Conference on Knowledge Management (I-Know 2005) (2005) 7. Horridge, M.: OWLDoc, http://www.coode.org/downloads/owldoc/co-ode-index.php (2004) 8. Hyland-Wood, D.: An OWL-DL Ontology of Software Engineering Concepts, version 0.1, http://www.itee.uq.edu.au/~dwood/ontologies/sec.owl (2006) 9. Hyland-Wood, D.: OWLDoc for an Ontology of Software Engineering Concepts, version 0.1, http://www.itee.uq.edu.au/~dwood/ontologies/owldoc/ sec/index.html (2006) 10. Hyland-Wood, D.: Example Data for an OWL-DL Ontology of Software Engineering Concepts, version 0.1, http://www.itee.uq.edu.au/~dwood/ontologies/sec-example.owl

(2006) 11. Kalyanpur, A., Parsia, B., Sirin, E., Cuenca-Grau, B., Hendler, J.: Swoop: A 'Web' Ontology Editing Browser, Journal of Web Semantics Vol 4(2) (2005) 12. Knublauch, H., Fergerson, R., Noy, N., Musen, M.: The Protégé OWL Plugin: An Open Development Environment for Semantic Web Applications, Third International Semantic Web Conference (ISWC 2004) (2004) 13. Hyland-Wood, D.: OWLDoc for Example Data for an Ontology of Software Engineering Concepts, version 0.1, http://www.itee.uq.edu.au/~dwood/ontologies/owldoc /secexample/ index.html (2006) 14. Jarrott, D., MacDonald, A.: Developing Relational Navigation to Effectively Understand Software, Proc. 10th Asia-Pacific Software Engineering Conference (APSEC'03) (2003) 144-153 15. Parsia, B., Sirin, E., Grove, M., Alford, R.: Online OWL Consistency Checker with SPARQL Query, http://www.mindswap.org/2003/pellet/demo.shtml (as updated 2006) 16. Parsia, B., Sirin, E., Kalyanpur, A.: Debugging OWL Ontologies, Proc. 14th International World Wide Web Conference (WWW2005) (2005) 633 – 640. 17. Sirin, E., Parsia, B., Cuenca Grau, B., Kalyanpur, A., Katz, Y.: Pellet: A Practical OWL-DL Reasoner. Submitted for publication to Journal of Web Semantics. http://www.mindswap.org/papers/PelletJWS.pdf (2005).

Related Documents

Paper Web Semantic Rabnawaz
December 2019 16
Semantic Web
May 2020 8
Semantic Web Und Frbr
November 2019 19
The Social Semantic Web
November 2019 12
Populating The Semantic Web
November 2019 24

More Documents from ""

Paper Web Semantic Rabnawaz
December 2019 16
Bluetooth Rabnawaz
December 2019 11
Rab Nawaz Cv
December 2019 11