The Genesis of a Pattern Language for Agent-based Enterprise Systems

Paul R Taylor Peter Evans-Greenwood James Odell Agentis International

233 Lincoln Square South Carlton Victoria Australia 26405 Lexington Avenue New York NY USA

ptaylor|pevansg|jodellagentisnet

Abstract Patterns have recognised utility in software engineering design and development processes The body of knowledge of design and development of agent-based systems is now sufficiently mature to be usefully expressed as a pattern language The essential elements of agent-based decompositionmdashautonomous agents relationships between agents and organisational structuresmdashlend themselves to a pattern-based description This paper describes an initiative currently underway at Agentis Software to mine document and evolve a complete pattern language for agent-based systems These patterns define recurring agent-based structures for both individual agents and multi-agent system architectures This paper discusses the software engineering motivations for making this investment in patterns by describing the strategic and pragmatic motivations the pattern mining process how the patterns are used in the design of agent-based solution architectures and our experiences in using and evolving the pattern language

1 Introduction

A process for mining reviewing and disseminating agent-based design patterns has been operating at Agentis Software for over a year The patterns that have resulted embody significant knowledge of the design of agent-based software architectures individual agents and agent-oriented coding idioms and mechanisms within agents The pattern languagemdashthough still relatively immaturemdashis changing the way agent systems are being designed We believe that its use will increase software design and code quality and introduce a degree of repeatability in the delivery of agent-based systems and we suggest that patterns represent a highly viable and

pragmatic way of introducing sound software engineering principles into the development of enterprise agent systems

The concepts underlying software patterns need little introduction but the motivations for choosing to write patterns (as opposed to using existing patterns) and the justification of the return on this investment are worthy of discussion Creation of a pattern language is not something to be taken lightlymdashproposers of such an initiative must have a mandate and clear support from their community of practice For a toolkit vendor (such as Agentis) this support must include a strategic commitment to open up the pattern language and its associated code resources to the wider Agentis development community and to provide a guarantee of platform support for the patterns

11 Motivations for creating a pattern language

Patterns express recurring software designs using a standard literary template that serves to externalise the motivations tradeoffs and final resolutions of the expert designer Patterns mature merge and diverge as richer experience illuminates more agent-oriented solutions and as more patterns are documented In time a repository of patterns becomes a design vocabularymdasha languagemdashin which novices and experts can converse short-circuiting the monotony of traditional models of mentoring and craftsmanship and ensuring higher quality designs get done faster and without unnecessary re-invention As individual patterns mature their interdependence increases and the overall strength of a pattern language emerges

Architecting well-designed extensible scalable agent-based solutions is a job for a technology expert Agentisrsquo product offering is typical of productivity platforms in that it incorporates quality documentation training and other collateral However these are not enough to engender expertise

16

Figure 1 The role of patterns in the knowledge spiral

The scarcity of agent solution design expertise

presents a classic knowledge management challengemdashhow should the essential expertise necessary to successfully design and develop agent-based systems and solutions be explicated and shared The very nature of this expertise works against us to begin with

The best (and most experienced) architects employ their combined knowledge of agent concepts design expertise and platform awareness both explicitly and tacitly They are no different to conventional software architects or architects of built-world structures in the ways they reuse certain template solutions and building blocksmdashand particular arrangements of these building blocksmdashin the conceptualisation of their designs Architectural theorist Christopher Alexander calls these blocks and template structures lsquopatternsrsquo and regards all of the great architects of history as having internalised lsquopattern languagesrsquo of our own from which we arrange our personal spaces and form our own designs lsquoWhen a person is faced with an act of designrsquo writes Alexander [1] lsquowhat he does is governed entirely by the pattern language which he has in his mind at the momentrsquo (p203)

To become an effective agent solution designer an experienced solution architect must learn how to use goal-directed BDI agent technology appropriately The recipes for how best to do this are only just emerging from the Agentis development community At this stage of the technologyrsquos adoption it is crucial that ways of sharing these lsquoprivate rules of thumbrsquo of the most experienced designers are found surfaced expressed in a suitable form reviewed for soundness and shared via a suitable medium Figure 1 from May and Taylorrsquos description of patterns as a knowledge management process [4] illustrates how explication of tacit knowledge (as patterns) ultimately enriches the practitionerrsquos explicit and then over time tacit knowledge in a transparent cycle of learning

12 Patterns and risk mitigation There are other pragmatic motivations for an

investment in an agent pattern language Before organisations adopt a new enterprise software technology every possible impediment must be eliminated To this end Agentis has invested in a number of lsquobridgesrsquo between established enterprise software engineering approaches and agent technology One is an import capability in the Agentis product that allows representations of UML business models to be imported into Agentisrsquo agent modelling environment Another is a small set of extensions to UML to support the translation of roles into role-based agent modules We regard the agent pattern language as another lsquobridgersquo Enterprise developers require access to a body of patterns to develop confidence in the new development approach Patterns as proven lsquobest practicersquo solutions mitigate project architecture and design risk The pattern language along with a supporting software component repository integration with the methodology training experience reports and case studies are offered as a complete solution offering It is also critically important that ownership of the pattern language sit with the community of practice rather then with a vendor

13 Patterns and agent-based decomposition Agent technology provides an alternative basis for

solution decomposition When experienced agent-based system architects design they apply this decomposition method to create viable solution models comprised of agents and roles Anthropomorphic approaches such as these appear to have application in complex enterprise systems as evidenced by the growing body of case studies [2]

In making a case for agent-oriented software engineering Jennings [3] claims the essential characteristics of agent-based systems are i) modelling with agents interactions and organizations ii)

26

decomposing the problem into multiple autonomous agents that can act and interact in flexible ways to achieve their objectives and iii) using explicit structures protocols and mechanisms to manage the complex and changing web of organizational relationships that exist among the agents Designing in this fashion is clearly not trivialmdashin simple terms the design of multi-agent systems parallels the design of object-oriented systems but adds a new degree of dynamism to the dimensions of individual agent behaviours and the inter-agent relationships Most decisionsmdashincluding the exact configuration of the collaborating entitiesmdashare deferred until runtime which leads to new levels of non-determinism The designerrsquos method and personal design processes do not yield to naiumlve stories that may have worked with object-oriented decompositions Neither are lsquodivide-and-conquerrsquo-based iterative decomposition techniques sufficiently rich to address these characteristics of agent-based solutions While the emerging plethora of agent methodologies are now beyond their infancy verification depends upon a large base of reported verifiable experience

As this will take some years to materialize patterns provide a sound theory and practical methodology to iteratively capture refine and validate these structures As well patterns are essentially about structure Experience from object-oriented systems development serves to validate the use of patterns in documenting agent code-level structures structures of inter-agent relationships and agent organisations We have tried to document patterns for our agent platform in all three spaces

Figure 2 A category map of agent patterns

2 Our Approach

The Agentis pattern language was created by an immersive activity to mine and author the most

fundamental architectural design and code patterns which resulted in a core of 17 patterns To structure the effort in selecting candidate patterns the agent solution space was categorised on the basis of conventional enterprise architecture abstraction layers

21 Pattern categories The pattern language is structured around three

categories architectural patterns which recommend structural solutions to problems at the level of system and agent architectures design patterns which solve common design problems within an agent and tactical patterns which offer pragmatic solutions to everyday problems when working with the platform

These categories can be thought of as horizontal layers with tactical patterns at the bottom (since these patterns extend the agent development platform) agent design patterns and agent-architectural patterns at the top (since they address the most abstract system-level structures) Within these layers particularly the architecture and design layers a further classification into business process functional design and data and integration patterns can be made (Figure 2) This grid serves two purposes Firstly it provides a way of locating and relating a candidate pattern to the existing solution design space Secondly it orientates the designer in locating a pattern needed to solve a particular problem The layering should not be taken to imply that the patterns in the Agent Architectural layer are abstractmdashthey are just as concrete in their problem and solution definitions as are the tactical patternsmdashthe

distinction is purely that they address the kinds of problems encountered when designing agent-based systems compared with designing modules goal hierarchies goals or plans

Tactical patterns are similar to Java or C++ coding idioms and are heavily dependent on the realisation of core BDI concepts in the agent-modelling platform Most of these patterns describe lsquobest practicersquo approaches to achieving some desirable

characteristic in an agent Examples include idioms to implement abstraction encapsulation and data homogenisation or manipulation Tactical patterns are supported with a reference implementation (code sample) which can be cloned and reused Because this category of patterns is closest to the agent development

36

platform it immediately began to attract local lsquowork-aroundsrsquo for unimplemented platform feature requests The resulting patterns provided valuable planning and prioritisation input to the productrsquos roadmap Over time we expect some of these patterns to be subsumed into the Agentis product

Agent design patterns sit at the next higher level of abstraction and describe agent-based realisations of many of the building blocks of enterprise applicationsmdashsmart caches filters intelligent data structures for example These are accompanied by a reference implementation in the patterns repository that an agent developer can copy and easily reuse The developer typically designs with these patterns and merges the reference implementations in appropriate ways

Patterns of agent-oriented system architecture sit at the next level of abstraction in the solution space These include agent-based realisations of system-level constructs that are applicable both within individual agents (roles layers and facades for example) and between agents in a multi-agent system (observers and brokers for example)

The pattern-mining effort does not stop there As experience in developing agent-based solutions accumulates in particular markets or business domains recurring solution structures are identified and clusters of patterns are mined within specific solution domains Work has commenced on workflow real time business exception handling and rule interpretation solution domains as well as in vertical markets such as insurance underwriting These pattern clusters and their template code modules approach the utility of small self-contained frameworks which designers combine and extend to design agent architectures and assemble agent solutions

22 Sample patterns Two short-form samples (Figure 3) from the language

illustrate the approach to individual patterns Note that these are greatly summarisedmdashthe actual patterns include full implementation details and discussions of considerations and optimisations (they run to 6 and 11 pages respectively)

The RULE COMPOSER pattern makes many assumptions about the best way to model business rules By recommending a rule equals goalrsquo approach the patternrsquos solution emphasises rule encapsulation and opens the door to a broader notion of rule as goal-directed rule The patternrsquos final solution captures the preferred option When less experienced developers implement a RULE COMPOSER the pattern guides them away from these pitfalls Individual patterns live or die on their usefulnessmdashif the patternrsquos solution is impractical unworkable or involves some form of unacceptable

compromise it will not be used Patterns to survive into maturity have to be firmly grounded in practical experience

Another sample pattern (Figure 3 right) from the language illustrates the architectural layer The DECISION TREE is a framework that executes within an agent to control a question-and-answer dialogue with the applicationrsquos user As the user responds to questions (prompts) their answers are passed to the DECISION TREE for interpretation and navigation

The DECISION TREE selects the appropriate sub-tree based on the userrsquos response and also optionally invokes application-specific behaviour in the agent at each node of the tree by delegating the userrsquos responses to an lsquoactionrsquo goal Inside this goal any application-specific behaviours can be implemented to invoke goal-directed processing at each node in the tree For example an agent could accumulate the userrsquos answers perform partial processing on them or retrieve information from external systems to inform the user about the current state of the dialogue Traversal of the DECISION TREE completes when it reaches a leaf node at which time the final action goal can complete any calculations and return the results

DECISION TREES can be nested composed or assembled dynamically to support arbitrarily complex dialogues It is typical of the patterns found in the Agent Architectural dimension of the pattern language in that it represents an architectural response to a class of recurring agent solutions Its sample implementation in the pattern repository includes Agentis agent modules Java source and sample database schema With repeated reuse this architectural pattern will mature into a solution component as unit test harnesses test data generalisation for different databases and deployment options and code to support configuration are all added

23 Designing with patterns The agent pattern language puts new nouns in the

agent solution designerrsquos vocabulary It is not difficult to anticipate how knowledge of several dozen such patterns changes the way an architect thinks about discusses and documents solutions The highest level of decomposition into agents roles and relationship structures can be expressed with patterns of multi-agent organisations There is scope to enrich our pattern language in this dimension mainly because there are fewer opportunities to repeatedly discover and validate these patterns in the domain of enterprise application development Even within solutions that require only relatively static organisations of agents we have valuable experience in using loosely coupled multi-agent structures Within individual agents the language is richest

46

Name RULE COMPOSER Context You are implementing goal-based data or form validation within an agent

Problem You have lots of interdependent validation rules that must be applied during a business process

Forces There are many validation scheduling sequencing and selection scenarios where you need to apply a number of business rules against a business data structure A naive approach might be to combine the individual validation rules into a single logical expression This approach restricts the ways you can implement the rules to those expressions and creates a maintenance problem because of the complexity of the composed usage rules A more flexible approach is to think of each individual business rule as a goal Rules can run the full range of complexity from a simple expression implemented in a usage rule for one of the goalrsquos plans to a complex decision making process implemented with multiple plans and sub-goals It also strongly encapsulates the implementation of the rule so that its evolution and change over time will not impact other parts of the agent The validation is then done by composing the individual business rules (goals) under a common validation goal which provides simple rule composition

Solution Encapsulate a number of (possibly interdependent) business validation rules behind a single validation goal (the RULE COMPOSER goal) which manages the interdependencies ensures that all the appropriate validation rules are executed regardless of their outcomes and reports on the overall result ltlt implementation details omitted gtgt

Consequences ltlt note on a disjunctive variant gtgt ltlt note on an audit trail gtgt ltlt note on the definition of lsquorulersquogtgt

Name DECISION TREE Context You are implementing an agent-based self-service web application

Problem You want to guide the user through a sequence of decisions but you want the agent to control the dialogue

Forces In some web applications navigation is dependent upon what interactions or data have been provided previously As more information is collected from the user the application makes informed decisions about narrowing or customising the presentation of options In an agent-based system you want a user interface agent controlling the user dialogue You need to represent a hierarchy of dependent navigation or business rules so that the agent can control the dialog with the user and resolve to a set of recommendations options or product offerings or calculation of results

Solution Use a DECISION TREE (a tree with decision and action metadata on each node) that represents all possible dialog paths and corresponding action sequences Each node in the tree represents a question presented to the usermdasha decision point Each time the user answers a question the DECISION TREE collects the supplied answer(s) delegates the userrsquos responses to an application-specific action and selects the appropriate sub-tree progressing toward the leaf node When the leaf node is reached the DECISION TREE invokes whatever final calculations the agent needs to perform on the set of attributes collected during the traversal and returns the result The user can then re-visit any of the nodes in the current tree initiate a new dialogue with a different instance of the same DECISION TREE (in parallel if this makes sense) or initiate a dialogue with another supported DECISION TREE ltlt implementation details omitted gtgt

Consequences I ltlt note on asymmetric trees gtgt ltlt note on instantiating multiple trees gtgt ltlt note on data-driven trees gtgt ltlt note on cycles gtgt ltlt note on localisation considerations gtgt

Figure 3 Some indicative (short-form) patterns from the language

24 A pattern lifecycle model Architects and developers use existing patterns and

components during development of an agent-based

solution In her work the reflective architect will likely uncover potentially useful new patterns Candidate patterns should not be written up immediatelymdashthe idea needs to be lsquofloatedrsquo for a period so that others in the

56

community can review it and so that its proposer can re-think and re-conceptualise it lsquoPatletsrsquo exist to support this early phase of a patternrsquos existence

A patlet is a cut-down pattern that states a name the problem some (optional) bullet-pointed forces and the solution It can be as simple or as detailed as the author desires The patlet sits on a shared portal and collects comments It takes three seconders from the community to justify creation of a pattern from a patlet When this happens the patlet (with the review input from its seconders) is formally prototyped using the agent platform and written up using the standard pattern template The new pattern is published and indexed but it stays in lsquoDraftrsquo state

The new draft pattern now surfaces in the pattern repository Users and reviewers accumulate comments and feedback which will quickly indicate its usefulness or otherwise When three instances of the patternrsquos use have been recorded it transitions from lsquoDraftrsquo to lsquoFinalrsquo state A patternrsquos state is therefore the best indication of its maturity

A pattern in Final state may ultimately be retired or merged with other patterns as the agent platform changes Patlets and patterns are never explicitly deleted as the life history of a pattern traces the progression of design thinking about a particular problem and its solutions

3 Brief Assessment

The pattern language has found an enthusiastic audience amongst Agentis consultants partners and clients Patterns are being used sample implementations reused and feedback is accumulating on a shared services portal Judging from feedback the decision to aim the pattern language at enterprise Java developers has been vindicatedmdashso much so that the pattern language is being used to support technical pre-sales activities a benefit not anticipated

In general we have found that the patterns are larger (in terms of the number of participating elements the description and the reference implementation) and more complex than lsquotraditionalrsquo object-oriented patterns DECISION TREE is a good example of this This may be due to our definition of patternmdashan OO traditionalist for example might argue that DECISION TREE is conceptually a component rather than a pattern Our definition is driven by achieving productivity through efficient reuse of the reference implementation by project team members

Integration of the language with the Agentis product roadmap is tight and as new features are planned for release patterns must be updated Pattern use is now a valuable input to roadmap planning

4 Conclusion

A process of pattern mining review use and evolution has been established at Agentis Software specifically to explicate agent-based system design and implementation knowledge The motivations for this effort include the acceleration of skilling agent technology solution architects and risk mitigation on the part of technology adopters Patterns are regarded as an excellent medium for representing agent-based designs due to the inherent structural basis of agentndashbased decomposition

The Agentis pattern language is organised around three abstraction layers and three functional layers Individual patterns within each grid square include a comprehensive sample implementation and repository artefacts to facilitate immediate reuse and customisation Designing with agent-based patterns is essentially familiar to object-oriented design pattern users but involves added design dimensions of runtime structure negotiation and adaptability for which some early patterns are emerging

A healthy pattern authoring and reviewing process reflects the health of a software engineering community of practice Ultimately the target of any pattern initiative should equally be the well being and longevity of the pattern mining process as well as the language itself The activities of proposing authoring reviewing and publishing patterns need to become embedded in the communityrsquos culture such that designers are able to pick up (and cut back) their involvement in pattern development as their interests or other workloads allow

5 References

[1] Alexander Christopher 1979 ldquoThe Timeless Way of Buildingrdquo New York Oxford University Press [2] Taylor Paul Evans-Greenwood Peter Odell James ldquoAgents in the Enterpriserdquo Industry Track Proceedings Australian Software Engineering Conference (ASWEC 2005) 29th March - 1st April 2005 Brisbane Australia [3] Jennings Nicholas R Bussmann Stefan ldquoAgent-Based Control Systems Why Are They Suited To Engineering Complex Systemsrdquo IEEE Control Systems Magazine June 2003 [4] May Daniel Taylor Paul 2003 ldquoPatterns and Knowledge Managementrdquo Communications of the ACM July 2003 Vol 46 No 7 p94-99

66

• Introduction
• • Motivations for creating a pattern language
  • Patterns and risk mitigation
  • Patterns and agent-based decomposition
  • • Our Approach
    • • Pattern categories
      • Sample patterns
      • Designing with patterns
      • A pattern lifecycle model
      • • Brief Assessment
        • Conclusion
        • References

decomposing the problem into multiple autonomous agents that can act and interact in flexible ways to achieve their objectives and iii) using explicit structures protocols and mechanisms to manage the complex and changing web of organizational relationships that exist among the agents Designing in this fashion is clearly not trivialmdashin simple terms the design of multi-agent systems parallels the design of object-oriented systems but adds a new degree of dynamism to the dimensions of individual agent behaviours and the inter-agent relationships Most decisionsmdashincluding the exact configuration of the collaborating entitiesmdashare deferred until runtime which leads to new levels of non-determinism The designerrsquos method and personal design processes do not yield to naiumlve stories that may have worked with object-oriented decompositions Neither are lsquodivide-and-conquerrsquo-based iterative decomposition techniques sufficiently rich to address these characteristics of agent-based solutions While the emerging plethora of agent methodologies are now beyond their infancy verification depends upon a large base of reported verifiable experience

As this will take some years to materialize patterns provide a sound theory and practical methodology to iteratively capture refine and validate these structures As well patterns are essentially about structure Experience from object-oriented systems development serves to validate the use of patterns in documenting agent code-level structures structures of inter-agent relationships and agent organisations We have tried to document patterns for our agent platform in all three spaces

Figure 2 A category map of agent patterns

2 Our Approach

The Agentis pattern language was created by an immersive activity to mine and author the most

fundamental architectural design and code patterns which resulted in a core of 17 patterns To structure the effort in selecting candidate patterns the agent solution space was categorised on the basis of conventional enterprise architecture abstraction layers

21 Pattern categories The pattern language is structured around three

categories architectural patterns which recommend structural solutions to problems at the level of system and agent architectures design patterns which solve common design problems within an agent and tactical patterns which offer pragmatic solutions to everyday problems when working with the platform

These categories can be thought of as horizontal layers with tactical patterns at the bottom (since these patterns extend the agent development platform) agent design patterns and agent-architectural patterns at the top (since they address the most abstract system-level structures) Within these layers particularly the architecture and design layers a further classification into business process functional design and data and integration patterns can be made (Figure 2) This grid serves two purposes Firstly it provides a way of locating and relating a candidate pattern to the existing solution design space Secondly it orientates the designer in locating a pattern needed to solve a particular problem The layering should not be taken to imply that the patterns in the Agent Architectural layer are abstractmdashthey are just as concrete in their problem and solution definitions as are the tactical patternsmdashthe

distinction is purely that they address the kinds of problems encountered when designing agent-based systems compared with designing modules goal hierarchies goals or plans

Tactical patterns are similar to Java or C++ coding idioms and are heavily dependent on the realisation of core BDI concepts in the agent-modelling platform Most of these patterns describe lsquobest practicersquo approaches to achieving some desirable

characteristic in an agent Examples include idioms to implement abstraction encapsulation and data homogenisation or manipulation Tactical patterns are supported with a reference implementation (code sample) which can be cloned and reused Because this category of patterns is closest to the agent development

36

platform it immediately began to attract local lsquowork-aroundsrsquo for unimplemented platform feature requests The resulting patterns provided valuable planning and prioritisation input to the productrsquos roadmap Over time we expect some of these patterns to be subsumed into the Agentis product

Agent design patterns sit at the next higher level of abstraction and describe agent-based realisations of many of the building blocks of enterprise applicationsmdashsmart caches filters intelligent data structures for example These are accompanied by a reference implementation in the patterns repository that an agent developer can copy and easily reuse The developer typically designs with these patterns and merges the reference implementations in appropriate ways

Patterns of agent-oriented system architecture sit at the next level of abstraction in the solution space These include agent-based realisations of system-level constructs that are applicable both within individual agents (roles layers and facades for example) and between agents in a multi-agent system (observers and brokers for example)

The pattern-mining effort does not stop there As experience in developing agent-based solutions accumulates in particular markets or business domains recurring solution structures are identified and clusters of patterns are mined within specific solution domains Work has commenced on workflow real time business exception handling and rule interpretation solution domains as well as in vertical markets such as insurance underwriting These pattern clusters and their template code modules approach the utility of small self-contained frameworks which designers combine and extend to design agent architectures and assemble agent solutions

22 Sample patterns Two short-form samples (Figure 3) from the language

illustrate the approach to individual patterns Note that these are greatly summarisedmdashthe actual patterns include full implementation details and discussions of considerations and optimisations (they run to 6 and 11 pages respectively)

The RULE COMPOSER pattern makes many assumptions about the best way to model business rules By recommending a rule equals goalrsquo approach the patternrsquos solution emphasises rule encapsulation and opens the door to a broader notion of rule as goal-directed rule The patternrsquos final solution captures the preferred option When less experienced developers implement a RULE COMPOSER the pattern guides them away from these pitfalls Individual patterns live or die on their usefulnessmdashif the patternrsquos solution is impractical unworkable or involves some form of unacceptable

compromise it will not be used Patterns to survive into maturity have to be firmly grounded in practical experience

Another sample pattern (Figure 3 right) from the language illustrates the architectural layer The DECISION TREE is a framework that executes within an agent to control a question-and-answer dialogue with the applicationrsquos user As the user responds to questions (prompts) their answers are passed to the DECISION TREE for interpretation and navigation

The DECISION TREE selects the appropriate sub-tree based on the userrsquos response and also optionally invokes application-specific behaviour in the agent at each node of the tree by delegating the userrsquos responses to an lsquoactionrsquo goal Inside this goal any application-specific behaviours can be implemented to invoke goal-directed processing at each node in the tree For example an agent could accumulate the userrsquos answers perform partial processing on them or retrieve information from external systems to inform the user about the current state of the dialogue Traversal of the DECISION TREE completes when it reaches a leaf node at which time the final action goal can complete any calculations and return the results

DECISION TREES can be nested composed or assembled dynamically to support arbitrarily complex dialogues It is typical of the patterns found in the Agent Architectural dimension of the pattern language in that it represents an architectural response to a class of recurring agent solutions Its sample implementation in the pattern repository includes Agentis agent modules Java source and sample database schema With repeated reuse this architectural pattern will mature into a solution component as unit test harnesses test data generalisation for different databases and deployment options and code to support configuration are all added

23 Designing with patterns The agent pattern language puts new nouns in the

agent solution designerrsquos vocabulary It is not difficult to anticipate how knowledge of several dozen such patterns changes the way an architect thinks about discusses and documents solutions The highest level of decomposition into agents roles and relationship structures can be expressed with patterns of multi-agent organisations There is scope to enrich our pattern language in this dimension mainly because there are fewer opportunities to repeatedly discover and validate these patterns in the domain of enterprise application development Even within solutions that require only relatively static organisations of agents we have valuable experience in using loosely coupled multi-agent structures Within individual agents the language is richest

46

Name RULE COMPOSER Context You are implementing goal-based data or form validation within an agent

Problem You have lots of interdependent validation rules that must be applied during a business process

Forces There are many validation scheduling sequencing and selection scenarios where you need to apply a number of business rules against a business data structure A naive approach might be to combine the individual validation rules into a single logical expression This approach restricts the ways you can implement the rules to those expressions and creates a maintenance problem because of the complexity of the composed usage rules A more flexible approach is to think of each individual business rule as a goal Rules can run the full range of complexity from a simple expression implemented in a usage rule for one of the goalrsquos plans to a complex decision making process implemented with multiple plans and sub-goals It also strongly encapsulates the implementation of the rule so that its evolution and change over time will not impact other parts of the agent The validation is then done by composing the individual business rules (goals) under a common validation goal which provides simple rule composition

Solution Encapsulate a number of (possibly interdependent) business validation rules behind a single validation goal (the RULE COMPOSER goal) which manages the interdependencies ensures that all the appropriate validation rules are executed regardless of their outcomes and reports on the overall result ltlt implementation details omitted gtgt

Consequences ltlt note on a disjunctive variant gtgt ltlt note on an audit trail gtgt ltlt note on the definition of lsquorulersquogtgt

Name DECISION TREE Context You are implementing an agent-based self-service web application

Problem You want to guide the user through a sequence of decisions but you want the agent to control the dialogue

Forces In some web applications navigation is dependent upon what interactions or data have been provided previously As more information is collected from the user the application makes informed decisions about narrowing or customising the presentation of options In an agent-based system you want a user interface agent controlling the user dialogue You need to represent a hierarchy of dependent navigation or business rules so that the agent can control the dialog with the user and resolve to a set of recommendations options or product offerings or calculation of results

Solution Use a DECISION TREE (a tree with decision and action metadata on each node) that represents all possible dialog paths and corresponding action sequences Each node in the tree represents a question presented to the usermdasha decision point Each time the user answers a question the DECISION TREE collects the supplied answer(s) delegates the userrsquos responses to an application-specific action and selects the appropriate sub-tree progressing toward the leaf node When the leaf node is reached the DECISION TREE invokes whatever final calculations the agent needs to perform on the set of attributes collected during the traversal and returns the result The user can then re-visit any of the nodes in the current tree initiate a new dialogue with a different instance of the same DECISION TREE (in parallel if this makes sense) or initiate a dialogue with another supported DECISION TREE ltlt implementation details omitted gtgt

Consequences I ltlt note on asymmetric trees gtgt ltlt note on instantiating multiple trees gtgt ltlt note on data-driven trees gtgt ltlt note on cycles gtgt ltlt note on localisation considerations gtgt

Figure 3 Some indicative (short-form) patterns from the language

24 A pattern lifecycle model Architects and developers use existing patterns and

components during development of an agent-based

solution In her work the reflective architect will likely uncover potentially useful new patterns Candidate patterns should not be written up immediatelymdashthe idea needs to be lsquofloatedrsquo for a period so that others in the

56

community can review it and so that its proposer can re-think and re-conceptualise it lsquoPatletsrsquo exist to support this early phase of a patternrsquos existence

A patlet is a cut-down pattern that states a name the problem some (optional) bullet-pointed forces and the solution It can be as simple or as detailed as the author desires The patlet sits on a shared portal and collects comments It takes three seconders from the community to justify creation of a pattern from a patlet When this happens the patlet (with the review input from its seconders) is formally prototyped using the agent platform and written up using the standard pattern template The new pattern is published and indexed but it stays in lsquoDraftrsquo state

The new draft pattern now surfaces in the pattern repository Users and reviewers accumulate comments and feedback which will quickly indicate its usefulness or otherwise When three instances of the patternrsquos use have been recorded it transitions from lsquoDraftrsquo to lsquoFinalrsquo state A patternrsquos state is therefore the best indication of its maturity

A pattern in Final state may ultimately be retired or merged with other patterns as the agent platform changes Patlets and patterns are never explicitly deleted as the life history of a pattern traces the progression of design thinking about a particular problem and its solutions

3 Brief Assessment

The pattern language has found an enthusiastic audience amongst Agentis consultants partners and clients Patterns are being used sample implementations reused and feedback is accumulating on a shared services portal Judging from feedback the decision to aim the pattern language at enterprise Java developers has been vindicatedmdashso much so that the pattern language is being used to support technical pre-sales activities a benefit not anticipated

In general we have found that the patterns are larger (in terms of the number of participating elements the description and the reference implementation) and more complex than lsquotraditionalrsquo object-oriented patterns DECISION TREE is a good example of this This may be due to our definition of patternmdashan OO traditionalist for example might argue that DECISION TREE is conceptually a component rather than a pattern Our definition is driven by achieving productivity through efficient reuse of the reference implementation by project team members

Integration of the language with the Agentis product roadmap is tight and as new features are planned for release patterns must be updated Pattern use is now a valuable input to roadmap planning

4 Conclusion

A process of pattern mining review use and evolution has been established at Agentis Software specifically to explicate agent-based system design and implementation knowledge The motivations for this effort include the acceleration of skilling agent technology solution architects and risk mitigation on the part of technology adopters Patterns are regarded as an excellent medium for representing agent-based designs due to the inherent structural basis of agentndashbased decomposition

The Agentis pattern language is organised around three abstraction layers and three functional layers Individual patterns within each grid square include a comprehensive sample implementation and repository artefacts to facilitate immediate reuse and customisation Designing with agent-based patterns is essentially familiar to object-oriented design pattern users but involves added design dimensions of runtime structure negotiation and adaptability for which some early patterns are emerging

A healthy pattern authoring and reviewing process reflects the health of a software engineering community of practice Ultimately the target of any pattern initiative should equally be the well being and longevity of the pattern mining process as well as the language itself The activities of proposing authoring reviewing and publishing patterns need to become embedded in the communityrsquos culture such that designers are able to pick up (and cut back) their involvement in pattern development as their interests or other workloads allow

5 References

[1] Alexander Christopher 1979 ldquoThe Timeless Way of Buildingrdquo New York Oxford University Press [2] Taylor Paul Evans-Greenwood Peter Odell James ldquoAgents in the Enterpriserdquo Industry Track Proceedings Australian Software Engineering Conference (ASWEC 2005) 29th March - 1st April 2005 Brisbane Australia [3] Jennings Nicholas R Bussmann Stefan ldquoAgent-Based Control Systems Why Are They Suited To Engineering Complex Systemsrdquo IEEE Control Systems Magazine June 2003 [4] May Daniel Taylor Paul 2003 ldquoPatterns and Knowledge Managementrdquo Communications of the ACM July 2003 Vol 46 No 7 p94-99

66

• Introduction
• • Motivations for creating a pattern language
  • Patterns and risk mitigation
  • Patterns and agent-based decomposition
  • • Our Approach
    • • Pattern categories
      • Sample patterns
      • Designing with patterns
      • A pattern lifecycle model
      • • Brief Assessment
        • Conclusion
        • References

platform it immediately began to attract local lsquowork-aroundsrsquo for unimplemented platform feature requests The resulting patterns provided valuable planning and prioritisation input to the productrsquos roadmap Over time we expect some of these patterns to be subsumed into the Agentis product

Agent design patterns sit at the next higher level of abstraction and describe agent-based realisations of many of the building blocks of enterprise applicationsmdashsmart caches filters intelligent data structures for example These are accompanied by a reference implementation in the patterns repository that an agent developer can copy and easily reuse The developer typically designs with these patterns and merges the reference implementations in appropriate ways

Patterns of agent-oriented system architecture sit at the next level of abstraction in the solution space These include agent-based realisations of system-level constructs that are applicable both within individual agents (roles layers and facades for example) and between agents in a multi-agent system (observers and brokers for example)

The pattern-mining effort does not stop there As experience in developing agent-based solutions accumulates in particular markets or business domains recurring solution structures are identified and clusters of patterns are mined within specific solution domains Work has commenced on workflow real time business exception handling and rule interpretation solution domains as well as in vertical markets such as insurance underwriting These pattern clusters and their template code modules approach the utility of small self-contained frameworks which designers combine and extend to design agent architectures and assemble agent solutions

22 Sample patterns Two short-form samples (Figure 3) from the language

illustrate the approach to individual patterns Note that these are greatly summarisedmdashthe actual patterns include full implementation details and discussions of considerations and optimisations (they run to 6 and 11 pages respectively)

The RULE COMPOSER pattern makes many assumptions about the best way to model business rules By recommending a rule equals goalrsquo approach the patternrsquos solution emphasises rule encapsulation and opens the door to a broader notion of rule as goal-directed rule The patternrsquos final solution captures the preferred option When less experienced developers implement a RULE COMPOSER the pattern guides them away from these pitfalls Individual patterns live or die on their usefulnessmdashif the patternrsquos solution is impractical unworkable or involves some form of unacceptable

compromise it will not be used Patterns to survive into maturity have to be firmly grounded in practical experience

Another sample pattern (Figure 3 right) from the language illustrates the architectural layer The DECISION TREE is a framework that executes within an agent to control a question-and-answer dialogue with the applicationrsquos user As the user responds to questions (prompts) their answers are passed to the DECISION TREE for interpretation and navigation

The DECISION TREE selects the appropriate sub-tree based on the userrsquos response and also optionally invokes application-specific behaviour in the agent at each node of the tree by delegating the userrsquos responses to an lsquoactionrsquo goal Inside this goal any application-specific behaviours can be implemented to invoke goal-directed processing at each node in the tree For example an agent could accumulate the userrsquos answers perform partial processing on them or retrieve information from external systems to inform the user about the current state of the dialogue Traversal of the DECISION TREE completes when it reaches a leaf node at which time the final action goal can complete any calculations and return the results

DECISION TREES can be nested composed or assembled dynamically to support arbitrarily complex dialogues It is typical of the patterns found in the Agent Architectural dimension of the pattern language in that it represents an architectural response to a class of recurring agent solutions Its sample implementation in the pattern repository includes Agentis agent modules Java source and sample database schema With repeated reuse this architectural pattern will mature into a solution component as unit test harnesses test data generalisation for different databases and deployment options and code to support configuration are all added

23 Designing with patterns The agent pattern language puts new nouns in the

agent solution designerrsquos vocabulary It is not difficult to anticipate how knowledge of several dozen such patterns changes the way an architect thinks about discusses and documents solutions The highest level of decomposition into agents roles and relationship structures can be expressed with patterns of multi-agent organisations There is scope to enrich our pattern language in this dimension mainly because there are fewer opportunities to repeatedly discover and validate these patterns in the domain of enterprise application development Even within solutions that require only relatively static organisations of agents we have valuable experience in using loosely coupled multi-agent structures Within individual agents the language is richest

46

Name RULE COMPOSER Context You are implementing goal-based data or form validation within an agent

Problem You have lots of interdependent validation rules that must be applied during a business process

Forces There are many validation scheduling sequencing and selection scenarios where you need to apply a number of business rules against a business data structure A naive approach might be to combine the individual validation rules into a single logical expression This approach restricts the ways you can implement the rules to those expressions and creates a maintenance problem because of the complexity of the composed usage rules A more flexible approach is to think of each individual business rule as a goal Rules can run the full range of complexity from a simple expression implemented in a usage rule for one of the goalrsquos plans to a complex decision making process implemented with multiple plans and sub-goals It also strongly encapsulates the implementation of the rule so that its evolution and change over time will not impact other parts of the agent The validation is then done by composing the individual business rules (goals) under a common validation goal which provides simple rule composition

Solution Encapsulate a number of (possibly interdependent) business validation rules behind a single validation goal (the RULE COMPOSER goal) which manages the interdependencies ensures that all the appropriate validation rules are executed regardless of their outcomes and reports on the overall result ltlt implementation details omitted gtgt

Consequences ltlt note on a disjunctive variant gtgt ltlt note on an audit trail gtgt ltlt note on the definition of lsquorulersquogtgt

Name DECISION TREE Context You are implementing an agent-based self-service web application

Problem You want to guide the user through a sequence of decisions but you want the agent to control the dialogue

Forces In some web applications navigation is dependent upon what interactions or data have been provided previously As more information is collected from the user the application makes informed decisions about narrowing or customising the presentation of options In an agent-based system you want a user interface agent controlling the user dialogue You need to represent a hierarchy of dependent navigation or business rules so that the agent can control the dialog with the user and resolve to a set of recommendations options or product offerings or calculation of results

Solution Use a DECISION TREE (a tree with decision and action metadata on each node) that represents all possible dialog paths and corresponding action sequences Each node in the tree represents a question presented to the usermdasha decision point Each time the user answers a question the DECISION TREE collects the supplied answer(s) delegates the userrsquos responses to an application-specific action and selects the appropriate sub-tree progressing toward the leaf node When the leaf node is reached the DECISION TREE invokes whatever final calculations the agent needs to perform on the set of attributes collected during the traversal and returns the result The user can then re-visit any of the nodes in the current tree initiate a new dialogue with a different instance of the same DECISION TREE (in parallel if this makes sense) or initiate a dialogue with another supported DECISION TREE ltlt implementation details omitted gtgt

Consequences I ltlt note on asymmetric trees gtgt ltlt note on instantiating multiple trees gtgt ltlt note on data-driven trees gtgt ltlt note on cycles gtgt ltlt note on localisation considerations gtgt

Figure 3 Some indicative (short-form) patterns from the language

24 A pattern lifecycle model Architects and developers use existing patterns and

components during development of an agent-based

solution In her work the reflective architect will likely uncover potentially useful new patterns Candidate patterns should not be written up immediatelymdashthe idea needs to be lsquofloatedrsquo for a period so that others in the

56

community can review it and so that its proposer can re-think and re-conceptualise it lsquoPatletsrsquo exist to support this early phase of a patternrsquos existence

A patlet is a cut-down pattern that states a name the problem some (optional) bullet-pointed forces and the solution It can be as simple or as detailed as the author desires The patlet sits on a shared portal and collects comments It takes three seconders from the community to justify creation of a pattern from a patlet When this happens the patlet (with the review input from its seconders) is formally prototyped using the agent platform and written up using the standard pattern template The new pattern is published and indexed but it stays in lsquoDraftrsquo state

The new draft pattern now surfaces in the pattern repository Users and reviewers accumulate comments and feedback which will quickly indicate its usefulness or otherwise When three instances of the patternrsquos use have been recorded it transitions from lsquoDraftrsquo to lsquoFinalrsquo state A patternrsquos state is therefore the best indication of its maturity

A pattern in Final state may ultimately be retired or merged with other patterns as the agent platform changes Patlets and patterns are never explicitly deleted as the life history of a pattern traces the progression of design thinking about a particular problem and its solutions

3 Brief Assessment

The pattern language has found an enthusiastic audience amongst Agentis consultants partners and clients Patterns are being used sample implementations reused and feedback is accumulating on a shared services portal Judging from feedback the decision to aim the pattern language at enterprise Java developers has been vindicatedmdashso much so that the pattern language is being used to support technical pre-sales activities a benefit not anticipated

In general we have found that the patterns are larger (in terms of the number of participating elements the description and the reference implementation) and more complex than lsquotraditionalrsquo object-oriented patterns DECISION TREE is a good example of this This may be due to our definition of patternmdashan OO traditionalist for example might argue that DECISION TREE is conceptually a component rather than a pattern Our definition is driven by achieving productivity through efficient reuse of the reference implementation by project team members

Integration of the language with the Agentis product roadmap is tight and as new features are planned for release patterns must be updated Pattern use is now a valuable input to roadmap planning

4 Conclusion

A process of pattern mining review use and evolution has been established at Agentis Software specifically to explicate agent-based system design and implementation knowledge The motivations for this effort include the acceleration of skilling agent technology solution architects and risk mitigation on the part of technology adopters Patterns are regarded as an excellent medium for representing agent-based designs due to the inherent structural basis of agentndashbased decomposition

The Agentis pattern language is organised around three abstraction layers and three functional layers Individual patterns within each grid square include a comprehensive sample implementation and repository artefacts to facilitate immediate reuse and customisation Designing with agent-based patterns is essentially familiar to object-oriented design pattern users but involves added design dimensions of runtime structure negotiation and adaptability for which some early patterns are emerging

A healthy pattern authoring and reviewing process reflects the health of a software engineering community of practice Ultimately the target of any pattern initiative should equally be the well being and longevity of the pattern mining process as well as the language itself The activities of proposing authoring reviewing and publishing patterns need to become embedded in the communityrsquos culture such that designers are able to pick up (and cut back) their involvement in pattern development as their interests or other workloads allow

5 References

[1] Alexander Christopher 1979 ldquoThe Timeless Way of Buildingrdquo New York Oxford University Press [2] Taylor Paul Evans-Greenwood Peter Odell James ldquoAgents in the Enterpriserdquo Industry Track Proceedings Australian Software Engineering Conference (ASWEC 2005) 29th March - 1st April 2005 Brisbane Australia [3] Jennings Nicholas R Bussmann Stefan ldquoAgent-Based Control Systems Why Are They Suited To Engineering Complex Systemsrdquo IEEE Control Systems Magazine June 2003 [4] May Daniel Taylor Paul 2003 ldquoPatterns and Knowledge Managementrdquo Communications of the ACM July 2003 Vol 46 No 7 p94-99

66

• Introduction
• • Motivations for creating a pattern language
  • Patterns and risk mitigation
  • Patterns and agent-based decomposition
  • • Our Approach
    • • Pattern categories
      • Sample patterns
      • Designing with patterns
      • A pattern lifecycle model
      • • Brief Assessment
        • Conclusion
        • References

Name RULE COMPOSER Context You are implementing goal-based data or form validation within an agent

Problem You have lots of interdependent validation rules that must be applied during a business process

Forces There are many validation scheduling sequencing and selection scenarios where you need to apply a number of business rules against a business data structure A naive approach might be to combine the individual validation rules into a single logical expression This approach restricts the ways you can implement the rules to those expressions and creates a maintenance problem because of the complexity of the composed usage rules A more flexible approach is to think of each individual business rule as a goal Rules can run the full range of complexity from a simple expression implemented in a usage rule for one of the goalrsquos plans to a complex decision making process implemented with multiple plans and sub-goals It also strongly encapsulates the implementation of the rule so that its evolution and change over time will not impact other parts of the agent The validation is then done by composing the individual business rules (goals) under a common validation goal which provides simple rule composition

Solution Encapsulate a number of (possibly interdependent) business validation rules behind a single validation goal (the RULE COMPOSER goal) which manages the interdependencies ensures that all the appropriate validation rules are executed regardless of their outcomes and reports on the overall result ltlt implementation details omitted gtgt

Consequences ltlt note on a disjunctive variant gtgt ltlt note on an audit trail gtgt ltlt note on the definition of lsquorulersquogtgt

Name DECISION TREE Context You are implementing an agent-based self-service web application

Problem You want to guide the user through a sequence of decisions but you want the agent to control the dialogue

Forces In some web applications navigation is dependent upon what interactions or data have been provided previously As more information is collected from the user the application makes informed decisions about narrowing or customising the presentation of options In an agent-based system you want a user interface agent controlling the user dialogue You need to represent a hierarchy of dependent navigation or business rules so that the agent can control the dialog with the user and resolve to a set of recommendations options or product offerings or calculation of results

Solution Use a DECISION TREE (a tree with decision and action metadata on each node) that represents all possible dialog paths and corresponding action sequences Each node in the tree represents a question presented to the usermdasha decision point Each time the user answers a question the DECISION TREE collects the supplied answer(s) delegates the userrsquos responses to an application-specific action and selects the appropriate sub-tree progressing toward the leaf node When the leaf node is reached the DECISION TREE invokes whatever final calculations the agent needs to perform on the set of attributes collected during the traversal and returns the result The user can then re-visit any of the nodes in the current tree initiate a new dialogue with a different instance of the same DECISION TREE (in parallel if this makes sense) or initiate a dialogue with another supported DECISION TREE ltlt implementation details omitted gtgt

Consequences I ltlt note on asymmetric trees gtgt ltlt note on instantiating multiple trees gtgt ltlt note on data-driven trees gtgt ltlt note on cycles gtgt ltlt note on localisation considerations gtgt

Figure 3 Some indicative (short-form) patterns from the language

24 A pattern lifecycle model Architects and developers use existing patterns and

components during development of an agent-based

solution In her work the reflective architect will likely uncover potentially useful new patterns Candidate patterns should not be written up immediatelymdashthe idea needs to be lsquofloatedrsquo for a period so that others in the

56

community can review it and so that its proposer can re-think and re-conceptualise it lsquoPatletsrsquo exist to support this early phase of a patternrsquos existence

A patlet is a cut-down pattern that states a name the problem some (optional) bullet-pointed forces and the solution It can be as simple or as detailed as the author desires The patlet sits on a shared portal and collects comments It takes three seconders from the community to justify creation of a pattern from a patlet When this happens the patlet (with the review input from its seconders) is formally prototyped using the agent platform and written up using the standard pattern template The new pattern is published and indexed but it stays in lsquoDraftrsquo state

The new draft pattern now surfaces in the pattern repository Users and reviewers accumulate comments and feedback which will quickly indicate its usefulness or otherwise When three instances of the patternrsquos use have been recorded it transitions from lsquoDraftrsquo to lsquoFinalrsquo state A patternrsquos state is therefore the best indication of its maturity

A pattern in Final state may ultimately be retired or merged with other patterns as the agent platform changes Patlets and patterns are never explicitly deleted as the life history of a pattern traces the progression of design thinking about a particular problem and its solutions

3 Brief Assessment

The pattern language has found an enthusiastic audience amongst Agentis consultants partners and clients Patterns are being used sample implementations reused and feedback is accumulating on a shared services portal Judging from feedback the decision to aim the pattern language at enterprise Java developers has been vindicatedmdashso much so that the pattern language is being used to support technical pre-sales activities a benefit not anticipated

In general we have found that the patterns are larger (in terms of the number of participating elements the description and the reference implementation) and more complex than lsquotraditionalrsquo object-oriented patterns DECISION TREE is a good example of this This may be due to our definition of patternmdashan OO traditionalist for example might argue that DECISION TREE is conceptually a component rather than a pattern Our definition is driven by achieving productivity through efficient reuse of the reference implementation by project team members

Integration of the language with the Agentis product roadmap is tight and as new features are planned for release patterns must be updated Pattern use is now a valuable input to roadmap planning

4 Conclusion

A process of pattern mining review use and evolution has been established at Agentis Software specifically to explicate agent-based system design and implementation knowledge The motivations for this effort include the acceleration of skilling agent technology solution architects and risk mitigation on the part of technology adopters Patterns are regarded as an excellent medium for representing agent-based designs due to the inherent structural basis of agentndashbased decomposition

The Agentis pattern language is organised around three abstraction layers and three functional layers Individual patterns within each grid square include a comprehensive sample implementation and repository artefacts to facilitate immediate reuse and customisation Designing with agent-based patterns is essentially familiar to object-oriented design pattern users but involves added design dimensions of runtime structure negotiation and adaptability for which some early patterns are emerging

A healthy pattern authoring and reviewing process reflects the health of a software engineering community of practice Ultimately the target of any pattern initiative should equally be the well being and longevity of the pattern mining process as well as the language itself The activities of proposing authoring reviewing and publishing patterns need to become embedded in the communityrsquos culture such that designers are able to pick up (and cut back) their involvement in pattern development as their interests or other workloads allow

5 References

[1] Alexander Christopher 1979 ldquoThe Timeless Way of Buildingrdquo New York Oxford University Press [2] Taylor Paul Evans-Greenwood Peter Odell James ldquoAgents in the Enterpriserdquo Industry Track Proceedings Australian Software Engineering Conference (ASWEC 2005) 29th March - 1st April 2005 Brisbane Australia [3] Jennings Nicholas R Bussmann Stefan ldquoAgent-Based Control Systems Why Are They Suited To Engineering Complex Systemsrdquo IEEE Control Systems Magazine June 2003 [4] May Daniel Taylor Paul 2003 ldquoPatterns and Knowledge Managementrdquo Communications of the ACM July 2003 Vol 46 No 7 p94-99

66

• Introduction
• • Motivations for creating a pattern language
  • Patterns and risk mitigation
  • Patterns and agent-based decomposition
  • • Our Approach
    • • Pattern categories
      • Sample patterns
      • Designing with patterns
      • A pattern lifecycle model
      • • Brief Assessment
        • Conclusion
        • References

community can review it and so that its proposer can re-think and re-conceptualise it lsquoPatletsrsquo exist to support this early phase of a patternrsquos existence

A patlet is a cut-down pattern that states a name the problem some (optional) bullet-pointed forces and the solution It can be as simple or as detailed as the author desires The patlet sits on a shared portal and collects comments It takes three seconders from the community to justify creation of a pattern from a patlet When this happens the patlet (with the review input from its seconders) is formally prototyped using the agent platform and written up using the standard pattern template The new pattern is published and indexed but it stays in lsquoDraftrsquo state

The new draft pattern now surfaces in the pattern repository Users and reviewers accumulate comments and feedback which will quickly indicate its usefulness or otherwise When three instances of the patternrsquos use have been recorded it transitions from lsquoDraftrsquo to lsquoFinalrsquo state A patternrsquos state is therefore the best indication of its maturity

A pattern in Final state may ultimately be retired or merged with other patterns as the agent platform changes Patlets and patterns are never explicitly deleted as the life history of a pattern traces the progression of design thinking about a particular problem and its solutions

3 Brief Assessment

The pattern language has found an enthusiastic audience amongst Agentis consultants partners and clients Patterns are being used sample implementations reused and feedback is accumulating on a shared services portal Judging from feedback the decision to aim the pattern language at enterprise Java developers has been vindicatedmdashso much so that the pattern language is being used to support technical pre-sales activities a benefit not anticipated

In general we have found that the patterns are larger (in terms of the number of participating elements the description and the reference implementation) and more complex than lsquotraditionalrsquo object-oriented patterns DECISION TREE is a good example of this This may be due to our definition of patternmdashan OO traditionalist for example might argue that DECISION TREE is conceptually a component rather than a pattern Our definition is driven by achieving productivity through efficient reuse of the reference implementation by project team members

Integration of the language with the Agentis product roadmap is tight and as new features are planned for release patterns must be updated Pattern use is now a valuable input to roadmap planning

4 Conclusion

A process of pattern mining review use and evolution has been established at Agentis Software specifically to explicate agent-based system design and implementation knowledge The motivations for this effort include the acceleration of skilling agent technology solution architects and risk mitigation on the part of technology adopters Patterns are regarded as an excellent medium for representing agent-based designs due to the inherent structural basis of agentndashbased decomposition

The Agentis pattern language is organised around three abstraction layers and three functional layers Individual patterns within each grid square include a comprehensive sample implementation and repository artefacts to facilitate immediate reuse and customisation Designing with agent-based patterns is essentially familiar to object-oriented design pattern users but involves added design dimensions of runtime structure negotiation and adaptability for which some early patterns are emerging

A healthy pattern authoring and reviewing process reflects the health of a software engineering community of practice Ultimately the target of any pattern initiative should equally be the well being and longevity of the pattern mining process as well as the language itself The activities of proposing authoring reviewing and publishing patterns need to become embedded in the communityrsquos culture such that designers are able to pick up (and cut back) their involvement in pattern development as their interests or other workloads allow

5 References

[1] Alexander Christopher 1979 ldquoThe Timeless Way of Buildingrdquo New York Oxford University Press [2] Taylor Paul Evans-Greenwood Peter Odell James ldquoAgents in the Enterpriserdquo Industry Track Proceedings Australian Software Engineering Conference (ASWEC 2005) 29th March - 1st April 2005 Brisbane Australia [3] Jennings Nicholas R Bussmann Stefan ldquoAgent-Based Control Systems Why Are They Suited To Engineering Complex Systemsrdquo IEEE Control Systems Magazine June 2003 [4] May Daniel Taylor Paul 2003 ldquoPatterns and Knowledge Managementrdquo Communications of the ACM July 2003 Vol 46 No 7 p94-99

66

• Introduction
• • Motivations for creating a pattern language
  • Patterns and risk mitigation
  • Patterns and agent-based decomposition
  • • Our Approach
    • • Pattern categories
      • Sample patterns
      • Designing with patterns
      • A pattern lifecycle model
      • • Brief Assessment
        • Conclusion
        • References