Proceedings of the 12th European Conference on Knowledge ...

Thomas Janke
S<strong>of</strong>twareQualityModel domain=”AAL” {
QualityAspect : Maintainability
QualityAspect : Expressivity isPartOf Maintainability Factor
: TestCoverage positivelyImpacts Maintainability EntityType : SourceCode {
influences TestCoverage by linesOfCode
}
EntityType
: TestCase {
influences TestCoverage by coveredSourceCode
}
...
}
Listing 4: DSL for describing s<strong>of</strong>tware quality in AAL systems
For domain engineers, <strong>the</strong> domain description is very cohesive because <strong>the</strong>re is just one level <strong>of</strong>
abstraction. They do not have to import o<strong>the</strong>r models, in this case <strong>the</strong> Quamoco meta model, but can
rely on <strong>the</strong> provided vocabulary and
syntax. During ontology generation, though, this single
description
can be modularized into an ontology specifically describing s<strong>of</strong>tware quality aspects in <strong>the</strong>
AAL domain and ano<strong>the</strong>r one describing s<strong>of</strong>tware quality in general. The latter is <strong>of</strong> course derived
from <strong>the</strong> given Quamoco meta model.
Both example languages, provided as part <strong>of</strong> <strong>the</strong> reference implementation,
illustrate that, depending
on <strong>the</strong> requirements <strong>of</strong> a given domain, various levels <strong>of</strong> abstraction may
be applied in order to foster
ontology modeling. Fur<strong>the</strong>rmore, those DSLs are used to fur<strong>the</strong>r evaluate <strong>the</strong> presented approach.
5. A domain-specific ontology engineering workbench
In order to facilitate <strong>the</strong> domain modeling task for domain experts and to evaluate <strong>the</strong> applicability <strong>of</strong>
<strong>the</strong> proposed platform, we implemented a textual editor based on Eclipse and Xtext. The editor <strong>of</strong>fers
syntax checking, code completion and highlighting for <strong>the</strong> domain-specific language introduced in
Section 4.4. Moreover, <strong>the</strong> editor allows <strong>the</strong> import and reuse <strong>of</strong> o<strong>the</strong>r domain descriptions, ei<strong>the</strong>r
created by means <strong>of</strong> <strong>the</strong> same DSL or in form <strong>of</strong> OWL or RDF(S) ontologies. In addition, we
seamlessly integrated <strong>the</strong> ontology generation process. Every time <strong>the</strong> domain model is edited, <strong>the</strong>
workbench automatically generates <strong>the</strong> corresponding target ontologies, applying all registered
ontology design patterns. As a result, <strong>the</strong> current domain model is reflected by concrete ontologies at
any time. The latter also introduces <strong>the</strong>
possibility to review <strong>the</strong> changes applied to <strong>the</strong> ontology with
regard to every modeling decision. Figure
5 illustrates <strong>the</strong> implemented workbench by means <strong>of</strong> <strong>the</strong>
introduced modeling example.
6. Summary and future work
In order to mitigate <strong>the</strong> problems <strong>of</strong> language selection and lack <strong>of</strong> modeling expertise by domain
engineers in <strong>the</strong> field <strong>of</strong> ontology engineering, a pattern-based ontology engineering platform has
been proposed. The latter enables <strong>the</strong> use <strong>of</strong> domain-specific languages, reflecting <strong>the</strong> requirements
<strong>of</strong> <strong>the</strong> given domain, on top <strong>of</strong> a common ontology model. This does not only simplifies <strong>the</strong> modeling
process but also introduces an additional layer <strong>of</strong> abstraction. Based on that, concrete ontologies in
RDF(S) and OWL are generated. During ontology generation, published modeling best practices, so
called ontology design patterns, contributed by ontology experts are automatically and transparently
applied. As a result, domain engineers can pr<strong>of</strong>it from <strong>the</strong> expertise <strong>of</strong> ontology experts without <strong>the</strong>
need to know about <strong>the</strong> underlying logical formalisms. Apart from <strong>the</strong> architecture <strong>of</strong> <strong>the</strong> platform, we
introduced a reference
implementation, covering <strong>the</strong> most relevant components. This includes an
implementation
<strong>of</strong> a common ontology model, <strong>the</strong> implementation <strong>of</strong> a modular ontology generation
component as well as <strong>the</strong> design <strong>of</strong> two domain-specific languages used to evaluate <strong>the</strong> concepts <strong>of</strong>
<strong>the</strong> platform.
The main item for future work is to evaluate <strong>the</strong> ideas <strong>of</strong> <strong>the</strong> platform in a bigger real world scenario. A
corresponding study needs to reflect estimates about efforts for designing and maintaining <strong>the</strong> DSL,
<strong>the</strong> ease <strong>of</strong> use for domain experts as well as <strong>the</strong> quality <strong>of</strong> <strong>the</strong> generated ontologies.
In this context, it
might also be necessary to adjust <strong>the</strong> expressivity <strong>of</strong> <strong>the</strong> common ontology meta model. Potential
candidates for extensions are <strong>the</strong> ability to formulate rules and <strong>the</strong> annotation triples (e.g. via
reification). Fur<strong>the</strong>rmore, we tend to implement patterns for F-Logic in <strong>the</strong> future.
468