1. Agent-oriented Requirements Modelling Liang Xiao and Des Greer School of Computer Science, Queen's University Belfast, UK August 2005

2. Overview Introduction and motivation Background Solution –Meta-model & case study –Goal mapping –Structural modelling –Behavioural modelling –Implementation Evaluation and conclusion

3. Introduction – traditional approach Software Engineers make changes Software System {Knowledge} Code Software Engineers Requirements Models Design Models … E.g. UML models

4. Make changes Software System Auto-generate Models {Knowledge} E.g. UML models Models are reused Introduction – current thinking (MDA)

5. Introduction – our thinking translate Agent Software System Models are reused Agent-oriented Models {Knowledge} E.g. UML models XML models Re-generation of the system is not necessary CASE tool Make changes

6. Two additional model element – 1. business rule Business rules capture the true essence of functional requirements. Therefore they should be made explicit rather than embedded directly into the final software product. The incorporation of business rules into UML models can compensate for the lack of capability of existing UML diagrams for capturing behavioural semantics.

7. Requirements can be organised around agents. Agents are responsible for realising the requirements. Agent is the container and business rule is the knowledge to fill the container in the requirements model. Agent and business rule complements each other in the implementation: the former is the actor, the latter guides it and dictates the role that it plays. The mapping from requirements to implementation for both the agent and the business rule brings traceability. Two additional model element – 2. agent

8. Agents play business roles, their behaviour is dictated by business rules and functions Agents collaborate to realise business goals by participating in business processes Business rules and functions support business goals Meta-model Business rules and functions represent functional requirements. They become agent behaviour and class method respectively. Classes are managed by agents, and rules are configured for the invocation of methods.

9. Case study - a national railway track system specification The system is mainly responsible for the running of the railway on a daily basis, monitoring train running with regard to incidents and ensuring the safety of the train service. It is a very complex system, the document has more than 250 pages. It contains a large number of function descriptions in a table-based unified form. Relationship between function tables is not immediately obvious.

10. DescriptionTo handle a late request for a train journey. CauseReceipt of a request for a train journey directly from a Train Operator or from the driver entering the production function’s area. The request is provided in the form of a combination of relevant train details, locations and desired timings. AssumptionThe crew is competent for the route requested. Information UsedRelevant locations. OutputsA new train journey, to Train Operator and others. Required EffectA new train journey is created from the request, and validated (PF.TR.B-ValidateTrainPlan). If the train journey is acceptable then it is distributed to all interested parties; otherwise the request is rejected or renegotiated. Having been accepted, the new train journey is known to the Production Function. IdentifierPF.TR.B-AcceptLateAddition Accept Late Addition

11. Validate Train Plan DescriptionTo validate a train journey. Sub-Reqt ofPF.TR.B-AcceptLateAddition Information UsedTrain journey and relevant train details, sectional running times, locations and track restrictions. Required EffectThe Production Function checks that the train journey:  complies with the Rules of the Route and, where relevant, the Rules of the Plan;  does not conflict with other train journeys and planned possessions; and  neither introduces unacceptable disruptions to this or other services nor increase the sensitivity of the Train Plan to disruption beyond “an acceptable level”. The Production Function must also balance the needs of all its customers. IdentifierPF.TR.B-ValidateTrainPlan

12. Solution – goal mapping (1) Organising functional requirements in terms of their goals can build a hierarchical requirements structure, where those at the bottom support those at the top. Top level requirements are those most valued by the business people and reflect the final business goals. Low level requirements reflect low level goals, which map to individual functional requirements.

13. One important business goal documented in the user requirements for the rail track system is to “deliver train journeys safely”. Whereas this goal may have been used as the basis to construct multiple functional requirements tables, the link from individual functional requirements may not have been maintained in the requirements document. Having the goal decomposed into the smallest granularity, we find that all the leaf nodes are presented in the original functional requirements tables. It helps to check the completeness and validity of the original user requirements. Solution – goal mapping (2)

14. Solution – goal mapping (3) For case study

15. Agents represent conceptual domains and are used to organise functional requirements tables. “AcceptLateAddition”, “AcceptTimetable” and “AcceptTimetableChange” belong to a single “Train Running” business domain. (indicated by the shared prefix “TR.B” field in their specification table identifier) They belong to the same agent, which we name “TrainRunning”. Solution – structural modelling (1)

16. The case study with corresponding elements in our meta-model, - the goal: make late additional journey accepted - the agent realises the goal: TrainRunning - a role/rule is defined in the functional requirements table telling the agent how to realise the goal, which we name “AcceptLateAddition” - “ValidateTrainPlan” is a business function that assists the rule “AcceptLateAddition” to realise the goal, as the “ValidateTrainPlan” table has “AcceptLateAddition” in its “Sub-Reqt of ” section Solution – structural modelling (2)

17. Solution – structural modelling (3) Agent Diagram Two agents interact for a business goal Classes/ objects managed Rules for agent function Classes as 2 nd class citizen Message path “TrainOperator” agent represents the “train operating company” domain “TrainRunning” agent represents the “train running planning” domain Agent Symbol Agent Name ‘association’ indicates agent interaction “TrainOperator” has a rule of “InformJourneyInfo” which sends a “Late journey request” message to “TrainRunning” (This may reflect increasing demand of train journeys during special dates and events in real life) To respond to such requests, “TrainRunning” plans additional journeys using the rule of “AcceptLateAddition” According to the functional requirements table, the rule constructs a “TrainJourney” object from the journey request information encoded in the received message The constructed object should pass a validation check before being put into use Therefore it is a necessity that a business class “TrainJourney” is managed by the “TrainRunning” agent and the class has a constructor method and a validation method to be invoked by the agent “AcceptLateAddition” and “ValidateTrainPlan”, presented as two functional requirements tables, become respectively an agent rule and a validation method of a business class that is managed by the agent

18. Solution – structural modelling (4) rule template 3. If the created object can pass the ValidateTrainPlan () evaluation method Rule transformed from the functional requirements table “AcceptLateAddition”: 1. Receive a late journey request message from TrainOperator 2. Construct a TrainJourney object using the information contained in the message A rule essentially captures a functional requirement in that it lays out action that should be taken, on receipt of an event (normally modelled as a message), if certain conditions are satisfied 4. Then send a message with the created TrainJourney to TrainOperator and other relevant agents 5. Add the belief that the TrainOperator has made such a request at this moment

19. Behavioural models show how agents behave to achieve the goals in their participation in business processes. Each agent can appear in multiple processes using different rules for different purposes. Agents and their rules are organised around the business processes they participate in. Requirements specification can be divided according to business processes. Solution – behavioural modelling (1)

20. Solution – behavioural modelling (2) Agent Communication Diagram Behavioural models describe business processes 1. TrainOperator sends a request message for late journey, it is picked up by AcceptLateAddition rule in TrainRunning 2. TrainRunning decodes the message, and creates a new train journey from it using the rule 3. Check the rule condition using the class method “ValidateTrainPlan ()” on the created object 4. If the condition is met, send a response message with required information to the initiating agent

21. Agent Communication Diagrams visualise how agents behave according to the rules transformed from the requirements specification. In order to make behavioural models of the requirements understandable for computers and facilitate future automation, the UML style diagrams are complemented by rules in the form of XML, describing exactly how agent rules function. A rule is composed by four XML tags:,,, and. They reflect respectively four steps an agent takes to execute a rule in the Agent Communication Diagram. Solution – behavioural modelling (3)

22. Rule definition in XML (identification section) A rule named “AcceptLateAddition” is defined as a rule that controls the behaviour of “TrainRunning” while the agent participates in the “Late train journey request handling” process.

23. Rule definition in XML (business object section) Business class “TrainJourney” will be used by the rule “AcceptLateAddition” with its instantiation “trainJourney”.

24. Rule definition in XML (event section) The rule will fire if its owner agent receives a “Late journey request” message from the “TrainOperator”.

25. Rule definition in XML (processing and condition section) Construct an “trainJourney” object using the information contained in the incoming message. Check if “ValidateTrainPlan ()” method of the created object returns TRUE.

26. Rule definition in XML (action section) If TRUE, then encode the created “trainJourney” object into a message and send it to “TrainOperator”.

27. Improved models for automation Integrated requirements & design models are built in the form of UML & XML. An Agent Communication Diagram in UML and a set of participating rules defined in XML describe a business process, delegated for a business goal. Any later change to the requirements specification will be mapped to XML element content, according to the mapping from the four main sections of functional requirements tables to the four main XML elements, and the corresponding UML model structures. UML/XML-based format is less likely to bring ambiguousness, incompleteness and inconsistency. These changes will be further transformed to the implementation so that maintenance of code is avoided.

28. Solution - implementation Implementation is not restricted to any particular technology, as the re-constructed requirements models are neutral requirements documentation. Nevertheless, agent-oriented implementation is straightforward. Implementing each conceptual agent in our models as a software agent is natural. One agent in the requirements level captures knowledge of a domain. One running agent has the knowledge processing capability with regard to the domain, reflected in their collaboration with other agents, in an information passing fashion.

29. Tool Support An AAM CASE tool is developed for the specification of agent communication models in UML and rule definitions in XML. Rules can be defined either in XML text or using a more user-friendly tree structure in the left panel of the tool. XML code is eventually generated from the completed tree structure and saved in a rules document.

31. Tool support Agent systems running on the JADE platform are automatically generated such that each rule maps to an agent behaviour. XML-based rules are plugged in and are subsequently translated by agents at run- time. While the system is running, rules can be updated through the tool, so that agent behaviour is continuously updated.

32. Pseudo code of one agent behaviour transformed from a rule All agents access a central XML-based rules document via a parsing package. A shared module called “Rule” is used by all behaviour with its ability to access the XML definition of rules and assemble corresponding objects. The methods getPriority(), getEvent(), and getAction() are provided by “Rule”.

33. Check if the selected rule is defined to deal with the incoming message by matching the rule section and the message Check if the rule is satisfied Execute the rule section

34. Conclusion The proposed agent-oriented modelling approach supports automatic generation of executable systems from the models. Accompanying XML rule definitions are used to explain function details of each UML element, or agent behaviour. Maintenance of the models is actually maintenance of the running systems. It is much less painful and risky to change UML & XML models than look for places in the code to reflect every change in the requirements, when requirements change.

35. Future work At the moment, running agent systems have limited autonomy and intelligence, truthfully reflecting the requirements demand. However, the integral design of agent beliefs leaves the possibility of adding advanced autonomous features to agents. In the future, we would strengthen the approach, for example, allow agents to resolve requirements conflicts or reject some requirements from a judgment based on their experience.

36. Questions?