Combining Agent-Oriented Conceptual Modelling with Formal Methods

Sergiy A. Vilkomir, Aditya K. Ghose and Aneesh KrishnaDecision Systems Lab, School of IT and Computer Science

University of Wollongong, NSW 2522, Australia{sergiy, aditya, ak86}@uow.edu.au

Abstract

Agent-oriented conceptual modelling notations such asi* have received considerable recent attention as a usefulapproach to early-phase requirements engineering. Agent-oriented conceptual modelling notations are highly effectivein representing requirements from an intentional stance andanswering questions such as what goals exist, how key ac-tors depend on each other and what alternatives must beconsidered. Formal methods such as those based on the Znotation offer a complementary set of representational fa-cilities. This paper explores how these two otherwise dis-parate approaches might be used in a synergistic fashion.

1 Introduction

Some common questions that need to be addressed inearly-phase requirements engineering are the following:what are the main goals of the system, how the stake-holders depend from each other, and what alternatives ex-ist [16]. The i∗ framework [12–15] is an agent- and goal-oriented modelling language that has been specifically de-signed for early-phase requirements engineering and that iswell-suited for answering questions such as these. The cen-tral concept in the i* framework is that of an intentionalactor (agent). Intentional properties of an agent such asgoals, beliefs, abilities and commitments are used in mod-elling requirements [17]. The i* framework is particularlyuseful for:

• making explicit (and in the process gaining) a deeperunderstanding of the organisational relationships be-tween various actors in the target environment;

• understanding of the rationale behind the existing prac-tices and structures; and

• representing, at an intentional level, the internals of ac-tors populating the target system, and relating these

explicitly to organizational objectives and inter-actorrelationships.

The i* notation consists of two main modelling compo-nents: the Strategic Dependency Model (SD) and the Strate-gic Rationale Model (SR).

The SD and SR models are graphical representations ofthe dependencies between actors and internal intentionalcharacteristics of actors respectively. A SD model is a graphconsisting of nodes and links among the nodes. Each noderepresents an actor, and each link between the actors rep-resents how one actor (depender) depends on another (de-pendee) for something in order to accomplish a goal ortask. The object around which the dependency relation-ship centres is called the dependum. An SD model rep-resents goals, task, resource, and soft goal dependenciesbetween actors. The first three of these dependency typesare relatively straightforward to understand (an actor de-pends on another to fulfill a goal, execute a task and sup-ply a resource, respectively). Softgoals are effectively non-functional requirements, i.e., statements of objectives thatthe target system should eventually meet. The SR modelprovides a more detailed level of modelling by looking ”in-side” actors to model internal intentional relationships.

As an example, consider a simplified version of the well-known meeting scheduler scenario [11, 16, 17]. This exam-ple will be used to illustrate both the i* notation and ourproposed methodology for transforming i* models into Zspecifications. The SD modelling process (see Figure 1)begins with identifying the actors involved with the meet-ing scheduling system and their mutual dependency rela-tionships.

The MeetingInitiator agent depends on Participantagents to achieve its AttendsMeeting goal. The MeetingIni-tiator’s dependency on the MeetingScheduler to schedulea meeting can be modeled as a goal dependency Meet-ingBeScheduled. The resource dependency Agreement andtask dependency EnterAvailDates are examples of otherkinds of dependencies between actors.

In the SR model (see Figure 2) intentional elements likegoals, tasks, resources, and softgoals appear not only as ex-

Figure 1. The Strategic Dependency Model

ternal dependencies, but also as internal elements which areconnected by task-decomposition links and means-ends re-lationships.

For example, the Participant has an internal task to Par-ticipateInMeeting. This task can be performed by sub-tasks AttendMeeting and ArrangeMeeting (these are re-lated to the parent task via task decomposition links). Forthe MeetingInitiator, the goal of MeetingBeScheduled isan internal goal. In the case of Participant, the inter-nal tasks FindAgreeableDateUsingScheduler and FindA-greeableDateByTalkingToInitiator are alternative means toachieve the goal Agreeable (Meeting, Date). How the al-ternatives contribute to softgoals is also represented. Theseare represented as means-ends link relationships. The SRmodel thus provides a way of modelling stakeholder inter-ests, how they might be met, and the stakeholders’ evalua-tion of various alternatives with respect to their interests.

Several proposals exist for integrating i* modelling withlate-phase requirements analysis and the downstream stagesof the software life-cycle. The TROPOS methodology [4]explores how i* models might be refined to form the ba-sis for late-phase requirements specifications, and subse-quently architecture specifications. The i* notation aloneis not adequate for representing the level of detail nec-essary for late-phase requirements specifications. To ad-dress this, formal languages such as Formal Tropos [7] havebeen developed. An alternative approach has been to de-fine methodologies for transforming i* models into agentprograms in formal agent programming languages such asConGOLOG [11].

Our thesis in this paper is that the Z formal notation andthe i* modelling framework can function in a complemen-tary and synergistic fashion and that a conceptual modelling

methodology that supports their co-evolution is of interest.Z [10] is a formal notation for computer systems and

software specification based on set theory and first orderpredicate logic. This mature formal method is widely usedboth in theoretical investigations [1] and in practice [3]. Themain elements of the Z notation are schemas which are usedto specify states and operations for the modelling of sys-tems. While Z can be used for early-phase requirementsmodelling, the necessary level of formalization, precisionand detail, the lack of a diagrammatic notation to supportthe visualization of requirements and the inability to repre-sent the intentional elements all suggest that an alternativenotation such as i* might be better suited for this phase.

Our proposal for a synergistic combination of i∗ and Zoffers several advantages:

• i* and Z can be viewed as a pair of complementaryrepresentation languages that can be jointly brought tobear on the requirements engineering exercise. The i*notation permits us to make explicit the intentional as-pects of the requirements specification, including anunderstanding of the organizational context of the pro-posed system, the alternatives that may be consideredin making design decisions as well as the rationale be-hind these decisions (these latter features support pro-cess reengineering). The Z notation permits us to spec-ify late-phase requirements with a degree of precisionand formality that i* does not.

• The i* notation allows us to represent and reason withsoftgoals (representations of non-functional require-ments or objectives).

• We propose a mapping from i* models into Z schemas

Figure 2. The Strategic Rationale Model

that does not result in any information loss, nor the in-troduction of information extraneous to the original i*model (this is distinct from proposals such as the oneinvolving mapping i* models to ConGolog agent pro-grams [11], where aspects of the i* model are ignoredin the translation).

• The mapping of i* models to Z schemas enables the re-finement of these schemas with additional information,such as invariant properties, fulfilment conditions etc.(note that these cannot be represented in the original i*model).

• Current approaches to the use of formal methods inconjunction with i* models are unduly complies. For-mal Tropos [7], for instance, is an intermediate lan-guage in which i* models must be defined before aneventual translation into a state machine model onwhich model checkers can be deployed to verify sys-tems properties (the process also assumes a significantamount of refinement of the original model with addi-tional information). Existing tool support for Z, on theother hand, allows analysis of specifications withoutany of this additional effort.

In Section 2, below, we presented the mapping between i*models and Z schemas. In Section 3, we present an exampleof such a mapping. The example is specially interestingon account of the pointers we provide on how an initial setof Z schemas obtained from an i* model might be refinedin useful ways. This paper may be viewed as a first stepin defining a complete methodology for supporting the co-evolution of i* models and Z specifications.

2 Mapping i∗ into Z

2.1 Mapping a general SD model into Z

All elements (actors and dependencies) of a SD modeldiffer in names. For describing their names in the Z notationwe introduce the basic type (given set) NAME. Given anSD model, one can refer to distinct subsets of NAME. Thesubset all actors contains the names of all actors while thesubset all depend contains the names of all dependencies inthe SD model.

[NAME]

all actors, all depend : P1 NAME

It is necessary to mention that names of internal intentionalelements of a SR model are also members of the given setNAME but do not belong to subset all depend. Formaliza-tion of these internal elements is considered later in the pa-per.

Both SD and SR models provide a description of the in-tentional relationships among actors of a process and do notdirectly address the dynamics of this process. But exactlythe dynamics are the most important for process or systemspecification. To reflect it, we use the fact that all depen-dencies in SD and internal elements in SR are realized dy-namically: a goal is achieved, task is performed or resourcebecomes available. We consider different states of the de-pendencies (elements) before and after realization using thefollowing free type definition:

STATE ::= inapplicable | unresolved | fulfilled| violated | satisficed | denied | undetermined

State inapplicable is held before the creation of a new in-stance of a dependency (element). State unresolved con-forms to a dependency (element) after the creation but be-fore realization and all other states are conforming to a de-pendency (element) after realization. The dependency (el-ement) is in state fulfilled if realization is successful and instate violated if realization is unsuccessful. With the idea ofkeeping uniform terminology with other researchers (e.g.,[5]) in the area, for softgoals we use two states satisficed anddenied. The last state undetermined can also be used onlyfor a softgoal. Softgoals are often identified with qualitycriteria and sometimes it is impossible to conclude immedi-ately after realization whether a quality criterion is satisfied.It means that it may not be clear whether the realization hadbeen successful or not. In this case we consider the softgoalis in the undetermined state.

The state of a whole SD model is a collection of statesof all dependencies for this SD model that is reflected in SDschema1:

SDSD state : NAME �→ STATE

dom SD state = all depend

Thus, the realization of a dependency changes its state andat the same time changes a state of the whole SD model.

Each SD dependency or SR element has its own specificfeatures and differs first in types and degrees.

TYPE ::= goal | softgoal | task | resource | ISA

DEGREE ::= open | committed | critical

In contrast to other values, the ISA type does not representa dependency. It means that one actor can be considered asa special instance of other actor. Since, ISA is a relationshipbetween two actors it is convenient for us to consider themtogether as a different values of TYPE. All other values offree type definitions TYPE and DEGREE are standard forthe i∗ framework.

All the dependencies in SD (as well as every element inSR model - see the next section of the paper)are describedby its own schema. A general structure of SD dependencies(external between actors) varies from a general structure ofSR elements (internal inside actors) but at the same timethey have some common patterns. That is why we use thefollowing steps of formalization, creating consecutively:

• ΦDepend schema which describes a common patternof SD dependencies and SR elements;

1All schemas in this paper were checked using the ZTC type-checkerpackage [8].

• SDependency schema which describes a general struc-ture of all the SD dependencies and includes ΦDependschema as one of the component part;

• A detailed schema for every SD dependency usingSDependency schema as a basis.

Common patterns for SD dependencies and SR elementsare represented in ΦDepend schema. Here, Φ is a part of theschema name, not an operator. It is just a naming conven-tion used to indicate a partial (incomplete) specification [2].

ΦDependdependum : NAMEtype : TYPEdegree : DEGREEresult! : STATE

result! �= unresolvedresult! = satisficed ∨ result! = denied ∨result! = undetermined ⇒ type = softgoal

Except for the above-mentioned type and degree, specificfeatures of every dependency are its name (dependum) andresulting state, which is represented by the output variableresult!. The first line of the predicate part of ΦDepend de-scribes the fact that the resulting state cannot be unresolved.The second line of the predicate part of ΦDepend reflectsthat the resulting state can take the satisficed, denied orundetermined value only for softgoals.

The following SDependency schema is a result of one-to-one mapping of the general structure of a SD dependencyinto the Z notation. This schema is an operation schema andchanges the state of the SD model (∆SD). SDependencyschema includes the components ΦDepend schema as wellas names of actors (depender and dependee) which arelinked by the dependency. While, this schema representsa general structure, its name, type, degree and names of ac-tors are not specified. It could be done later on during theconsideration of an i∗ model for a specific example.

SDependency∆SDΦDependdepender, dependee : NAME

dependum ∈ all dependdepender ∈ all actorsdependee ∈ all actorsSD state′ = SD state ⊕ {dependum �→ result!}

The most significant information is contained in the lastline of the predicate part of this schema, which describeshow the realization of the dependency changes the state ofthe SD model. Using the override operator ⊕ shows that

the value of the SD model’s state function SD state ′ afterthe dependency realization differs from its value SD statebefore the realization only in the part of the considered de-pendency and coincides for all other dependencies.

2.2 Mapping a general SR model into Z

Our approach of mapping a SR model into the Z nota-tion is similar to the approach for SD diagrams which wereconsidered in the last section. The mapping consists in con-secutively creating:

• Actor schema which describes a general structure ofall the actors in SR diagrams;

• AElement schema which describes a general structureof all the SR internal intentional elements and includesΦDepend schema as one of the component part;

• A detailed schema for every actor in the specific SRmodel using Actor schema as a basis;

• A detailed schema for every internal element of everyactor using AElement schema as a basis.

The following schema describes a general structure ofall the actors. An actor is characterized by his nameactor name, set actor element of names of all internal el-ements, and state function actor state.

Actoractor name : NAMEactor element : P1 NAMEactor state : NAME �→ STATE

actor name ∈ all actorsdom actor state = actor element

The actor state function is similar to the SD model’s statefunction SD state′ and represents a collection of states ofall internal elements of the actor.

For formalizing a general structure of all SR elements,we need to introduce a new free type, which describes pos-sible types of links between the elements.

LINK TYPE ::= NA | task decomp | means ends| contrib

Type NA (Non-Applicable) is used for elements whichhave no means for attaining them and have no compo-nents. Type task decomp represents task decompositionlinks. Types means ends and contrib describe means-ends links. Type means ends is used for Goal-Task, Task-Task, Resource-Task, and Goal-Goal links. Type contribrepresents special kinds of means-ends links for softgoal(Softgoal-Task and Softgoal-Softgoal links).

For convenience, we allocate all conditions connectedwith links into a separate schema Link. This schema in-cludes:

• names of internal (inside the actor) elementsint components which are linked with the consideredelement;

• names of external (from SD model) dependenciesext components which are linked with the consideredelement;

• type of the link;

• names of elements which give positive (contrib p) andnegative (contrib m) contribution to the softgoals.

LinkΦDependint components, ext components : P NAMEcontrib p, contrib m : P NAMElink : LINK TYPE

link = task decomp ⇒ type = tasklink = contrib ⇒ type = softgoalcontrib p ∪ contrib m �= ∅ ⇒ link = contrib ∧〈contrib p, contrib m〉 partitions int components

ext components �= ∅ ⇒ link = task decomplink = NA ⇔ cint components∪ ext components = ∅

The predicate part describes the following constraintsbetween types of links and types of elements:

• Task decomposition links are used only for tasks;

• Positive or negative contribution is possible only forsoftgoals;

• Only task decomposition links are used for connectionwith external components.

The following schema describes a general structure of allthe SR internal elements. This operational schema changesthe state of the general model of an actor (∆Actor). Simi-larly SDependency schema, AElement one includes as com-ponents ΦDepend schema. Inclusion of Link schema bringsall the information concerning links between the elements.

AElement∆ActorLink

dependum ∈ actor elementint components ⊂ actor elementext components ⊆ all dependactor name′ = actor nameactor element′ = actor elementactor state′ = actor state ⊕ {dependum �→ result!}

The predicate part of AElement schema formalizes thechanges of Actor schema under the realization of the inter-nal element. Only one component of Actor schema namelythe actor’s state function actor state′ is changed. Similarto the SD model’s state function SD state, the differencebetween values of actor state before and after the elementrealization exists only in the state of the considered element.

3 Mapping a specific i∗ model into Z: an ex-ample

3.1 Mapping the SD model

Consider the example of mapping the i∗ model intoZ for the meeting scheduling system (see above Section1). The SD model of the meeting scheduling system in-cludes three actors (initiator, scheduler, and participant)and six dependencies (scheduled, date range, avail dates,proposed date, agreement, and attend). First of all it isnecessary to describe their names in Z using the followingaxiomatic definition:

initiator, scheduler, participant : NAMEscheduled, date range, avail dates,proposed date, agreement, attend : NAME

all actors = {initiator, scheduler, participant}all depend = {scheduled, date range,avail dates, proposed date, agreement, attend}

The next step is to create six Z schemas (Scheduled,DateRange, AvailDates, ProposedDate, Agreement, andAttend) for each of six dependencies using Sdependencyschema as a basis. In other words, we use inclusion ofSdependency schema and then additionally specify the fol-lowing information: the names of the dependum, dependerand dependee, the type and the degree of the dependency.

As an example, consider DateRange schema which de-scribes the following task dependency - the scheduler ex-pects the meeting initiator to enter the data range.

DateRangeSDependency

dependum = date rangedepender = schedulerdependee = initiatortype = taskdegree = committed

Line dependum = date range shows the name of thedependency. It is a task dependency so type = task. Thescheduler depends on the meeting initiator so depender =scheduler and dependee = initiator. The importance of

the dependency is not marked in the SD diagram hence weconsider degree = committed.

Thus, DateRange schema corresponds to the date rangedependency. It is intuitively obvious because of the similar-ity of names (we use this similarity only for clarity purpose).The formal correspondence between schemas and depen-dencies is established by using variable dependum insidethe schemas without explicitly using the names of schemas.The formal rule of correspondence is described below:

correspond : NAME �→ SDependency

dom correspond = all depend∀ x : NAME | x ∈ all depend •

(correspond(x)).dependum = x

The schemas for all the other dependencies are similar toDateRange schema so we present only one of them withoutcomments.

AvailDatesSDependency

dependum = avail datesdepender = schedulerdependee = participanttype = taskdegree = committed

3.2 Mapping the SR model

The first step of formalization of the SR model in Z iscreating Z schemas Initiator, Scheduler, and Participant foreach actor using Actor schema as the basis. In such schemawe specify the name of the actor and names of all the in-ternal elements of this actor. For example, consider the SRdiagram of the meeting scheduling system (see above Sec-tion 1) initiator actor has four internal elements. We reflectit in the following Z schema:

InitiatorActororg meeting, meeting be sch, low effort,let scheduler : NAME

actor name = initiatoractor element = {org meeting, meeting be sch,low effort, let scheduler}

The schemas for scheduler and participant actors aresimilar:

SchedulerActorschedule, obt avail, obt agreement, slot,merge : NAME

actor name = scheduleractor element = {schedule, obt avail,obt agreement, slot, merge}

ParticipantActorparticipate, attend, arrange, agreeable, friendly,using sched, talking init, agree date : NAME

actor name = participantactor element = {participate, attend, arrange,agreeable, friendly, using sched,talking init, agree date}

The next step is the creation of Z schemas for all theinternal elements using AElement schema as the basis. Inthis way, we need to create seventeen schemas - four forinternal elements of initiator actor, five for scheduler actor,and eight for participant actor. It is necessary to specifythe name of the dependee, the type and the degree of theelement (similar external dependencies) but also the kindof the link and names of external and internal componentsof the considered element. We are describing an example(without comments) of two internal elements using schedand friendly of participant actor.

UsingSchedAElementParticipant

dependum = using schedtype = taskdegree = committedint components = {agree date}ext components = {avail dates}link = task decomp

FriendlyAElementParticipant

dependum = friendlytype = softgoaldegree = committedint components = {using sched, talking init}contrib p = {talking init}contrib m = {using sched}ext components = ∅

link = contrib

3.3 Refinement

The benefits of using concepts introduced in Section 2.1state function SD state becomes apparent on the step of theinformation refinement. The task of refining with additionalinformation from the existing SD and SR models requires aseparate investigation and is beyond the scope of this paper.We are providing essence of possible approaches with twoexamples.

The first example is concerned with the data exchangebetween actors. The Scheduler actor receives and sends in-formation about the possible dates of the meeting. We usethe basic type DATE to describe this information and intro-duce more detailed schema Scheduler1 which contains allthese dates.

[DATE]

Scheduler1Schedulerd range, d avail : P DATEd propos : DATE

d avail ⊆ d ranged propos ∈ d avail

This gives us an opportunity to create a more detailedschema for dependency AvailDates (now AvailDates1).First of all, intermediate (partial) schema ΦAvail1 showsthat Scheduler1 changes but only for d avail component.

ΦAvail1 == ∆Scheduler1 ∧ (ΞScheduler1 \ (d avail))

AvailDates1 schema includes ΦAvail1 and describes theway now d avail changes.

AvailDates1AvailDatesΦAvail1input? : P DATE

SD state(date range) = fulfilledd avail = ∅ ⇒ d avail′ = input?d avail �= ∅ ⇒ d avail′ = d avail ∩ input?

This change is possible only if the previous dependencydate range is realized (fulfilled) successfully. The sched-uler collects data from several participants. Hence the con-dition of date range realization is the selection of availabledates which are suitable for all the participants.

The second example is concerning temporal features andoperators. The state function SD state represents the snap-shot state of the system. To describe the behaviour of the

system in time, consider all the possible sequences of sys-tem states

SDscenarios : P(seq SD)SDfuture, SDpast : SD �→ P(seq SD)

ran SDfuture ∪ ran SDpast ⊆ P SDscenarios∀ s : SD • SDfuture(s) = {f : seq SD | head f = s} ∧

SDpast(s) = {p : seq SD | last p = s}

For each state function s consider all the behavioursSdfuture which are started in s (the future of the system)and behaviours SDpast that are finished in s (the past of thesystem). Now we can formalize all the main temporary op-erators such as sometimes in the past, always in the past,sometimes in the future, always in the future, etc., whichare used in different techniques of requirements engineer-ing, for example, KAOS [6], Formal Tropos [7]. Thus, theoperator � φ always in the future [7] for state s can bemodelled as

∀ c : seq SD; st : SD | c ∈ SDfuture(s) ∧ 〈st〉 ⊆ c • φ

Correspondingly, the operator ◦ φ next state for states can be modelled as

∀ c : seq SD; st : SD | c ∈ SDfuture(s) ∧ st = c(2) • φ

and the operator ♦ φ eventually in the future for states can be modelled as

∀ c : seq SD | c ∈ SDfuture(s) • ∃ st : SD | 〈st〉 ⊆ c • φ

If we consider a system which demands special timingrequirements (for example, a concurrent real-time reactivesystem), then it is possible to use special extensions of Zlike Timed Communicating Object Z (TCOZ) [9] designedfor modelling real-time.

4 Conclusions

Our proposal in this paper is that the Z formal notationand the i* modelling framework can function in a comple-mentary and synergistic fashion. A conceptual modellingmethodology that supports their co-evolution is of interest.This approach makes use of the advantages of i∗ for theearly-phase of requirements engineering (visualization ofrequirements, possibility of easy modifications, etc.) andthen continues with the specification of requirements in Z.The Z notation permits us to specify late-phase require-ments with a degree of precision and formality that i* doesnot.

We have considered in detail the first step of the method-ology - one-to-one mapping i∗ diagrams into the Z nota-tion. It allows us to formalize i∗ diagrams without adding

or suppressing information. The next step in the approachis the refinement of the methodology by considering addi-tional information from the i∗ diagrams. This information(invariant properties, fulfilment conditions, etc.) can be eas-ily incorporated into the Z schemas and allows us to con-sider the dynamic changes in the system states. The com-plete methodology of refinement with additional informa-tion from the existing SD and SR models requires a sepa-rate investigation and forms the main direction of our futureresearch.

References

[1] Bert, D., Bowen, J. P., King, S., Walden, M., editors.ZB2003: Formal Specification and Development in Zand B, 3rd International Conference of B and Z Users,Turku, Finland, 4-6 June 2003. Springer-Verlag, LNCS2651, 2003. ISBN 3-540-40253-5.

[2] Bowen, J. P. Formal Specification and DocumentationUsing Z: A Case Study Approach. International Thom-son Computer Press, 1996.

[3] Bowen, J. P., Hinchey, M. G., editors. Industrial-Strength Formal Methods in Practice. Springer-Verlag,FACIT series, 1999.

[4] J. Castro, M. Kolp and J. Mylopoulos. TowardsRequirements-Driven Information Systems Engineer-ing: The Tropos Project. To appear in Information Sys-tems, Elsevier, Amsterdam, The Netherlands, 2002.

[5] Chung, L., Nixon, B. A., Yu, E., Mylopoulos J.Non-Functional Requirements in Software Engineer-ing. Kluwer Academic Publishers, 2000.

[6] Dardenne, A., van Lamsweerde, A., Fickas, S. Goal-Directed Requirements Acquisition. Science of Com-puter Programming, Vol. 20, North Holland, 1993, pp.3-50.

[7] Fuxman, A., Pistore, M., Mylopoulos, J., Traverso,P. Model checking early requirements specificationsin Tropos. Proceedings of Fifth IEEE InternationalSymposium on Requirements Engineering, Toronto,Canada, August 27-31, 2001, pp. 174 -181.

[8] Jia, X. ZTC: A Type Checker for Z Notation. User’sGuide. Version 2.03, August 1998. Division of SoftwareEngineering, School of Computer Science, Telecom-munication, and Information Systems, DePaul Univer-sity, USA, 1998.

[9] Mahony, B., Dong, J S. Timed Communicating ObjectZ. IEEE Transactions on Software Engineering, Vol.26, Issue 2, February 2000, pp. 150–177.

[10] Spivey, J. M. The Z Notation: A Reference Manual.Prentice Hall International Series in Computer Science,2nd edition, 1992.

[11] Wang, X., Lesprance, y. Agent-Oriented Require-ments Engineering Using ConGolog and i*. Pro-ceedings of 3rd International Bi-Conference Work-shop Agent-Oriented Information Systems (AOIS-2001), Berlin, Germany, 2001, pp. 59-78.

[12] Yu, E., Mylopoulos, J. An Actor Dependency Modelof Organizational Work - with Application to BusinessProcess Reengineering. Proceedings of Conference onOrganizational Computing Systems, Milpitas, Califor-nia, USA, Nov. 1-4, 1993, pp. 258-268.

[13] Yu, E., Mylopoulos, J. Understanding ”Why” in Soft-ware Process Modelling, Analysis, and Design. Pro-ceedings of 16th International Conference on SoftwareEngineering, Sorrento, Italy, May 16-21, 1994, pp. 159-168.

[14] Yu, E. Towards Modelling Strategic Actor Relation-ships for Information Systems Development – With Ex-amples from Business Process Reengineering. Proceed-ings of 4th Workshop on Information Technologies andSystems, Vancouver, B.C., Canada, December 17-18,1994, pp. 21-28.

[15] Yu, E. Modelling Strategic Relationships for Pro-cess Reengineering. PhD Thesis, Graduate Departmentof Computer Science, University of Toronto, Toronto,Canada, 1995, pp. 124.

[16] Yu, E. Towards Modelling and Reasoning Supportfor Early-Phase Requirements Engineering. Proceed-ings of 3rd IEEE International Symposium on Require-ments Engineering, Washington D.C., USA, January 6-8, 1997, pp. 226-235.

[17] Yu, E. Agent Orientation as a Modelling Paradigm.Wirtschaftsinformatik, April 2001, pp. 123-132.