Towards a Software Component Ontology
Alex Talevski
Digital Ecosystems and Business
Intelligence Institute (DEBII), Curtin
University of Technology
GPO Box U1987, Perth, WA, 6845,
Australia
A.Talevski@cbs.curtin.edu.au
Pornpit Wongthongtham
Digital Ecosystems and Business
Intelligence Institute (DEBII), Curtin
University of Technology
GPO Box U1987, Perth, WA, 6845,
Australia
P.Wongthongtham@cbs.curtin.
edu.au
Surasak Komchaliaw
Digital Ecosystems and Business
Intelligence Institute (DEBII), Curtin
University of Technology
GPO Box U1987, Perth, WA, 6845,
Australia
Maxtor_p@hotmail.com
ABSTRACT
Research has shown that component-based software engineering
leads to software that exhibits higher quality, shorter time-to-
market and therefore, lower development cost. However, the
development of component-based systems has been widely
plagued with problems surrounding the integration of third-party
components. Currently, software developers are forced to rely on
ambiguous definitions of a component’s services. There is no easy
to understand protocol for defining how third-party components
and component compositions are described and integrated into
systems. Most vendors specify their components’ services in a
proprietary or context dependant fashion. This makes it difficult
to clearly understand a component’s services, their use and their
operational pre and post conditions. Software Engineering
ontologies define common sharable software engineering
knowledge. They explicitly define software engineering concepts,
their relationships and their interactions. In this paper, we propose
a Software Component Ontology that specifically defines a
formal, explicit specification of a shared conceptualization in the
domain of software component engineering. We propose the use
of our software component ontology as the basis for the
development of future component compositions and component
based applications.
Categories and Subject Descriptors
D.2 [Software Engineering]: Software Component.
General Terms
Management, Standardization.
Keywords
Software Component, Ontology, Software Engineering.
1. INTRODUCTION
Large-scale systems account for the majority of all software
development undertakings [1]. Growing enterprises demand rapid
and frequent software development, maintenance, customization
and evolution. However, the software development industry tends
to develop large-scale systems that are monolithic, error-prone
and expensive [2][3][4]. Such systems normally evolve from an
uncoordinated build-and-fix pattern. A lack of a systematic
approach to large-scale software development has resulted in
many project failures [2][3][4]. Failures such as these can be
attributed to many factors relating to software development
complexity.
1.1 Software Complexity
Parnas [5] suggests that when a system is described by a
continuous function, it can contain no hidden surprises. Small
input changes should always cause correspondingly small changes
in outputs [6].
Software programmers, analysts, architects and testers can only
simultaneously comprehend seven chunks of information, plus or
minus two [7]. Therefore, the distinguishing characteristic of
large-scale software compared with the smaller variants is that it
is much more difficult to grasp. A large-scale software system
may have many variables that reside on multiple threads of
control. The collection of variables and various processes
represents the state of a software application. Discrete systems
may have a vast number of possible combinations that potentially
place a system in a new state. If an error is made as a result of
improper development reasoning, the state of the system may
change unpredictably.
1.2 Component based Software
Software complexity has plagued large-scale system development
projects. In particular, we have noticed that rapidly changing
requirements, diverse end-user bases, and the creation of extended
enterprises (collaborative development models) play a major part
in the necessity for simplified software development. Components
extend the existing object principles by strengthening the role of
an interface. A component interface separates the component
implementation from its interaction. It contains a collection of
operations and attributes that specify the services that a
component provides. Component-based software engineering is a
way of raising the level of abstraction for software development
so that software development can be simplified through a more
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
iiWAS2008, November 24–26, 2008, Linz, Austria.
(c) 2008 ACM 978-1-60558-349-5/08/0011 $5.00.
AIIDE 2008 Proceedings of iiWAS2008
503

coordinated divide and conquers approach to software problem
solving. This results in benefits such as:
x Reusability – Reusability removes dependencies on
development tools and languages, and allows the reuse
of already tested and certified components that are of
high quality and perform well.
x Productivity - When reusable artifacts are applied
throughout the software process, less time is spent
creating the plans, models, documents, code, and data
that are required to deliver a system.
x Quality - Ideally, a software component that is
developed for reuse would be verified to be correct, and
would contain no defects. As a component is reused,
defects are found and eliminated and its implementation
is refined.
x Cost - A reduction in cost results from less effort being
spent developing the software product. In addition, an
increase in software quality lowers software
maintenance costs.
Component-based approaches achieve loose coupling among
interacting software components where disparate components
interact using a common interaction protocol and architectural
constraints. By abstracting a component’s internals through an
interface, components become well isolated and standardized.
Component services are well-defined, self-contained, and do not
depend on the context or state of other services [8]. Therefore,
composite component architectures can be formed without
knowing the specific implementation details of a particular
service. This allows specialized component developers to focus
on their areas of expertise while ignoring other complexities and
continually refining component quality and performance. These
components are then guaranteed through their interface definition
and acquired as building blocks.
1.3 Component Tailorability
Tailorability is a formal concept which defines how generic
software can satisfy the specialized, rapidly changing, unclear and
/ or evolving changes in third-party system requirements. It
provides a means for the dynamic creation and modification of
software based on multiple levels of detail and complexity. Morch
[9] identified three levels of tailoring activity that typically exist
within a software development project.
x Customization – Customization refers to user interface
modifications.
x Integration – The integration level of tailoring refers to
changes in application components, compositions,
interconnections and their configuration.
x Extension – The extension level of tailoring refers to the
addition of new application components and
configurations.
Each tailoring activity requires formal, explicit specification and a
shared conceptualisation for it to be eased within a distributed
development environment where third-party components are
reused. Using a framework as a basis for the creation and
modification of software, it possible to construct, customize,
integrate and evolve software in a straightforward way.
With the evolution of the web and web services it is now more
and more common for software developers to acquire third party
components online and reuse them within their own application
contexts [10] in a distributed development environment.
Unfortunately, even with the broad benefits of component
development, component-based systems have been widely
plagued with problems surrounding system composition and
integration. Currently, software developers are forced to rely on
lacking or ambiguous definitions and specifications of a
component’s services. There is no easy to understand protocol for
defining how a third-party component is described, configured,
integrated and modified to fit within third-party system
requirements or within distributed development environments.
Most vendors specify their components’ services in a proprietary
or context dependant fashion. This makes it difficult to clearly
understand a component’s operational properties and
requirements.
2. ONTOLOGIES
Changes are inevitable during software development projects;
such projects are continuously confronted with an evolving
specification problem. If such changes are not properly tracked
and traced or maintained, this would impede the development and
third party integration of components. In component projects, the
project data needs to be modified periodically to reflect
x project development progress
x changes in the software requirements
x changes in design
x additional functionality
x incremental improvements
x reconfiguration
Ontologies are a widely accepted state-of-the-art knowledge
representation. Software engineering concepts, ideas and
knowledge, software development methodologies, tools and
techniques are organized into a software engineering ontology
that is used as the basis for classifying the communication
concepts by enabling specification, reasoning, problem solving
and other intelligence aspects within software development
projects.
We have merged Gruber’s [11], Borst’s [12], and Studer’s [13]
definitions of an ontology as a basis for the software engineering
ontology definition. Ontologies are formal, explicit specifications
of a shared conceptualization in the domain of software
engineering with the following properties;
x machine-process-able semantics
x explicitly defined
x consensual knowledge
x abstract model
When coupled with multi-agent systems, ontologies allow greater
ease of communication by aggregating the agreed project
knowledge with domain knowledge, and other concepts of
software engineering into a shared information resource platform
that is distributed amongst the development team and others that
reuse the projects artifacts. The first Software Engineering
Ontology is available online at www.seontology.org.
In this paper we present the model of our software component
ontology using the notations proposed in [14] to represent the
ontology and communication architecture. The ontology will be
transformed to a software development resource using the web
ontology language, OWL, and can be accessed by multi-site,
multi-team and multi-development groups. The development of
Proceedings of iiWAS2008 AIIDE 2008
504