Towards a More Collaborative and Integrated Approach to Software Design Simula Research Lab - PowerPoint PPT Presentation

Towards a More Collaborative and Integrated Approach to Software Design
1 / 30

  • Uploaded on
  • Presentation posted in: General

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

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,



  • Design tools are becoming collaborative and integrated in lifecycle

  • Design tools are embracing semantic web technologies

Design is a key phase of development lifecycle

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

Challenges for design tools today

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

Required design tool features

Required Design Tool Features

  • CollaborativeTeam Access

  • Team Awareness

  • Lifecycle integration

  • Configuration management

  • Parallel development

  • Expressive Design Domains

Design management a collaborative design solution

Design Management: a Collaborative Design Solution

  • Rational Design Management (DM)











Collaborative team access

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







Team awareness

Team Awareness

  • Provide a project overview dashboard as a mashup of widgets

Towards a more collaborative and integrated approach to software design simula research lab

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

Configuration management

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

Parallel development

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

Expressive design domains

Expressive Design Domains

  • Structured Domains

    • UML, BPMN

  • Non Structured Domains

    • Sketches, Rich Text

  • Custom Domains

    • Abstract syntax

    • Concrete syntax

    • Tool behavior

Design tools embracing semantic web

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

Representing designs with rdf

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:about="#William">

<rdf:sameAs rdf:resource=“#Bill”/>


<rdf:Description rdf:about=“people#Person">

<rdf:equivalentClass rdf:resource=“species#Human”/>


<rdf:Description rdf:about=“#activity1">


<notation:Diagram rdf:resource=“#Diagram1”/>


Defining design domains with owl

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">


<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:about=“uml#Comment">

<rdf:type rdf:resource=“owl#Class”/>



<owl:onProperty rdf:resource=“uml#context”/>




<rdf:type rdf:resource=“dmcore:GraphType”/>


Linking design tools to other lifecycle tools with oslc

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

Overview of oslc

Overview of OSLC

  • Service Provider

  • Resource

  • Resource Shape

  • Data Integration API

  • UI Integration API

Oslc service provider api

OSLC Service Provider API

  • Defines the domain [AM, RM, QM or CM]

  • Defines creation factory URL

  • Defines Query capability URL

Oslc resource

OSLC Resource

  • A resouce is represented following the principles of linked data

    • A resource is identified with a web URL (

    • 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=""> <rdf:type rdf:resource=“uml#Class”/>

<dcterms:title>Class 1</dcterms:title>

<dmoslc:validatedBy rdf:resource=“../testcase1”/>


Oslc resource shape

OSLC Resource Shape

  • OWL supports open world assumption

  • OWL ontology supports inferencing

  • Validation requires closed world assumption

  • Resource Shape supports validation

Oslc data integration api

OSLC Data Integration API

  • Retrieve/update/delete using HTTP GET/ PUT/DELETE on resource URI

    • HTTP GET

    • HTTP GET, uml:NamedElement_visibility

  • Create using HTTP POST on creation factory URI

    • HTTP PUT

  • Query using HTTP GET on query base URI

    • HTTP GET”Class1”

User interface integration api

User Interface Integration API

  • Delegated UI: consumer tool invokes dialogs supplied by provider tools

    • Resource creation dialog URI

    • Resource selection dialog URI

User interface integration api1

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:

Design management implements oslc

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

Converting xmi models to rdf resources

Converting XMI Models to RDF Resources

<owl:Ontology rdf:about=“dsl#“/>

<owl:Class rdf:about=“dsl#X“>



<owl:onProperty rdf:resource=“dsl#a”/>





<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 rdf:about=“dsl#b">

<rdfs:domain rdf:resource=“dsl#Y”/>

<rdfs:range rdf:resource=“xsd:String”/>


<owl:ObjectProperty rdf:about=“dsl#c">

<rdfs:domain rdf:resource=“#X”/>

<rdfs:range rdf:resource=“#Y”/>


  • Mapping XMI data to RDF triples

    • Metamodel mapping: MOF to OWL and reverse

    • Profile mapping: Profie to OWL and reverse

    • Instance model mapping






a:Integer [1]

b:String [*]


c *

<owl:Ontology rdf:about=“pdsl#“/>

<owl:Class rdf:about=“pdsl#Z“>

<dm:compatibleWith rdf:resource=“dsl#Y”/>


<owl:DatatypeProperty rdf:about=“dsl#d">

<rdfs:domain rdf:resource=“dsl#X”/>

<rdfs:range rdf:resource=“xsd:Boolean”/>


<dsl:Y rdf:about=“#y1 ">

<rdf:type rdf:resource=“pdsl#Z”/>




Providing rdf resources as oslc resources

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

Providing owl ontologies as oslc resource shapes

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

Oslc integrated workflow

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)



  • Login