Using a Controlled Language in Spanish to specify ...

Using a Controlled Language in Spanish to specify the architectural design of a Multiagent System ⏐

Juan Carlos González Moreno and Luis Vázquez López Departament of Computer Science University of Vigo [email protected] [email protected]

Abstract In recent years it has tried to experience a major boom Software Engineering, at the initial stage, to get the Model Requirements and Objectives of the problem to solve. We seek to achieve this as quickly as possible and the time it is complete, that is, with all the particulars that present the problem to solve. This rise is due in part to the emergence of new methodologies based on the use of tools to support the process of development partner and tried to automation of this phase. Normally models of the problem tend to be biased by the knowledge of specific equipment analysts involved in the development. The automation of the process avoids this difficulty and reduces the times, but we need a high level of participation by the customer / user. In recent years, the field of elicitación requirements has been the subject of numerous works, almost all linked to the object paradigm, and with the ultimate objective of achieving specifications less ambiguous and more accurate. This paper focuses on the field, making a proposal that actively involves the client in the development process, in our case for INGENIAS and can be adapted to other methodologies or production environments which have a characterization based on similar principles.

1. Introduction Moreover based management processes (Business Process Management) have gained popularity and deployment in recent years in many organizations. The companies have changed their management model, based management departments to a horizontal managementbased processes. This has led to structural changes that perhaps the most significant is the replacement of the measure of the efficiency of the departments by the measure of the efficiency of the process [15]. As for the implementation of an information system, its realization is always an expensive task that involves a lot of effort. Thus, the presence of environments automated software provides a great advantage when it comes to deal with this work, because it represents a significant savings in both material and temporal. Within this field can be stress-OO Method [26] and its commercial tool

[3], an approach for modeling information systems with a formal semantics that allows the generation of complete applications from conceptual models. OO-Method generates application code based on a conceptual model of information system, in [33] extending OO-Method with a layer initial early modeling requirements (organizational) and late (Information System). Another interesting proposal is INGENIAS [27] is a recent methodological proposal for the development of applications based on multi Systems. The proposal has a good definition of the elements of modeling in which it is based, uses an amendment to the Unified Process Development for its life cycle and allows obtaining consistently, and correctly executable code traceable to the requirements modeled [16 ]. In order to generate code automatically specification on starting out, you have to integrate all the features of the organization and not to be ambiguous, that is, it is deemed necessary for a full specification of requirements to be met by the system, defined Based on the infrastructure business which owns the organization and who will lead the post conceptual modeling. Thus an organization has a method that allows you to have aligned its information system and its strategy, key to business success [23]. It should be noted that the process of generating the conceptual model is not fully automatic, none of the proposed systems, both as INGENIAS OO-Method and to be completed manually. To avoid the need for manual development models that develop a solution to the problem, is that the proposed system through a very active involvement by the client avoids a significant participation of the analyst. It proposes an iterative process with the customer / user, which can describe this in writing and in natural language (in his own words) the problem we want it solved. The various iterations (do not need the involvement of the analyst) actively engage customers in the development process (can be made against the system by the customer from any location) and are accurate to better understand

1

the domain of the application, the problematic and also to disambiguous vague descriptions or impersonal. At each iteration the text introduced undergoes an analysis and subsequent transformation process leading to the award of problem a model based on INGENIAS. A model obtained from the engineer or analyst tool with which it will develop the product, one can begin to shape a solution that will include architectural adequate and appropriate solutions which will be linked to each problem (objectives) raised by the client / user, making it easier debugging, testing and maintenance of development. The reason for choosing INGENIAS and non-OO Method is that the latter tool is commercial and is based on UML diagrams, which are not adjusted to all kinds of problems, for example System MultiAgent does not tend to use UML notation because not based on the element modeling given by the binomial object / interface, but the team roles / agent [9], [16]. The rest of the article has been structured as follows: The second section is devoted to briefly describe other work related to the proposal, an overview for the proposed model described in section 3. The following section presents an example of model proposed in XML. It continued with the proposal specifies NLP4INGENIAS specifically, section 6 makes a series of findings and future work, and lastly the classical sections of acknowledgements and references.

2. Related Works In [17] presents a procurement process requirements for INGENIAS, from natural language descriptions in Spanish, based on the discovery of targets and agents / roles. The part of a process of linguistic processing you gets a lot of information. Because much of the information is redundant or not prosecution are considering transforming the text entered by the user to a controlled manner (in a manner transparent to the user). They intend to develop a knowledge base of their own domains resolve to avoid, as far as possible, conducting much of the analysis in cases where domains are introduced and studied in specifications or similar in functionality . The shortage is that it presents the conceptual framework does not extend to all phases of software development, but explained that what they are trying to solve is obtaining models automatically currently existing tools left to be done so handbook. The model obtained from the system could be integrated into any existing tools, which would cover the remaining phases of software development. Its integration into INGENIAS is almost automatic. Other works aim to resolve the approach for obtaining the requirements from an approach stressing integration of different tools [33] to address the problem of alignment

uses a significant use of approaches and models that facilitate their understanding and solution. Reutilise and combine proposals success in its corresponding application framework that has been widely tested. They propose a combination of strategic alignment model (SAM), with the business of Zachman, and the methodology for automatic generation of code-OO method. Connect the world of modelling with the organizational world of software development through the adaptation and interpretation of the cells in the architecture business Zachman. Thus each of the actors involved employs models of their own area of work. Moreover, integration with an environment of automatic generation of software accelerates the achievement of the alignment, eliminating many of the traditional stages of the software development processes, and the necessity to define many of the business models of architecture. This idea is developing which only this proven its reliability in a number of cases. Concerning the use of the Zachman framework to address strategic alignment, [24] provides an approximation of alignment on this architecture which distinguish four different sizes (architectures business, application and technical information) and defines various categories of alignment that contribute the global (business processes and information, business processes and applications, applications and information, IT and information, and applications and TI) with rules of consistency within them. Steven Bleistein has done several jobs to solve strategic alignment. SOARE [3] is an approach designed to allow the alignment between requirements for business systems and electronic business strategy to which should provide support. Stop it provides tools to analyse and decompose the business strategy with the use of modelling targets to represent both the strategy, in a context of engineering requirements, such as linking the strategic goals with requirements for low level through the refinement of the . The process consists of following phases: understanding of the overall business strategy, identifying business models, the selection of models goals (suitable for the requirements), the identification of the business strategy (to take competitive advantage ), the creation of a model goals of the business strategy (also to take competitive advantage), the integration of the models created, and finally, the refinement of the model targets. Bleistein also has proposed modelling goals and diagrams challenged and validate the strategic alignment of organizational IT requirements [4]. In [19] describes a solution based on two distinct processes on the one hand with the help of disambiguous identified in NL RSs. In the first step, T1 would be used to determine the level of ambiguity in a RS sentences (prayers) potentially ambiguous in the RS. In the second

2

step, T2 determine which of these potentially ambiguous RS are. The paper describes the use of a prototype script for the passage T1 and a prototype simulation for T2 manual with the aim of exploring their potential. The use of prototypes to a small group of RS and ABCVPS proposes a solution on the requirements for T1 and T2. Additional experiments have been conducted to determine other requirements for T1 and T2 [25]. It is in the preliminary stages and lack identifying assessment tools in an appropriate manner. In this article, [32] described the latest guidelines for preventing Ambiguities in NL RSs have found that on the basis of analysis of several industrial projects RSs. As partial validation of the new rules, the paper gives some examples of ambiguous phrases of RSs and rewriting, in a less ambiguous. They hope to further explore industrial projects RSs to find additional rules. It is developing a system Systematized an environment Requirements Engineering (SREE) that seeks potentially Rstats ambiguities. And it offers suggestions for rewriting each potential ambiguity. Rstat is based on the effectiveness of SREE and will be validated their application in industrial projects RSs. The lack of uniformity and differences of the main characteristics of the different problems to solve directors makes the rules are a little disconcerting. However, these guidelines aim to cover the kind of ambiguities found in RSs real industry. Of course, the method by which standards are chosen makes it difficult to assess if enough standards encountered. Probably, there is no limit to the number of rules. However, they hope that at some point, the rate of addition of new standards will diminish considerably, just as it did not begin to find new types of ambiguity. In part, this work is complementary to all other works cited in Section 2 of article cited that try to find ways to detect or avoid ambiguity. KAOS permits to build models of requirements from the organizational goals. This approach is supported by a formal framework that defines each term rigorously. The main contribution of KAOS is demonstrating that the conditions correspond to the goals of the future system. The main drawback is that it provides no mechanism to represent the structure of the organization and as a result does not make, for example, an analysis of process reengineering. Moreover, in previous editions of WER have submitted articles in similar lines of research. On the one hand, [34] intends to make the elicitación requirements from business processes and its goals, but I do not know operational decomposition of the goals. On the other hand, [12] and [31] put forward proposals for the automatic generation of models use cases from models of business processes and to guide the case definition from organizational models defined in * respectively, but we

would have the disadvantage that the models that generate use cases are too complex and in the case of multiagent systems model use cases is a model secondary. Article [10] presents an approach that enriches approximations based development goals with a model of processes, proposing a set of guidelines or heuristics to divert a model of requirements based on a model processes using a tree intermediate targets. The proposal allows developers to identify in a systematic way and participatory (as it involved various actors such as business managers, analysts and analysts organizational information systems) system requirements that will support the organization. In addition, the proposal ensures alignment between the business strategy of the organisation and its information system, thanks to the traceability between the various models. The latter requirements are defined from the goals of the business processes, which in turn are based on the strategic goals of the organization. At present, the work is being applied to other case studies to assess the scope of the method and the heuristics proposals. [35] This work is part of a broader project which aims at the analysis of important aspects of the needs identification and modelling of multi-agents. In this study the goal was to provide a qualitative assessment of the methodology used ADELFE suit and the proposed framework Yu Cysneiros [36]. ADELFE has a great set of modelling concepts Agents cooperation covering different situations of the requirements, analysis and the phases of the project. With a well-defined process. However, the methodology has to improve certain aspects of the traceability of requirements and the identification of the shares. The medium where it develops can be improved by the addition of new modelling diagrams that may objectives, a plan and organizational aspects in the early months of the requirements. Summarizing indicates that the first problem that we must address now to generate models to solve the problem is to grasp adequately solve the problem. In this process, the ambiguity of natural language is a problem [7] it difficult to interpret the requirements of the domain of the problem, resulting in inappropriate responses or customer dissatisfaction with the solutions and not allowing fulfil the objectives of the organization . In order to alleviate these problems has been proposed within the so-called Requirements Engineering process Elicitación Requirements that can be defined as "the process of acquiring all knowledge is important and necessary to produce a model of requirements in a domain problem" . The idea behind this process is that only after understanding the nature, characteristics and limitations of a problem, you can generate a specification of the minimum quality requirements to be developed and

3

validated with the user. Within this area you can find many suggestions to extract all relevant information in developing software requirements from texts written in natural language [34]. Usually, these solutions are based on reformulating descriptions of the problem through natural language subsets of the employee or using semi-formal languages, from which apply processing techniques lead to obtaining and / or appropriate deliverables that can be validated both by the user / client and the development team. These proposals improve the quality of the model obtained and try to shorten development time (one of the critical factors in modern software development processes), but are faced with the difficulty of the active involvement of customers / users in the life cycle the application (very important and widely recommended by modern development processes).

of the system in agents / roles. The aims are associated with cases of use described by means of scenes in those who develop individual tasks and interactions among the identified agents / identified roles. As the initial other that raises us the client / user to solve the problem is going to realize it in natural language not to force this one to have to be able to interpret the methodology of development, which in many cases would be so or more complex than the solution to the raised problem. Doing it in natural language, raises as

3. Our Proposal INGENIAS [27] The goal-model appear of separated form being the agent's goal-model the one that describes particular agents and the mental conditions in which they will be along his life. Goal-model of tasks and objective it is used to associate the mental condition of the agent with the tasks that he executes. The goal-model of organization defines how the agents gather in crowds, the functionality of the system and which restrictions are necessary to impose on the behaviour of the agents. The goal-model of interaction details how the agents are coordinated and communicate and the goal-model of environment define what exists about the new system and how every agent perceives it. In [17] a study of the elements has been done of shaped used by the main methodologies of Systems multiagent and the unification of criteria appears of what is understood by each of the elements of shaped in our case. The system raised multiagent is going to arise on the basis of the aims of the system and the first organization

Figure 1 - Organization Model

principal disadvantage the possibility of that present ambiguity that is going to be solved by the involvement of an active way on the part of the client / user in the different phases of the process of product development, with this there are also going to avoid possible forgotten of characteristics that it must have the product or in coherences of what must have the end product developed with regard to the first realized description. In the process of acquisition it differs between the aims [14] of the System that indicate what is tried to obtain by the development, and the aims of an Agent who is what has, needs or this agent wants to reach to satisfy or to help to satisfy an aim of the system. As for the roles they are characterized as the set of actions that determine a distinctive behaviour of an agent. [6]When multiagent [18] refines [5] the graph of the system the roles they are constructed in cases of use that are in use for solving the

4

aims indicated by the role. If the aims to resolving are a complex at the time the subsystems can be used as elements of refinement. On the other hand, the Roles realize Tasks that cover Activities and that satisfy the aims to resolving. In general the identification of all these elements of shaped comes from interviews, between the client and members of the equipment of development (analysts, engineers of requirements...) that remain reflected as descriptions in natural language in most of the cases. In the process of identification of elements of shaped of the system multiagent from a description of text in Spanish the following characteristics are born in mind: The agents [17] are going to be extracted from the own names, the objects and the subjects of the passive verbs of the description. The cases of use are going to correspond with the lexical verbs, due to the fact that the verb of the prayers that defines a case of use must be transitive. An idea similar to it, is the used in marked automatically of texts raised in [8].

condition of common names. The interactions between agents it is a complex process but possibly they can be established in phrases in which several fastened (agents / roles) appear in active phrases that are in the habit of denoting collaboration and/or cooperation. As for the identification of concrete tasks and scenes associated with a certain aim, the importance of an active it is necessary to realize in general in later iterations with the user in which it specifies this one with more detail the actions, relations and meaning of certain verbs and names. With which returns to be indicated participation active on the part of the client / user.

The aims are going to be the verbs that are in subjunctive way and the verbs in gerund or participle. The verbs when gerund and participle or subjunctives way are in the not personal forms are in the habit of indicating reached achievements or in phase of attainment, that it is the definition of object that it is going to handle. The roles are going to be identified analysing the subjects of the phrases in which aims are identified, with the

Figure 3 - Tasks and Goals Model

Figure 2 - Interaction Model

5

Our shaped architectural it goes from the Model NLP4INGENIAS presented in [17] whom might be summarized of the following way: Departing from a description in an electronic suitable format, a linguistic processing of the same one is done. Consisting of a morphologic analysis, a parsing and the alteration of the text in case of some mistake be detecting during the morphologic or syntactic analysis. Resting on an approach example STILUS [28]. Due to this alteration sometimes the collaboration of the user is necessary. Finished this part of the process is obtained for each of the tried words: his type, his motto and his function inside the phrase that can store in format table, if it considers it to be suitable. Now already it is in conditions to do the process of extraction of the entities of the system consistent multiagent in: The compound phrases are simplified using a few own rules of production. This process consists of being seeking for the verbs of request and to leave every verb with the corresponding complements as if it had been enunciated as a simple request. Another possibility that is being studied at this moment is the raised one in [20] by means of the marked one with the words in the own text. With which he avoid the step 5 that he are to realizing. The aims are identified following the criterion mentioned before: "the verbs are looked in gerund or participle and the infinitive verbs in phrases desiderative and conditional ". It is possible to see more information since the aims of a description obtained in [1], [22]. It is looked the lexical verbs that determine the cases of use of the system. These verbs are those which are in indicative and that do not form a part of a verbal periphrasis. Later there are identified the own names, the objects and passive subjects of the phrases that the agents / agents of

the system determine. The roles associate to the subjects of adjectives or qualified names. Transformation of the description of transparent form for the user to controlled language. [38] Once extracted [37] the entities of the system multiagent it is necessary to verify the existence of entities repeated (synonymous, antonyms): if they have the same value they are eliminated and if it is different the order of appearance is verified, taking like correct the first appearance. Once extracted the entities of the system multiagent it is necessary to verify the existence of entities repeated (synonymous, antonyms): if they have the same value they are eliminated and if it is different the order of appearance is verified, taking like correct the first appearance. Now he is already in conditions to indicate which is going to be the agents architecture that it is going to use for our system for the generation of the first phases of the process of the development of the cycle of life of the product requested by the client/user. I will consist as minimum of the following agents, agent user who is going to be the manager of intergesticulating with the client/user, taking the description that this gives us the problem and to intergesticulate along the whole development. Another important agent in the process is going to be the Agent Phrase, manager of the morphologic and syntactic analysis of the text introduced by the client, due to the complexity that has this phase, more than an agent in I make concrete, it can be speaking again about a System Multiagent. Where there might be an agent for the phase of the morphologic, different analysis for syntactically, different for the division of phrases composed in simple phrases, other one for search of the definition of the meaning of a word inside the domain that it is working...

Figure 4 - Initial Model of Agents

6

There should also be an agent analyst who would be the manager of integers articulating with the analyst responsible for the development in order that this one checks the analysis done of almost automatic form. And it is indicating the necessary modifications to conclude in an analysis and successful design. Due to good coordination of all the agents there is necessary an agent that can name principally in order that it solves the convicts of interests that appearing between the different agents. This agent would also be the manager of realizing the distribution of the work. To indicate that in the Agent Model describes single agents, their tasks, goals, initial mental state, and played roles. Moreover, agent models are used to describe intermediate states of agents. These states are presented using goals, facts, tasks, or any other system entity that helps in its state description. This way, an agent model could represent in which state should be an agent that starts a negotiation. It is also necessary to stand out Environment model defines agent's perception in terms of existing elements of the system. It also identifies system resources and who is responsible of their management. The advantage that give us an automatic system [30] [29] as the raised one, is that it allows us to take without problems several projects different from a simultaneous way without there exist interferences of domain of a problem with other one, since they are done in an almost autonomous way by a very scanty participation on the part of the analyst.

4. Model of Example Every XML document contains mandatory and optional parts, in addition to having to follow an order. An XML document is composed of the foreword and the body of the document. Prologue Though not compulsory, XML documents can start with a few lines describing the XML version, the document type and other general issues. The prologue contains: An XML declaration. It is the decision which declares to as an XML document. A document type declaration. Connects document with your DTD, or it can be included in the declaration itself, or both simultaneously. One or more comments and processing instructions. Corps Unlike the prologue, the body is not optional in an XML document, the body must contain one and only one root element, a feature essential to enable the document is well formed. Elements The XML elements can have content (more elements,

characters or both), or elements to be empty. Attributes The elements may have attributes, which are a way to incorporate characteristics or properties to the elements of a document. Must be in quotation marks. Entities predefined Entities to represent special characters not to be interpreted as marked on the XML processor. CDATA Sections It is a XML to specify data using any character without being interpreted as marking XML is only used in the attributes not to be confused with 2 (# PCDATA) which are for elements Comments Comments by way informative to the programmer or designer to be ignored by the processor. The comments XML have the following format: Parties XML document used in the model. The XML document will contain a Prologue, although it is not compulsory, is believed to be important as it will save information from the XML version I know this to be used, the number of revisions that I know this to be carried out in document, the project properties, and so on. The Prologue will be: