A decentralized architecture for software process modeling and enactment

Abstract

supports distributed process modeling and enactment for distributed software development projects. Serendipity-II is based on a decentralized architecture and uses Internet communication facilities. 53 IEEE INTERNET COMPUTINGSuch centralized architectures can seriously constrain system robustness, performance, security, and distribution. There has been some research to overcome some of these problems, for example, through distributed process-enactment engines and distributed task-automation agents. However, little work has been done to facilitate distributed work process modeling and more generalized software agents. SERENDIPITY-II ENVIRONMENTWe have developed a distributed architecture and environment that supports fully decentralized software process modeling, process enactment, and distributed work coordination, task automation, and tool integration. Serendipity-II emerged from an earlier central-server-based process support tool, Serendipity. 2 The newer architecture is decentralized, and runs over the Internet and modem and mobile computer networks, as well as over local area networks. It also supports a wider range of distributed collaborative process modeling and software agents than most other distributed process support systems.

Engineering plug‐in software components to support collaborative work

“…Such groupware functionality might include 20 When developing the systems illustrated in Figure 1, we have reused many software components, as reported elsewhere 19 . However, much of the collaborative work support these environments provide we originally built into the various framework abstractions and components we reused 17,19 . Thus while we used reusable components to built applications, our groupware support followed the "monolithic" application development approach, where developers had little control on what groupware support was included in specialised components, and this resulted in sometimes inappropriately reused and over-complex component functionality 19,18 .…”

“…The main advantage with using standard distributed systems programming APIs for groupware applications is flexibility. The main disadvantages include a lack of high-level, reusable abstractions and components for building such tools (making their construction very timeconsuming and difficult), and an inability for users (and often developers) to extend or reconfigure the groupware functionality of these applications 15,17 .…”

“…When using such applications, users require a wide range of "groupware" (collaborative work) facilities, to help them work effectively together 6,13,11,17 . While the travel itinerary planner is a very different application to the software development tools, users require very similar kinds of collaborative work support.…”

“…CASE tools, CAD tools, programming tools, workflow tools etc 19,17 . JViews incorporates component-based building blocks for constructing such systems from reusable parts.…”

“…We hope our experiences will be useful for others interested in developing their own component-based groupware applications. Figure 1 shows some component-based software engineering tools and distributed information systems we have developed 17,18 . View (a) shows a workflow tool process diagram, used to describe workflow for software developers (but can be used to describe office automation workflow etc).…”