Process moel patterns for collaborative work Jacques Lonchamp To cite this version: Jacques Lonchamp. Process moel patterns for collaborative work. 15th IFIP Worl Computer Congress - Telecooperation 98, ug 1998, Vienna, ustria, 12 p, 1998. <inria-00107838> HL I: inria-00107838 https://hal.inria.fr/inria-00107838 Submitte on 19 Oct 2006 HL is a multi-isciplinary open access archive for the eposit an issemination of scientific research uments, whether they are publishe or not. The uments may come from teaching an research institutions in France or abroa, or from public or private research centers. L archive ouverte pluriisciplinaire HL, est estinée au épôt et à la iffusion e uments scientifiques e niveau recherche, publiés ou non, émanant es établissements enseignement et e recherche français ou étrangers, es laboratoires publics ou privés.
PROCESS MODEL PTTERNS FOR COLLBORTIVE WORK Jacques Lonchamp 1 bstract s most real work is collaborative in nature, process moel evelopers have to moel collaborative situations. This paper efines generic collaborative patterns, ie, pragmatic an abstract builing blocks for moelling recurrent situations. The first part specifies the graphical notation for the solution escription. The secon part gives some typical patterns for the collaborative prouction of a single ument in isolation an for the synchronization of two epenent uments. The conclusion emphasizes some implications for process-centre systems. 1. Introuction Process-centre systems (PCSs), like process-sensitive software engineering environments [8] or workflow management systems [4], are base on the explicit efinition of the process they support. s most real work is collaborative in nature, ie, not one iniviually, but rather in groups, process moel evelopers have to moel collaborative situations. n obvious solution for reucing the process moelling effort is to provie process moel evelopers with generic collaboration patterns, efining basic builing-blocks for constructing their specific moels. This paper gives some preliminary results about this issue. The term pattern has the meaning given initially by C. lexaner for architectural patterns [1]: «each pattern escribes a problem which occurs over an over again in our environment, an then escribes the core of the solution to that problem, in such a way you can use this solution a million times over, without ever oing it the same way twice». In other terms, a pattern is an abstract solution to a problem in a context. s for OO esign patterns [9], the granularity is neither too small («not about esign that can be encoe in classes»), nor too large («not complex, omain specific esigns for an entire application or subsystem»). In aition, the term collaboration (or collaborative ) is use as the umbrella-term for all kins of collective work, mixing communication aspects, coorination aspects, an co-ecision aspects. The secon section escribes how the problem is tackle in some relate approaches, an contrasts them with the view taken in this paper. The thir section summarizes the notation use for escribing the pattern solution part. The fourth section illustrates the approach through a selection of typical patterns. Finally, the conclusion iscusses some implications for PCSs. 1 LORI-Université Nancy 2, BP 239, 54506 Vanoeuvre-lès-Nancy Ceex, France (e-mail: jloncham@loria.fr)
2. Relate approaches Many ifferent kins of builing blocks are escribe in relate approaches. We summarize here three of them. However, a majority of PCSs give only low level constructs an process moel evelopers have to buil their moels of collaborative situations from scratch. 2.1. Conversation-base workflow management systems In this first category, an activity always results from the request from one actor (the requester or customer) to another actor (the assignee or performer). For instance, in ction Workflow [13] a generic loop is the basic component of all process moels (see Figure 1). Figure 1. ction Workflow loop. loop can complete any quarant of another loop. Process moels are networks of relate loops. In Regatta [16], the assignee can choose among three ifferent ways of performing the activity: manually, by instantiating a plan template, or by creating a new plan from scratch. plan is a network of stages, each stage involving in turn a loop between a requester an an assignee. 2.2. Domain specific process moelling languages In this secon category, systems provie process moelling languages eicate to a specific class of collaborative applications. For instance, there exist several proposals of PCSs eicate to collaborative review/inspection applications [12, 17]. The process eveloper just specifies in the specific language his/her choices for customizing the whole collaborative application. 2.3. Transactional systems In this thir category, approaches emphasize consistency an integrity maintenance of share uments. Classically consistency an correctness are asserte by isolating concurrent activities (CID transactions). Exchanges are only possible at the start/en of activities. But exchange of intermeiate results is necessary for collaborating. vance transaction moels are require to favour cooperation while continuing to assert some correctness properties [5]. These moels provie preefine strategies, associate with privilege cooperation structures. 2.4. Discussion proposal satisfaction customer agreement performer performance In conversation-base approaches of section 2.1, the generic loop structure implies a very specific way for structuring an eploying the process moel, having an impact on both the prouction process an the meta process [2]. The plan template concept of Regatta is a specific solution for a given activity, an not a generic reusable builing block. The last remark also applies for the kin of reuse provie by omain specific approaches of section 2.2. In this case, the analogy is more with OO frameworks [9] than with OO esign patterns. Transactional systems are base on some
theoretical correctness criterion which is implemente into some preefine strategy. Unfortunately, there exist many ifferent notions of correction, an each extene transactional moel has a limite applicability an a high level of rigiity. In summary, an by contrast, collaboration patterns consiere in this paper specify pragmatic solutions to recurrent problems: they provie basic, generic, an abstract builing blocks for constructing prouction process moels. 3. The notation for the pattern solution part The solutions are expresse with a notation esigne for showing visually their most important aspects. It has some similarities with the PEL visual process moelling language [6]. The control part is similar to many workflow moelling notations [4, 18, 19], an its semantics is specifie through (free choice) Petri nets. The control part shows the task orering. The ata part shows how prouct artifacts flow between tasks or are share by them. 3.1. Tasks process moel is a network of tasks. Tasks are either atomic or can be refine into a network of sub-tasks. workspace is associate to each atomic task, where actors perform their work. workspace provies actors with the proucts an tools they nee, in a right form an a right location (computer). Workspaces can exchange prouct artifacts an can also share them, if there is some common repository. task (of any kin) is epicte by a rectangular box. tomic tasks have an letter in the top left-han corner, which istinguishes them from compoun tasks. single man icon in the bottom right-han corner epicts an iniviual task, while a group icon (with two men) epicts a collective task. compoun task is refine statically into a network of sub-tasks. compoun iniviual task is refine exclusively into iniviual sub-tasks. compoun collective task is refine into either iniviual or collective sub-tasks. question mark epicts an unefine task, ie, a task that must be refine on the fly, uring process execution. multiple task, with a ouble borerline, has at least one instance: its exact number of instances is only known at run time. Figure 2. Graphic representation of task types. name tomic iniviual tomic collective Compoun iniviual Compoun collective Unefine Multiple 3.2. Control flows name name name name name? Flows of control between tasks are epicte by soli arrows. In terms of Petri nets, a place is associate to each task, followe by as many transitions as there are successors (ie, estinations of outgoing arrows). Each control flow has a corresponing ege from a transition to a place. Figure 3. control flow B task control flow task B
black circle moels an ND noe, useful for escribing a parallel split of the flow of control, or a join between flows of control. transition, precee by as many places as there are preecessors (ie origins of incoming arrows), is associate to each ND noe. Figure 4. C1 C2 D task control ND control tasks flow noe flows, tasks control ND control task C1,C2 flows noe flow D If a task has several outgoing arrows, it moels an OR split. If a task has several incoming arrows it moels an OR join. Figure 5. C1 C2 D task control flows tasks, tasks control task D C1, C2 flows White triangles moel either begin or en noes. If a task is refine into a network of sub-tasks, its incoming (resp. outgoing) arrows become internal begin (resp. en) noes. Figure 6. begin noe en noe task gives network of sub-tasks 3.3. Data flows an ata sharing Prouct artifacts are moelle as small circles. They can flow between tasks or be share by them. a) synchronous ata flow (SDF) takes place when the sener task terminates an before the receiver task starts. It is a flow of final results between transactional workspaces [6]. The prouct is remove from the sener an transferre to the receiver. It is represente in conjunction with the corresponing control flow, always on the vertical sies of tasks, because by convention the time flows from the left to the right: the right sie correspons to the en of the task an the left sie correspons to its beginning. The aitional notation (r) specifies that is transferre in rea-only moe. Figure 7 shows ifferent examples of SDFs.
Figure 7. B 1 2 1,2 1(r) 2 C1 C2 1 2 1,2 D C1 C1 1 C1 C2 {} D (set of versions) C2 2 D C2 D b) n asynchronous ata flow (DF) takes place uring task execution. It is a flow of intermeiate results between cooperative workspaces [6]. It is represente by a otte arrow always connecte to the horizontal sies of the concurrent tasks (ie, between their beginning an their en). The prouct is either copie (simple arrow) or transferre (ouble arrow). When the prouct is copie, changes are performe separately by the tasks. There can exist many strategies for eciing when proucts are sent or fetche. Figure 8 shows ifferent examples of DFs. Figure 8. 1,2 1,2 1 2 1 2 (r) B is copie into B is transferre into 1 is copie into is copie into 1 is copie into an or or 2 is copie into an 2 is copie into (rea only) c) Prouct sharing is possible if there exists some common repository. In this case, proucts are not epicte close to tasks. rea only access is shown by a otte arrow from the prouct. rea/write access is epicte by a two sies otte arrow. Exclusive rea/write access is specifie by the x letters on the corresponing arrows. Figure 9. Rea only access Rea/write access Exclusive rea/write access x x Share prouct artifacts may be versionne. When necessary, it is possible to istinguish between purely linear versionning an versionning with alternative paths, respectively with an.
4. Some typical collaboration patterns We escribe in this section several patterns, which cover some of the most important collaborative situations, but certainly not all of them. These patterns result from pragmatic stuies of many processes. 4.1. The co-work pattern Problem Collaborative prouction of a single ument in isolation. Context Several actors work together within the same atomic task. There exist many ways to perform such co-work: interaction can either be synchronous or asynchronous; ument construction either results exclusively from collective ecisions or results from both iniviual an collective initiatives. t least is a collective ecision. Figure 10. co-work 4.2. The elegate work pattern Problem Collaborative prouction of a single ument in isolation. Context The group elegates the prouction work to a single actor an performs a collective review afterwars. efect list is prouce by the review. rework task follows, which will be efine, if necessary, after the review. The ecision to perform or not some rework is taken collectively at the en of the review. There are many ways for structuring the collective review task: for instance, with a single co-work pattern, or with patterns reflecting structure inspection methos (e.g. Fagan [7] or Humphrey [11] methos). We have no room for escribing all these specialize patterns here. Figure 11. elegate setup work 4.3. The multiprocessing pattern review rework? + efect list(r) Problem Collaborative prouction of a single ument in isolation. Context Several actors buil concurrently their own version of the same ument. They have no access to the s from the others. Then, these personal alternative versions are integrate. Such a pattern is often useful at the very beginning of a complex task, when ifferent expertise are require. There are many ways for structuring the collective integration task: integrating two lists of elements is ifferent from integrating two complex esign schemata. We have no room for escribing all these specialize patterns here.
setup Figure 12. 1 { i } integration rework? i, i=2..n 4.4. The ivision of labour pattern Problem Collaborative prouction of a single ument in isolation. Context Several actors perform in parallel an inepenently some partial work for builing the ument. Their work is mainly inepenent because it concerns ifferent subparts of the ument (name c i ). However, their work can sometimes interfere, in particular when a moification of the ument structuring (name struct ) is require. In this case, a collective ument restructuring task creates a new ecomposition that will be reworke. This task is also responsible for the collective ecision to terminate the parallel work. When has occurre, a collective review of the whole ument is performe for ensuring its global consistency. Figure 13. setup = struct + {c i, i=1..n } struct(r)+c 1 struct(r)+c i, i=2..n c 1 c i review + efect list(r) rework? struct ument restructuring + struct 4.5. The proucer/reviewer pattern Problem Collaborative prouction of a single ument in isolation. Context The two concurrent tasks (prouction an review) exchange proucts uring their execution. There exist many possible policies efining when an by whom proucts are sent or fetche. The only collective work is about the consensual. similar pattern is escribe in [10], with no collective task but a istribute protocol ensuring that the writer an the reviewer have rea the last version of the artifact prouce by the other actor. prouction Figure 14. setup efect list review
4.6. The istribute merge pattern Problem Collaborative prouction of a single ument in isolation. Context Two actors change the same prouct inepenently an synchronize it with the other. Different policies may apply for eciing when the ument is copie or fetche. Termination results from a collective ecision. This pattern becomes complex if more than two actors are involve. similar pattern with a istribute protocol is escribe in [10]. Figure 15. setup & merge & merge 4.7. The mutual exclusion pattern Problem Collaborative prouction of a single ument in isolation. Context The ument is share by several tasks. Prouct transfer into the workspaces is performe through check out/check in operations. The actors work in mutual exclusion because some locking mechanism prevents from concurrent work. Co-work only takes place for efining a consensual state. Figure 16. setup x x 4.8. The collective merge pattern Problem Collaborative prouction of a single ument in isolation. Context Several actors buil the same ument. Concurrent work is mae possible by managing alternative versions of the ument within the repository. n alternative version is create at check in if the checke out version in the repository has alreay one successor. Merge is performe collectively by the contributors, at will. This task is also responsible for efining a consensual state.
Figure 17. setup merge & 4.9. The check in an merge pattern Problem Collaborative prouction of a single ument in isolation. Context In this pattern, merge is performe iniviually by the contributors. Instea of creating an alternative version in the repository, the actor who has attempte a conflicting check in operation has the responsibility for merging the current version in the repository an his/her version in the workspace [14]. Co-work only takes place for efining a consensual state. If some notification mechanism exists the iniviual merge activity may start as soon as the check in operation concerning the checke out version has occurre. Figure 18. setup & merge & merge 4.10. The istribute synchronization pattern Problem Synchronization of two epenent uments. Context Two actors evelop their own ument an synchronize it with the other ument. They exchange their respective uments. Different policies may apply for eciing when the uments are copie or fetche. Termination is the only collective task. The two uments are input parameters of the pattern. 1 prouction & synch. Figure 19. 1+2 1 2 2 prouction & synch. 1+2
4.11. The master/slave pattern Problem Synchronization of two epenent uments. Context Only one actor (the slave) has to synchronize his (her) ument with the master s one. The ument can be sent at the master s initiative or fetche at the slave s initiative. similar pattern is escribe in [10]: the slave can terminate if an only if he/she has rea the last version. Figure 20. 1 1 prouction (master) 1+2 2 2 prouction & synch. (slave) 1+2 4.12. The collective synchronization pattern Problem Synchronization of two epenent uments. Context The uments are share an their synchronization is performe collectively, at will. Figure 21. prouction prouction 1 synchronization & 2 4.13. The iniviual synchronization pattern Problem Synchronization of two epenent uments. Context Synchronization is left to the inepenent initiative of each actor within his/her iniviual task. The collective task just ensures that is ecie collectively. prouction & synch. 1 2 prouction & synch.
4. Conclusion This paper briefly escribes some typical cooperation patterns. On this basis, several implications for PCSs may be emphasize: 1. PCS shoul manage iniviual an collective workspaces, either transactional or cooperative. Prouct artifacts either flow between them or are share by them, if there exists some (centralize or istribute) common repository. 2. In orer to provie an efficient support for collaborative work, it is necessary to stuy in epth an to support ifferent kins of collective conflict resolution tasks, such as review, merge, an synchronization. CSCW approaches [3] are well suite for supporting these tasks, an also for proviing irect communication through messages (such as notifications, requests, comments), in aition to inirect communication through prouct artifacts. 3. Incremental construction of process moels is very important, as exemplifie by the rework task in several patterns. Integrating an unspecifie rework task constitutes a more flexible solution than a schema with a backwar iteration: rework can be organize ifferently than the initial work an the ecision is taken ynamically, on the basis of the actual process performance. 4. There exists also a process escribing how the process moel is built an how it evolves ynamically, ie, a meta process. It is either an iniviual or a collective process, an PCSs shoul support it, through process moelling, as the prouction process is. Specific patterns for structuring the meta process moel shoul exist, as suggeste by the loop structure of conversation base workflow systems (see section 2.1). It woul be also very interesting to specify what a well-forme builing block is. From the control perspective, some results exist for characterizing well-forme networks of tasks (e.g. [15, 18]), base on the analysis of the corresponing Petri nets. From the collaboration point of view, a first iea coul be to istinguish three phases within well-forme collaborative patterns: a prouction phase, which must be a well-forme network of tasks, a collaborative evaluation an/or phase, which shoul always terminate the prouction phase, an, possibly, an unspecifie rework phase for the ynamic restructuring of the prouction process, when the evaluation is negative. ll the patterns escribe in this paper are well-forme from this point of view. References [1] LEXNDER, C., Pattern Language: Towns, Builings, Construction. Oxfor University Press, New York, 1977. [2] BNDINELLI, S., FUGGETT,., GHEZZI, C., Software Process Moel Evolution in the SPDE Environment, IEEE Transactions on Software Engineering, 19, 12, pp 1128-1144, 1993. [3] ELLIS, C., GIBBS, S., REIN, G., Groupware: Some Issues an Experiences, Communications of the CM, 34, 1, pp 38-58, 1991.
[4] ELLIS, C., NUTT, G., Moeling an Enactment of Workflow Systems, in: pplication an Theory of Petri Nets, Lecture Notes in Computer Science 691, Springer-Verlag, pp 1-16, 1993. [5] ELMGRMID,. (e.), Database Transaction Moels for vance pplications, Morgan Kaufmann Pub., 1992. [6] ESTUBLIER, J., DMI, S., MIOUR, M., High Level Process Moelling for SCM Systems, in: Proceeings of SCM Workshop, LNCS 1235, Springer-Verlag, pp 81-97, 1997. [7] FGN, M., Design an Coe Inspections to Reuce Errors in Program Developments, IBM System Journal, 15, 3, 1976. [8] FINKELSTEIN,., KRMER, J., NUSEIBEH, B. (e.), Software Process Moelling an Technology, Research Stuies Press, 1994. [9] GMM, E., HELM, R., JOHNSON, R., VILLISIDES, J., Design Patterns: Elements of Reusable Object Oriente Software, ison-wesley, 1994. [10] GODRT, C., CNLS, G., CHROY, F., MOLLI, P., SKF, H., Designing an Implementing COO: Design Process, rchitectural Style, Lessons Learne, in: Proceeings of Int. Conference on Software Engineering (ICSE 18), IEEE Press, 1996. [11] HUMPHREY, W., Managing the Software Process, ison-wesley, 1989. [12] MCDONLD, F., MILLER, J., utomatic Generic Support for Software Inspection, Technical Report RR-96-198, University of Strathclye, Glasgow, 1996. [13] MEDIN-MOR, R., WINOGRD, T., FLORES, R., FLORES, F. The ction Workflow pproach to Workflow Management Technology, in: Proceeings CM Conference on Computer-Supporte Cooperative Work (1992) pp 281-288. [14] MILLER, T., Configuration management with the NSE, in: Proceeings of Int. Workshop on Software Engineering Environments, LNCS 467, pp 99-106, Springer-Verlag, 1989. [15] STRUB, P., HURTDO, C., Unerstaning Behavior of Business Process Moels, in: Proceeings of the First International Conference on Coorination Moels an Languages, Cesena, pp 440-443, 1996. [16] SWENSON, K., MXWELL, R., MTSUMOTO, T., SGHRI, B., IRWIN, K. Business Process Environment Supporting Collaborative Planning, Collaborative Computing, 1 (1994) pp 15-34. [17] TJHJONO, D., Builing Software Review Systems using CSRS, Technical Report ICS-TR-95-06, University of Hawai, Honolulu, 1995. [18] VN DER LST, W., Verification of Workflow Nets, in: Proceeings of pplication an Theory of Petri Nets (ICTPN 97), LNCS 1248, Springer-Verlag, 1997. [19] Workflow Management Coalition Terminology an Glossary, Technical Report WFMC-TC-1011, 1996.