“Loosely-coupled ” Consistency between Agent-Oriented Conceptual Models and Z Specificati

“Loosely-coupled”Consistency between Agent-Oriented Conceptual Models andZ SpecificationsAneesh Krishna,Aditya K.GhoseDecision Systems Laboratory School of IT and Computer Science University of Wollongong,Australia ak86,aditya@.auSergiy A.Vilkomir Software Quality Research Laboratory Dept of Computer Sc.&Info.Systems University of Limerick,Irelandsergiy.vilkomir@ul.ieAbstractAgent-oriented conceptual modelling(AOCM)is a rel-atively new technique that offers significant benefits in the modelling and development of complex computer systems. It is highly effective in answering questions such that what are the main goals of the system,how key actors depend on each other,and what alternatives exist.A formal method can benefit any stage of the software development lifecycle and improves the quality of the computer systems.The pa-per defines an approach that allows to complement require-ments modelling notations with formal specifications,while preserving the consistency between them.1.IntroductionMany existing modelling techniques and frameworks tend to address the“late-phase”of requirements engineer-ing,which focuses on completeness,consistency and auto-mated verification of the requirements[12],while the vast majority of critical modelling decisions(such as determin-ing the main goals of the system,how the stakeholders de-pend on each other,and what alternatives exist[12])are taken in the early-phase requirements engineering.Hence,it would be appropriate to present different modelling and rea-soning support for the two phases.The i*modelling frame-work[12]is a semi-formal notation built on agent-oriented conceptual modeling that is well-suited for answering these questions.The central concept in i*is that of the intentional actor or agent.The actor or agent construct is used to iden-tify intentional characteristics represented as dependencies involving goals to be achieved,tasks to be performed,re-sources to be furnished or softgoals(optimisation objectives or preferences)[12]to be satisfied.The i*framework con-sists of two graphical modelling components:Strategic De-pendency(SD)Models and Strategic Rationale(SR)Mod-els.The SD model captures the social context of the system.It consists of a set of nodes and links where each node rep-resents an actor,and each link between the two actors indi-cates that one actor depends on the other for something in order that the former may attain some goal.An SR model (see Figure1)provides a more detailed level of modelling by looking“inside”actors to model internal intentional rela-tionships.Intentional elements(goals,tasks,resources,and softgoals)appear in the SR model not only as external de-pendencies,but also as internal elements linked by task-decomposition and means-ends relationships.Readers are encouraged to refer to[12]for a comprehensive explana-tion of the i*framework.Consider the following modified example(see Figure1)(to be used throughout the rest of the paper)from our earlier case study[9]which concen-trates on a key function of the emergency services agency (ESA):computer based training system(CBT)for volun-teers.This research has been conducted in the context of a larger project to deploy i*for enterprise modelling in a large ESA.There have been a number of proposals reported in the literature for combining i*modelling with late-phase re-quirements analysis and the downstream stages of the soft-ware life-cycle.One of them combines the i*framework with the formal agent programming language[11].We have similar objectives with a slightly different approach.We be-lieve that the value of conceptual modeling in the i*frame-work lies in its use as a notation complementary to existing specification languages.We believe that,the i*framework when used in conjunction with other modeling/specification in notation X(X could be UML/Z/English)improves the quality of those models/specifications.Our work focuses on the combined use of agent-oriented conceptual modeling and Z notation.The notion of co-evolution is used in a very specific sense to describe a class of methodologies that per-mits the i*modeling to proceed independently of specifica-tion in a distinct notation,while maintaining some modicum of loose coupling via consistency constraints.Our research suggests how diagrammatic notations suitable for model-ing the requirements;organisational contexts and rationale can be used in a complementary manner with more tradi-tional specification notations(in our case Z,may be UML).When proposing the co-evolution of two otherwise dis-parate approaches for requirements engineering,we need to take care the issue of maintaining consistency between the two approaches.The mapping rules can be viewed as pro-viding formal semantics to i*diagrams by mapping this no-tation into Z specifications,a language which already has richer semantics.A set of mapping rules is defined to help ensure consistency between the two models.In Section2,below,we present the mapping methodol-ogy between i*models and Z schemas.Section3introduces a methodology for supporting the co-evolution of i*mod-els and Z specifications.Section4discusses how consis-tency is preserved during the co-evolution of i*models and Z specifications.Finally,Section5presents concluding re-marks.2.i*to Z TransformationThefirst step in defining a co-evolution methodology for i* and Z is to define a mapping from i*to Z.We shall be pre-senting results from our earlier work[10,7,6]which has been modified and extended.The sets of all actor names,all actors,and dependency names,all depend,are defined as power sets of the set NAME.Free types STATE(which can be any one of inap-plicable,unresolved,fulfilled,violated,satisficed,denied or undetermined),TYPE(either goal,softgoal,task,resource or ISA),DEGREE(either open,committed or critical)and LINK TYPE(any one of task-decomp,means-ends,con-trib or not applicable)describe the possible states,types and degrees of dependencies and the types of links between the internal intentional elements respectively.The notion of STATE is implicit in i*,but requires explication in Z spec-ifications.The state of an SD model is the set of states of all its de-pendencies.The state of an actor is given by the set of states of all its internal(SR)elements(i.e.,goals,tasks etc.).SDSD state:NAME→STATEdom SD state=all dependActoractor name:NAMEactor element:P1NAMEactor state:NAME→STATEactor name∈all actorsdom actor state=actor elementAs a common pattern for SD dependencies and SR ele-ments,the schemaΦDepend[10,7]is used(theΦin the schema name is used toflag a partial specification[8]). This schema is an operation schema and changes the state of the SD model(∆SD).SDependency schema in-cludes the componentsΦDepend schema as well as names of actors(depender and dependee)which are linked by the dependency.This schema also includes the names of the internal elements(depender internal element and dependee internal element)linked to the de-pendency.The sets actor element depender and actor element dependee are the names of all the in-ternal elements present in the depender and dependee respectively.While this schema represents a general struc-ture,its name,type,degree and names of actors are not specified.It could be done later on during the considera-tion of an i∗model for a specific example.SDependency∆SDΦDependdepender,dependee:NAMEdepender internal element,dependee internal element:NAMEactor element depender:P1NAMEactor element dependee:P1NAMEdependum∈all dependdepender∈all actorsdependee∈all actorsdepender internal element∈actor element dependerdependee internal element∈actor element dependeeSD state =SD state⊕{dependum→result!} Links between internal actor elements as described in an SR model(task decomposition,means-ends,softgoal con-tribution)are represented using thefirst of the following two schemas.The second schema describes the structure of ac-tor internal elements such as tasks,goals,softgoals etc.LinkΦDependint components,ext components:P NAMEcontrib p,contrib n:P NAMElink:LINK TYPElink=task decomp⇒type=tasklink=contrib⇒type=softgoalcontrib p∪contrib n=∅⇒link=contrib∧contrib p,contrib n partitions int componentsext components=∅⇒type=tasklink=NA⇔int components=∅AElement∆ActorLinkdependum∈actor elementint components⊂actor elementext components⊆all dependactor name =actor nameactor element =actor elementactor state =actor state⊕{dependum→result!}Figure1.The Strategic Rationale model for a computer based training systemWe have considered Z schemas represented above as part of one to one mapping of i*models into the Z -ing this approach,all the information from the i*models is reflected in the Z specification.We shall refer to these ba-sic schemas as model schemas.The next step in our methodology is the mapping of spe-cific i*model into Z schemas.Following steps are carried out to realise this goal:i)Names of all the actors and exter-nal dependencies are specified.This is thefirst step in map-ping the SD model of the CBT system.ii)The second step in the mapping is based on the creation of Z schema for every dependency using SDependency schema as a basis.iii)The first step in mapping the SR model is to specify the names of all the internal intentional elements of the selected ac-tor.iv)The second step is the creation of a Z schema for ev-ery internal intentional element using AElement schema as a basis.Schemas for actors,dependencies,actor internal in-tentional elements and the links between them in a specific i*model are defined using these model schemas-we shall call these as element schemas.Considerable detail has been omitted in this section due to space limitations,but exam-ples and full versions of the schemas described can be found in[10,7].The mapping process that we have described so far leads to a Z specification that captures the structure represented in an i*model(and in the instance of states,obliges the an-alyst to represent some additional information as well).A key subsequent step is the refinement of these essentially structural schemas with additional information(r-mation not included in an i*model,but obtained via further analysis-e.g.,temporal sequencing of dependencies,fulfill-ment conditions for dependencies etc).We shall refer to the Z specification obtained after these refinements as the Ex-tended Z Specification.3.Methodology supporting the co-evolutionof i*and ZThe proposed methodology permits the maintenance of loose coupling between an i*model and Z specification(re-fer to Figure2).The strategy we have adopted is to local-ize the impact of changes.The idea is to look at two specific points:-explain techniques for reflecting changes in an i*model in the corresponding(unrefined)Z specification(i.e.,the Z model obtained by directly applying the mapping tech-niques discussed in the previous section to the prior i* model).-explain techniques for reflecting the refinements con-tained in the prior extended Z specification to obtain a new extended Z specification(i.e.,one which contains all of the prior refinements,while reflecting the changes in the corre-sponding i*model).It is worth mentioning here that changes in the i*model only affect the element schemas,but not the model schemas. The solution to thefirst of the identified question(i.e.ob-taining an unrefined Z specification from the modified i* model)is obtained by defining techniques that require ref-erence to the prior i*model and the corresponding prior un-refined Z specification.These are the addition and deletion, respectively,of the following eight elements:Dependen-cies,Tasks,Goals,Resources,Softgoals,Means-end links,Task-decomposition links and Actors.We shall discuss each of these cases in turn.Addition/deletion of a dependency to an existing SD model:i)Addition leads to the creation of an additional element schema for the new dependency(deletion leads to the re-moval of this schema).ii)The internal intentional elements as represented in the SR models for the pair of actors in-volved in the dependency may need to be modified,since all the external dependencies are connected to some inter-nal element of an actor.This change is localized to the fol-lowing simple step:we add(or delete)the dependency name from the ext components set in the corresponding element schema for the relevant internal element.Addition/deletion of a task to an existing SR model:i)Addition will result in the creation of a new ele-ment schema for the task(deletion leads to its removal).A newly added task is typically related via a means-ends link to a goal,or via a task decomposition link to an-other task.Potentially,it may also be related via a soft-goal contribution link to an existing softgoal.Schemas for these links must then also be added along the lines de-scribed below.ii)The element schemas for the goals,tasks and softgoals that this new task might be linked to(as dis-cussed above)need to be modified by adding(resp.delet-ing)the name of the task to the int components set of the corresponding schema(s).iii)The name of the task must be added(resp.deleted)to the actor element set in the element schema for the corresponding actor.iv)The name of the task must be added(resp.deleted)as the value of the depender internal element variable in the schema for any dependency related to the task(should such a relationship be established after the task is added)in which the corresponding actor(into whose SR model the task has been added)is the depender.In a similar fash-ion,the name of the task is added as the value of the dependee internal element variable in the schema of any dependency related to the task in which the corresponding actor is the dependee.v)A downstream effect of the addi-tion of a task in an SR model followed by the creation of a new dependency connecting this task to an internal ele-ment in another actor is that the steps outlined for the addi-tion(resp.deletion)of a dependency(outlined above)have to be followed.Addition/deletion of a goal/resource/softgoal to an exist-ing SR model:We follow steps similar to those described above for the addition/deletion of tasks.Addition/deletion of a means-ends link to an existing SR model:Means-ends links(as with task decomposition links)are not represented via separate schemas,but via the schemas of the internal(SR)elements that they relate.A means-ends link offers alternative means for achieving a given goal(we shall refer to this as the end).In other words,it is effectively the analogue of an OR node in an AND-OR goal graph.The addition of a means-ends link results in the value of the link variable in the element schema for the end being assigned the value means-ends and the int components set in the same schema being defined as the collection of the internal SR elements(which could be tasks,goals or resources)re-lated to the end via the means-ends link.Deletion results in these values being removed.Addition/deletion of a task decomposition link to an ex-isting SR model:A task decomposition link functions as the analogue of an AND node in an AND-OR goal graph and provides a singly,unique means of decomposing a task(we shall re-fer to this as the parent task)into a collection of subtasks, subgoals,resources etc.The addition of a task decompo-sition link results in the following changes to the element schema for the parent task:the link variable is assigned the value task-decomposition while the int components set is defined as the collection of subtasks,subgoals etc.related to the parent task by this link.Deletion results in these val-ues being removed.Addition of an actor to an existing i*diagram will lead to the following four steps:A new element schema for the actor is created.In the in-stance of each internal(SR)element for the actor,the steps outlined above are followed.The same applies for any de-pendencies that this actor might participate in.The solution to the second of the identified question(i.e. the generation of a new extended Z specification given the new set of Z schemas(corresponding to the modified i* model)and the prior extended(refined)Z specification)is obtained by identifying the set of Z schemas in the prior col-lection of(unrefined)Z schemas(obtained from the prior i*model)that were refined in some fashion.We identify schemas with the same names(if they exist,since some might have been deleted)in the current collection of(unre-fined)Z schemas(obtained from the revised i*model),and apply the same refinements to these.This gives us the new extended Z specification.Our aim is to reflect the refine-ments in the prior set of Z schemas(that led to the prior ex-tended Z specification)in the new collection of Z schemas, without having to re-do the refinements.We shall now present an illustration to explain the methodology supporting the co-evolution of i*and Z.This example is based on the CBT system case study.The fol-lowing modifications/additions were performed on the initial i*diagram:Introducing a task Let Training Co-ordinator Schedule Training into the SR model of the actor Training Co-ordinator will lead to the modifica-tion of the original i*diagram(consider that initially this task does not exist in the model)and creation of an ad-Figure 2.Co-evolution of i*models and Zspecificationsditional internal element Z schema(step(i)under task addition of our co-evolution methodology).Based on this action the name of the task must be added to the actor element set in the element schema for the cor-responding actor(Training Coordinator)-(step(iii)). This newly added task is related via a means-ends link to a goal Schedule Training.It is also related via a soft-goal contribution link to existing softgoals Low effort and Quick.Based on the step ii under task addition,the ele-ment schemas for the goal Schedule Training and softgoals Low effort and Quick that this new task is linked to(as dis-cussed above)need to be modified by adding the name of the task to the int components set of the correspond-ing schema(s).The rest of the mapped Z schemas remain unchanged for the modified i*model.We note that a reverse mapping from a collection of Z schemas to an i*model is possible provided the following assumptions hold:i)The Z schemas were obtained from an initial i* model via mapping and refinement along the lines de-scribed above.ii)The prior i*model is available for ref-erence.iii)The integrity of the element schemas are maintained throughout the refinement process,i.e.,refine-ment steps may add to but not modify existing element schemas.Given these assumptions it is relatively sim-ple to identify the named element schemas in a Z specifica-tion and thus reconstruct the corresponding i*model with-out loss of information(any refinements made will,of course,not be reflected in the i*model).4.Preserving consistency in the co-evolutionof formal and informal modelsWhen proposing the co-evolution of two otherwise dis-parate approaches for requirements engineering,we need to maintain consistency between the two approaches.The mapping rules can be viewed as providing formal seman-tics to the i*diagrams by mapping this notation into Z spec-ifications,a language which already has one.We believe that these semantics are largely consistent with the some-what implicit semantics for i*developed in[12].A set of mapping rules is defined to help ensure consistency between the two models.We have proposed a set of mapping rules that constrains the modeler to map the elements of the i* model to appropriate Z schemas and ensures that the two models are consistent.This allows us to trace correspond-ing elements in the two models when changes are made. We are interested in providing a taxonomy of inconsisten-cies that may occur from translating i*models into Z speci-fications(and their co-evolution).The main types of incon-sistencies that may occur when performing the co-evolution of formal and informal models are listed below.The discus-sion on how our methodology provides support to overcome these issues is presented.Structural inconsistency:According to our methodology, it is necessary to introduce Z schemas corresponding to the elements in the i*model.If the Z specification lacks a schema for a certain i*element,the combined model is inconsistent with respect to this regime.In our co-evolution methodology we are keeping the structural inconsistency is-sue under control by strictly adhering to the mapping rules to accommodate any changes.This allows us to keep track of corresponding elements in the two models when changes are made.The mapping process that we have described so far leads to a Z specification that captures the structure represented in an i*model(and in the instance of states, obliges the analyst to represent some additional informa-tion as well).Hence,parsing of Z specifications will lead to one i*model.Likewise,from the given i*model we are in a position to arrive at Z specifications which capture and rep-resent all the structural information contained in the given i*model.Hence,with the help of clear mapping rules and a supporting methodology we are in a position to avoid struc-tural inconsistencies.Semantic inconsistency:As we have explained earlier, the mapping rules can be viewed as giving a formal seman-tics to i*diagrams by mapping this notation into Z spec-ifications,a language which already has richer semantics. We believe that these semantics are largely consistent with the somewhat implicit semantics for i*developed in[12]. Semantic inconsistencies may arise if the creation condi-tions are contradictory;invariants are not maintained.In-consistencies may arise if the default creation condition ofa subgoal of a task decomposition link or a means-ends link is that the parent goal exists,but has not been fulfilled. The fulfillment condition of the parent goal depends on the fulfillment of the subgoals.If the subgoals are connected to the parent goal with means-ends links,then fulfillment of at least one of the subgoals is necessary for the fulfill-ment of the parent goal.If they are connected with task-decomposition links then the fulfillment of all the subgoals is necessary.We have proposed a set of translation rules and guidelines that permit us to systematically derive these constraints.These rules capture the intuitive semantics that we use when designing an i*model.For instance,a tempo-ral ordering or sequencing refinement technique is applied in the Z schema of the parent task in the task decomposi-tion links to include the pre-condition that all of the sub-goals or subtasks are fulfilled prior to the fulfillment of the parent task.This helps us in taking care of semantic incon-sistencies which may arise in the mapping of i*diagrams into Z specifications.Existing tool support for Z,on the other hand,allows analysis of specifications without any additional effort.By making use of formal notation like Z to formalize the i*di-agrams,we are using the customary facilities available for Z like:i)type checking the components ii)proving proper-ties in relation to the components and iii)providing precise rules for manipulating the componentsFor realising above-mentioned objectives,various tools for formatting,type-checking and aiding proofs in Z are available.We are listing some of them that might be used.First of them is CADiZ[5],which is a UNIX based tool for checking and typesetting Z spec-ifications.Zola the WYSIWYG editor is another inter-esting tool,which supports the production and type-setting of Z specifications.Also included are a type-checker and a Tactical Proof System(available from /PRODUCTS/zola.html).The integra-tion of i*diagrams and Z allows one to use Z type checkers like ZTC[3]and Z animation tools like ZANS[4]to anal-yse the models.It is projected to be compliant with the second edition of Spivey’s Z reference manual.For-maliser[1]is a syntax-directed Z editor as well as an interactive type-checker,running under Microsoft Win-dows obtainable from Logica.5.ConclusionWe presented a methodology to support the complementary use of an early-phase requirements modeling notation such as i*with formal specifications,in this instance Z.The issue of preserving consistency in the co-evolution of formal and informal models was discussed in this work.We have not investigated the possibility of articulating semantic consis-tency constraints between i*models(possibly augmented with FormalTropos annotations)[2]and formal specifica-tions.This is the focus of our future work. References[1]Flynn,M.,Hoverd,T.,Brazier,D.Formaliser an interactivesupport tool for Z.Z User Workshop,Oxford,1989,Nicholls, J.,Ed.New York:Springer-Verlag,1989,pp.128-141[2]Fuxman,A.,Pistore,M.,Mylopoulos,J.,Traverso,P.Modelchecking early requirements specifications in Tropos.Pro-ceedings of Fifth IEEE International Symposium on Require-ments Engineering,Toronto,Canada,August27-31,2001, pp.174-181.[3]Jia,X.ZTC:A Type Checker for Z er’s Guide.Version2.03,August1998.Division of Software Engineering, Telecommunication and Information Systems,DePaul Uni-versity,USA,1998.[4]Jia,X.An approach to animating Z specifier’sGuide.Division of Software Engineering,School of Com-puter Science,Telecommunication and Information Systems, DePaul University,USA,1995.[5]Jordan,D.,McDermid,J.A.,Toyn,I.CADiZ ComputerAided Design in Z.5th Oxford Z User Meeting,Springer-Verlag Workshops in Computing,December,1990,pp.93-104.[6]Krishna,A.,Ghose,A.K.,Vilkomir,S.Co-evolution of com-plementary formal and informal requirements.Proceedings of IWPSE2004(held in conjunction with RE04-12th IEEE International Requirements Engineering Conference),Kyoto, Japan,September,2004,pp.159-164.[7]Krishna, A.,Vilkomir,S.,Ghose, A.K.A case study ofcombining i*framework and the Z notation.Proceedings of ICEIS-2004:The6th International Conference on Enterprise Information Systems,Porto-Portugal,April,2004,pp.192-200.[8]Spivey,J.M.The Z Notation:A Reference Manual.PrenticeHall International Series in Computer Science,2nd edition, 1992.[9]Unni,A.,Krishna,A.,Ghose,A.K.,Hyland,P.Practical earlyphase requirements engineering via agent-oriented conceptual modelling.Proceedings of ACIS-2003:The2003Australasian Conference on Information Systems,Perth,Australia,Novem-ber26-28,2003.[10]Vilkomir,S.,Ghose,A.K.,Krishna,bining agent-oriented conceptual modeling with formal methods.Proceed-ings of ASWEC-2004:The2004Australian Software Engi-neering Conference,Melbourne,Australia,April,2004,pp.147-155.[11]Wang,X.,Lesprance,Y.Agent-Oriented Requirements En-gineering Using ConGolog and i*.Proceedings of3rd Inter-national Bi-Conference Workshop Agent-Oriented Informa-tion Systems(AOIS-2001),Berlin,Germany,2001,pp.59-78.[12]Yu,E.Modelling Strategic Relationships for Process Reengi-neering.PhD Thesis,Graduate Department of Computer Sci-ence,University of Toronto,Toronto,Canada,1995.。