Towards a More Collaborative and Integrated Approach to Software Design Simula Research Lab

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

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

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. 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. Required Design Tool Features • CollaborativeTeam Access • Team Awareness • Lifecycle integration • Configuration management • Parallel development • Expressive Design Domains

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

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. Team Awareness • Provide a project overview dashboard as a mashup of widgets

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. 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. 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. Expressive Design Domains • Structured Domains • UML, BPMN • Non Structured Domains • Sketches, Rich Text • Custom Domains • Abstract syntax • Concrete syntax • Tool behavior

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. 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 <rdf:Description rdf:about="#activity1"> <rdfs:label>Activity 1</rdfs:label> <rdf:type rdf:resource=“uml#Activity”/> <rdf:type rdf:resource=“bpmn#Activity”/> </rdf:Description> <rdf:Description rdf:about="#William"> <rdf:sameAs rdf:resource=“#Bill”/> </rdf:Description> <rdf:Description rdf:about=“people#Person"> <rdf:equivalentClass rdf:resource=“species#Human”/> </rdf:Description> <rdf:Description rdf:about=“#activity1"> <uml:isReadOnly>true</uml:isRealOnly> <notation:Diagram rdf:resource=“#Diagram1”/> </rdf:Description>

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) <rdf:Description rdf:about=“uml#context"> <rdfs:label>Context</rdfs:label> <rdf:type rdf:resource=“owl#ObjectProperty”/> <rdf:domain rdf:resource=“uml#Comment”/> <rdf:range rdf:resource=“uml#Namespace”/> <dmcore:cascadeDelete rdf:resource=“dmcore:cd-domain”/> </rdf:Description> <rdf:Description rdf:about=“uml#Comment"> <rdf:type rdf:resource=“owl#Class”/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource=“uml#context”/> <owl:maxCardinality>1</owl:maxCardinality> </owl:Restriction> </rdfs:subClassOf> <rdf:type rdf:resource=“dmcore:GraphType”/> </rdf:Description>

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. Overview of OSLC • Service Provider • Resource • Resource Shape • Data Integration API • UI Integration API

18. OSLC Service Provider API • Defines the domain [AM, RM, QM or CM] • Defines creation factory URL • Defines Query capability URL

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) <rdf:Description rdf:about="http://company.org/dm/model/123#class1"> <rdf:type rdf:resource=“uml#Class”/> <dcterms:title>Class 1</dcterms:title> <dmoslc:validatedBy rdf:resource=“../testcase1”/> </rdf:Description>

20. OSLC Resource Shape • OWL supports open world assumption • OWL ontology supports inferencing • Validation requires closed world assumption • Resource Shape supports validation

21. OSLC Data Integration API • Retrieve/update/delete using HTTP GET/ PUT/DELETE on resource URI • HTTP GET http://abc.com/dm/model/001 • HTTP GET http://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 • Query using HTTP GET on query base URI • HTTP GET http://abc.com/dm?oslc.where=dcterm:title=”Class1”

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

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. 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. Converting XMI Models to RDF Resources <owl:Ontology rdf:about=“dsl#“/> <owl:Class rdf:about=“dsl#X“> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource=“dsl#a”/> <owl:cardinality>1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about=“dsl#Y“/> <owl:DatatypeProperty rdf:about=“dsl#a"> <rdfs:domain rdf:resource=“dsl#X”/> <rdfs:range rdf:resource=“xsd:Integer”/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about=“dsl#b"> <rdfs:domain rdf:resource=“dsl#Y”/> <rdfs:range rdf:resource=“xsd:String”/> </owl:DatatypeProperty> <owl:ObjectProperty rdf:about=“dsl#c"> <rdfs:domain rdf:resource=“#X”/> <rdfs:range rdf:resource=“#Y”/> </owl:ObjectProperty> • Mapping XMI data to RDF triples • Metamodel mapping: MOF to OWL and reverse • Profile mapping: Profie to OWL and reverse • Instance model mapping dsl <profile>pdsl X Y <stereotype>Z a:Integer [1] b:String [*] d:Boolean c * <owl:Ontology rdf:about=“pdsl#“/> <owl:Class rdf:about=“pdsl#Z“> <dm:compatibleWith rdf:resource=“dsl#Y”/> </owl:Class> <owl:DatatypeProperty rdf:about=“dsl#d"> <rdfs:domain rdf:resource=“dsl#X”/> <rdfs:range rdf:resource=“xsd:Boolean”/> </owl:DatatypeProperty> <dsl:Y rdf:about=“#y1 "> <rdf:type rdf:resource=“pdsl#Z”/> <dsl:b>Hello</dsl:b> <pdsl:d>true</pdsl:d> </dsl:X>

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. 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 property’s domain • Derive the oslc:name, oslc:occurs, oslc:valueType, oslc:allowedValue from OWL ontology

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 Requirement (RM) Test Case (QM) Change Request (CM)

29. Summary