codesign a highly extensible collaborative software modeling framework
Post on 25-Feb-2016
47 Views
Preview:
DESCRIPTION
TRANSCRIPT
S
CoDesignA Highly Extensible
Collaborative Software Modeling Framework
Jae young Bang (jaeyounb@usc.edu)
University of Southern California
Daniel PopescuGeorge EdwardsProf. Nenad Medvidovic
Naveen KulkarniGirish M. Rama
Dr. Srinivas Padmanabhuni
2
Trends• Globally distributed
software development• Large, multinational
software companies• Emerging economies
(India and China)• Widely distributed
stakeholders• Communication and
coordination challenges
3
Collaborative Development
• Current collaborative development tools• Traditional software configuration management
(SCM) tools• Based on check-in/check-out paradigm• Incur redundant work and wasted effort
• Next-generation collaborative integrated development environments (IDEs)• Oriented toward distributed programming, not
architecture design and modeling
• Software architects still use traditional SCM tools to coordinate model changes
4
CoDesign Project Motivation
• Infosys – a globally distributed software developer
• Use many proprietary/legacy/domain-specific tools
• Found existing collaborative tools are coupled to specific IDEs and lack extensibility• e.g., IBM Jazz (Eclipse) and MSR CollabVS (Visual Studio)
5
CoDesign Project Motivation
• Identified a need for a collaborative tool that allows:1. Arbitrary client applications (front-end)2. Client-specific management functions (back-end)
6
CoDesign Project Goals
• Extensible collaborative software modeling framework
• Real-time synchronization & conflict detection• Scalability of models and users• Objectives:
• Understand collaborative modeling issues• Define methods and processes to resolve issues• Develop designs and patterns for distributed
model management and conflict detection
7
Collaborative Design Issues
• Multiple architects unknowingly modify related objects• Caused by latency and lack of communication
• Two different types of issues• Parallel modification
• Changes are compatible, but architects should be alerted• Model conflicts
• Changes are not compatible, and must be resolved• Three types:
• Synchronization• Syntactic• Semantic
8
Parallel Modification
MoveDoctora
teto right
Change name to PostDoc
9
Synchronization Conflicts
• Simple conflicts caused by latency• Can be resolved with little or no human
intervention
Delete Doctora
te
Change name to PostDoc
!
10
• Conflicts that violate modeling tool’s or language’s constraints
Syntactic Conflicts
Metamodel defines an Ethernet Router can only have 0 to 4 Port(s)
Add a Port Add a Port
!
11
Semantic Conflict
• Either can be the server or the client; not both• The one that makes requests be the client• This can be defined using OCL
12
Semantic Conflict
Request from C1 to
C2
Request from C2 to
C1
!
13
Implication• Different types of conflicts require different
types of conflict detection engines• Synchronization, Syntactic, Semantic
• Conflict detection engines must be chosen based on the model tools and languages used
• Extensible collaborative tool is in need
14
CoDesign ImplementationGME: software modeling tool from Vanderbilt Univ.
CoWare: lightweight integration platform for CoDesign
Drools: business logic integration platform from jBoss community
15
Event Distribution
Design Decision
Broadcast “clean” event to the other architectsOr, send conflict notificationTo the involved architects
16
Ongoing Work
• Investigate of the type and nature of conflicts• Causes of conflicts• More complex conflicts
• Experiment with conflict resolution processes• Automated or semi-automated• Win-win negotiation
• Implement adaptive scope for parallel modification warnings• Based on usage profile and feedback
17
Contributions
• Collaborative software modeling framework• Real-time synchronization• Extensible architecture
• Categorization of collaboration issues and conflicts• Parallel modification vs. model conflicts• Synchronization, syntactic, and semantic
conflicts• Efficient and scalable conflict detection
18
Demonstration• Demo setup:
• Machine 1• CoWare Server• Conflict detection engines
• Machine 2• Two virtual machines
• CoWare Client/CoDesign Adapter/GME Modeling Tool
• Capabilities shown:• Synchronization between CoDesign instances• Conflict detection and notification
19
Contacts & References
• Jae young Bang jaeyounb@usc.edu• Nenad Medvidović neno@usc.edu• Jae young Bang, Daniel Popescu, George Edwards, Nenad
Medvidovic, Naveen Kulkarni, Girish M. Rama, and Srinivas Padmanabhuni, CoDesign – A Highly Extensible Collaborative Software Modeling Framework, Proceedings of the Research Demonstration Track at the 32nd International Conference on Software Engineering (ICSE10)
• Thank you!
20
Backup Slides
21
Overview1. Background and Motivation2. Project Goals3. Collaborative Design Conflicts4. CoDesign Architecture and Implementation5. Ongoing Work6. Live Demonstration
22
Current Tools• Collaborative modeling tools
• IBM Jazz• Tightly coupled with Eclipse
• Microsoft Research CollabVS• Tightly coupled with Microsoft Visual Studio• No open platform available for integration of existing
tools
• How can we detect and resolve design-time issues?
• Infosys had issues in extensibility
23
CoDesign ArchitectureGeneric Modeling Environment
From Vanderbilt University
Software Modeling Tool
Drools
From JBoss Community
Business Logic Integration Platform
Prism-MW
From SoftArch, USC
Lightweight Middleware
24
Semantic Conflicts• Conflicts that violate the intended meaning of
a model
Intended model: only clients can requestConstraint defined using OCLCloud cannot make requests; it isagainst the rule
!
25
• Conflicts that violate the intended meaning of a model
Semantic Conflicts
!
top related