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

Thomas Janke
A rule specifies a source model element, annotated with @In, and a number <strong>of</strong> target elements,
marked with @Out. In order to foster code reuse and modularization, rules can extend each o<strong>the</strong>r,
inheriting all <strong>the</strong> instructions defined in <strong>the</strong> base rule. Beyond that, rule priorities can be expressed in
order to describe complex dependencies between rules <strong>of</strong> one single pattern as well as between
different patterns. Patterns can easily be registered or unregistered as needed for a given
transformation using <strong>the</strong> frameworks API. Even though <strong>the</strong> framework has been developed and will
be evaluated in <strong>the</strong> context <strong>of</strong> <strong>the</strong> ontology engineering platform, it is designed as a general purpose
model to model transformation framework. This means, it can be applied for every model
transformation based on Ecore models.
4.4 Developed domain-specific languages
Domain-specific languages are used in order to provide suitable and easy to use modeling languages
for domain engineers. They can be seen as interfaces for populating <strong>the</strong> common ontology model. As
a result, <strong>the</strong>y inherit <strong>the</strong> abstraction level, introduced by <strong>the</strong> common ontology meta model.
Additionally, <strong>the</strong>y provide a syntax which reflects requirements <strong>of</strong> a specific domain. This can be
achieved by means <strong>of</strong> <strong>the</strong> provided vocabulary in forms <strong>of</strong> <strong>the</strong> collection <strong>of</strong> supported keywords as
well as <strong>the</strong> level <strong>of</strong> expressivity. This enables domain engineers to model <strong>the</strong>ir domain <strong>of</strong> expertise in
an easy and intuitive way without <strong>the</strong> need to understand <strong>the</strong> logical formalisms and best practices
behind. The reference implementation <strong>of</strong> <strong>the</strong> platform uses <strong>the</strong> Xtext framework to implement two
textual DSLs.
This design decision was tailored by <strong>the</strong> fact that Xtext provides rich tool support for
deriving
parser implementation from <strong>the</strong> DSL grammar as well as for automatically generating a basic
Eclipse-based editor. The latter has been extended to <strong>the</strong> engineering workbench introduced in
Section 5.
The reference implementation contains two DSLs mainly designed to evaluate <strong>the</strong> concepts <strong>of</strong> <strong>the</strong>
platform. The first modeling language is not specifically bound to a certain domain but <strong>of</strong>fers keywords
that are very close to <strong>the</strong> terms used in <strong>the</strong> common ontology meta model. As a result, <strong>the</strong> provided
vocabulary contains terms like ontology, concept and property.
Never<strong>the</strong>less, it also provides
examples on how to provide sufficient abstraction from complex
modeling primitives. Listing 3
introduces
an example on how to describe n-ary relations in conjunction with cardinality constraints.
ontology 'http://s<strong>of</strong>tware/traceability/v1.0'
{
concept HtmlDocument
{
property
isGeneratedFrom as 'TransformationRelation' :
XmlDocument[1,1] as 'has_XML',
XsltDocument[1,1] as 'has_XSLT'
}
}
Listing 3: DSL describing n-ary relation and cardinality constraints
The given example defines <strong>the</strong> same n-ary relation as introduced in Section 4.2. Additionally, it poses
cardinality constraints on <strong>the</strong> XML and <strong>the</strong> XSLT document. The optional as keyword can be used to
explicitly label properties or concepts instead <strong>of</strong> using auto-generated names. This fairly simple
example shows, though, how abstraction can be used to simplify ontology modeling. Although <strong>the</strong>
domain engineer does not know about how
to model n-ary relations or cardinality constraints in OWL,
an
according ontology can be generated automatically. Figure 5 illustrates <strong>the</strong> workbench
implemented to foster domain model editing and ontology generation. In addition, a small excerpt <strong>of</strong>
<strong>the</strong> resulting OWL ontology is depicted.
The second DSL has been designed specifically for modeling s<strong>of</strong>tware quality aspect <strong>of</strong> Ambient
Assisted Living (AAL) systems. As a requirement, <strong>the</strong> provided language should reuse an existing
meta model (Kläs et al., 2010) developed in <strong>the</strong> Quamoco project
pts like QualityAspect,
ualityRequirement, Impact, Factor and EntityType, toge<strong>the</strong>r with <strong>the</strong>ir relations to each o<strong>the</strong>r, are
ed DSL by means <strong>of</strong> keywords (for an example
e List
6 . This meta model provides a
vocabulary for specifying and evaluating s<strong>of</strong>tware quality. Therefore, conce
Q
described. The meta model is reflected in <strong>the</strong> provid
se ing 4) and <strong>the</strong>refore is seamlessly integrated in <strong>the</strong> modeling process.
6 https://quamoco.in.tum.de/
467