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

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

  • Uploaded on

Towards a More Collaborative and Integrated Approach to Software Design Simula Research Lab Oslo, July 2013. Maged Elaasar, Ph.D. [email protected] 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

PowerPoint Slideshow about ' Towards a More Collaborative and Integrated Approach to Software Design Simula Research Lab' - lynde

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

Oslo, July 2013

Maged Elaasar, [email protected]

Agenda Software Design

  • 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 Software Design

  • 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 Software Design

  • 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 Software Design

  • 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 Software Design

  • Rational Design Management (DM)











Collaborative team access
Collaborative Team Access Software Design

  • 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 Software Design

  • Provide a project overview dashboard as a mashup of widgets

Lifecycle Integration Software Design

  • 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 Software Design

  • 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 Software Design

  • 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 Software Design

  • 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 Software Design

  • 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 Software Design

  • 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 Software Design

  • 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 Software Design

  • 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 Software Design

  • Service Provider

  • Resource

  • Resource Shape

  • Data Integration API

  • UI Integration API

Oslc service provider api
OSLC Service Provider API Software Design

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

  • Defines creation factory URL

  • Defines Query capability URL

Oslc resource
OSLC Resource Software Design

  • 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 Software Design

  • 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 Software Design

  • 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 Software Design

  • 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 Software Design

  • 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 Software Design

  • 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 Software Design

<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 Software Design

  • 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 Software Design

  • 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 Software Design

  • 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)

Summary Software Design