Dynamic Agent Hierarchies for Design Prototypes

Nick Szirbik, Marco Stuit SOM Research School, dept. Business & ICT

FEB, University of Groningen Groningen, The Netherlands {n.b.szirbik, m.stuit}@rug.nl

Gerben Meyer The Agent Lab, dept. Business & ICT

FEB, University of Groningen Groningen, The Netherlands

g.g.meyer@rug.nl

Abstract— Introducing dynamic aspects in diagrams that capture the aggregate structure of composite agents represents a promising notion, which can help to express in a straightforward manner how an entity is changing its placement during its evolution in time. This paper focuses on the novel concept of a dynamic aggregate “prototype” for agent-oriented modeling languages, which enables business modelers and system designers to play with and generalize models of existing reality. First, the importance of the role concept in dynamic collaboration is discussed and then the necessity of having explicit hierarchical structures for agents is argued. Next, the rationale for introducing agent groups is presented and their relation with the role concept is explained. A comparison with other approaches that offer agent aggregation is done. Finally, an example is used to illustrate the use of the new concept, and future avenues for research are introduced.

Keywords- Business modeling, multi-agent system design, dynamic collaboration, process visualization

I. INTRODUCTION

Today, several agent-based modeling languages and their frameworks are widely known as mature tools for business modeling and system design, despite the lack of an accepted standard. Due to the experimental nature of these approaches, the academic research area is coming continuously with ideas for improvement. Characteristic for the majority of proposed languages is the widespread use of a highly explicit graphical symbolism [9]. Depending on the purpose of the modeling exercise, there are various special requirements for the language and associated tools used to capture the intricacies of collaboration in dynamic organizations. Structural consistency and process coherence aside, the easy understanding of meaning by “non-natives” is a very strong requirement [10]. The choice for user-friendly graphical syntax constructs contributes always to the understandability of a modeling language.

A model that is used to capture the reality of a collaborative business process needs different types of diagrams for different purposes. In any case, the formal syntax and semantics, plus the visualization techniques have to cope with the dynamic features of the process. Most of the time, this dynamics refers to the allocation of resources to roles. Consequently, one of the most important concept evolutions in agent-based modeling languages is how the term “role” gained importance over the last decade [5][6][18][19].

Agent-based modeling languages are used in different phases of system design, which can include a (business) domain analysis in the early requirements phase (like in TROPOS [4]. Nevertheless, it was identified that there is a “modeling gap” [7] between the conceptual modeling and implementation design, as well as between the agent and role concepts. This gap is revealed when the modeler and the system designer are identifying the intrinsic structure of the organization under study, and trying alternatives of agent system organization and the mapping of agents’ internal structure with the agent structures in the conceptual models.

The approach presented in this paper tries to overcome this modeling gap. The idea is to link agent structure descriptions to an ongoing discussion and comparison of hierarchies [8]. Hierarchies are categorized in four distinct types [2]: control, inclusion, order, and level hierarchy. It is argued here that roles are typically organized in a control hierarchy, composite agents should be represented as inclusion hierarchies, and abstract classifications of agents in agent groups (based on their skills and authorizations) should make use of order hierarchies. The paper refines the concept of the agent group as classifier and its relation with the classical role concept, and presents the novel concept of agent prototype and its importance in the context of creating generic aggregations of agents and building design alternatives for the envisaged business system.

The remainder of the paper is organized as follows. Section 2 presents the motivation for the proposed diagrammatic conventions. Section 3 presents the syntax and semantics for the agent group and the agent prototype, and Section 4 compares inclusion and level-based aggregation with two other approaches that are concerned with these aspects. Section 5 deepens the discussion through an illustrative example that shows how an agent prototype is developed from dynamic agent instance diagrams. Section 6 summarizes the arguments in favor of the presented approach and points out directions for future research.

II. BACKGROUND AND MOTIVATION

The notion of dynamic allocation of entities to roles assumes that agents can acquire and loose – in a short time span – a number of “acting places”, but without loosing their “natural” identity. This concept is simple and straightforward in modern organizational theory, where a person is considered a flexible and pro-active human entity that can play various roles in different situations, some of them

2009 18th IEEE International Workshops on Enabling Technologies: Infrastructures for Collaborative Enterprises

1524-4547/09 $25.00 © 2009 IEEE

DOI 10.1109/WETICE.2009.33

7

simultaneously. Teams and larger collectives (i.e. organizations with a purpose and goals) can play “composite” roles – like “army” plays the role of “defense” for a nation-wide organization, but also other roles in the same time. Thus, for business modelers, a role is typically an abstract concept, a mere placeholder that is normally attached to a certain activity. The agent playing the role is then regarded as a resource [17].

Yet, when combining business models with IT development, the software-centric modeling takes a rather different tack. For example, in UML [12], roles can be modeled in the simplest way as relationship-end names, improving the semantic explicitness of class associations. In database design, approaches like ORM [13] upgrade the role concept to a higher graphical syntactic complexity and a more focused meaning, but still keep the role statically linked to an object. The work of Steimann [19] proposed the equivalence of role and object (or class) interface, where other proposals worked around the concept of multiple classifications of objects, which allow in turn dynamic class binding. These “role-classes” can be modeled in various ways (e.g. [7], by introducing the “is-a-role-of” relations), but in most cases, the method is to establish a new relationship between classes, or just a dynamic role attribute in a class.

In contrast to these approaches, workflow models associate the roles directly to activities and not to the resources or actors. This increases the semantic explicitness of the dynamic bindings, by allowing a clear separation between activity, role, and the entity (resource) that plays the role [1]. When used for dynamic aspect diagramming, UML and its extensions offer the use of “indirect” role names for, for swimlanes and timelines in the activity diagrams and sequence diagrams respectively (as “prototypical instance” names). Agent oriented extensions like AUML [3] and MESSAGE [5] use the role concept for the same purposes.

Figure 1. Figure 1. Dynamic binding of agents to roles in TALL

The TALL agent-based language [20][22] links the role concept directly to the explicit interaction construct [21] like in Figure 1. The verbalization of the diagram, if interpreted from a present state view is the following: “the agent named A of kind C is currently playing the role ct in an agent interaction of type R” (having the unique identity y). The other role involved in the interaction, tr, is not yet allocated to an agent. In a past state view (a trace, or log), the diagram indicates that “A played ct”, and in a future (prescriptive) state view it will indicate that “A shall play ct”, or in a predictive sense, “A may play ct”. The underlining of the diagram elements’ names shows that these are instances (like in UML). Roles, being placeholders, cannot be instantiated. The agent-role connector, in an instance level diagram, denotes the “play” relation. The triangle icon for agent A is used to distinguish synthetic agents (i.e. composite agents) in

TALL. A synthetic agent can be composed by other synthetic agents. Circle icons represent human agents (see Figure 2), square icons represent software agents, and a diagonal cross represents physical assemblies. Physical assemblies and software agents can also be composite. For instance, a software agent can be part of a larger assembly, like in Figure 3, and can contain other software agents, but cannot contain humans, who are considered atomic (i.e. cannot contain any other agent). Two more relationship types complete the language elements: humans can be “represented” by software agents and can be “in charge” of synthetic agents (like G.Head is “in_charge” of B.Department, or like in Figure 3, a.H is in charge of a.B, and is represented by a.PA – a.B is represented by a.BA, and a.T is represented by a.Ap). Synthetic agents can be also “represented” by software agents, which is typical in situations when for instance fully automatic sales websites represent the seller company.

One of the issues that is very important in organizational theory but up to now completely neglected in software models (agent-oriented or not) is that roles can be structured in various hierarchies. It was argued [8] that the concept of hierarchy must be added to any universe of discourse, language, and modeling method in those research fields that have already central concepts like “system”, “interactions”, “emergence”, “self-organization”, “learning and adaptation”, “networks”, “distributed control”, which are all common concepts in the multi-agent system paradigm. An explanation of why the concept of hierarchy (except for the ubiquitous object-oriented class hierarchies based on “is-a” relations) was avoided until now is [14] that it is notoriously difficult to model and visualize complex hierarchical structures properly.

III. HIERARCHICAL AGENT AND PROTOTYPE MODELING

According to [15], hierarchy is the key concept for understanding complex systems. This research produces a general ontological framework based on hierarchy, and argues why both natural and manmade complex systems should conform to this framework. The research is critically reviewed in [2], where a series of fundamental questions is raised about the issues of control, inclusion, ordering, and level-based systematization. These issues stand as the basis for four main types of hierarchies. All four are represented to some degree in TALL. The first one, the control hierarchy, is represented by Role Structure (RS) diagrams. It is commonly used in social organization, and has to do with who gives the orders/reports to whom. In Figure 2, the triangle that unites role c with role tr shows that c has a degree of control over tr. The composition of a synthetic agent is reflected by an inclusion hierarchy [8] in the Agent Structure (AS) diagram, Inclusion semantics refers to the position of a agent inside other agents. In this regard, the AS diagram is used to reflect the fact that, during the execution of a collaborative process, it may emerge that an agent exists and “participates” within the boundaries of an agent that can be identified by name and scope because of an a priori ontological claim – based on organizational or social need (e.g. a doctor “acts” within the

8

scope of the hospital). This participation indicates that the agent plays a dynamic “internal” role. The inclusion hierarchy in the AS diagram captures the emergence of an internal role structure via the “participate_in” relation. This relation can be expressed further by the skills that the agent brings to the (organizational or social) context that is reflected by the synthetic agent, and additionally by the topology of inclusion. Agent groups are used in TALL to group together agents with similar skills.

In Figure 1, agent A “is a kind of C”, where C represents an agent group where all the member agents have similar skills. In Figure 2, the human agent J who has a skill S participates in the synthetic agent A, which is envisaged as possessing a composite “skill” C. By identifying collections of skills (and eventual authorizations, or just purpose in the case of agents representing physical assemblies), a model describing the group structure can be extended with an explicit group definition for each collection, which leads to a group list and a group diagram where groups are visualized with the same shape used for agents, a “roundangle”, with a name stamp that adheres to the syntax of class names in UML. In Figure 2, there are two groups explicitly shown: C and S.

Figure 2. Figure 2. An example of the role-group-agent concept triad

It is important to stress that in TALL an agent is not statically linked to a group. Agents can change dynamically their group membership, and can be members of more groups simultaneously (resulting in visual overlap of their groups). It is also possible that an agent is not a member of any group. Within an agent group, it is possible to have the third type of hierarchy, namely the order hierarchy. Depending on a specific quantitative feature (like seniority in business for example, or rank in the military), the group can have various orderings, which transforms the group into a topologically ordered set. This concept of order hierarchy is not yet implemented in TALL. In TALL, the group concept has an additional purpose besides the classification. Steimann [18] proposed the “populate” relation between resources and roles. The equivalence between a group name and a role name (syntactically these are slightly different, but an equivalence is easy to establish – like between the role name c and the group name C) illustrates a “weak populate” relation, meaning that a group defines those agents that are recommended to play a specific role. It can be verbalized from Figure 2 that the members of C are the most recommendable to play role c. However, there is not a one-

to-one relation between group and role. Initially, the language proposed an isomorphism between roles and groups, but it proved to be too rigid for practical modeling because one of the early design principles in TALL is that any agent can play any role. An exception for the above principle is when explicit constraints (like authorizations) are specified via a “strong populate” relation, syntactically rendered as an arrow between a group symbol and role symbol. In Figure 2, members of S are the only ones authorized to play role tr.

The interaction-bound roles, the agents’ compositional structures, the groups and their (strong and weak) relationship with roles are the main modeling concepts that assist in identifying and monitoring an emergent and ever-changing reality in TALL. The user-interfaces that display these models have to exploit (by positioning, animation) the dynamic features that are part of the syntax and semantics of the language. The symbols depicting agents have to illustrate with ease how agents change the roles they are playing, how they change their group membership, and their participation within synthetic agents.

However, from a mental modeling perspective (i.e. the modeling of an extended, imagined, or desired reality), the role-group-agent_instance triad of concepts is not enough. Furthermore, if the models are developed as executable simulation models (e.g. for serious gaming, prediction, simulation-driven design) or used for software agent design, a special kind of diagram is needed. This diagram has to fulfill the function of a drawing-board for dynamic structures and should allow the exploration and creation of alternate realities, which are derived from the diagrams discussed above that capture the existent reality.

*

Figure 3. Figure 3. An agent prototype

This exploration and creation is done in a new type of diagram named the Agent Prototype (AP) diagram. This diagram allows the modeler to play with reality by changing the generic structure of a synthetic agent. The syntax of the AP diagram is similar to the AS diagrams, which use nesting as the graphical layout (to illustrate the “participate_in” relation). In AP diagrams, roundangles are used to represent “prototype” agents, and the nested graphical layout expresses a “placed_on” relation, which is also dynamic, like the “participate_in” relation for agent instances. In many engineering domains, prototypes are built to play with

9

reality, to test and validate ideas, and support decisions for design, development, and use.

In Figure 3, a prototype who is member of a skill group B contains a number of human and software agents. Physical assemblies like a.T can represent generic objects from reality. The naming convention for prototypes is a hybrid between instance and class name, suggesting for example “a Human” for the prototype a.H. Multiplicities can be added in a fashion similar to UML (the circle in the upper right of a roundangle contains the specification).

The user interfaces that assist in creating AP diagrams should allow for easy manipulation of the placement of prototypes on each other, because these diagrams have the same dynamic quality like the AS diagrams. The main difference with the AS diagrams is that an AP diagram is not an inclusion hierarchy, but a level hierarchy, according to [8]. This is because the diagram depicts something that is designed and is not a direct snapshot of reality. The main utility of the agent prototypes in the AP diagram is that they can acts like collectives from which new agent instances can easily be created for simulation purposes. Such agents will not have a direct mapping to reality, being a consequence of the design decisions and mental models of the experimenter.

IV. RELATED WORK

Previously it was positioned that the AS diagram is an inclusion hierarchy in which agents are dynamically composed and AP diagram is a designed level-hierarchy. Below, a couple of agent-oriented modeling techniques that offer comparable structural representations of the agents are discussed.

AORml [23] presents an agent-oriented approach to the conceptual modeling of organizations and organizational information systems. In AORml, an institutional agent is a composite agent similar to the synthetic agent in TALL. It is an aggregate of a number of (human, software, or institutional) internal agents that act on behalf of it. In AORml, the agent diagram is used to depict agent types, object types and the relationships between them. Graphically, internal agents are depicted inside the institutional agent. Syntactically, this is similar to the TALL AS and AP diagrams. However, the semantics is quite different. In AORml, the internal agents assume a certain position within the subordination hierarchy of the institution they belong to. Thus, in effect this is a control hierarchy. In the AS and AP diagram, the synthetic agents are mere containers for the agents that participate in interactions. In this regard, the synthetic agent provides a certain (organizational) scope for its members instead of acting as a higher-ranked agent.

AML [6] is a visual modeling language for specifying, modeling and documenting multi-agent systems. In the language, agents are one of many entities that can exist independently of other objects. Entities make use of the modeling possibilities allowed for UML classes. Although the use of UML notation is common in many agent-oriented languages (e.g. AUML), AML provides some specific agent-oriented features. Among these features is the environment type. The environment type provides the condition under

which the inner entities exist. The internal structure of an environment that can consist of agents and other entities is modeled by means of contained parts, ports and connectors. Aggregation and composition associations are also used. In this way, the language allows entities to be nested in order to model hierarchical structures. The environment type acts like a container in which the agents are situated.

The agent diagrams in the languages above adhere to a static representation of the agent structure. The visualization of the agent diagrams in TALL allows for dynamic repositioning of the agents. In other words, agents can leave and enter inclusion hierarchies or can be placed and deleted from level hierarchies.

V. FROM AGENTS TO DESING PROTOTYPES: AN

EXAMPLE

After the text edit has been completed, the paper is ready for the template. Duplicate the template file by using the Save As command, and use the naming convention prescribed by your conference for the name of your paper. In this newly created file, highlight all of the contents and import your prepared text file. You are now ready to style your paper.

This section shows how an AP diagram is composed, using AS diagrams of agents participating in a business process. The composition is demonstrated using a case example of a transportation company, which main business is to transport pallets for clients from a certain source to a certain destination. The research related to this case is driven by the need to develop software agents that represent physical assemblies (transport pallets), transforming these in “intelligent products” that can assist the logistic process via agent-based decentralized control (see [11]).

3. DeliverySource DestinationTransportation

Company

Client

1. Order

2. Pick up

Figure 4. Figure 4. Typical process of transportation of pallets

As shown in a simple flowchart in Figure 4, this process typically consists of several steps. First, the transportation company receives an order from a client, which has one or more pallets that are in need of transportation. Afterwards, the transportation company will send a truck to pick up the pallets at a source location. This truck delivers the pallets to the storage location of the transportation company. Finally, another truck will pick up the pallets from the storage location and deliver them at the final destination. Of course, the transportation company always tries to combine pickup and delivery of pallets of different orders as much as possible, in order to obtain a more efficient use of trucks. A more detailed description of the company’s activities and processes can be found in [13].

Next, the different steps of this case example are described in more detail, using AS diagrams that capture the

10

state of the business domain at a certain moment in time. Afterwards, these diagrams are used to compose an AP diagram. In the initial state, the pallets that are to be transported are still at the source location, as is shown in Figure 5. The figure shows two pallets P1 and P2 (depicted as physical assemblies), which are participating_in the source location, in this case, company C1 (depicted as a synthetic agent).

Figure 5. Figure 5. Pallet P1 and P2 are at the source location

An order is placed at the transportation company, to transport the pallets P1 and P2 to company C3 and C4 respectively. After sending a truck to pick up the two pallets at the source location, and delivering them to the storage location of the transportation company, the state of the transportation company is as shown in Figure 6. The company has two human planners, Jan and Piet, as well as two human drivers, Klaas and Peter, who both participate_in the transportation company. Furthermore, the company has two idle trucks, T1 and T2, and the two pallets, P1 and P2, which participate_in the company’s storage facility S1.

Figure 6. Figure 6. Pallet P1 and P2 are in the storage of the

transportation company

Next, two trips are planned, in order to deliver the pallets P1 and P2 to their final destinations C3 and C4. This leads to the situation as shown in Figure 7, where two trips are shown, TR1 and TR2, depicted as synthetic agents, with a driver, truck, and route graphically representing participate_in relations. The driver and truck that are participating in the trip are not anymore represented as included in the transportation company agent, meaning that they are not idle anymore, but have been assigned to a specific trip. Furthermore, the pallets participate_in the trucks, showing that in reality the pallets are now loaded into these trucks for transportation.

Finally, the two pallets are delivered to their destinations. This leads to the situation as shown in Figure 8. The pallets are now participating_in their destinations, company C3 and C4 in this case.

Figure 7. Figure 7. Trip TR1 and TR2 have been planned

Figure 8. Figure 8. Pallet P1 and P2 are delivered

The AS diagrams, as shown in Figures 4 to 8, can be used to compose an AP diagram. Such a composition can yield a diagram as shown in Figure 9.

**

***

**

*

**

*****

33

Figure 9. Figure 9. The generic diagram of the composed prototypes

The diagram shows all the possible locations where agents can be “placed on” other agents. For example, a pallet agent can be placed on a company agent, meaning that it is located at a company, alternatively it can be placed on a storage agent, meaning that it is in the storage facility of a transportation company, or it can be placed on a truck, meaning that the pallet is inside that truck. Furthermore, the

11

diagram shows the multiplicity of the agents that can be placed on another one. For example, only one driver, route, and truck can be placed on a trip, but 33 pallets can be placed on top of a truck, as this is the maximum capacity of a truck. Just as in UML, a “*” indicates that there is no particular threshold value for how many agents of this kind can be placed on the other agent.

In this specific example, the development of design prototypes was extremely useful for investigating logistic and collaborative planning scenarios. These have to assume the existence of software agents that represent various synthetic and human agents, as well as physical assemblies (like trucks and pallets). This example shows that the novel features of the TALL language allow easy dynamic placement and inclusion. The first modeling experiences showed the diagrammatic conventions to be intuitive for non-native users and stakeholders. However, the semantic explicitness is still to be proven empirically in a controlled environment.

VI. CONCLUSIONS AND FUTURE WORK

This paper shows how a development process from existing agents to design prototypes benefits the system designer. In the development process, dynamic participate-in relationships are visualized in a way that captures a flexible inclusion hierarchy. This enables the system and business designer to evolve models of reality into desired models of agent structures that preserve dynamic features. The novelty of this approach is the link between an ontological framework of hierarchies and the design principles governing agent-oriented language development. The framework states that there are four basic types of hierarchies and in TALL all these four are investigated and some already represented.

Future work intends to test quantitatively the expressive power of the presented diagrammatic conventions. Moreover, the language is to be applied and tested in various empirical business settings using a multiple case study approach.

REFERENCES [1] van der Aalst, W. M. P., van Hee, K., Workflow Management:

Models, Methods, and Systems, MIT Press, Cambridge, MA, (2002).

[2] Ahl, V., Allen T., Hierarchy Theory: A Vision, Vocabulary, and Epistemology, Columbia University Press, NY, (1996).

[3] Bauer, B., Muller, J., Odell, J., Agent UML: A formalism for specifying multiagent interaction. In: Proc. AOSE’00, 91–104, Limerick, Ireland, (2001).

[4] Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F., Mylopoulos, L., Tropos: An agent-oriented software development methodology, Autonomous Agents and Multi-Agent Systems 8(3), 203-236, (2004).

[5] Caire, G., Coulier, W., Garijo F., Gomez, J., Pavon, J., Leal. F., Chainho, P., Kearney, P., Stark, J., Evans, R., Massonet, P., Agent Oriented Analysis using Message/UML, LNCS, vol. 2222, pp. 119-135. Springer, Heidelberg (2002).

[6] Cervenka, R., Trenanský, I., Calisti, M., Modeling social aspects of multi-agent systems: The AML approach. In: Müller, J.P, Zambonelli, F. (Eds.) AOSE 2005. LNCS vol. 3950, pp. 28-39. Springer, Heidelberg (2006).

[7] Jodlowski, A., Habela, P., Plodzien, J., Subieta, K., Extending OO Metamodels towards Dynamic Object Roles, LNCS, Volume 2888, Springer, Heidelberg (2003).

[8] Lane, D., Hierarchy, Complexity, Society. In: Hierarchy in Natural and Social Sciences, (ed. D. Pumain), Springer Methodos, Dordrecht, (2005).

[9] Luttighuis, P. O., Lankhorst, M., van de Wetering, R., Bal, R., van den Berg, H., Visualizing business processes, Computer Languages, Pergamon, 27, 39-59, (2001).

[10] Mendling, J., Reijers, H., Cardoso, J., What makes process models understandable? In: Alonso, G., et al., eds., BPM 2007 Proceedings. LNCS 4714, (2007).

[11] Meyer, G. G., Främling, K., and Holmström, J., Intelligent Products: A survey. Comput. Ind. 60, 3, 137-148, (2009).

[12] OMG Unified Modeling Language, v.2.1.2, available at: http://www.omg.org/spec/UML/2.1.2/, (2007).

[13] ORM foundation, at: http://www.ormfoundation.org/

[14] Robertson, G. G., Czerwinski, M. P., Churchill, J. E., Visualization of mappings between schemas. In Proc. of the SIGCHI Conference on Human Factors in Computing Systems, ACM, NY, (2005).

[15] Simon, H., The Organization of Complex Systems. In Hierarchy Theory: The Challenge of Complex Systems, (ed. H. Pattee), George Braziller, NY, (1973).

[16] de Snoo, C., Hoogenraad, M., Wortmann, J.C., Opportunities for collaborative planning in freight transport planning. Proc. EurOMA 200), 15-18 June 2008, Groningen, The Netherlands, (2008).

[17] Stacey, R. D., Strategic Management and Organisational Dynamics: The Challenge of Complexity to Ways of Thinking About Organisations, Pearson Education ltd., Harlow, Essex, England, (2007).

[18] Steimann, F., On the representation of roles in object-oriented and conceptual modelling, Data & Knowledge Engineering, 35 (1), 83-106, (2000).

[19] Steimann, F., Role = Interface: A merger of concepts, Journal of Object-Oriented Programming, 14 (4), 23-32, (2001).

[20] Stuit, M., Szirbik, N.B., de Snoo, C., Interaction Beliefs: A Way to Understand Emergent Organizational Behaviour. In: 9th International Conference on Enterprise Information Systems, 241-248. INSTICC, Funchal, Madeira, Portugal (2007).

[21] Stuit, M., Szirbik, N.B., Modelling and Executing Complex and Dynamic Business Processes by Reification of Agent Interactions, LNCS, vol. 4457, 106-125. Springer, Heidelberg (2007).

[22] Stuit, M., Szirbik N.B., Towards Agent-based Modelling and Verification of Collaborative Business Processes, Int. J. of Cooperative Information Systems, under review (2009).

[23] Wagner, G., The Agent-Object-Relationship Metamodel: Towards a Unified View of State and Behaviour, Information Systems, 28(5), 475-504 (2003).

12