Design Management: a
Collabortive Design
Solution
ECMFA 2013
Montpellier, France
Maged Elaasar (Presenter)
Senior Software Engineer, IBM
melaasar@ca.ibm.com
Jim Conallen
Senior Software Engineer, IBM
jconallen@us.ibm.com
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
2
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
3
Required Design Tool Features
 CollaborativeTeam Access
 Team Awareness
 Lifecycle integration
 Configuration management
 Parallel development
 Expressive Design Domains
4
Design Management: a Collaborative Design Solution
 Rational Design Management (DM)
Rational
Software
Architect
DM
Rational
Design
Management
Rational
DM
Rhapsody
5
6
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
 Provide a project overview dashboard as a mashup of widgets
7
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
8
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
9
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
10
Expressive Design Domains
 Structured Domains
UML, BPMN
 Non Structured Domains
Sketches, Rich Text
 Custom Domains
Abstract syntax
Concrete syntax
Tool behavior
11
Design Management: Embracing Semantic Web
 Semantic web makes it easier to build modern design tools
Representing designs with RDF
Defining design domains with OWL
Linking designs to lifecycle artifacts with OSLC
12
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>
13
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)
 Generic mapping from/to MOF-defined metamodels
Support for mapping profiles (using multi-classification)
<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=“#class1 ">
<rdf:type rdf:resource=“uml#Class”/>
<rdf:type rdf:resource=“sysml#Block”/>
<sysml:isEncapsulated>true</sysml:isEncapsulated>
</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>
14
Linking Designs to Lifecycle Artifacts with OSLC
 DM adopts Open Services for Lifecycle Collaboration (OSLC)
Designs are represented using linked data (URI, RDF graph, etc.)
Designs have expected OSLC properties (e.g., dcterms:title)
Designs may use predefined link propeties (e.g.,dmoslc:validatedBy)
<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>
15
Contributions and Future Work
 Described challenges facing software design tools today
 Identified features that should help tools meet these challenges
 Provided examples in the context of Design Management (DM) tool
 Discussed how semantic web can help realize some of those features
 Future work includes:
Assess impact of DM on design team productivity through case studies
Define ways to define a rigorous design process
Support configurations across the lifecycle
Support automation of design migration due to domain evolution
16
17
17