placed upon technological support of the software development process. .... Rationale (Knowledge management), User, and Communication (Chat, Phone. Etc.).
COMPUTER SUPPORTED COOPERATIVE SOFTWARE ENGINEERING: A FRAMEWORK FOR SUPPORTING DISTRIBUTED CONCURRENT GROUP MODELING OF SOFTWARE Naoufel Boulila Technische Universität München, Applied software engineering Chair, Advisor: Prof. Bernd Bruegge
1. MOTIVATION AND OVERVIEW The distributed development of software is increasingly widespread, driven by the globalization of companies and business and enabled by the improvements in communication and computing [1]. The distributed development of software introduces new aspects of cooperative work in which a greater emphasis is placed upon technological support of the software development process. Software development activities deal with the complexity by constructing and validating models of the application domain. Models are important artifacts used for communication within the organizations, developers and stakeholders as well. Constructing correct, complete, consistent, and unambiguous models is a tough task that needs concurrent participation of multiple users possibly geographically dispersed. Distribution of software development through meetings is harder to control. Distributed Meetings play typically a critical role in teamwork. During which large amount of implicit knowledge is exchanged through negotiation and conflicts resolution. Hence, efforts in supporting distributed development should focus on better supporting distributed meetings [2]. This research focuses on the specific problem of distributed brainstorming and the construction of UML models of software through successive distributed teamwork meetings. In Particular we investigate the issues we considered in designing a unified framework based on CSCW concepts and Software Engineering to support concurrent ObjectOriented software analysis and design phases. We present an activity-based model and a prototype called GroupUML based on the framework.
2. PROBLEM DOMAIN Much cooperation in development occurs during meetings, where designers discuss, argue, negotiate, and reach decisions via compromise and consensus. These meetings represent critical points in the project when knowledge is created, conflicts are identified and resolved. In particular, for software modeling, we identify four main activities, which can be achieved along one or several meetings (Figure 1).
Figure 1. Modeling activities.
IV - 11
IADIS International Conference Applied Computing 2004
2.1 Model Creation The early stages of modelling require brainstorming and idea exploration and analysis. During this activity, team members explore a wide range of solutions using informal drawings and sketches to create an initial model.
2.2 Model Transformation Once team members have explored a sufficient number of ideas, they detail a small number of promising ones and eventually refine them through several transformations. The model is usually a composition of formal artifacts, e.g. UML diagrams.
2.3 Conflict Identification and Resolution During modeling, participants raise several issues and propose options with different argumentations. These issues are resolved after the evaluation of the pro and cons with respect to criteria. Therefore, structuring issues and the different options and criteria enables team members to quickly identify the source of the conflict and focus on new options to address them. Hence techniques to capture and maintain rationale are used to support negotiation [3].
2.4 Consolidation At the end of a meeting or after the meeting, team members review their decisions, examine open issues and eventually close them. Finally, this activity ends up with restructuring and documenting the meeting for the following modelling session.
3. RESEARCH HYPOTHESIS Meetings are crucial part of teamwork. We focus our initial work in exploring the requirements and developing a meeting model. The requirements for a meeting model that supports distributed modelling of software should consider the following aspects: • Supporting the activity (e.g. UML modelling) • Enabling the communication within the group, • Ensuring awareness inside the group and their activities, • Dealing with the produced knowledge during the meeting, and finally • Managing the floor control. A formal presentation of a modelling meeting model: ::|||| ::{} Hence, a meeting model for distributed synchronous modelling of software have to consider the following issues: • Group awareness: People need to know who else present at the meeting to guide their work and need up-to-the-minute knowledge about other person's interactions with the shared workspace and with users to help them coordinate their work [4]. • Floor Control: In synchronous groupware it is the problem of how, when, and why participants interact in a shared computing environment while working simultaneously on common tasks. • Multi-User Interface: Adapting a single-user interface to multi-user interfaces transparently and provide some tailorability for purpose of supporting cooperative applications. • Communication: It is a social activity and takes different forms, formal and informal. • Sharing information: Facilitating the exchange of shared information among the group members is necessary for collaboration. • Knowledge Management: Is crucial for a long-term collaborative work among group members. Reusable knowledge (i.e., group history, Rationale etc.) can control the progress of meeting and avoid wasting of time.
IV - 12
To each of the above issues corresponds a component in the meeting model that encapsulates a related behaviour. Each component can coexist in different instances within different implementations. Components need to talk to each other to accomplish their task. For example, Floor Control component needs Awareness information to synchronize people’s floor.
4. RESEARCH GOAL The goal of this research is to develop a model for supporting distributed synchronous modelling meetings that meet the above listed issues. In particular there is a need to develop an integrated environment that brings together techniques and solutions from the CSCW (Computer Supported Cooperative Work) field to the issues of synchronous distributed UML modelling meeting activities. As a second goal, design an integrated framework that can be reused to other fields like distributed XP by specifying and implementing Activity component described later, and finally, we like to investigate the effectiveness and usability of distributed meetings of software modelling activity.
Figure 2. Simplified GroupUML architecture
5. RELATED WORK Most of the existing research on distributed collaboration concerns groupware support involving general features like video, audio, chat etc [5, 6]. The most relevant related work to our research field are the existing environments for concurrent engineering developed by using information sharing approaches, such as Flecse [9], CASCADE [10], CEDTS [11], OOWB [12] and CoConut [13]. However none of these systems have provided support to distributed ObjectOriented modeling of software but little support to organizing and coordinating activities. The novelty of our research is that we provide an integrated CSCW framework to support Object-Oriented Software Engineering with UML and the rationale behind.
6. PROPOSED SOLUTION With respect to the issues listed above, a basic model was elaborated as well as a prototype called GroupUML[2] that supports distributed modeling with UML. The main software components that we identify for distributed collaborative software modeling meetings are Floor Control, Awareness, Modeling (UML), Design Rationale (Knowledge management), User, and Communication (Chat, Phone. Etc.). We present a generic reactive architecture of a model built upon several design pattern and object-oriented design (Figure 2). The application model integrates several components on a higher abstraction level. The building blocks of the core model are composed of two chunks based upon two design patterns described as follows: o The meeting component as a whole: based on the Mediator pattern, described in the next section. o The distribution component as a whole: based on a Broker Pattern that enables Meeting components (each representing a participant in a location) to access the Model transparently.
IV - 13
IADIS International Conference Applied Computing 2004
o Using the Broker pattern, we ensure location transparency, components decoupling that interact remotely, and hiding protocols and implementations details as well. ¾ Model components Here we site just the most important components: Meeting: is the core engine of the model, built as a mediator class that defines an interface for communicating with the MeetingComponent. MeetingComponent: represents a generic component that makes up a meeting. It communicates with the Meeting object whenever an event of interest occurs. Design Rationale: Addresses an important issue such as linking rationale to the concrete and visible artifacts through embedding communication and history in the design process. This enables developers to collaboratively build a UML diagram and attach additional knowledge to the diagram.
6. EXPERIMENTAL APPROACH A prototype called GroupUML [2] (Figure3) has been built based on the above model specification (a shared UML editor accessible from a Smart board). The prototype was used in several internal meetings within the Applied Software Engineering department and during a semester course [9] where students volunteer to work on a modeling project using the prototype in which the students conduct a familiar activity (collaborative concurrent drawing UML models) in two collaborating groups located in different rooms. The students are initially provided with a simple infrastructure (GroupUML, Smart Boards). At the end of each session, the students propose new features and methods to address the distributed issues that they encounter. Selected new features are then introduced in the infrastructure for the next session. The issues encountered during the exercises are discussed both in the context of the exercise and the general context of the research papers.
Figure 3. GroupUML
7. STATUS The experience conducted within the university environment enabled to build an initial prototype that meets both the preliminary requirements fixed for a basic model and the requirements discovered during a real experience of distributed software modeling. Results are to be use as guidelines for developing a refined framework as a semi-complete application based on a set of classes, abstract classes and interfaces. It allows us to investigate the effectiveness and usability of distributed meetings of software modeling activity. Half of thesis time was consumed already (two years of four).
IV - 14
8. CONCLUSION AND FUTURE WORK We propose a meeting model for supporting distributed software modeling using UML as well as a framework to support activity-centered meetings. The contributions of this research are as follows: Initial meeting model architecture is presented. A tool for supporting synchronous software modeling in a same-time/different place environment. A CSCW framework for concurrent Object-Oriented software engineering. An empirical study of the impact of using such a meeting model and framework. As future work, we intend to thoroughly validate the model and the framework by building several instances, conducting experiences with different instances and testbeds in different environments with different components.
REFERENCES [1] R.E. Grinter, J.D. Herbsleb, & D.E. Perry. “The Geography of Coordination: Dealing with Distance in R&D Work”. ACM. 1999. [2] Boulila, Dutoit, Bruegge, D-Meeting: An Object-Oriented Framework for supporting distributing modeling of software, ICSE 2003 International Workshop on Global Software Development [3] A.H. Dutoit, B. Paech, “Rationale management in Software Engineering”, In S.K. Chang (ed.) Handbook of Software and Knowledge Engineering, World Scientific Publishing, 2002 [4] Dourish,P., Bellotti, V. Awareness and Coordination in Shared Work Spaces. CSCW92. [5]Groove Networks, http://www.groove.net [6] Streitz, N., Geißler, J. Haake, J., Hol, J. (1994). DOLPHIN: Integrated meeting support across LiveBoards, local and remote desktop environments. Proceedings of the ACM 1994 Conference on Computer--Supported Cooperative Work [7] Ludwin Fuchs, Steven E. Poltrock, Ingrid Wetzel: TeamSpace: An Environment for Team Articulation Work and Virtual Meetings. DEXA Workshop 2001 [8] A. MacLean, R.M. Young, V.M.E. Bellotti, and T.P. Moran. Questions, options, and criteria: elements of design space analysis. CHI’91. [9] P. Dewan, J. Riedl. (1993) “Toward Computer-Supported Concurrent Software Engineering”, IEEE Computer, Vol. 27, pp. 17-27, Jan. 1993. [10] C. Branki. (1995) “The Acts of Cooperative Design”, CERAs, 3(3):237-245. [11] G. A.Forgionne. (1994)“A Decision Technology System to Deliver Effective Concurrent Engineering”, CERAs, 2(2): 67[12]J.Dong.(1995)”Organization structures, Concurrent Engineering, and Computerized Enterprise Integration”, CERAs, 3(3):167-176. [13] U. Jasnoch, H. Kress, K. Schroeder, M. Ungerer, “CoConut: Computer Support for Concurrent Design Using STEP”, http://www.igd.fhg.de/www/igda2/ docs/pubs/pubs_1994/wetice_fullpaper.fm.htm
IV - 15
