Model-driven Software Engineering with Description Logicsstaab/Presentations/staab-dfki... ·...

WeST – Web Science & TechnologiesUniversity of Koblenz ▪ Landau, Germany

Model-driven Software Engineering

with Description Logics

Steffen StaabWith Fernando Parreiras, Gerd Gröner, Tobias Walter

Universität Koblenz-Landau

Steffen Staab [email protected]

WeST – Web Science & Technologies 2

Semantic WebDr. Janik

Web RetrievalDr. Sizov

Interactive WebDr. Scherp

Multimedia WebDr. Grzegorzek

Software WebF. Silva Parreiras

Prof. Dr. Staab Prof. Dr. Sure

EU WeGovEU X-Media

HP Synth DocsEU WeKnowItDFG Multipla EU Most

BMBF CollabCloudEU NeOn

EU Tagora

Who we are

GESISProf. Sure

EU WeGovEU ASG

EU aceMediaEU kspace

EU Net2



Two Worlds of Models

MDA / MDE

IngredientsModels: representing complementary views of a system

StructuralBehavioral

Metamodeling: Linguistic instantiation of syntactic class descriptionsTransformations:Towards target platformAdding refinements

Description Logics / Ontologies

IngredientsOntologies: representing complementary views of a system

Structural(Behavioral)

Metamodeling: Ontological instantiation of logical class descriptions Transformations:Between knowledge bases/ontologies

MOST – Marrying Ontology and Software Technologies



Model-driven Engineering

Refinements in several dimensionsRefinements along metamodeling levels

DSL User

DSL DesignerDSL

Metamodel

uses

specifies

Domain Modelbuilds

Metamodeling Language

uses

Framework Developer specifies

M1

M2

M3




Refinements in several dimensionsRefinements along metamodeling levelsRefinements along model specification

From business developer to software developer




Refinements in several dimensionsRefinements along model specification

From business developer to software developerRefinements along metamodeling levelsRefinements along platform specification

For Ontology Translations

Classical MDA

PIM PSM Code

JAVAUML UML





From business developer to software developerRefinements along platform specification

For Ontology TranslationsRefinements along time

Metamodel evolution• Suggesting changes to transformations

by DL reasoningOntology API Co-evolution



Agenda

Description Logics Reasoning by Example

Refinements in several dimensionsRefinements along metamodeling levels [Models 2009]Refinements along model specification [DL 2009]

• From business developer to software developerRefinements along platform specification [ER 2008]

• For Ontology TranslationsRefinements along time

• Metamodel evolution [submitted]– Suggesting changes to transformations

by DL reasoning• Ontology API Generation/Co-evolution [ICSC 2009]




Reasoning on UML class diagrams

Classical MDA

PIM PSM Code

Translation

OWL

JAVAUML UML

[Calvanese et al, AIJ 2005]



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.



Model Checking: Example

Every

WebPortalAccount

is used by at

most one Researcher

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



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



Agenda



• From business developer to software developerRefinements along platform specification


• Metamodel evolution– Suggesting changes to transformations

by DL reasoning• Ontology API Generation/Co-evolution



Scenario (Roles)

DSL User

DSL Designer DSLMetamodel

uses

specifies

Domain Modelbuilds

Metamodeling Language

uses

Framework Developer specifies

requires

Guidance and services

Guidance and services

ConstraintsConstraints

based on

defined in



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

Cisco 7603:

Restrictions modeling a Cicso7603 device:• Every Cisco7603Cisco7603 has at least 1 Configuration7603Configuration7603• Every ConfigurationConfiguration has at least 1 SlotSlot in which a

SupervisorEngineSupervisorEngine card is plugged in• A Configuration7603Configuration7603 has exactly 3 SlotsSlots in which either a

HotSwappableOSMHotSwappableOSM or SPAInterfaceSPAInterface card is plugged in.

SupervisorEngine

HotSwappableOSMSlot

Slot

Slot

Configuration

Device

Domain Model:

DSL Designer



Scenario (DSL User)

• Requirements of DSL User:• Consistency Checking

• Debugging of domain models

HotSwappableOSM

Configuration

Device

• Domain Model:DSL User

(inconsistent)

Error



HotSwappableOSM

Scenario (DSL User)

Slot

Slot

Slot

Configuration

Device


(consistent)


• Debugging of domain models• Validate incomplete models

• Guidance and explanations how to complete the model



SPAInterface

HotSwappableOSM

HotSwappableOSM

Scenario (DSL User)

Slot

Slot

Slot

Configuration

Device


(inconsistent)



• Guidance and explanations how to complete the model

ErrorErrorErrorExplanation:ConfigurationConfiguration hasSlot some SlotSlot and hasCard some SupervisorEngineSupervisorEngine



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 UserC

onfiguration7603

Device

Cisco7603

(consistent)



State of the ArtMetamodel 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



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)• Provide formal semantics

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



Description Logic (Example)

Cisco7603 v Device (1)

Cisco7603 ≡ ∃hasConfiguration.Configuration7603 (2)

Configuration v ∃ ≥ 1hasSlot.Slot u (3)

∃hasSlot.(∃hasCard.SupervisorEngine)Configuration7603 ≡ ∃ = 3hasSlot.Slot u (4)

∃hasSlot.(∃hasCard.(HotSwappableOSM t SPAInterface))Slot v ∃hasCard.Card (5)

Card ≡ HotSwappableOSM t SPAInterface t SupervisorEngine (6)

TBox:

ABox: Device(cisco) (1)

Configuration(conf) (2)

Slot(cslot1), Slot(cslot2), Slot(cslot3) (3)

SupervisorEngine(supervisor720), SPAInterface(spa360) (4)

hasConfiguration(cisco, conf) (5)

hasSlot(conf, cslot1), hasSlot(conf, cslot2), hasSlot(conf, cslot3) (6)

hasCard(cslot1, supervisor720), hasCard(cslot2, spa360) (7)

Configuration7603(conf)

Cisco7603(cisco)



Description Logics• DLs allow for joint as well as for separate sound and

complete reasoning at the model and at the instance level• DLs allow for tractable reasoning and efficient query answering• DLs provide more expressiveness than usual metamodeling

languages

• But: DLs are not designed to act as a metamodel for defining DSLs

• DSL Designer has no experience modeling with DLs and ontologies

• DSL Designer requires to use the languages he is familiar with as much as he can (standard metamodeling language like KM3)

• DSL Designer wants to define constraints

DSL Designer



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

Framework Developer

Ontology-based framework for domain-specific languages



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

DSL User

DSL Designer

FrameworkDeveloper



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 hasConfiguration with min 1 Configuration7603 {

{

equivalentWith IntersectionOf(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



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



Refinements along metamodeling layersFramework 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



Agenda



• From business developer to software developerRefinements along platform specification






Process refinement is a crucial task in process modeling and managementProblems during development

Processes are developed by multiple people in various stepsA change might impact the overall consistency(Current) manual checking is time-consuming and error-proneErrors are expensive:

RemodelingHidden errors

Motivation



Can description logics capture the dynamic aspects of the domain, particularly the changing of a process model?

Formalization of graph-based modelsInterpretation of refinement constraintsRepresentation and validation of refinement constraints

ChallengesEnsuring the specific process preserving the intended meaning of the generic processProviding efficient reasoning service

Research Questions



A simple flow:

Process in BPMN



A simple flow:Parallel gateway:

Flow goes through all the branches

Process in BPMN



A simple flow:

Loop:

Flow can go back to previous activity or gateway

Parallel gateway:

Flow goes through all the branches

Exclusive gateway:

Flow go through one and only one of the branches

Process in BPMN



Simple Flow:

{AB}

Execution Set Semantics



Parallel gateway:

{a1b1b2a2, a1b1a2b2, a1a2b1b2, a1a3}

Simple Flow:

{AB}




Parallel gateway:

{a1b1b2a2, a1b1a2b2, a1a2b1b2, a1a3}

Simple Flow:

{AB}

Loop:

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




Parallel gateway:

{a1b1b2a2, a1b1a2b2, a1a2b1b2, a1a3}

Simple Flow:

{AB}

Loop:

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

Exclusive gateway:

{E, EF}




{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 description logics?

Process Refinement („horizontal“)



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

Complexity O(n!)

2. Reduce execution sets to predecessor and successor sets:

Process Normalization



• 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 („horizontal“)



A process refinement step is represented in the refinement ontologyNormalize the process (only XOR-gateways)Represent activities as conceptsRepresent orderings and composition relations as propertiesPre-refinement relations by universal restrictionsPost-refinement relations by existential restrictionsUniqueness of activities by disjointness

Refinement Representation



Given a refinement ontology an activity is valid iff its concept is satisfiable

A process refinement is valid iff all the concepts in the refinement ontology are satisfiableA path is unexecutable iff any of its activity is unsatisfiable in the refinement ontology

Refinement Checking



Complexity of refinement ontology: ALCUnsatisfiability checking

Worst-case: ExpTime-completeImprovement: Approximation

Transformation/Normalization Worst-case: n!

Practical Evaluation result: reasoning more complex than transformation (order of magnitude 3)

Computational Properties



Temporal Logic and Model CheckingRefinement specification in LTL

Process Algebra and Model CheckingRefinement specification in process algebra

Communication and Transition System Calculus, e.g. ∏-calculusOWL and DL models

Modeling of activity pre- and postconditionsOntologies for annotationsProcess refinement and validation is not (directly) considered

Related Work



ResultsOntologies are used to compensate the lack of formal semantics in models (BPMN models)Reasoning is used to check semantic constraints

Next StepsOptimization of reasoning (PTIME via approximation)Extended process models (further gateways)Non-pairwised gateways (e.g. nested gateways)Generalized refinement solution for other models

Future Work



State SA, SB

SA = A ⊔ ∃ transition.TSB = B ⊔ ∃ transition-.TT = TL ⊔ ∃ event. E

⊔ ∃ prec.Guard⊔ ∃ source.A⊔ ∃ target.B

Analogous Problem for Statecharts

SA = A SA1 = A1 ⊔ ∃ transition.TSA2 = A2

SA1 ⊑ SA SA2 ⊑ SASB = B ⊔ ∃ transition-.TT = TL ⊔ ∃ source.A1

⊔ ∃ target.B



Agenda



• From business developer to software developerRefinements along metamodeling levelsRefinements along platform specification






Scenario

Ontology translation between datasets of bibliographic references

Input Output

examples from http://oaei.ontologymatching.org



Overview

Schema View

Input OutputTranslation

Semantic

Syntactic, Lexical

Lexical

SemanticF-Logic

+

Ontobroker

(Java)SPARQL

+

Jena(Java)

MBOTL

examples from http://oaei.ontologymatching.org

Input OutputInput Output



State of the Art: Neon Toolkit

visual mapping of ontologies

Plug-ins must be written separately

Input Output

www.neon-toolkit.org



Problem

All three layers are platform independent

A PIM [Conceptual Schema] is a view of a system from the platform independent viewpoint. (MDA Guide)

Problem:Can it be specified with one language? Can it be a specific language instead of a general-purpose programming language?


Semantic

Syntactic, Lexical

Lexical

SemanticF-Logic

+

Ontobroker

(Java)SPARQL

+

Jena(Java)

F-Logic

+

Ontobroker

(Java)SPARQL

+

Jena(Java)

Input OutputTranslationInput Output



The MBOTL Solution

Advantages:Productivity: focus on business and not on platform detailsPortability: Same PIM can be automatically transformed into multiple PSMs for different platforms


Semantic

Syntactic, Lexical

Lexical

Semantic

Input OutputTranslationInput Output

MBOTL

F-Logic + Ontobroker

SPARQL + Jena



Task

MBOTL accomplishes ontology translation between datasets at:

• Semantic Layer• Syntactic Layer• Lexical Layer

MDA ProcessImplementation: Screenshots



Addressing the semantic layer

Usage of OCL-like expressions to formulate queries.

ChapterInBook2InBook

s : _input!Part (s.owlIsInstanceOf(Chapter) or s.owlIsInstanceOf(InBook)

t : _output!InBook ( title s.title.toUpper(), pages <- s.pages.endPage - s.pages.startPage + 1 month <- s.date.month.notShortened() )

rule { from

to

<-

}

Ontology Element

Property Expression

Matched Rule

Out Pattern

In Pattern

Operation Expression

Variables

1

3

5

7

9

11 Assignment Operator

MBOTL’s concrete syntax is based on the Atlas Transformation Language (ATL)



Addressing the syntax and lexical layers

Application of predefined operations or helpers

Unified Representation



Conceptual Architecture

Reference Layer(EU STReP MOST)

MBOTL Extension



Agenda

MotivationHow to MBOTL accomplishes ontology translation between datasets at:

• Semantic Layer• Syntactic Layer• Lexical Layer

MDA ProcessImplementation: Screenshots

Future Work



Translation Process

Source Ontology

Target Ontology

PlatformSpecific Model

java.ecoresparql.ecore

PlatformIndependent Model

mbotl.ecore

Code

query.javabuiltins.java Jena

Framework

ATL Model Transformation

ATL Model Transformation



Screenshot: Editing a MBOTL Translation



Screenshot: Generated SPARQL Model



Screenshot: Java Code with Jena API



Screenshot: Java Code of Built-In



Summary

MBOTL provides an unified language to model different layers of ontology translation between datasets.At semantic level: OCL-like query language.At syntactic and lexical levels: OCL-like predefined operations and user-defined helpers.Improvements to be evaluated: productivity, portability.Implementation: Eclipse, Atlas Transformation Language, Jena.Future work: plug-in, SPARQL-like syntax, evaluation.

Download and test: isweb.uni-koblenz.de/Research/MBOTL



Agenda



• From business developer to software developerRefinements along metamodeling levelsRefinements along platform specification







MDA / MDE Description Logics / Ontologies

MDE & Description LogicsNot for all and everything

But, still, a marriage in heaven

Thank You!

Check out the TwoUse toolkit: http://west.uni-koblenz.de/twouse



ReferencesWalter, Tobias; Ebert, Jürgen (2009): Combining DSLs and Ontologies using Metamodel Integration.

In: Domain-Specific Languages. Springer. Bd. 5658. S. 148-169. Silva Parreiras, Fernando; Walter, Tobias; Staab, Steffen; Saathoff, Carsten; Franz, Thomas (2009):

APIs agogo: Automatic Generation of Ontology APIs. In: Proceedings of the 3rd IEEE International Conference on Semantic Computing (ICSC 2009), September 14-16, 2009, Santa Clara, California, USA. IEEE Computer Society.

Ren, Yuan; Gröner, Gerd; Lemcke, Jens; Rahmani, Tirdad; Friesen, Andreas; Zhao, Yuting; Pan, Jeff .; Staab, Steffen (2009): Validating Process Refinement with Ontologies. In: Int. Workshop on Description Logics (DL).

Walter, Tobias; Silva Parreiras, Fernando; Staab, Steffen (2009): OntoDSL: An Ontology-Based Framework for Domain-Specific Languages. In: ACM/IEEE 12th International Conference on Model Driven Engineering Languages and Systems, 12th International Conference, MODELS 2009. Springer. Bd. 5795. S. 408-422.

Silva Parreiras, Fernando; Pan, Jeff. Z.; Assmann, Uwe (2009): Second Workshop on Transforming and Weaving Ontologies and Model Driven Engineering (TWOMDE 2009) at MoDELS 2009, October 4th, Denver, Colorado, USA. In: TWOMDE.

Walter, Tobias (2009): Combining Domain-Specific Languages and Ontology Technologies. In: MoDELS Doctoral Symposium 2009.

Groener, Gerd; Staab, Steffen (2009): Modeling and Query Pattern for Process Retrieval in OWL. In: Proceedings of 8th International Semantic Web Conference (ISWC). Nr. 5823.

Jekjantuk, Nophadol; Groener, Gerd; Pan, Jeff Z. (2009): Reasoning in Metamodeling Enabled Ontologies. In: Proc. of 6th Int. Workshop OWL: Experiences and Directions (OWLED).

F. Silva Parreiras, S. Staab, A. Winter. Improving Design Patterns by Description Logics: An Use Case with Abstract Factory and Strategy. In: T. Kühne & F. Steimann (eds.) Proc. of Modellierung 2008. LNI, Gi e.V, März 2008.

F. Silva Parreiras, S. Staab, A. Winter. On Marrying Ontological and Metamodeling Technical Spaces. In: ESEC/ACM FSE-2007 – Proceedings of the 6th joint meeting of the European software engineering conference and the 14th ACM SIGSOFT symposium on Foundations of software engineering, September 03 - 07, 2007, Dubrovnik, Croatia. ACM 2007, pp. 439 - 448




MDA / MDE Description Logics / Ontologies

MDE & Description LogicsNot for all and everything

But, still, a marriage in heaven

Thank You!

Check out the TwoUse toolkit: http://west.uni-koblenz.de/twouse

Model-driven Software Engineering with Description Logicsstaab/Presentations/staab-dfki... ·...

Documents

Transcript of Model-driven Software Engineering with Description Logicsstaab/Presentations/staab-dfki... ·...