The Core Ontology of Software Components v1.1 29/8/2005 - edited by Daniel Oberle
We define a Profile as follows: First, it aggregates CSO:PolicyDescriptions, an OoP:Plan, the required SoftwareLibraries, the implemented Interfaces and additional Characteristics of a specific Software entity. Second, the link to the described Software is specified via the describes association. We specialize this definition to ComponentProfile and ServiceProfiles.
Often, we need to express certain capabilities or
features of components, such as the version, transactional or
security settings. For this purpose, we introduce Characteristics
on a ComponentProfile. It is expected that ComponentProfiles are
specialized and put into a taxonomy. For example, we might define
a DatabaseConnectorProfile as a ComponentProfile that provides for
specific Characteristics} describing whether the underlying
database provides transactions or SQL-99 support. A taxonomic
structure further accommodates the developer in browsing and
querying for ComponentProfiles in his system.
The concept of a License is a special kind of
LegalContract as introduced in the Core Legal Ontology. We here
just subclass it to Description as we do not include the Core
Legal Ontology. Descriptions is the superclass of LegalContract.
A SoftwareLibrary consists of a number of
CSO:Classes and is classified as CSO:Data because it cannot be
executed as a whole
Assuming the object-oriented paradigm we state
that a SoftwareComponent is a special kind of CSO:Class and that
it conforms to a FrameworkSpecification. According to the
reference version of this ontology, a FrameworkSpecification is
(i) a DOLCE:Collection of CSO:Interfaces and (ii) a special kind
of OoP:Plan which specifies the interaction of components.
Conformance means that every CSO:Interface prescribed by the
FrameworkSpecification has to be implemented by the
SoftwareComponent.
Very often there are
dependencies between libraries that are revealed only during run
time by ClassNotFoundExceptions. For example, a library lib1.jar
might depend on lib2.jar which in turn depends on lib3.jar and so
forth. It is a very tedious task to keep track of such
dependencies and, additionally, to check whether there are
conflicts between libraries in this dependency graph. In order to
reason with such information, we introduce the following
associations and axioms: First, the transitive libraryDependsOn.
Second the symmetric libraryConflictsWith.
The profiles association is as a catch-all for
DnS:defines, DnS:unifies, OIO:about, as well as OIO:expressedBy.
This is done for convenience in order to relieve the developer,
who will certainly have to deal with such information, from such
modelling details when modelling the parts of a ComponentProfile.
a ComponentProfile is defined as
follows: First, it aggregates CSO:PolicyDescriptions, an OoP:Plan,
the required SoftwareLibraries, the implemented Interfaces and
additional Characteristics of a SoftwareComponent. Second, the
link to the described SoftwareComponent is specified via the
describes association
Very often there are
dependencies between libraries that are revealed only during run
time by ClassNotFoundExceptions. For example, a library lib1.jar
might depend on lib2.jar which in turn depends on lib3.jar and so
forth. It is a very tedious task to keep track of such
dependencies and, additionally, to check whether there are
conflicts between libraries in this dependency graph. In order to
reason with such information, we introduce the following
associations and axioms: First, the transitive libraryDependsOn.
Second the symmetric libraryConflictsWith.
Very often there are
dependencies between libraries that are revealed only during run
time by ClassNotFoundExceptions. For example, a library lib1.jar
might depend on lib2.jar which in turn depends on lib3.jar and so
forth. It is a very tedious task to keep track of such
dependencies and, additionally, to check whether there are
conflicts between libraries in this dependency graph. In order to
reason with such information, we introduce the following
associations and axioms: First, the transitive libraryDependsOn.
Second the symmetric libraryConflictsWith.
Very often there are
dependencies between libraries that are revealed only during run
time by ClassNotFoundExceptions. For example, a library lib1.jar
might depend on lib2.jar which in turn depends on lib3.jar and so
forth. It is a very tedious task to keep track of such
dependencies and, additionally, to check whether there are
conflicts between libraries in this dependency graph. In order to
reason with such information, we introduce the following
associations and axioms: First, the transitive libraryDependsOn.
Second the symmetric libraryConflictsWith.