CoDesign A Highly Extensible Collaborative Software Modeling Framework

10 

Loading....

Loading....

Loading....

Loading....

Loading....

Full text

(1)

CoDesign – A Highly Extensible

Collaborative Software Modeling Framework

Jae young Bang, Daniel Popescu, George Edwards, and Nenad Medvidovic

University of Southern California Los Angeles, CA 90089-0781, USA

{jaeyounb, dpopescu, gedwards, neno}@usc.edu

Naveen Kulkarni, Girish M. Rama, and Srinivas Padmanabhuni

Infosys Technologies Limited

Bangalore 560 100, India

{Naveen_Kulkarni, Girish_Rama, srinivas_p}@infosys.com

ABSTRACT

Large, multinational software development organizations face a number of issues in supporting software design and mod-eling by geographically distributed architects. To address these issues, we present CoDesign, an extensible, collabora-tive, event-based software modeling framework developed in a distributed, collaborative setting by our two organizations. CoDesign’s core capabilities include real-time model syn-chronization between geographically distributed architects, as well as detection and resolution of a range of modeling conflicts via several off-the-shelf conflict detection engines.

1.

INTRODUCTION

In recent years, many technology companies have trans-ferred significant portions of their software development ac-tivities to emerging economies such as India and China [15]. At the same time, many stakeholders, such as customers and requirements engineers, remain in developed countries. As a result, companies have created global software development teams in which engineers are separated by large geographic distances. While the economic advantages of distributed software development are real, communication challenges must be overcome in order to fully realize these advantages. Convincing evidence shows that geographic separation can drastically reduce communication among coworkers [6, 7, 13]. Irregular and ineffective communication typically pre-vents shared understanding of problems and solutions, and incurs redundant work during software development.

In the past, global software teams relied on traditional IDEs that were developed for co-located development teams along with software configuration management (SCM) sys-tems. SCM tools, such as CVS and Subversion, allow engi-neers to work on software artifacts independently and with reduced planning and coordination because they

automat-Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

ICSE’10 Cape Town, South Africa

Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$10.00.

ically merge modifications and detect conflicting changes. However, SCM systems do not detect conflicts until the en-gineers “check in” changes, at which point unnecessary or useless effort may have already been expended. Further-more, conflicts may be more difficult and time-consuming to resolve at this stage.

To detect conflicts earlier and avoid costly conflict resolu-tion,collaborative IDEshave become a popular mechanism to provide engineers with awareness of the concurrent devel-opment activities of their coworkers [1, 3, 5, 14]. Most col-laborative IDEs detect conflicting concurrent modifications to the same artifact – such as the same file – and provide real-time notifications of these obvious, direct conflicts. A more limited number of collaborative IDEs also detect in-direct conflicts that require more rigorous analysis [5, 14]. For example, if one engineer changes the implementation of a component while another engineer concurrently modifies the component’s interface, an indirect conflict could result.

Current collaborative IDEs primarily focus on distributed

programming. Other critical development tasks, particularly

architecture design and modeling, are not readily supported, even though these activities require frequent interactions among team members and short feedback cycles [2]. As a result, geographically-distributed software architects still create and edit their models in traditional modeling environ-ments and check-in their changes to a repository using an SCM system. Of course, this results in all the same problems noted above that collaborative IDEs help to solve. Like col-laborative IDEs for programmers, software architects need collaborative modeling environments that detect conflicts in real-time, rather than waiting for a check-in action.

We presentCoDesign, a collaborative software modeling environment that supports system design in geographically distributed work settings. A conceptual view of CoDesign is depicted in Figure 1. At its core, CoDesign relies on CoW-are, a lightweight middleware platform that (1) provides the integration infrastructure, (2) synchronizes concurrent ed-its made in distributed CoDesign instances, and (3) notifies architects of conflicting modeling decisions.

CoDesign’s main contribution is anextensible conflict

de-tection framework for collaborative modeling. CoDesign

uti-lizes an event-based architecture [16] in which highly-decoupled components—different instances of CoDesign—exchange mes-sages via implicit invocation, allowing flexible system com-position and adaptation. CoDesign couples this event-based

(2)

Figure 1: High-Level Architecture of CoDesign.

architecture with an API that provides explicit extension points for plugging in conflict detection engines. This al-lows different CoDesign clients (e.g., a UML modeling tool or a finite state machine modeling tool) to be paired with the most appropriate consistency checkers. It also allows multiple consistency checkers to be used in concert, in or-der to handle different types of modeling inconsistencies (see Section 2). To demonstrate this capability of CoDesign, we have integrated three off-the-shelf conflict detection engines: Drools [8], Jess [9], and a metamodel checker [4].

In Section 2, we classify the types of conflicts that can oc-cur during collaborative distributed architectural modeling. Section 3 then explains the architecture and implementation of CoDesign, with a particular focus on CoDesign’s extensi-bility mechanism. The paper concludes with a summary of lessons learned and a discussion of planned future work.

2.

DESIGN-TIME CONFLICTS

When designing distributed collaborative systems, it is necessary to understand the potential issues and conflicts caused by modeling events that are generated simultane-ously in remote locations. Two categories of issues may occur in collaborative software modeling over the network: parallel modification and modeling conflicts.

Parallel modification represents a situation when multiple

architects modify the same modeling object or multiple ob-jects that are very close in a model, e.g., an object and its parent. Parallel modification need not manifest itself as a conflict. However, detecting it and notifying the architects may be crucial as a warning to exercise caution and avoid future conflicts. For example, even though two simultaneous modifications to an object and its parent may be consistent with one another, each of the architects making one of those modifications may be unaware of the other architect’s ac-tions and may be more likely to make subsequent changes that will, in fact, result in a conflict.

Aconflict, as we define it, is an issue that is engendered by

synchronization latency, that is, when one architect makes a design decision that cannot be reconciled with another design decision that was made previously but that has not yet been synchronized with the architect’s local model data (i.e., with the local CoDesign Instance in Figure 1). Be-cause of their nature, decentralized systems cannot always be perfectly synchronized, inducing the architects to make such potentially erroneous decisions.

We categorize modeling-level conflicts into three classes based on the rules that the system modeling events vio-late: (1) synchronization, (2) syntactic, and (3) semantic conflicts. Each category is briefly elaborated next.

Synchronization conflictscan be resolved with little or no human intervention. For example, if an architect removes a class from a system model and another architect decides to add an attribute to the same class before the removal event arrives, those two events would result in inconsistent states in the two CoDesign instances. This type of conflict would not happen if the two architects were in the same workspace, since the removal event would be instantly “recorded” and the class would no longer be there for the second architect to modify. Although synchronization conflicts are the simplest of the three conflict types, they are the most common and thus must be detected and resolved efficiently and scalably.

Syntactic conflictsviolate a modeling tool’s or language’s meta-model constraints. Suppose, e.g., that an architect connects an instance a1 of class A with an instanceb1 of classBand, before the connection addition event arrives, an-other architect connectsa1and a new instanceb2 of classB. If the cardinality constraint of the meta-model allows class

A to have an association to only one instance of class B, this becomes a conflict that would likely not have occurred if the two architects were co-located. When the modeling tool such as CoDesign receives the second event, the tool’s meta-model constraint checker will detect an error. Alter-natively, the tool could experience an unexpected crash if it does not support syntactic conflict detection. Either way, unlike the synchronization conflicts, the resolution of syn-tactic conflicts will typically require human intervention.

Unlike the synchronization and syntactic conflicts, se-mantic conflictsreflect violations in theintended, implicit rules by which a system’s model should abide. For example, a collaboratively completed design in a given architecture description language (ADL) [16] may have no irreconcilable events on the same model elements (i.e., no synchronization conflicts) and no violations of the ADL’s grammar (i.e., no syntactic conflicts). However, the model may be modified in a way that violates, e.g., the rules of the underlying design style. As a simple example, let us assume that the intended style is client-server. An architect may model componentC1

to make direct requests of componentC2 in the system; the implication of this is thatC1 is a client andC2 is a server. Another architect may, however, model component C2 to make direct requests of component C1; the implication of this interaction dependency is thatC1 is, in fact, a server and C2 a client. Hence, the same component is erroneosly modeled both as a client and a server. Again, the language in which the model is specified (e.g., UML) may not consider this a conflict. In order to be properly checked for, this se-mantic rule would have to be specified externally (e.g., in the Object Constraint Language, or OCL). As with syntac-tic conflicts, semansyntac-tic conflicts such as the one illustrated

(3)

Architect-side GME (Modeling Tool)

GME API (BON)

CoDesign GME Adapter Event Handler Update Handler CoDesign/CoWare Connector CoWare Client Event Queue Prism Connector Login GUI Architect Server-side CoWare Server Prism Connector Conflict Detector User Management Drools GME Meta-model Checker DB Connector User DB Event Storage User Information User Information Events New Events User Information Conflict-free Events Conflict Notifications New Events Conflicts Conflicts User Information & New Events Conflict Notifications & Broadcasted Conflict-free Events

Conflict Detector Connector

User Information New Events Conflict-free Events New Events

New Events

Conflict-free Events Conflict-free Events

New Events Conflicts

Figure 2: CoDesign’s Architecture. The double-lined polygons represent off-the-shelf software.

above can only be highlighted by a tool such as CoDesign, but cannot be resolved without human intervention.

3.

CODESIGN

In this section, we describe CoDesign’s architecture and mechanism for enabling the integration of off-the-shelf (OTS) conflict detection engines. As mentioned previously, CoDe-sign aims to support integration of a variety of modeling lan-guages and environments. Since modeling lanlan-guages differ in the way their syntax and semantics are defined, CoDe-sign allows distributed architecture teams to use their own specific conflict detection engines rather than attempting to provide a general-purpose conflict detection engine. Sec-tion 3.1 provides an example use case scenario of a collabora-tive conflict that helps to describe CoDesign’s architecture. Section 3.2 describes CoDesign’s conflict detection extension points and the integration and customization of two OTS components for conflict detection; other such components (e.g., Jess) have been integrated in the same manner.

3.1

CoDesign’s Architecture

CoDesign uses a modeling tool-specific adapter (compris-ing a CoDesign Instance in Figure 1) to capture design deci-sions, in the form of model updates, from architecture mod-eling tools. Each model update is subsequently encapsulated within a CoWare design event and is transferred through the CoWare infrastructure. A CoWare Client is installed at each architect location to connect a CoDesign adapter to a CoWare Server, which is running a Conflict Detector mod-ule. The design events are forwarded from the CoDesign adapter, through the CoWare Client and CoWare Server, to the Conflict Detector. The Conflict Detector evaluates each event to determine whether it conflicts with any previous event(s) by requesting all plugged-in conflict detection en-gines to analyze the event. The CoWare Server broadcasts each event back to all CoWare Clients only if all plugged-in

conflict detection modules affirm that the design event does not cause any conflict. However, if a conflict exists, CoWare (1) tries to resolve the conflict by itself and (2) alerts those architects involved in the conflict by generating a notifica-tion message.

Figure 2 depicts our implementation. We use three off-the-shelf software components: (1) GME [4], a software modeling tool from Vanderbilt University, (2) Drools [8], a rule-based business logic integration platform developed by the JBoss community, and (3) Prism-MW [12], an event-based middleware platform created at the University of South-ern California.

As noted above, the use of GME with CoDesign requires a GME-CoDesign Adapter. The adapter captures design decisions made by architects using GME via GME’s native API, packages them within Prism-MW events, and transfers them to the CoWare Client. The CoWare Client receives the events and utilizes Prism-MW’s connector facilities to send them to the Conflict Detector in the CoWare Server. In this particular CoDesign configuration, we use Drools to detect synchronization conflicts, GME’s native metamodel checker to detect syntactic conflicts and GME’s OCL con-straint checker to detect semantic conflicts.

As a simple scenario of conflict detection, suppose an ar-chitect A1 deletes a design element e1 from her model in GME. Once the Prism-MW event generated by this design decision arrives at the Conflict Detector, each plugged-in conflict detection engine will analyze it. The GME meta-model checker and Drools respond that the event does not cause a conflict. Both engines may also store the event tem-porarily or permanently, depending on the circumstances. The CoWare Server then broadcasts the event back to all CoWare Clients except the original sender,A1.

Now suppose another architectA2 changes the geometric location of e1 before the remote deletion event is applied to her local model data. The event is sent to the Conflict

(4)

Detector via the same route, and this time the Drools engine detects that the model update applies to an object that no longer exists. CoWare does not broadcast the location event, and since the intentions of the two architects differ, CoWare notifies the involved architects to ensure that they are aware of the situation.

3.2

Extending CoDesign

We illustrate CoDesign’s support for integrating and cus-tomizing conflict detection engines using two example en-gines: Drools and GME’s metamodel checker.

Detecting synchronization conflicts using Drools:

Drools is a production rule system that can be used to de-tect complex events [11]. Drools evaluates whether a pro-duction rule triggers based on the facts it receives and com-putes. A production rule follows a simple pattern: when

<condition>then<action>. A complex event(e.g., a syn-chronization conflict) is a pattern-based abstraction of other events and can also be evaluated using production rule sys-tems [10]. Whenever CoDesign’s Drools customization re-ceives a CoDesign event to evaluate, it adds the event to its working memory and evaluates all synchronization conflict rules. Figure 3 shows a simplified example of a Drools rule that detects when one CoDesign client changes a model el-ement that had already been deleted by another CoDesign client. CoDesign is able to detect modifications to the same model elements because all distributed instances of a model element have a single objectID in every CoDesign client.

Detecting syntactic and semantic conflicts using GME: In the CoDesign configuration described thus far, GME is used as the system modeling environment. Hence, this CoDesign configuration’s syntactic and semantic con-flict detection engines need to understand the syntax and semantic constraints of GME models. To ensure that syn-tactic and semantic conflicts are detected early, we reused and integrated the relevant components of GME. GME’s metamodel checker contains the logic that manages the data model and checks whether executing a received CoDesign event keeps the data model consistent with its meta-model.

Integrating conflict engines into CoDesign: To

in-tegrate an OTS conflict engine, we need to implement an adapter connector to translate CoWare events into invoca-tions of the conflict engine’s API and to tie the results re-turned by the conflict engine back to the conflicting events (see Figure 2). The Conflict Detector component checks each event that the CoWare Server receives from the CoDe-sign Clients. Since the Conflict Detector is unaware of the syntax and the semantic constraints of the edited models, it does not itself check whether an event causes a conflict but forwards each event to the Conflict Detector Connector. The Conflict Detector Connector distributes the event to each

1 r u l e ” O b j e c t was e d i t e d a f t e r 2 i t had a l r e a d y been removed ” 3 when

4 $ e 1 : Event ( name == ”remove ”)

5 $ e 2 : Event ( $ e 1 . o b j e c t I D == o b j e c t I D , 6 timestamp > $ e 1 . timestamp ) 7 then

8 o u t . s e n d ( new C o n f l i c t E v e n t ( $e1 , $ e 2 ) ; 9 end

Figure 3: Synchronization Conflict Detection Rule

integrated conflict detection engine, which in turn evaluate the received event in parallel. The results are returned to the connector and evaluated by the Conflict Detector, which notifies the CoDesign Clients in the case of conflicts.

4.

CONCLUSION AND FUTURE WORK

CoDesign is a software modeling infrastructure, devel-oped collaboratively at our two institutions, that supports real-time model synchronization between geographically dis-tributed software architects, as well as detection and reso-lution of syntactic and semantic modeling conflicts. While CoDesign is a mature prototype, the work on CoDesign is on-going. We are investigating the root causes of design-time conflicts, the relationships between conflict types and modeling activities, and conflicts caused by complex event sequences, such as those caused by many parallel events. Since we are a geographically distributed team, CoDesign has presented a unique opportunity for “reflective” use in its own design and implementation. In turn, this has allowed us to test first-hand its scalability, efficiency, and extensibility.

5.

REFERENCES

[1] J. T. Biehl et al. Fastdash: a visual dashboard for fostering awareness in software teams. InProc. CHI

2007.

[2] M. Cataldo et al. Camel: A tool for collaborative distributed software design. InProc. ICGSE 2009. [3] L.-T. Cheng et al. Jazzing up eclipse with

collaborative tools. InProc. OOPSLA Workshop on

Eclipse Technology eXchange. ACM, 2003.

[4] GME.http://isis.vanderbilt.edu/projects/gme/. [5] R. Hegde and P. Dewan. Connecting programming

environments to support ad-hoc collaboration. In

Proc. ASE 2008.

[6] J. Herbsleb. Global Software Engineering: The Future of Socio-technical Coordination. InICSE: 2007 Future

of Software Engineering. ACM, 2007.

[7] P. J. Hinds and D. E. Bailey. Out of sight, out of sync: Understanding conflict in distributed teams.

Organization Science, 14(6):615–632, 2003.

[8] jBoss Drools.http://jboss.org/drools/. [9] Jess.http://www.jessrules.com/.

[10] G. Li and H.-A. Jacobsen. Composite subscriptions in content-based publish/subscribe systems. InProc.

Middleware, 2005.

[11] D. Luckham.The power of events: an introduction to complex event processing in distributed enterprise

systems. Springer, 2002.

[12] S. Malek et al. A style-aware architectural middleware for resource-constrained, distributed systems.IEEE TSE, pages 256–272, 2005.

[13] G. M. Olson and J. S. Olson. Distance matters.

Human-Computer Interaction, 15(2):139–178, 2000.

[14] A. Sarma et al. Towards supporting awareness of indirect conflicts across software configuration management workspaces. InProc. ASE 2007. ACM. [15] B. Sengupta et al. A research agenda for distributed

software development. InProc. ICSE 2006.

[16] R. N. Taylor et al.Software Architecture: Foundations,

(5)

CoDesign Demonstration Script

Jae young Bang, Daniel Popescu, George Edwards, Nenad Medvidovic

Computer Science Department

University of Southern California

{jaeyounb,dpopescu,gedwards,neno}@usc.edu

Naveen Kulkarni, Girish M. Rama, and Srinivas Padmanabhuni

Infosys Technologies Limited

Bangalore 560 100, India

{Naveen_Kulkarni,Girish_Rama,srinivas_p}@infosys.com

The CoDesign research demonstration will begin after a short presentation highlighting the main points of the accompanying research paper. The short presen-tation will explain:

The motivation of the work – why a

collabora-tive software modeling infrastructure is needed. We will give examples of software development off-shoring, explain the devel-opment of collaborative software design sys-tems, and introduce the overview of the project.

The theoretical foundations of our approach

how we categorized and defined the potential issues created by geographically distributed software modeling. We have grouped the is-sues, which we refer as conflicts, into three categories: (1) synchronization conflicts, which are directly conflicting design decisions that occur due to the latency between distri-buted architects, (2) syntactic conflicts, which are design decisions that cannot be simulta-neously accommodated by the metamodel of the modeling tool or language being used, and

(3) semantic conflicts, which are design

deci-sions that break the intended rules of the sys-tem being modeled. We define the terms using examples since the definitions of these terms vary based on context.

The CoDesign architecture – how we detect

and resolve conflicts. We discuss how exten-sibility is achieved and the roles of compo-nents in the high-level CoDesign architecture. We show the implementation of the architec-ture and the list of research off-the-shelf soft-ware used in the system.

We will then begin our demonstration. In this demon-stration, we will use (1) GME, a software modeling tool created by Vanderbilt University, (2) Drools, a business logic integration platform developed by the JBoss Community, and (3) Prism-MW, a lightweight middleware created by the software architecture re-search group at USC.

Start up:

1. An instance of the CoWare Server is initia-lized and waits for connections from CoWare Clients.

2. The plug-in conflict detection engines within the CoWare Server are instantiated automati-cally as CoWare Server initializes.

Figure 1: CoWare Server Initialization 3. Two or more architects (depending on the

pro-jection equipment in the demonstration room) denoted A1An connect CoWare Clients to

the CoWare Server. Each architect logs in with a unique user ID and password.

(6)

Figure 2: CoWare Client Start-up

4. After logging in, all architects receive identic-al copies of a design model from the CoWare Server. A diagram showing a portion of the design model is displayed on each architect’s screen.

Figure 3: Screens after Model Check-out 5. Each of the architects makes a modification to

a design element in the model, such as chang-ing its attributes, relations, or location in the model hierarchy. All other architects see the changes in near real-time.

Examples of Conflict Detection:

6. Synchronization Conflict – Architect A1

re-moves a modeling object, and Architect A2

changes the geometric location of it before the remote removal event has arrived and been applied to the second architect’s model data. We will (1) introduce an artificial delay in the event distribution and (2) color the relevant object(s) so that the audience may appreciate what is occurring. (See Figure 4)

Figure 4: Coloring Removed Objects

The action of A2 creates a conflict through

modification of an object that no longer exists. CoWare detects the conflict and notifies the architects. The notification includes informa-tion about the conflict, including (1) the iden-tities of the architects involved, (2) the model-ing elements involved, and (3) the actions that created the conflict. (See Figure 5)

Figure 5: Conflict Detection

7. Syntactic Conflict – We show the metamodel

for a client/server system in which each server can only support n clients. In the modeling environment, A1 connects n clients to a server

and A2 connects an additional client to the

server. CoWare detects the conflict and noti-fies the architects.

8. Semantic Conflict – We show a set of OCL

constraints for a component-based system. In this system, a component that makes requests of other components is a client, and a compo-nent that receives requests is a server. A com-ponent may not be both a client and a server. A1 creates a design element indicating that

component C1 makes a request of component

C2. A2 creates a design element indicating that

component C2 makes a request of component

C1. CoWare detects the conflict and notifies

the architects.

We conclude the demonstration by mentioning the po-tential of CoWare/CoDesign as an infrastructure for conducting additional research on collaborative model-ing environments.

(7)

CoDesign Screenshots

Jae young Bang, Daniel Popescu, George Edwards, Nenad Medvidovic

Computer Science Department

University of Southern California

{jaeyounb,dpopescu,gedwards,neno}@usc.edu

Naveen Kulkarni, Girish M. Rama, and Srinivas Padmanabhuni

Infosys Technologies Limited

Bangalore 560 100, India

{Naveen_Kulkarni,Girish_Rama,srinivas_p}@infosys.com

This screenshots document depicts an example conflict that two architects are collaboratively modeling at remote locations.

Figure 1: CoWare Server Start-up

As the first step, CoWare Server is turned on. Two architects then connect from CoWare Client to CoWare Server. The architects are requested to log in to CoWare.

Architect 1: A1 Architect 2: A2

Figure 2: A1 initializes CoWare Client Figure 3: A2 Initializes CoWare Client

(8)

Figure 4: A1’s CoWare Client Status after Log-in Figure 5: A2's CoWare Client Status after Log-in

Figure 6: CoWare Server Status after the Logging-in

The architects turn on GME, and check out the current model data to join the remote modeling session.

Architect 1: A1 Architect 2: A2

(9)

The architect A1 moves a design element, and A2 sees the change on her/his screen after synchronization.

Architect 1: A1 Architect 2: A2

Figure 9: A1's Screen after Moving an Element Figure 10: A2's Screen after Moving an Element The architect A1 removes a design element, and the element appears in red on A2’s screen.

Architect 1: A1 Architect 2: A2

(10)

The architect A2 changes the geometric location of removed object, which creates a synchronization conflict since A2 deletes an element that no longer exists in the model. CoDesign captures the conflict, and notifies both of them.

Architect 1: A1 Architect 2: A2

Figure 13: A1 Receives a Conflict Notification Figure 14: A2 Receives a Conflict Notification

Figure 15: CoWare Server Status after It Detects a Conflict between A1 and A2

The log of Conflict Detector shows that A1 and A2 have a conflict, and it sends conflict notification messages to both A1 and A2.

Figure

Updating...

References

Updating...

Related subjects :