ology
Like object-oriented software development, we believe that an iterative approach to developing an agent-based software systems holds the best promise of successfully developing such systems. An iterative approach allows important requirements of the system to be validated early and also serve to clarify unclear requirements. The concepts covered here do not represent a fully functional agent-based development methodology but rather provide several suggestions on what to focus on during anal- ysis, design, coding and testing of multi-agent systems.
Typically, an iterative development has the following characteristics, as illus- trated in Figure 2.6.
In an iterative development approach, several phases of the system are created to provide early feedback on the usability and performance of the system. Also, analysis, design, coding and testing can take place almost simultaneously. Note, however, that the effort expanded in analysis, design, coding or testing is different in each time quantum. For example, during the initial development to the system, most of the effort would focus on analysis. Towards the end of the development, most of the effort would be spent on testing. Various formal reviews are also planned during the development in order to track and monitor the progress of the project (i.e. we
23
: effort Legend
Phases Iteration 1 Iteration 2 Iteration 3
Test Readiness Review Design Review Review Analysis System Integration &
Testing Design
Coding & Testing Analysis Time 1st running system system 2nd running system Fully running
Figure 2.6: Example of an iterative approach to agent software development.
develop iteratively but manage it sequentially). These reviews also serve as ‘exit points’ to the project. For example, if the project cannot meet its expectation, the project management team can choose to terminate the project.
Note that for more exploratory systems, a spiral development methodology can be followed. Figure 2.7 shows a typical spiral development process. However, it will not be discussed in this section.
In the discussion that follows, we will assume that the development of the agent- based system will be built on top of an agent-based infrastructure. Also, we will sug- gest appropriate UML diagrams suitable for capturing analysis and design decisions.
24 Project entry point axis Customer Communication Customer Evaluation Risk Analysis Engineering
Construction & Release Planning
Product Maintenance Projects
Product Enhancement Projects
New Product Development Projects
Concept Development Projects
Figure 2.7: Spiral development process [193].
2.5.1
Analysis
During the analysis phase, the system requirements of the system are analysed and translated to unambiguous specifications. Use-cases and interactions diagrams can be used to capture these requirements. From the use-case description, agents can be identified.
Having defined the use-case model, the roles of the system need to be found. Four types of roles need to be determined. These are:
Responsibilities. This represents the dos and don’ts of that role.
Permissions. This represents the type of information the role can access.
Activities. This represents the tasks that a role performs without interacting with other roles.
Protocol. This refers to the specific pattern of interaction between roles. After the roles have been identified and documented, the other important aspect is the interactions between roles. Note that this is done when analysing the system require- ments after the agents are identified. This step examines how the agents collaborate to accomplish certain roles.
25
2.5.2
Design
In the design phase, the roles are mapped into agent types. Agent instances are created from each type. This is analogous to the classes and objects in the object- oriented world. The class diagram can be extended to be an agent diagram by stereo- typing the class as<<agent>>. The same idea can be applied to agent instances by extending the object representation. The next step is to develop the service model. This model captures how each agent fulfil its role. The collaboration diagram can be extended to serve as a service model. Finally, the acquaintance model is created. This model captures the communication between agents. The interaction diagram can be extended to represent the acquaintance model.
In detail design, we then decide what type of agents will best implement the system requirements. Here, the software designer will need to decide if an agent will be a BDI (belief, desire, and intention), Reactive, Planning, Knowledge-based or some other new user-defined agent architecture. In addition, in situations where non-agent based entities are required to be incorporated into the system, they should be wrapped up as agents so that the entire design view of the system can be/have an agent-based view. Concepts on agent-based design pattern can also be applied during detail design.
2.5.3
Coding
In coding, the facilities provided by the agent-based infrastructure will be used to code the system. For example, in the JACK agent infrastructure, the system is essen- tially Java codes. However, extensions incorporated into the Java language to provide agent-related facilities are used to implement agent behaviours and functions.
2.5.4
Testing
Testing of agent systems follows testing of traditional software system. The test cases should be derived from the use-case model. If certain agent behaviours need to be verified, specific scenarios should be created to make verification possible. The system can then be tested.