1. Towards a More Collaborative and Integrated Approach to Software Design Simula Research Lab Oslo, July 2013 Maged Elaasar, Ph.D. melaasar@gmail.commelaasar@gmail.com

2. 2 Agenda Design tools are becoming collaborative and integrated in lifecycle Design tools are embracing semantic web technologies

3. 3 Design is a Key Phase of Development Lifecycle Reduces software development complexity Identifies issues early in development lifecycle Documents technical decisions for stakeholders Accelerates implementations through model-driven development

4. 4 Challenges for Design Tools Today Designers work in silos unaware of team activities Difficult to express designs in a suitable formalism Difficult to share designs and get feedback from stakeholders Difficult to work in parallel on design with other designers Difficult to manage change and variability of design Difficult to link designs to other lifecycle artifacts Difficult to trace and analyze the impact of design changes Difficult to create reports across multiple designs and lifecycle artifacts

5. 5 Required Design Tool Features CollaborativeTeam Access Team Awareness Lifecycle integration Configuration management Parallel development Expressive Design Domains

6. 6 Rational Design Management (DM) Design Management: a Collaborative Design Solution Rational Software Architect Rational Rhapsody DM Rational Design Management

7. 7 Collaborative Team Access Shared design respository with one or more clients Access with role-based permissions Search using keywords or queries Browse elements and discover relationships Collaborate by mark-up, comment, and review RSA Client Rhapsody Client Web Client

8. 8 Team Awareness Provide a project overview dashboard as a mashup of widgets

9. 9 Lifecycle Integration Create links to other lifecycle artifacts Preview link details and navigate to the linked artifact Create reports and generate documents that cover linked artifacts Analyze the impact of change to artifacts across the lifecycle

10. 10 Configuration Management Designs are organized into project Designs evolve with change sets producing new versions Design versions are recorded in one or more configurations A configuration can be changeable (workspace) or frozen (snapshot) Configurations are organized in a hierarchy

11. 11 Parallel Development Support a traditional design process Designer works in a private WS and delivers/rebases to intergration WS Conflicts are resolved with compare/merge Support an agile design process More than one designer work in parallel in same WS Minimize edit lock-out by maximizing design componentization

12. 12 Expressive Design Domains Structured Domains UML, BPMN Non Structured Domains Sketches, Rich Text Custom Domains Abstract syntax Concrete syntax Tool behavior

13. 13 Design Tools: Embracing Semantic Web Semantic web makes it easier to build modern design tools Representing designs with RDF Defining design domains with OWL Linking design tools to other lifecycle tools with OSLC

14. 14 Representing Designs with RDF Designs are represented as RDF graphs Design integration (multi-classification, aliases) Design extension (open world assumption) Design modularization (multi-definition) Separation of concerns Parallel development Activity 1 true

15. 15 Defining Design Domains with OWL Design domains are defined with OWL ontologies that define Syntax (some validation, reflective tooling) Semantics (reasoning, consistency check) Extra tooling annotations (e.g., componentization, cascade delete) Context 1

16. 16 Linking Design Tools to Other Lifecycle Tools with OSLC Integrated development environment (IDE) Tools follow the IDE guidelines (e.g., Eclipse) Tools use common components (e.g., GEF, EMF) Does not help integrate tools built on different platforms Does not help when data or API used for integration evolve Open Services for Lifecycle Collaboration (OSLC) Data representation based on the principles of linked data Minimal web-based API allowing workflow integration

17. 17 Overview of OSLC Service Provider Resource Resource Shape Data Integration API UI Integration API

18. 18 OSLC Service Provider API Defines the domain [AM, RM, QM or CM] Defines creation factory URL Defines Query capability URL 01 02 03 04 05 06 07 08 09 10 11 12 13 14 @prefix oslc:. a oslc:ServiceProvider; oslc:service [ a oslc:Service; oslc:domain ; oslc:creationFactory [ a oslc:CreationFactory; oslc:creation http://abc.com/toolA/contentshttp://abc.com/toolA/contents ]; oslc:queryCapability [ a oslc:QueryCapability; oslc:queryBase http://abc.com/toolA/contentshttp://abc.com/toolA/contents ] 01 02 03 04 05 @prefix rdfs:. ; # … 998 more triples here ….

19. 19 OSLC Resource A resouce is represented following the principles of linked data A resource is identified with a web URL (http://abc.com/dm/model/000) A resource is represented as an RDF graph Contains standard set of properties (e.g., rdfs:type, dcterms:title ) May contain pre-defined link properties May contain other properties (open world assumption) Class 1

20. 20 OSLC Resource Shape OWL supports open world assumption OWL ontology supports inferencing Validation requires closed world assumption Resource Shape supports validation 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 @prefix oslc:. @prefix xsd:. @prefix dcterms:. @prefix uml:. a oslc:ResourceShape; dcterms:title "Shape of resources of type UML Class"; oslc:describes: uml:Class; oslc:property [ a oslc:Property; dcterms:title "details for dcterms:title property"; oslc:propertyDefinition dcterms:title; oslc:name "title"; oslc:occurs oslc:Zero-or-many; oslc:valueType xsd:String ]; oslc:property [ a oslc:Property; dcterms:title "details for visibility property"; oslc:propertyDefinition uml:NamedElement_visibility; oslc:name "visibility"; oslc:occurs oslc:Zero-or-one; oslc:valueType oslc:Resource; oslc:allowedValue uml:VisibilityKind::public; oslc:allowedValue uml:VisibilityKind::private; oslc:allowedValue uml:VisibilityKind::protected; oslc:allowedValue uml:VisibilityKind::package ]; oslc:property [ a oslc:Property; dcterms:title "details for superClass property"; oslc:propertyDefinition uml:Class_superClass; oslc:name "superClass"; oslc:occurs oslc:Zero-or-many; oslc:valueType oslc:Resource; oslc:range uml:Class ].

21. 21 OSLC Data Integration API Retrieve/update/delete using HTTP GET/ PUT/DELETE on resource URI HTTP GET http://abc.com/dm/model/001http://abc.com/dm/model/001 HTTP GET http://abc.com/dm/model/001?oslc.properties=dcterms:title, uml:NamedElement_visibilityhttp://abc.com/dm/model/001?oslc.properties=dcterms:title, uml:NamedElement_visibility Create using HTTP POST on creation factory URI HTTP PUT http://abc.com/dm/model/contents http://abc.com/dm/model/contents Query using HTTP GET on query base URI HTTP GET http://abc.com/dm?oslc.where=dcterm:title=Class1http://abc.com/dm?oslc.where=dcterm:title=Class1

22. 22 User Interface Integration API Delegated UI: consumer tool invokes dialogs supplied by provider tools Resource creation dialog URI Resource selection dialog URI

23. 23 User Interface Integration API Link preview: consumer tool asks provider tool for compact rendering Consumer does HTTP GET with application/x-oslc-compact+xml header Provider replies with RDF/XML document containing:

24. 24 Design Management Implements OSLC RSA Design Management server implements OSLC Converting XMI models to RDF resources Providing RDF resources as OSLC resources Providing OWL ontologies as OSLC resource shapes

25. 25 Converting XMI Models to RDF Resources Mapping XMI data to RDF triples Metamodel mapping: MOF to OWL and reverse Profile mapping: Profie to OWL and reverse Instance model mapping Hello true 1 dsl a:Integer [1] X b:String [*] Y c * pdsl d:Boolean Z

26. 26 Providing RDF Resources as OSLC Resources HTTP GET with a special OSLC header Add expected OSLC types to resources (e.g., oslc_am:Resource) Add expected OSLC properties to resources (e.g., dcterms:title) Filter types and properties not intended to be exposed to OSLC

27. 27 Providing OWL Ontologies as OSLC Resource Shapes Provide a mapping from OWL ontologies to OSLC resource shape Define a resource shape for each given OWL class Add all properties with the OWL class (or its superclasses) as the propertys domain Derive the oslc:name, oslc:occurs, oslc:valueType, oslc:allowedValue from OWL ontology @prefix oslc:. @prefix xsd:. @prefix dcterms:. @prefix uml:. a oslc:ResourceShape; dcterms:title "Shape of resources of type Y"; oslc:describes: dsl:Y; oslc:property [ a oslc:Property; dcterms:title b"; oslc:propertyDefinition dsl:b; oslc:name b"; oslc:occurs oslc:Zero-or-many; oslc:valueType xsd:String ];

28. 28 OSLC Integrated Workflow Al wants to change the signature of operation sendMessage(buffer) Al performs a multi-level impact analysis diagram on the operation Change Request (CM) Requirement (RM) Test Case (QM)

29. 29 Summary

30. 30