A Uniform Model for Coordinating Software Development Activities

A Uniform Model for Coordinating Software Development Activities Kari Alho, Casper Lassenius and Reijo Sulonen Helsinki University of Technology {kta,cls,shs}@cs.hut.fi Abstract This paper presents a model for supporting and coordinating distributed software process enactment by both human and computerized agents. Enactment is supported by a general Process Support System (PSS), which implements the coordination model presented in this paper. The model includes abstractions of activities, artifacts, agents and their behavior and relationships. Automatic enactment, i.e., invoking tools and requesting operations from them, is supported by several techniques, e.g., tool invocation servers or callbacks to the client. Parameterized finite state machines are used to coordinate the activities and the agents performing the work. The prototype system, currently under development, will be evaluated in industrial pilot projects performed in cooperation with several Finnish software houses.

1. Introduction Software processes are extremely large and complex. They are partly enacted by humans, partly by automated software systems. The processes are modeled at many different levels of abstraction, from many different points of view. We strongly believe that no single process modeling formalism can ever cope with all these aspects in a uniform way, a belief supported by [1], [2]. In this work we have tried to extract the “greatest common denominator” of many process modeling formalisms and use it as a basis for joining more specific modeling techniques into the framework. Furthermore, we try to exploit the natural dualism between processes and the objects they use and create to make the process models more manageable. In our view, software processes only exist to create or modify software objects; the software objects with their status express a substantial part of the software process creating and manipulating them. On the system support side, the Software Engineering community is still lacking integrated support of processes “executed” in different computing domains across large organizations or between organizations. We feel that there is a need for a general-purpose Process Support System that can be utilized across computer systems and envi-

ronments. Our approach has some similarities with the ideas presented in [3], where it is proposed that the state of software processes should be stored separately from the applications that created that state.

2. Conceptual Framework The system is based on a conceptual framework, which tries to capture a minimal set of concepts that we believe are sufficient but necessary in order to model a process to the level that it is enactable, i.e., can be carried out. The framework consists of three principal entity classes and their relationships: • Artifacts: the things created, deleted, modified and used. • Activities: the things done. • Agents: the “doers”, that is, who (or what) perform the activities. Each entity class has predefined class-specific properties and relationships as well as methods for manipulating both the properties and the relationships. The framework also contains a general attribute model allowing the user to define his own entity-attributes. Additional relationships, whose semantics the PSS does not interpret can also be specified by the users. Queries can be made on all relationships, also on the user-defined ones. In addition, all entity classes have behavioral data described by Finite State Machines (FSMs). At the top level, the framework is similar to the one presented by Armitage and Kellner in [1].

2.1 Artifacts The objects that the process creates, deletes or manipulates are called artifacts. An artifact has a number of visible properties, as well as methods for different purposes: getting and setting the properties and the actual data of the artifacts, adding and deleting components, managing new versions, and deleting the artifacts. The FSMs attached to the artifact typically model its life-cycle behavior, and is used for coordination purposes. For example, a pre-condition for starting an activity may refer to the current state of the artifact.

Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE

2.2 Activities An activity is a representation of a unit of work. Activities have attributes and methods, just like artifacts, as well as relationships with artifacts, agents and other activities. Activities are executed by one or several agents. When creating an activity, the creator specifies what kind of agents are needed for carrying out the activity by declaring what roles are needed. Roles specify agent capabilities. When specifying a needed role, the creator of the activity also has to specify the authority of the role with respect to the activity. The system has three predefined agent authorities: executor, controller and observer. The executing agents perform the activity, the controlling agents supervise it, and the observers can only view the activity but not actively participate in it. These concepts are useful for supporting delegation of the activities. The idea of delegation relies on the concepts of executing and controlling agents, and on the hierarchical relationships between activities. The hierarchy is dynamic, meaning that an agent executing an activity has the possibility to create sub-activities and delegate some part (or the whole) of its own work to other activities, even during process enactment. The agent creating the new subactivity automatically becomes the controlling agent of that activity. It is also possible to disallow the creation of sub-activities.

The state of an activity may be modeled using several state machines arranged in sub-states and orthogonal components [4], [5]. The PSS defines a common life-cycle model that is the same for all activities. The preconditions and post-operations in this LCM are systemdefined, as they provide the “hooks” needed for automated enactment. In addition to the system defined LCM, the user can attach any number of his own FSMs to the activity to extend its behavior. The system does not, however, automatically change the states in the user-defined FSMs.

3. Current Status and Future Work We are currently building a prototype of the general Process Support System outlined in this paper, utilizing a commercially available ORB and an object-oriented database system. At the moment, most of the functionality of the PSS, including automated enactment, is implemented. We are working on translators that can be used to import process models into the PSS. A specialized PSS client to be used for enacting processes under Windows NT/95, is under development. Another client for PSS administration is being developed using Java. The PSS prototype will be validated with some example applications representing different problem domains. More information of the PSS project is available at “http://mordor.cs.hut.fi/sw-workmate/”.

2.3 Agents

References

Agents represent the “doers”, i.e., the entities that execute or control the activities. Agents can be either automated or human. Each agent has a set of capabilities, i.e., a list of roles in which it can perform. This is useful for finding agents that can perform a certain activity, for example, all testers.

[1] Armitage, J., Kellner, M. I.: “A Conceptual Schema for Process Definitions and Models”. In Proceedings of the 3rd International Conference on the Software Process, ICSP-3, pp. 153-165, Reston, VA, October 1994. [2] Kellner, Marc I. Multiple-Paradigm Approaches for Software Process Modeling. In Proceedings of the 7th International Software Process Workshop. Yountville, California, USA, October 15-18, 1991. Los Alamitos, California, USA: IEEE Computer Society Press, 1991. pp. 82-85. ISBN 08186-4050-2. [3] Heimbigner, D.: “The ProcessWall: A Process State Server Approach to Process Programming”. In 5th ACM SIGSOFT Symposium on Software Development Environments, pp. 159-168, December 1992. [4] Harel, D.: “On Visual Formalisms”. Communications of the ACM, 31(5), pp. 514-530, May 1988. [5] Coleman, D., Hayes, F., and Bear, S.: “Introducing Objectcharts or How to Use Statecharts in Object-Oriented Design”. IEEE Transactions on Software Engineering, 18(1), pp. 9-18, January 1992.

2.4 Behavior The behavior of the entities is described by FSMs. The PSS contains functionality for creating state machines and associating them with activities, agents and artifacts. The FSMs consist of states and state transitions. We associate an event, a pre-condition and an operation with each state transition. The specified event triggers the transition; the pre-condition has to be true in order for the transition to take place, and the operation is performed after the state transition. The pre-conditions are stated using a simple predicate language. The conditions can reference all entities, their attributes and relationships. Operations are used to inform other entities of the state transition and for automatic enactment.

Proceedings of The Thirtieth Annual Hawwaii International Conference on System Sciences ISBN 0-8186-7862-3/97 $17.00 © 1997 IEEE

1060-3425/97 $10.00 (c) 1997 IEEE