Agent Based Executable Conceptual Models using i* and CASO

Aniruddha Dasgupta and Aneesh Krishna and Aditya K. Ghose

Decision System Laboratory School of Computer Science and Software Engineering University of Wollongong, Wollongong, Australia {ad844, aneesh, aditya}@uow.edu.au

Abstract. Agent-Oriented Conceptual Modelling (AOCM) is a novel approach to conceptual modelling that has gained considerable credence within the research community over the last decade. The key innovation in AOCM is the use of an agent, together with associated concepts such as goals, plans, commitments etc. as modelling constructs. This has been inspired, in part, by the growing popularity of agent-oriented approaches to the building of intelligent systems, within the articial intelligence and related research communities. CASO is a formal agent programming language for process specication and agent programming. It supports the formal specication of complex multiagent systems and provides a tool for process simulation. On the other hand it lacks features for modeling the rationale behind design choices. This work allows us to benet from the complementary representational capabilities of the two frameworks.

Introduction

Requirements Engineering is the process which identies the purpose of a software system and documents it in a form which is responsive to detailed examination, communication followed by implementation [15]. The criticality and centrality of requirements engineering is now widely acknowledged, given that the majority of software errors can be traced back to errors in the requirements engineering phase, and given the diculty of recovering from these errors in subsequent phases (i.e., design specication, coding, testing etc.) of the software life cycle. AOCM notations oer abstractions that are suciently high-level to be particularly suitable to early-phase requirements modelling. As problems grow in size and complexity, the need for formal analysis during the early RE phase may increase. Hence it is often desirable to include mechanisms which allow simulations of dierent scenarios which would be useful in analyzing its properties and could serve as a decision-support tool. Our approach uses the technique of BDI (belief-desire-intention) [13] agent programming with CASO [2], which incorporates constraints into a reactive BDI agent programming language. This extends and builds upon our earlier work on co-evolution of i* model and CASO agent programs [2]. Unlike most of the other approaches we particularly focus on modeling non-functional requirements also

known as softgoals in the context of i* framework without making any modications to the existing i* model. We use CASO to incorporate preferences or soft constraints to map to the softgoals in i* model. In this work a methodology for the combined use of i* and CASO is proposed and applied to a harbor supply chain specication. The goal of our approach is to devise a method for the analysis and validation of requirements models represented in i* with CASO agent programs without ignoring aspects of the i* model in the translation and analysis process. The remainder of this article is organized as follows. Section 2 and gives some background on i* and CASO. Sections 3 describes how softgoals can be modeled in i* and section 4 discusses the combined use of i* and CASO. Section 5 uses a harbor supply chain system to discuss the methodology and shows using examples, how one can benet from the combined us the two frameworks. Finally, related work and concluding remarks are presented in the last sections.

Background

We briey provide an overview of the i* and CASO in this section. Considerable detail has been omitted in this section due to space limitations but examples and full versions of the text can be found in [10] and [2]. The i* framework The i* framework [10] for agent-oriented conceptual modeling was designed primarily for early phase requirements engineering. An i* model consists of two main modeling components: the Strategic Dependency (SD) Model and the Strategic Rationale (SR) Model. The SD diagram consists of a set of nodes and links. Each node represents an actor, and each link between the two actors indicates that one actor depends on the other for something in order that the former may attain some goal. The depending actor is known as depender, while the actor depended upon is known as the dependee. The SD diagram represents the goals, task, resource, and softgoal dependencies between actors. There are four types of dependencies in i* - goal dependency, task dependency, resource dependency and softgoal dependency. The notion of softgoals (quality goals) is related to the notion of non-functional requirements [1]. Softgoals are the goals that do not have a clear-cut satisfaction condition. Each contribution link [11] towards a softgoal is characterized by a label that species the contribution type and strength. The positive contribution types for softgoals are HELP (positive but not by itself sucient to meet the higher goal), MAKE (positive & sucient), SOME+ (partial positive contribution), and ? (unknown). The dual negative types are HURT, BREAK, and SOME- respectively. CASO CASO(Constraint AgentSpeak with Objectives) [2] is a programming language based on the popular BDI (belief-desire-intention) language AgentSpeak [9]. It incorporates constraints and objectives into the symbolic approach of BDI

model. CASO is based on a logical formalism and is very expressive. It can be well adapted to the early-design stages of system development, when detailed alternative process designs have to be specied and need to be compared. CASO incorporates Constraint Solving and Optimization (CSOP) techniques where the optimization is based on the objective function (softgoal). An agent program in CASO consists of a set of beliefs B, a set of constraints C, an objective function O, a set of events E, a set of intention I, a plan library P, a constraint store CS, an objective store OS and three selection functions SE , SP , SI to select an event, a plan and an intention respectively to process and np and ni are parameters which denote the number of steps to look-ahead for plan and intention selection respectively. Transition of agent program to process events depends on the event triggers. An event trigger, t, can be addition(+) or removal(-) of an achievement goal(!gi ) or a belief(bi ). The CASO interpreter manages set of events, a constraint store, an objective store and a set of intentions with three selection functions. The usefulness of using preferences comes when a CASO agent has to perform an option selection SO operation in choosing a particular plan to pursue.

Modelling softgoals as preferences in i*

In order to decide among dierent courses of action, it is important to rank them according to some measure of utility. This decision involves the categorization of the softgoals according to the importance to the system. We extend the approach put forward in [6] for goal analysis in which simple preference scores are given to softgoals based on the contributions. A value of 1 is added for each positive contribution to a preference, 0 to each unmarked preference, and -1 for each negative contribution to a preference. Note that these numbers are arbitrary and depends on the modeler who may wish to give any other weights depending on the domain requirements. It is to be noted that although softgoal decomposition is possible, we are only concerned about the lowest level of softgoal decompositions here. Using this notion we observe that in Figure 1 which describes the Meeting Initiator agent, using the task UseMeetingScheduler is going to have a positive contribution (value of 1) towards the softgoal MinimizeEort and the task ScheduleManually is going to have a negative contribution (value of -1) towards the same softgoal. If there are many softgoals in the system say p1, p2 p3 and

Task T1 T2 T3 T4

p1 3 2 -1 1

p2 0 1 2 1

p3 -1 1 0 1

Table 1. Task-softgoal contribution

Fig. 1. SR diagram for Meeting Initiator

tasks T1, T2, T3 and T4 then i* could be extended to incorporate a preference value associated with each softgoal. We annotate each softgoal with a weight (say between 0 and 1) such that p1=0.5, p2=0.7 and p3=0.7. Let us further assume that the tasks have contribution towards each softgoal as given in Table 1. Now if we further assume that each of the tasks T1, T2, T3 and T4 are alternate ways of achieving the same goal, then using simple weighted sum for calculating the task contribution values (ConVal ) towards all the softgoals, we get the following values for each task: ConV al(T 1) = 30.5+00.7+(1)0.7 = 0.8; ConV al(T 2) = 2 0.5 + 1 0.7 + 1 0.7 = 3.1 ; ConV al(T 3) = 1 0.5 + 2 0.7 + 0 0.7 = 0.9; ConV al(T 4) = 1 0.5 + 1 0.7 + 1 0.7 = 1.9.

Combined Use of the i* and CASO Frameworks

Our methodology for the combined use of i* and CASO frameworks includes six steps described below. 1. Building the strategic Dependency Model(SD) for the System. The analyst develops a SD model that species the agents, roles, positions, and the intentional dependency relationships between them. 2. Building the Strategic Rationale Model(SR) for the System. The analyst further analyzes the requirements of the system based on the developed SD model, focusing on identifying the goals, softgoals, and tasks to be accomplished inside agents. It also species the decompositions of the tasks/goals, and the contributions to softgoals. The dependency relationships will be specied between nodes inside the related agents. 3. Developing the Initial CASO Model. The analyst maps elements in the SR model into entities in the CASO model using the dened mapping rules and builds the initial CASO model by specifying the actions, tasks, softgoals, plans, the initial beliefs and constraints, and the behavior of the agents in the system. 4. Validating the CASO Model by Simulation. The analyst evaluates the CASO model through simulation. Given a specication of an initial state for the system, the developed CASO model will be simulated using the interpreter and the results are used to check the correctness of the model. Then, we identify the

shortcomings and rene the CASO model based on the results of the evaluation. This step will help the analyst nd those mistakes and revise the annotated SR model in the next step. 5. Rening i* and CASO Models Based on Validations Results. Whenever the analyst observes that the i* model or CASO models has to be modied based on the results of the validation step, he will rene both the CASO model and the corresponding part of the i* model. Also by communicating with the client about the current i* and CASO models, the analyst can obtain the feedback from the client and revise the i* model and the corresponding parts of the CASO model. This brings out new specication of the system of interest. Another case is when the analyst needs to add new features into the designed system after he nds some missing requirements have to be modeled, such as loops, exogenous actions, etc. He must modify the i* model and the corresponding part of the CASO model to ensure consistency between these two models. 6. Producing the Requirements Analysis Document. The models and specications are collected in a document with appropriate explanations and discussion. The results of simulation and verication are also described.

Case Study: Harbor Supply Chain Management

In this section we take the example of supply chain management in the context of a harbor as described in [14]. In a harbor, cargo is loaded onto the ship, unloaded from the ship, and stowed on the pier where the receipt and delivery of freight happens. Harbor management system consists of ship operation system, cargo moving system, storage systems, receipt and delivery systems, gate operation systems, and management and operation information system. Ships arrive at the port, receive the service at the berth, and then de-berth after completing the activities of unloading and loading of the containers. Containers are unloaded by the gantry cranes from the ships, and then transported by yard trailer to the yard. At the yard, the transfer crane load/unload the container to the yard and the tractor moves the container to the gate for transferring outside the port. For the export containers, the reverse process applies. In addition, the operational policies of container terminal consists of berth allocation, yard planning, stowage planning, and logistics planning. 5.1 Building i* models for the Harbor Supply Chain

From the case study described above, we can formulate the following logical entities in the harbor supply chain which control material and information ow: Customer Relationship Agent which is responsible for acquiring, modifying and cancelling orders and negotiating with customers with regards to due dates, prices etc. Logistics Agent which is responsible for coordinating the supplier, harbor, and distributor. Transportation Agent which is responsible for the assignment and scheduling of transportation resources to satisfy inter-harbor movement requests from the logistic manager. Distributor Agent which is

responsible for delivery of goods to the customer. Other physical entities are ship and harbor. Figure 3 shows the Strategic Rationale (SR) model of the actor Customer Relationship Agent. We will use this actor to describe our combined methodology of using i* and CASO. The main goal of the agent is to make deals with the customer and full the order. To achieve this goal, it has to perform the task of acquiring orders which in turn calls for handling requests from the customer and negotiating with the customer in terms of price and date. It needs to also check with the logistics agent to see whether an order can be fullled (order feasibility). A soft goal of the agent is to process orders fast. Also the negotiation process could be carried out by an automated software or manually - the former contributing positively towards the soft goal and the later contributing negatively. The agent is also responsible for generating invoice to the customer and supply the order information to the logistics agent.

Fig. 2. SR diagram for Customer Relationship Agent in Harbor SCM

5.2

Developing the Initial CASO Model

A rst step in developing the CASO model is to dene a mapping from i* to CASO. For sake of continuity, we provide the results from the earlier work [3] where this mapping was initially dened. A multi-agent system (MAS) is dened as a pair {Agents, ESA} where Agents= a1 an , each ai is a CASO agent and ESA is a specially designated Environment Simulator Agent implemented in CASO. ESA holds the knowledge about the actions that might be performed by actors in SD model and the possible environment transformation after the executions of those actions. The environment agent can verify fulllment properties such as creation conditions, invariant conditions, and fulllment conditions of those actions associated with each agent. While ESA is a CASO agent, it must be provided with necessary beliefs as well as the plans. The context of the plans determines the constraints that must hold and actions in the body are

7 Plans (p1) +task(Make Deals):True !task(Acquire Order), !task(Order Feasibility), Supply(Order Information). (p2) +task(Acquire Order):resource(Order Detail) !task(Handle Request), !goal(Negotiate). (p3) +task(Handle Request):True !task(Generate Invoice). (p4) +task(Generate Invoice)):True Supply(Invoice). (p5) +goal(Negotiate):True !task(Automated). (p6) +goal(Negotiate):True !task(Manual). (p7) +task(Manual): ConVal(Manual , >=, 0) . (p8) +task(Automated): ConVal(Automated , >=, 0) . (p9) +task(Order Feasibility):resource(Contract Advice) . Fig. 3. CASO Customer Relationship Agent

how to react to the situation. The agents in the MAS are Customer Relationship Agent, Logistics Agent, Transportation Agent, and Distributor Agent. We map the edges and nodes for each agent from the SR diagrams for each actor which denes the goal, task and resource dependencies into CASO plans. It is to be noted here that besides the four agents, the ESA is also supplied by the analyst of the system (not shown here) which monitors all of the actions/tasks performed by each agent, all of the messages exchanged and all of the beliefs communicated by individual agents for consistency and constraint violations. In CASO we use decision-theoretic planning which investigates alternatives with the aim of nding the best solution in terms of some measure of utility. For this purpose a softgoal is given a numeric value, which can then be incorporated into the utility computation. The mapping of softgoals in i* to the soft constraints extended CASO model as described earlier is quite straightforward. The option selection function So determines the particular plan to follow in case there are alternatives by calculating the task contribution towards each softgoal. The result of applying the mapping rules generate the four CASO agents as mentioned above. We show the Customer Relationship Agent (CRA) CASO agent in Figure 3. Note that some of the plans that do not have any body do not exist in the actual programs. However, we show them in this gure to avoid the confusion and improve the clarity of the paper. There are 9 plans - p1, p2, p3, p4 p5, p6, p7, p8 and p9 as shown in the gure. There are 2 beliefs in the belief base of the ESA which quanties the contribution of two tasks towards the softgoals as described in section 5. ConVal(Manual , FastOrderProcessing =, -1) signies that the task Manual has a contribution of -1 towards the existing softgoal. Similarly ConVal(Automated, FastOrderProcessing, =, 1) implies that the task Automated has a contribution of +1. Plans p4 and p5 which describe the alternates that CRA can choose from has constraints as the context of the plans. In plan p7, the context ConVal(Manual , >=, 0) means that this plan will be pursued if and only if the task contribution of Manual is >= 0. Here the belief base has the contribution as -1 and hence this plan will not be selected. Thus plan p5, whose context clearly satises the constraint, will be selected as

the alternate. It is to be noted here that it is purely up to the analyst to decide the context constraint of the plans when dealing with softgoals. Thus any plan context of the form ConVal(T, cond, val) could be used by the analyst where T refers to the task, cond could be any of >, =>=, <, <= and val refers to a number. Thus CASO captures the softgoal contribution of each task into its plans as shown here. 5.3 Validating and Rening the CASO Model by Simulation

The analyst can evaluate the CASO model through simulation. First, we specify an instance of the system and then we run a simulation. By checking and comparing the results of simulation on dierent system instances or initial states, we can see whether the system behaves as expected. The analyst rst creates an instance of ESA, and each of the other agents in the system. As an example, the Harbor Supply Chain may not have capabilities to handle more that 20 shipments in a day. This constraint can be supplied to the CRA but it cannot be depicted in the i* model. Thus this constraint is given to the ESA by the user and thus this MAS can detect in its execution cycle whether the constraint is violated. Based on the order fulllment perspective, simulation model identies not only the product and information ow, but also the delay of delivery, information, order decision, and order lling. The input parameters of the experiment are the number of entities, their association, properties and the coordination strategy, which determines the information propagation depth upstream or downstream. In the initial SR model, the possibility of failing to achieve a goal is not clearly shown, but in the CASO model, this is handled. Moreover the CASO model gives hints about how to achieve the softgoals using quantitative modeling. The six steps as described in section 4 will need to be repeated if errors are found or if aspects of the i* model and CASO model do not satisfy the clients needs. Based on the CASO model and simulation experiments, if the i* model lacks some part of the desired requirements, modications to the i* model will be performed. Similarly if the CASO model needs to specify additional details or aspects of the i* model, modications to the CASO model will be made. Once a satisfactory model of the required system has been developed, a requirements specication document is produced.

Related Work

Much of the existing work in requirements engineering has focused on modelling and specication languages for the late-phase, and assume that an initial statement of the requirements is always available [11]. The late-phase of requirements engineering focuses on the completeness, consistency, and automated verication of requirements. In contrast, the early phase intends to model and analyse stakeholders interests and how they might be addressed, or compromised, by means of various system and environment alternatives. However, formal support for the early-phase requirements engineering has been relatively sparse.

Formal Tropos [4] is an intermediate language in which i* models must be dened before an eventual translation into a state machine model on which model checkers can be deployed to verify systems properties. Alternative approach have been proposed for transforming i* models into agent programs in formal agent programming languages such as ConGolog [5]. In their work aspects of the i* model are ignored in the translation process. [8] presents an agent-oriented requirements engineering approach that combines informal i* models with formal specications written in the CASL language. Co-evolution of i* models with 3APL is described in [7] where agent programs are concurrently maintained and updated. In another notable system called SNet [12], extended i* diagrams are automatically translated into executable ConGolog programs in inter-organizational networks in business process management. It also uses softgoals to model alternates in ConGolog but makes modications to i* diagrams. One major drawback of most of the existing approaches is that the agents themselves are limited in the kinds of choices they are able to make during a simulation. During a particular simulation run, the agents simply commit reactively to the choices required by the design of the agent network and do not themselves engage in deliberation about what the most appropriate course of action might be.

Conclusion

In this paper, we review an approach to executing i* models by translating these into set of interacting agents implemented in the CASO language and suggest how we can perform reasoning with the requirements modelled (both functional and non-functional) using i* models. In this paper we particularly incorporate deliberation into the agent design. The methodology allows the requirements engineer to exploit the complementary features of the two frameworks to develop better models of the application of interest and produce requirements specications that fulll the clients goals. A CASO model can be used both as a requirements analysis tool and as a formal high-level specication for a MAS that satises the requirements because it is possible to produce a high-level, formal model of the MAS right from the i* diagrams. Our work particularly focuses on modeling alternatives using softgoals which is dierent from most other approaches where softgoals and softgoal dependencies are abstracted out from SR diagrams before annotations are introduced and softgoal nodes are dropped from the i* diagrams along with the accompanying contribution links. We can analyze the system behavior and especially reason with the alternates, using real-life examples which is otherwise not possible by only looking at the i* model and CASO agents separately. Using the CASO interpreter, one can run this highlevel model of the system on some sample environment/agent parameters and determine if the behaviour of the program corresponds to the expected behaviour of the system-to-be. If discrepancies are found, they can be analyzed and appropriate changes can be made to the original SR diagram. Due to the tight mapping between SR diagrams and the CASO models, it is easy to nd parts of the SR diagram that are related to specic parts of the CASO program and vice

10

versa. Using this technique one can specify requirements, dene architecture, model behavior as well as perform simulation. Our future work is to build an automated tool which can help towards achieving this exercise.

References
1. L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos. . Non-Functional Requirements in Software Engineering. Kluwer Academic Publishers. 1999. 2. A. Dasgupta and A. K. Ghose. Caso: A framework for dealing with objectives in a constraint-based extension to agentspeak(l). In Proc. of the 2006 Australasian Computer Science Conference, 2006. pp. 121-126. 3. A. Dasgupta, A. Krishna, and A. K. Ghose. Co-evolution of agent-oriented conceptual models and CASO agent programs. In IEEE/WIC/ACM International Conference on Intelligent Agent Technology, Hong Kong, China (IAT06), 2006. pp. 686-689 4. A. Fuxman, R. Kazhamiakin, M. Pistore, and M. Roveri. Formal tropos: language and semantics. 2003. 5. G. D. Giacomo, Y. Lesperance, and H. J. Levesque. Congolog, a concurrent programming language based on the situation calculus. Vol. 121, pages 109169, 2000. 6. B. Hui, S. Liaskos, and J. Mylopoulos. Requirements Analysis for Customizable Software Goals-Skills-Preferences Framework. In International Requirements Engineering Conference, RE(2003). IEEE, 2003. pp. 117-126. 7. A. Krishna, Y. Guan, and A. K. Ghose. Co-evolution of i* models and 3apl agents. In Sixth International Conference on Quality Software (QSIC06), 2006. pp. 117-124. 8. A. Lapouchnian. Modeling Mental States in Requirements Engineering An AgentOriented Framework Based on i* and CASL. MSc. Thesis, York Univ., Canada, 2004. 9. A. Rao. Agentspeak(l): BDI agents speak out in a logical computable language. In Agents Breaking Away: Proc. of the 7th European WS on Modelling Autonomous Agents in a Multi-Agent World. Springer, 1996. 10. E. Yu. Modelling strategic relationships for process reengineering, Phd. Thesis. Univ. of Toronto, Canada, 1995. 11. E. Yu and L. Liu. Modelling trust for system design using the i* strategic actors framework. In Trust in Cyber-Societies Integrating the Human and Articial Perspectives. R. Falcone, M. Singh, Y.H. Tan, eds, LNAI-2246. Springer, 2000. pp. 175-194 12. Gunter Gans, Matthias Jarke, Gerhard Lakemeyer and Dominik Schmitz. Deliberation in a metadata-based modeling and simulation environment for interorganizational networks. In Information Systems. Elsevier Science Ltd., Volume 30, number 7,pages 587-607, 2005. 13. A.S. Rao and M. George. BDI Agents: from theory to practice, In Proc. of First International Conference on Multi-Agent Systems (ICMAS-95 ), San Fransisco, 1995. pp. 312-319. 14. D.W. Yi, S.H. Kim and N.H. Kim. Combined Modeling with Multi-Agent Systems and Simulation: Its Application to Harbor Supply Chain Management. In Proceedings of Hawaii International Conference on System Sciences. USA, 2002. 15. B. Nuseibeh, and S. Easterbrook. Requirements Engineering: a roadmap. In Proc. of 22nd International Conference on Software Engineering-Future of SE Track. June 4-11, 2000, Limerick, Ireland, pp. 35-46.