manyfarmswalkingInternet and Web Development

Oct 21, 2013 (3 years and 7 months ago)


Ontology Classification for
Semantic-Web-Based Software Engineering
Yajing Zhao,Jing Dong,Senior Member,IEEE,and Tu Peng
Abstract—The Semantic Web is the second generation of the Web,which helps sharing and reusing data across application,
enterprise,and community boundaries.Ontology defines a set of representational primitives with which a domain of knowledge is
modeled.The main purpose of the Semantic Web and ontology is to integrate heterogeneous data and enable interoperability among
disparate systems.Ontology has been used to model software engineering knowledge by denoting the artifacts that are designed or
produced during the engineering process.The Semantic Web allows publishing reusable software engineering knowledge resources
and providing services for searching and querying.This paper classifies the ontologies developed for software engineering,reviews
the current efforts on applying the Semantic Web techniques on different software engineering aspects,and presents the benefits of
their applications.We also foresee the possible future research directions.
Index Terms—Semantic Web,ontology,business requirement modeling,requirements for enterprise modeling.
HE Semantic Web is the second generation of the Web to
share and reuse data across application,enterprise,and
community boundaries.One important component of the
Semantic Web is ontology that is the study of existence.In
computer science and information technology,it is a formal
representation of a set of concepts within a domain and the
relationships between these concepts.The representation is
at the semantic level,independent from data structure and
implementation.Being used to define a domain of knowl-
edge,it enables the reasoning about the properties of the
domain.In addition,it enables the integration of hetero-
geneous data and the interoperability among disparate
systems.The W3C standards for the Semantic Web include
the Web Ontology Language (OWL) [46],Resource Descrip-
tion Framework (RDF) [44],etc.OWL is an ontology
specification language and RDF is a language for describing
resources that exist on the Web.The Semantic Web
overcomes the disadvantages of natural language in a
way to represent formal,precise,and unambiguous
contents.In addition,it maintains information in the format
that can be understood and processed by automated tools
[9].It provides an integrated framework so that information
can be well organized,widely published,broadly shared,
easily retrieved,and simply integrated.
Software development is a complex process which
produces a large amount of information.Systematic,
disciplined,and quantifiable approaches are required for
the development,operation,and maintenance of software
systems [43].Effort has been made to improve the software
process.For example,modeling languages have been
proposed to better represent system designs;the advanced
Integrated Development Environments (IDEs) have been
produced to facilitate implementation;and other types of
Computer-Aided Software Engineering (CASE) tools have
been developed to manage different types of software
artifacts.However,software development remains difficult
in several ways.
First,software process involves a lot of efforts in
acquiring and producing information.Reusing existing
information saves efforts.The scope of reuse has been
expanded fromreusing pieces of code to reusing all kinds of
information,such as requirements,project processes,and
software designs.However,the current representation of
such information makes it hard to manage,retrieve,and
reuse.A method that facilitates information retrieval and
promotes reuse is highly demanded.
Second,due to globalization,software systems are
usually developed among teams that are geographically
dispersed.Consequently,diversity exists among the pro-
cesses used by different teams.For example,teams at
different locations may use diverse processes and may also
possess different sets of knowledge.Information sharing
helps to prevent inconsistency.
Information sharing and reuse have the following
benefits:improving productivity,shortening development
life cycle,decreasing cost,and increasing product quality.
The Semantic Web provides a way to improve information
sharing and reuse.Ontology has been used to model
software engineering knowledge by denoting the artifacts
designed or produced during the engineering process.The
Semantic Web allows publishing reusable software engi-
neering knowledge resources.With the support of software
engineering related ontologies,the Semantic Web allows the
query and reasoning on software engineering knowledge
manually or by software agents.
In this paper,we review the ontologies for software
engineering,provide a classification of these ontologies,and
discuss their relationships.The goal of this workis toprovide
.The authors are with the University of Texas at Dallas,PO Box 830688,
EC 31,Richardson,TX 75083.
Manuscript received 11 Dec.2008;revised 7 Mar.2009;accepted 24 June
2009;published online 1 July 2009.
For information on obtaining reprints of this article,please send e-mail to:
tsc@computer.org,and reference IEEECS Log Number TSC-2008-12-0108.
Digital Object Identifier no.10.1109/TSC.2009.20.
1939-1374/09/$25.00 ￿ 2009 IEEE Published by the IEEE Computer Society
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.
a generic and systematic set of ontologies,which enables the
application of the Semantic Web techniques.We reviewthe
current effort of using the ontologies in the Semantic-Web-
based software engineering.We examine howthe Semantic
Web technologies are used to solve different problems in
software engineering.We classify the existing approaches
according to their usage of the ontologies.The goal of this
work is to present the current state of this research area.We
discuss our ownviewonthe applicationof the Semantic Web
technologies and point out the future research directions.
The rest of this paper is organized as follows:Section 2
surveys the ontology that can be built for software
engineering.Some of the ontologies are used or mentioned
by existing researches and others are identified by us.We
also provide a schema to classify the ontologies.Section 3
discusses how the Semantic Web techniques can be used to
solve problems in software engineering.Finally,Sections 4
and 5 cover the discussions and conclusions.2 ONTOLOGIES FOR SOFTWARE ENGINEERING
The goal of the Semantic Web is to allow the Web contents
to be understood by both human and software agents.Thus,
Web contents not only have to be presented in a formal way
but also need semantic information.Ontology is a formal
representation for the concepts within a domain and the
semantic relationship between concepts.It consists of a
taxonomy and a set of inference rules.It has been used in
the Semantic Web as a formal vocabulary.It allows the
software agents to understand the Web contents through
making logical conclusions.
Software engineering is a complex process that involves
large amount of information.The amount and complexity
of the information make the process difficult to manage.
The Semantic Web and ontology techniques have been
applied in software engineering with the following advan-
tages [18]:first,to formalize the information;second,to
provide broad access from different physical locations;
third,to provide universal retrieving service that applies to
all types of software knowledge;and fourth,to allow
comparison and matching of knowledge or concepts.The
approach of applying the Semantic Web and ontology
techniques in software engineering typically includes the
following steps:first,information resources about software
development methodologies,techniques,supporting tools
as well as the software itself are gathered;second,the
concepts appearing in the resources are classified hierarchi-
cally and built into ontologies using ontology languages;
and finally,information resources are published on the Web
either for people to read or for software agents to process.
In the following sections,we survey the ontologies for
software engineering.In each section,we discuss a software
activity and the related ontologies.The organization of the
ontologies according to their related software activities
makes our presentation clear.In the last section,we discuss
the relationship between the ontologies and provide a
classification of them.
2.1 Software Process Ontology
Software engineering is a complex process.Inexperienced
engineers may be unclear about their tasks,their goals,and
the processes they should follow.Awell-defined,complete,
and disciplined process can be quite helpful for them.On
the other hand,experienced engineers or managers may
have different opinions about the project plans or processes,
which causes conflicts.A well-defined process serves as a
standard when there is a disagreement.In addition,since it
becomes common that collaboration and cooperation are
needed between software teams at different physical
locations,communication becomes even harder.To im-
prove the communication,process can be modeled and
shared on the Web.The Semantic Web techniques also
allow process automation,dynamic assembly and tailoring
of process elements,formal reasoning and query about
activity specifications,and reusable work products.It
creates the opportunity to measure the process usage,
ensures the process conformance,and suggests future
process improvement options [19].
Ontology 1.Software process ontology [28],[19],[33],which
defines software activities,process phases,and existing
process models.Each process phase can be defined by a
sequence of activities,and each process model can be
defined by process phases.In addition,each activity can
be associated with software artifacts it produces.The
structure of the ontology can be illustrated by Fig.1.
In Fig.1,each oval with solid border represents a
concept,each directed line represents a relationship
between two concepts,and the text on the line denotes
the type of the relationship.Instead of a concrete concept,
Fig.1.Partial software process ontology.
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.
an oval with dashed lines represents an ontology,which can
be seen as a metaconcept.These ontologies are connected to
other concepts/metaconcepts by dashed lines with arrow
heads.The reason that these ontologies are included in this
figure will be explained in Section 2.11.For simplicity,some
information has been omitted in Fig.1.For example,the
lines that do not have attached text represent the subClassOf
relationships.The relationship that the WriteCode activity
produces the Code artifact is not displayed in the figure.
Building ontology is not an easy task,which involves the
selection of appropriate concepts and semantic relations.In
order to achieve high-quality process ontology,existing
software process models and related information have to be
studied.The international standards of software process
models,such as CMMI and ISO/IEC 15504,are good
resources [28].By learning and comparing the basic
components and activities in the standard process model,
slight differences betweenthe models canbe found.Different
standards are defined by using different set of terms.The
terms from two vocabularies may have the same meaning,
whereas the same term in two vocabularies may represent
different meanings.Thus,the vocabulary sets cannot be
simply combined.To establish a complete process model,a
mapping has to be created for each pair of items that share
the same meaning.In this way,the overlapping part of the
standards as well as the different part canbe identified,anda
complete set of concepts can be achievedafter combining the
concept sets and filtering out the duplicate concepts.
Besides CMMI model and ISO/IEC1554 model,there are
many other standard process models.Variation exists
among these models which cannot be covered by one
process ontology.It is proposed to have a general process
ontology,which can be extended to cover different existing
models [28].In addition,there are more various process
models created by different software teams by tailoring the
standard models to serve their own needs.Accordingly,the
general process ontology can be tailored to project-specific
process ontology [38] which defines rules and logic within a
specific application development project.Comparing to the
general ontology,which has a broader application scope,
the project-specific ontologies are applicable to fewer
development processes and within smaller communities.
More discussions about the ontology application scopes can
be found in Section 2.11.
2.2 Domain Ontologies
Domain engineering is the process of defining a scope for
software application domain,analyzing the important
concepts within the domain and their relationships,
specifying the domain structure,and building the reusable
components.Domain engineering collects useful informa-
tion within a specific domain,which can be maintained and
reused in future application development in the same
domain.Reusing domain information may reduce time and
save the effort of gathering information.The following
ontologies related to domain information can be created.
Ontology 2.Application domain ontology [1],[4],[8],[17],[33],
whichrepresents the knowledge of anapplicationdomain
and the business information required for building
software applications ina specific domain.It also includes
the semantic relationships established among their con-
cepts froma real-world domain point of view.
Systems in the same domain share common features.
Software features differentiate software applications in
different domains as well as their engineering processes
[36].Capturing common features for domain applications
facilitates the domain engineering as well as softwareengineering.
Ontology 3.Application domain feature model ontology,which
models the features of software systems in the same
application domain.In addition,it maintains the
relationships between features,such as mandatory,
optional,alternative,or,requires,and excludes [36].
2.3 Requirement Ontology
Requirement specifications arethedescriptions of thedesired
software characteristics specified by the customer.There are
twotypesof requirements:functional requirements(FRs) and
nonfunctional requirements (NFRs).Each FR can be viewed
as a sequence of behaviors/actions that the systemperforms
under a particular context [8].On the other hand,NFRs
represent the quality-related characteristics of a system.
Ontology 4.System behavior ontology [8],which models
system behaviors,the actions that system performs
under certain scenarios.The main concepts of this
ontology include event,action,reservation,etc.Relation-
ships include making agreement,making reservation,etc.
2.4 Architecture and Design Ontologies
Software architecture is a description of the systemcompo-
nents and how they interact with each other at a high
abstraction level.There are some common architecture
styles,such as pipe and filter,data abstraction and object-
oriented organization,and layered systems.Each architec-
ture style includes a set of components andtheir interactions.
It has some constraints on its components as well as on the
interactions between the components.In addition,each style
has its advantages and disadvantages.In order to formally
specify the architecture styles,software-architecture-related
information can be defined by the following ontology.
Ontology 5.Software architecture ontology [23],which models
architecture-related concepts,such as architectural
styles,components that are required in each architectural
style,and their interactions.
A number of modeling techniques have been proposed
to facilitate the software design.For example,the control
flow diagram (CFD) can be used to model the execution
flow of a system;the data flow diagram(DFD) can be used
to model data processing systems visually.Petri nets can be
used to model discrete distributed system by describing
places and transitions.In addition,state diagram together
with preconditions and postconditions can also be used to
model the behavior of software systems.Such modeling
techniques and their related concepts can be defined in the
application logic ontology.
Ontology 6.Application logic ontology [13],which defines
concepts that are used to model the logic behind the
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.
application behaviors.For example,CFD concepts,such
as asynchronous calls,synchronous calls,fork,and
merge,could be included in this ontology.
Object-oriented programming languages have been
adopted in many software applications.UML is a good
modeling language for object-oriented software system.The
following ontology can be built to catch the information in
UML diagrams.
Ontology 7.Object-Oriented design ontology [11],[22],which
defines the vocabulary for describing object-oriented
software designs.The concepts in this ontology includeclasses,interfaces,methods,and attributes.The relationships
include inheritance,realization,etc.
2.5 Pattern Ontology
Software patterns capture expert experience and document
flexible designs and development that may change over
time [16].Currently,there are several kinds of patterns,
such as Gang of Four (GoF) design patterns,usability
design patterns,and Web application patterns.GoF design
patterns [16] provide experienced design practices for
object-oriented software application.Usability patterns
[20] have been used to distribute usability knowledge and
ensure a degree of consistency across applications.Web
application patterns describe the experience of recurring
problems in Web applications [25].
Patterns are usually described in natural languages or
diagrams.Since the definition is informal,there are a
number of variants for each design pattern.Developers
apply design patterns according to their own understand-
ing.Researchers discover design patterns from existing
software source code based on their own interpretation.
Thus,there is a demand for the formal definition of patterns.
The Semantic Web techniques,such as OWL and RDF,
can be used to formally describe the patterns [11],[12].
Using OWL and RDF,a pattern definition itself can be an
instance of the OWL class represented by a set of RDF
statements.The characteristics of a pattern,such as the
problem it solves,the solution it provides,the context it is
used,and the alternatives,can be defined through RDF
properties.Each pattern consists of several participants.For
example,a design pattern usually involves several classes
which interact with each other.These participants can also
be represented as OWL classes and be associated with the
pattern.Thus,the following ontology can be defined.
Ontology 8.Pattern ontology [20],[21],which aims at
providing a catalogue for patterns,including software
design patterns,usability patterns,Web application
patterns,etc.Patterns are defined as OWL concepts
and are placed as subconcepts of their corresponding
categories.The patterns are connected with their
participants by the hasParticipant relationship.The de-
sign of this ontology can be illustrated by Fig.2.
Although the pattern ontology is not completely defined,
we illustrate the idea of providing a unified pattern
repository.Kamthan and Pai [25] try to define the ontology
for Web Application Patterns (OWAP),which can be included
as a subclass of the SoftwarePatterns.
2.6 Implementation Ontologies
Software development process requires a large amount of
information and produces a large number of software
artifacts.When information is not well organized,and
thus,becomes unsearchable or irretrievable,it becomes
useless.Therefore,it is necessary to organize the
information in an easy-to-retrieve manner.Defining the
following ontologies helps to organize the artifacts
produced during implementation.
Ontology 9.Software artifact ontology [1],[4],[17],which
provides a set of concepts that permit the classification of
different artifacts according to their formats and internal
structures,such as text files,diagrams,maps,images,
tables,and code,or according to their types,such as
source code,design,and documentation.The ontology
also includes artifact-related concepts,such as person,
who might be the creator,and project,where an artifact
might be produced.
As discussed in the previous section,object-oriented
programming languages are commonly used in software
industry.Object-oriented source code ontology can be
created so that source code can be organized along with
it.The difference between this ontology and the object-
oriented design ontology is that this ontology involves more
programming language constructs which are not used in
the design,such as method parameters and local variables.
Ontology 10.Object-oriented source code ontology [26],[37],
[39],which is designed to formally specify major
concepts of object-oriented programming languages.
The concepts of this ontology include package,class,
Software process is iterative,in which the software
artifacts keep improving and updating.In the process,there
might be several versions created for each artifact.It is a
complex activity to manage the versions.The following
ontology can be created,according to which versions of files
can be organized.
Ontology 11.Version ontology [26],which aims at modeling
the relationships between files,releases,and revisions of
software projects.The relationships in this ontologyinclude hasRevision,isReleaseOf,etc.For example,a file
whichhas anumber of revisions shouldbeconnectedwith
the corresponding revisions using hasRevision relation-
ship.At some point,the software is relatively stable and
ready to be publishedas a newrelease.The release should
Fig.2.Part of pattern ontology.
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.
containall the revisions made until that point.Inthis case,
the release is connected with its corresponding file
revisions by using the isReleaseOf relationship.
Software component configuration is an activity to keep
track of version changes and various dependency con-
straints imposed on the system.Dependencies between
components include AND dependency and OR depen-
dency.For example,component A may depend on either
component BOR component C.Component Dmay depend
on both component E AND component F.Version
restrictions specify the range of versions of a component
that works with the range of versions of another compo-
nent.For example,there are situations such that componentA version m works well with component B version n.
Nevertheless,the mþ1 version of A may be incompatible
with version n of Banymore.The following ontology can be
created to facilitate the configuration between components.
Ontology 12.System configuration ontology [31],a model for
component constraints and version restrictions.Nor-
mally,each system has its own configuration ontology.
2.7 Documentation Ontologies
Documentation is one of the important ways to commu-
nicate and share information.However,documentation is a
tedious task.To provide some assistance to this task,it is
desired that information that is expected to be documented
can be collected and transformed into text format auto-
matically.Thus,during the development process,the
valuable information can be collected and defined in the
documentation ontology.
Ontology 13.Documentation ontology [37],[39],[10],which
consists of a large amount of concepts that are expected
to appear in the content of software documents.These
concepts are based on various programming domains
and design decisions.
A large number of documents are produced to record
different types of information.For example,there are
documents recording customer-related contents,documents
describing the software artifacts,documents providing
guidelines for the development or testing tools,and
documents recording the process information related to
schedule,cost,and task breakdown structure [32].To
organize generated documents and maintain a historical
overviewof the document revisions,the following ontology
can be developed.
Ontology 14.Document ontology [10],which models docu-
ment types and their relationships.The relationshipsinclude useTemplate,related,refinedIn,update,etc.For
example,a document written according to a template
document can be connected to the template by theuseTemplate relationship.The newversion of a document
can be connected to the previous versions of the same
document by the update relationship.
The difference between the document ontology and the
documentation ontology is that the document ontology
aims at organizing documents,whereas the documentation
ontology aims at organizing information recorded by
documents.They differ in their intentions and application
scopes.Besides,the concepts and restrictions defined in the
two ontologies are different.
2.8 Quality Ontologies
Software quality can be measured along the following
software attributes:capacity,usability,performance,relia-
ing and measuring quality help to learn the current status of
a systemand identify the aspects that need to be improved.
Currently,the most widely used software quality measure-
ment tools are the Ishikawa’s seven basic tools,Pareto
diagram,histogram,scatter diagram,run chart,control
chart,and cause-and-effect diagram.To improve software
product quality and satisfy customer needs,there have been
developed quality models and standards,such as ISO 9001,
Capability Maturity Model (CMM),and ISO/IEC 9126.
Therefore,defining the quality concepts requires studying
the existing quality models and constructing a superset.The
same method as discussed in Section 2.1 can be applied.
Thus,the following ontology is constructed.
Ontology 15.Quality ontology [3] (also called feature
ontology [13]),represents reusable knowledge about
different quality characteristics,subcharacteristics,and
metrics.The basic structure of this ontology can be
illustrated in Fig.3 where the edges represent thesubClassOf relationship.
Asoftware systemis considered to be of high quality if it
satisfies customer requirements and fits the use [29].
Software testing is the activity to assess the attributes of a
software system and determine whether it meets the
functional requirements and quality requirements before
deployment.During the testing process,defects can be
identified.For example,in testing phase,a tester may find a
function failed to be provided.Another example is that
during the market early trial of the software product,
customers may request some changes which are sent to the
engineers.Resolving a defect involves the communication
between several parties.To improve the management of
software testing,the following ontologies can be defined.
Ontology 16.Testing ontology [40],which defines concepts
related to testing,such as tester,environment,context,
artifact onwhichthe testing is performed,testing method,
and activity.Each concept is further refined by introdu-
cing more subconcepts.For example,testing contexts
include unit testing,integration testing,system testing,
regression testing,etc.Activity includes planning,test
Fig.3.Partial quality ontology.
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.
case generation,execution,validation and verification,
etc.The relationships in the ontology include subsume
relation between testing methods,compatible-with relation
between artifacts format,enhance relation between envir-
onments,include relation between activities,temporal
ordering between activities,etc.
Ontology 17.Defect ontology [26],which defines the
concepts used to describe the defects detected during
the software testing phase.It includes the concepts suchas defect,action,person,and comment.Relationships
include discover,assignedTo,hasBehavior,requiresBehavior,
etc.For example,a tester who discovers and reports a
defect should be connected by the discover relationship
with the defect.The discovered defect will be assigned to
a developer by using the assignedTo relationship.A
defect usually means the system presents different
behaviors from what have been required by customers.
The defect can be associated with its current behavior
using the hasBehavior relationship and its desired
behavior using the requiresBehavior relationship.A defect
is usually discovered in one revision of the source code
and resolved in another revision so that it should be
associated with the corresponding revisions (defined in
Ontology 11) by the isDiscoveredIn and isResolvedIn
2.9 Maintenance Ontology
Software maintenance is the activity of modifying the
system after delivery,so as to correct faults,improve
performance,or adapt the system to a new environment.It
is a complex task that involves system understanding,
maintenance planning,etc.Software maintenance process
models need to be defined to facilitate the task [30].In
addition,concepts involved in this task can be modeled by a
maintenance ontology.
Ontology 18.Software maintenance process ontology [2],which
provides maintenance-related concepts and their rela-
tionships.The concepts include activity,person,procedure,
resource,etc.The activities are,for example,maintenance
activity,management activity,modification activity,etc.
People involved in maintenance process include main-
tenance engineer,maintenance manager,customer,etc.
The relationships include uses which connect a proce-
dure with its corresponding activities,performs which
connect a maintenance engineer with the maintenanceactivities,negotiates-with which connects maintenance
manager and customers,etc.
2.10 Technology Ontology
A large number of technologies have been proposed for
software development.Development environments and
tools have been developed to automate or semiautomate
the software engineering process.For each software en-
gineering activity,there might be several candidates within
the large pool of technologies.Lacking knowledge about the
existing tools and technologies impacts the productivity of
software process.A technology ontology can be built to act
as a library,to provide engineers with possible information,
and to help engineers to pick up the most appropriate tools
or technologies for their specific needs.
Ontology 19.Technology ontology [13],[17],which is a
repository of software development technologies,envir-
onments,platforms,tools,etc.For example,program-
ming environments include J2EE,.Net,etc;application
servers include Tomcat,JBoss,etc;and Web Service
execution engines include BPEL-engines,XL-engine,etc.
2.11 Classification of Ontologies
We have introduced 19 software-engineering-related ontol-
ogies.We have discussed the background,the motivation,
and main contents of the ontologies.In this section,we
discuss the relationship between the ontologies and provide
a classification schema along which we classify them.This
work provides our reviews of the ontologies and our
categorization of the existing ontology-based approaches.
There are several ways to classify the software-engineer-
ing-related ontologies.For example,they can be classified
according to their related engineering phase,according to
the type of information they model,or according to their
application scope.
First,we classify ontologies according to their related
activities in different software engineering phases.Typical
software engineering phases include requirement engineer-
ing,architectural design,implementation,testing,and
maintenance,as presented in Fig.1.Since software process
ontology defines phases and activities,we use Fig.1 to
show the relationships between the ontologies and the
engineering phases and activities.For example,application
domain ontology and application domain feature model
ontology can be used to facilitate requirement elicitation,an
activity in requirement engineering phase;systembehavior
ontology can be used to facilitate requirement specification,
which is also an activity in requirement engineering phase;
software architecture ontology,application logic ontology,
object-oriented design ontology and pattern ontology can be
used to facilitate activities in architectural design phase;
software artifact ontology,object-oriented source code
ontology,version ontology,system configuration ontology,
document ontology,and documentation ontology are
related to activities in implementation phase;testing
ontology and defect ontology can help testing;and software
maintenance ontology can be used during maintenance.In
addition,there are some ontologies,such as software
process ontology,quality ontology,and technology ontol-
ogy,which are related to all different activities and not
shown in the figure.Since ontologies are not concrete
concepts,we treat themas metaconcepts and use ovals with
dashed border to denote them.The contributing ontologies
can be connected to the related activities by the facilitatedBy
relationship.However,this relationship connects metacon-
cepts.To differentiate it from the regular relationships,we
create a new type of relationship denoted by dashed line
with arrowhead.In addition to illustrating the relationships
by Fig.1,we use a table to summarize the classification.The
third column of Table 1 shows the classification of
ontologies according to their related software activities.
Second,we classify ontologies according to the type of
information they model.Some ontologies model informa-
tion related to processes,such as software process ontology
and software maintenance process ontology.Some ontolo-
gies model concepts within an application domain,such as
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.
application domain ontology and application domain
feature model ontology.Some ontologies,such as pattern
ontology and technology ontology,aim at providing a
library of standards and technologies.Some ontologies
model information related to software products,which
might be final products or intermediate products.The final
product refers to the software artifacts that are requested by
customers.The intermediate products refer to the software
artifacts that are not directly requested but are internally
produced along the product line.Example ontologies that
model product-related information are system behavior
ontology,software architecture ontology,software artifact
ontology,system configuration ontology,etc.Some ontol-
ogies model information related to management and
support of the software engineering.Normally,such
information is also generated internally.For example,
version ontology,document ontology,quality ontology,
testing ontology,and defect ontology belong to this
category.We use this criterion to classify the ontologies as
shown in the fourth column of Table 1.
Third,we classify the ontologies according to their
application scopes.Some ontologies model concepts that
are common for almost all projects.For example,software
process ontology,system behavior ontology,software
architecture ontology,and pattern ontology are all generic,
which means they can be used in almost any software
engineering processes.In addition,some ontologies,such as
application domain ontology and application domain
feature model ontology,are domain-specific.These types
of ontologies can be applied only to projects within the
domain being modeled.Furthermore,some ontologies are
only applicable to projects that use object-oriented program-
ming languages due to their main programming language.
For example,object-oriented design ontology and object-
oriented source code ontology belong to this category.
Finally,some ontologies are project-specific.For example,
in Section 2.1,we discussed project-specific process ontolo-
gies,which are extensions of the generic software process
ontology.They belong to this category.Systemconfiguration
ontology is mainly designed to capture constraints and
interrelationships between components of a system.Each
software system should have its own configuration.Thus,
this ontology is project-specific.Documentation ontology
consists of a large body of concepts that are expected to
appear in the content of documents.The information within
this ontology is mainly related to a specific project.We use
the last column of Table 1 to show the classification of the
ontologies following this criterion.
We summarize the software-engineering-related ontolo-
gies in Table 1.The order of the ontologies listed in this
table corresponds to the sequence of their occurrence in
Section 2.Columns 3-5 list our classification for the
ontologies along the three criteria mentioned above,
namely,the related software engineering activity,type of
information modeled,and application scope.3 SEMANTIC WEB APPLICATIONS IN SOFTWARE
Ontologies are used to formally express a shared under-
standing of a domain.As software engineering is a
sequence of activities that involve high amount of commu-
nication,it is better to have an agreement on the knowledge
shared among different parties.In the previous section,we
have described some software-engineering-related ontolo-
gies in the literature.In this section,we describe how these
ontologies and the Semantic Web technologies are used to
improve software engineering,i.e.,the software engineering
problems that can be solved or improved by the Semantic
Web technologies,the proposed approaches,and the
ontologies that are required in each approach.
Problems in software engineering can be categorized in
different ways.In this section,we categorize the problems
from two perspectives:the life-cycle perspective and the
critical issue perspective.From the life-cycle perspective,a
problem may exist in a particular software engineering
phase.On the other hand,there are certain critical issues
that might need to be handled throughout the entire life
Classification of Software-Engineering-Related Ontologies
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.
cycle.Through this categorization schema,the Semantic-
Web-based approaches on software engineering are also
categorized accordingly.
The rest of this section is organized in the following way.
Section 3.1 introduces problems fromthe life-cycle perspec-
tive and discusses how they can be improved by using the
Semantic Web technologies.Section 3.2 discusses certain
critical issues that have to be dealt with throughout the
entire engineering life cycle and introduces the Semantic-
Web-based solutions.
3.1 From Life-Cycle Perspective
Software engineering process can be divided into several
phases according to the main goal to be achieved from the
life-cycle perspective.The distinguishable phases of a
software engineering process include requirement engi-
neering,architectural design,implementation,testing,and
maintenance.In each phase,there are some ontologies that
can be applied and utilized to improve the phase.In the
following sections,we introduce the phases,discuss the
ontologies that benefit each phase,and present the Semantic
Web technologies that can be used.
3.1.1 Requirement Engineering Phase
Requirement Engineering (RE) concerns the real-world
goals for,functions of,and constraints on software systems.
It also concerns the relationship of the factors to precise
specification of software behavior and their evolution over
time and across software families [35].RE is a crucial phase
in software development since the quality of the require-
ments directly affects the quality of the entire project.
Requirement elicitation is an important activity in this
phase,which is to lead customers to state their expected
functionalities during interviews.It involves a good
communication between system analysts and customers.
Misleading or misinterpreting during the interviews may
cause incorrect,incomplete,and inconsistent requirements.
Therefore,it is important to improve the communication
and achieve an agreeable contract.Two ontologies can be
used to support the requirement elicitation:application
domain ontology and quality ontology [3].Both of them
suggest requirement analysts the questions that they should
ask during the requirement elicitation interview.
Application domain ontology records the important
information within the domain that is relevant to the
application.It is able to suggest the elicitation questions of
FRs,since FRs highly depend on the application domain
information.Quality ontology records the different aspects
of software qualities.It is able to suggest the NFRs
elicitation questions since NFRs are much more indepen-
dent from application domain and define quality-related
characteristics.The Semantic Web can be used to publish
the domain and quality information,using domain ontol-
ogy and quality ontology as the underlying vocabulary.
Services such as query and reasoning can be provided on
the Web.These Web services can help the software analysts
to learn about the application domain and quality char-
acteristics.It helps themto come up with a more reasonable
list of interviewquestions for requirement elicitation so that
they can be more active during the interview,elicit the
correct information,and thus,achieve high-quality require-
ment specification [3].
Use cases are proposedtomodel software requirements to
improve the understandability.They describe in a graphical
representation the systemoperation scenarios.Eachscenario
has its own context and contains actors,tasks,extension
points,sometimes preconditions,and postconditions.In the
development process of large software systems,there is a
large library of use cases.Retrieving a use case created in the
past is a complex and error-prone task.The Semantic-Web-
based approach can be used to solve this problem [8].Use
cases can be annotated with semantic information,such as
their context and the modeled system behaviors.A Web
service can be built to retrieve use cases based on their
semantic information.The application domain ontology and
systembehavior ontology can be used to support the query.
The quality of the requirements directly impacts that of
the software system.Requirement assessment is the activity
to measure the quality of the requirements and to discover
errors and potential issues.The task can be facilitated by the
domain ontology [24],[41],[42].Mapping between applica-
tion domain ontology and the requirement specification
items can be created,so as to establish the relationships
between requirement items according to the relationships
between the corresponding domain concepts.Thus,the
inference on the domain ontology enables the inference on
the requirement specification.A query service can be
provided which allows the errors,such as incompleteness
and inconsistency,to be detected through query.The three
typical errors in requirements are incompleteness,incon-
sistency,and ambiguity.Through the literature study,we
found that there are more approaches focusing on detecting
the inconsistencies than on incompleteness or ambiguity.
3.1.2 Software Design Phase
As software systems become larger and more complex,
software architecture and design are important for mana-
ging complexity and scalability.Due to constant changes
during the product life cycle,in addition,the design has to
be adaptable to changes and easy to extend.
Software patterns document expert experiences for
recurring problems.They provide guidance for software
design.Software pattern ontology provides a library of
commonly used patterns.The Semantic-Web-based ap-
proach facilitates the knowledge dissemination and en-
courages the engineers to study patterns.With the support
of the pattern ontology,query services can be provided on
the Web,which further makes the pattern training easier.
This approach broadens the community of pattern users.
Feature modeling is part of domain engineering as
systems in a domain share common features and also differ
in certain features.A feature model ontology describes the
common features and constraints for systems in the
domain.A specific system in a domain may have its own
set of features,which should be consistent with the
constraints defined in the domain feature model ontology.
Thus,feature model ontology can be used in Semantic-Web-
based approaches to provide design guidance [36].A Web
service can be provided to ensure the consistency between
the feature design of a system and the feature model
ontology for its application domain.
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.
3.1.3 Implementation and Integration Phase
Software implementation phase is when the source code is
written and data storage schema is designed.It involves a
large amount of effort in producing different kinds of
artifacts.Automating source code generation not only saves
time and effort,but also ensures the consistency and
establishes traceability.
Mapping can be established between application domain
concepts,object-orientedconcepts,anddata model concepts.
According to the mapping,a transformation approach can
be used to transform knowledge from the ontology to the
programming language so that source code could be
automatically generated from domain ontology [5],[6].In
addition,transformationcanalso be usedto derive relational
data models fromthe application domain ontology [5].
Software integration is the activity performed after the
implementation of individual component.It focuses on the
problem of integrating two or more software components
into a large system,given that they function properly
independently.The integrated system should satisfy the
combined requirements within the new environment.
Components should communicate with each other through
interfaces without any conflict.The components depend on
each other and there are usually certain constraints on their
dependencies.For example,version m of component A
requires version n,or above,of component B.The system
configuration ontology can be built to capture the informa-
tion about the component dependencies and version restric-
tions of the system[31].A Web service can be developed to
support the query and reasoning over the systemconfigura-
tions.Supported by the ontologies,the service enables the
validationof a givenintegrationto be checkedautomatically.
3.1.4 Software Testing Phase
As software systems continue to growin size and complex-
ity,it becomes harder to control the quality.Software
testing is an essential phase in software engineering,which
is performed after implementation to ensure the quality.
Software testing ontology is designed especially to model
testing tasks.Testing tasks are currently performed by
software programs.Approaches are proposed to develop
software agents to perform testing tasks.The communica-
tion and interaction between agents can be supported by the
software testing ontology [40].
The Semantic-Web-based approach can be built to detect
potential problematic areas from the source code [26].The
resource that needs to be analyzed in this case is the source
code.A query service can be provided with the object-
oriented source code ontology as the underlying vocabu-
lary.The query service should be able to answer the
questions such as whether many objects mutually know
each other and which classes contain methods with long
parameter lists.Such queries provide a hint that there might
be a problem around the classes involved in the query
results.Other queries may be able to tell whether the
problem could be solved.
3.1.5 Software Maintenance Phase
Software maintenance [35] describes activities that keep a
deployed software system functioning correctly.The
activities in software maintenance phase include the
modification of a software product to correct faults,to
improve performance,user-friendliness,or other attributes
of the system,to add extra functionalities,or to adapt the
product to a new or changing environment.
A Semantic-Web-based maintenance planning and man-
agement tool can be built to facilitate the maintenance
process [2].The tool can be supported by the software
maintenance ontology,which models maintenance-related
activities.The relationships between identified software
maintenance problems and appropriate activities can be
established so that it is able to provide guidance for software
maintainers to make correct planning and decisions.
As maintenance phase requires changes,there is a
demand for the automation of change propagation.Thus,
mappings between software artifacts can be established.For
example,requirements,tests,and metrics can be associated
with software components.In this way,once there is a
change request on a requirement item,the affected
components and test cases can be identified.A Semantic-
Web-based environment can be built to manage the soft-
ware artifacts and ensure the consistency between them
[22].The object-oriented design ontology,domain ontology,
test ontology,and quality ontology can be used as the
underlying vocabulary of the environment.Queries can be
performed to monitor the changes happening to the system.
In this way,the changes can be tracked and developers can
be notified when changes require actions.
Reverse engineering and system understanding are
normally required during systemmaintenance or evolution.
Software patterns help the system understanding by
providing the design intents.However,they are usually
not retrievable once transformed into source code.Pattern
discovery is an approach to get back the initial design
intents.Pattern discovery can be described as to find a piece
of systemthat satisfies the characteristics and constraints of
a pattern.Thus,the discovery is performed according to the
pattern definitions.As we have introduced,pattern ontol-
ogy defines all the patterns in a formal way,by using
ontology languages,such as OWL.Such pattern descrip-
tions are accessible by tools.If the system source code can
also be transformed into OWL or RDF format,the discovery
of patterns can be realized by query and reasoning system
properties according to the pattern definitions [11].
3.1.6 Summary
In this section,we discuss the Semantic-Web-based
approaches proposed for each software engineering phase.
We have introduced the ontologies that can be used to solve
each problem.Now,we summarize them in Table 2.
Table 2 shows the usage of ontologies insolving problems
related to different software engineering phases.Software
engineering phases are listed in the first row.Ontologies are
listed in the first column in the order of their occurrence in
Section 2.A cross mark in the table indicates that the
ontology has been used by some research work to solve
problems in the phase.The table shows that the application
domain ontology has been adopted by the most research
works to solve different problems.The table also suggests
that a broader range of ontologies have been used to support
software maintenance phase.A question mark in the table
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.
indicates that the ontology can be used to solve the problem
but there is no work on it yet.The question marks suggest
future work trends which will be discussed in Section 4.
3.2 From Critical Issues Perspective
There are some critical issues that are consideredthroughout
the software life cycles.For example,documentation needs
to be produced in every software phase;changes have to be
predicted so that the system will be adaptable;traceability
needs to be established;and quality has to be assured.These
issues have to be addressed to ensure the product quality
and process efficiency.The following sections introduce the
critical issues and discuss how the Semantic Web technol-
ogies can be applied to solve the issues.
3.2.1 Documentation
Documentation is a necessary activity during the entire
software process.Documents are critical artifacts in the
maintenance phase and reverse engineering phase,since it
helps the understanding of the software product.However,
documentation is a tedious work.Due to the complexity of
software systems and the tight schedule,documentation is
often omitted.To ease documentation and provide,to some
extent,automation of this activity,some of the ontologies,
such as software artifact ontology and application domain
ontology,can be used.
Software artifacts can be classified according to the
software artifact ontology.Relationships can also be estab-
lished between the software artifacts and domain ontology
concepts so that the software artifacts can be attached with
additional background information.Query services can be
provided so that information is easier to access.It provides
guidance for the documentation team and allows docu-
ments to be created with an integrated perspective.It also
helps to ensure the document to be consistent and up-to-
date along time as the system evolves [1].
3.2.2 Traceability
There are many artifacts developed in the software
engineering process.Sometimes,people may be confused
about the sources of the artifacts,i.e.,what causes the
artifacts to be produced.Without knowing the source,
engineers are not clear on the goal they are to achieve.
Establishing traceability for the software artifacts helps to
clarify the entire product line.
Semantic links are where the traceability is established.
For example,concepts in domain ontology can be asso-
ciated with requirement specification items [24],source
code [26],and software components [7].Requirement
specifications can be associated with software components
[22] and test cases.Software metrics and test cases can also
be associated with software components [22].Establishing
the semantic relations fills in the gaps between high-level
artifacts and low-level artifacts [23] as well as the commu-
nication gaps between different teams.
Traceability is also important information for the system
understanding during the maintenance phase.Usually,the
traceability information can no longer be found after the
deployment of a software system.Reestablishing traceability
can facilitate the system understanding [37],[39].Common
discovered and be associated with the concepts defined in
object-oriented source code ontology and documentation
ontology.Web-based queries can be performed to gather
information regarding the source code entities,design-level
concepts,andtheir occurrences indocuments.
3.2.3 Change Control
Change happens constantly in software systems.Change in
one part of the system may have impact on others.Even
small changes could result in disasters.Therefore,a good
strategy is to prepare for changes,instead of waiting until
they take place.Predicting future change benefits in the
sense that designers can create system designs that are
adaptable for the potential changes.
Application domain ontology should be a good knowl-
edge base for change prediction [24].Concepts and their
relationships in the domain ontology usually correlate with
items in the requirement specification;therefore,a mapping
can be established between them.Usually,there are a
number of existing projects for an application domain,and
thus,an effort can be made to study the evolution of
existing requirement specifications.Sometimes,it can be
found that certain types of requirement changes are
correlated with certain domain ontology relationships.
Thus,these types of relationships can be annotated that
they suggest certain types of requirement changes.In the
future projects,if a requirement itemmatches the annotated
ontology relationship,it is highly possible to perform the
predicted changes.
A main goal of design patterns is to design for changes.
Appropriately applying design patterns while program-
ming normally renders a well-structured,easy to under-
stand,easy to extend/change software system.Publishing
the library of software patterns on the Web allows the
training of the pattern knowledge much easier.It also
allows easy access to the pattern knowledge and promotes
the production of change adaptable code.
An automatic generation of source code fromthe domain
ontology by transferring knowledge from the ontology to
the programming language [6] has been discussed in
Usage of Ontologies to Support Engineering Phases
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.
Section 3.1.3.The transformation actually establishes the
mapping between domain concepts and the source code,
which makes change propagation easier.The Semantic Web
services can be provided to constantly check the consistency
between the domain model and the source code.It suggests
the areas of the code which requires changes accordingly
when the requirement changes.This ensures the synchro-
nization between domain model and the source code.It can
also suggest the amount of code changes required for a
model evolution,which allows the business to consider
whether to perform the evolution immediately,perform
later,or come up with an alternative.
When change is required,it is demanded to measure the
amount of change,so as to make a mature decision.
Regarding an object-oriented software project,all the Java
classes of one major release should be compared with those
of another major release,so as to visualize the code changes
within a certain time span in the software life cycle.To
analyze the changes according to the history of a single Java
class,it is necessary to calculate the class similarity between
each pair of immediate consecutive releases.The calculation
can be done for all classes,the result of which can be
plotted.Thus,the change amount of the entire project over
the entire life cycle can be presented.A Semantic Web
service can be provided to perform the calculation and
visualize the results [26].Object-oriented source code
ontology and version ontology can be used as the formal
knowledge base for the service.
3.2.4 Quality Control
Quality is one of the most important metrics of software
products.Software testing is the activity to ensure that the
product system delivers the desired functionality.In
Section 3.1.4,we have introduced how the Semantic-
Web-based approaches can be used for software testing.
In this section,we address other quality control aspects
that can be improved.
Software process model defines concepts related to
software activities and provides several commonly used
processes.A Semantic-Web-based process management
environment helps to achieve a process of high efficiency
[19].The formality of the underlying process ontology
allows the process automation,dynamic assembling,and
tailoring of process elements fromreusable process compo-
nents.It also allows the formal reasoning about activity
specifications and semantic-based searching for activity-
relevant standards and lessons learned.
A large number of artifacts are produced during the
engineering process.To achieve high quality,assessment
needs to be performed on each artifact.Especially,when the
artifacts produced in one phase are inputs to the next phase,
their quality directly affects that of other artifacts.Assessing
software artifacts before delivering them to the next phase
not only ensures the product quality,but also improves the
process efficiency.For example,requirement specifications
need to be measured before development and test cases
need to be measured before testing.Existing approaches
[24],[41],[42] on assessing requirement specifications have
been discussed in the last paragraph of Section 3.1.1.
Calculating software metrics is a way that quality can be
measured.In an object-oriented software system,it is not a
good practice to have objects that knowtoo much,i.e.,have
too many instance variables and methods.Thus,the
number of instance variables and methods can be calculated
as an indicator of the quality.With the support of object-
oriented source code ontology,a Semantic Web service can
be provided to perform the measurement [26].
Quality can also be measured by performing calculations
on the number of defects [26].A Semantic Web service can
be provided to perform the calculation.The service can be
supported by the object-oriented source code ontology,
defect ontology,and version ontology.It should be able to
suggest the problematic areas by calculating the number of
defects associated to each class.It should also be able to
calculate the defect density for each release,which is a good
indicator of the software quality over time.
3.2.5 Reuse
Information reuse saves the effort and time in software
engineering process.Acritical step for reuse is the informa-
tion retrieval,which acquires the desired knowledge.Since
the Semantic-Web-based approach attaches semantic infor-
mation to the information resources,it is able to provide the
context-based search in addition to the keyword-based
search.Since most software artifacts have more complex
internal structures than the text format,the Semantic-Web-
based approaches have greater retrieving ability.
In a Semantic-Web-based information retrieval environ-
ment,software artifacts,such as specification documents,
design diagrams,and source code,can be represented in
RDF,RDFS,or OWL format [4],[10],[17].The artifacts can
be further annotated by implicit and explicit metadata,and
indexed or classified according to the concepts defined in
the software artifact ontology and the domain ontology.The
use of these two ontologies empowers the search mechan-
isms and makes the retrieval easier.This enables the
context-based searching,which is more powerful than
keyword-based searching.
A software component is a piece of system that works
well independently.It can also be integrated with other
components to achieve more functionality.Components are
the most commonly reused software artifacts.Since there is
a large pool of software components,including the
commercial ones,it is a complex task to select the right
components.Similar to other software artifacts,RDF,RDFS,
and OWL can be used to specify the components according
to their UML specifications [27].This allows the component
repository to be shared through the Web.A Semantic-Web-
based environment can be provided for component char-
acterization,which helps to annotate the components so
that the components are easier to be retrieved.This
approach allows open-source software components to be
commented by experts worldwide.The characterization can
be done from different perspectives.From architecture
perspective [23],software components can be associated
with their satisfying architectural mechanisms and archi-
tectural policies.From application domain perspective,
components can be associated with their domain [7].In
this way,each domain concepts have certain associated
components.Thus,the domain concepts provide a uniform
view of the available components organized in domain
taxonomy.The characterization/annotation allows the
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.
searching of software components at the semantic level,
which is different from the traditional keyword-based
search or component-interface-based search.Architecture
ontology and domain ontology are required as the under-
lying vocabulary.
3.2.6 Technology Selection and Process Support
Software engineering is a complex process and requires the
assistance of existing technologies.There are a number of
tools,environments,and platforms provided for software
engineering.Usage of the suitable technology makes the
software engineering process easier.However,without the
knowledge of the existing technologies,it is difficult to
make a smart selection.
A Semantic-Web-based environment for technology
selection can be provided [13].Each tool can be treated as
a registered service.The tool can be annotated with its
application scope,its environment requirements,the types
of inputs it processes,and the formats of the outputs it
produces.Supported by the application logic ontology,
quality ontology,and technology ontology,query service
and tool composition service can be provided.For example,
if a tool is needed for a single task,a request can be
formulated accordingly.If a set of tools is needed for a
complex task,tools can be selected and composed.The
composition of the tools has to be done with the considera-
tion of the consistency between the inputs,outputs,
preconditions,and postconditions of two adjacent tools.
This allows a software engineering process supported by
tools to be planned automatically.
Knowledge-based software engineering environments
can be developed [15],[34] with the help of the Semantic
Web technologies.The environment may consist of multi-
layers,such as the ontology data layer and the application
service layer.The ontology data layer contains the
ontologies,such as software process ontology,quality
ontology,and software artifact ontology.The application
service layer includes the software agents which perform
independent tasks.The tasks include interpreting requests
from end users,breaking requests into subtasks and
delegating to other agents,formulating queries,reasoning,
etc.These agents cooperate with each other to provide help
for different software engineering tasks,such as software
process definition,risk estimation,and object modeling.
3.2.7 Summary
In this section,we discussed the critical issues in software
engineering that can be improved by using the Semantic-
Web-based approaches.We have introduced the ontologies
that can be used to solve the issues.
Table 3 shows the usage of ontologies by different
approaches to solve or improve critical issues.Critical
issues of software engineering are listed in the first row.
Ontologies are listed in the first column in the order of their
occurrence in Section 2.A cross mark in the table indicates
that the ontology has been used to solve the issue.The table
shows that the application domain ontology has been used
broadly to improve different areas of software engineering.
Quality control is a general task that may involve a greater
number of ontologies.Aquestion mark in the table indicates
that the ontology can be used to solve the issue but there is
no research on it yet.The question marks suggest future
work trends which will be discussed in Section 4.4 DISCUSSIONS
In the previous sections,we discussed the existing
approaches for the Semantic-Web-based software engineer-
ing.The main goal of these approaches is to better manage
the information.There used to be less help for the software
engineers to access the needed information from the large
amount of information or to understand the information.By
using Semantic Web techniques,the information within the
software community can be formalized,the level of
information reusability can be increased,and the accessi-
bility and availability of information can be improved.On
the other hand,such approaches also have some draw-
backs.For example,ontologies definition is a difficult task.
The development of Semantic Webs and services requires
time and effort.However,once the ontologies are defined
and services are built,they can be reused many times,and
thus,bring tremendous benefits.Continuing effort has been
put in Semantic Web area.The growth of the Semantic Web
technologies will further improve the Semantic-Web-based
software engineering.As more powerful tools being built
and better standards being defined,they will be adopted to
improve the Semantic-Web-based software engineering.
In the following sections,we discuss some of our
observations during our study of the literature.
4.1 Ontologies
In Section 2,we provide a list of ontologies that are
beneficial for software engineering.The generation of the
list is based on the existing works on building ontologies for
software engineering.By observing the ontologies list,we
found that the ontologies can be built at different abstrac-
tion levels.For example,the pattern ontology is a library of
patterns,which provides the information for individual
patterns.On the other hand,the OO design ontology
Benefits of Ontologies to Critical Issues
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.
models the object-oriented design concepts.Design patterns
can be described by object-oriented concepts,and the
relationships of which should conform to the OO design
ontology.Since the OO design ontology defines the
constraints for the description of design patterns,it can be
considered as a metaontology for design pattern ontology.
A software system contains a large amount of informa-
tion,which can be modeled by ontology.For example,the
design of an object-oriented system,which is usually
modeled by UML diagrams,can also be modeled by
ontology.Such ontology is here referred to as project-
specific design ontology.In UML,a model usually can be
defined by a metamodel.This means that the design of an
object-oriented system must conform to the UML metamo-
del,which represents the object-oriented design principle.
Similarly,a project-specific design ontology should also
comply with the object-oriented design principle,whose
definition can be found in the OO design ontology.
Therefore,the OO design ontology can be seen as the
metaontology for any project-specific design ontology.
Some of the ontologies defined in Section 2 are metalevel
ontologies,such as OO design ontology and OO source
code ontology.Because of the complexity of building
ontologies,only reusable ontologies are worth building.
metalevel ontologies can be reused as rules and guidance
for knowledge-driven software engineering processes.Since
they not only provide a formal definition,but also provide a
way for software agents to learn and understand,they
become foundations for the Semantic-Web-based software
engineering environment.Although ontologies can be built
for individual projects,they are not reusable;thus,it is not
wise to do so.
There are several existing standards to create ontologies
nowadays.The most popular and mature ontology devel-
opment language is OWL.There are a number of tools
created for OWL.To name a few,Prote
and SWOOP are
OWL editors;FaCT++,Pellet and Racer are Reasoners for
OWL;and Jena and OWL API are programming environ-
ments for building Semantic Web applications.Table 4 lists
some supporting tools for OWL.Only the most popular
ones,which are employed by the researches studied in this
paper,are listed.Another emerging language for ontology
definition is Web Service Modeling Language (WSML),
which is intended for handling Web services.However,
this language is not mature enough.The language itself has
not been defined completely and there are less supporting
tools.We only found WSMO Studio and WSMT as WSML
editors and WSML DL Reasoner as a plug-in for reasoning.
To the best our knowledge,there is no integrated
programming environment for WSML yet.Comparatively,
OWL is more preferable.The evaluation of the usage of
WSML as ontology language to solve software engineering
problems can be a future direction.
4.2 Current Approaches and Future Directions
We introduced the application of the Semantic Web
technologies in different areas of software engineering in
Section 3.The discussions include the current research state
inthis area.For example,there are more works onimproving
requirement engineeringthanothers.Almost everyapproach
discusses certaincritical issues that canbe addressedbytheir
approach.In this section,we discuss some issues and point
out some potential research directions.
Semantic-Web-based component characterization,dis-
cussed in Section 3.2.5,focuses on the open-source software
systems,which can be accessed and studied publically.
Proprietary systems,however,are not publically accessible
and can only be characterized by a limited number of
people.Therefore,this approach cannot benefit from
receiving comments on proprietary system from world-
wide.However,this approach can be used to get comments
fromengineers who develop the systemand existing users,
and to deliver the opinions to other potential users.
There are a number of existing resources that assist
software design.In addition to patterns,common architec-
tural styles serve as design guidelines.They help to achieve
better high-level software architecture.Furthermore,exist-
ing design and modeling languages,such as UML,helps to
visualize software design so as to improve communication.
In the future,the Semantic Web can be used to publish
architectural styles and knowledge about existing modeling
languages to encourage the dissemination of architecture
and design knowledge.
Documentation ontology consists of a large body of
concepts related to the software system.Any information
that is expected to appear in the content of software
documents goes into this ontology.Such information
includes domain knowledge,design decisions,etc.In the
future,the documentation ontology can be used to help
automating the documentation process.Relationships can
be established between the concepts in the documentation
ontology and the software artifacts ontology.With the
support of the ontologies,Semantic Web service may be
developed to generate documents automatically from
existing resources.
Automatic generation of source code fromdomain model
helps to ensure the consistency between them.When there is
a change in the domain model,update of source code is
required.Applying the same approach to the automatic
update of requirement specification can be a future work.
With the mapping established between the application
domainontology concepts andthe requirement specification
items,any change of the domain ontology can be populated
to the requirement specification,or at least a notification
about the change request can be sent to the engineers.
Concerning assessment,the Semantic Web technologies
are good at detecting inconsistency.However,there are
other types of errors,such as incompleteness and ambiguity
in requirement specification.Checking incompleteness and
ambiguity can be another future work.The idea is to
provide one-many mapping between domain ontology
concepts and requirement specifications.Every concept in
the domain ontology shall be able to map to the require-
ments;otherwise,incompleteness is detected.In addition,
Ontology Languages and Tools
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.
the Semantic-Web-based approaches provide formal ontol-
ogy as a definition for domain concepts.Every concept in
the requirement specification is able to find its formal
definition in the domain taxonomy.Thus,such approaches
help to avoid ambiguity.
Another possible work is to use quality ontology to
perform assessment of software artifacts along some
predefined metrics.The quality ontology is an important
source where metrics can be found.A Web service can be
provided to measure software artifacts according to
different metrics that are defined in the quality ontology.
This service may also require the support of other
ontologies,such as source code ontology and software
artifact ontology.5 CONCLUSIONS
There are many discussions and suggestions about improv-
ing software engineering process by using ontology and the
Semantic Web techniques.To the best of our knowledge,
there is no classification or assessment on these approaches
yet.Our goal in this paper is to provide a reviewon current
status of this field.
We discussed the ontologies proposed by different
research works.For each ontology,we identify its back-
ground and motivation as well as present what need to be
modeledbythe ontology.We provide a classificationschema
to further categorize the ontologies.Our review and
classificationof ontologies provide a clear viewof the current
state of the ontology development for software engineering.
We study the Semantic-Web-based approaches on im-
proving software engineering processes.We categorize the
approaches based on the engineering phases and the critical
issues they can be applied.We analyze the usage of
ontologies in different approaches.This work provides a
comprehensive view on the current approaches proposed
for software engineering,by presenting which area has been
fully covered and which has not.We also suggest future
research directions in this field.REFERENCES
[1] A.P.Ambro´sio,D.C.de Santos,F.N.de Lucena,and J.C.de Silva,
“Software Engineering Documentation:An Ontology-Based Ap-
proach,” Proc.WebMedia and LA-Web Joint Conf.10th Brazilian
Symp.Multimedia and the Web Second Latin Am.Web Congress,
[2] A.April,J.-M.Desharnais,and R.Dumke,“A Formalism of
Ontology to Support a Software Maintenance Knowledge-Based
System,” Proc.18th Int’l Conf.Software Eng.and Knowledge Eng.,
[3] T.H.Al Balushi,P.R.F.Sampaio,D.Dabhi,and P.Loucopoulos,
“Performing Requirements Elicitation Activities Supported by
Quality Ontologies,” Proc.18th Int’l Conf.Software Eng.and
Knowledge Eng.,pp.343-348.July 2006.
[4] B.Antunes,P.Gomes,and N.Seco,“SRS:A Software Reuse
System Based on the Semantic Web,” Proc.Third Int’l Workshop
Semantic Web Enabled Software Eng.,June 2007.
[5] I.N.Athanasiadis,F.Villa,and A.-E.Rizzoli,“Enabling
Knowledge-Based Software Engineering through Semantic-
Object-Relational Mappings,” Proc.Third Int’l Workshop Seman-
tic Web Enabled Software Eng.,June 2007.
[6] M.V.Bossche,P.Ross,I.MacLarty,B.V.Nuffelen,and N.Pelov,
“Ontology Driven Software Engineering for Real Life Applica-tions,” Proc.Third Int’l Workshop Semantic Web Enabled Software
Eng.,June 2007.
[7] R.M.M.Braga,M.Mattoso,and C.M.L.Werner,“The Use of
Mediation and Ontology Technologies for Software Component
Information Retrieval,” Proc.Symp.Software Reusability:Putting
Software Reuse in Context,pp.19-28,2001.
[8] J.C.Caralt and J.W.Kim,“Ontology Driven Requirement Query,”
Proc.40th Ann.Hawaii Int’l Conf.SystemSciences,p.197c,Jan.2007.
[9] J.Davies,R.Studer,and P.Warren,Semantic Web Technologies:
Trends and Research in Ontology-Based Systems.Wiley,July 2006.
[10] B.Decker,E.Ras,J.Rech,B.Klein,and C.Hoecht,“Self-Organized
Reuse of Software Engineering Knowledge Supported by Seman-
tic Wikis,” Proc.First Int’l Workshop Semantic Web Enabled Software
[11] J.Dietrich and C.Elgar,“A Formal Description of Design Patterns
Using OWL,” Proc.Australian Software Eng.Conf.,pp.243-250,
[12] J.Dietrich and C.Elgar,“Towards a Web of Patterns,” Proc.First
Int’l Workshop Semantic Web Enabled Software Eng.,2005.
[13] U.Dinger,R.Oberhauser,and C.Reichel,“SWS-ASE:Leveraging
Web Service-Based Software Engineering,” Proc.Int’l Conf.Soft-
ware Eng.Advances,2006.
[14] J.Dong,R.Paul,and L.-J.Zhang,“High Assurance Service-
Oriented Architecture,” Computer,vol.41,no.8,pp.22-23,Aug.
[15] R.A.Falbo,F.B.Ruy,and R.D.Moro,“Using Ontologies to Add
Semantics to a Software Engineering Environment,” Proc.17th
Int’l Conf.Software Eng.and Knowledge Eng.,pp.151-156,2005.
[16] E.Gamma,R.Helm,R.Johnson,and J.Vlissides,Design Patterns:
Elements of Reusable Object-Oriented Software.Addision-Wesley,
[17] H.-J.Happel,A.Korthaus,S.Seedorf,and P.Tomczyk,“KOntoR:
An Ontology-Enabled Approach to Software Reuse,” Proc.18th
Int’l Conf.Software Eng.and Knowledge Eng.,pp.349-354,July 2006.
[18] H.-J.Happel and S.Seedorf,“Applications of Ontologies in
Software Engineering,” Proc.Second Int’l Workshop Semantic Web
Enabled Software Eng.,2006.
[19] J.S.Hawker,H.Ma,and R.K.Smith,“A Web-Based Process and
Process Models to Find and Deliver Information to Improve the
Quality of Flight Software,” Proc.22nd Digital Avionics Systems
Conf.(DASC ’03),vol.1,pp.12-16,Oct.2003.
[20] S.Henninger and P.Ashokkumar,“An Ontology-Based Infra-
structure for Usability Design Patterns,” Proc.First Int’l Workshop
Semantic Web Enabled Software Eng.,Nov.2005.
[21] S.Henninger and P.Ashokkumar,“An Ontology-Based Metamo-
del for Software Patterns,” Proc.18th Int’l Conf.Software Eng.and
Knowledge Eng.,2006.
[22] D.Hyland-Wood,D.Carrington,and S.Kaplan,“Toward a
Software Maintenance Methodology Using Semantic Web Tech-niques,” Proc.Second Int’l IEEE Workshop Software Evolvability,
[23] P.Inostroza and H.Astudillo,“Emergent Architectural Compo-
nent Characterization Using Semantic Web Technologies,” Proc.
Second Int’l Workshop Semantic Web Enabled Software Eng.,Nov.
[24] H.Kaiya and M.Saeki,“Ontology Based Requirements Analysis:
Lightweight Semantic Processing Approach,” Proc.Fifth Int’l Conf.
Quality Software,pp.223-230,2005.
[25] P.Kamthan and H.-I.Pai,“An Experience in Ontological
Representation of Web Application Patterns for the SemanticWeb,” Proc.First Int’l Workshop Semantic Web Enabled Software Eng.,
[26] C.Kiefer,A.Bernstein,and J.Tappolet,“Analyzing Software with
iSPARQL,” Proc.Third Int’l Workshop Semantic Web Enabled
Software Eng.,June 2007.
[27] A.Korthaus,M.Schwind,and S.Seedorf,“Leveraging Semantic
Web Technologies for Business Component Specification,” J.Web
Semantics:Science,Services and Agents on the World Wide Web,vol.5,
no.2,pp.130-141,June 2007.
[28] L.Liao,Y.Qu,and H.K.N.Leung,“A Software Process Ontology
and Its Application,” Proc.First Int’l Workshop Semantic Web
Enabled Software Eng.,Nov.2005.
[29] S.H.Kan,Metric and Models in Software Quality Engineering.
[30] J.Rilling,Y.Zhang,W.J.Meng,R.Witte,V.Haarslev,and P.
Charland,“AUnified Ontology-Based Process Model for Software
Maintenance and Comprehension,” Proc.Workshop and Symp.at
Models in Software Eng.,pp.56-65,Oct.2006.
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.
[31] H.H.Shahri,J.A.Hendler,and A.A.Porter,“Software Configura-
tion Management Using Ontologies,” Proc.Third Int’l Workshop
Semantic Web Enabled Software Eng.,June 2007.
[32] I.Sommerville,Software Engineering,fourth ed.Addison-Wesley,
[33] S.Thaddeus and S.V.K.Raja,“Ontology-Driven Model for
Knowledge-Based Software Engineering,” Proc.18th Int’l Conf.
Software Eng.and Knowledge Eng.,pp.337-341,July 2006.
[34] S.Thaddeus and S.V.K.Raja,“A Semantic Web Tool for
Knowledge-Based Software Engineering,” Proc.Second Int’l
Workshop Semantic Web Enabled Software Eng.,2006.
[35] D.Van Edelstein,“Report on the IEEE STD 1219-993—Standard
for Software Maintenance,” ACM SIGSOFT—Software Eng.Notes,
[36] H.Wang,Y.F.Li,J.Sun,H.Zhang,and J.Pan,“Verifying Feature
Models Using OWL,” J.Web Semantics:Science,Services and Agents
on the World Wide Web,vol.5,no.2,pp.117-129,June 2007.
[37] R.Witte,Y.Zhang,and J.Rilling,“Empowering Software
Maintainers with Semantic Web Technologies,” Proc.Fourth
European Semantic Web Conf.,pp.37-52,June 2007.
[38] P.Wongthongtham,P.E.Chang,T.S.Dillon,and I.Sommerville,
“Software Engineering Ontologies and Their Implementation,”
Proc.IASTED Int’l Conf.Software Eng.(SE ’05),pp.208-213,Feb.
[39] Y.Zhang,R.Witte,J.Rilling,and V.Haarslev,“An Ontology-
Based Approach for Traceability Recovery,” Proc.Third Int’l
Workshop Metamodels,Schemas,Grammars,Ontologies for ReverseEng.,2006.
[40] H.Zhu and Q.Huo,“Developing a Software Testing Ontology in
UML for a Software Growth Environment of Web-Based
Applications,” Chapter IX of Software Evolution with UML and
XML,Idea Group,Inc.(IGI),2005.
[41] X.Zhu and Z.Jin,“Ontology-Based Inconsistency Management of
Software Requirements Specification,” Proc.31st Conf.Current
Trends in Theory and Practice of Computer Science,pp.340-349,Jan.
[42] X.Zhu and Z.Jin,“Inconsistency Measurement of Software
Requirements Specifications:An Ontology-Based Approach,”
Proc.10th IEEE Int’l Conf.Eng.of Complex Computer Systems,
[43] IEEE Std 610.12-1990,IEEE Standard Glossary of Software Engineer-
ing Terminology,IEEE,1990.
[44] Resource Description Framework (RDF),http://www.w3.org/
[45] SPARQL Query Language for RDF,http://www.w3.org/TR/
[46] Web Ontology Language OWL,http://www.w3.org/2004/OWL,2009.
Yajing Zhao received the BS degree in com-
puter science from Nankai University in 2005,
and the MS degree in software engineering from
the University of Texas at Dallas in 2007.She is
currently working toward the PhD degree at the
University of Texas at Dallas,majoring in soft-
ware engineering.Her research interests in-
clude software architecture and design,service-
oriented architecture,semantic Web services,
system modeling,and model transformation.
Jing Dong received the BS degree in com-
puter science from Peking University in 1992,
and the MMath and PhD degrees in computer
science from the University of Waterloo,
Canada,in 1997 and 2002,respectively.He
is an assistant professor in the Department of
Computer Science at the University of Texas
at Dallas.His research and teaching interests
include formal and automated methods for
software engineering,software modeling and
design,services computing,and visualization.He has had more than
100 publications in these areas.He is a senior member of the ACM
and a senior member of the IEEE.
Tu Peng received the BS and MS degrees
from the School of Mathematics,Peking
University,China.He is currently working
toward the PhD degree majoring in software
engineering at the Computer Science Depart-
ment,University of Texas at Dallas.His
research interests include formal modeling
and verification of software design,security,
services computing,and model checking.
Authorized licensed use limited to: IEEE Xplore. Downloaded on May 13,2010 at 11:43:27 UTC from IEEE Xplore. Restrictions apply.