components and concepts in a specific domain, con-
structed by mapping and integrating individual dis-
covery ontologies for software components. Here,
the ontological heuristics serves as guidelines to re-
spond to a developer request. After using ontologi-
cal heuristics on the shared ontology, SEC++ gener-
ates a number of alternative solutions to component
composition. These alternatives are then evaluated
by a decision engine using a set of criteria specified
by the developer. Such criteria may include QoS-
based optimization of component composition, busi-
ness rules and strategies. A selected optimal compo-
sition scheme is then executed.
As for the integration ontology, we employ prob-
lem solving method to develop a local ontology for
component. In the integration ontology we try to di-
vide the component process into tasks. Tasks are ei-
ther solved directly (by means of primitive methods),
or are decomposed into subtasks (by means of de-
composition methods). We use the Unified Problem-
Solving Method Language (UPML) to describe the
components of PSMs (task, method and adapter).
Similarly, the component model subclass is especially
beneficial for composition ( see Figure 1). The pro-
posed approach utilizes the component model class in
two ways. For base components, a component model
keeps information about composability, which speci-
fies when the component can be used in a composite
component. For composite components, a component
model maintains alternative composite solutions in-
crementally for reuse. This semantic enrichment pro-
vides a self-learning capability of component compo-
sition.
Integration
ontology
= Shared ontology
Software components
Discovery
ontology
Meta data
Ontological heuristic
Figure 2: An ontology-supported system for component
composition.
Local integration ontologies are consolidated in a
server by ontology mapping and integration. As a re-
sult, all relevant concepts and components in a do-
main are in the shared ontology, local discovery ontol-
ogy for a component is mapped into the shared ontol-
ogy, appearing as a node in the ontology tree. How to
organize all components into the repository depends
on domains and application requirements. For exam-
ple, for calculating Matrix we can maintain semantic
relationships (e.g., hierarchical and sibling relation-
ships) between Matrix operations. The shared on-
tology also represents other application-specific con-
cepts for mapping and integrating components. The
mapping and integration not only unite component
descriptions and concepts but also add more seman-
tics. Moreover, the shared ontology enables ontolog-
ical heuristics, thus facilitating dynamic component
composition. For example, we can study composabil-
ity of components based on some generic concepts.
As a simple example, when composing component
C2 that calculates the determinant of a real matrix by
receiving the output parameters of a component C1
that calculates the sum of two matrix which have a
natural type. At first glance, these two components
cannot be composed. However, the relationship be-
tween real and natural is revealed in the type ontol-
ogy: natural is included in real.
4 MAPPING THE DISCOVERY
ONTOLOGY INTO
INTEGRATION ONTOLOGY
In this section, we present a prototype system
for mapping a discovery ontology of mathemati-
cal service into integration ontology, which is de-
veloped based on the proposed ontology-supported
software component integration. Our prototype
system employs W3C-recommended standards (i.e.,
RDF+OWL) for semantic description and ontologi-
cal engineering. The software utilized for this task is
Prot
´
eg
´
e 3.4.4. At the discovery ontology description
level, the prototype system translates component de-
scriptions and then adds more semantics in the com-
ponent model class. The composability property of
the component model class can have values denoting
possible ways for component composition.
Taking the Linear system resolution component as
an example, its composability contains a list of possi-
ble parameter flows (from inputs to outputs), each of
which can be a part of an alternative path in a compos-
ite component (Complex Matrix −→ Complex Ma-
trix), (Reel Matrix −→ Real Matrix).
Another way to exploit composability is first to at-
tach composability to other properties with concrete
meanings, then associate composability with compo-
sition rules.
All individual discovery ontologies are mapped
together, appearing as nodes or subclasses in the
shared ontology. For example, the LSR component
is a subclass of the LS class (see Figure 3). The pro-
totype can extract some metadata from individual dis-
covery ontologies and map into the shared one. After
SemanticMatchingtoAchieveSoftwareComponentDiscoveryandComposition
147