Elizabeth A. Kendall Intelligent Business Systems ... - CiteSeerX

AGENT ROLES AND ROLE MODELS: NEW ABSTRACTIONS FOR INTELLIGENT AGENT SYSTEM ANALYSIS AND DESIGN Elizabeth A. Kendall Intelligent Business Systems Research, MLB1 / PP12, BT Research Labs Martlesham Heath, Ipswich IP5 3RE ENGLAND Email: [email protected] ABSTRACT This paper presents roles and role models as new abstractions for specifying, modelling, and designing intelligent agent systems. The approach is particularly valuable for applications that involve information and process management because it represents a unified approach. Software agents, objects, processes, organizations, and people can play roles and can therefore be incorporated into a role model. This paper provides an overview of role modelling and describes research at BT that is documenting role model patterns of intelligent agent systems. 1. INTRODUCTION The analysis and design of systems that include intelligent agents, as one type of software engineering, should answer the following questions (along with others): 1. What does this application do ? 2. Should intelligent agents be used in this application ? 3. What does each intelligent agent do ? 4. What goals, responsibilities, tasks, and expertise does each agent have ? 5. How do the intelligent agents interact with each other and with other entities ? 6. What kind of agents and what kind of agent architecture should be used ? Capturing and structuring goals [13] is an approach to analysis that results in a goal model (a goal hierarchy diagram) as an answer to question 1 above. Questions 2 through 6 above involve partitioning the goal model, allocating goals and activities to intelligent agents, objects and people. This is similar to responsibility based design [26] The relatively new area of role modelling [1, 16, 19, 22], as defined in object oriented software engineering, is presented in this paper as a promising approach to addressing questions 3 through 6 above. As described in this paper, role modelling is appropriate for intelligent agent systems because of the following: • Role models emphasize social or interactive behavior. • Roles in a role model work together to accomplish a goal. • Role models are patterns that should be documented and shared. • Roles and role models provide a new abstraction that can unify diverse aspects of a system. Software agents, objects, processes, organizations, and people can play roles, and this is especially important in applications that encompass all these types of entities, such as information and process management. • Role model synergy integrates roles and may be valuable for agent design. • Role model dynamics can be employed to model mobility, adaptive behavior, context switching, and other aspects of agent systems. 2.0 ROLES AND ROLE MODELLING IN OBJECT ORIENTED SOFTWARE ENGINEERING 2.1 Overview Roles and role models [1, 16, 19] are relatively new abstractions in object oriented software engineering. Object oriented software engineering has to date focused on classes. Classes stipulate the capabilities of individual objects, while the notion of a role E. A. Kendall, Agent Roles and Role Models

focuses on the position and responsibilities of an object within an overall structure or system. A class is a template or prototype for instantiating individual objects or modules; a role model is a template for instantiating subsystems of interacting modules. Role models are orthogonal and complementary to object models; they do not replace them. Role models also preserve the benefits of object oriented programming because role models are first class objects. This means they can be abstracted, generalized, specialized, aggregated, and instantiated. A role model is very similar to a collaboration diagram in the software engineering standard UML (Unified Modelling Language), which captures object interactions in a scenario or use case. However, a collaboration diagram depicts instances in a particular application; it is not a reusable abstraction. Further, a collaboration diagram is only one perspective; usually it is subordinate to the class diagram. 2.2 Example The example (based on [21]) is a high level view of process management in manufacturing. There are customers and managers, including the plant manager. There are several functional groups: assembly, QA (quality assurance), and a repair shop. Customer

Manager

Functional Group

Assembly Plant Manager

QA

Repair Shop

Figure 1: Class Diagram in UML Notation Figure 1 provides the class diagram in UML, while a collaboration diagram (also in UML) appears in Figure 2. In the class diagram, a triangle indicates inheritance, so the three functional groups shown are subclasses of the class Functional Group. Further, Plant Manager is a subclass of Manager. The solid lines indicate a static relationship, so instances of the Functional Group subclasses have a static relationship with an instance of the Plant Manager class. There are also static relationships between Customer and Manager, and between the Manager and Functional Group classes. aCustomer

aRepairShop 1: newProduct

6: product 3: completedWork

anAssembly

aPlantManager

2: newWork

4: newWork

5: completedWork

Figure 2: Collaboration Diagram in UML Notation E. A. Kendall, Agent Roles and Role Models

aQA

While rich in information content, the class diagram does not depict the interactions between objects; this is addressed in the collaboration diagram in Figure 2. Individual objects (instances of the classes in Figure 1) appear, and they collaborate with each other through messaging. A typical messaging sequence is shown. The sequence begins with a Customer’s request for a new product (1). This leads to messages 2 through 5, where the plant manager delegates work to assembly and then to QA. The product is then delivered to the customer in message 6. The pattern of interaction is clear; all messaging is done through the plant manager. The collaboration depicted in Figure 2 is a pattern of general applicability; it is characteristic of centralized control. In [9] it is called the Mediator pattern; another name for it is the Facilitator. A role model representation of it is shown in Figure 3, where a rounded box is a role, and the solid arrows indicate collaboration paths between the roles. The direction of the arrow represents the direction of messaging, and the solid circle on the link from the Mediator to the Colleague indicates that there is more than one Colleague. The objects in the application (shown as rectangles) play the various roles, as indicated by the dashed arrows. (The notation merges [1] and [23].)

Role Model Client

aCustomer

Mediator

aPlantManager

Colleague aQA aRepairShop

Objects in the Application anAssembly

Figure 3: Role Model for the Mediator Pattern and Role Assignments The full semantics of the role model for the Mediator pattern can be detailed in additional views and notation that are provided in [1] and [19]. The important distinction between the collaboration diagram in Figure 2 and the role model in Figure 3 is that the role model is an abstraction; the collaboration diagram is merely an instantiation of it. 2.3 Role Relationships Once you have a base role model, you can build on it to form more advanced ones. This provides model reuse, and it also helps in conceptual modelling. These are the ways that role models can be synthesized from existing ones: • One role model may be an aggregate of other role models. This may be encapsulated, visible or virtual [16]. • A new role model may be derived from (specialize) one or more base models. In this case, the derived role must be able to play the base role(s). • Individual roles can also be brought together to form role sequences. Sometimes a composite role model is more than just a sum of the parts, and this is called role synergy. An example of this is the Bureaucracy pattern that is documented as a role model in [23] and in Figure 4. This pattern features a chain of responsibility, a multilevel hierarchical organization, and centralized control at every level. This pattern can be constructed by bringing together the Composite, Mediator, Observer, and Chain E. A. Kendall, Agent Roles and Role Models

of Responsibility patterns [9] [22, 23]. The Bureaucracy pattern is formed from multiple Mediators and Colleagues, arranged in a Chain of Responsibility. The Composite pattern appears because a Mediator may in fact represent several Mediators. A Mediator is also an Observer as it monitors activities under its control. A simple combination of the four design patterns results in fourteen roles, as follows: • Handler Client, Handler, Successor, Predecessor, Tail - Chain of Responsibility • Mediator, Colleague - Mediator • Observer, Subject - Observer • Node Client, Node, Parent, Child, Root - Composite However, there are in fact only five roles in the Bureaucracy pattern (Director, Manager, Subordinate, Clerk, and Clerk Client), because some roles are merged. Figure 4 follows the notation of [21] and [23], with a triangle indicating role specialization. For example, Managers and Subordinates must also be Clerks (a customer can deal directly with any entity), and a Director must also be a Manager. Role specialization is similar to inheritance; a more specialized role has added responsibilities and collaborations.

Clerk

ClerkClient Manager

Subordinate

Director Figure 4: Role Model for the Bureaucracy Pattern (based on [23]) The five roles have sophisticated behavior, however, as they must each play several of the lower level roles. They also must be able to switch context as they go from one role to another. The lower level roles are combined as follows: • Director - Root, Tail • Manager - Mediator, Parent, Observer, Predecessor, Successor • Subordinate - Colleague, Subject, Successor, Child, Predecessor • Clerk - Node, Handler • Clerk Client - Node Client, Handler Client 3.0 AGENT ROLES Based on the background material presented in section 2, object roles have the following facets or dimensions: Table 1: Facets of an Object Role context role model services, tasks responsibilities roles it interacts with collaborators access to services external interfaces relationships to other roles aggregation, generalization, refinement, role sequences Due to benefits in modularity, reuse, and portability, object oriented implementations are commonly employed for intelligent agents [4, 12, 18] There are also many patterns and models for intelligent agents that are based on extensions to object oriented techniques [10, 11, 12]. As agents are extensions of objects, they encompass all the E. A. Kendall, Agent Roles and Role Models

features that objects have, adding autonomous, proactive, social, reactive, and intelligent behavior. Therefore, the object role dimensions cited in Table 1 are not sufficient for intelligent agents; there are additional facets that are discussed here. First, an agent role has goals; this is the basis of its proactive and autonomous behavior. Second, expertise or intelligence in a strong agent can include [25] a domain ontology, task models, inferencing, and problem solving knowledge. Third, an agent role often has some degree of adaptability or learning. Additionally, the social behavior of agents can be very rich. At the lowest level, it encompasses a protocol that is often comprised of speech acts. More advanced social behavior in agents involves coordination and negotiation strategies, which may address exception handling and/ or conflict resolution. Further, an agent can have knowledge of why other agent roles are related, and agents may share or exchange ontologies. Research at the University of Toronto [2] has developed a coordination language that defines agent organizations and roles. The agents play roles in the organization, and a role is defined by its major function, permissions, obligations, and interdictions. A role’s permissions include the agents under its authority and its acquaintances. Based on the items summarized here, agent roles add dimensions to those in Table 1, as in Table 2. Agent roles are more multifaceted than object roles; they have more dimensions. During agent role synthesis, these dimensions all need to be considered, and synergy can be ascertained in many ways. Table 2: Facets of an Agent Role context role model services, tasks, goals responsibilities roles it interacts with collaborators access to services external interfaces relationships to other roles aggregation, specialization, generalization, role sequences domain ontology, task models, inferencing, problem expertise solving knowledge a specified protocol, conflict resolution, knowledge of why coordination and other roles are related, share or exchange ontologies, negotiation: obligations, interdictions, permissions learning learning/adaptability 4.0 CATALOG OF AGENT ROLE MODELS 4.1 Motivation A catalog of agent role models is being compiled at BT. Many diverse role models are under investigation, but roles pertinent to workflow and process management are emphasized. The roles in the catalog have been compiled from various sources, including: frameworks [4, 18], FIPA [7], KADS [25], and single function agents [8]. The objectives of this research are the following: • to identify categories or types of roles played by agents. • to investigate the meaning and significance of agent roles and role modelling • to determine the tools and techniques that are needed for agent role modelling • to uncover and document agent role model patterns that can be employed to model and design future agent systems Two excerpts from this catalog are presented in this section; they are both relevant to information and process management. Section 4.2 provides a role model for a contract E. A. Kendall, Agent Roles and Role Models

net, while section 4.3 details a role model for a supply chain. For brevity, the roles are documented here in terms of only two of the facets in Table 2: responsibilities and collaborators; this approach is analogous to CRC cards [3, 5]. Collaboration diagrams are provided; these are for illustration purposes only. A role model instantiation may not exactly follow the message sequence that is shown in the collaboration diagram. 4.2 Contract Net Figure 5 depicts the role model for the Contract Net. At the highest level, there are two roles: CN Manager and CN Participant; there is more than one CN Participant. Both of the high level roles are role sequences. This is indicated in Figure 5b, where the sequences are enclosed in a rounded box, and filled chevrons depict the order of progression. The CN Manager is first a Publisher to the CN Participant’s Subscriber. (This itself is a role model: Publish - Subscribe [5].) After publishing the cfp (call for proposals), the CN Manager becomes a Proposal Manager and then a Client. The CN Participant has two other roles: a Bidder and a Server (Contractor). CN Manager

Publisher CN Manager

Proposal Manager

Client

b.

a. CN Participant CN Participant

Subscriber

Bidder

Server

Figure 5: Contract Net Role Model A sample collaboration diagram is shown in Figure 6, and this is done on a role by role basis. First the Publisher issues the cfp to the Subscribers. The Bidder then considers the proposal (2), and it may refuse it (3a). Alternatively, the Bidder formulates the bid or proposal (3b). The Bidder then proposes the bid to the Proposal Manager (4). The Proposal Manager considers the bid (5) and either accepts it (6a) or rejects it (6b). If the bid is accepted, the Bidder gives way to the Server and the Proposal Manager gives way to the Client. (For brevity, collaborations within the role sequences are not shown.) 5. considerBid

Publisher

6a. reject

3a. refuse

1. cfp

Client

Proposal Manager

Subscriber 2. considerCfp

6b. accept

8. informResult

4. proposeBid

Bidder 3b. formulateBid

Server 7a. doAction

Figure 6: Collaboration Diagram for Contract Net Four of the roles are documented in RRC (Role Responsibility Collaborators) cards that are provided in the tables below. The cards indicate the direction of the message path from the role to the collaborator; they also indicate role sequences. Role: Publisher Responsibilities: Collaborators: maintain registry of subscribers notify subscribers of events > (send message to) Subscriber E. A. Kendall, Agent Roles and Role Models

Role: Subscriber Responsibilities: receive notification pass proposal

Collaborators: < (receive message from) Publisher > (role sequence) Bidder

Role: Bidder Responsibilities: consider cfp forward / send refusal formulate bid forward / propose bid

Collaborators: > (send message to) Proposal Manager > (send message to) Proposal Manager

Role: Proposal Manager Responsibility: Collaborators: consider bid reject unwanted proposals > (send message to) Bidder pass accepted proposal > (role sequence) Client 4.3 Supply Chain A supply chain is another common role model for intelligent agents [2, 18]. A supply chain has suppliers who produce items and consumers who consume them. A consumer can have many suppliers, but a supplier usually only has one consumer in any given supply chain. At the highest level, a supply chain is made up of SC (Supply Chain) Predecessors and SC Successors. A predecessor can have many successors. As shown in the role model in Figure 7, an SC Participant is both a predecessor and a successor, while an SC Head is only a predecessor, and an SC Tail is only a successor. SC Predecessor

SC Head

SC Successor

SC Tail

SC Participant

Figure 7: Top Level Role Model Supply Chain Predecessor Negotiation Initiator

Consumer

Supply Chain Successor Negotiation Partner

Producer

Supplier

Figure 8: Role Sequences There are two phases to a supply chain: negotiation and delivery (Figure 8). An SC Predecessor goes from being a Negotiation Initiator to a Consumer. An SC Successor is first a Negotiation Partner, then a Producer, then a Supplier. During negotiation, the Negotiation Initiator in the predecessor negotiates with the Negotiation Partner in the E. A. Kendall, Agent Roles and Role Models

successor. One collaboration diagram for this part of the Supply Chain role model is in Figure 9; this is followed by he delivery collaboration diagram in Figure 10. 1. request Negotiation Initiator

Negotiation Partner 2a. agree 2b. refuse

Figure 9: Collaboration Diagram for Negotiation Supply Chain Predecessor

Supply Chain Successor

4. deliver

Supplier

Consumer 3. produce

Producer

Figure 10: Collaboration Diagram for Delivery This pattern is repeated for the length of the Supply Chain, as shown in Figures 11 and 12. During negotiation, the pattern commences at the SC Head, and finishes at the SC Tail. During delivery, the opposite is true. Once agreement is reached during negotiation, the delivery phase is entered. Decimal numbering is utilized in Figure 11 to indicate that the SC Head and SC Participant 1 can not finalize their agreement until the entire chain has. (Other variations are common.) SC Head: Negotiation

1. request

SC Participant 1: Negotiation Negotiation Partner

Negotiation Initiator

1.1 request SC Participant2: Negotiation

Negotiation Initiator 2. accept

Negotiation Partner 1.2 accept Negotiation Initiator

Figure 11: Supply Chain Negotiation 6. deliver

SC Participant N: Delivery Supplier

5. performTask

Performer SC Tail: Delivery Consumer

Supplier 4. deliver

Performer

Figure 12: Supply Chain Delivery E. A. Kendall, Agent Roles and Role Models

3. performTask

Figures 11 and 12 reveal that an SC Participant is more than just a SC Predecessor and a SC Successor. Its role sequence differs from the two in Figure 8 and in fact follows this sequence: i) Negotiation Partner, ii) Negotiation Initiator, iii) Negotiation Partner, iv) Consumer, v) Producer, vi) Supplier. Sample RRC Cards for the predecessor and the successor are provided below. The responsibilities on the cards are actually further delegated to the roles in the role sequences, as indicated in the collaboration diagrams. Role: Supply Chain (SC) Predecessor Responsibilities: Collaborators: initiate and complete supply negotiation (send, receive message) SC Successors receive supplies < (receive message from) SC Successors Role: Supply Chain (SC) Successor Responsibilities: complete supply negotiation produce supplies deliver supplies

Collaborators: (receive, send messages) SC Predecessor > (send message to) SC Predecessor

Role: Supply Chain (SC) Participant Responsibilities: Collaborators: complete supply negotiation (receive, send message) SC Predecessor initiate and complete supply negotiation (send, receive message) SC Successors receive supplies < (receive message from) SC Successors produce supplies deliver supplies > (send message to) SC Predecessor 5.0 APPLICATIONS OF INTELLIGENT AGENTS IN PROCESS MANAGEMENT Any application of intelligent agents will in fact encompass many role models. As an illustration, consider a supply chain with a customer and three enterprises. At the highest level, the application can be viewed to be an instantiation of the Supply Chain role model (Figure 7), as in Figure 13. There are four entities that play the roles. The Customer is the SC Head, Enterprise 1 and Enterprise 2 are both SC Participants, and Enterprise 3 is an SC Tail. These distinctions are indicated by the dashed lines in Figure 13, and the small S and P are used to indicate the Successor and Predecessor relationships between neighboring entities. That is, Enterprise 1 is a Successor (S) to the Customer, but it is a Predecessor to Enterprise 2. SC Predecessor SC Successor

SC Head

P

Customer

SC Participant

S

P

S

SC Tail

P

Enterprise1 Enterprise2 Figure 13: Top Level View

E. A. Kendall, Agent Roles and Role Models

S

Enterprise3

Each enterprise is really made up of several entities. For example, Enterprise 1 may in fact be the manufacturing organization in Figure 3. In this case, the role models of Figure 3 and 7 can be merged to yield Figure 14. It is the responsibility of the Plant Manager to be the SC Successor to the Customer, but it is the Assembly functional group that requires input from Enterprise 2, so it is the SC Predecessor in that context. Therefore, the Plant Manager must play all of the roles found in a Supply Chain Successor, in addition to the role of a Mediator. Likewise, the Assembly group must be a Supply Chain Predecessor in addition to satisfying the responsibilities of a Colleague. Both entities must also appropriately address context switching as they go from role to role. SC Predecessor

SC Successor

Mediator

Customer

aPlantManager

SC Predecessor

SC Successor

Colleague

aQA

Enterprise 2

anAssembly aRepairShop Enterprise 1

Figure 14: Mediator with Supply Chain

Section 1 proposed role models for specifying and designing systems that include intelligent agents. Some of the roles in Figure 14 can be played by intelligent agents. A role should be played by an agent if it is to be automated and if it exhibits proactive, autonomous, and social behavior. Other roles should be allocated to people, objects, systems, processes, or organizations. The example here describes an existing supply chain and a given organizational structure. The real value of role modelling, as described in section 1, is in specifying, modelling, and designing new applications. In is anticipated that, as research in agent role modelling progresses, this can be accomplished in the following ways: • Look for patterns: Analysts should first look for patterns in the goal hierarchy diagram. For example, goals and tasks that involve open competitive bidding can be addressed by the Contract Net role model. A chain of goal and task dependencies may match the Supply Chain role model. Other simple role model patterns are provided in [22]; research at BT is documenting further agent role models. • Apply heuristics: If all or some of the goal hierarchy diagram is not covered by known patterns, analysts have to apply general heuristics or rules of thumb for partitioning. For example, [26] proposes high cohesion, low coupling or interdependency, and proximity (keep behavior and information together). • Assign roles: During design, the individual roles are assigned to agents, objects, people, organizations, and processes, as appropriate. 6.0 SUMMARY This paper introduces new abstractions for specifying, modelling, and designing agent based systems: roles and role models. A definition for agent roles has been provided; it adds many dimensions to object roles. Some sample agent roles and role models are


discussed as part of a catalog that is under development. The catalog is being constructed to clarify these concepts and to identify patterns. This work has just begun; it is anticipated that it will provide many benefits for agent based system analysis and design. The approach should be particularly valuable for applications of multiagent systems that involve business information and process management because it represents a unified approach. Agents, objects, and people can play roles and can be incorporated into a role model. New language constructs and new programming techniques are being considered to bring role models to the implementation level. Until these are available, class based object designs and implementations must be used. One promising alternative that is being considered at BT is aspect oriented programming (AOP). Aspects, like role models, are orthogonal to object or component definitions; they cut across the units of a system’s functional decomposition. Research presented in [15] aims at providing language constructs and compilers (called Aspect Weavers) that can interleave component (class) and aspect definitions appropriately to formulate a unified and executable program. The key to the promise of AOP lies in the fact that it directly builds on and extends the power object oriented programming, adding complementary constructs without throwing away the benefits. Similar language constructs and "weavers" may be able to facilitate role based programming for agents [14]. Role model programs could manage a role model instantiation in an application. With AOP, this can potentially be accomplished without overly complex distributed behavior and/ or centralized, monolithic control objects. 7.0 REFERENCES 1. Andersen, E. (Egil), Conceptual Modelling of Objects: A Role Modelling Approach, PhD Thesis, University of Oslo, 1997. 2. Barbuceanu, M., Gray, T., Mankovski, S., "Coordinating with Obligations," Agents ’98, Minneapolis, May, 1998, p. 62 - 69. 3. Beck, K., and W. Cunningham, "A Laboratory for Teaching Object- Oriented Thinking," SIG PLAN Notices, Vol 24, No 10, October, 1989. 4. Bradshaw, J. M., “KAoS: Toward an Industrial-Strength Open Agent Architecture”, Research and Technology, Boeing Information and Support Services, in Bradshaw, J. M., (Ed), Software Agents, AAAI Press/The MIT Press, 1997. 5. Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Pattern- Oriented Software Architecture: A System of Patterns, Wiley, 1996. 6. Chandrasekaran, B., Johnson, T, “Generic Tasks and Task Structures: History, Critique and New Directions”, in Krivine, D., & Simmons, R., (Eds.), Second Generation Expert Systems, Springer Verlag, 1993. 7. Dickinson, I., “Agent Standards”, Agent Technology Group, 1997. http://drogo.cselt.stet.it/fipa. 8. Dunskus B.V, Grecu D.L., Brown .D.C & Berker I. “Using Single Function Agents to Investigate Conflicts”, AI EDAM, Special Issue: Conflict Management in Design, (Ed.) Smith I., Cambridge UP, 1995. 9. Gamma, E.R., R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. 1994: Addison-Wesley.


10. Kendall, E. A., M.T. Malkoun and C.H. Jiang, "The Application of Object-Oriented Analysis to Agent Based Systems", The Report on Object Oriented Analysis and Design / The Journal of Object Oriented Programming, February, 1997. 11. Kendall, E. A., M.T. Malkoun and C.H. Jiang, "Multiagent System Design Based on Object Oriented Patterns", The Report on Object Oriented Analysis and Design in conjunction with The Journal of Object Oriented Programming, June, 1997. 12. Kendall, E. A., P.V. Murali Krishna, Chirag V. Pathak, C.B. Suresh, "Patterns of Intelligent and Mobile Agents," Agents ’98, May, 1998. 13. Kendall, E. A., U. Palanivelan, S. Kalikivayi, "Capturing and Structuring Goals: Analysis Patterns," European Patten Languages of Programming, July, 1998. 14. Kendall, E. A., "Agent Roles and Aspects", ECOOP’98 Workshop on Aspect Oriented Programming, July, 1998. 15. Kiczales, G., J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J. - M. Loingtier, and J. Irwin, "Aspect Oriented Programming," Xerox Corporation, 1997. http://www.parc.xerox.com/spl/projects/aop/ 16. Kristensen, B. B., Osterbye, K., “Object-Oriented Modelling with Roles”, OOIS’95, Proceedings of the 2nd International Conference on Object-Oriented Information Systems, Dublin, Ireland, 1995. 17. Kristensen, B. B., Olsson, J., “Roles & Patterns in Analysis, Design and Implementation”, OOIS’96, Proceedings of the 3rd International Conference on Object-Oriented Information Systems, London, England, 1996. 18. Nwana, H. S., Ndumu, D. T., and Lee, L. C, "ZEUS: An Advanced Tool Kit for Engineering Distributed Multi Agent Systems," Prac. App. Agent Multi- agent Sys (PAAM), (March, 1998), 377 - 391. 19. Reenskaug, T., Wold, P., Lehne, O. A., Working with Objects, The OOram Software Engineering Method, Manning Publications Co, Greenwich, 1996. 20. Reenskaug, T., "Role Modelling Enters the Main Stream," Object EXPERT, January, 1997. 21. Reenskaug, T., "The Four Faces of UML," www.ifi.uio.no/~trygve/documents/, May 18, 1998. 22. Riehle, D., “A Role-Based Design Pattern Catalog of Atomic and Composite Patterns Structured by Pattern Purpose”, Ubilab Technical Report 97.1.1 Zurich, Switzerland: Union Bank of Switzerland, 1997. http://www.riehle.org. 23. Riehle, D., “Composite Design Patterns”, OOPSLA ’97, Proceedings of the 1997 Conference on Object-Oriented Programming Systems, Languages and Applications, ACM Press, Page 218-228, 1997. http://www.riehle.org. 24. Stone, P., and M. Veloso, "Task Decomposition, Dynamic Role Assignment, and Low Bandwidth Communication for Real Time Strategic Teamwork," Artificial Intelligence, 1998. 25. Wielinga, B., G. Schreiber, J. Breuker, "Modelling Expertise," in G. Schreiber, B. Wielinga, J. Breuker (Eds.): KADS: A Principled Approach to Knowledge - Based System Development, 1993. 26. Wirfs- Brock, R., Wilkerson, B., Wiener, L., Designing Object Oriented Software, Prentice Hall, Englewood Cliffs, NJ, 1990.
