Design Management: When Model Driven Engineering Embraces the Semantic Web NECSIS 2012, Gatineau, QC 27 June 2012 Maged Elaasar

2 2 Agenda  Overview of Design Management (DM)  Defining a domain with DM  The remaining challenges

3 Design Management (DM)  DM is a collaborative web-based tool that enables stakeholders to contribute to and influence the design of software and systems.  DM embraces the Semantic Web principles: Linked Data, Open-world assumption  DM is implemented as a set of web services on top of the Jazz platform  DM capabilities are integrated in two products:  Rational Software Architect Design Manager (beta available on Jazz.net)  Rational Rhapsody Design Manager (beta available on Jazz.net)

4 Design Management Features  Domain definition  Declaratively define a modeling domain along with a domain-specific tool for it.  In-context collaboration  Create, share and review models collaboratively using a web client with stakeholders.  Change management for designs  Store and manage model elements on a server directly (i.e., no need to map to files)  Traceability and impact analysis  Set up links between model elements, trace between them and analyze impact of change  Reporting and document generation  Use document/report templates to generate and share documents and reports  Other: Validation, Transformation, Migration of models

5 Design Management Architecture Jazz Storage §Architecture Elements §Index §Comments (visual, textual) §Links §Reviews OSLC + DM REST APIs Design creation, search, query, view, comment, review, link, report, validate, analyze Design creation, editing, search, query, validate, analyze, report Design Management services on Jazz Team Server (JTS) Design change control and versioning (model- based) RSA client Web client Rhapsody client OSLC + DM REST APIs

6 6 Agenda  Overview of Design Management (DM)  Defining a domain with DM  The remaining challenges

7 Domain Definition with Design Management  A domain is a definition of a domain-specific modeling language and its tooling  Before Design Management  A domain was defined as either a MOF (EMF) metamodel or a UML profile  A model is serialized in XMI and queried using OCL/XPath  Closed world assumption: hard to integrate domains or extend models  Most domain-specific tooling was code driven  With Design Management  A domain is defined as a set of OWL ontologies  A model is serialized in RDF and queries using SPARQL  Open world assumption: easy to integrate domains and extend models  Most domain-specific tooling is data driven

8 Domain Definition with Design Management  DM Domain Toolkit allows for defining a domain declaratively:  The abstract syntax is defined with a set of OWL ontologies (with DM extensions)  The concrete graphical syntax is defined with a mapping to a graphics  Various (diagram, tree or form based) editors can be defined in details  Live and batch validation rules can be defined in several expression languages  Future aspects: transformation, migration, inference…etc.  Several domains are prepackaged:  UML (ontology is imported from EMF)  BPMN (ontology is imported from EMF)  Topology  Sketcher  Rich Text

9 Domains Prepackaged in RSA DM  UML, BPMN and Topology

10 Domains Prepackaged in RSA DM  Rich Text and Sketcher

11 Domain Definition Process

12 DM Domain Editors

13 DM Core Domain  DM provides a Core domain that consists of several ontologies including:  XSD/RDF/RDFS/OWL (subset) for concept (class/property) modeling  DM Core fills some gaps in concept modeling  DM Editor/Explorer for defining content, layout and behavior of various kinds of editors  DM File/Folder for defining domain-independent hierarchical organization of models  DM Validation/Problem for defining validation rules using a number of languages  DM Index/Query for controlling search/traceability related aspects on models  DM Reporting/UI for controlling various UI and reporting aspects

14 DM Core Ontology  DM Core fills some gaps in concept modeling by special annotations  Document boundaries: which concepts should be defined in separate documents?  dmcore:DocumentClass (class)  dmcore:canDefine (property of dmcore:DocumentClass)  Deletion cascade: how to cascade deletion of a model element?  dmcore:deleteCascade (property of owl:ObjectProperty)  Detailed container modeling: what is the type of container members?  dmcore:allMembersFrom (property of owl:Restriction)  Initial values for properties: is there an initial value for a property?  dmcore:hasInitialValue (property of owl:Restriction)  Type compatibility: can two given types be used together on a model element?  dmcore:compatibleWith (property of owl:Class)

15 Agenda  Overview of Design Management (DM)  Defining a domain with DM  The remaining challenges

16 Open Issues  Scalable Inferencing  We need some level of scalable inferencing support for OWL ontologies  Validation based on semantics of OWL  We need to validate models against their ontology definition (a use case for inference?)  Scalable and extensible SPARQL Queries  We need SPARQL queries to scale regardless of order of statements in query  We need the ability to define a library of useful utility functions to be used in SPARQL  Derived properties  We need a strategy to derive values of some properties such that they can be queried

17 Open Issues  Model to model mapping  We need a way to declaratively define a mapping between two domains  We need the mapping to define document  Model Migration  We need a way to automatically migrate models when domains change  Model Refactoring  We need a way to perform model refactoring (update)

18 Open Issues  Diagram Definition  We need to define a diagram interchange ontology  We need a way to declare the graphical syntax of a diagram (rendering rules)  Scalable diagram loading  We need a way to load diagrams incrementally as they are browsed  Diagram Auto layout  We need a way to declare auto layout strategy for a diagram  Mapping OWL to UML Notation  We need to define a mapping of the UML notation to OWL  Multi resource editing  We need a way to declare which resources should be impacted by a high level gesture

19 Open Issues  Domain Extensibility  We need a strategy for automatically managing extensions across document boundaries  Domain Subsetting  We need a strategy for defining a subset of a domain that should be visible

20 © Copyright IBM Corporation All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.  What tooling do you get by defining ?