Patterns are everywhere. In all fields of our daily life, we use existing patterns to solve recurring problems or we develop new patterns for future use. In most cases, however, we do so subconsciously and are thus not aware of this powerful technique. Although todays software practice has shown that patterns are useful tools, no rationale for the transition from cognitive aspects into software engineering has been provided. Therefore, I will take a short detour to cognitive science at the beginning of this paper and discuss some mental aspects that are involved in using and developing solutions for recurring problems. We will, however, not completely ignore computer science aspects but instead explain the effects of the cognitive mechanisms that are introduced on computer programming and software engineering. The following paragraphs are an excerpt from the document Cognitive Aspects of Software Engineering.
First of all, we need a model of the human memory such that we can establish
a link between the abstractions on the cognitive level and those on the domain
level. According to (Anderson, 1983), the human memory is organized in hierarchical
levels of abstraction using so-called cognitive units as the building
blocks. Whereas the knowledge on low levels of abstraction is represented
with little abstraction from the pure sensory impressions, knowledge on higher
levels of abstraction uses a more complex representation: schemata.
Schemata are cognitive units with a rich internal structure (Detienne, 1990)
that consists of several slots (variables) that can be instantiated
with slot fillers (values). Partially instantiated schemata are prototypes
for a particular concept, fully instantiated schemata are exemplars
of this prototype. These exemplars can be ordered according to their semantic
distance to their common prototype (Spada, 1990). In the software engineering
domain, schemata can be classified according to three different classes (Detienne,
1990): programming schemata, application domain schemata and
discourse schemata.
Programming schemata are either variable plans or control-flow plans. A variable plan, for example, contains the semantic knowledge about the concept of a counter variable that is used in loops and a typical control-flow plan is the programmers knowledge about the general process of iterating over list of arbitrary elements. In a real program, the software engineer will need both schemata (amongst others) to implement a concrete function e.g. to sum up a list of integer values. Application domain schemata represent the engineers background knowledge about the application domain. It is a crucial task in the software engineering process to match the application domain knowledge and the programming g domain knowledge in order to develop or to understand a software system for the application domain.
Discourse schemata, finally, enable the software engineer to reason and communicate
about programs besides functional aspects. These schemata include knowledge
about general principles and conventions such as the convention that a variable
should reflect its function or that particular variable names are used for
certain tasks (e.g. i and j are typical variable
names for loop variables). For larger units of knowledge with many different
interrelationships, schemata are not suited because of their rather descriptive
nature. A more dynamic approach to the representation of large-scale cognitive
units are mental models (Johnson-Laird, 1983). These mental models
contain declarative and procedural knowledge about a well-defined field and
are often individualized scientific theories, e.g. about electricity (Spada,
1990). Humans usually maintain a wide variety of these mental models and construct
new models on demand, e.g. in the process of understanding the behavior of
a complex system. The newly created models must be consistent with the existing
models because these are resistant against changes and can only be revised
with a certain learning effort (Spada, 1990).
The schemata discussed in the previous paragraphs are purely cognitive structures
that normally have no external representation. To make the knowledge that
is captured in the schemata available for re-use, we thus need a mechanisms
to externalize the contained knowledge. Enter patterns.
Generally speaking, a pattern is a general solution to a specific recurring
design problem. It explains the insight and good practices that have evolved
to solve the problem and it provides a concise definition of common elements,
context, and essential requirements for a solution. Patterns were first used
in (Alexander, 1979) to describe constellations of structural elements in
buildings and towns. In (Lind, 2001b), I have argued that software design
is a general design task in that it is concerned with arranging a collection
of primitive elements according to a given design language in order to achieve
a particular goal (Grenno, 1988). Examples for general design tasks can be
found in technical disciplines such as architectural design or electrical
circuit design, but also in cultural areas, e.g. in music composition or in
writing an essay. Thus, design tasks are complex tasks that entail multiple
subtasks that draw on different knowledge domains and a variety of cognitive
processes (Pennington, 1990). Although these subjects appear to be rather
different in their nature, they nonetheless share two fundamental activities
that are exercised during the overall design process (Pennington,1990). The
first general aspect is composition, i.e. the process of developing
a design by describing associations between the structural elements of the
design. In terms of a software engineering process, this step maps what
a program should achieve onto a detailed set of instructions that specify
how these requirements are implemented in a particular programming
language. The second, and equally important aspect, is comprehension.
Comprehension means to take a particular design and to understand the associations
between its structural elements. The input for this process may be a design
that was produced by a third party, but often it is a design that was developed
by the same person. Now, why should it be necessary for a designer to understand
something that he or she has developed? Simply because it is almost impossible
to anticipate all implicit relations that are introduced as side-effects of
one explicit design decision. For example, creating a new function for a particular
purpose may have the side-effect that other, already existing functions can
be simplified by using the newly created function. For the software engineer,
the process of understanding a design is to map how a program implements
a specification to what this specification entails. The most important
property of general design tasks is the evolutionary nature of the entire
process. The design process is not sequential in that it proceeds from one
intermediate product to the next until the design is completed, Rather, the
process involves frequent revisions of previous decisions, re-structuring
of the design elements or exploration of tentative solutions for particular
sub-problems. Therefore, the design process often starts with constructing
a kernel solution and then incrementally extending this solution until it
meets the initial requirements (Kant, 1984) (Ratcliffe, 1985). In software
development, the kernel solution is often retrieved by re-using existing code
fragments and the applying a series of repeated modifications to these fragments
until the target system is constructed (Green, 1990).
In this section, I have provided a general outline for why patterns are a
suitable tool in software development as they are general solutions for recurring
design patterns and software development is a general design task. Now, we
will come to the main part of this paper and discuss the potential use of
software patterns for intelligent agents and multiagent systems. We will start
with a review of existing approaches in patterns in general and agent patterns
in particular before we turn to the development of a patterns catalog structure
for agent-oriented patterns. Then, I will propose a pattern description scheme
that can be used for agent patterns and I will subsequently provide some brief
examples on how the pattern description scheme can be used in practice.
Several templates for software design patterns have been developed. The first attempt to bring the idea of software patterns into the broad public was undertaken by the "Gang of Four" (GoF) (Gamma, 1994). Their template is used for patterns that describe constellations of classes that solve common software design problems of relatively small scope. A similar approach is taken by a group of Siemens employees (Buschmann, 1996) who also provide a section. that discusses component structures of relatively large scope. What is common to these two approaches is the fact that they deal with very general problems that are to be found in almost any (sufficiently large) software system. In their second volume (Schmidt, 2000), the Siemens people therefore deal with patterns for large scale problems in greater detail.The idea of Software Architecture as a field of software development that can specifically benefit from a pattern oriented approach is also discussed in (Shaw, 1995). Due to the great success of the early attempts to semi-formalize the description of software patterns, international conferences are conducted every year to enhance the information interchange in the pattern community; the best known of these conferences is the (PLoP).
Bringing together agents and other fields of software engineering might be difficult as the advantages of agent technology are still not widely recognized. In (daSilva98), for example, the entire agent approach is presented as a singular patterns among others. Clearly, this view on agents is much too limited and coarse grained and more elaborate pattern schemata for agents are necessary. In the agent world itself, several attempts to introduce patterns and pattern languages have been made. In (Kendall, 1997), for example, a concrete pattern for layered agent architectures is presented using am ad-hoc pattern description scheme and without providing and outline for the organization of a agent-oriented pattern catalog. Similarly, (Wooldridge, 1998a) provides a collection of best practices but without adhering to a particular description scheme. In (Kendall, 1998a) and (Kendall, 1998b), a large collection of agent interaction schemata and generic role models is presented where each role and its relations to other roles are expressed in terms of CRC cards. Further approaches to introducing patterns into the agent world are to be found in (Aridor, 1998) or (Yasuyuki, 1999); an interesting approach for using agent patterns in a real world scenario is described in (Knublauch2001). In summary, however, one must clearly admit that the idea of developing a standardized pattern catalog for agent-based systems has not been investigated in depth and that such an attempt is necessary in order to advance the development of agent-based applications.
The first problem in developing a pattern catalog for software patterns is to find an adequate structure of this catalog such that the patterns are grouped together in meaningful categories. In (Gamma, 1994), for example, the patterns that are discussed are classified into three classes: creational patterns deal with object creation, structural patterns describe the composition of classes and objects and behavioral patterns, finally, capture interaction between classes and objects. The approach taken in (Buschmann, 1996) differentiates between three categories of patterns: architectural patterns, design patterns and idioms. Architectural patterns describe fundamental structural organization schemata for software systems; this structure contains a set or predefined subsystems with well-defined responsibilities and it includes rules and guidelines for organizing the relationships between them. Design patterns, on the other hand, are schemata for refining subsystems or components or the relations between them. These patterns describe commonly recurring communication structures that solve general design problems within a particular context. Idioms, finally, are low-level patterns specific to a particular programming language. Idioms describe how particular aspects of a pattern are implemented in that language.
For agent patterns, I suggest using a catalog structure that follows the view oriented approach presented in (Lind, 2001b). The views that are introduced there are used to model the entire system from different perspectives where each of these perspectives captures a set of related aspects. The views that are proposed are as follows:
The advantage of using this collection of views as the categories of the agent patterns is that it adheres to a decomposition of the target software system that has shown to be quite effective in developing agent-based applications (Lind, 2001b). Still, the above collection of views should serve solely as a starting point as it is not yet clear whether a sufficient number of patterns can be found for each view. If it is difficult to find patterns for a particular view, the best idea is probably to abandon the respective view as a pattern category as it may be too volatile. A sufficient degree of stability is a prerequisite for successful pattern extraction.
Pattern description schemata are collections of aspects that, when taken together, fully capture a software pattern. The major advantage of such schemata is that they introduces a structured way to understand, explain and reason about patterns. Furthermore, they allows for a more effective communication among software engineers because a particular pattern description scheme provides the language to talk about patterns. In the existing literature, several general purpose schemata have been proposed; in the appendix, I have briefly summarized two of them. As we can see, these two schemata are rather similar, suggesting that there might exist something as a "canonical" scheme that an be used for different pattern catalogs.
As valuable as the schemata summarized in the appendix are, I do not think that a single, general pattern description scheme is adequate for all categories of patterns, simply because it is too general. Furthermore, I also believe that pattern schemata for agents must be more complex than "normal" patterns because the usually deal with problems of coarser granularity. Therefore, I suggest to split up the pattern description scheme into two parts: a general part that deals with the generic properties of a pattern and a view-specific part that handles those aspects that are characteristic for the view the pattern belongs to two. In the following table, I have summarized the resulting scheme, the view specific aspects will extend the last point mentioned there.
| Name | A crisp name that captures the essential idea underlying the pattern. |
| Aliases, also known as | |
| Problem | What problem is solved by the pattern? |
| Forces | Which aspects of the problem are the forces that led to the development of the pattern? What are the prerequisites for using the pattern? |
| Entities | The entities that participate in the pattern. The name of the slot is chosen to avoid technical terms such as "class" or "object" to avoid a premature limitation on a particular implementation. |
| Dynamics | How do the entities of the pattern collaborate to achieve their goal? |
| Dependencies | Does the pattern require any specific environment before it can be applied? |
| Example | A simple, abstracted example for how to use the pattern. |
| Implementation | Hints or large scale examples on how the pattern may be implemented. |
| Known Uses | Examples of systems where the pattern has been applied successfully. |
| Consequences | What are the consequences of using the pattern? Does the pattern determine design decisions in other places of the system? |
| See Also | References to other patterns that solve similar problems or that can be beneficially combined with this pattern. Also, where are potential conflicts with other patterns |
| View category specific fields | Additional fields that are specific for a particular category and that do not make sense for other categories. |
In this section, I will demonstrate how the pattern description scheme from Table \ref{massive} can be used for agent-oriented software patterns. Due to the limited space, however, I shall restrict myself to some introductory remarks only.
The first example that we will discuss in this section stems from the architecture view and deals with the agent architecture. According to (Lind, 2001b), the agent architecture defines a structural model of the components that constitute an agent as well as the interconnections of these components together with a computational model that implements the basic capabilities of the agent. In addition to the general purpose pattern fields, we will use the following view-specific fields that are used to capture the characteristics of a particular agent architecture.
We will no see a concrete example on how this scheme can be used to describe a particular agent architecture pattern. I have chosen the InteRRaP architecture as presented in (Mueller, 1996a) because it is well documented and therefore the pattern description scheme can be applied easily. Obviously, though, a complex thing such as a generic agent architecture requires a lot more space then that available in this paper. Therefore, the following paragraphs are solely intended to demonstrate how one might start with a pattern that captures the InteRRaP architecture; this is illustrated by the dots that appear in almost any field.
Behavior Based Layer (BBL) This layer implements the reactive behavior of the agent, i.e. this layer reacts to external requirements without any explicit reasoning, thus it reacts very fast.
Local Planning Layer (LPL) This layer performs the planning process of an individual agent, it is also responsible to monitor the plan execution of the agents current plan.
Social Planning Layer (SPL) This layer is responsible for the coordination with the other agents within a multiagent system. The coordination with the other agents is achieved with explicit negotiation protocols.
These layers mainly serve two purposes. First, the represent different functionalities that compete for the resources of the agent. Second, the layering allows for better conceptual abstractions in terms of the agents knowledge representation and by restricting access to particular pieces of information to a particular layer.The second example that we will discuss in this section are patterns for the interaction view. Here, we have the situation that the most important view-specific aspects of an interaction pattern are already covered in the part of the pattern description that deals with general aspects. These parts are the roles, the messages and the temporal ordering of the message exchange. In the general description scheme, the roles and the messages can be discussed in the "entities" section and the temporal ordering of the messages is part of the "dynamics" of the pattern. However, in order to point out the specific meanings of the three major concepts, I think it is a better idea to remove the fields from the general part of the description scheme and to add the three new fields to the view-specific part. That way, the special semantics of the filed names are emphasized.
To demonstrate how a concrete interaction protocol pattern might look, we will now briefly present a pattern description for the well-known Contract-net protocol as introduced in (Smith,1980). Remember that the following paragraphs serve as example only and therefore, the field contents contain introductory aspects only. Furthermore, we will only consider the simple Contract-net variant without task refinements etc.
Software pattern have shown to be useful tools in many areas of software development; in this paper, a starting point for introducing patterns into agent-oriented software engineering has been presented. The approach integrates with the MASSIVE method but it is not limited to that particular development method. The basic idea that was discussed is to develop a pattern catalog that is structured according to the view-oriented decomposition of the final system as it is suggested in the MASSIVEmethod.
In forthcoming research, the suggested view system must be evaluated for its usefulness as a pattern catalog structure and the pattern description scheme must be analyzed with respect to its adequacy for capturing all relevant aspects of agent patterns. The most important task, however, is to start to collect agent patterns and to make them widely available.
In (Gamma et al., 94) a design pattern is described using the fields shown in the following table.
| Pattern Name | A good name is vital, because it will become part of your design vocabulary. |
| Intent | What does the design pattern do? What is its rationale and intend? What particular design issue or problem does it address? |
| Also Known As | Other well known names for the pattern, if any. |
| Motivation | A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem. The scenario will help you to unerstand the more abstract description of the pattern. |
| Applicability | What are the situations in which the design pattern can be applied? What are examples of poor designs that the pattern can address? How can you recognize these situations? |
| Structure | A graphical representation of the classes in the pattern (OMT). |
| Participants | The classes and or objects in the design pattern and their responsibilities. |
| Collaborations | How do the participants collaborate to carry out their responsibilities. |
| Consequences | How does the pattern support its objectives? What are the trade-offs and results of using the pattern? What aspect of the system structure does it let you vary independently? |
| Implementation | What pitfalls, hints or techniques should you be aware of when implementing the pattern? Are there language specific issues? |
| Sample Code | Code fragments that illustrate how you might implement the pattern in a particular language (C++) |
| Known Uses | Example of the pattern found in real systems. Preferably several (at least two) examples from different domains. |
| Related Patterns | What design patterns are closely related to this one? What are the important differences? With which of the other patterns should this one be used? |
(Buschmann et al. 1996) use the fields shown in next table.
| Name | The name and a short summary. |
| Also Known As | Other names, if any. |
| Example | A real world example that demonstrates the existinence of the problem and the need for the pattern. |
| Context | The situations in which the pattern may apply. |
| Problem | The problem the pattern addresses, including a discussion ofthe associated forces. |
| Solution | The fundamental solution principle underlying the pattern. |
| Structure | A detailed specification of the structural aspects of the pattern (OMT). |
| Dynamics | Typical scenarios describing the run-time behavior of the pattern. |
| Implementation | Guidelines for implementing the pattern. |
| Example Resolved | Discussion of any important asepcts resolving the example that are not covered elsewhere. |
| Variants | A brief description of variants or specializations of a pattern. |
| Known Uses | Examples of the use of the pattern, taken from exsiting systems. |
| Consequences | The benefits the pattern provides, and any potential liabilities. |
| See Also | References to patterns that solve similar problems and to patterns that help us refine the pattern we are describing. |