Lecture 2: Domain-Specific Logic Languages (DSLL) or Logic-based Domain-Specific Languages (LDSL)

Transcription

1 Lecture 2: Domain-Specific Logic Languages (DSLL) or Logic-based Domain-Specific Languages (LDSL) Prof. Uwe Aßmann Christian Wende Technische Universität Dresden Software Engineering Group Version 0.2 Dresden, Aug. 27, 2013

2 Literature [ODSD] Jeff Pan, Steffen Staab, Uwe Aßmann, Jürgen Ebert, Yuting Zhao. Ontology-Driven Software Development. Springer, 2013 [Walter] Tobias Walter. Bridging Technological Spaces: Towards the Combination of Model-Driven Engineering and Ontology Technologies. Dissertation. Universität Koblenz-Landau, 2011 [RW2010] Uwe Aßmann, Andreas Bartho, and Christian Wende, editors. Reasoning Web. Semantic Technologies for Software Engineering, 6th International Summer School 2010, Dresden, Germany, August 30 - September 3, Tutorial Lectures, volume 6325 of Lecture Notes in Computer Science. Springer, OWLText URL 2

3 Contents 2.1 Why do we need DSL? 2.2 The historical development of DSL environments 2.3 We need semantics... But there is the problem of technical spaces 2.4 OWLText: a tool for textual LDSL 2.5 A graphical LDSL: Feature model with ontology semantics 2.6 Families of LDSD 2.7. Outlook: LDSL as Language Families Logic-Based DSL 3

4 2.1 Why do we need Domain-Specific Logic Languages = Logic-Based Domain-Specific Languages?

5 In Dresden, we work on the eternal problems... Coffee admins Logic-Based DSL 5

6 Recently, we got a NAO Robot Chuck Chuck could fetch coffee! Logic-Based DSL 6

7 Well, I like to teach Logic-Based DSL 7

8 But, how do I teach Chuck to bring me a coffee?

9 Why Domain-Specific Languages (DSL)? Pros: + Use the concepts and idioms of a domain + DSL embody domain knowledge (concepts and constraints) + Make domain modeling easy + Grandmothers (.. Domain experts..) can understand and write DSL programs + Higher level of abstraction + Concise and self-documenting + Can enhance productivity, reliability, maintainability and portability But: - Costs of design, implementation and maintenance - Costs of education for users - Limited availability of DSLs From: Logic-Based DSL 9 / 28

10 Network Device Specification (DSL for Comarch) K. Miksa, COMARCH Logic-Based DSL 10

11 Graphic DSLs in Device Modeling K. Miksa, COMARCH Logic-Based DSL 11

12 Ex.: Graphic DSL for Process Guidance Ontologies in MOST Project K. Miksa, COMARCH Logic-Based DSL 12

13 Ex.: Guidance Task List During BPMN Process Refinement (SAP) Logic-Based DSL 13

14 2.2 The Historical Development of DSL

15 DSLs and Logic-Based DSLs 2015 LDSL Families Family LDSL 2012 OWLText Logic-Based DSL Product families ELI Attribute-Grammar Cocktail based JastAdd Compiler environments DCG Eclipse based toolkits Parsing environments for DSL Hand implementation of DSL EMFText XText Lex, yacc Logic-Based DSL 15

16 Example: Building textual DSLs using EMFText EMFText is based on Eclipse Modeling Tramework (EMF) Generates editors, parsers, printers for a EMOF metamodel (Florian Heidenreich, Jendrik Johannes, Sven Karol, Mirko Seifert, Christian Wende) Logic-Based DSL 16

17 What s in a DSL? DSL Concrete Syntax Meta Model (Structure) Sta5c Seman5cs Dynamic Seman5cs Symbols, shapes Domain concepts, Language concepts, relations, attributes Typing, use-definition relationships Behavior, meaning Logic-Based DSL 17 / 28

18 How to build a DSL with EMFText Editor Ecore Metamodel EMFText Parser Generator (ANTLR) ConcreteSyntax Specification Grammar Static Semantic Resolvers EMFText Resource Printer Parser input for generates derived from Logic-Based DSL 18 / 28

19 How to build a DSL - Overview Editor a) Ecore Metamodel EMFText Parser Generator (ANTLR) CS Specification Grammar b) Static Semantic Resolvers EMFText Resource Printer Parser input for generates derived from Logic-Based DSL 19 / 28

20 How to build a DSL Meta model in EMOF Creating a new meta model: Define concepts, relations and properties in an EMOF/Ecore model Meta model elements: Classes, Data Types Enumerations Attributes References (Containment, Non-containment) Cardinalities Inheritance Very similar to the T-Box of a restricted RDFS a) Logic-Based DSL 20 / 28

21 How to build a DSL Meta model Meta model elements: a) Classes Data Types Enumerations Attributes References (Containment, Non-containment) Cardinalities Inheritance Very similar to the T-Box of a restricted RDFS Logic-Based DSL 21 / 28

22 Derive initial syntax of the DSL in HUTN (Human Usable Text Notation) a) b) Logic-Based DSL 22 / 28

23 Generated Grammar of Initial HUTN syntax b) Logic-Based DSL 23 / 28

24 Initial HUTN syntax Example Document b) Logic-Based DSL 24 / 28

25 Syntax Customization The Concrete Syntax language Structure of a.cs file based on EBNF: Header File extension Meta model namespace URI, location Start element(s) Imports (meta models, other syntax definitions) Options Token Definitions Syntax Rules b) Logic-Based DSL 25 / 28

26 Syntax refinement by changing the ENBF Syntax rules One per meta class Syntax: MetaClassName ::= Syntax Definition ; b) Definition elements: Static strings (keywords) public Choices a b Multiplicities +,* Compounds (ab) Terminals a[] Non-terminals a Logic-Based DSL 26 / 28

27 Syntax rules - Examples b) OfficeModel ::= "officemodel" name[] "{" elements* "}" ; officemodel SoftwareTechnology {... } Logic-Based DSL 27 / 28

28 Syntax rules - Examples b) OfficeModel ::= "officemodel" name[] "{" elements* "}" ; Employee ::= "employee" name[] "works" "in" worksin[] "works" "with" workswith[] ("," workswith[])* ; Office ::= "office" name[]; officemodel SoftwareTechnology { office INF2080 employee Florian works in INF2080 } Logic-Based DSL 28 / 28

29 Complete Customized Syntax b) Logic-Based DSL 29 / 28

30 Generic Syntax vs. Custom Syntax b) Logic-Based DSL 30 / 28

31 DSL Syntax Modules for DSL Families Import meta models optionally with syntax Extend and combine existing DSLs Create embedded DSLs (e.g., for Java) Create a template language from your DSL... c) Logic-Based DSL 31 / 28

32 The EMFText Syntax Zoo (~100 residents) Ecore, KM3 (Kernel Meta Meta Model) Quick UML, UML Statemachines Java 5 (complete), C# (in progress) Feature Models Regular Expressions natspec controlled natural language DOT (Graphviz language) and lots of example DSLs Ontology-related languages: OWL2 Manchester Syntax* OWL2 Functional-Style Syntax OWLCL* SPARQL* SPARQL-DL Abstract Syntax SWRL EMFText_Concrete_Syntax_Zoo#Ontology_Languages

33 I have DCGs, so why should I want EMFText? Metamodel-based, typed environment Generation of tools Statically typed Integration with application software Integration with many other tools Modularity Integration with software process Software Process Tools for management and guidance of the software development process Methodology Tools for supporting the software development methodology Automation Tools for automating repetitive validation and transformation tasks Logic-Based DSL 33

34 2.3 We need Semantics Why not try Ontologies?

35 What s in a DSL? DSL Concrete Syntax Meta Model (Structure) Sta5c Seman5cs Dynamic Seman5cs Symbols, shapes Domain concepts, relations, attributes Typing, use-definition relationships Behavior, meaning Logic-Based DSL 35 / 28

36 Language Semantics and Technical Spaces Domain world Ontologies Domain models OWL Domain Expert Structural (syntactic) Modeling World Structure Hierarchies Graphs EMOF UML-CD MOF Software Engineer Dynamics Semantic Expert Static Semantic Expert Static Semantic World Attributed Grammars Abstract Interpretation Model checking Ontologies OWL CTL Dynamic Semantic World Interpretation State systems Simulation Logic-Based DSL Petri nets SOS Natural Semantics 36

37 Language Semantics and Technical Spaces Domain world Ontologies Domain models OWL Domain Expert Structural (syntactic) Modeling World Structure Hierarchies Graphs EMOF UML-CD MOF Software Engineer Dynamics Semantic Expert Static Semantic Expert Static Semantic World Attributed Grammars Abstract Interpretation Model checking Ontologies OWL CTL Dynamic Semantic World Interpretation State systems Simulation Logic-Based DSL Petri nets SOS Natural Semantics 37

38 But there is the problem of technical spaces

39 Language Semantics and Technical Spaces Domain world Ontologies Domain models OWL Domain Expert Structural (syntactic) Modeling World Structure Hierarchies Graphs EMOF UML-CD MOF Software Engineer Dynamics Semantic Expert Static Semantic Expert Static Semantic World Attributed Grammars Abstract Interpretation Model checking Ontologies OWL CTL Dynamic Semantic World Interpretation State systems Simulation Logic-Based DSL Petri nets SOS Natural Semantics 39

40 Bridging Ontologies and Software Technology Software Engineer Ontology Expert Software Modeling World (ModelWare) Ontology World (OntologyWare) EMOF UML-CD MOF OWL RDFS Logic-Based DSL 40

41 Bridging technologies Transformation bridge (physical transport of models to the other space) Integration bridge integrating metalanguages Bridging Technology Tools Querying Reasoning Technology Ontoware TS OWL2 Metamodel Ontology TBox ABox transformation integration query language Modelware TS Ecore Metametamodel DSL Metamodel Model Model Tools M3 conformsto M2 ValidaDon Constraint Technology M1 conformsto Logic-Based DSL 41

42 TransformaDon Bridge Bridging Technology - TransformaDon - Ontoware TS Modelware TS OWL2 Metamodel target metamodel TransformaDon DefiniDon source metamodel Ecore Metametamodel M3 Tools Querying Reasoning Technology Ontology TBox ABox target model target model TransformaDon Engine source model source model DSL Metamodel Model Model Tools conformsto M2 ValidaDon Constraint Technology M1 conformsto Logic-Based DSL 42

43 Transformation Bridges Language mapping generates model bridges (same L) TS EclipseWare TS Ontologyware M3 EMOF/ECore OWL M2 L Transformer Generator/ Interpreter L M1 Models Transformer Models Logic-Based DSL 43

44 Transformation Bridge for Languages with Differences Language mapping can result from composition, integration, and extension of L+E1 and L+E2 TS EclipseWare TS Ontologyware M3 EMOF/ECore OWL M2 L+E2 Mapping Transformer Generator L+E1 M1 Models Transformer Models Logic-Based DSL 44

45 Transformation Bridge for More Semantics Language mapping can result from extension by constraints Models have more semantics in semantic space TS EclipseWare TS Ontologyware M3 EMOF/ECore OWL M2 L(+C1) extension Transformer Generator Checker Generator/ Reasoner L+C1 M1 Models Transformer Models Logic-Based DSL 45

46 2.3.2 Language IntegraDon with MM- IntegraDon Bridges Bridging Technology - IntegraDon - Tools Querying Reasoning Technology Ontoware TS OWL2 Metamodel Ontology TBox ABox integradon projecdon projecdon Integrated (Meta- )Metamodel Hybrid (Meta- )model ontoware modelware Model integradon projecdon projecdon Modelware TS Ecore Metametamodel DSL Metamodel Model Model Tools M3 conformsto M2 ValidaDon Constraint Technology M1 conformsto Logic-Based DSL 46

47 Ex.: OntoDSL: Integration Bridge [Tobias Walter, Steffen Staab, Uni Koblenz] Development Environment Framework Developer Integrated Metametamodel KM3 OWL Metametamodel Metamodel instanceof :M3 instanceof DSL Designe r DSL User M2': M1': Domain Definition Metamodel (Concrete Syntax) instanceof Domain Model Visualization Integrated Model (Abstract Syntax) Constraints / Axioms transform :M2 transform Ontology Definition TBox OWL Ontology ABox Reasoning Service Logic-Based DSL 47

48 2.4 OWLText A tool for textual LDSL, automatically bridging technical spaces Courtesy: Christian Wende, TU Dresden Tobias Walter, U Koblenz

49 Ex.: OWLText Transformation Bridge Chain, with Integration From textual DSL to OWL constraint checking TS Ontolog y-ware TS EclipseWare TS Grammar -ware M3 OWL-CL EMOF/ECore EBNF M2 L OWLizer transformer L EMFText Generator L M1 Models Printer Parser Models Printer Parser Models Logic-Based DSL 49

50 Ex.: OWLText Transformation Bridge Chain, with Integration From textual DSL to OWL constraint checking TS Grammar -ware TS EclipseWare TS OWLware M3 EBNF EMOF/ECore OWL M2 L EMFText Generator L OWLizer transformer L M1 Models Printer Parser Models Transf. 1 Transf. 2 Models Logic-Based DSL 50

51 Motivation Technology Space Bridging Metamodelling Space: Comprehensible infrastructure with tools for metamodelling, modelling, persistence, transformation, code generation Generated API for model manipulation Plethora of integrated tools that share repository => Metamodelling is a syntactic island for technology space bridges Interesting Bridges: Other Syntactical Spaces EMFText, XText, GMF Grammarware, Parsing and Printing Semantic technical spaces (static and dynamic) Ontologies Attribute Grammars (JASTEMF) Logic-Based DSL 51

52 Design OWLText technology space bridging for LDSL Grammar Space Metamodelling Space Ontology Space EBNF ANTLR Textual Syntax EMOF EMF Syntactic Repository OWL Pellet Semantic Classification and Validation Logic-Based DSL 52

53 Design OWLText technology space bridging for LDSL Grammar Space Metamodelling Space Ontology Space EMFText EBNF EMOF OWL ANTLR EMF Pellet Textual Syntax + Syntactic Repository Semantic Classification and Validation Logic-Based DSL 53

54 Design OWLText technology space bridging for LDSL Grammar Space Metamodelling Space Ontology Space EMFText OWLlizer EBNF EMOF OWL ANTLR EMF Pellet Textual Syntax + Syntactic Repository + Semantic Classification and Validation OWLText Logic-Based DSL 54

55 OWLText Architecture OWLText technology space bridging for LDSL print classify parse validate EMFText OWLizer EBNF refines CS Language EMOF OWLCL references references refines OWL customises customises ANTLR Parser OWLizing code model ontology Printer deowlizing Logic-Based DSL 55

56 Architecture Generalised Architecture of technical space bridges print classify parse Service Integration validate EMFText OWLizer EBNF refines Metamodell Integration CS Language EMOF OWLCL references (Integration references Bridges) refines OWL customises customises ANTLR Parser OWLizing code Modell model Integration ontology Printer deowlizing (Transformation Briges) Logic-Based DSL 56

57 Example: Office LDSL office 2080 employee Prof. Assmann works in 2087 works with Wende office 2087 employee Wende Office DSLL Tutorial language to model offices, employees, and their interaction Employees work in offices, there are co-working relationships Logic-Based DSL 57

58 Example: Office LDSL office 2080 employee Prof. Assmann works in 2087 office 2087 Textual Syntax Model Level Metamodel Level Metamodelling Space OfficeModel := (employees:employee*, offices:office*); Office:= (name: String); Employee: (name: String, title: String, worksin: Office, workswith: Employee*); Logic-Based DSL 58

59 Example: Office LDSL office 2080 employee Prof. Assmann works in 2087 office 2087 Textual Syntax Model Level Metamodel Level Grammar Space OfficeModel:= (employees offices)*; Office:= office name; Employee:= employee title name works in worksin works with workswith*; Metamodelling Space OfficeModel := (employees:employee*, offices:office*); Office:= (name: String); Employee: (name: String, title: String, worksin: Office, workswith: Employee*); Logic-Based DSL 59

60 Example: Office office 2080 employee Prof. Assmann works in 2087 office 2087 Textual Syntax Model Level Metamodel Level Grammar Space OfficeModel:= (employees offices)*; Office:= office name; Employee:= employee title name works in worksin works with workswith*; Metamodelling Space OfficeModel := (employees:employee*, offices:office*); Office:= (name: String); Employee: (name: String, title: String, worksin: Office, workswith: Employee*); Ontology Space Constraints ProfessorsRoom ProfessorsAssistants PhDCoworkers Logic-Based DSL 60

61 Example: PetriNets LDSL Graphical Syntax Textual Syntax place P1; place P2; place P3; place P4; transition T1; transition T2; from P1 to T1 {...}; from T1 to P2 {...}; from T1 to P3 {...};... from T2 to P4 {...}; from T2 to P1 {...}; PetriNets DSLL Language to describe the dynamic semantics of distributed systems Places and transistions connected by arcs Consuming arcs take tokens from places Producing arcs put tokens to places Transition fires if all incomming arcs have tokens Logic-Based DSL 61

62 Example: PetriNets LDSL Graphical Syntax Textual Syntax place P1; place P2; place P3; place P4; transition T1; transition T2; Model Level Metamodel Level from P1 to T1 {...}; from T1 to P2 {...}; from T1 to P3 {...};... from T2 to P4 {...}; from T2 to P1 {...}; Metamodelling Space Nameables := (name: String); Components : Nameable := (in: Arc*, out: Arc*); Transition : Component; Place : Component (type: EClass); Arcs := (from:component, to:component) Logic-Based DSL 62

63 Example: PetriNets LDSL Graphical Syntax Textual Syntax place P1; place P2; place P3; place P4; transition T1; transition T2; Model Level Metamodel Level Grammar Space Arc := from -> to Transition := transition name; Place := place place : type; from P1 to T1 {...}; from T1 to P2 {...}; from T1 to P3 {...};... from T2 to P4 {...}; from T2 to P1 {...}; Metamodelling Space Nameables := (name: String); Components : Nameable := (in: Arc*, out: Arc*); Transition : Component; Place : Component (type: EClass); Arcs := (from:component, to:component) Logic-Based DSL 63

64 Example: PetriNets LDSL Graphical Syntax Textual Syntax place P1; place P2; place P3; place P4; transition T1; transition T2; Model Level Metamodel Level Grammar Space Arc := from -> to Transition := transition name; Place := place place : type; from P1 to T1 {...}; from T1 to P2 {...}; from T1 to P3 {...};... from T2 to P4 {...}; from T2 to P1 {...}; Metamodelling Space Nameables := (name: String); Components : Nameable := (in: Arc*, out: Arc*); Transition : Component; Place : Component (type: EClass); Arcs := (from:component, to:component) Ontology Space Global Constraints Invalid Arcs Consuming Arcs Producing Arcs Domain Specific Constraints Start Places Disallow Parallelism Logic-Based DSL 64

65 Screencast Logic-Based DSL 65

66 2.5 Example of a Graphical LDSL: Feature Models for Tool Families Christian Wende, Uwe Aßmann

67 Challenges for Product Families Build many tools with common platform Strengthen reuse by sharing commonalities Control by configuration ontology MOST TOPF (Tool Product Family) -> Ontology-controlled tool configuration 67

68 Development Process in MOST TOPF Tool Family 9#:;%<(),(=,3,->% '.(-/).%012.3% 41)%!15-%$"&'%!"#$%$"&'%()*+),,-+)*%!"#$%$"&'%.)/01)2123)% <(),(7-%012.3% 41)%*17*).-.% 6)12/*-% 9#D;%<(),(7-% 9#A;%'.(-/).% ()*+,-.*-/).% '.(-/).I2),G.7% 9#E;%<(),(7-% 9#C;%'.(-/).%!(66,78%!"#$%$"&'% 0(66,78% 012.3% H17*).-.%!"#$% $"&'%6)12/*-% J76/-%41)% B.3(-.5%-1%

69 (S1) Variabilty Specification MOST TOPF Graphic Feature Model Enables systematic classification and documentation of commonalities and variability Enables explicit management of feature dependencies Enables easy and systematic configuration of generic tools Propositional logic, translates to ontology MOST TOPF Variability Software Process Guidance Development Method Automation MDSD Process Modelling Language Specification Validation Comarch Network Configuration Comarch OSS Development Business Process Development PDDSL PDIDSL BEDSL MEDSL DBDSL BPMN Specification Transformation Ontology Technology Reasoner Ontology Language Pellet OWL Full Fact+ OWL DL BPMN (Specification Validation and OWL DL) or not (Specification Validation) TrOWL REL OWL Lite OWL FA

70 MOST TOPF Architecture (S2) Feature Realisation Views Editors Project Explorer Task Management Specification Validation Model Querying Graphical Editor Tree-based Editor Textual Model Editor Properties Editor Vertical Services Ontology-based Services Import/Export Interfaces Security and User Management Versioning and Collaboration Ontology-based Process Guidance Integration Infrastructure Modelling Infrastructure Validation Explanation Querying Semantic Modelling Infrastructure Bridge / MOST Bridge Model & Metamodel Repository Management Ontology Infrastructure Ontology Repository Other Semantic Reasoner Persistency Services Database Persistency Other

71 (S2) Feature Realisation MOST TOPF Architecture Component-based architecture modelled using UML,+-"%"./&5(')$*6")78$+01 H!L-$:-*?$:-='%*H#2-") Defines blue-print for layered ODSD tool architecture O'%2#'-2"+*L'0'#$!!"#$%#&'&())!"#$%*B)"M2#$)!!"#$%#&'&())?)'+3<")4'-2"+F)"7$) Platform-independent can be implemented using various tool platforms (e.g. Q5B*B)"0$33*,+-"%"./!!"#$%#&'&()) S"4')01*B)"0$33*,+-"%"./!!"#$%#&'&())!,Q?*B)"0$33*,+-"%"./!!"#$%#&'&()) 59,::!$-'D!"#$%N-"N,6> ;!"#$%O'%2#'-2"+H+.2+$!!"#$%#&'&()) Q5BC$<2+$4$+->28)')/5#'A-$)!!"#$%#&'&()) 59,::*R3$)*!.-4!!"#$%#&'&()) FB!GN-"N,6> ;C$'3"+$)!!"#$%#&'&()) CH>!!"#$%#&'&())?),6>!!"#$%#&'&())!!"#$%#&'&())!!"#$%#&'&())!!"#$%#&'&()) Q5BC$<2+$4$+->28)')/ B$%%$- ;+<)'3-)=0-=)$ 59,::*!"#$%%2+.*;+<)'3-)=0=)$!!"#$%#&'&()),+-"%"./*>'/$) FB!G!!"#$%#&'&()) 59,::!$-'D4"#$%!!"#$%#&'&()),+-"%"./*5B;

72 (S4) Variant Selection Variant Model for Concrete Demonstrator Variant Editor guides tool customisation Interactively checks and annotates consistency w.r.t. feature model and constraints Provides repair suggestions * Feature model excerpt

73 MOST TOPF mapping model Interactive, graphical mapping approach Mapping of boolean feature terms to elements of Ecore-based models Mapping stored in a dedicated, external mapping model (S3) Feature Mapping Manual feature mapping

74 ,+-"%"./&5(')$*6")78$+01 (S3) Feature Mapping BB0"4A"+$+-CC BB0"4A"+$+-CC Q'%2#'-2"+*62#.$-?'37*>23-*62#.$- BB0"4A"+$+-CC BB0"4A"+$+-CC J!N-$:-*?$:-='%*J#2-") 500$33*>'/$) BB0"4A"+$+-CC BB0"4A"+$+-CC BB0"4A"+$+-CC BB0"4A"+$+-CC Q'%2#'-2"+*N'0'#$!"#$%*D)"O2#$)?)'+3<")4'-2"+H)"7$)!"#$%&'(')$*'+#*,+-"%"./&'(')$*!$ BB0"4A"+$+-CC 59,::!$-'F!"#$%P-"P,6> BB0"4A"+$+-CC HD!IP-"P,6> ;E$'3"+$) ;!"#$%Q'%2#'-2"+J+.2+$ BB0"4A"+$+-CC?)'02+.*J+.2+$ BB0"4A"+$+-CC S5D*D)"0$33*,+-"%"./ BB0"4A"+$+-CC BB0"4A"+$+-CC BB0"4A"+$+-CC EJ> U"4')01*D)"0$33*,+-"%"./ S5DE$<2+$4$+->28)')/5#'A-$) BB0"4A"+$+-CC BB0"4A"+$+-CC BB0"4A"+$+-CC?),6>!,S?*D)"0$33*,+-"%"./ 59,::*T3$)*!.-4 BB0"4A"+$+-CC BB0"4A"+$+-CC BB0"4A"+$+-CC BB0"4A"+$+-CC S5DE$<2+$4$+->28)')/ D$%%$- ;+<)'3-)=0-=)$ 59,::*!"#$%%2+.*;+<)'3-)=0=)$,+-"%"./*>'/$)

75 (S5) Variant Derivation Feature-Driven Demonstrator Derivation Variant model is used together with feature mapping and component diagram to derive variant specific component diagram AutomaDc Variant DerivaDon

76 Lessons Learned Feature models form a graphical, logic-based DSL (LDSL) for specification of software product lines Conciseness: Concise feature model (DSL, boolean expressions) Automatic checking Communicative: Unified and clarified terminology used in communication Interactivity: Interactive and graphical tooling helped visualising the mapping without interfering with UML syntax Logic-based DSL provide simple configurability Uniformity: Extension of feature model were quite similar for each demonstrator Harmlessness: Component-based infrastructure reduced threat of feature interaction Evolvability: External mapping model helped extending the architecture without breaking the mapping Stability: Unique identifier for solution space elements required to provide stable mapping Complexity: Complex mappings with terms hard to visualise

77 2.6 A Feature-Modeled Family of Ontology Languages Christian Wende and Florian Heidenreich, TU Dresden (MDPLE Workshop, Twente, 2009)

78 Causes of the Scalability Problem Use Case implies? Computational Complexity language expressiveness language features Language Customisation Combined Data Complexity facts size axioms size queries complexity Queries uses Ontology Language uses Knowledge Base Logic-Based DSL 78

79 Existing Approaches to Achieve Scalability Language Design Reasoning Infrastructure OWL-Full SHOQ(D) Syntactic Approximation RACER Pellet FaCT++ OWL2 OWL-Lite EL++ OWL-FA Semantic Approximation OWL-DL TrOWL Minerva DL-Lite Sesame RDF(S) Logic-Based DSL 79

80 Existing Approaches to Address Complexity Current Status: An Ontology Language Hierarchy Most Expressive OWL2 OWL-Lite OWL-Full EL++ OWL-FA Subset-of relationships w.r.t syntax and semantics Trade-off between expressiveness and reasoning complexity Implemented mostly independent Goal: An Ontology Language Family Problem Space Systematic organisation of family members Specific expressiveness and reasoning requirements can be addressed by recombining existing language features Most Efficient OWL-DL DL-Lite RDF(S) Systematic reuse of common language features Generating language tooling (e.g., dedicated parsers, printers, editors, and reasoners) Language evolution by contributing new features Solution Space Logic-Based DSL 80

81 Language Customisation Realising an Ontology Language Family Feature-based Family Specification Mapping Model-Based Language Specification Language Family Engineering Language Instantiation Use Case Requirements Feature-based Variant Selection Transformation of Language Specification Requirements Specific Language Logic-Based DSL 81

82 Problem Space of Ontology Language Family Feature Model to specify Ontology Language Families Ontology languages are classified by logical constructors (language features) they provide Feature Model restricts combinatorial variability to valid variation space (language family) Expressiveness and Computational Complexity (Scalability) can be derived from used constructors Concepts DescriptionLogics Roles R Datatypes (D+) AL Minimal TransitiveRoles R+ RoleHierarchy H Union U Top Bottom ConceptNegation C Nominals O FunctionalProperties F Intersection ValueRestriction InverseProperties I ExistentialQualification E AtomicNegation ALCR+ == S CardinalityRestriction N QualifiedCardinalityRestriction Q SHOIN(D+) == OWL DL Reduced feature models describe specific ontology language family member Logic-Based DSL 82

83 Solution Space of Ontology Language Family Dimensions of a Language Specification Abstract Syntax domain concepts relations and properties (OWL metamodel) Concrete Syntax (OWL parser) Language Semantics (OWL reasoner) Benefits of a Model-based Approach Provides means for transformation (Variant Refinement) Provides means for code generation (Tool Generation) Provides infrastructure based on metamodels (Tool Concrete Syntax Abstact Syntax Interoperability) Ontology: Class: Pizza Class: Spiciness ObjectProperty: hasspiciness Range: Spiciness OWL Property Ontology frames Frame OWLClass Semantics

84 Mapping Features to Language Specifications Mapping between Problem and Solution Space During Family Engineering single Ontology features are mapped to artefacts in the language specification models This mapping is stored in a Mapping Model Problem Space Solution Space OWL Metamodel OWL Featuremodel ObjectProperty Concepts DescriptionLogics Roles R property inverse Minimal ObjectPropertyReference Top Bottom Intersection AtomicNegation ValueRestriction InverseProperties I OWL Syntax Specification ObjectProperty ::= "ObjectProperty:" iri[iri]!1 ((annotations!1)... OWL Mapping Model )*; ( "InverseOf:" inverseproperties ("," inverseproperties)*!1) Logic-Based DSL Christian Wende, TU Dresden 84

85 FeatureMapper: Tool Support for Mapping Mapping between Problem and Solution Space Logic-Based DSL Christian Wende, TU Dresden 85

86 Language Instantiation Transformation Process for Language Instantiation FeatureMapper Model Transformation EMFText Code Generation OWL Feature Model < variant of > < maps to > OWL Metamodel OWL Variant Metamodel OWL Variant Parser OWL Variant Model < maps to > < refers to > < refers to > OWL Textual Syntax OWL Variant Concrete Syntax OWL Variant Printer OWL Variant Editor Logic-Based DSL 86

87 Conclusion Feature-Based Customisation for Families of Ontology Languages Ontology Languages are used for different Use Cases Use Cases imply data complexity Use Cases should also guide computation complexity Feature-Based Customisation provides means for Use Case driven language customisation Feature-Based Customisation is also supports Ontology Language Extension Ontology Language Evolution Ontology Language Integration Research Questions How can we compose reasoners w.r.t. language features? How to get from Use Case to required features? Logic-Based DSL 87

88 2.7 LDSL as Language Families

89 How do I teach Chuck to bring me a coffee? with a family of Gesture-LDSD Logic-Based DSL 89

90 Gesture DSL will be Domain-Specifc and should be Logic Based Gestures in Cars Context modeling Gestures in Public User editable Gestures in Factories Semantics Logic-Based DSL 90

91 Logic-Based DSLs 2015 OWLGraphics OWLGestures LDSL Families Family LDSL OWLText Logic-Based DSL Attribute-Grammar based Compiler environments Product families Eclipse based toolkits 1980 Parsing environments for DSL Hand implementation of DSL 1950 Logic-Based DSL 91

92 Engineering LDSL Families Logic-Based DSL Families Gestural Logic-Based DSL Graphical Logic-Based DSL Textual Logic-Based DSL Ontology-controlled Product families Technical Space Bridging Logic-Based DSL 92

93 LDSL need Bridging between Logics and Software Engineering Product family engineering Logic-based Semantics DSL LDSL Families Adequate Logic languages Logic-Based DSL 93

94 End Many slides are courtesy to the MOST project Tobias Walter (U Koblenz) Srdjan Zivkovic, Harald Kühn (BOC Information Systems GmbH) Krzystof Miksa (Comarch) And many others.. Forthcoming Book with Springer Ontology-Driven Software Development Logic-Based DSL 94

95 The End