Model-Driven Software Development with Semantic Web Technologies

Web Science & Technologies
University of Koblenz ▪ Landau, Germany

Model-Driven Software Development with
Semantic Web Technologies

Fernando Silva Parreiras, Tobias Walter,
Christian Wende and Edward Thomas

Tutorial Description

 Purpose: to enable attendees to fully appreciate the
application of semantic web and ontology technologies in
MDSD.
 Prerequisites: basic concepts of UML

WeST Tobias Walter ECMFA Tutorial
walter@uni-koblenz.de 2 of 7

Objectives

 We will show you how to:
 Use semantic web skills across your organization
 Understand the main concepts of semantic web and
ontology technologies.
 Identify the valued added by semantic web in MDSD.
 Identity potential applications of semantic web
technologies in MDSD.
 Apply semantic web tools to transform or validate software
models.


Administrative Information

 Facilities
 Coffee Break
• 10:30 – 11:00
• 16:00 – 16:30
 Lunch
• 12:30 – 14:00


Agenda

1. What are ontologies and what can they do for MDSD?
Edward, Fernando 30min
2. Demystifying OWL. Edward 90min
3. Reasoning with OWL in Models. Tobias 60min
4. Integrating OWL in Model-Driven Software Development -
TwoUse. Fernando 30min.
5. Case Studies 150min
 Improving Software Design Patterns. Fernando
 OWLizer and LOD in Model Driven Engineering. Fernando
 Ontology-based Domain Specific languages. Tobias
 Validating Process Refinements. Tobias


Meet Your Classmates

 Name
 Company name
 Experience in ontologies
 Current assignment
 Your expectations for the class


<is web> Information Systems & Semantic Web

What are ontologies and what can
they do for MDSD
Fernando Silva Parreiras, Edward Thomas

What is this unit about <is web>
This unit presents the basic concepts of ontology and
ontology technologies and illustrate the application of
ontologies with well-kown use cases.

ISWeb - Information Systems Fernando Silva Parreiras ECMFA Tutorial
& Semantic Web parreiras@uni-koblenz.de 2 of 42

What You Should Be Able to Do <is web>
At the end of this unit you will be able to:
• Understand the basic concepts of ontologies
• Identify the usage of ontologies in MDE


Rationale of this Talk <is web>
Core Statements: Hypotheses:
Ontologies are yet another 1. Ontologies and SE modeling
type of Conceptual Models may be integrated by MDE!

A Generic Process of MDA + Ontology Technologies

Ontologies are used differently 2. New possibilities for SE!
and with different technology
than UML usually is

Advantages


Agenda of this Talk <is web>
Part 1: What is an ontology?
 Definition
 Purpose, Usage, Formality, Type, Communities

Part 2: Two cases of MDA & ontology technologies
 Model checking
 Hybrid models


Definition: What is an ontology? <is web>
(in computer science)

Based on Gruber 93:

An Ontology is a
formal specification ⇒ Executable, Discussable
of a shared ⇒ Group of persons
conceptualization ⇒ About concepts
of a domain of interest ⇒ Between application
and „unique truth“


Purpose: What is an ontology? <is web>

To make domain assumptions explicit
 Easier to change domain assumptions
 Easier to understand and update legacy data

To separate domain knowledge from operational
knowledge
 Re-use domain and operational knowledge
separately

A community reference for applications

To share a consistent understanding of what
information means


Usage: What is an ontology? <is web>

Topic Maps Front-End
Thesauri
Navigation
Taxonomies Information Retrieval
Query Expansion Sharing of Knowledge

Queries
Ontologies Semantic Networks
Consistency Checking
EAI
Mediation
Reasoning

Extended ER-Models
Predicate Logic
Back-End


Formality: What is an ontology? <is web>

Ad-hoc
Hierarchies XML Data Models
DTDs (UML, STEP) F-Logic
Text (Yahoo!) DB Frames
Corpora Glossaries Schema (OKBC)

lightweight heavyweight
Folks- Thesauri XML Description
onomies Schema Logics
Data Principled First-order,
Dictionaries Formal
Informal Higher-order,
(EDI) Taxonomies
Hierarchies Modal Logic

Glossaries & MetaData,
Thesauri, Formal Ontologies
Data Dictionaries XML Schemas,
Taxonomies & Inference
Data Models


Example: What is an ontology? <is web>
Foundational Model of Anatomy
 Represents structures ranging from macromolecular
complexes to body parts
 Contains
 ~70,000 distinct concepts
 ~ 110,000 terms
 140 relations
 Metaclasses to define class-level properties
 Attributed relations
 Different types of part-whole, location, and other spatial
relations
 Synonyms


Agenda of this Talk <is web>
Part 1: What is an ontology?
 Definition
 Purpose, Usage, Formality, Type, Communities

Part 2: Two cases of MDA & ontology technologies
 Model checking
 Hybrid models


Model-driven Architecture <is web>
A Standard Process

UML UML JAVA
PIM PSM Code

Classical MDA

MDA & Ontology Case 1: Model Checking <is web>
Reasoning on UML class diagrams

OWL

Translation

UML UML JAVA
PIM PSM Code

Classical MDA

Model Checking <is web>
Reasoning on UML class diagrams allows for checking:

 Consistency of the diagram:
Can the classes be populated?

 Classification to identify the possible omission of an
explicit generalization.

 Equivalence among classes to discover redundancy.

 Refinement of properties to apply stricter multiplicities or
typing than the ones explicitly specified in the diagram.


Model Checking: Example <is web>

if Researcher is
UserAccount User empty, User and
0..n 1
INCONSISTENT
Owns Student will be
redundant
Researcher
Uses {complete, disjoint} is disjoint from
Student
WebPortalAccount Researcher Student
1..n
0..1


Model Checking: Example <is web>

UserAccount User
0..n 1
INCONSISTENT
Owns

Uses {complete, disjoint}

WebPortalAccount Researcher Student
1..n
0..1

Advantage for SE:
Models with provably higher quality


MDA & Ontology Case 2: Hybrid Models <is web>
Integrating UML Models and OWL Ontologies: TwoUse
TwoUse: Transforming and Weaving Ontologies and UML for SE

TwoUse:
Previously:
Ontology
Combined OWL
Engineering
Ontology &
Software
Software
Engineering
Engineering UML UML JAVA
PIM PSM Code
Classical MDA


MDA & Ontology Case 4: Hybrid Models <is web>
Case: Integrating UML Models and OWL Ontologies with TwoUse

UML/OCL OWL
(ODM)
M2

TwoUse
Metamodel

OWL
Ontology
InstanceOf

M1
UML Profiled TwoUse UML Class Java Code
Diagram Model Diagram ...

PIM PIM PIM Code


Hybrid Model: Example UML <is web>

+hasCustomer +hasProduct
FreeTradeZone
1..n Customer 1 0..n Purchase
Product
+hasOrder Order
+memberOfTradeZone +has Name: String
+hasMember
Resident getCharges()

Country 1 +livesIn UML


Hybrid Model: Example OWL <is web>

+hasCustomer
FreeTradeZone
1..n Customer 1 0..n Purchase
+hasOrder Order
+memberOfTradeZone +has
+hasMember
Resident getCharges()

Country 1 +livesIn

<<owlRestriction>>
DutyFreeOrder
OWL
<<owlRestriction>> (ODM)
CountryFromEU DutyFreeOrder = OrderFromEUCustomer
<<equivalentClass>>
<<owlValue>> {hasValue = eu}
memberOfTradeZone : FreeTradeZone
<<owlRestriction>>
<<owlValue>> OrderFromEUCustomers
+{someValuesFrom = CountryFromEU}
livesIn <<owlValue>>
+{someValuesFrom= CustomersFromACountry }
ISWeb - Information <<owlRestriction>> Parreiras OrdersFromEUCustomers hasCustomer SOME
Systems Fernando Silva ECMFA Tutorial
hasCustomer
20 of 42 CustomerFromEUCountries
& Semantic WebCustomerFromEUCountry
parreiras@uni-koblenz.de

MDA with Ontologies <is web>
Cases seen today (there are more):
1. Model Checking, e.g. Reasoning on UML class diagrams (Berardi, 2005)
2. Hybrid Approach, TwoUse: Integrating UML Models and OWL Ontologies
(Parreiras, Staab, Winter, 2007)

OWL

UML UML JAVA
PIM PSM Code
Classical MDA


Key Messages for this Unit <is web>
Hypotheses: OWL
1 Ontologies and SE
modeling integrated
by MDE (specifically MDA)!
UML UML JAVA
A Generic Process
PIM PSM Code
Classical MDA

2 New possibilities for SE!

Models with provably higher quality.

Advantages Joint engineering of ontologies and SE
models.



Thank You!

Model-Driven Software Development
with Semantic Web Technologies
Demystifying OWL

Edward Thomas
University of Aberdeen

Outline
 Introduction to Description Logic
 Makeup
 Syntax and Semantics
 Reasoning
 The OWL family of Ontology Languages
 OWL 1
 OWL 2
 Open vs. Closed World
 Unique Name Assumption
 Tools and resources

2009-05-26

Introduction
 OWL is not hard
 But it makes some assumptions
 These differentiate it from more
familiar KR formalisms

2009-05-26

Demystifying OWL

INTRODUCTION TO OWL
& DESCRIPTION LOGICS

2009-05-26

DL Makeup
 DL consists of
 TBox (Terminology)
 ABox (Assertions)
 Consider this to be analogous to
 Schema (ER Model)
 Data (database)

2009-05-26

 A DL consists of named
 Concepts
 Roles
 Individuals

2009-05-26

TBox
 A TBox (Terminonagy Box) is a set of
“schema” axioms (sentences), e.g.:
{∃≥50goodFriend v Popular,
goodFriend v friend}
 i.e., a background theory for the
vocabulary

2009-05-26

ABox
 An ABox (Assertion Box) is a set of
“data” axioms (ground facts), e.g.:
goodFriend (John,Kate)
Mother (Kate)

2009-05-26

Syntax
 Several common syntaxes exist
“everyone who has a child who is a doctor who
has children who are all female”

 DL Syntax:
∃hasChild.(Doctor ∧ ∀hasChild.Female)
 Manchester Syntax
hasChild some (Doctor and (hasChild only Female))
 OWL Functional Syntax
SomeValuesFrom (hasChild IntersectionOf ↲
(Doctor AllValuesFrom (hasChild Female))

2009-05-26

TBox Syntax
 Boolean Operators

⊓
DL Manchester Example

⊔
Intersection and Rich and Doctor
Union or Doctor or Lawyer
Complement ¬ not not Lawyer

2009-05-26

TBox Syntax
 Restrictions

Existential ∃ some eats some fruit

∋
Universal ∀ only eats only fruit
Exact value value eats value bamboo
Min cardinality ≥ min hasChild min 3
Max cardinality ≤ max hasChild max 3
Exact cardinality = exactly hasChild exactly 3

2009-05-26

TBox Syntax
 Roles

Inverse ¯ inverse inverse eats
Chain o eats o inhabits

2009-05-26

Subsumption
 TBox contains a set of concept and
role subsumptions

C1 SubClassOf: C2
C1 ⊑ C2

R1 SubPropertyOf: R2
R1 ⊑ R2

2009-05-26

Subsumption
 These can be complex concepts
“everyone who has a child who is a
doctor who has children who are all
female is happy”

HappyPerson SubClassOf: hasChild some ↲
(Doctor and (hasChild only Female))
HappyPerson ⊑ ∃hasChild.(Doctor ∧ ↲
∀hasChild.Female)

2009-05-26

Subsumption
 Complex concepts can appear on either (or
both) sides
“everyone who is happy has a child who is a
doctor who has children who are all female”
 This is different from the previous sentence
 By adding both these sentences to our
ontology, we make the concepts equivalent
 A SubClassOf: B
B SubClassOf: A
 A EquivalentClass: B

2009-05-26

Semantics
 The semantics for a DL are derived
from its features
 The semantics of OWL-DL are defined
here
 http://www.w3.org/TR/owl-
semantics/semantics-all.html#3
 The formal definition is concise, but
not easy to understand

2009-05-26

Semantics
 DLs use a Model Theoretic semantics
 An interpretation I consists of
 The domain or universe
 Mappings from
 Concepts to sets of instances
 Roles to pairs of instances
 The semantics of a DL tell us how to
interpret the domain

2009-05-26

Semantics
 Given an ontology O, the constraints on
the possible interpretations may lead to
consequences in those interpretations.
 C subsumes D w.r.t. an ontology O iff for
every model I of O, I(D) ⊆ I(C)
 C is equivalent to D w.r.t. an ontology O iff
for every model I of O, I(C) = I(D)
 C is satisfiable w.r.t. O iff there exists some
model I of O such that I(C) ≠ ∅
 An ontology O is consistent iff there exists
some model I of O.

2009-05-26

Reasoning
 Reasoning derives new facts from the
ontology
 Several standard services
 Consistency
 Satisfiability
 Classification
 Subsumption checking
 Instance retrieval
 Query answering
 Justification

2009-05-26

Consistency
 Is the ontology semantically
consistent?
 Inconsistency arises when there is a
conflict in the axioms in the ontology
 A SubClassOf: not B
A(x), B(x)

2009-05-26

Satisfiability
 Can some concept description be
instatiated?
 Given that A SubClassOf: not B
 (A and B) is not satisfiable
 (A or B) is!

 How about
 creates only Sculpture and creates
some (Artwork and not Sculpture)

2009-05-26

Classification
 Find all the named concepts which a
particular instance belongs to
 Tiger SubClassOf: Cat
Tiger (ShereKhan)
Classify (ShereKhan) := [Tiger, Cat, T]

2009-05-26

Subsumption checking
 For two concept or role descriptions A
and B, is every possible instance of A
always an instance of B?
 Carnivore SubClassOf: eats only Animal
Shark SubClassOf: eats only Fish
Fish SubClassOf: Animal
 Given these, a reasoner can infer that
 Subsumes(Shark Carnivore) := true
 EVERY shark is a carnivore

2009-05-26

Instance Retrieval
 Find all the instances of a particular
concept or role description
 Given A(a,b,c), B(a,c,d)
 IR(A and B) := [a,c]
 IR(A or B) := [a,b,c,d]
 And trivially: IR(A) := [a,b,c]

2009-05-26

Query Answering
 Query answering is a special form of
instance retrieval
 Eg: q(x,z)  A(x), R1(x,y), R2(y,z), B(z)
 Find instances x and z, such that x is an
instance of A, x is related to some value
y by the role R1, y is related to some
value z by the role R2, z is an instance of
B
 Currently there is no algorithm for
complete query answering in OWL-DL

2009-05-26

Justification
 Given some reasoning result A in
ontology O
 What is the minimal subset (or
subsets) of the axioms in O which are
responsible for that result

2009-05-26

Naming
 There is an informal naming convention for DLs

 AL Attributive language
EL Intersection and existential qualification
F Functional properties
E Full existential qualification
U Concept union
C Complex concept negation
S ALC with transitive roles
O Nominals
I Inverse properties
N Cardinality restrictions
Q Qualified cardinality restrictions
(D) Datatype properties

2009-05-26

Naming
 Under this nomenclature:
 OWL-Lite is SHIF(D)
 OWL-DL is SHOIN(D)
 OWL2-DL is SROIQ(D)

2009-05-26

Demystifying OWL

THE OWL FAMILY

2009-05-26

The family tree
OWL 2 Full Undecidable

2NExpTime-
OWL 2 DL Complete
SROIQ

NExpTime-
OWL 1 DL Complete
SHOIN

PTime-
OWL 2 RL OWL 2 EL Complete
EL++

OWL 2 QL In AC0
DL-Lite

30

OWL 1
 Successor to DAML+OIL language
 Became a W3C recommendation in
2004
 Consists of three defined languages
 OWL-Lite is the DL SHIF(D)
 OWL-DL is the DL SHOIN(D)
 OWL-Full is first order logic
 Undecidable

2009-05-26

OWL 1
 Three sub langauges
 OWL-Lite
 OWL-DL
 OWL-Full

2009-05-26

OWL-Lite
 Lightweight, easy to use language
 Supports most DL features we have
seen
 Some exceptions
 Restricted cardinality (0 or 1)
 Only intersection, no union or
complement
 Intersection only on named classes
 Still worst case NExpTime

2009-05-26

OWL-DL
 The real OWL 1 language
 Extends OWL-Lite with
 Arbitrary cardinality restrictions
 Boolean operations on class descriptions
 Property values
 USPerson SubClassOf: bornIn value USA
 While maintaining the same
complexity

2009-05-26

OWL 2
 OWL 2 working group began in 2005
 Advances in DLs
 Expressivity
 SROIQ(D) (Horrocks and Sattler, 2006)
 Tractability
 For TBox reasoning, EL++ (Baader et al,
2005)
 For query answering, DL-Lite (Calvanese et
al, 2004)
 For rules, DLP (Grosof et al, 2003) and PD*
(Herman et al, 2005)

2009-05-26

Why OWL 2
 Problems identified in OWL 1
 Complexity for large ontologies
 OWL-Lite was still NExpTime
 Expressivity limitations
 Qualified cardinality restrictions
 Data ranges
 Keys
 etc

2009-05-26

Differences
 Syntactic sugar
 Expressivity
 Punning
 Annotations
 Profiles

2009-05-26

Syntactic Sugar
 DisjointUnion
 BrainHemisphere SubClassOf: ↲
DisjointUnionOf (LeftBrain RightBrain)
 Disjoint Classes
 DisjointClasses (A B C D E)
 Negative property assertion
 NegativeObjectPropertyAssertion
 NegativeDataPropertyAssertion

2009-05-26

Expressivity
 Self restriction
 SelfEmployed SubClassOf: hasBoss Self
 Qualified cardinality restriction
 Allows a class description in cardinality
expressions
 BusyParent SubClassOf: hasChild ↲
max 3 Female
 Data property cardinality restrictions
 Person SubClassOf: hasSSN max 1

2009-05-26

Expressivity
 Reflexive properties
 The property holds true between every individual and itself
 ReflexiveProperty(livesWith)
 Irreflexive properties
 The property is false between every individual and itself
 IrreflexiveProperty (smallerThan)
 Asymmetric properies
 The property cannot hold both ways between two
individuals
 AsymmetricProperty (smallerThan)
 Disjoint properties
 The same pair of individuals cannot share both properties
 DisjointObjectProperties (smallerThan biggerThan)
 Property chain inclusion
 Properties can be subsumed by chains of properties
 locatedIn SubPropertyChain: locatedIn o partOf

2009-05-26

Keys
 OWL 1 did not support keys
 For example:
“Every street is uniquely identified by a
postcode”
 In OWL 1 this became undecidable
(inverse functional data property)
 OWL 2 supports composite keys
 Street HasKey: postcode
 Transplant HasKey: donor recipient
organ

2009-05-26

Metamodelling
 OWL 1 and 2 have disjoint sets of
properties, classes, objects
 OWL 2 allows these to share names
 This allows simple metamodelling
 CheesePizza SubClassOf: Pizza
hasTopping (CheesePizza, Mozzarella)
orderFor (John CheesePizza)
 Classes and datatypes must still be
separate, as must object and data
properties

2009-05-26

Profiles
 Profiles in OWL 2 define fragments of
the language with known tractable
properties
 EL
 QL
 RL
 This provides a set of constructors for
users who need very large ontologies

2009-05-26

OWL 2 QL
 OWL 2 QL is the fragment targeted at
query answering
 Very restricted TBox constructs
 Any query can be rewritten into a
union of relational queries
 This gives AC0 query performance
 Same as relational databases

2009-05-26

OWL 2 RL
 OWL 2 RL is the fragment which is
amenable to implementation using
rule-based technologies
 Most constructs are supported, but in
a limited fashion
 Complexity is polynomial
 VERY scalable reasoners exist
 Billions of statements, over hundreds of
nodes

2009-05-26

OWL 2 EL
 OWL 2 EL captures the expressive
power of many very large ontologies
 SNOMED CT contains millions of classes
 Complexity is worst case polynomial
(including query answering)
 Supports full existential qualification

2009-05-26

Demystifying OWL

OPEN VS. CLOSED WORLD

2009-05-26

Open World
 OWL operates on an open world
assumption
 Relational databases, Prolog, and
many other KR languages use a
closed world assumption
 This leads to different behavior in
OWL to what you may expect

2009-05-26

Closed World
Assumption
The closed world assumption implies
that everything we don’t know is
false, while the open world
assumption states that everything we
don’t know is undefined
— Stefano Mazzocchi

2009-05-26

Closed World
Assumption
 Example:
 Given the following ontology
 R(a,b) R(a,c):r, R(b,c):r, R(c,d):r
 X(b), not X(d).
 And the following query
 Q(x)  R(?x,?y), R(?y,?z), X(?y), not X(?z)
 Under CWA, no results are returned
 With OWA, individual a will be returned.
 Although X(c) or not X(c) is unknown, it
does not affect the answer. In either model,
answer a always holds.

2009-05-26

Simulated CWA
 Closed world assumption can be
partially simulated
 Since OWL supports nominals, an
ontology can be closed by:
 Finding all named individuals
 Setting owl:Thing to be equivalent to this
set
 This prevents the reasoner from inferring
new unnamed individuals

2009-05-26

Local CWA
 Local CWA goes further than simulated
CWA
 It allows complete knowledge to be
assumed for parts of an ontology
 Individuals classes can be closed
 Cat EquivalentClass:
{Henry,Garfield,James}
 Closing properties can be done, but it is
more difficult
 Supported in TrOWL reasoner
2009-05-26

NAF and NOT
 OWL does not support negation as
failure
 Negation has to be made explicit
 This is called true NOT
 A(a,b,c) B(a,c,d)
 IR(A and not B) := []
 Open world assumption!
 IR(A and naf B) := [b]
 Supported in TrOWL reasoner

2009-05-26

Demystifying OWL

UNIQUE NAME ASSUMPTION

2009-05-26

Unique Name
Assumption
 Unique name assumption assumes that
every object has a unique name
 For example, if we define a person X
and a person Y, under UNA:
 X differentFrom Y will hold true
 OWL operates without this assumption
 This means that one object can have
many names
 Can be explicit using sameAs/differentFrom

2009-05-26

UNA assumptions
 This lack of UNA can cause problems
 Unintuitive behavior with keys
 Street HasKey: postcode
 AcaciaRoad postcode “NW8 6DN”
BakerStreet postcode “NW8 6DN”
 Key violation?
 Actually, this just entails
 AcaciaRoad sameAs BakerStreet

2009-05-26

Applying local UNA
 OWL supports the AllDifferent
construct
 Pass it sets of individuals which are
different from one another
 AllDifferent(AcaciaRoad BakerStreet)
 Combined with the key, this leads to
inconsistancy
 Key violation!
 Therefore UNA can be simulated in
OWL

2009-05-26

Demystifying OWL

TOOLS AND RESOURCES

2009-05-26

Reasoners
 Full DL Reasoners
 Fact++
 HermiT
 Pellet
 Racer
 Approximation based
 KAON2
 TrOWL
 Lightweight
 CEL
 OWLGRES
 Quill
 REL

2009-05-26

Ontology Editors
 Protégé
 Version 3.4 for plugin support
 Version 4.0 or 4.1 beta for OWL2 support
 NeON tookit
 Eclipse based
 Topbraid Composer
 Commercial tool

2009-05-26

Demystifying OWL

QUESTIONS
DEMONSTRATION

2009-05-26


Reasoning with OWL in Software Models

ECMFA Tutorial on
Model-Driven Software Development with Semantic Web
Technologies

Tobias Walter

Objectives

 Context
 Software Languages
 Ontology Languages
 Language Bridges
 Transforming Software Languages to OWL
 Integrating Software Languages with OWL
 Services
 Reasoning Services
 Querying Services


Context (Model Hierarchy)

 Model hierarchy

Language
Designer

Language
User


Context (Metametamodel)

 Ecore M3 metametamodel


Basics (Metamodel)

 M2 metamodel (Activity Diagram)
Language
 conforms to Ecore M3 metametamodel Designer
 visualized using concrete syntax of UML class diagrams


Basics (Metamodel)
 Ecore-based metamodel (Activity Diagram)
 conforms to Ecore M3 metametamodel
Language
 visualized using textual concrete syntax Designer
abstract class ActivityNode {
reference incoming [0-*] : ActivityEdge oppositeOf target;
reference outgoing [0-*] : ActivityEdge oppositeOf source;
}
class ObjectNode extends ActivityNode { }
class Action extends ActivityNode {
attribute name : String;
}

abstract class ControlNode extends ActivityNode { }
class Initial extends ControlNode { }
class Final extends ControlNode { }
class Fork extends ControlNode { }
class Join extends ControlNode { }
class Merge extends ControlNode { }
class Decision extends ControlNode { }

abstract class ActivityEdge {
reference source [1-1] : ActivityNode;
reference target [1-1] : ActivityNode;
}
class ObjectFlow extends ActivityEdge ECMFA Tutorial
WeST Tobias Walter
{ }
class ControlFlow walter@uni-koblenz.de
extends ActivityEdge of 45}
6 {

Basics (Model)

 Model (Activity Diagram)
 designed by language user
Language
User


Description Logics

 Description Logics (DLs) are logics designed to represent
and reason on structured knowledge
 The domain of interest is structured into (TBox):
 concepts, which correspond to classes, and denote sets of
individuals
 roles, which correspond to associations, and denote binary
relations on individuals
 The knowledge is asserted through so-called assertions
(ABox)

 They provide formal semantics

 DLs provide the foundations for standard ontology
languages, like OWL2

Ontologies as Software Models
 OWL2 Metamodel (excerpt)


OWL2 Ontology (Example)
 Functional Style Syntax (axiom-based)

SubClassOf(ActivityEdge owl:Thing)

SubClassOf(ActivityNode owl:Thing)

ObjectPropertyDomain(to ActivityEdge)
ObjectPropertyRange(to ActivityNode)

ObjectPropertyDomain(outgoing ActivityNode)
ObjectPropertyRange(outgoing ActivityEdge)

ObjectPropertyDomain(from ActivityEdge)
ObjectPropertyRange(from ActivityNode)

ObjectPropertyDomain(incoming ActivityNode)
ObjectPropertyRange(incoming ActivityEdge)

ClassAssertion(action1 Action)


OWL2 Ontology (Example)

 Manchester Style Syntax (frame-based)
Class: ActivityEdge
SubClassOf: owl:Thing

Class: ActivityNode
SubClassOf: owl:Thing

ObjectProperty: to
Domain: ActivityEdge
Range: ActivityNode

ObjectProperty: outgoing
Domain: ActivityNode
Range: ActivityEdge

ObjectProperty: from
Domain: ActivityEdge
Range: ActivityNode

ObjectProperty: incoming
Domain: ActivityNode
Range: ActivityEdge

Individual: action1
Types: Action

Comparing Ecore with OWL

 Many similar constructs
Ecore OWL
package ontology
class class
instance and literals individual and literals
reference, attribute data property
data types data types
enumeration enumeration
multiplicity cardinality
Opposite reference Inverse object properties
 Reasoners use logic-based language
 Representation of software models in a logic-based language

 We need bridges!


Software Language Bridges

 2 kinds of Language Bridges
 M3 Transformation bridge
 M3 Integration bridge


M3 Transformation Bridge

 Transformation of Ecore Technical Space with Ontology
Language OWL2
 Transformation of Ecore-based Metamodels
 Transformation of conforming Models
Transformation
Definition

Transformation
Use

M3 Transformation Bridge
 OWLizer
 Transforming Software Metamodels to Ontology TBox
 Transforming Software Models to Ontology ABox

Language
Designer

Language
User

Ecore to OWL - OWLizer

Language
Designer

Language
User

• Definition of Transformation Bridge
• Model transformation rules according to mappings
of similiar constructs

Ecore to OWL - OWLizer

SubClassOf(ActivityEdge owl:Thing)
SubClassOf(ActivityNode owl:Thing)

use of transformation ObjectPropertyDomain(to ActivityEdge)
brdige ObjectPropertyRange(to ActivityNode)
ObjectPropertyDomain(from ActivityEdge)
ObjectPropertyRange(from ActivityNode)

...
Language
Designer
ClassAssertion(A Action)
ClassAssertion(B Action)
ClassAssertion(C Action)

ClassAssertion(e1 ObjectFlow)
Language ClassAssertion(e2 ObjectFlow)
User of transformation
use
brdige ObjectPropertyAssertion(to e1 B)
ObjectPropertyAssertion(from e1 A)

...


Extending Software Metamodels

 Integration of Ecore Technical Space with Ontology
Language OWL2
Integration of abstract Syntax
• OWL2 metamodel + Ecore Metametamodel integrated
Create Ecore-based metamodels with
Integration of concrete Syntax
• OWL2 axioms
• OWL2 concrete syntax + Ecore concrete Syntax
• OWL2 expressions


Integration of abstract Syntax

 Metamodel Integration by using Integration Operations
 Merge of concepts

 Relation of concepts by
• Specialization Relationship

• Association


Ecore Metametamodel + OWL2 Metamodel
 Integration of abstract Syntax
 Result: Integrated Metametamodel


Ecore concrete syntax
 Textual Concrete Syntax for Coding Metamodels
• Simple Syntax, similar to Java

 Grammar (concrete Syntax):
class ::= ["abstract"] "class" name [supertypes] "{" features "}";
...

feature ::= attribute | reference;
...

attribute ::= "attribute" name multiplicity ":" typeref ";";
...

reference ::= "reference" name multiplicity [iscontainer] ":“
typeref ["oppositeOf" name] ";";
...


Example of Ecore Textual Concrete Syntax

 (textual) Activity Diagram Metamodel
abstract class ActivityNode {
}
class ObjectNode extends ActivityNode { }
class Action extends ActivityNode {
attribute name : String;
}

abstract class ControlNode extends ActivityNode { }
class Initial extends ControlNode { }
class Final extends ControlNode { }
class Fork extends ControlNode { }
class Join extends ControlNode { }
class Merge extends ControlNode { }
class Decision extends ControlNode { }

abstract class ActivityEdge {
reference source [1-1] : ActivityNode;
reference target [1-1] : ActivityNode;
}
class ObjectFlow extends ActivityEdge { }
class ControlFlow extends ActivityEdge { }


Extension of textual concrete syntax
• New non-terminals:
• classAxioms: produces a list of OWL Class Axioms

• objectPropertyAxioms: produces a list of OWL Object Property
Axioms

• dataPropertyAxioms: produces a list of OWL Data Property
Axioms
class ::= ["abstract"] "class" name [supertypes] [classAxioms] "{" features "}";

classAxioms ::= ClassAxiom { "," ClassAxiom};

reference ::= "reference" name multiplicity iscontainer ":" typeref "oppositeOf“
name [objectPropertyAxioms] ";";

objectPropertyAxioms ::= ObjectPropertyAxiom { "," ObjectPropertyAxiom};

attribute ::= "attribute" name multiplicity ":" typeref [dataPropertyAxioms] ";";

dataPropertyAxioms ::= DataPropertyAxiom { "," DataPropertyAxiom};


Example
• Extended Metamodel of Activity Diagram (excerpt)
class ActivityNode equivalentWith restrictionOn edge with some Final{

transitive reference edge [0-*] : ActivityNode isChain(outgoing, target);
}

...

class Initial extends ControlNode,
subClassOf restrictionOn outgoing with some
(restrictionOn with some (Action or ControlNode))
{

}


Reasoning Services

 Consistency Checking  Subsumption Checking
 Satisfiability Checking  Explanation
 Classification  Querying


Consistency Checking

Name Consistency Checking
Signature boolean consistency (Ontology O)
Description Checks if the given ontology O is consistent, i.e. if there exists a model
(a model-theoretic instance) for O. If ontology O is consistent, then
return true. Otherwise return false.
Pattern b = consistency (O)
Input An Ontology O
Output b = true iff o is consistent,
b = false otherwise


Consistency Checking in Software Modeling

 Accomplished Service
 Ensures that a Model does not contain any contradictory
facts with regard to its Language Metamodel

 Requirements for Language Designers
• Possibility to define Constraints and Restrictions
• Define Axioms

 Benefits for Language User
• Qualitative Models


Consistency Checking (Example)

M2 Metamodel

}

M1 Model
Inconsistency:
Missing Edge to
Final Action
Receive Order


Satisfiability Checking
Name Satisfiability checking
Signature Set<Concept> GetUnsatisfiable (Ontology O)
Description Find all unsatisfiable concepts in given ontology O. A concept in an
ontology is unsatisfiable if it is an empty set. Return NULL if there
is not any unsatisfiable concept.
Pattern b = GetUnsatisfiable (O)
Input An Ontology O
Output b = NULL iff there is no unsatisfiable concept
b = a set of unsatisfiable concepts otherwise


Satisfiability Checking in Software Modeling

 Finds unsatisfiable classes in a metamodel

 Benefits for Language Designers
 More qualitative metamodels, where all classes can be
instantiated

 Benefits for Language Users
 Less inconsistencies in models (because instances of
unsatisfiable classes lead to inconsistencies)


Satisfiability Checking (Example)

M2 Metamodel

}

class Final extends ControlNode
subClassOf (restrictionOn edge with some ActivityNode) and
not(restrictionOn edge with some ActivityNode)
{ }

Unsatisfiable Class:
two contradictory
restrictions


Classification
Name Classification
Signature boolean classifiesAs (Ontology O, concept A, individual i)
Description Checks if the given individual i is an instance of concept A in the
ontology ref, then return true. Otherwise return false.
Pattern b = classifiesAs ( O, A, i)
Input An Ontology O, Concept A and Individual i
Output b = true iff i is an instance of A,
b = false otherwise


Classification in Software Modeling

 Determines the most specific type an Model Element
belongs to
 With respect to all Attributes and Properties in the Context
of the Model Element

 Requirements for Language Designers
 Define Axioms
 Possibility to define Constraints and Restrictions

 Automatically Refinement of Model Elements
 Suggestions of suitable domain concepts to be used


Classification (Example)

M2 Metamodel
class ObjectNode extends ActivityNode
equivalentWith ((restrictionOn incoming with some ObjectFlow)
and (restrictionOn outgoing with some ObjectFlow))

{ }

M1 Model
Send Invoice Invoice Make Payment

Classify Invoice Node
Result: It is of type
ObjectNode

Subsumption Checking
Name Subsumption Checking
Signature boolean subsumes (Ontology O, concept A, concept B)
Description Checks whether the interpretation of A is a subset of the interpretation
of B in the given ontology O. If the interpretation of A is a subset of
the interpretation of B, then return true. Otherwise returns false.
Pattern b = subsumes (O,A,B)
Input An Ontology O and concepts A, B
Output b = true iff the interpretation of A is a subset of the interpretation
of B in the ontology O,
b = false otherwise


Subsumption Checking in Software Modeling

 Computes a Subsumption Hierarchy of all Classes
 based on all Class Expressions and Axioms in the
Ontology

 Requirements for Language Designers
 Define Axioms
 Possibility to define Expressions and Restrictions


Explanation

Name Explanation
Signature Set<Axiom> getExplanation (Ontology O, axiom Ax)
Description Retrieve the set of axiom that entail axiom Ax in the given ontology,
then return them.
Pattern b = getExplanation (O,Ax)
Input An Ontology O and axiom Ax
Output b = set of axiom that entail the given axiom Ax.
b = NULL otherwise


Explanation for Software Modeling

 Explanations for subsumptions and unsatisfiable classes in
metamodels
 Explanations for inconsistencies in models

 Debugging of metamodels

 Debugging of models


Explanation (Example Unsatisfiability)
M2 Metamodel

}

class Final extends ControlNode
subClassOf (restrictionOn edge with some ActivityNode) and
not(restrictionOn edge with some ActivityNode)
{ }

Explanation from TwoUse Toolkit
---------------------------------------
Unsatisfiability of Final:
Explanation:
Final equivalentTo not edge some ActivityNode
and edge some ActivityNode


Explanation (Example Inconsistency)

Explanation from TwoUse Toolkit
M2 Metamodel ---------------------------------------
class ActivityNode CONSISTENCY restrictionOn edge with some
CHECK equivalentWith Final{
Consistent: No
}
Explanation:
receiveOrder type Action
Action subClassOf ActivityNode
ActivityNode equivalentTo edge some Final
M1 Model

Receive Order


Querying

Name Query answering
Signature Set answering (Ontology O, query q)
Description checks the answer sets of a query q to ontology O.
Pattern res = answering (Ontology O, query q)
Input An Ontology O, and a query q
Output res = a set of answers of the query to the ontology iff there is a answer
set
res = NULL if there is not any answer


Querying Service for Software Modeling

 Query for model elements and metamodel element
 Use of OWL2 entailment regime

 Retrieving information on concepts

 Retrieving existing and complex parts of models


Querying (Example)
 Find all actions, that are executed before „Ship Order“:
Query ( ClassAssertion(?i Action),
ObjectPropertyAssertion(InverseInverseObjectProperties(edge)
?i shiporder))

Results:
-----------------
| c |
=================
| fillorder |
| receiveorder |
-----------------
M1 Model
[order
rejected]
Ship Order
Receive Order Fill Order Close Order
[order
accepted]

Send Invoice Make Payment Accept Payment
Invoice


Querying (Example)

 Find all unsatisfiable classes:
Query ( SubClassOf(?c owl:Nothing) )
Results:
------------
| c |
============
| Nothing |
| Final |
------------
 Find all concepts that do not go via edge to Final:
Query ( EquivalentClasses(?c
Not(ObjectSomeValuesFrom(edge Final))))
Results:
-------------------
| c |
===================
| ActivityDiagram |
-------------------

Discussion…

… Questions?


Information Systems & Semantic Web

The TwoUse Toolkit

University of Koblenz-Landau

1. What?
2. How?


What?
Platform for developing ontology-based applications


Yes, you can!

• Design ontologies with UML, graphically,
with Functional Syntax, add SWRL rules,
• Design DSLs, Software Design Patterns
• Validate BPMN

• Reasoning explanation

• Query with SPARQL, SPARQLAS
• And More…

Design


Validate


Query


Explanation


Other Functionalities

• Specify Ontology Mappings
• Specify Ontology APIs
• Generate Code



Improving Design Patterns by Description
Logics: A Use Case with Abstract Factory and
Strategy Pattern

Fernando Silva Parreiras

EU STReP MOST

This Talk is about <is web>
Weaving features of Description Description Logics
(OWL)
Logics into the Strategy Pattern under

Classification

Inference
the variant management subset of
software design patterns.

Algorithm Encapsulation
Management
Variant

Factorization of common functionality Sel ec tor
Choice of implementations Pa tter n

Software Design Patterns


Running Example <is web>
An order-processing system for an international e-
commerce company in the United States
This system must be able to process sales orders in many
different countries, like the USA and Germany, and handle
different tax calculations.


Strategy Pattern <is web>
Drawbacks:
context TaskController::getRulesForCountry():Tax
body:
if so.customer.country.name = 'USA' then
USTax.new()
else
if so.customer.country.name = 'GERMANY' then
GermanTax.new()
endif
endif
Tangling
TaskController
so : SalesOrder SalesOrder
3. process(tax : Tax) Context
2. getRulesForCountry() : Tax
1. process()
Tax
taxAmount()
Customer
Coupling 4.
Client USTax GermanTax
Country Strategies
name : String
How to improve it?


Building Blocks <is web>
- The TwoUse solution
Uses an Ontology to describe Context and Strategies
Classifies dynamically the Context
- Hybrid Diagram
- Metamodel
- Transformation Process

TaskController
so : SalesOrder SalesOrder
process(tax : Tax) Context
getRulesForCountry(): Tax
process()
Tax
taxAmount()
Customer
Client
USTax GermanTax
Country Strategies
name:String


Hybrid Diagram: Strategy Pattern + OWL <is web>
No Coupling context SalesOrder::getRulesForCountry():OclType UML
body:
Select ?T where ?self directType ?T OWL
No Tangling
«owlClass» TwoUse
TaskController SalesOrder Tax
process() process() taxAmount()
getRulesForCountry()
«owlClass»
Customer
Dynamic
«rdfSubClassOf» «rdfSubClassOf»
«owlClass» «owlClass» Classification
«owlClass»
(USSalesOrder) (GermanSalesOrder)
Country USTax GermanTax
«equivalentClass» «equivalentClass»

«owlRestriction» «owlRestriction» Reuse
«owlValue» {someValuesFrom=USCustomer} hasCustomer
«owlRestriction»
USCustomer Flexibility
«owlValue» {hasValue = USA} country : Country
«owlRestriction»
GermanCustomer
«owlValue» {hasValue = GERMANY} hasCountry : Country
«owlValue» {someValuesFrom=GermanCustomer} hasCustomer

TwoUse Metamodels Organization <is web>
M3 MOF
InstanceOf

UML OWL

M2
TwoUse

SPARQL


Transformation Process <is web>
UML Metamodel Grammar Ontology
Metamodel

M2 OWL Java
TwoUse
Abstract Syntax

Metamodel Metamodel
Metamodel
InstanceOf

UML 2.
OWL OWL
M1 TwoUse 2. 3.
Java Java

1.

Reasoner
Concrete

API
Syntax

UML UML UML
Profiled Profiled Profiled OWL
4TwoUse 4 OWL 4Java Java
RDF XML
PIM PSM PSM Source Code
Syntax

Key Messages <is web>
The Ontology can be:
 reused independently of platform;
 modeled and evolved independently of the execution logic;
 tested automatically by logical unit tests.
 Changes required for adoption are minor.



Thank You!

http://isweb.uni-koblenz.de/Projects/twouse

EU STReP MOST: http://www.most-project.eu

Related Publications <is web>
Silva Parreiras, F., Staab, S., Winter, A.: On marrying
ontological and metamodeling technical spaces. In:
ESEC/FSE’07, ACM Press
Silva Parreiras, F., Staab, S., Winter, A.: TwoUse: Integrating
UML models and OWL ontologies. Technical Report
16/2007.

Download at http://isweb.uni-koblenz.de



Ontology-based Domain Specific languages

ECMFA Tutorial on
Model-Driven Software Development with Semantic Web
Technologies

Tobias Walter

Objectives

 Motivation
• Scenario
• Requirements

 Ontology-based DSL Frameworks
• Design DSLs
• Use DSLs

 Conclusion


Scenario (Roles)

Metamodeling
Framework
specifies Language
Developer

uses

DSL
DSL Designer specifies defined in
Constraints
Metamodel
based on
uses

Guidance
DSL User Domain Model
builds and services

requires


Scenario
• Modeling physical devices, e.g. Cisco network devices
Cisco 7603: Domain Model:

Configuration
Slot HotSwappableOSM

Device
Slot SupervisorEngine

Slot

Restrictions modeling a Cicso7603 device:
• Every Cisco7603 has at least 1 Configuration7603
• Every Configuration has at least 1 Slot in which a
SupervisorEngine card is plugged in DSL Designer
• A Configuration7603 has exactly 3 Slots in which either a
HotSwappableOSM or SPAInterface card is plugged in.

Scenario (DSL User)
• Domain Model: (inconsistent)
DSL User

Configuration
HotSwappableOSM

Device Error

• Requirements of DSL User:
• Consistency Checking
• Debugging of domain models


Scenario (DSL User)
• Domain Model: (consistent)
DSL User

Configuration

Device Slot
Slot

• Validate incomplete models
• Guidance and explanations how to complete the model


Scenario (DSL User)
• Domain Model: (inconsistent)
DSL User

Configuration

Device
Explanation:
Slot Configuration hasSlot someError and
SPAInterface Slot
hasCard some SupervisorEngine



Scenario (DSL User)
• Domain Model: (consistent)
DSL User

Configuration7603
Configuration
Cisco7603

Device Slot SupervisorEngine

Slot

• Suggestions of suitable domain concepts
• Use of services without any extra effort

State of the Art
 Metamodel of Physical Device DSL (PDDSL) (M2 layer)
• Implemented using KM3 (a Java-like syntax)
• Simple to use and understandable
• But: Not effectual to define configurations with valid cards and slots
class Device {
reference hasConfiguration [1-*]: Configuration;
}

class Cicso7603 extends Device{
} DSL Designer
class Configuration {
reference hasSlot [1-*]: Slot;
}

class Configuration7603 extends Configuration{
}

class Slot {
reference hasCard [1-*]: Card;
}

class Card {
}


Proposed Solution
Ontology-based framework for domain-specific languages
 Integrate KM3 with ontology language OWL2
• Provide a metamodeling language to specify
Framework further DSLs
Developer

 Design Domain Specific Languages
• Develop new DSL with integrated constraints
DSL Designer and axioms

 Use domain-specific languages
• Builds domain models and uses services
DSL User

Model-based Integration Architecture
• Framework Developer
• Provide framework for designing and using DSLs
• DSL Designer
• Defines abstract Syntax, concrete Syntax, semantics
• DSL User
• Builds domain models

Development Environment
Framework
Integrated Metametamodel
Developer
KM3 OWL
Metametamodel Metamodel
:M3
instanceOf instanceOf
Ontology Definition
Domain Definition
DSL Integrated Model
M2': Metamodel Visualization (Abstract Syntax) :M2 TBox
Designer (Concrete Syntax)
Constraints / Axioms
transform OWL Reasoning
instanceOf Ontology Service
DSL User M1': Domain Model transform ABox


Integrated Modeling
• Metamodel of PDDSL
class Device {
reference hasConfiguration [1-*]: Configuration;
}
DSL Designer

class Cisco7603 extends Device, equivalentWith restrictionOn hasConfiguration
{
with min 1 Configuration7603 {
}

class Configuration equivalentWith
{
IntersectionOf(restrictionOn hasSlot with min 1 Slot,
restrictionOn hasSlot some
restrictionOn hasCard some SupervisorEngine) {
reference hasSlot : Slot;
}

class Configuration7603 extends Configuration ,
{
equivalentWith IntersectionOf(restrictionOn hasSlot with exactly 3 Slot,
restrictionOn hasSlot with some
restrictionOn hasCard with some
UnionOf(HotSwappableOSM, SPAInterface) {
}

class Slot {
reference hasCard [1-*]: Card;
}

Benefits of DL in Domain Modeling

 Open World Assumption
• assumes incomplete information by default
• guidance and validation of incomplete models

 Joint semantic definitions at 2 layers
• M1- and M2 layer affect each other
• simultaneously reasoning at M1- and M2 layer

 Debugging and reasoning explanation
• identifying debugging-relevant facts (e.g. model elements)
which lead to inconsistency with regard to the metamodel
• explanations of errors in domain models


Conclusion
 Framework Developer
• Integration of KM3 and OWL at the M3 layer
• Provide metamodeling language that allows
Framework
Developer designing metamodels with embedded OWL
Constructs

 DSL Designer
• Specifies new DSLs with additional, integrated
DSL Designer constraints

 DSL User
• Builds domain models
DSL User • Gets services and guidance for free

Discussion…

… Questions?



OWLizer and Linked
Data in Model Driven Engineering

Fernando Silva Parreiras

What You Should Be Able to Do

 At the end of this unit you will be able to:
• Translate multiple software languages into OWL
• Write queries over multiple software artifacts
• Address problems like impact analysis with ontology
technologies.

WeST Fernando Silva Parreiras ECMFA Tutorial
parreiras@uni-koblenz.de 2 of 45

Scenario


Linked Data

 „Linked Data is about using the Web to connect related
data that wasn't previously linked, or using the Web to
lower the barriers to linking data currently linked using
other methods. “


Requirements

 Extend modeling languages with new capabilities
 Identification of same or similar concepts in different
languages:
 Integration Management


Features

 Consistent view over multiple MOF Models
 Integrated well-formedness constraints
 Dependency checking
 Query Answering


Integrating OWL and Ecore


OWLizer: Mapping MOF and OWL


OWLizer Example


SPARQLAS Queries

Which Tasks realize Use Case Querying?

Namespace: = <http://www.eclipse.org/uml2/3.0.0/UML#>
Select ?name
Where: _:u name "Querying"^^xsd:string
_:u includeUseCases ?uc
?uc ownedBehavior ?act
?act node ?node
?node type OpaqueAction
?node name ?name


SPARQLAS Queries
What Use Cases do I have to test If I update the component
west.twouse.reasoner?

Namespace: uml = <http://www.eclipse.org/uml2/3.0.0/UML#>
Namespace: srs = <http://west.uni-koblenz.de/SRS#>
Namespace: mf = <http://west.uni-
koblenz.de/EclipseManifest#>
Select ?name
Where: ?component mf:name
"west.twouse.reasoner"^^xsd:string
?component srs:requirement ?requirement
?requirement srs:useCase ?uc
?uc uml:name ?name
Union:
?uc (inverse uml:addition o uml:includingCase) ?iuc
?iuc uml:name ?name

Key Message

 With OWLizer, you can transform any Ecore-based
software language into OWL
 With OWL constructs like sameAs and EquivalentWith, you
connected similar concepts and instances over different
languages
 With SPARQLAS queries, you query multiple software
artifacts


THANK YOU!


Fakultät Informatik Institut Software- und Multimediatechnik, Lehrstuhl Softwaretechnologie

Feature-based Derivation of
Ontology-Enabled Tool
Environments

Motivation

Ontology-driven Software Development

• ODSD denotes our vision to address current MDSD challenges by contribution of ontology
services
• ODSD is a generic approach with several variability dimensions
• Languages used in development processes
• Customisation of ontology technology for scalable reasoning
• Customised guidance for specific development processes
• Techniques for bridging modelling and ontology technology spaces
• Repository infrastructure
• …

• Tool environments are a vital factor of productivity and applicability of ODSD

• MOST demonstrators are organised in a product-line of ODSD tool environments – MOST
TOPF
• reuse & customisation of generic infrastructure
• Derivation of use-case specific variants

Christian Wende, TU Dresden 2

Development Process MOST TOPF

Application of ODSD in the development of the MOST TOPF
• Ontology-driven software product line engineering
• MOST TOPF development is itself a case study for ODSD

MOST Tool Product Family Engineering

(1) Variability
(2) Feature Realisation (3) Feature Mapping
Specification

Feature Model for MOST Mapping
Most TOPF Model
MOST TOPF
Architecture

< variant of >
OSGS
Variant Model for
Software Process
Guidance System Feature-driven Workbench
Instantiation

(4) Variant
Specification (5) Variant Derivation

Workbench Instantiation

(1) Variabilty Specification:
MOST TOPF Feature Model

Variability of Languages

MOST Tool Product Family

Metamodelling Technical Space

Metamodelling Language
Modelling Language
FODA ADOxx

BPMN EMF
BE-DSL
TGraphs/GrUML
UML
PDI-DSL
PD-DSL


Variability of Ontology Technology


Ontological Technical Space Ontology Language
Reasoner RDFS
World Assumption
Pellet RDFS(FA)
Open World
Fact+ OWL Full
Closed World
TrOWL OW2
REL OWL FA


Variability of Guidance


Software Process Guidance

MDE Process

SAP Process

Comarch Process

MOST Process

Tracing

Semantic Validation

Model-Driven Software Development with Semantic Web Technologies

Model-Driven Software Development with Semantic Web Technologies

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Model-Driven Software Development with Semantic Web Technologies

Ähnlich wie Model-Driven Software Development with Semantic Web Technologies (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Model-Driven Software Development with Semantic Web Technologies