ABSTRACT
 
 

In this work we present some guidelines for the integration of organizational requirements and functional requirements of sys tem. For the organization modeling we use the i* technique, it allows a better description of the organizational relationships among the various agents of a system as well as an understanding of the rationale of the decisions taken. For the formal functional specification of the requirements we use at present Structured Modal Action Logic (MAL). We demonstrate the approach by means of an example of a mineral water factory.
 
 

1. INTRODUCTION

¹ Supported by CNPq grants n. 301052/91-3= (RN) and 520674/93-6 (RN)

motivations involved . Only recently goal oriented t= echniques that support multiple agents have been proposed in the literatu= re. Among these, we choose the i* approach [2].
 
 

In our work we address the issue of requirements for= malization. In particular we show some guidelines on how to transform org= anizational requirements (i*) into a pre-formal specification (Structured= Modal Action Logic [3] - MAL++) to provide an initial systems specificat= ion. Throughout the paper we make use of a mineral water factory as an ex= ample, to describe the approach and benefits.
 
 

In Section 2, we provide a brief revision of the mai= n characteristics of Structured Modal Action Logic. Section 3 presents th= e main characteristics of i* framework. Section 4 presents the organizati= onal model of the case study. In Section 5 we give some guidelines to int= egrate the organizational approach with the functional one. Section 6 pro= vides some related works. Section 7 concludes the paper with a discussion= of the contribution.
 
 

1. STRUCTURED MODAL ACTION LOGIC

Modal Action Logic - MAL is based on Typed First Ord= er Logic. It includes types, variables, logical symbols, predicates, func= tional symbols, constant symbols, terms, atomic formulas and a number of = axioms and inference rules. MAL++ is an extension of MAL the has added: (= a) pre-defined types called "agents" and "actions" that respectively defi= ne real world entities and describe processes that the agents can execute= ; (b) the modality [ ] to capture the effect of the occurrence of actions= , i. e. [action a] can be considered as the post-condition or resu= lt of an action a that has been completed; (c ) deontic operators = per (permission) and obl (obligation) that allow the contro= l over what action can be executed by the agents; (d) combinators ; and (= e) interval temporal logic of branching linear type. Therefore, a structu= red MAL specification corresponds to a set of agent (object) descriptions= , where the descriptions consists of a set of declarations and axioms tha= t define the behavior of the agents that can interact sharing attributes = and actions (label s - shared). Some attributes or actions have on= ly local effects and are labeled l - local.
 
 

1. THE I* TECHNIQUE

The Strategic Dependency Model (SD) consists of a se= t of nodes and links connecting them, where nodes represent actors and ea= ch link indicates a dependency between two actors. Hence, a process is de= scribed in terms of network of dependency relationships among various act= ors, capturing the motivation and why of activities. We can distinguish, = four types of dependencies, three of them related to existing intentions = - goal dependency, resource dependency and task dependency - while the fourth is associated with the not= ion of non-functional requirements, the so called soft-goal depende= ncy. In the goal dependency, an agent depends on an= other one to provide the desired condition, and it does not worry about h= ow this condition is achieved. In the resource dependency, = the agent depends on the availability of physical resource or information= =2E In the task dependency, the agent informs the other wha= t (and how) should be done. The soft-goal dependency is sim= ilar to the goal dependency, except that the condition is n= ot precisely defined at the start of the process, i.e., the goals in a se= nse involves subjective aspects, that gradually are clarified during the = development process. This type of dependency provides an important link c= onnecting two important aspects in software engineering: (i) the technica= l and (ii) managerial side. We still can identify different degrees of de= pendencies: open, committed and critical [4]. We can also distinguish = agents, roles and positions [6].
 
 

The second model is the Strategic Rationale Model (S= R) that is used to: (i) describe the interests, concerns and motivations = of the process participants; (ii) enable the assessment of the possible a= lternatives in the definition of the process; and (iii) research in more = detail the existing reasons behind the dependencies between the various a= ctors. Nodes and links also compose this model. It includes four types of= nodes (also based on the previous SD model): goal, t= ask, resource and soft-goal. There ar= e two types of relationship, means-end that suggests that t= here be other means of achieving the objective and task-decompositi= on that describes what should be done in order to perform a certa= in task.
 
 

The i* framework, provides a description, that can b= e further refined if necessary, of the intentional aspects of the actors = that are considered strategic for the clear and complete comprehension of= software process.
 
 

4. THE CASE STUDY: MINERAL WATER FACTORY
 
 

In this section, we present a case study using a= s example of real mineral water factory. Our intention is to present the = i* framework and to migrate from an organizational model to a functional = model that is a more precise and complete specification of the system. Fi= rst we present the Strategic Dependency (SD) model and then we construct = the Strategic Rationale (SR) model.
 
 

In the Figure 1, we have the SD model of the mineral= water factory. The Client wishes to have his bottles filled with mineral= water (goal-dependency) as well as to have it done safely = (softgoal-dependency), i.e., that the water to be appropria= te to drink. The Company wishes the satisfaction of its client concerning= the quality of its services (softgoal-dependency). In orde= r to maintain its costs the Company wishes the Client to pay for its serv= ices (resource-dependency). From the Client=92s viewpoint h= e/she wishes to be serviced quickly (softgoal-dependency) b= y the Worker and to receive his/her bottle filled with mineral water (= resource-dependency). For this the Client depends on the Worke= r to pass the bottles according to some procedures (task-dependency= ). The agent Worker also depends on the Company to maintain safe = his working conditions (softgoal-dependency) and at the sam= e time the Company depends on the Worker to maintain the quality of the s= ervice (softgoal-dependency). The Worker depends on the Com= pany for wages (resource-dependency). The Worker depends on= the Client to delivery the bottles empty ( resource-dependency= ) and in a good state (softgoal-dependency).
 
 

In our example, the agent Worker has several roles. = There are intentional relationships among agents and roles as well as amo= ng roles and roles. Due to space limitatio= ns we will only describe one agent (see Figure 2). The chosen agent is th= e worker that has the role of "Do External Cleaning". This agent depends = on other agent ("Do Inspection") to pass the dirty and empty bottle that = was counted (see Figure 1). We now realize that the initial model needs t= o be refined to include a new dependency "Counted Bottles" (resourc= e dependency) (see Figure 2). The agent "Do External Cleaning" is= responsible for receiving the counted bottles, and doing the visual insp= ection task (a task-decomposition of the task "Receive Bott= les"). The visual inspection consists of two alternatives: (i) If there i= s any problem with the bottle this agent will "Return the Bottle" to the = Client; (ii) else he will make the cleaning of the bottle (here we can se= e a means-end relationship). The task "Make Cleaning" consi= sts of: removing the residue of the company label ("Remove Label"), seali= ng wax ("Remove Sealing Wax") and the bottle=92s cap ("Remove Cap"). It a= lso passes the cleaning bottles ("Pass Cleaning Bottles") to the agent "D= o Washing", as can be seen Figure 2. Again we have to add a new resource = in the our original model, i. e. "Cleaning Bottles" (resource depen= dency).
 
 

Many other details are also important, but due space= limitation we will fix our attention in the agent "Do External Cleaning"= making the integration with MAL in the next section.
 
 

1. GUIDELINES ON THE INTEGRATING I* AND STRUCTURED MAL

Part of the concepts employed in the i* technique ca= n be directly translated into structured MAL
 
 

Fig. 1 - Strategic Dependency Model of the Mineral wa= ter factory
 
 

Fig. 2 - Strategic Rationale Model of the Mineral Wat= er Factory
 
 

Guideline G1:

Agents in the strategic models can be tra= nslated as Objects in MAL. For exeample, Agent "DoExternal Cleanin= g" corresponds to Object "DoExternal Cleaning".

=

Figure 3 - Object Definition

Guideline G2:

The resources will be mapped :
=

Figure 4 - Object=92s Attributes and Actions

Guideline G3:

The tasks will be mapped into actio= ns in MAL. That axioms will describe their effect. We can = observe in Figure 2, Agent "DoExternalCleaning", that the task "ReceiveBo= ttles" requires a "VisualInspection" that might result in "MakeCleaning" = or "ReturnTheBottles". These tasks will be mapped (see Figure 5) into the= corresponding actions. Also note in Figure 2 that the task "MakeC= leanig" can be decomposed into four sub-tasks (RemoveLabel; RemoveSealing= Wax; RemoveCap; and PassCleaningBottles). Due to space limitation we have= not translated them in Figure 5, neither dealt with exceptions and other= more complex situations. For other case studies see [7] [8].

 In the real world, during the requirements eng= ineering process the engineer can iterate navigating between the i* model= s (SD and SR) and the MAL specification, enabling him/her to cope with th= e impacts of each description. The two levels of description (organizatio= nal and formal specification) have enabled us to adopt different concepts= of agent at each level, each one is appropriate to the kind of modeling = and reasoning required at each stage. At the level of organizational rela= tionships, it is necessary a notion of agent that is flexible enough to e= xpress the freedom that agents have to violate restrictions and commitmen= ts. At the level of formal requirements specification, a prescriptive vie= w is more appropriate than a descriptive one.
 
 

1. RELATED WORK

Figure5 - Object=92s Axioms

 Another related work is that of Yu, Du Bois, D= ubois and Mylopoulos [4], in which they relate the i* to the ALBERT [9] f= ramework. The authors describe how the Albert and i* can work together. T= hey adopt explicitly a set of intentional concepts with a precise semanti= cs related to the ALBERT language.
 
 

In KAOS [10] all goals are explicitly modeled and ar= e simplified (reduced) through means-end reasoning until it reaches the a= gent level of responsibilities. Agents should behave as prescribed, which= makes it difficult to analyze strategic relationships and implications.<= /P>
 
 

Various other organizational modeling techniques and= formalization have been proposed in the literature [5] [11] [12]. The de= pendency concept has also been used for the coordination of organization = [13].
 
 

One of the reasons for choosing the MAL language in = this work is our previous experience with the formalism in the context of= the FORMLAB project [14] and MULTIVIEW environment [15] [16].
 
 

1. FINAL CONSIDERATIONS

The i* technique has provided some means for modelin= g adequately the requirements of a system, dealing mainly with non-functi= onal aspects that traditionally have not been well represented in the exi= sting conventional models. However, for functional requirements descripti= on, another technique is required. In this work we gave some initial guid= elines to integrate the descriptive model of the i* technique with the pr= escriptive model of the structured MAL logic, which enable a more precise= specification in terms of an action logic. The benefits are many and inc= lude the possibility of the animation of specification that would help th= e validation of requirements, and the potential for formal reasoning of t= he desired system properties.
 
 

Some tools support these techniques. For the i* tech= nique there exists the OME, while for the MAL language, the MULTIVIEW env= ironment [16] allows the generation of MAL specifications, guided by he V= SCS Method. However, future work is still required for the integration of= these tools under a single environment.
 
 

8 . REFERENCES