Towards a More Collaborative and Integrated Approach to Software Design
This presentation is the property of its rightful owner.
Sponsored Links
1 / 30

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


  • 59 Views
  • 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. [email protected] Agenda. Design tools are becoming collaborative and integrated in lifecycle Design tools are embracing semantic web technologies.

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, [email protected]


Agenda

Agenda

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

Rational

Software

Architect

DM

Rational

Design

Management

Rational

Rhapsody

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

RSA

Client

Rhapsody

Client

Web

Client


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


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

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


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


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://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”


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

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


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)


Summary

Summary


  • Login