Cooperation Support in the SPADE Environment: A Case ... - CiteSeerX

Cooperation Support in the SPADE Environment: A Case Study Sergio Bandinelli, Marco Braga, Alfonso Fuggetta, Luigi Lavazza CEFRIEL { Politecnico di Milano

GOODSTEP ESPRIT-III project No. 6115 GOODSTEP Technical Report No. 016 June, 1993 Abstract

This paper describes the cooperation support facilities of SPADE, a process-centered development environment, i.e., an environment where software production activities are guided by the process speci cation. In SPADE, such speci cations are written in SLANG, a process modeling language based on high-level Petri nets. SLANG process descriptions can be executed by means of an interpreter that is interfaced with an integrated tool environment | namely DEC FUSE. The paper illustrates the features of SLANG that can be used in supporting coordination and communication by means of an example.

1 Introduction Software artifacts are the result of software production processes, which involve a number of steps and activities from the conception of an idea to the delivery of the system and its evolution. There is a wide consensus that the overall quality of these artifacts depends on the process through which they are produced [12]. The focus on software processes as a relevant research theme is quite recent, but has quickly drawn considerable interest both within academia and industry. In order to address the technical issues involved in specifying and supporting software processes, many process languages and environments have been proposed. The starting point is the recognition that there is no universally valid software process that can be analyzed, modeled, and automated once for all, and then replicated for any new project. Rather, the process |and its support environment| should be tailored to each speci c organization and/or project. The software process is the framework in which interacting agents cooperate to develop software applications, support their evolution, produce and maintain reusable components, etc. Dierent kinds of roles may be involved, and dierent people may be interacting in the process: managers, software engineers, end-users, etc. The software process is the common ground on which these individuals work cooperatively. Despite its importance, however, the process is normally left implicit and little or no attention is paid to making it clearly understood by all participants in the process. By providing an explicit representation, the process becomes more clearly understood, and this helps improve communication and cooperation among people. By using formal operational notations to model the process, it is also possible to derive an interpreter of the notation. The notation would then be executable, possibly at dierent levels of completeness. Parts of the process may thus be automated by \coding" them in the process de nition. Actually, the word \enaction" (instead of execution or interpretation) is used in the process modeling area to mean that the execution of the process is done not only by machines but by a symbiosis of human beings and computers. Our approach to process modeling views software processes as a set of related software engineering activities that are carried out in parallel by multiple cooperating agents. This view has been adopted in the SPADE environment [2, 3] for Software Process Analysis, Design, and Enactment. SPADE includes a process modeling language, called SLANG (SPADE Language), which is de ned on top of a high-level Petri net formalism, called ER nets [9]. In SPADE each activity is described by a high-level Petri net. 1

Activities may be dynamically instantiated during process enactment. A process model in SLANG may include the description of the interaction with tools and human beings. By explicitly modeling this interaction, it is then possible to guide and control cooperation during process enaction to ensure that it occurs in a way consistent with the process model. This paper presents a case study on how a cooperative process may be modeled using SLANG. Section 2 explains the basic features of SLANG. Section 3 describes SPADE architecture, that provides a communication infrastructure supporting cooperative work among individuals. Section 4 presents the case study and proposes a solution using SLANG. The dynamic behavior of the model is analyzed in Section 5. Finally, Section 6 draws some conclusions from the case study.

2 Modeling processes using Petri nets Much research eort is being carried out in the software process eld, yielding a number of dierent approaches to process representation and execution [1]. These approaches range from the use of full- edged programming languages [11] to abstract speci cation formalisms, including Statecharts [13], rule based languages [15, 4], attribute grammars [16], and Petri nets. Several research groups use Petri net based notations for modeling the process. FUNSOFT nets [10], for example, are based on PrT nets, a wellknown and widely studied class of high-level Petri nets, and have been mainly proposed for process veri cation and validation. Another example is PROCESS WEAVER[7], developed by Cap Gemini Innovation in the context of the Eureka Software Factory project [8]. It provides a set of tools to add process support to UNIX-based environments. In PROCESS WEAVER a process is described as a hierarchy of activity types. Then each activity is associated a procedure that tells how the the activity is carried out. Such procedure is expressed with transition nets, a data- ow notation similar to Petri nets. SLANG is based on a timed Petri net formalism (ER nets) and thus provides the means to specify time constraints in the process. SLANG has been specially designed to support process evolution by oering re ective mechanisms to model the process change from within the process itself. In addition, SLANG allows the process modeler to describe tool and user interaction, which is then supported by the SPADE architecture during process enaction. In the rest of this section we provide an overview of the main 2

SLANG features.

2.1 SLANG features

A SLANG process speci cation is composed of a set of hierarchically structured activities. An activity encapsulates a set of logically related process procedures and may include invocations to other (more simple) activities. Each activity is de ned by means of a high-level Petri net notation. Tokens in the net may be arbitrarily complex object structures and may model documents, tools, resources, data, programs, etc. Places are viewed as distributed persistent object repositories. Places are typed and every place may contain only tokens of its declared type. A SLANG type is similar to a class template with a list of attributes and functions. Transitions represent events that may or may not occur in a given state: a transition ring represents the occurrence of an event taking a negligible amount of time. The net topology describes precedence relations among events; it also describes parallelism and con ict situations. Each transition is associated with a guard and an action. The guard is a condition on the transition input places for the occurrence of an event. The action represents what should be done in response to the event. An activity de nition has an interface part and an implementation part. The activity interface includes a set of starting events and a set of ending events, that respectively represent the starting and ending events of the activity. The activity begins when one of its starting events occurs and nishes with the occurrence of one of its ending events. Interface places are classi ed in three sets. The set of input places, that are input for any of the starting events, the set of output places, that are output places from any of the ending events and the set of shared places, that may be shared by more than one activity and thus play the role of communication and synchronization variables during activity execution. SLANG provides a way to deal with time in process speci cations and supports ways to formally reason about the temporal evolution of a process. In SLANG, each token implicitly carries a timestamp representing the time at which it has been produced. A time constraint may be associated with each transition to de ne the time interval during which an enabled transition can re. SLANG also oers a timeout construct that allows the designer to set a maximum time that may elapse between the occurrence of two events.

3

2.2 An example

In order to illustrate SLANG, we consider an example inspired in the one proposed for the 6th. and 7th. International Software Process Workshops [6]. The example deals with the modi cation of a program unit. We assume that, due to changes in the global speci cation of a system, some units have to be modi ed. For each of these units, a change unit speci cation has been written. The unit design is changed in view of the new speci cation, and a new unit design together with a new unit interface is produced. Then, the unit is edited and changes are coded. Once coding nishes, the unit is compiled and tested. If no errors are encountered during compilation and testing, the modi ed unit is released, otherwise, compilation or test errors are used as feedback to x the unit. No feedback to the design is foreseen in this version of the example. Note also that this version does not consider either the fact that units are interdependent and, therefore, a change in one unit interface may have an impact on other units. In Section 4 we will extend this non-cooperative version of the example to a cooperative version that considers parallel modi cations of interdependent units. Figure 1 is a SLANG model for the unit change process described above. The process is modeled through the activity Unit change. The part inside the dashed box corresponds to the activity implementation, what remains outside is the activity interface. Unit change has a single starting event (Start change) and a single ending event (End change). The interface includes also the shared place Unit repository that contains all program units. Activity Unit Change invokes other activities: Design change, Unit coding, and Compile and test. A complete SLANG model (here omited) should include also the description of these subactivities and a textual part for each transition with the guards and action speci cations.

3 SPADE support for cooperation Large-scale software development involves the intensive use of a large variety of software tools: editors, compilers, debuggers, database systems, word processors, graphic editors, and so on. A process modeling language should therefore provide a way for integrating software tools and automate tool invocation. SPADE provides a communication infrastructure supporting cooperative work among the individuals involved in the process. During execution many process engines (PE) may concurrently enact the activity descrip4

Change specification Start change

Change specification

Design change

New design

Unit repository

New unit interface

Unit coding

Unit with errors

Coded unit

Compile and test

Tested unit

Change unit

End change New unit

Figure 1: SLANG implementation of the \coding" activity.

5

tions. In particular, it is possible to instantiate the same activity multiple times, generating dierent execution threads for the activity. Each of these activity instances is called active copy. Thus, dierent active copies are concurrently executed by dierent process engines. The process engines access to an object-oriented database (it behaves as database client). The database contains not only all process products (documents, code, speci cations, manuals, etc.), but also the process model (the de nition of all the activities that compose the process model). A SLANG process model may also describe the interaction with tools and users. This is done with a special kind of transitions, called black transitions and a special kind of places, called user interface places. A black transition represents the invocation of an external service, that may be the asynchronous execution of a tool or the invocation of a particular service oered by a tool. When, during enactment, a process engine encounters a black transition, it forks a concurrent process that executes the tool speci ed by the black transition. Black transitions may model the execution of a \black box tool", such as a C compiler, that does not require any interaction during tool execution. It is also possible to use black transitions as message senders. In this case, a black transition models the sending of a message to a tool previously integrated in a tool environment. In this way, it is possible to ask for a single service of a tool (e.g., require an editor to open a le) and provide a ne-grained description of the interaction with tools in the process model. User interface places are used to capture relevant events that may occur in the external environment. These events are generated by the users (such as a programmer, a designer, etc.) by using, for example, a tool in the environment. A relevant event may be, for example, a user request to open a le. Relevant events in the environment are captured and transformed into tokens stored in user interface places. Depending on how the process is modeled, a reaction may be provoked by the presence of the token. The reaction may be, for example, the editor authorization to open the required le. Therefore the semantics of the interaction among tools and human beings is contained in the process description. The environment can thus support the interactions and guarantee that cooperation occurs in a way consistent with the process description. Figure 2 shows a high-level view of the rst implementation of the SPADE architecture, called SPADE-1. This prototype is based on O2 [14] as object repository and DEC FUSE [5] as an integrated tool platform. In 6

DEC FUSE, each user interacts with a set of tools that may communicate via a message server (MSG Server). The SPADE Communication Interface is responsible for receiving the relevant events generated by tools and human beings and communicate them to the appropriate process engine. Conversely, it captures the messages produced by process engines and forwards each of them to the corresponding user/tool.

4 A case study on modeling cooperation with SLANG This section presents a cooperative version of the example discussed in Section 2.2, in order to illustrate how SLANG supports the speci cation and enaction of cooperating activities. We assume that each program unit is composed of an interface and an implementation. Changes in the implementation do not aect other units. Changes in the interface, instead, need to be agreed among the unit responsible and the responsibles of all units using it. Thus, once the new unit design has been completed, the new unit interface has to be proposed to all its users. They may decide to accept the new interface or they may reject it. If some of the unit users reject the proposed interface, the unit responsible makes a new proposal, which is in turn reconsidered by all unit users. This process is iterated until all user unit responsibles agree on the interface: then the unit coding may start. Note that the proposed problem is highly dynamic. On one hand, the concurrent unit change activities may be generated dynamically. This means that the number of units that have to be changed is not statically known, and thus a dynamically changing number of threads (of the modify unit activity) has to be executed concurrently. On the other hand, the uses relationships among units1 may also be changed during unit design. If the supplier unit interface is undergoing some changes, and thus its interface is not stable, the client unit responsible has to be immediately noti ed and made participant in the approval of change proposals to the supplier unit interface. The cooperative de nition of activity Change unit is depicted in Figure 3. In the cooperative model of Change unit, the new interface de nitions are not fed directly to the coding phase, as they were in the de nition given in Figure 1. Instead, they are the input places of an activity | We use the standard de nition for the uses relationship among program units, i.e., a unit A uses unit B , if A contains a call to a function de ned in B . A is called the client unit and B , the supplier. 1

7

tool1

tool2

tooln

tool1

tool2

FUSE MSG Server

tooln

FUSE MSG Server

USER_1

USER_n

SPADE Communication Interface

PEroot

PE1

O2Client

O2Client

PEn

O2Client

O2Server

OODB

Figure 2: SPADE architecture. 8

called Propose interface change | that represents the process of collecting the approvals of the interface users. The de nition of activity Propose interface change is described in Figure 4. Transition Propose interface change is the starting event of activity Propose interface change. This starting transition is enabled as soon as the modi ed unit interface is available in place New unit interface, and produces four outputs:  In place Interface state the state of the unit interface is set from stable to unstable.  Read depend and last check time is a copy of the token contained in Unit dependency read by the transition, together with the time at which the token was read.  Proposal approval document is a token containing the proposal description and the list and number of users that are expected to approve the proposal.  Interface change proposal is the proposal document that is submitted to the unit users. The arc connecting Propose interface change with Interface change proposal is marked with an asterisk: this means that the number of tokens that are produced is known only dynamically. In this case as many tokens as the number of unit users are produced. Interface change proposal is an input place for activity Evaluate new interface. An instance of such activity is created for each user of the changed interface: its task is to communicate the proposal to the unit users and collect the responses (either and acceptance or a reject, together with motivations). Answers from the users are accumulated in Response to proposal, until their number equals the number of users stored in the place Proposal approval document. In such a case there are two possibilities:  All of the answers are accept: the ending event Produce approved interface is enabled.  There is at least one reject and thus activity Remake proposal is enabled. Such activity is concerned with the revision of the new interface based on the comments of the users. It is performed by the responsible of the unit interface and produces the same outputs as the starting event. 9

Change specification Start change Change spec. doc.

Design change

Unit dependency New unit interface

New design Approved interface

Propose interface change

Interface state

Unit coding

Unit with errors

Unit repository

Coded unit

Compile and test

Tested unit Change unit End change New unit

Figure 3: The cooperative de nition of activity \Change unit"

10

Unit dependency

New unit interface

Interface state

Propose interface change

*

*

Interface change proposal

Proposal approval document Read depend. and last check time

Evaluate new interface

* * Remake proposal

Response to proposal

*

Make proposal for new user Unit dependency

Propose interface change Produce approved interface Interface state

Approved interface

Figure 4: The de nition of activity \Propose interface change"

11

Actually Produce approved interface and Remake proposal are enabled only if the list of users recorded in the Proposal approval document corresponds to the current list of users (deduced from Unit dependency). If the lists dier, a new unit started to use the interface, whose responsible did not receive the new interface proposal. In such a case we want to suspend the production of the approved interface until the new user also approves it: this is done by means of the transition Make proposal for new user. It compares the present list of users of the unit, taken from Unit dependency, with the list of users that was copied in place Read depend and last check time when the Propose interface change activity began. If there are new users, they are also sent the interface proposal, in place Interface change proposal, and the counter in the Proposal approval document is incremented. If there are no new users, the activity ends with an ending event Produce approved interface, that sets the interface state to stable in Interface state place and produces the interface in place Approved interface. Figure 5 represents the speci cation of Approve new interface activity. This activity speci es that when a new interface proposal is produced for an user, an instance of the editor is automatically opened on the workstation of that user, and two les are opened: the text of the proposal, and the answer form. The user reads the proposal and lls the acceptance form: when the form is saved the activity ends. Activity Approve new interface has been speci ed using the interface available in SPADE-1 to deal with DEC FUSE services. In particular, we use places User active tools and Editor file saved. Their detailed type description, together with the de nition of the other places belonging to the activity, follows2 : User active tools : UserId (this subtype contains information on the user, in particular: UserName, ProjectRole, WorkstationName) ToolName (name of the tool class) ToolState (name of the current state for this tool instance) ToolId (identi er of the tool instance) User : UserId EditorId : ToolId for simplicity we use the same name to denote a place name and the name of the type of the place 2

12

Interface change proposal

User active tools Start evaluate new interface

Editor file saved

User Doc. file name

Set buffer to answer

Start editor Editor id.

Editor id. Read form text

Open proposal file

Editor id.

Editor id.

Wait for answer and quit editor

Open answer file

Answer form

Editor id. User answer form

Evaluate new interface Interpret answer and produce response Response to proposal

Figure 5: The de nition of activity Approve

13

new interface

Editor le saved : MsgName (name of the DEC FUSE message received, here Editor le saved) MsgParameter (the name of the le that has been closed) Doc. le name : FileName (name of the le containing the proposed interface) User answer form : FileName (name of the le containing the user answer form) Answer form : UserId AnswerFileName (name of the le containing the user answer form) Accepted (a boolean that indicates if the answer is accept or reject) Activity Approve new interface performs the following sequence of operations:  The starting event Start evaluate new interface creates two tokens: one containing the name of the interface user, the second containing the name of the le where the proposal text is stored.  A black transition executes the command: send msg(StartTool, FuseEditor, ControlPanelId)



that starts an instance of the Fuse Editor, by sending the start message to the instance of Control Panel associated to the speci c user (this information is obtained searching the tokens in the User active tools). A second black transition executes the command:



that loads the proposed interface document in the editor. The third black transition executes the command:

send msg(EditorOpenFile, Doc.

file name, EditorId)

send msg(EditorOpenFile, User answer form, EditorId)



that de nes the name of the le that will contain the answer of the user and loads it in the editor. The next black transition executes the command: send msg(EditorBufferCommand, User answer form, EditorId) that sets User answer form as the current buer.

14



The next black transition executes the command:

send msg(EditorInsertFile, Answer form, EditorId)





that reads into the current buer the text of the Answer form. The next black transition waits for an EditorFileSaved message from the editor identi ed by EditorId on the le speci ed by User answer form (i.e. it waits that the user writes his/her response and saves it), than it issues the command send msg(ToolControlCommand, "STOP", EditorId), that sends a quit message to the editor. The ending event Interpret answer and produce response reads the Answer form le and creates the appropriate token in the output place.

5 Enactment of cooperative activities In the case study description we noted that the proposed problem is highly dynamic. In this section we explain how this dynamicity is managed during enactment of cooperative activities. One dimension of dynamicity is given by the number of change speci cation that are generated. Each new change speci cation for a unit generates a new thread of execution of activity Change unit. In other words, each time the starting event Start change occurs, a new active copy of Change unit is created and its enactment is carried out by a new process engine. These parallel active copies may communicate by shared places. In particular, they may access to Unit repository (see Figure 3) where the last version of each unit is stored, to Interface state that says for each unit, whether there is an ongoing change interface proposal, and to Unit dependency that provides the updated uses relationships among units. Let us suppose that a program is composed of ve units, called U 1, U 2, U 3, U 4, and U 5. Initially the dependencies among these units are: U 5 uses U 3 and U 4, and U 3 uses U 4. Let us also assume that, at a given time, there are three concurrent active changes for units U 1, U 4, and U 5. Therefore, at run-time, we have three active copies of activity Change unit, identi ed respectively with the names Ch1 , Ch4 , and Ch5 . After U 4 interface has been modi ed accordingly with the changes in the unit speci cation (activity Design change has nished), it has to be proposed to the users of the unit. This is done by a new active copy of activity Propose interface change. Since unit U 4 has two users, two tokens 15

are produced in place Interface change proposal. These two tokens enable the starting event of Evaluate new interface twice, generating two active copies of that activity: one for user U 3 and one for user U 5 (see Figure 4). Thus, active copy Ch4 dynamically create two active copies of activity Evaluate new interface, that we may call Ev4 3 and Ev4 5, respectively corresponding to the cient units U 3 and U 5. No communication is foreseen among two users of the same unit, and thus, Evaluate new interface has no shared places. In fact, the communication is done only with the proposal generator, by responding to the proposal in place Response to proposal. The previous scenario shows that active copies of an activity are dynamically generated, depending on run-time data. The dierent threads may communicate and synchronize by sharing places, de ned in the calling activity. A second dimension of dynamicity in the example shows up when the dependencies among units are changed while one unit interface change is being discussed. This case is treated by transition Make proposal for new user, that detects that a new uses relationship among units has been introduced and creates a new interface change proposal for the new unit user. ;

;

6 Conclusions In this paper we explained, through a case study, how cooperation in the software process may be handled in the SPADE environment. The environment provides the infrastructure that allows the process modeler to describe at a ne grained level the interaction among dierent users and tools. It is also possible to construct very dynamic descriptions, ignoring the number of cooperating agents that would be involved in a particular execution.

References [1] Pasquale Armenise, Sergio Bandinelli, Carlo Ghezzi, and Angelo Morzenti. Software Process Representation Languages: Survey and Assessment. In Proceedings of the 4th International Conference on Software Engineering and Knowledge Engineering, pages 455{462, Capri (Italy), June 1992. IEEE.

16

[2] Sergio Bandinelli and Alfonso Fuggetta. Computational Re ection in Software Process Modeling: the SLANG Approach. In Proceedings of the 15th. International Conference on Software Engineering, Baltimore, Maryland (USA), May 1993. [3] Sergio Bandinelli, Alfonso Fuggetta, and Sandro Grigolli. Process Modeling-in-the-large with SLANG. In Proceedings of the 2nd International Conference on the Software Process, Berlin (Germany), February 1993. [4] Naser S. Barghouti and Gail E. Kaiser. Scaling up rule-based software development environments. In Axel van Lamsweerde and Alfonso Fuggetta, editors, Proceedings of ESEC 91{Thrid European Software Engineering Conference, volume 550 of Lecture Notes on Computer Science, Milano (Italy), October 1991. Springer-Verlag. [5] Digital Equipment Coorporation. DEC-FUSE manual. 1992. [6] M. Kelner et al. Ispw6 software process example. In Proc. of the 1th. International Conference on the Software Process, Redondo Beach CA (USA), October 1991. [7] Christer Fernstrom. PROCESS WEAVER: Adding Process Support to UNIX. In Proceedings of the 2nd International Conference on the Software Process, Berlin (Germany), February 1993. [8] Christer Fernstrom, Kjell-Hacan Narfelt, and Lennart Ohlsson. Software Factory Principles, Architectures, and Experiments. IEEE Software, pages 36{44, March 1992. [9] Carlo Ghezzi, Dino Mandrioli, Sandro Morasca, and Mauro Pezze. A Uni ed High-level Petri Net Formalism for Time-critical Systems. IEEE Transactions on Software Engineering, February 1991. [10] Volker Gruhn. Validation and Veri cation of Software Process Models. PhD thesis, University of Dortmund, 1991. [11] Dennis Heimbigner, Stanley M. Sutton, and Leon Osterweil. Managing change in process-centered environments. In Proceedings of 4th ACM/SIGSOFT Symposium on Software Development Environments, December 1990. In ACM SIGPLAN Notices. 17

[12] Watts S. Humphrey. Managing the Software Process. SEI Series in Software Engineering. Addison-Wesley, 1989. [13] Mark Kellner. Software Process Modeling Support for Management Planning and Control. In Proceedings of the 1st. International Conference on the Software Process, Redondo Beach CA (USA), October 1991. [14] O2. The O2 User Manual. O2 Technology, 1992. [15] Burkhard Peuschel and Wilhelm Schafer. Concepts and Implementation of a Rule-based Process Engine. In Proceedings of the 14th International Conference on Software Engineering, pages 262{279, Melbourne (Australia), May 1992. ACM-IEEE. [16] Masato Suzuki, Atsushi Iwai, and Takuya Katayama. A Formal Model of Re-execution in Software Process. In Proceedings of the 2nd International Conference on the Software Process, Berlin (Germany), February 1993.

18