1 / 30

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

Towards a More Collaborative and Integrated Approach to Software Design Simula Research Lab Oslo, July 2013. Maged Elaasar, Ph.D. melaasar@gmail.com. Agenda. Design tools are becoming collaborative and integrated in lifecycle Design tools are embracing semantic web technologies.

lynde
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related