model-driven software development with semantic web technologies

Web Science & TechnologiesUniversity of Koblenz ▪ Landau, Germany

Model-Driven Software Development with Semantic Web Technologies

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

Tobias [email protected]

ECMFA Tutorial2 of 7

WeST

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

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.



WeST

Administrative Information

Facilities Coffee Break

• 10:30 – 11:00• 16:00 – 16:30

Lunch• 12:30 – 14:00



WeST

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 60min4. 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



WeST

Meet Your Classmates

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

<is web> Information Systems & Semantic WebUniversity of Koblenz ▪ Landau, Germany

What are ontologies and what canthey do for MDSD

Fernando Silva Parreiras, Edward Thomas

<is web>

ISWeb - Information Systems & Semantic Web

Fernando Silva [email protected]


What is this unit about

This unit presents the basic concepts of ontology and ontology technologies and illustrate the application of ontologies with well-kown use cases.

<is web>




What You Should Be Able to Do

At the end of this unit you will be able to:• Understand the basic concepts of ontologies• Identify the usage of ontologies in MDE

<is web>




Rationale of this Talk

Core Statements:Ontologies are yet another type of Conceptual Models

Ontologies are used differently and with different technology than UML usually is

Hypotheses:1. Ontologies and SE modeling

may be integrated by MDE!

2. New possibilities for SE!

A Generic Process of MDA + Ontology Technologies

Advantages

<is web>




Agenda of this Talk

Part 1: What is an ontology? Definition Purpose, Usage, Formality, Type, Communities

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

<is web>




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

Based on Gruber 93:

An Ontology is aformal specificationof a sharedconceptualizationof a domain of interest

⇒ Executable, Discussable⇒ Group of persons⇒ About concepts⇒ Between application

and „unique truth“

<is web>




Purpose: What is an ontology?

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

<is web>




Usage: What is an ontology?

Front-End

Back-End

Topic Maps

Extended ER-Models

Thesauri

Predicate Logic

Semantic Networks

Taxonomies

Ontologies

Navigation

Queries

Sharing of KnowledgeInformation Retrieval

Query Expansion

Mediation Reasoning

Consistency CheckingEAI

<is web>




lightweight heavyweight

Text Corpora

DataDictionaries

(EDI)

Ad-hocHierarchies

(Yahoo!)

Folks-onomies

Glossaries

Thesauri

XMLDTDs

PrincipledInformal

Hierarchies

DBSchema

XMLSchema

Data Models(UML, STEP)

FormalTaxonomies

Frames(OKBC)

DescriptionLogics

Glossaries &Data Dictionaries Thesauri,

Taxonomies

MetaData,XML Schemas,Data Models

Formal Ontologies& Inference

First-order,Higher-order,Modal Logic

F-Logic

Formality: What is an ontology?

<is web>




Example: What is an ontology?

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

<is web>




Agenda of this Talk

Part 1: What is an ontology? Definition Purpose, Usage, Formality, Type, Communities

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

<is web>




Model-driven Architecture

Classical MDA

PIM PSM Code

JAVAUML UML

A Standard Process

<is web>




MDA & Ontology Case 1: Model Checking

Reasoning on UML class diagrams

Classical MDA

PIM PSM Code

Translation

OWL

JAVAUML UML

<is web>




Model Checking

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.

<is web>




Model Checking: Example

UserAccount User0..n 10..n 1Owns

Student

Uses {complete, disjoint}

WebPortalAccount Researcher1..n0..1

Researcheris disjoint from

Student

if Researcher is empty, User and Student will be

redundantINCONSISTENT

<is web>




Model Checking: Example

UserAccount User0..n 10..n 1Owns

Student

Uses {complete, disjoint}

WebPortalAccount Researcher1..n0..1

INCONSISTENT

Advantage for SE:

Models with provably higher quality

<is web>




MDA & Ontology Case 2: Hybrid Models

Integrating UML Models and OWL Ontologies: TwoUseTwoUse: Transforming and Weaving Ontologies and UML for SE

Classical MDA

PIM PSM Code

OWL

JAVAUML UML

Previously:

Ontology Engineering

Software Engineering

TwoUse:

Combined Ontology &

Software Engineering

<is web>




MDA & Ontology Case 4: Hybrid Models

Case: Integrating UML Models and OWL Ontologies with TwoUse

PIM PIM Code

. . .

M2

M1

InstanceOf

PIM

UML Profiled Diagram

OWL Ontology

UML Class Diagram Java CodeTwoUse

Model

OWL(ODM)

UML/OCL

TwoUseMetamodel

<is web>




FreeTradeZone

Country

Customer PurchaseOrder

getCharges()

ProductName: String

UML

+hasProduct

+hasResident

+memberOfTradeZone+hasMember

+hasOrder

+hasCustomer

+livesIn

Hybrid Model: Example UML

1 0..n1..n

1

<is web>




FreeTradeZone

Country

Customer PurchaseOrder

getCharges()+has

Resident+memberOfTradeZone

+hasMember

+hasOrder

+hasCustomer

+livesIn

Hybrid Model: Example OWL

<<owlValue>>+{someValuesFrom = CountryFromEU}

<<owlRestriction>> CountryFromEU

<<owlValue>> {hasValue = eu} memberOfTradeZone : FreeTradeZone

livesIn

<<owlRestriction>> OrderFromEUCustomers

<<equivalentClass>>

+{someValuesFrom= CustomersFromACountry } <<owlValue>>

<<owlRestriction>> CustomerFromEUCountry

DutyFreeOrder = OrderFromEUCustomer

1 0..n1..n

1

<<owlRestriction>> DutyFreeOrder

hasCustomerOrdersFromEUCustomers hasCustomer SOME

CustomerFromEUCountries

OWL (ODM)

<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)

MDA with Ontologies

Classical MDA

PIM PSM Code

OWL

JAVAUML UML

<is web>




Key Messages for this Unit

Hypotheses:1 Ontologies and SE

modeling integrated by MDE (specifically MDA)!

2 New possibilities for SE!

A Generic Process

Advantages

Classical MDA

PIM PSM Code

OWL

JAVAUML UML

Joint engineering of ontologies and SE models.

Models with provably higher quality.


Thank You!

Model-Driven Software Development with Semantic Web TechnologiesDemystifying OWL

Edward ThomasUniversity 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

INTRODUCTION TO OWL & DESCRIPTION LOGICS

Demystifying OWL

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 SyntaxhasChild some (Doctor and (hasChild only Female))

OWL Functional SyntaxSomeValuesFrom (hasChild IntersectionOf ↲(Doctor AllValuesFrom (hasChild Female))

2009-05-26

TBox Syntax Boolean Operators

2009-05-26

DL Manchester ExampleIntersection ⊓ and Rich and DoctorUnion ⊔ or Doctor or LawyerComplement ¬ not not Lawyer

TBox Syntax Restrictions

2009-05-26

DL Manchester ExampleExistential ∃ some eats some fruitUniversal ∀ only eats only fruitExact value ∋ value eats value bambooMin cardinality ≥ min hasChild min 3Max cardinality ≤ max hasChild max 3Exact cardinality = exactly hasChild exactly 3

TBox Syntax Roles

2009-05-26

DL Manchester ExampleInverse ¯ inverse inverse eatsChain o eats o inhabits

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

http://www.w3.org/TR/owl-semantics/semantics-all.html�

http://www.w3.org/TR/owl-semantics/semantics-all.html�

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 AnimalShark SubClassOf: eats only FishFish 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 languageEL Intersection and existential qualificationF Functional propertiesE Full existential qualificationU Concept unionC Complex concept negationS ALC with transitive rolesO NominalsI Inverse propertiesN Cardinality restrictionsQ 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

THE OWL FAMILYDemystifying OWL

2009-05-26

The family tree

OWL 2 DL

OWL 1 DL

OWL 2 QL

OWL 2 RL OWL 2 EL

SROIQ

SHOIN

DL-Lite

EL++

OWL 2 Full

In AC0

PTime-Complete

NExpTime-Complete

2NExpTime-Complete

Undecidable

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

OPEN VS. CLOSED WORLDDemystifying OWL

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

UNIQUE NAME ASSUMPTIONDemystifying OWL

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

TOOLS AND RESOURCESDemystifying OWL

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

QUESTIONSDEMONSTRATION

Demystifying OWL

2009-05-26


Reasoning with OWL in Software Models

ECMFA Tutorial onModel-Driven Software Development with Semantic Web

Technologies

Tobias Walter



WeST

Objectives

Context Software Languages Ontology Languages

Language Bridges Transforming Software Languages to OWL Integrating Software Languages with OWL

Services Reasoning Services Querying Services



WeST

Context (Model Hierarchy)

Model hierarchy

Language User

Language Designer



WeST

Context (Metametamodel)

Ecore M3 metametamodel



WeST

Basics (Metamodel)

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

Language Designer



WeST

Basics (Metamodel) Ecore-based metamodel (Activity Diagram) conforms to Ecore M3 metametamodel visualized using textual concrete syntax

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 { }class ControlFlow extends ActivityEdge { }

Language Designer



WeST

Basics (Model)

Model (Activity Diagram) designed by language user

Language User



WeST

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



WeST

Ontologies as Software Models

OWL2 Metamodel (excerpt)



WeST

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)



WeST

OWL2 Ontology (Example)

Manchester Style Syntax (frame-based)Class: ActivityEdge

SubClassOf: owl:Thing

Class: ActivityNodeSubClassOf: owl:Thing

ObjectProperty: toDomain: ActivityEdgeRange: ActivityNode

ObjectProperty: outgoingDomain: ActivityNodeRange: ActivityEdge

ObjectProperty: fromDomain: ActivityEdgeRange: ActivityNode

ObjectProperty: incomingDomain: ActivityNodeRange: ActivityEdge

Individual: action1Types: Action



WeST

Comparing Ecore with OWL

Many similar constructs

Reasoners use logic-based language Representation of software models in a logic-based language

We need bridges!

Ecore OWLpackage ontologyclass classinstance and literals individual and literalsreference, attribute data propertydata types data typesenumeration enumerationmultiplicity cardinalityOpposite reference Inverse object properties



WeST

Software Language Bridges

2 kinds of Language Bridges M3 Transformation bridge M3 Integration bridge



WeST

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



WeST

M3 Transformation Bridge

OWLizer Transforming Software Metamodels to Ontology TBox Transforming Software Models to Ontology ABox

Language User

Language Designer



WeST

Ecore to OWL - OWLizer

Language User

Language Designer

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

of similiar constructs



WeST

Ecore to OWL - OWLizer

Language User

Language Designer

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

ObjectPropertyDomain(to ActivityEdge)ObjectPropertyRange(to ActivityNode)ObjectPropertyDomain(from ActivityEdge)ObjectPropertyRange(from ActivityNode)

...

ClassAssertion(A Action)ClassAssertion(B Action)ClassAssertion(C Action)

ClassAssertion(e1 ObjectFlow)ClassAssertion(e2 ObjectFlow)

ObjectPropertyAssertion(to e1 B)ObjectPropertyAssertion(from e1 A)

...

use of transformationbrdige

use of transformationbrdige



WeST

Extending Software Metamodels

Integration of Ecore Technical Space with OntologyLanguage OWL2

Integration of abstract Syntax• OWL2 metamodel + Ecore Metametamodel

Integration of concrete Syntax• OWL2 concrete syntax + Ecore concrete Syntax

Create Ecore-based metamodels with integrated• OWL2 axioms• OWL2 expressions



WeST

Integration of abstract Syntax

Metamodel Integration by using Integration Operations Merge of concepts

Relation of concepts by• Specialization Relationship

• Association



WeST

Ecore Metametamodel + OWL2 Metamodel

Integration of abstract Syntax Result: Integrated Metametamodel



WeST

Textual Concrete Syntax for Coding Metamodels• Simple Syntax, similar to Java

Grammar (concrete Syntax):

Ecore concrete syntax

class ::= ["abstract"] "class" name [supertypes] "{" features "}";...

feature ::= attribute | reference;...

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

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

...



WeST

Example of Ecore Textual Concrete Syntax

(textual) Activity Diagram Metamodelabstract 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 { }class ControlFlow extends ActivityEdge { }



WeST

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};



WeST

Example

• Extended Metamodel of Activity Diagram (excerpt)class ActivityNode equivalentWith restrictionOn edge with some Final{reference incoming [0-*] : ActivityEdge oppositeOf target;reference outgoing [0-*] : ActivityEdge oppositeOf source;

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

...

class Initial extends ControlNode, subClassOf restrictionOn outgoing with some

(restrictionOn with some (Action or ControlNode)){

}



WeST

Reasoning Services

Consistency Checking Satisfiability Checking Classification

Subsumption Checking Explanation Querying



WeST

Consistency Checking

Name Consistency CheckingSignature 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, thenreturn true. Otherwise return false.

Pattern b = consistency (O)Input An Ontology OOutput b = true iff o is consistent,

b = false otherwise



WeST

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



WeST

Consistency Checking (Example)

class ActivityNode equivalentWith restrictionOn edge with some Final{reference incoming [0-*] : ActivityEdge oppositeOf target;reference outgoing [0-*] : ActivityEdge oppositeOf source;


Receive Order

M2 Metamodel

M1 ModelInconsistency:

Missing Edge toFinal Action



WeST

Satisfiability Checking

Name Satisfiability checkingSignature 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 thereis not any unsatisfiable concept.

Pattern b = GetUnsatisfiable (O)Input An Ontology OOutput b = NULL iff there is no unsatisfiable concept

b = a set of unsatisfiable concepts otherwise



WeST

Satisfiability Checking in Software Modeling

Accomplished Service 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)



WeST

Satisfiability Checking (Example)



class Final extends ControlNodesubClassOf (restrictionOn edge with some ActivityNode) and

not(restrictionOn edge with some ActivityNode){ }

M2 Metamodel

Unsatisfiable Class:two contradictory

restrictions



WeST

Classification

Name ClassificationSignature 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 iOutput b = true iff i is an instance of A,

b = false otherwise



WeST

Classification in Software Modeling

Accomplished Service 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

Benefits for Language Users Automatically Refinement of Model Elements Suggestions of suitable domain concepts to be used



WeST

Classification (Example)

class ObjectNode extends ActivityNodeequivalentWith ((restrictionOn incoming with some ObjectFlow)

and (restrictionOn outgoing with some ObjectFlow))

{ }

M2 Metamodel

M1 Model

Send Invoice Make PaymentInvoice

Classify Invoice NodeResult: It is of type

ObjectNode



WeST

Subsumption Checking

Name Subsumption CheckingSignature 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 ofthe interpretation of B, then return true. Otherwise returns false.

Pattern b = subsumes (O,A,B)Input An Ontology O and concepts A, BOutput b = true iff the interpretation of A is a subset of the interpretation

of B in the ontology O,b = false otherwise



WeST

Subsumption Checking in Software Modeling

Accomplished Service 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



WeST

Explanation

Name ExplanationSignature 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 AxOutput b = set of axiom that entail the given axiom Ax.

b = NULL otherwise



WeST

Explanation for Software Modeling

Accomplished Service Explanations for subsumptions and unsatisfiable classes in

metamodels Explanations for inconsistencies in models

Benefits for Language Designers Debugging of metamodels

Benefits for Language Users Debugging of models



WeST

Explanation (Example Unsatisfiability)



class Final extends ControlNodesubClassOf (restrictionOn edge with some ActivityNode) and

not(restrictionOn edge with some ActivityNode){ }

M2 Metamodel

Explanation from TwoUse Toolkit---------------------------------------Unsatisfiability of Final:Explanation:

Final equivalentTo not edge some ActivityNodeand edge some ActivityNode



WeST

Explanation (Example Inconsistency)



Receive Order

M2 Metamodel

M1 Model

Explanation from TwoUse Toolkit---------------------------------------CHECK CONSISTENCY

Consistent: No

Explanation: receiveOrder type ActionAction subClassOf ActivityNodeActivityNode equivalentTo edge some Final



WeST

Querying

Name Query answeringSignature 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 qOutput res = a set of answers of the query to the ontology iff there is a answer

setres = NULL if there is not any answer



WeST

Querying Service for Software Modeling

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

Benefits for Language Designers Retrieving information on concepts

Benefits for Language Users Retrieving existing and complex parts of models



WeST

Querying (Example) Find all actions, that are executed before „Ship Order“:

M1 Model

[orderaccepted]

Receive Order Close Order

Accept Payment

Ship OrderFill Order

Send Invoice Make Payment

Invoice

[orderrejected]

Query ( ClassAssertion(?i Action), ObjectPropertyAssertion(InverseInverseObjectProperties(edge)

?i shiporder))

Results:-----------------| c |=================| fillorder || receiveorder |-----------------



WeST

Querying (Example)

Find all unsatisfiable classes:

Find all concepts that do not go via edge to Final:

Query ( SubClassOf(?c owl:Nothing) )

Results:------------| c |============| Nothing || Final |------------

Query ( EquivalentClasses(?c Not(ObjectSomeValuesFrom(edge Final))))

Results:-------------------| c |===================| ActivityDiagram |-------------------



WeST

Discussion…

… Questions?

Information Systems & Semantic WebUniversity of Koblenz ▪ Landau, Germany

Information Systems & Semantic WebUniversity of Koblenz ▪ Landau, Germany

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

<is web>




This Talk is about

Software Design Patterns

Cla

ssifi

catio

n

Infe

renc

e

Varia

ntM

anag

emen

t

Factorization of common functionality

Algorithm Encapsulation

Choice of implementations

Sel ec tor

Pa tter n

Description Logics(OWL)

Weaving features of Description Logics into the Strategy Pattern under the variant management subset of software design patterns.

<is web>




Running Example

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.

<is web>




Strategy Pattern

How to improve it?

TaskController

so : SalesOrder

getRulesForCountry() : Taxprocess()

USTax GermanTaxCountry

name : String

TaxtaxAmount()

Customer

SalesOrderprocess(tax : Tax)

context TaskController::getRulesForCountry():Taxbody:if so.customer.country.name = 'USA' then

USTax.new()elseif so.customer.country.name = 'GERMANY' then

GermanTax.new()endif

endif

Drawbacks:

Tangling

Coupling

Context

StrategiesClient

2. 3.

4.

1.

<is web>




Building Blocks

- The TwoUse solutionUses an Ontology to describe Context and StrategiesClassifies dynamically the Context- Hybrid Diagram- Metamodel- Transformation Process

TaskController

so : SalesOrder

getRulesForCountry(): Taxprocess()

USTax GermanTaxCountry

name:String

TaxtaxAmount()

Customer

SalesOrderprocess(tax : Tax) Context

Strategies

Client

<is web>




Hybrid Diagram: Strategy Pattern + OWL

TaskController process()

(USSalesOrder)«owlClass»

USTax

«owlClass»Country

«owlClass»

Customer«owlClass»

TaxtaxAmount()

SalesOrder«owlClass»

process()getRulesForCountry()

«rdfSubClassOf»«rdfSubClassOf»

context SalesOrder::getRulesForCountry():OclTypebody:Select ?T where ?self directType ?T

USCustomer«owlRestriction»

«owlValue» {hasValue = USA} country : Country

«owlValue» {someValuesFrom=USCustomer} hasCustomer

GermanCustomer«owlRestriction»

«owlValue» {hasValue = GERMANY} hasCountry : Country«owlValue» {someValuesFrom=GermanCustomer} hasCustomer

«owlRestriction»

«equivalentClass»

«owlRestriction»

«equivalentClass»

UML

OWL

TwoUse

Dynamic Classification

GermanTax(GermanSalesOrder)

Reuse

Flexibility

No Coupling

No Tangling

<is web>




TwoUse Metamodels Organization

UML

SPARQL

TwoUse

MOFM3

M2

OWL

InstanceOf

<is web>




Transformation Process

PIM PSM Source Code

Java

UMLProfiled 4TwoUse

Con

cret

e S

ynta

xA

bstra

ct S

ynta

x M2

M1

UMLProfiled4Java

TwoUseJava Java

InstanceOf

Java MetamodelTwoUse

Metamodel

Metamodel Grammar Ontology

RDF XMLSyntax

OWL

OWLUML

Profiled4 OWL

OWL

PSM

1.

2.

2.

3.

OWL Metamodel

UML

UMLMetamodel

ReasonerAPI

<is web>




Key Messages

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!

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

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

<is web>




Related Publications

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

http://isweb.uni-koblenz.de/�


Ontology-based Domain Specific languages

ECMFA Tutorial onModel-Driven Software Development with Semantic Web

Technologies

Tobias Walter



WeST

Objectives

Motivation• Scenario• Requirements

Ontology-based DSL Frameworks• Design DSLs• Use DSLs

Conclusion



WeST

Scenario (Roles)

DSL User

DSL Designer DSLMetamodel

uses

specifies

Domain Modelbuilds

Metamodeling Language

uses

specifies

requires

Guidanceand services

Constraints

based on

defined in

Framework Developer



WeST

Scenario• Modeling physical devices, e.g. Cisco network devices

Cisco 7603:

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• A Configuration7603 has exactly 3 Slots in which either a

HotSwappableOSM or SPAInterface card is plugged in.

SupervisorEngine

HotSwappableOSMSlot

Slot

Slot

Configuration

Device

Domain Model:

DSL Designer



WeST

Scenario (DSL User)

• Requirements of DSL User:• Consistency Checking

• Debugging of domain models

HotSwappableOSM

Configuration

Device

• Domain Model:DSL User

(inconsistent)

Error



WeST

HotSwappableOSM

Scenario (DSL User)


• Debugging of domain models• Validate incomplete models

• Guidance and explanations how to complete the model

Slot

Slot

Slot

Configuration

Device


(consistent)



WeST

SPAInterface

HotSwappableOSM

HotSwappableOSM

Scenario (DSL User)



• Guidance and explanations how to complete the model

Slot

Slot

Slot

Configuration

Device


(inconsistent)

ErrorErrorErrorExplanation:Configuration hasSlot some Slot and hasCard some SupervisorEngine



WeST

SupervisorEngine

Scenario (DSL User)



• Guidance and explanations how to complete the model• Suggestions of suitable domain concepts• Use of services without any extra effort

HotSwappableOSMSlot

Slot

Slot

Configuration

• Domain Model:DSL UserConfiguration7603

Device

Cisco7603

(consistent)



WeST

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{}

class Configuration {reference hasSlot [1-*]: Slot;

}

class Configuration7603 extends Configuration{}

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

}

class Card {}

DSL Designer



WeST

Proposed Solution

Integrate KM3 with ontology language OWL2• Provide a metamodeling language to specify

further DSLs

Design Domain Specific Languages• Develop new DSL with integrated constraints

and axioms

Use domain-specific languages• Builds domain models and uses servicesDSL User

DSL Designer

Ontology-based framework for domain-specific languages

Framework Developer



WeST

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

Integrated Metametamodel

:M3

:M2Integrated Model(Abstract Syntax)

Domain Model

instanceOf

instanceOf

KM3Metametamodel

OWL Metamodel

Constraints / AxiomsOWL

Ontology

instanceOf

ABox

TBox

Reasoning Service

M2':

M1':

Domain Definition Metamodel

(Concrete Syntax)transform

transform

Development Environment

Ontology Definition

Visualization

DSL User

DSL Designer

FrameworkDeveloper



WeST

Integrated Modeling• Metamodel of PDDSLclass Device {reference hasConfiguration [1-*]: Configuration;}

class Cisco7603 extends Device

}

class Configuration

reference hasSlot : Slot;}

class Configuration7603 extends Configuration

}

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

}

, equivalentWith restrictionOn hasConfigurationwith min 1 Configuration7603 {

{

equivalentWithIntersectionOf(restrictionOn hasSlot with min 1 Slot,

restrictionOn hasSlot somerestrictionOn hasCard some SupervisorEngine) {

{

,equivalentWith IntersectionOf(restrictionOn hasSlot with exactly 3 Slot,

restrictionOn hasSlot with somerestrictionOn hasCard with some

UnionOf(HotSwappableOSM, SPAInterface) {

{

DSL Designer



WeST

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



WeST

Conclusion Framework Developer• Integration of KM3 and OWL at the M3 layer• Provide metamodeling language that allows

designing metamodels with embedded OWL Constructs

DSL Designer• Specifies new DSLs with additional, integrated

constraints

DSL User• Builds domain models• Gets services and guidance for freeDSL User

DSL Designer

Framework Developer



WeST

Discussion…

… Questions?


OWLizer and Linked Data in Model Driven Engineering

Fernando Silva Parreiras



WeST

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

Scenario



WeST

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. “



WeST

Requirements

Extend modeling languages with new capabilities Identification of same or similar concepts in different

languages: Integration Management



WeST

Features

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



WeST

Integrating OWL and Ecore



WeST

OWLizer: Mapping MOF and OWL



WeST

OWLizer Example



WeST

SPARQLAS Queries

Which Tasks realize Use Case Querying?

Namespace: = <http://www.eclipse.org/uml2/3.0.0/UML#>Select ?nameWhere: _:u name "Querying"^^xsd:string

_:u includeUseCases ?uc?uc ownedBehavior ?act?act node ?node?node type OpaqueAction?node name ?name



WeST

SPARQLAS Queries

What Use Cases do I have to test If I update the componentwest.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 ?nameWhere: ?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



WeST

Key Message

With OWLizer, you can transform any Ecore-basedsoftware language into OWL

With OWL constructs like sameAs and EquivalentWith, youconnected similar concepts and instances over different languages

With SPARQLAS queries, you query multiple softwareartifacts



WeST

THANK YOU!

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

Feature-based Derivation of Ontology-Enabled Tool Environments


Christian Wende, TU Dresden 2

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


Development Process MOST TOPF

MOST Tool Product Family Engineering

Workbench Instantiation

MOST TOPF Architecture

Feature Model for Most TOPF

MOST Mapping Model

(1) VariabilitySpecification (2) Feature Realisation (3) Feature Mapping

(4) VariantSpecification

Variant Model forSoftware Process Guidance System

(5) Variant Derivation

OSGS

Feature-driven Workbench Instantiation

< variant of >

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


(1) Variabilty Specification: MOST TOPF Feature Model

Modelling Language

BPMN

UML

Metamodelling Language

ADOxx

EMF

TGraphs/GrUML

MOST Tool Product Family

Metamodelling Technical Space

FODA

BE-DSL

PDI-DSL

PD-DSL

Variability of Languages



Ontology Language

RDFS

RDFS(FA)

OWL Full

OW2

OWL FA

Reasoner

Pellet

Fact+

TrOWL


REL

Ontological Technical Space

World Assumption

Open World

Closed World

Variability of Ontology Technology




Software Process Guidance

MDE Process

SAP Process

Comarch Process

MOST Process

Tracing

Semantic Validation

Variability of Guidance



Transformation Technology Mediation

Integration

CompositionModelling Level

M0 - System

M1 - Model

M2 - Metamodel

M3 - Metametamodel

Mapping/Transformation

ATL

QVT

Plain Java

Environment

Runtime

Design Time

Directionality

Bi-directional

Unidirectional


Variability of Bridging Technology




Repository Infrastructure

Database

File System

Variability of Repository Infrastructure


(2) Feature Realisation: Generic Architecture for ODSD Tools


(2) Feature Realisation: Configuration of TrOWL

// trowl.properties

TODO include Edwards example config

I send him an email

TrOWL Customisation of Reasoning Technology

• TrOWL is a configurable, transformation based, tractable reasoner for OWL2

• Supports configuration of:• OWL dialect• Reasoner• Approximation techniques• OWA/CWA/CDA

• Configuration affects• Characteristics of reasoning services

(completeness, soundness)• Performance• Expressiveness• Ontology size scalability


(3) Feature Mapping: Mapped OSGS Component Architecture

* Feature modelexcerpt

Manual featuremapping


// trowl.properties

TODO include Edwards example config

I send him an email

(3) Feature Mapping: Mapped TrOWL Configuration


Manual featuremapping


(4) Variant Specification: Feature model constraints ensure validity


Manual variantrefinement


(5) Variant Derivation: Automatic derivation of MOST TOPF Instance

Derivation Steps• Variant model is used together with feature mapping and component diagram to

derive variant specific component diagram

Automatic VariantDerivation

// custom trowl.properties



Application of Ontology Technology in Software Product Line Engineering

Variability Modelling

• Extended Feature Models (Kang, 1990) for variability modeling• Mandatory and optional features

• E.g. Tracing, MDE Process

• Feature groups (and, or, xor)• E.g. SAP Process, Comarch Process, MOST Process

• Feature constraints (requires, conflicts)• E.g. SAP Process requires BPMN Language

• Ontology-based feature models verification (Pan, 2007)• Generate ontology that encodes variability constraints

and use reasoning to check for consistency• Report contradicting constraints, etc.


MDE Process

SAP Process

Comarch Process

MOST Process

Tracing

Semantic Validation

OntologyConsistency




Feature Mapping

• Mapping Model stores mappings of features/feature terms to solution space artefacts (e.g., UML components)

• Mappings are checked for completeness (feature exists, component exists)

• Ontology-based feature term verification• Feature Terms: logical expressions on features

(and, or, not) that are mapped to solution space artifacts• Verified against feature model constraints• Invalid terms are reported and can not be mapped


MDE Process

SAP Process

Comarch Process

MOST Process

Tracing

Semantic Validation

Ontology

Consistency

SAP Process andComarch Process

UML Component X




Variant Configuration

• Variant models describe a subset of the features in a feature model required for a specific use case

• Need to conform to variability defined in feature model• Mandatory features• Group constraints• Feature constraints

• Ontology-based variant verification (Pan, 2007)• Generate ontology that encodes variability constraints

of feature model and a specific variant model• Report inconsistencies in variant configurations


MDE Process

SAP Process

Comarch Process

MOST Process

Tracing

Semantic Validation

OntologyConsistency


MDE Process

SAP Process

Tracing

Semantic Validation




Comprehensible Product Line Validation

• Outline/Idea Models PapierSoftware Process Guidance

MDE Process

SAP Process

Comarch Process

MOST Process

Tracing

Semantic Validation

OntologyConsistency


MDE Process

SAP Process

Tracing

Semantic Validation


DEMO

Validating Process Refinement with Ontologies

ISWeb – Information Systems & Semantic Web

University of Koblenz-Landau, Germany

Yuan Ren1, Gerd Gröner2, Jens Lemcke3, Tirdad Rahmani3, Andreas Friesen3, Yuting Zhao1, Jeff Z. Pan1 and Steffen Staab2

1University of Aberdeen, 2University of Koblenz-Landau and 3SAP AG

Agenda

• Background

• Motivation & Research Question

• Process and Process Refinement

• Ontological Process Refinement Validation

• Summary & Future Work

ISWeb – Information Systems& Semantic Web

Gerd Grö[email protected] 2

Background (1)

• Model Driven Software Development (MDSD)• General Problems from Knowledge Representation

(KR) perspective:

Representational ViewLack of formal semantics in modeling languages

e.g. metamodel to check syntax but not semantics of a model Operational View

Reasoning tasks are not well automated



Background (2)

• Ontology Driven Software Development (ODSD) Using ontologies to formalize models Modeling relationships between artifacts Inferring relationships between artifacts, e.g.

traceability relationships Ensuring semantic correctness by constraint

validation Guiding the development by reasoning (reasoning in

process/model development)



Background (3)

• Process modeling and management plays an important role in software development Process is general representation for control flow,

data flow and workflows Process as the planning and abstraction of

procedures Process as an interaction network of tasks, artifacts

and actors



Motivation

• Process refinement is a crucial task in process modeling and management

• Problems during development

Processes are developed by multiple people in various steps

A change might impact the overall consistency

(Current) manual checking is time-consuming and error-prone

Errors are expensive: Remodeling

Hidden errors



Research Question

• Can ontologies capture the dynamic aspects of the domain, particularly the changing of a process model Formalization of graph-based models Interpretation of refinement constraints Representation and validation of refinement

constraints

• Challenges Ensuring the specific process preserving the

intended meaning of the generic process Providing efficient reasoning service



Process in BPMN



A simple flow:

Loop:

Flow can go back to previous activity or gateway

Parallel gateway:

Flow go through all the branches

Exclusive gateway:

Flow go through one and only one of the branches

Execution Set Semantics



Parallel gateway:

{a1b1b2a2, a1b1a2b2, a1a2b1b2, a1a3}

Simple Flow:

{AB}

Loop:

{C, D, CC, CD, DC, DD, CCC, CCD, CDC, CDD,…}

Exclusive gateway:

{E, EF}

Process Refinement (horizontal)



{AB}1. Getting the execution sets

{a1b1b2a2, a1b1a2b2, a1a2b1b2, a1a3}

{AB}2. Renaming {ABBA, ABAB, AABB, AA}

{AB}3. Decomposition {ABA, ABAB, AB, A}

4. Validation: invalid

How to represent and reason in an ontology?

Process Normalization



1. Eliminating parallel gateways: Executions remain the same

Predecessor sets:

PS(b11) = {a11};

PS(a21) = {b11}, etc.

Successor sets:

SS(b11) = {a21,b22};

SS(a21) = {b21}, etc.

Execution sets subsumption can be reduced to PS/SS sets subsumptions [Theorem2];

Exponential complexity (O(n!))

2. Reduce execution sets to predecessor and successor sets:

Refinement Representation (horizontal)



• In pre-refinement process:Component_A subclassOf to only (Component_A or Component_B);Component_B subclassOf from only (Component_B or Component_A);

• In post-refinement process:a31 subclassOf to some Endb11 subclassOf (to some b22) and (to some a21);

3. Renaming:a31 subclassOf Component_A;

b23 subclassOf Component_B;

Invalid

4. Uniqueness:Disjoint(Start, End, Component_A, Component_B)

Refinement Representation

• A process refinement step is represented in the refinement ontology

Normalize the process (only XOR-gateways)

Represent activities as concepts

Represent orderings and composition relations as properties

Pre-refinement relations by universal restrictions

Post-refinement relations by existential restrictions

Uniqueness of activities by disjointness



Refinement Checking

• Given a refinement ontology an activity is valid iffits concept is satisfiable

A process refinement is valid iff all the concepts in the refinement ontology are satisfiable

A path is unexecutable iff any of its activity is unsatisfiable in the refinement ontology



Computational Property

• Complexity of refinement ontology: ALC

• Unsatisfiability checking

Worst-case: ExpTime-complete Improvement: Approximation

• Transformation/Normalization

Worst-case: n!• Evaluation result: reasoning more complex than

transformation (order of magnitude 3)



Comparison to other Approaches – Related Work

• Temporal Logic and Model Checking

Refinement specification in LTL

• Process Algebra and Model Checking

Refinement specification in process algebra

• Communication and Transition System Calculus, e.g. ∏-calculus

• OWL and DL models

Modeling of activity pre- and postconditions

Ontologies for annotations

Process refinement and validation is not (directly) considered



Summary & Future Work

• Results

Ontologies are used to compensate the lack of formal semantics in models (BPMN models)

Reasoning is used to check semantic constraints

• Next Steps

Optimization of reasoning (PTIME via approximation)

Extended process models (further gateways)

Non-pairwised gateways (e.g. nested gateways)

Generalized refinement solution for other models



model-driven software development with semantic web technologies

Technology

mdsd fernando silva

theapplication of semantic

semantic web skills

semantic web tools

fernando owlizer

fernando 30min2

classwesttobias walter

ontology technologies