Agent-oriented Requirements Modelling

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. RequirementsModels DesignModels … Code E.g. UML models Software Engineers Software Engineers make changes Introduction – traditional approach SoftwareSystem {Knowledge}

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

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

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. Two additional model element – 2. agent • 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.

8. 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. Agents play business roles, their behaviour is dictated by business rules and functions Business rules and functions support business goals Agents collaborate to realise business goals by participating in business processes Meta-model

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. Accept Late Addition

11. Validate Train Plan

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. Solution – goal mapping (2) • 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.

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

15. Solution – structural modelling (1) • 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”.

16. Solution – structural modelling (2) • 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

17. Agent Name ‘association’ indicates agent interaction Agent Symbol Two agents interact for a business goal Classes/ objects managed “TrainOperator” agent represents the “train operating company” domain Rules for agent function “TrainRunning” agent represents the “train running planning” domain According to the functional requirements table, the ruleconstructs 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 Message path “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) “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 Classes as 2nd class citizen 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 To respond to such requests, “TrainRunning” plans additional journeys using the rule of “AcceptLateAddition” Solution – structural modelling (3)Agent Diagram

18. 3. If the created object can pass the ValidateTrainPlan () evaluation method 2. Construct a TrainJourney object using the information contained in the message 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 Rule transformed from the functional requirements table “AcceptLateAddition”: 1. Receive a late journey request message from TrainOperator Solution – structural modelling (4)rule template • 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

19. Solution – behavioural modelling (1) • 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.

20. 1. TrainOperator sends a request message for late journey, it is picked up by AcceptLateAddition rule in TrainRunning Behavioural models describe business processes 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 Solution – behavioural modelling (2)Agent Communication Diagram

21. Solution – behavioural modelling (3) • 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: <event>, <processing>, <condition>, and <action>. They reflect respectively four steps an agent takes to execute a rule in the Agent Communication Diagram.

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 <event> section and the message Execute the rule <processing> section Check if the rule <condition> is satisfied Execute the rule <action> 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?