Modelling business processes with TALMOD
Cees de Snoo
Faculty of Management and Organization, University of Groningen P.O. Box 800, 9700 AV Groningen, The Netherlands
c.de.snoo@rug.nl
Abstract
Due to the complex and dynamic nature of organizations, carefully developed models are necessary for business analysis and for the design of correct business support tools.
Currently, both information system oriented and business process oriented modelling languages are available to easy the modelling project. Unfortunately, only a few attempts to merge both schools exist, like the business extensions of UML and YAWL. However, these languages do not sufficiently take into account the importance of agents, roles and interactions. Interactions are temporarily ordered sets of activities perceived and performed by agents in a process. Agents are actors that play one or more roles, and will often have a lack of process knowledge and conflicting process views.
In this article, we give a brief overview of recent trends in business process modelling as well as information system development. We introduce the research at The Agent Laboratory and present a new agent oriented modelling language, TALMOD, which is able to support business analysis, redesign and simulation as well as the development of agent-based software systems. TALMOD is an extension to and a ‘union’ of two existing modelling languages: UML and Petri nets.
Key words: Modelling, business analysis, agent-theory, UML, Petri nets, TALMOD
1. Introduction
Loosely coupled business processes within and between organizations, flexibility, mass
customization, outsourcing, and overall IT-support are some of the main characteristics of
today’s enterprises. Supply chain management is the relatively new term that is used to describe
models and methods to manage such current business dynamics, especially focusing on the
interactions between different departments and enterprises (Stadler, 2002). As a consequence of
these features, humans in organizations increasingly rely on software systems for everyday
activities. However, modern software systems exhibit characteristics that make them very
different from the software systems to which we are accustomed (Zambonelli, 2003). Today’s
software systems become more and more pro-active, pushing the activities in the organization’s
business processes. The shift from workflow management systems to business process
management systems (Van der Aalst, 2004a) and the rapid advance of agent oriented software
systems (Odell, 2005a; Giorgini, 2004) can be seen as the most obvious examples of this tendency. In addition, the increasing informational visibility, for instance brought by ERP systems, is changing organizational control and the way people collaborate in and between organizations. Ultimately, these trends change the behaviour of people, and also the structure and dynamics of organizations. Unfortunately, these aspects are not yet properly investigated (Szirbik, 2005).
The Agent Laboratory at the University of Groningen researches these issues from a multi- disciplinary point of view. One of the first projects contains the development of an agent oriented modelling language, based on existing languages like UML and Petri nets, that is able to support business analysis, redesign and simulation as well as the development of agent-based software systems. Our background motives and ideas, as well as our modelling approach and the modelling language TALMOD itself are extensively described in this paper.
We first shortly present some reasons and methods for business or enterprise modelling (section 2). Recent trends in business modelling and information system development are discussed in section 3 respectively section 4. These sections encompass also a brief description of UML and Petri nets. We use these languages to develop a ‘joined’ extension to them, called The Agent Lab modelling language (TALMOD). The need of a merge between business process and information systems modelling is explained in section 5. Some other attempts to realize this via extended and new modelling languages are presented together with a brief overview of some main shortcomings of these tries in section 6.
TALMOD is introduced in section 7 and is described in detail in the sections 8 to 10. Each of the four kinds of diagrams to model complex, distributed business processes is explained: the agent- role diagram, role-interaction diagram, static structure diagram and the process or ‘local behaviour description’ diagrams. Finally, an overview about the strengths and weaknesses of the current version of TALMOD is given in section 11. We end with a conclusion.
2. Enterprise modelling
Due to the complex and dynamic nature of organizations, carefully developed models are necessary for the understanding and analysis of their behaviour and for the design of new support tools (Giaglis, 2001). A model is an abstract representation of reality that excludes much of the world’s infinite detail. The purpose of a model is to reduce the complexity of understanding a phenomenon by eliminating the detail that does not influence its relevant behaviour. Selecting bounds for the phenomena to be modelled depends on the uses to which the model will be put (Curtis, 1992). Therefore, a model highlights certain aspects of the phenomenon being described, and it disguises other aspects (Kusters, 2005). Models enable to filter out the irrelevant complexities of the real world, so that efforts can be directed toward the most important parts of the system under study (Vernadat, 1996).
Shortly, a model reveals what its designer believes is important in understanding and treating the phenomena modelled (Curtis, 1992). This finality, i.e. the goal of the modeller, has a direct influence on the modelling method definition (Vernadat, 1996).
Modelling has always been at the core of both business process analysis and information systems
development (Giaglis, 2001). Management and computer science researchers are interested in
improving the understanding of organizations and their processes, facilitating process analysis
and design and supporting process management. The topic is also of great practical importance to industry as an aid to design organizational structures, processes and IT infrastructure that achieve business goals in an efficient and flexible way (Koubarakis, 2002). Furthermore, models can be used as a communicative tool for human actors playing different roles in the business processes (Kusters, 2005; White, 2004; Dietz, 2003; Eriksson, 2000). The design of a model can be also instructive in itself: a by-product of the modelling exercise is that it often quickly reveals anomalies, inconsistencies, inefficiencies and opportunities for improvement (Koubarakis, 2002).
The field of modelling businesses and organizations is also called enterprise modelling (Kusters, 2005; Eriksson, 2000; Marshall, 2000; Vernadat, 1996). The objective of enterprise modelling is not to fully describe all aspects of an enterprise. This would be useless, nearly impossible, and certainly endless. Moreover, during the enterprise modelling exercise, one has to keep in mind the inherent complexity and dynamic nature of the enterprise, and make sure that once the model has been obtained, it is still a valid representation of the current reality because things modelled first might have changed in the meantime (Vernadat, 1996).
Some of the main motivations for enterprise modelling are:
•
managing system complexity,
•
enhance the understanding of the way in which a business is organized,
•
enabling regular management activities, i.e. monitoring, control and planning, but also change management,
•
capitalization of enterprise knowledge and know-how, and last but not least
•
design, implementation, use and continuous improvement of information systems (Kusters, 2005; Vernadat, 1996).
Vernadat (1996) defines an enterprise model as “a consistent set of special purpose and complementary models describing various facets of an enterprise to satisfy some purpose of some business users.” This definition emphasizes several points:
•
an enterprise model serves a goal for a business user,
•
an enterprise model may be composed of sub models,
•
the sub models have special purposes, and
•
the set of models should be consistent (Kusters, 2005).
We should keep these criteria in mind when we define our modelling language TALMOD (sections 7 to 10) and come back to these points in section 11.
A wide range of model types exists that can be used to describe aspects of an enterprise. We can for instance mention descriptive, formal, programming and analytical models, each having their own purposes and own requirements regarding to the preciseness of their syntax and semantics.
Furthermore, modellers differ on how they intend their models to be. Take for example business processes into consideration. Prescriptive modelling implies the process should be performed in a particular way. Descriptive modelling attempts to determine the actual processes used to get work done in an organization. A third perspective is offered by proscriptive models, which delineate behaviour that is not allowed (Curtis, 1992).
TALMOD can be characterized as a modelling language that enables the development of
descriptive, analytical models. The initial focus is on the representation of the current business
situation. After analysis, redesign can be done by creating more formal and prescriptive models.
Vernadat (1996) provides us with a graphical representation of the basic steps in the enterprise modelling process (fig. 1). The feedback loop to business process engineering via continuous improvement is emphasized, suggesting that, as we already noted, the enterprise modelling process is a never-ending process. Several steps will be discussed in coming sections.
Figure 1. Basics steps of the enterprise modelling process (Vernadat, 1996: 86).
Finally, Kusters and Wortmann (2005) make some useful remarks about conflicting goals regarding enterprise modelling. As we already stated, the requirements for enterprise models depend on the purpose of the model. However, consider properties such as simplicity and completeness. Most people would agree that models should be as simple as possible. Similarly, many people would agree that a good model should be complete, i.e. cover as many as possible aspects and situations of reality. Unfortunately, if a model becomes richer and more complete, it usually becomes less simple and transparent.
More important is the criticism that enterprise models are often too detailed for the intended purpose. Engineers tend to think that more details can always be added, which, however, is often leading to information overload for business analysts. Business analysts the other way around tend to think that alternatives and exceptions can be neglected in the models, although in information systems design the thing that matters most is exactly that of handling exceptions (Kusters, 2005). We come back to these issues in section 11 where we also discuss the interrelated term coherence, as defined by Szirbik and Wagner (2001).
3. Business process and workflow modelling
Enterprise modelling is driven by business process modelling (Vernadat, 1996). Business
processes represent the flow of control of things happening in the enterprise. They show up in
management policies, operating and administrative procedures, manufacturing processes, flows
of documents, and the like. The modelling of business processes often starts with capturing high-
level activities and then drilling down to lower levels of detail within separate diagrams (White,
2004).
Business process modelling is studied now more than a decade ago, and a variety of products are available to support this, based on different process languages (Weske, 2004). It is stated that the absence of a universal organizational ‘theory’ and accompanying standard business process modelling concepts explains and even justifies the major differences in business process modelling languages (Van der Aalst, 2005). Lim et al. (1997) distinguish five orientations or approaches to which the modelling of business processes can be designated:
1. Activity oriented approach – representing the main activities and the relationships between activities and entities as well as resources that are required to perform these activities.
2. Agent oriented approach – especially useful when the interactions between human actors and human-machine actors are to be modelled.
3. Resource oriented approach – representing the logistic behaviour of individual work centres.
4. Goal oriented approach – based on the idea that each business process needs to attain a certain business goal.
5. Organization oriented approach – defining the enterprise structure roughly from a management point of view.
Most modelling languages are a product of a combination of these approaches. However, an explicit and so-called interaction oriented approach does not exist, although the agent oriented approach approximates it the best. In our research, we use an interaction oriented approach with an emphasis on agents and roles. We want to figure out if an interaction can be viewed as a stand- alone, independent object abstracted and separated from the agents and roles involved in this interaction. Such an object should be suitable for analysis, reuse and probably automation.
Section 3.1 contains some more arguments for an interaction oriented approach.
Our modelling language is strongly based on existing theory about business process and workflow modelling. Therefore, in this section we successively discuss process modelling, workflow modelling as a specialization of process modelling, and business process management as an extension of workflow management. Next, we shortly introduce the Petri net modelling language. This section is ended with a short discussion about current needs and shortcomings in business process modelling. As a kind of solution, we briefly introduce the agent oriented business process modelling approach.
3.1. Process modelling
Process modelling languages and representations usually should present one or more different perspectives. Lim et al. (1997) mention the next perspectives (they call them ‘conditions’ that business process models should meet):
•
Functional – ‘what’ has to be done.
•
Behavioural – ‘when’ something has to be done.
•
Informational – what are the ‘informational entities used/produced’.
•
Organizational – ‘who’ (which agents) has to do something.
•
Operational – ‘how’ is something achieved.
•
Interaction – how are members ‘informed about work’ (Lim, 1997; Kusters, 2005; Curtis,
1992).
Compared with the five business process modelling approaches mentioned earlier in this section, we see some overlapping. For instance, a modelling language having an agent oriented approach will pay most attention to the organizational perspective.
The sixth perspective is called ‘interaction’, suggesting that a process modelling language should take communication, interaction and negotiation aspects between actors, either human or artificial, into account. We agree with that and propose an even stronger emphasis on this condition. It has not only to do with ‘information about work’ but more fundamentally with communication, negotiation, collaboration, cooperation and coordination. Although many business processes are automated and supported by artificial systems, humans are still important and indispensable.
Because of the specialized skills of human actors, they are more and more dependent on each other. Well-functioning interaction processes therefore are of great importance for a business. It is this conviction that brings us to argue for an interaction and agent oriented approach to business process modelling (see also De Snoo, 2005).
Anyhow, in short, a good process model should allow representation of “what is going to be done, who is going to do it, when and where it will be done, how and why it will be done, and who is dependent on its being done” (Curtis, 1992).
Although there is not widespread consensus on the constructs that collectively form the essential basis of a process model, the following list includes the most frequently mentioned (based on:
Kusters, 2005; Dietz, 2003; Eriksson, 2000; Lim, 1997; Curtis, 1992).
•
Agent – an actor (human or machine) who executes activities.
•
Role – a coherent set of process elements to be assigned to an agent as a unit of functional responsibility.
•
Activity – the primary building blocks of a process, being an embodiment of work to be done.
•
Flow – a link between activities mutually and between an activity and an ‘external’
process.
•
Artefact – a product created or modified by the enactment of a process element.
•
Resource – a source used in the process (physical, abstract or informational).
•
Goal – a purpose of the process, or the outcome the process is trying to achieve.
•
Rule – a statement that define or constrain some aspect of the process.
It is interesting to note that Curtis already in 1992 elaborates about the important issue of agents and roles.
“A single agent can perform multiple roles (e.g., designer, reviewer, coder), and a single role may be performed by multiple agents. A process can now be further elaborated as one or more agents acting in defined roles to enact the process steps (i.e. activities). Typically, process steps either manipulate an artefact or coordinate dependencies with other agents involved in the same or a related process. Consequently, process steps should be planned as part of a defined process, assigned to a role, allocated resources, and monitored” (Curtis, 1992).
We adopted this view on process modelling as a basis for our modelling language, but we call the
process steps ‘activities’.
3.2. Workflow modelling and Business Process Management
Business processes that are executed regularly, that have few foreseeable exceptions and that can be easily represented and implemented as a fixed order of activities can be modelled as a workflow (Van der Aalst, 2005; Georgakopoulos, 1995). The Workflow Management Coalition (WfMC) defines a workflow as: ‘the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules’ (WfMC, 1999). In this definition, it is emphasized that the artefacts are passed from and to participants, thus multiple agents. However, a workflow description can also be used to represent a sequence of activities executed by a single agent.
In the last decades, workflow management systems have become a popular tool to support and automate some business processes (Fischer, 2005; Liu, 2003). A workflow management system is a generic software tool that allows for the definition, execution, registration, and control of business processes or workflows (Van der Aalst, 2004c). At the moment, many vendors are offering a workflow management system. This shows that the software industry recognizes the potential of workflow management tools (Verbeek, 2004).
We need to describe some characteristics of workflows and workflow modelling, because our research follows some guidelines from this field.
The fundamental property of a workflow process is that it is case-based (Verbeek, 2004). This means that every piece of work is executed for a specific case, also called a workflow instance.
Examples of cases are an insurance claim, a tax declaration, a customer complaint, an order, and the design of a production plan (Van der Aalst, 2004c).
A typical example of a process that is not case-based, and hence not a workflow process, is a production process such as the assembly of bicycles. The task of putting a tire on a wheel is (generally) independent of the specific bicycle for which the wheel will be used. Note that the production of bicycles to order can be considered as a workflow process (Verbeek, 2004).
Today’s workflow processes become more and more complex, especially because they often span more than one organization (inter-organizational workflow processes). If the part of the workflow process in one organization fails, then it might have a serious effects on the other organizations involved (Verbeek, 2004).
This risk of current workflow management systems calls for a shift in the approach to business processes. This shift has been recognized in the advance of business process management tools.
Business Process Management (BPM) includes methods, techniques, and tools to support the design, enactment, management, and analysis of operational business processes (BPMI, 2005).
BPM can be considered as an extension of classical workflow management systems and approaches. Many people consider business process management to be the ‘next step’ after the workflow wave of the 1990s (Van der Aalst, 2004a).
In comparison to workflow management, business process management also focuses on diagnosis,
flexibility, goal driven process design, and human-centric processes (Weske, 2004). However,
also BPM tools cannot deal with non-predefined business processes, unpredictable interactions
and completely independent and autonomous participants (agents) having each their own, local
view on the process. Therefore, our research at TAL does not have in mind to reinvent a new
workflow management system. On the contrary, the ‘stringent’ process view developed in the
workflow research community should be extended to a more flexible, agent oriented direction.
To explain the advantages of modelling processes like workflows, we will describe a modelling language that is perfectly suitable for modelling workflows: the almost half a century old Petri net notation. According to Salimifard and Wright (2001) several modelling techniques can be applied to workflow modelling, but Petri nets are the only formal technique suitable to be used for both structural modelling and a wide range of qualitative and quantitative analysis.
3.3. Petri nets
Petri nets are graphical and mathematical modelling tools developed to represent and analyze the behaviour of concurrent and parallel processes and systems. Petri nets were first proposed in Carl Adam Petri’s doctoral dissertation in 1962 for the analysis of concurrent computer systems, and have been applied since then to a wide range of problems (Liu 2002, Salimifard, 2001).
Petri nets are based on a very simple, abstract representation of a process in terms of a bipartite directed graph made of two types of nodes, respectively called places (represented by a circle) and transitions (represented by vertical bars) and connected by directed arcs. The progress of the process, i.e. the behaviour of the system, is modelled by tokens (i.e. marks) flowing from place to place via the firing of transitions. When a transition is fired, it consumes tokens in its input places and produces tokens in its output places. Each transition is connected with at least one input place and one output place. The state of the process is defined by the marking of places, i.e. the number of tokens in each place (Van der Aalst, 2004c; Vernadat, 1996).
The popularity of Petri nets for the analysis and design of complex dynamic processes and systems can be explained by its advantages: the ability to model systems graphically, the clear representation of conflicts, parallelism and synchronization, and the ability to model qualitative as well as quantitative properties (Vernadat, 1996). The graphical nature of Petri nets makes them self-documenting and a powerful design tool, which facilitates visual communication between several people. On the other hand, Petri nets are based on a strong mathematical formalism, which makes it possible to set up mathematical models describing the behaviour of the system.
Moreover, validation of a Petri net model can be carried out using Petri net analysis techniques (Salimifard, 2001).
Coloured Petri nets (CPNs) are one of the most well-known classes of high-level Petri nets developed to overcome some problems to use basic Petri nets for enterprise modelling (Liu, 2002;
Giaglis, 2001). CPNs can be used to model business processes of an enterprise: tokens represent objects (data and/or materials), each one being characterized by its data type (i.e. its colour), and transitions represent processes or activities. The algorithm of an activity can be modelled as a procedure attached to the transition. A logical predicate can be specified on some transitions for the modelling of conditions constraining the execution of an activity (Vernadat, 1996).
While modelling with Petri nets is common, the idea of programming with Petri nets has not been widely accepted yet. However, especially when it comes to concurrent and distributed processes, e.g. multi-agent systems, the advantages of Petri nets are obvious (Cabac, 2005).
Cabac et al. (2005) uses Petri nets to model interaction protocols between different agents. We propose to use elements of the Petri net notation (symbols and partly semantics) to easy the modelling of processes. Particularly the simple ‘agreement’ of alternation between transition (i.e.
activity in UML) and place (i.e. ‘wait state’ in UML) will be important. This main feature has
been neglected in YAWL (Van der Aalst, 2005), one of the newest workflow modelling languages (see also section 6.4).
3.4. Discussion: an agent oriented alternative
Workflow modelling as well as BPM lack some important notions regarding the modelling of the behaviour of processes. Less attention is paid to the agent or actor perspective. A clear representation of agents and roles involved in the process is missing. In addition, the discussed business process modelling approaches assumes (nearly) full acquaintance with the processes, i.e.
a full understanding of the activities, the sequence of them, the division of tasks over actors and/or roles, the interaction protocols, etc. However, processes are fundamentally not knowable in detail, beforehand as well as during the process execution. Furthermore, people have several and often mutually exclusive views on the same process. There are also hidden agendas, hidden goals, and hidden activities, conscious as well as unconscious. By the way, many similar activities performed by human actors will be nonetheless executed in different ways. A planner creating a production schedule can start with the assignment of employees while a colleague creating the same plan can prefer to start with the division of orders to the machines. It is questionable if it really makes sense to model all such kinds of little differences and alternatives during the process modelling exercise.
In conclusion, if business process modelling only enables the modelling of standard, beforehand and for everyone knowable, and ‘automatable’ activities, its impact and usability will be very limited. Therefore, the modelling language and also the accompanying process simulation and support software should contain elements to model these important aspects.
A good alternative to deal with current business process modelling requirements can be found in the multiagent theory that is founded in the science discipline of artificial intelligence.
The agent approach enables the modelling and support of a slightly known process, conflicting process views and complex actor interactions. All participating active entities are agents. The interaction patterns between the various agents in the system do not have to be described completely or beforehand. In an agent based system, each agent has a given behaviour and the overall agent community will achieve its goals via the concerted actions of the agents (Szirbik, 2001; Szirbik, 2005). Because of the many advantages of this agent approach, we developed a modelling language based on existing workflow modelling languages that takes the just mentioned issues into account. Our agent based modelling language, however, is also based on the object-oriented modelling approach, which will be discussed now.
4. Information systems modelling and UML
Many differences can be pointed between the characteristics of the first computer applications
and present-day applications, even refrained from the differences with respect to software design
development, improvement, and impact (Zambonelli, 2003; Iivari, 2000; Iivari, 1998). Since the
1980s, the object-orientation concept has been evolved from both a programming language and
an analysis (modelling) perspective. Compared to the more traditional, function-oriented software
engineering approaches a number of advantages of the object-oriented approach are stated. First,
this approach is claimed to be more natural: it fits the way we view the world around us.
Secondly, the focus on structuring the problem rather than solving it with any particular solution and the smoother transition from requirements analysis to design to code are mentioned. Other advantages would be the more flexible systems that are easier to adapt and change, and the promotion of reusability (Van Vliet, 2000).
The object-oriented approach is a very powerful and universal modelling tool, although it is based on only one modelling construct: the object. Objects are uniquely identified, have a state and behaviour. They represent abstract or concrete things. The main characteristic of the approach is encapsulation: joining function modelling and information modelling into one unified paradigm. The whole model is defined as a set of communicating objects (Vernadat, 1996).
In terms of business modelling, the main advantages of the object-oriented approach are property inheritance mechanisms and reusability of models and model constructs. However, the object- oriented approach is originally not meant to model businesses and processes. As Vernadat says:
“the object-oriented approach emphasizes the concept of object while enterprise modelling emphasizes the concept of process” (Vernadat, 1996). Also other familiar concepts for business users such as goals, products, and resources are not present in the object-oriented paradigm and must therefore be defined as specific object classes (Eriksson, 2000; Marshall, 2000).
4.1. UML
Since its introduction in January 1997 by the three amigos Grady Booch, James Rumbaugh and Ivar Jacobson, the Unified Modelling Language (UML) has quickly become the standard modelling language for object-oriented software development (Roques, 2004; Fowler 2004).
UML is a language for specifying, constructing, visualizing, and documenting the artefacts of a software-intensive system (OMG, 2003). According to the official introduction of UML on OMG’s website, UML defines twelve types of diagrams, divided into three categories: four diagram types represent static application structure; five represent different aspects of dynamic behaviour; and three represent ways you can organize and manage your application modules (Siegel, 2005):
•
structural diagrams – class diagram, object diagram, component diagram, and deployment diagram.
•
behaviour diagrams – use case diagram, sequence diagram, collaboration diagram, activity diagram, and state chart diagram.
•
model management diagrams – packages, subsystems, and models (OMG, 2005).
Some of the UML diagrams are explicitly intended for modelling business processes also, from which the activity diagrams form the most important one (Dumas, 2001).
UML is currently being upgraded to a new major version, namely UML 2.0. Being a multi-
purpose language, UML 2.0 offers a variety of notations for capturing different aspects of
software structure and behaviour (Wohed, 2005). Because the UML 2.0 specification is not ready
at the moment, we cannot summarize and evaluate the most modern UML’s possibilities to model
business processes. Therefore, we base our judgement about modelling business processes with
UML chiefly on two trials to model businesses with UML 1.x, proposed by Eriksson and Penker
(2000) respectively Marshall (2000).
The model management diagrams are in literature often left out, for example in the official description of the latest official version of UML (1.5) (OMG, 2005; OMG, 2003). The component and deployment diagram are seldom used in business modelling, so we still have seven diagrams. Eriksson and Penker (2000) give the following description of them:
•
Class diagram – describes the structure of a system. The structure is built from classes and relationships, such as associations, aggregations, and generalizations. Classes can represent and structure information, products, documents, or organizations.
•
Object diagram – expresses possible object combinations of a specific class diagram.
•
Statechart diagram – expresses possible states of a class (or a system) and shows also what triggers the change from one state to another.
•
Activity diagram – describes activities and actions taking place in a system.
•
Sequence diagram – shows one or several sequences of messages sent among a set of objects.
•
Collaboration diagram – describes a complete collaboration among a set of objects.
•
Use-case diagram – illustrates the relationships between use cases. Each use case, typically defined in plain text, describes a part of the total system functionality.
4.2. Business modelling with UML
Eriksson and Penker (2000) mention some reasons to use object-oriented techniques to describe a business. They call the next advantages:
•
Similar concepts. A business can be described in terms of processes that achieve goals by collaborating with different types of resource objects. Rules define conditions and constraints as to how the processes and resources may relate to each other and how they may behave.
•
Well-proven established techniques. Object-oriented modelling and programming has proven that it can handle large and complex systems. A number of patterns are available for modelling businesses.
•
Standard notation. Business modelling methods and techniques are in need of a standard notation. The tools are already there (viz. UML), and these tools can be adapted and used to describe the business models.
•
Short learning curve. Using object-oriented techniques and notation will decrease the gap between the business modellers and information system modellers and architects.
•
New and easier way to view an organization. The traditional way of describing and viewing an organization does not show much of how the business is performed. Object- oriented techniques can easily show modern business processes, as well as the traditional organizational structure.
The Eriksson and Penker-extension to UML has been called by Scott W. Ambler a ‘marriage between proven business modelling concepts and the techniques of the UML’ (Eriksson, 2000).
However, probably the major disadvantage to UML is its size and complexity. Many model
constructs, each having its own semantics, notation, and usage rules leads to an enormous barrier
that business modellers have to take before they can become familiar with this modelling
language. Moreover, the number of diagrams and the focus on system development instead of
giving the opportunity to analysis and model a business without implicitly taking always into
account any system, makes this language in our opinion unsuitable for and little accepted by the business modelling community. Although some efforts are taken to combine UML and workflow modelling languages, no real breakthrough has been realised until now (Wohed, 2005; Eshuis, 2003; Dumas, 2001).
We will not evaluate several business extensions to UML (see e.g., Marshall, 2000; Eriksson, 2000) and compare them with our language TALMOD in detail here; we will elaborate on this issue in future research.
4.3. Discussion: again an agent oriented alternative
During the last decade, more and more computer as well as business analysts indicated the shortcomings of the object-oriented approach (see e.g., Jennings, 2000; Zambonelli, 2003; Ferber, 2004). As an alternative, the agent oriented approach was quickly rising (Tveit, 2001). Yoav Shoham is seen as the first scientist using the agent-concept; his most famous article ‘Agent- Oriented Programming’ was published in 1993. The agent-concept as ‘one who is authorized to act for or in the place of another’ (Merriam Webster’s Dictionary) exists of course already many centuries.
The agent oriented approach has been used by many disciplines, like artificial intelligence, computer science, organization and management science, sociology, economics, philosophy and psychology (Weiss, 1999). Wooldridge (1999) defines an agent as ‘an encapsulated computer system that is situated in some environment and that is capable of flexible, autonomous action in that environment in order to meet its design objectives’. However, many scientists, and we agree, view humans, organizations, etc. also as agents (De Snoo, 2005; Wagner, 2003; Ferber, 1999).
Nevertheless, there will be always fundamental differences between humans and artificial agents, at least with respect to responsibility and liability (Dietz, 2003).
Summarizing, the agent concept seems to be very suitable, both regarding the ‘new’ requirements from software engineering, like flexibility and reusability, and from business modelling like process- and human-orientation (Klügl, 2002). We discussed and argued for an organization- centered agent-based perspective on businesses in our previous work, having a specific focus on planning process modelling (De Snoo, 2005).
5. A ‘union’ between business process and information system modelling
Now we have discussed two important modelling approaches and have argued for an agent oriented approach, we want to benefit from lessons learned.
Historically, business process models developed by business people have been technically
separated from the process representations required by systems designed to support, implement
and execute those processes. In this way, there was a need to translate the original business
process models to the information system models manually (White, 2004). Such translations are
subject to errors and make it difficult for the process owners, the business analysts and the IT-
specialists to discuss the same process from different points of view. However, business process
design and information technology development are more or less natural partners, and their
relationship can be defined as a recursive pattern (Giaglis, 2001).
How can we bridge the gap between business models and system models and between business or process modelling and information systems development? Important insights like the focus on actors and roles, distributed and complex processes and the ability to model static as well as dynamic aspects should then be taken into account (Odeh, 2003).
As we have seen, the advantages of Petri nets lie in their inherent concurrency, whereas UML is a powerful modelling language that is well accepted and widely spread. Both – UML and Petri nets – can contribute to the construction of large distributed and/or concurrent systems (Cabac, 2005).
A productive and intelligent ‘merge’ of the information systems models with the business models is meant to mirror, support and even automate the business (Odeh, 2003). However, as we also have seen, models are and can be used for many purposes. Therefore, we search a modelling language, that can be used for business processes analysis on the one hand and information system development on the other, between which a certain form of translation and conversion is possible.
6. Existing joining attempts
Several modelling scientists have tried to realize a merge between business process modelling and information system modelling, sometimes also by adopting the agent concept. Most of them have tried to incorporate the concept in existing languages (Odell, 2005a; Giorgini, 2004; De Lara, 2003; Wagner, 2003; Odell, 2000). We briefly discuss some of these languages and indicate the main shortcomings of them. For a more extensive analysis of these languages, see De Snoo (2005).
6.1. Agent UML (AUML)
Odell et al. (2000) propose an agent-based extension to the standard UML, called Agent-UML (AUML). The AUML-extension is remained limited to some subsets of UML, viz. interaction protocols, role modelling and class diagrams. An approach for defining semantics for AUML agent interaction protocol diagrams using Petri net code structures is described by Cabac et al.
(2005). Tveit remarks that AUML has been submitted to the UML standardization committee as a proposal for inclusion in the forthcoming UML 2.0 (Tveit, 2001).
AUML’s general philosophy is ‘when it makes sense to reuse/extend portions of UML, then do it;
when it doesn't make sense to use UML, use something else or create something new’. Although AUML pays some attention to agents and roles, the diagrams representing these roles and their accompanying activities are ‘at the threshold of human readability’ (Odell, 2000). However, we adopted from AUML the idea to use life lines, or swim lanes, to indicate which activities a role is performing in the course of time.
6.2. AORml
Wagner developed an agent oriented approach to the conceptual modelling of organizational information systems, called Agent–Object-Relationship (AOR) modelling (Wagner, 2003;
Szirbik, 2003). AOR is inspired by two widely applied models of databases, i.e. the Entity-
Relationship (ER) meta-model and the Relational Database (RDB) model (Tveit, 2001). AORml has been developed because neither ER modelling nor UML would provide any means to account for the deontic aspects of an information system, while such deontic concepts (like commitments and claims with respect to external agents, and right and duties with internal agents) would be essential for understanding and controlling interaction between agents and other systems (the social context). There are two basic types of AOR models: external and internal ones. An external AOR model adopts the perspective of an external observer who is observing the (prototypical) agents and their interactions in the problem domain under consideration (the ‘global view’). In an internal AOR model, the internal (first-person) view of a particular agent to be modelled (the
‘local view’) is adopted. However, these diagrams are really insufficient when you want to represent the complexity of multiple, probably conflicting views. Each agent has its own local view that is not known by other agents. The development of only two diagrams is obviously too little. The strength of AORml is the clear set of ontological principles that the modelling language is based on. An important disadvantage of AORml is the enormous amount of slightly different symbols, mainly caused by the many variations of dotted, semi-dotted and closed lines.
Furthermore, AORml currently does not include the concept of activities.
6.3. DEMO
DEMO has been developed as a result of a deep dissatisfaction with current ways of thinking about information systems and business processes (Dumay, 2005; Dietz, 2001; Dietz 2003).
According to the DEMO developers does existing modelling languages and tools fail to provide assistance in articulating what is essential and what is invariant about business processes. Like in our view, they argue for a focus on communication and interaction. DEMO is an acronym that has had several different meanings during the last two decades; currently it is an abbreviation of
‘Design & Engineering Methodology for Organizations’ (Dumay, 2005). It is a theory about and methodology for the construction and the operation of organizations that is rooted in the Communicative Action Paradigm, or also called the Language Action Perspective, regarding human communication and action. In this theory, the working principle of an organization consists of the entering into and the complying with commitments between human beings, where authority, responsibility and competence play an important role (Dumay, 2005).
DEMO is grounded on the concept of the ‘actor role’, defined as an amount of authority to perform particular acts (Van Reijswoud, 1998). An actor is a subject fulfilling an actor role. An organization consists of recurrent patterns of communication and action between actors playing several roles. Important notions in these patterns like responsibility, delegation and authorization are included in the DEMO syntax. However, DEMO is meant to model processes on a very high level: little attention is paid to activities and alternative work flows. Nevertheless, their strive to model communication patterns motivates us to continue our focus on agent interactions.
6.4. YAWL
Based on a meticulous analysis of existing workflow management systems and workflow
languages, Van der Aalst et al. propose a new workflow language: YAWL, an acronym for ‘Yet
Another Workflow Language’ (Van der Aalst, 2005). YAWL is strongly based on Petri net
modelling, but extended with additional features to facilitate the modelling of complex
workflows. YAWL has its own formal semantics and consists of only a few symbols. However, it is claimed to be able to represent most of all workflow patterns, i.e. recurring interactions. An overview of workflow patterns can be found in (Van der Aalst, 2003).
YAWL is explicitly meant to support the development of workflow systems (Van der Aalst, 2004b) and can be classified as an activity oriented approach, cf. section 3. It does currently not pay much attention to the agent, resource and goal perspective, unfortunately. Moreover, the YAWL semantics are not totally clear. Places are replaced by ‘conditions’, but a compulsory alternation of activities and condition is lacking. As a consequence, the state of a system cannot be easily recognized, because the exact location of the tokens cannot be depicted.
6.5. BPMN
Related to the Workflow Management Coalition (WfMC) and the Object Management Group (OMG) a group of commercial enterprises united in the Business Process Management Initiative (BPMI) is developing the Business Process Modelling Notation (BPMN). The BPMN 1.0 specification was released to the public in May 2004 (BPMI, 2005). BPMN is a modelling language that has been specifically designed to coordinate the sequence of processes and the messages that flow between different process participants in a related set of activities. The primary goal of the BPMN effort was to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes (White, 2004). Due to the size and power of the collaborating founders of BPMN, this notation will have an enormous impact on the acceptance and use of other (new) business process oriented modelling languages. BPMN already has been adopted by the UML group (BPMI, 2005).
Like with YAWL and many business process oriented languages, BPMN misses the link between the modelling of static and dynamic aspects of the process. Furthermore, these languages presume full process knowledge, or even omniscience. However, as we all know, in today’s dynamic business environments many aspects of processes are not known or even knowable before a process is executed.
This list of research into modelling languages is far from complete. However, it shows some different points of view and indicate some ‘grey areas’. In the next section, we present our research and introduce our alternative modelling language TALMOD.
7. The Agent Lab Modelling Language (TALMOD)
Starting in September 2004, The Agent Laboratory (TAL) at the University of Groningen has
been involved in the development of agent oriented business tools from an interdisciplinary, but
mainly organizational and management point of view. We will briefly introduce here our
background ideas. We believe that an architecture of distributed heterogeneous applications that
interact in a coordinated way is easier to maintain and extend than current enterprise information
system architectures (Zambonelli, 2003). Furthermore, we believe that such an architecture is a
more natural match to the network-centric model of computing and to today’s network-centric
business environment (Szirbik, 2003). More specifically, we believe that multi-agent
architectures have great potential in the support of and automation and optimization of business processes (Gilbert, 2000; Gazendam, 1998). In such an architecture, an enterprise information system would consist of a collection of expert agents that have knowledge and skill in narrow domains. The overall functionality of the system is implemented by the coordinated activities of the individual agents (Wagner, 2003; Szirbik, 2003). Finally, as can be concluded from the previous sections, we believe that an agent oriented approach is a natural match to business process modelling and that the success of an enterprise information system strongly depends on its ability to match the structure and scope of the business processes it is supporting.
We want to develop an open platform that is able to support collections of heterogeneous agents and a collection of tools that allow us to develop agents efficiently from (business process) models. Since their development in the 80’s, multi-agent systems, an important emphasis has been put on the agent side. Less attention has been given to the more organizational aspects (Ferber, 2004). Therefore, we will focus on interaction and coordination between the agents and will not focus on the decision making processes that must occur within the agent. Many alternatives exist for the implementation of the internal decision making processes (rule-based systems, BDI agents, etc), each with its strengths and weaknesses (Ferber, 1999; Weiss, 1999).
Following Wagner (2003) and Dietz (2003), we view business processes as social interaction processes emerging from the behaviour and the communication patterns of the participating agents (see also Van den Broek, 2001; Szirbik, 2001; Katzenstein, 2000).
Summarizing, we will develop a modelling language for agent oriented analysis and design, tools to automatically create (skeleton) code from these models and an open platform on which these agents can be executed. Humans can be actively involved in the development phase as well as during the use of the support software.
In this article, we present the modelling language developed in TAL. The language is explicitly based on UML as well as on Petri nets and can be seen as a union between them. TALMOD is suitable to model complex processes.
Parallel to the development of TALMOD we have been busy with the development of the so- called ‘Tupos’ framework. Tupos is ancient Greek meaning ‘prescribed form, model to be imitated’ or ‘archetype, pattern, model’. Tupos is all about models and patterns: it is the software implementation of the TALMOD language. The framework is meant as a basic software architecture for the implementation of the TALMOD diagrams. The Tupos framework will be described in a separate paper and is therefore not explained in this article.
Because planning belongs to the most difficult business processes (Van Wezel, 2001a; Van Wezel, 2001b; Jorna, 1996), we have taken planning processes as a basis case example during the development of the language. In this way, we use the modelling of planning processes as a benchmark to, more or less, proof the usability of our modelling language.
Planning has long been approached as a well-defined problem of a single stakeholder. However,
many planning problems are not owned by the planner only, but also by other employees like
suppliers, engineers, managers and operational co-workers. A planning problem therefore can be
considered as a problem in which various stakeholders negotiate to find a solution, and
collectively explore other ways than the conventional ways to solve problems. We can approach
this situation from a paradigm that the various stakeholders may have objectives, constraints and
degrees of freedom that the planner simply cannot know, should not know, and will not know,
because these stakeholders have no reason to publish them. As a consequence, many planners in
practise do not so much spend their time in planning but in social negotiations (Szirbik, 2004).
Recently, the suitability of using agent-based models, simulation and support systems in supply chain management and advanced planning systems has been described (Stadler, 2005; Dudek, 2004; Nishioka, 2004; Szirbik, 2003; Stadler, 2002; Fox, 2000).
Several studies about distributed planning in multi-agent systems from a more artificial intelligence point of view can be found in DesJardins (1999) and De Weerdt (2003).
Until now, TALMOD has been used to model several complex planning processes. Some examples encompass the personnel planning process of a police region, the production planning process of a cookie factory and the business and sales planning of a starch processing factory.
Currently, TALMOD is being used to model the complex assignment process of elderly to houses for long term care, like hospitals, nursing homes and residential homes, in UK. You can find the results at our website.
We propose to start each analysis and modelling project with indicating all actors and roles involved in the process. Humans are the most important entities in a process, because they initiate, handle and manipulate it and they are responsible for and stakeholders of the process results.
Secondly, the static structure should be investigated because this structure represents the environment in which a process takes place. Finally, the processes can be modelled, while explicitly paying attention to the local views on the processes of each of the agents.
This modelling methodology is extensively described in the manual ‘Modelling with TALMOD’, that you can download at our website, http://tbk15.fwn.rug.nl/twiki.
TALMOD define four types of diagrams that will be discussed in the next sections:
•
Agent-role diagram – displays which actors and entities play which roles in the modelled scenario (section 8).
•
Role-interaction diagram – identifies the roles in the process and the specific local processes that realize the overall process from the perspective of theses roles (section 8).
•
Static structure diagram – is basically the UML static structure diagram to which roles and the concept of information ownership are added (section 9).
•
Process diagram – describes in detail the activities that an agent executes in a business process. This diagram is always made from the perspective of one role in the process: the role that a specific entity plays in the process (section 10).
8. Agents, roles and interactions
Many people, such as the planner(s), operational and strategic managers, supply and purchase managers, marketing and inventory people will be involved in the planning process. The agent oriented modelling activity starts with making a diagram showing all these actors as agents related to the roles they are playing. One agent can play multiple roles, whereas one role can be played by multiple agents (Koubarakis, 2002).
A role involves a set of responsibilities and actions carried out by an actor or a group of actors
(Odell, 2005b; Koubarakis, 2002). Steimann (2000) and Dahchoura et al. (2004) have
convincingly described the difficulties around and also conflicting meanings and usage of the role
concept. Partsakoulakis et al. (2004) discuss the importance of roles for multi-agent systems to
act in complex domains. Their article encompass a review concerning specification and exploitation of roles in agent oriented system engineering methodologies, in formal models about agent social activity, and in multi-agent systems that are deployed in dynamic and unpredictable domains.
An agent is represented by a rounded rectangle and a role by an ellipse. An agent is a system that is situated in some environment and that is capable of flexible, autonomous action in that environment in order to meet its objectives. An agent can be an encapsulated computer system, but can also be a human being, organization, department, etc. (see also section 4.3). A role has a set of properties (= attributes) which are important for an agent to be able to behave in a certain way expected by a set of other agents. A role principally should not exist without being bound to an agent (-instance!). However, it is imaginable that a certain position is vacant, as a result of which a role is temporarily not played. The agent-role-connector is used to model which agent plays which role(s) (or: which role is played by which agent(s)) and is represented by a dotted- line arrow with open arrowhead.
Figure 2 shows an example of an agent-role diagram. Three agents, George, Bill and David are shown. They are all employees (their class-name) of a certain company and they have two (relevant) attributes: age and skills level. Three roles are played by these agents. Whereas Bill and David are playing each one role (‘manager’ respectively ‘department planner’), George is playing two roles (‘central planner’ and ‘department planner’).
Figure 2 is drawn on instance level. However, it is possible to make this diagram on class level, to stay on a higher level and give a more overview. We advice to avoid mixing class and instance level too much, although this can be sometimes useful. Like in UML, you can create hierarchies of agents, roles and probably even interactions.
Figure 2. Agent-role diagram.
The structural and/or temporary relationships between roles in a certain process are shown in a separate diagram (fig. 3). The Role interaction, comparable with the UML N-ary association symbol, is the most important symbol. Roles are connected to the lines outcoming the hexagon.
Each role has its own view (goal, knowledge, contribution, etc.) regarding the process. A
sNICKer (the arrow rectangle) represents this local view of the process. Therefore, a sNICKer is
also called a local behaviour (LB); this name will be the official name from the next TALMOD
version. Within the hexagon, for each of the roles at least one sNICKer should be drawn. For
each sNICKer principally a separate process diagram showing the process from this specific viewpoint should be drawn. The process diagram will be called a LB-diagram in the next TALMOD version (section 10).
Be aware, some other modelling languages use the sNICKer symbol to represent messages. The sNICKer has nothing to do with messages. Messages are represented by envelopes in TALMOD, see section 10.
Figure 3. Role-interaction diagram.
Figure 3 shows the relation between the roles from figure 2. Central and department planner interact within the planning process. Manager and central planner interact in a small part of the planning process, viz. during the determination of the order sequence. This determination is done in a consultation (a negotiation). Local views on the processes are depicted with the sNICKers, e.g. the left arrow rectangle with the ‘c’ indicates the local view of the manager on the consult process in which the central planner also is involved.
As you see, the role-interaction diagram does not provide a detailed description of how a role is implemented, but rather serves to identify roles and role responsibilities. The role-interaction diagram is a type-level diagram, identifying types instead of instances.
9. Static structure
All important objects involved in the process should be represented in the static structure diagram(s). This diagram is nearly the same as the UML static structure diagram (OMG, 2003;
Eriksson, 2000); it is of all TALMOD diagrams the one that is closest to UML. The diagram consists of all the passive objects involved in the process accompanied by relationship with or ownership of roles. By the way, sometimes it is advisable to create separate database diagrams representing a database structure (see e.g., De Brock, 1995).
The most obvious object in a planning process will be the plan itself. Subsequently, the object types that are planned in the planning process should be indicated. If the planner is assigning nurses to shifts, the nurses (people) and time slots (time) are objects in the static structure diagram. Messages are the third important group of objects. Messages should be sorted by kind;
e.g., cancellations, remarks, requests, etc. We propose to use a limited list of message
‘stereotypes’, based on the FIPA-specifications (FIPA, 2005) like inform, propose, request, promise, decline, quit, state, accept, reject, cancel, refuse, failure, not understood and stop.
Because we expect most of the readers are familiar with the UML static structure diagrams, we do not give an extensive explanation of this type of diagram here.
Figure 4 shows an example of the static structure diagram, created at class level. This model is far
from complete, only a few classes and attributes are shown.
The already introduced roles are placed in the mid of the diagram. Because we deal with a planning process, the plan is the most important class. Plan is the superclass for three kinds of plans: the four week plan, the week plan, and the department plans. These three subclasses are connected with the generalization symbol to the plan class.
Each plan consists of a number of allocations, at least one. Each cell in a plan can be seen as one allocation: an article is allocated to a resource (or vice versa). Plan and allocation are connected with the composition symbol: a part instance, i.e. an allocation, is included in at most one composite, i.e. a plan, at a time, and that the composite object is responsible for the creation and destruction of the parts.
One article can appear within zero or more allocations, as it is the case with one resource, while one allocation can only deal with only one article and one resource.
The three roles can send and receive messages. Two kinds of messages are shown: the subclasses cancellation and call for change.
Figure 4. Static structure diagram.
10. Process diagram
After the modelling of the static and structural aspects of the process, much attention should be paid to the process itself. Which activities are performed, what is the sequence of these activities, which actors collaborate, what are the dependencies, what time issues are relevant, et cetera.
Because each actor has his/her own view on the process, for each actor a separate process diagram should be drawn. Thus, the process diagram provides a detailed description of the business process from a local (role-specific) perspective.
The TALMOD process diagrams together describe the business process dynamics in the greatest amount of detail. To avoid miscommunication we here announce our proposal to change the name ‘process diagram’ into ‘local behaviour’ (LB) in the next TALMOD version. A LB often does not show a complete process, because it focuses on some local activities that are part of a process. In fact, it present the content of the sNICKer that is drawn within the interaction in the role-interaction diagram. In the next TALMOD version, a ‘process diagram’ will show combinations of LBs. This is of particular interest because such a process diagram can represent the extent of successful matching between several LBs. As we argued, this matching issue has been one of the main reasons to use an agent oriented approach to business modelling.
An actor has often some vague ideas about the ‘way of performance’ of other agents, as far as this way is relevant for him/her. These other roles involved in the process are depicted in separate swim lanes, but can be depicted at a very high-level of abstraction (really only defining the interaction-protocol or role-interface). The external activities (i.e. external activities relevant for an actor, but unknown by him) are very roughly pictured with a ‘cloud’. By describing processes performed by other roles at a high level of abstraction, the assumptions about the other roles are decreased and the local process model becomes compatible with more remote process models.
The process diagram is based on Petri nets. The token is the element that in a certain sense flows through the model. A token is defined as a marker that says that an event has occurred that is relevant to the business process instance (i.e. the ‘case’). A token is a little piece of information that serves as trigger for activities to be executed in the process. The transition of an object (a product, document, etc.) is called an activity. An activity is performed under certain conditions by the agent that is executing the process model. Activities are very much like Petri net transitions or UML actions.
An activity is always connected with one or more input ports and one or more output ports. A port can be seen as the portal of an activity. No token can enter an activity than via an input port and no token can leave an activity than via an output port. No other modelling languages model these entrance and exit points explicitly, and we have seen that by doing this the process diagrams are much easier to read and interpret.
An input port is defined as a logical entrance of an activity, used to differentiate logical input conditions for the activity. It describes situations in which an activity should be executed. By distinguishing several input ports, it is possible to represent these different situations explicitly.
An output port is slightly different defined: it is a logical outcome of an activity, used to differentiate logical output conditions for the activity. By distinguishing several output ports, it is possible to represent different activity outcomes explicitly. Output ports are comparable with the
‘decision’-symbol in UML activity diagrams. However, a UML decision (or ‘branch’) should be
enriched by guards, which are implicit in the TALMOD ports.
Ports cannot exist without activities. They are represented with a rectangle with a small black triangle (to indicate the direction and to distinguish them from activities). Within the port, a letter can be written to represent a certain ‘logical’ condition explicitly (e.g., a ‘y’ (for ‘yes’) and ‘n’
(for ‘no’)).
The place where an arrow connects to a port is called a port connector and it denotes a token slot.
These port connectors are not modelled explicitly and are only important for the conversion of the TALMOD models into (simulation) software. Therefore, we neglect this issue here.
A plate, represented by a circle, is a state in which a token can be. It is a placeholder for tokens.
Plates represent process internal ‘waiting areas’ for tokens that are being moved through the process model. Plates are very much like Petri net places or UML activity states (Eshuis, 2003).
In an effort not to use too many overloaded terms, we have decided to call them ‘plates’ (as you can guess the runner-up was ‘staces’).
Figure 5 shows the cohesion between activity, ports and plates.
Figure 5. Activity, ports and plates.
