A practical guide to Message Structures: a modelling technique for information systems analysis and design
Despite the increasing maturity of model-driven software development (MDD), some research challenges remain open in the field of information systems (IS). For instance, there is a need to improve modelling techniques so that they cover several develo…
Authors: Sergio Espa~na, Arturo Gonzalez, Oscar Pastor
Informe Técnico / Technical Report Ref. #: ProS-TR-2011-0 2 Title: A practical gui de to Message Structures : a modelling t echnique for inform ation systems analysis an d design Author (s): Sergio España, Arturo Go nzález, Óscar Pa stor, Marcela Ruiz Corresponding autho r (s): Sergio Esp aña sergio .espan a@pros.u pv.es Marce la Rui z lrui z@pros .upv. es Documen t versio n numbe r: 2.0 Final version: No Pages: 30 Release date : Februa ry 20 11 Key words: Informati on system s, analysi s, desig n, requi rements engin eering, model-driven develo pment, Mess age Structures, Comm unication Analysis A practical guide to Message Struct ures: a modelling technique for information systems analysis and design Sergio España, Arturo Gonz ález, Óscar Pastor, Marcela Ruiz Universid ad Poli técnic a de Va lenc ia · Cami no de V era s/n · Edi ficio 1F · 46022 Valencia Spain · T . +34 96 387 70 07 E xt. 83530 · M . + 34 619 543 6 23 · F. +34 96 38 7 73 59 · info @pros .upv.es · w ww.p ros.upv.es MESSAGE STRUCTURES: A MODELLING TECHNIQU E FOR INFORMATION SYSTEMS ANALYSIS AND DESIGN Authors (in alphabetic al order): Sergio España, Ar turo González, Óscar Pastor, Marcela Ru iz This document is born as an extended version of a paper presented in the 14 th Workshop on Requirements Engineering ( WER 2011 ). If you int en d to cite Message Structures in a scientif ic paper, please use the following re ferenc e: A. Gonzál ez, M. Ruiz, S. España , and Ó. Pastor, "Message Structures: a modell ing technique for informat ion syst ems analysis and design." In: 14th Workshop on Requirem ents Engineerin g (WER 2011), Rio de Janeir o, Brazil, 2011. ESTRUCTURAS DE MENSAJE: UNA TÉCNICA DE MODELADO PARA EL ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN Autores (por orden alfabético ): Sergio España, Ar turo González, Óscar Pastor, Marcela Ru iz Este doc umento nace como una versión extendid a de un artículo presentado en el 14 Workshop en Ingeniería de Requisitos ( WER 2011 ). En caso de querer citar las Estructuras de Mensaje en un artículo científ ico, se debe usar la siguiente referencia: A. Gonzál ez, M. Ruiz, S. España , and Ó. Pastor, "Message Structures: a mode lling technique for informat ion syst ems analysis and design." In: 14th Workshop on Requirem ents Engineerin g (WER 2011), Rio de Janeir o, Brazil, 2011. TABLE OF CONTENTS I. .. ENGLISH VERSION .............................................. ........................................ ... 1 1. I NTRODUCTIO N .......... ..................... ...................... ..................... .................. ............ ... 1 2. O VERVIEW OF C OMMUNICATION A NALYSIS ............ ................... ........... ...................... 1 3. M ESSAGE S TRUCTUR ES ........ ............ .................. ............ ..................... ..................... . 2 3.1. Grammatical construc ts ............... ............... .............. .................. .... 3 3.2. Field spec ific at ion ............................ .................. .............. ............... 4 4. U SAGES OF M ESSAGE S TRUCTURES ..... ...................... .................. ............ ................. 5 4.1. Creation and usage of Me ssage Structures in analys is time .......... 5 4.2. Usage of Message Structures in design time . ............... .................. 7 5. T ECHNOLOGICAL SUPPORT FOR M ESSAGE S TRUCTURE S ............ ..................... .......... 8 5.1. Support to Message Structures wi th Xtext ...................... ............... 8 5.2. Support to Message Structures with Eclipse Mode ling Framework9 6. R ELATED WORKS ............. ................... ............ ..................... ..................... ............... 11 7. D ISCUSSION AND FUTURE WORK ........... ............ ..................... ................... ............ ... 12 II. . VERSIÓN EN ESPA ÑOL ........................................ ........................................ . 13 1. I NTRODUCCIÓ N .............. ......... ............ ..................... ..................... ..................... ...... 13 2. P ERSPECTIVA GE NERAL DEL A NÁLISIS DE C O MUNICACIO NES ................. ........... ...... 13 3. E STRUCTURA S DE M ENSAJE ... ..................... ...................... .................. ............ ........ 14 3.1. Constructores gramati cales ...... .............. .................. ............... ..... 15 3.2. Espe cifica ción de campos ................ .................. .............. ............. 17 4. U SOS DE LAS ESTRUCTU RAS DE MENSAJE ...... ......... ............ ..................... ............... 17 4.1. Creación y uso de Estructuras de Mensaje en tiem po de análisis 18 4.2. Uso de Estructuras de Mensaje en tiempo de diseño ..... ............. 20 5. S OPORTE TECNOLÓGICO A LAS E ST RUCTURAS DE M ENSAJE .... ..................... .......... 21 5.1. Soporte a las Estruct uras de Mensa je mediante Xtext .... ............. 21 5.2. Soporte a las Estruct uras de Mensa je mediante EM F ................ .. 22 6. T RABAJOS RELACION ADOS ............... ..................... ..................... ..................... ........ 24 7. D ISCUSIÓN Y TRABAJOS FUTUROS .................... ..................... ..................... ............. 25 8. R EFERENCES ............... ..................... ..................... ..................... ................... .......... 26 1 I. ENGLISH VERSION 1. INTRODUCTION Nowadays, there exists wide consensus about the importance of modelling in informat ion system s development. However, the re is st ill much sp ace for improvement in model ‐ driven software development (MDD), sinc e many research challenges that remain open. To name a few: (i) to facilitate bu siness process modelling fr om a communicati onal perspective [E spaña, González et al. 2009], (ii) to provide model transformat ions in order to obtain the sy stem design from the requirements models, (iii) to allow req uiremen ts traceabi lity throughout the entire software lifecycle . This paper presen ts in detail a techn ique for the specification of communication with the informat ion system (IS): Message Structures 1 . Alt hough this technique is part of Com mu nic at ion Analysis, a com municat ion ‐ oriented r equirem ents engineering metho d [Es paña, Gonzále z et al. 2009], it can be used in combination with other methods and notations as well (e.g. Use Cases, Business Process Mo delin g Notation). Also, Mess age St ructur es can be applied solely in an alys is time, so lely in design ti me, or eve n throughou t the enti re lifecycle. Previous wo rks present Me ssage Structures conci sely [González, España et al. 2008; España, González et al. 2009]. This paper extends thes e works and makes th e fol lowing contri butions: • A precise specificat ion of the technique is prov ided, including definitions and ex amples of its concepts, its grammatical co nstructs, and it s acquisi tion operations. • Diffe rent ways if using the me ssa ge struc tures are described, diffe r entiating its app lica tio n in analysis time (specificat ion of business processes from a communicational perspective) and its application in design ti me (derivation of IS memory models and reasoning of the user int er fac e in terms of abstract patterns). • Two alter nati ve technological supports fo r Message Structures ar e presented: a modelling tool that is based in Xtext and a modelling tool tha t is based in Eclipse Mode ling Framew ork. The rest of the paper is structured as fo llows. Section 2 presents an ov erview of Communication Analysis. Section 3 presents in detail the concepts related to Message Structures, and describes its grammar. Section 4 differentiates it s applica tion in analysi s time and in design time. Section 5 presents the tool sup port . Section 6 reviews re lated work. Section 7 discus ses some ad va nta ge s and risks of usin g Message Structures an d presents future work. 2. OVER VIEW OF COMM UNI C A TIO N ANAL YSIS Communication Analysis is a requirements enginee ring method t hat pr oposes describing business processes from a communicational perspective. The objective is to disc over and describe communicative interactions between the IS an d its environment. The meth od st ems from academ ic research and it evolve s in collaboration with industry [González 2004]. The following definitions clarify the concepts in wh ich the prop osed modelling techniques are founded. We refer as c ommunicative inter act io n to an interaction between ac to rs with the purpo se of exchanging information. Dependin g on the preeminent direction of the commu nication, two types of 1 This technique has been named differently during the ev olution of Communication Analysis: Data Acquisit ion Structures [Gonz ález 2004; España 2005], Communicat ion Structures [Españ a, González et al. 2009]. We consider that the term Message Structures reflects their essence more appropriately. 2 communicative interaction are dis tingui she d: − In going communica tive interaction . Its main objective is to convey to the sy stem new meaningful informatio n; i. e. to feed the IS memory with pr evio usly unknown dat a that is relevant to the organi sation . − Out going c ommunicative int erac tion . Its main objective is to distribute known information to users; i.e. to consult IS memory to retrieve data and present it. The experience in developm ent proj ects has shown us that ingoing communicative int eractions entail more analytical complexity. Thus, we recommend analysts to focus on these interactions during analysis. A c ommunic ative event is a set of acti ons related to information (acq uisition, sto rage, processing, retrieval, and /or dis tribution), that are carri ed out in a c omplete and uninterrupted way, on the occasion of an external stimulus [Gon zález 2004]. For Comm unic at ion Analysis, a communicative event is an ingoing communicative interaction that fu lfils certain unity crite ria (method ological guidelines that f acilitate the creati on of modula r models) [González, España et al. 20 09]. Informally, a communica tive event can be seen as a business process activity. Communication Analysis propos es sp ecify ing business processes by means of Com mun ic at ive Event Diagrams, a g raphica l modelling technique whose notat ion is similar to UML Activity Diagrams. Event Spe cif ica tio n Templates is a textual spec ific atio n technique that prescribes a st ruc tur e for the requirements related to a communic ative ev ent. Previ ous works described thes e techniques in detail [España, González et al. 2009]. In the following, we foc us on a technique that allows the spec if icat io n of the messages that are associa t ed to business process activities. 3. MESSAGE ST R U C T U R E S Message Structures is a sp ec ific at ion technique that allows descr ibing, by means of structured text, the message that is associated to a communicative int erac tion. Al though message structures can be used to specify outgoi ng co mmunicative interactio ns, we focus on the spe ci fica t ion of ingoing communicative interactions, given their anal ytical interest. Table 1. Example of a message s tructure in analysis time FIELD OP DOMAIN EXAMPLE VALUE ORDER = < Order number + Request date + Payment type + Client + DESTINATIONS = { DESTINATION = < Address + Person in charge + LINES = { LINE = < Produ ct + Price + Quantity > } > } > g i i i i i i i i number date text Client Client address text Product money number 10352 31-08-2009 Cash 56746163-R, John Papiro Jr. Blvd. Blue mountain, 35-14A, 2363 Toontown Brayden Hitchcock ST39455, Rounded scissors (cebra) box-100 25,40 € 35 Table 1 presents an example 2 of the usag e in an alysis time; the ORDER messag e structure specif ies a communicative interaction by which a client places an order 3 . 2 This part icular font , the colou rs and the capitalis ation are a non ‐ prescriptive conven tion that is intended to facilitate message stru ct ure comprehension. Feel free to configure thes e as pec ts . 3 3.1. Grammatical constructs The syntax of Messag e Structures can be describe d in terms of the follow ing grammatical constructs. We refer as substr ucture to an eleme nt that is part of a message structure. This way, LINE , Client an d Payment type ar e substructures that are part of OR DER . There ex ist two classes of substructures: fiel ds and compl ex subs tructu res. We refer as init ial substructure to the substruc ture that co nsti tutes the first level of a messag e structure. For inst an ce, ORDER =< Order nu mber + Request date + Paymen t type + Client + DESTINATIONS > . • Fie ld . It is a basic inform ational element of the message; that which is not compo sed of other elements. Th ere exist two types of fields. o Data field. It is a field th at represents a piece of data with a basic domai n 4 . For inst anc e, Paym ent typ e is a data field that bel ongs to the me ssage structure ORDER . o Referenc e fie ld. It is a field whose do main is a type of business objects . For instance, Client references a client that is already known by the IS. • Complex substructure . It is any substructure that has an internal composi tion. There exist three types of complex substructures. o Aggregation substructure. It spec ifies a c om pos it ion of several sub structures in a way that they remain grouped as a whole. It is represe nted by angle brackets < > . For inst an ce, LINE =< Product + Price + Quantity > specifies t hat an order line consists of information abou t a product, its price and the quant ity that the client requests. o Iteration substructure. It spec ifies a set or repe tition of the substruct ures it contains. It is represented by curl y brackets { } . For instance, an order can have severa l destinat ions an d, for each destination, a set of order lines is defined. Both DESTINATIONS and LI NES are iteration substructures . LINE S ={ LINE =< Product + Price + Quantity > } o Specialisation substruc ture. It spec ifies one or more variants; that is, struct ural alternative s 5 . There is no example of specialisation substructure in Table 1; the mess age structu re in Table 2 specifies that the assignment ma de by a student can be of type THEORY , in which case the fields Subject and Title c haracterise the work, or it can be of type PRACTICE , in which cas e the fields Programming language and Functionality characteris e the work. Table 2. Frag ment of a message structu re that includes specialis ation FIELD OP DOM A IN < ... Type of assignment + TYPE = [ THEORY = < Subject + Title > | PRACTICE = < Programming language + Functionality > ] + ... > i i i i i [theo|prac] Subject text Language text 3 Mo st of the examples in this paper are taken from a requiremen ts mode l that can be found in [España, González et al. 2011] . 4 Basic domains (e.g. numbers, text) are discussed below. 5 It is more frequent to use spec ialisation with two or more variants . The usage with one variant represents the optionali ty of that variant; that is, a message might or mi ght not include the variant. 4 Table 3. EBNF gr ammar of M essage Struct ures 6 message structure = structure name, ’ =’, initial sub structure; initial substructure = aggregation subst ructure | itera tion substructu re; aggregation substructur e = ’<’, substructure list, ’>’; iteration substruct ure = ’{’, substructure list, ’}’; specialisation substruc ture = ’[’, substructure list,{ ’|’, su bstructure list },’]’; substructure list = substructure, { ’ +’, substructur e }; complex substructure = aggregation subst ructure | itera tion substructu re | specialisation su bstructure; substructure = substructure name , ’=’, complex substructure | field; For greater disambigu atio n, Table 3 presents the grammatical constructs of Message Struc tures using the Extended Backus ‐ Naur Form notation (EBNF) [ISO/IEC 1996]. In practice, the syntax is more flexible. The syntax of Mes sage Structures allow s creating equivalent structures by means of the follow ing mechani sms: (i) The names of co mplex subst ructures can be omitted. (ii) An iterat ion substructur e also aggregates it s own content (there is an aggregation subs tructu re that can be made explicit of it can be left im plicit). (iii) Similarly, eac h var iant of a specialisa tion substructure also has an im pl icit aggregation. This ‘syntactic sugar’ allows ada pting the notation to pro ject c ontingenc ies and it facilitates the usage of the technique. Table 4 illustrat es these mechan isms by presentin g four message str uct ure s that are semant ically equ ivalent. Table 4. Four equivalent message structures A = < a + b + C = { D = < e + f + g > } > A = < a + b + { D = < e + f + g > } > A = < a + b + C = { e + f + g } > A = < a + b + { e + f + g } > 3.2. Field specification To character ise a field, the following prop erties can be specified: • Name . Each field mus t have a significant name (e .g. Request date ). • Acquisition operation . It specifies the origin of the information that the field re presents. o Input i . The information of the field is provided by the primary acto r. o Generation g . The IS can automatically generate the information of the fi eld. o Derivation d . The information of the fi eld is already known by the IS and, therefore, it can be derived fro m its memory; that is, it was pr eviously communicated in a preceding communicative event. This operation can have an associated derivati on fo rm ul a. • Domain . It specifies the type of information the field contains . • Exam ple. An examp le of a value for the field, provided by the organisation. • Descr iption. An explanat ion that helps the reader to u nderstand the field meaning. 6 The eleme nts structure n ame , substructure n ame and field are character strin gs. 5 • Labe l . A brief text that describes the field when shown in a graphical int erface. • Link with memory . It spec ifies the corr espondenc e between the field an d a database table column or a cl ass diagram attribut e. • Compulsorine ss . It specifie s whether the message field is mandatory or not. It is possible to spec ify that the fiel d is not compul sory by using a one ‐ variant specialis ation (e.g. [ a ] ). • In itialisation . The value that the field is given by def ault can be specified by me ans of a functio n or a derivati on fo rmula. • Visibility . It specifies whether the field is visible in a graphi cal user interface form. It is recommended to lay the fiel ds ou t vertically and to specify the field properties horizontally (by means of columns). For reasons of space, the desc ription of the fields can be done in a separate table. Message Struc tures can be extended wi th other field pro perties that a method designer or an analyst deem approp riate. However, as discussed below, no t all properties are convenient at analysis time . 4. USAGES OF MESS AGE STRU C TU R ES Message Structures can be applied for different pu rposes (from softw are development to adap tive maintenance) and in different stages of the so ftware development life cycle (e.g. ana lysis, design ). Depending on whether they are used in an alysis or design time, syntactic and pragmatic di fferen ces have to be taken into account. Table 5 presents recommendations on the usage of field properties, depending on the development stag e in which Me ssage Structures are used. Table 5. Applicabili ty of field properties to development stage Name Acquisition operation Domain Example Description Label Link with memory Compulsoriness Initialisation Visibility i g d Analysis ++ ++ ++ ‐‐ ++ ++ ++ ‐‐ ‐‐ ‐‐ ‐‐ ‐‐ Design Memory ++ ++ ++ ++ ++ ++ ++ ‐ ++ + ‐‐ Interface ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ + LEGEND : ++ highl y recommended + recommended ‐ not reco mmended ‐‐ discouraged 4.1. Creation and usage of Message St ru ctures in an alysis time In analysis time, Message Structures allow specifying in detail the co mmunicative interact ions that take place in the organisational work pract ice . This way, they offer a commun icational perspective for business process modellin g and they act as requirements for the IS. In the context of Communication Analysis, the new mea n ingful informati o n that is conveyed to the IS in each communicative even t is specified by means of a message structur e. In the followin g, we enumerat e so me sources of informat ion and techni ques for acquir ing informat ion and analysi ng the messages exchanged with the IS. Organisational act ors play an im por ta nt role in IS analys is, since they know orga nisational wor k practice first ‐ hand. The an alyst wi ll employ e lic it atio n techn iques such as intervi ews or JAD sessions [August 1991]. It is crucial to ask the proper questio ns so as to define which inf or mati on is con ve yed in each communicat ive event, as well as to dis tinguish new information fro m derived information. Business forms are a technological support for commu nicative int er act ion s an d, therefore, they are a major source for analysis. In this sense, the user interface sc re ens fro m pre ‐ existin g softw are are equivalent. Forms can be used for entering information (input forms), for presenting data (output 6 forms), or fo r both purposes. In analysi s time, input fo rm s allow to identify comm unicative events that convey new inform ation to the IS. The analyst has to carry on, along with the users, the following inv est ig at ion s: − Whether the fo rm is filled in one go or iteratively in diffe rent moments in time; the corresponding communicat ive event s are identified. For instan ce, the cl ient ord er form shown in Fig. 1 is affected by more than one communica tive event 3 [España, González et al. 2011]: the request of the order, the assignment to a supplier, and the supplier respon se. − Which is the temporal order in which com mun ic ativ e events occur. − Which are the primary ac tors of the c ommunicat ive events (those that are the source of the information the form is filled which). − What message is conveyed in each communicative event (t he fields of the form that are affected by the even t). Observe that the message structure in Table 1 does not inclu de fields suc h as Supplier or Planned delivery date , which correspond to later communicative events. If the organisation has previous bu siness proces s specificatio ns or quality procedur es, then this documentat ion can also be used as in put for the analy sis. Using these sour ces an d techniques, analysts id ent ify communicative ev ents and they sp ecify, by means of message struct ures, the new mean ingful infor mation communicat ed in each event. This information is mainl y provided by the primar y act or; in case the informat ion of a field is prov ided by the primary ac tor, then it is at tac hed an input acquisition op eration (e.g. the quantity of items of a certain product that the cl ient requests: Quantity i ). Some information al elements may not be provided by the pri mary ac tor, but generated by the IS itself; in that case the acquisition ope ration is generation (e.g. order numbers, as well as invo ice numbers, are usually pre ‐ printed in fo rm booklets: Order number g ). Fig. 1. Example of an order form With regards to the domain , in analysis time it is advised to use fi ve basi c types for data fields: text , number , mo ney , date , time . For inst anc e, the do main of Quantity is number . For referenc e fields, the domain is the type of bus iness object. For in st anc e, the field Client identifies a clie nt that has alr ead y been registered in the IS; thus, its do main is Client (sim ilarly, Address refers to a c lient address and Product iden tifies a product of the catalogue). Also, if the values t hat the field can take are restri cted to a predefined set and there is not muc h prospect that the set will be updated , then the dom ain can be expressed by means of a specialisation subs tructure (e.g . the domain of Type of work in the example in Table 2 is [theo|prac] ). Also, in order to enhance the comprehen sibility of analys is specific ations, an examp le is provided for each field (e.g. Request date , 31-08-2009 ), as well as a description . 7 In ana lysis time, it is di scou raged to specify de rived fields (d ata fie lds whose ac qui sit ion operat ion is d ), as we ll as any othe r field property that is an aspect of design (see Table 5). Derived fiel d s do not convey new information and they contr ibute to an unnecessary over ‐ spec ification. It is convenie nt to postpone specifying derivation until the design stage. In order to avoid specifying derived fiel ds, each time it is needed to identify a business object that is already known by the IS (e.g . a client), the guideline is to inc lude a re ference fie ld (e.g . Client i Client ), an d to avoid in clu d ing the information that characterises the object (e.g. the clien t name). Equally, the analyst will avoid inc lud ing fields whose content can be derived fr o m the rest of the information in the mes sage (e.g. total am ou nt s such as Amount or Total ). In any case, notice that the message structure in Table 1 inc ludes a field named Price that corresponds to the price of the product. In fact, this field is infringing the abov e ‐ menti oned methodological gu idelines. The field ac tually refers to informatio n that is already known by the IS (the price is part of the company catalogue). The analyst has inc lud ed this field with a design solution in mind: the IS is int ended to register the Price of the produc t at the time of the order request so as to guarantee that, even thou gh th e prices are yearly updated, the informatio n on the orders and invoices will remain unchanged. However, this is only one pos sible design solu tio n amon g others (e.g . a ar chi va l st or age of prices). In case an alysts decide to includ e design aspects in an alysis time, then they should be well awar e and justify their decis ion. 4.2. Usage of Message Structures in design time In design time, Message Struc tures allow establishing the traceabili ty between analys is documentat ion, the spec ification of th e IS memory (e.g. by means of a class di agram or a relation al database sch ema), and the sp eci fica tio n of the user interfa c e. Mor eover, it is possible to define techniques for der iving the memory if the IS from requireme nts mo dels, as well as techniques for systematically reasoning the inte rf ace design. The summ ari sed procedure for the der ivation of th e IS memory is as follow s 7 . First the communicative event s are sorted acc or din g to their temporal p receden ce. Then the messag e structure of each event is pro cessed in order to obtain a class diagram view. This way, the complete class diagram is iteratively created by int egrating the class diagra m views that correspond to all the communicative events. Fig. 2 (right ‐ hand side) sho ws the derivation of the class diag ram view that corresponds to a communicat ive event in which a client places an order. A mo re detailed an d bigger example is avail able online [España, González et al. 2011]. The su mmar ised procedure to reason the user interface is as follows. First the interface st yle manual. Then the edit ing environments are identified (i.e. sets of forms or interface screens that support a set of editoria lly ‐ co mpatible communicative events. Next, the messa ge st ruc tur es are fragmented (e.g. normalising them in first normal form) and the fragments are assi gned to ab stract interface structur es (e.g. registry, set of registries ). The abstract interface structures ar e encapsulated in forms. Each form is specified in detail, esta blishing the po ssib le interaction and the edit in g faciliti es (fil ters, order criteria ). The behaviour of the interface can be sp ecified by mea ns of trigger tables. La stly, additi onal list in gs and printouts are specified . Fig. 2 (left ‐ hand side) shows ho w the IS interface is designe d in terms of abstrac t interf ace patterns. Methodological guidelines are described in detail in [España 2005]. 7 We describe the der ivation of cl as s diagrams because this derivation technique is part of ong oin g research. An analogous argument ation can be made fo r relational schemas. 8 Fig. 2. Derivation of an interfa ce desig n and a class diagram view that correspond to a communicative event in which an order is placed In desi gn time, it is usual to specif y de rived fields (e.g. the total a mount of each order li ne Amount d (:Price * :Quantity) ). Other properties that specif y aspects of design are also spec ified in this stage (e.g. th e sp ec ific atio n of the data field Request date coul d also include a fo rm ul a that defines its initialisat ion value: today() ). 5. TECHNOL OGICAL SUPPORT FOR MES SAGE ST RU C T U RE S Model ‐ driven software development (MDD) has become a real ity [Pasto r and Molina 20 07] . However, the communi ty lacks a collecti on of well integrated CASE tools that cover all the lifecycle, from requirements engineer ing to autom atic software code generation, and that take advan tage of model tra nsformations in al l the stages. This sect ion presents the mode lling tools that are being developed to support Message Structures. These su pports extend a CASE tool u nder developmen t that aims for the integration of Communicat ion Analysis in MDD environment s[Ruiz, España et al. 2010]. Two alternative dev elopment en vironment s have been chosen; nam ely, Xt ext and the Eclipse Modeling Fr amework. 5.1. Support to Message Stru ctures with Xtext Message Struc tures is a m odelling lan guage based on st ruc tur ed text, that can be spec ifie d using the extended Backus ‐ Naur Form no tation (s ee Table 3). This char acteristic facilitate s the development of a domain ‐ spe cific language (DSL) tool. Fig. 3.a shows the Messag e Struct ure grammar as de fined in the Xtext environment, an Eclipse ‐ based enviro nment for the development of textual DSLs [Behrens, Clay et al. 2010]. This environment allows the automatic generat ion of textual editors for the defined DSLs. Fig. 3.b shows the sp ecific ation of the message structure ORDER , using the Xtext tool. An advanta ge of this environment is that it can be integrated with other Eclipse ‐ based modellin g too ls. 9 grammar org.xtext.examp le.mydsl.CAMS w ith org.eclipse.xtext.c ommon.Terminals generate cAMS "http://www.xtext.o rg/example/myds l/CAMS" MessageStruc : strucName +=StrucNa me (initialSubstruc += InitialSubstruc ); StrucName : strucName=ID '=' ; InitialSubstr: (aggregationSubstru c +=Aggregation Substruc) | (iterationSubstruc +=It erationSubstruc ); AggregationSubstruc : '<' (substrucList += SubstrucList) '> ' ; IterationSubstruc: '{' (substrucList += SubstrucList) '} ' ; SpecialisationSubst ruc: '[' (substrucList += SubstrucList) ( '|' (substrucList +=SubstrucList) ) ']' ; SubstrucList: (substruc+=Substruc ) ( '+' (substruc+=Substruc) )*; Substruc: (field +=Field) | substrucName=ID '=' (complexSubstruc+=C omplexSubstruc) ; Field: fieldName=ID; ComplexSubstruc: (aggregationSubstru c+=AggregationS ubstruc)| (iterationSubstruc+ =IterationSubst ruc)| (specialisationSubs truc+=Specialis ationSubstruc); a) DSL definition in Xtext for Messag e Structures b) Example of a message structure Fig. 3. Support to Message Structures with the Xtext en vi ronm ent 5.2. Support to Message Structures with Eclipse Modeling Framework The MDD paradi gm can add value to requi rements model s: the potential to derive fro m them conceptual models that can later be used for automatic code generation. With th is aim in mind , [Ruiz, Espa ña et al. 2010] defines a process to integrate Com muni cati on Analysis in a MDD environment and it present s a metamodel that spe cifies part of the method. Th is metamod el was created using Eclipse Modeling Framework (EMF) (first a class diagram was des igned using UML2 Tools and then an Ecore metamodel was generated). This p aper presents an extension of the metamodel for Communicati on Analysis that allows modell ing Message Struc tures. In Fig. 4, pre ‐ ex istin g metaclasses have a gray border, whereas added metaclasses have a bla ck border. 10 Fig. 4. Support to Message Structures with Eclipse Modeling Framework (partial view of the extend ed me tamodel) Fig. 5 show s the messag e struct ure as an inst antiati on of the metamo del, in the form of an Ec ore tree. The tree gr aphically represents the composition of compl ex substruc t ures, leaving the operators = and + implicit. The type of each substructure is store d in the prop er ty type of the metaclass COMPLEX _ SUBSTRUCT URE (e.g. the tab named Properties shows that the complex su bstructure DESTINATIONS is of type iteration). On the one hand, the implementation in Xtext ensures the compliance with the EBNF gram mar for Message Structures and it offe rs an edit oria l enviro nment that is more efficient and usable . On the other hand, the implementation in EMF extend s the CASE tool for Communicat ion Analysis; moreov er, its Ecore metamo del offers the possib ility of defining mode l to model transformation s using languages suc h as ATL Transformat ion Language (A TL[ Jouau lt an d Kurtev 2005]) or Query/View/Transformation (QVT [OMG 2008]). In any case, both implementation approach es are complementary, since both env ironment s (Xtext and EMF) can be integrated (this is planned as future work). Fig. 5. Example of message stru ct ure suppo rted by the EMF en viro nmen t 11 6. REL A TED WO R KS There exist severa l communicati onal appr oach es to info rm atio n systems analysis; e.g. Action Workflow [Medina ‐ Mora, Winograd et al. 1992], SAMPO [Auramäki, Lehtinen et al . 1988], Business Action Theo ry [Goldk uhl 1996], DEMO [Dietz 1999], Cronhol m and Go ldkunhl’s Communication Analysis [Cronh olm and Goldkuhl 2004], SANP [Chang and Woo 1994], Organisational Semiotics [Stamper 1997]. We sh are with them the co mmun ic at ion al perspective an d many foundations borrowed fro m communication theory. However , Communication Analysis differs in sever al conceptual foun dations, in the underlyin g requirements structu re, and in the business process modular ity guidelines . Fo r a more detail ed compar ison see [España, González et al. 2009]. Moreover, unlike the abo ve ‐ mentioned appro aches, Communi cation Analysis places the emphasis on specify ing the messages that c orrespond to ing o ing communicative int er act ion s; to that end, we propose Message Struct ures. A not able ancestor of Message St ructures is Backus ‐ Naur Form (BNF). BNF is a notation for context ‐ free grammars that was pro pos ed during the developme nt of the comp iler Algol 60 [Bac kus, Bauer et al. 1963]. The grammatical cons tructs are the sequence, represented by contigui ty, and the alterna tive, represente d by a vertical bar |. Later extensions incorporat e the curly bracket s { } for repetitions, and the square brackets [ ] for the alternative. Struc tured Analysis ad apts BNF for the specification of data struc tures [DeM arco 1979]. Fortuna et al. [F ortu na and Borges 2005] propose extending UML Use Cases with a BNF ‐ based notati on to specify inf orm at ion al interfaces, with a simila r intention to Message St ructures. However, no prev ious notatio n inc lu de s an operato r to ex plic it ly parent hesise sequences. Th is prevents the an alyst from includin g subs tru ctures within substructures and forces the fragment ation of complex substructure s. For in stance, the first struct ure (a) presents an ambiguity that can only be avoided by fr agment ing th e structure in two parts (b) or, as pr o posed by Co mmunication Analysis, paren thesising the aggr egat ion (c ). An advantage of (c) over (b) is that (c) preserves the un ity of the message. a) Veh icle = NumberPlate + Bra nd + Model + Moto r = CubicCapacity + Valve s + Fuel + Colour b) Vehi cle = Nu mberPlate + Bran d + Model + Motor + Colou r Motor = CubicCapacity + Valves + Fuel c) Vehic le = Numbe rPlate + Brand + Mo del + Motor =< CubiCapacity + Valves + Fuel >+ Colou r Other techniques that all ow modelling the interaction between the organisational actors and the IS can be used in stea d of Me ssag e Structures; for insta nce , UML Sequ ence Diagr ams and ConcurTaskTrees [Panach, España et al. 2008]. However, our experie nce with these techniques has shown us the convenienc e of us ing a lightweight no tation, such as Message Structures, whic h has the advantage of allowing a fast, text ual specification. 12 7. DISCUSSION AND FU TUR E WO RK Information systems (IS) support organisa tional communicat ion. This pap er presents Message Structures. Mess age Structures is a technique that specifies the communicat i ve interactions among the organisational ac tors an d the IS. Besides detai ling the grammar of Message Structures, this paper also exp lains its uses in analysi s and design time. In an alysis time, message st ruc tur es facilitate the id entifi cati on of com mu nic at ive events (business activities that provide new significant informat ion to the IS) an d comp lement the bu siness proc ess descripti o n. In design time, message structures allow deriv ing the IS memor y and determining the interface design. In addition, this pape r provides methodological guidelines and i llustrative examples. Message Structures are a part of Communication Analysis, which is a commu nication ‐ oriented requirements engi neerin g method. However, in the case that an enterp rise desires to continue using a parti cular method, it is p ossible to extend it with Message Structures (this has been done for Use Cases). Since the technique is based on other well ‐ known techn iques, the adopt ion of Message Structures is facilitated. Note that, if Message Struct ures are used in co mb inat ion with other techniques for the spec ification of the interaction (e.g. UML Sequence Diagram), redun dancies may appear. In such cases , it is advised to define rules to derive so me models from others or to establish procedures to verify the consis tence. Clear distin ctio n between an alysis and design is import ant in the use of message structu res. This paper prov ides guide lines for the use the technique in the analys is and des ign phases. The use of Message Structures helps an ana lyst to not specify design aspects in analysis time without being conscious of it (something that can occur due to lack of ex perience with the technique). The ri sk of work overload and over ‐ spec ification of the requirements model decreases with the practice, as the nuances of the techniq ue are internalised. Due to the fact that Message Structures is a textual notation, it offers the adv antage of allow ing their spec if icat ion by means of a word processor or by configuring textual fields in CASE tools. However, our experiences in industria l developments, in teaching master courses in software engineering, and in labor atory experiments (e.g. [España, Condori ‐ Fernández et al. 2010]), have convinced us to offer more vers at ile support. This paper presents tw o to o ls that support the technique. One t ool is based on the Xtext technology. Another one is based on the Eclipse Modelin g Framework. As future work, we plan to integrate bot h tools. This integration will take advan tage of the usabilit y of the first techno logy an d the capacity to support mod el transform ation of the secon d technology. We are currently working on deriving conceptual mode ls from requirem ents models that include messa ge str uctures. This derivat ion is imp lemen ted us ing ATL Transformation Lang uage rules. 13 II. VERSIÓN EN ESPAÑOL 1. INTRODUCCIÓN Hoy en día , existe amplio con senso acerca de la import ancia del mode lado en el d esarrollo de sistem as de inform ación (SI). Sin embargo, todavía hay aspectos po r mejorar en el área de l desarrollo de software dirigido por mo delos (D SDM ): (i) facilitar el mo delado de procesos de negocio desde una perspe ctiva comuni cacional [España, Gonzále z et al. 2009], (ii) guiar la creaci ón de unos modelos a pa rtir de los ant eriores (p.e. de razonar el diseño en función de los requ isitos), (iii) permitir la traz abilidad de requisitos a lo largo de l ciclo de vida . En este artíc ulo presentamos con de talle una té cnica para especificar la comunica ción con el SI: las Estructuras de Mensaje 8 . Esta técnica nace vinculada al Análisis de Comunicaci ones, un método de ingeniería de requisitos con orientación comunicativa [E spaña, González et al. 2009], si bien se puede usar en combinación co n otras notacione s (v.g. con Casos de Uso o con Business Proc ess Modeling Notation). Además, las Estructur as de M ensaje se pueden ap licar aisl adamente en tiempo de anális is, de diseño, o a lo largo de todo el cic lo de vida. Trabajos anterio res introducen de forma co ncisa las Estruc turas de Mens aje [G onzález, España et al. 2008; España, González et al. 2009]. Este artícu lo extiende estos trab ajos y realiza las siguientes contribuciones: • Se ofre ce una especi ficaci ón precisa de la técnica, inc luy endo def inic iones y ejemp los de conceptos, constructores gramat icales y operaciones de adquisición. • Se descri ben los usos de las estructuras de mensaje, diferenciando su uso en tiempo de análisis (especificación de proces os de negocio desde un punt o de vista comuni cacional) de sus usos en tiempo de diseño (derivación de los mod elos de memoria del sistema de información y razonamiento de la interfaz de usuario) . • Se presentan dos ejemplos alternativos de sop orte tecnológico para la especifi cación de Estructuras de Mensaje: un modelador basa do en Xtext y un modelador basado en Ecli p se Modeling Fr amework. La estructura del artículo es la siguiente. La Sección 2 presenta resum idamente el Análisis de Comunicaciones. La Sección 3 presenta con detalle los concep tos relacionados con las Estruct uras de Mensaje y describe su gramática. La Sección 4 difere ncia los usos en tiempo de an álisis y tiempo de diseño. La Sección 5 presenta las herramientas de soporte. La Sección 6 revisa trabaj os re lacionados. La Secc ión 7 discute las ventajas y los riesgos de las Estructuras de Mensaje, y enumera los trabajos futuros. 2. PE RSPE CT IV A GENERAL DE L ANÁLISIS DE CO MU N IC A CI O NES El Anális is de Comu nica c iones es un método de ingeniería de re quisitos que propone describir los procesos de negocio desde una perspectiva comunicativa. El objetivo es descub rir y descri bir las interacciones comunicativas entre el SI y su entorno . Nace de la inv est iga ció n académica y 8 Esta técnica ha recibido otros nombres durante la evolución del Aná lisis de Comunicaciones: Estructuras de Adqui sición de Datos [González 2004; España 2005], Estruct uras de Comunica ción [España, González et al. 2009]. Con sidera mos que el térmi no Estructuras de Mensa je re fleja de manera más adecuada su naturaleza. 14 evoluciona en cola bo raci ón con la industria [González 2004]. Las siguientes defin iciones cla rifican los conceptos que fundamen tan las técni cas de modelad o propuestas. Se de fine interacción comunicativa como la interacción entre actores con el objetivo de intercambiar información . Dependiendo de la dirección preponderante de la c omuni cación, se distinguen dos tip os de int e rac ció n comunicativa: − Interac ción comunicativa entrante . Su objetivo fundamental es aport ar al sistema nuev a información s ign if ica tiv a; es decir, alimenta la memoria del SI con datos relevantes para la organi zación, previamente desconocidos. − Interac ción comuni cativ a saliente . Su objetivo fundamental es distribuir datos conocidos a los usuari os; es decir, consulta la memoria del sistema para rec uperar datos y presentarlos a los usuari os. La exper iencia en proyectos de de sarrollo nos ha en señado que las interacciones comunicativas entrantes compor tan ma yor c ompleji dad analítica. Por lo t anto, se aco nseja al analista centrar la atención en éstas durante el anális is. Un suc eso comuni cativo es un conjunto de acciones relacionadas con la informac ión (adquisición, almacenami ento, proceso, recuperación y/o distri bución) , que se llevan a cabo de mane ra completa y sin interrupciones, con mo tivo de un est ímulo ex terno [Go nzález 2004]. Para el A nális is de Comunicaciones, un suceso co municativo es una interacción comunicat iva entrante que cumple ciertos criterios de unidad (gu ías metodológicas que faci litan la creación de modelos modulares) [González, Españ a et al. 2009]. El Anál isis de Comunicaciones propone especificar lo s proc esos de negocio medi ante Diagramas de Sucesos Comun icativos , una técnica de modelado gráfico de notación semejante a los Diagramas de Actividad. Las Plantillas de Espe cificaci ón de Sucesos so n una técni ca de especificación textual que prescribe una e structura para los requisitos as ociados a un suce so comunicat ivo. Estas técnicas se describen con más detalle en trab ajos prev ios [E spaña, González et al. 2009]. En lo suc esivo nos centramos en una técni ca que permite la especifi c ación del mensaje asociado a cada interac ción comunicativa. 3. ESTRUCTURA S DE MENSA JE Estructuras de Me nsaje es una técnica de espe cificaci ón que permite describir, mediante texto estructurado, el mensaje asociado a una interacción comunicativa. Si bien las e structu ras de mensaje pueden usarse par a especifica r interacci ones comunicativas salientes, nos cent ramos principalmente en la especifica c ión de las interac ciones comunic ativas entrant es, por el interés analítico que con llevan. La Table 6 presenta un ejemplo 9 de la estructura de mensaje ORDER , qu e especifica una int eracci ón comunicativa entrante por la cual un cliente reali za un pedido 10 . 9 La tipogr afía, los color es y el uso de mayúscul as so n una convención no prescriptiva que está destinada a facilit ar la comprensión de las estru ctur as de mensaje. 10 La ma yor parte de los ejemplos de este artículo per tenec en a un modelo de requisitos que puede encontrarse en [España, González et al. 2011 ]. 15 Table 6. Ejemplo de un a estructura de mens aje e n tiempo de análisis FIELD OP DOMAIN EXAMPLE VALUE ORDER = < Order number + Request date + Payment type + Client + DESTINATIONS = { DESTINATION = < Address + Person in charge + LINES = { LINE = < Produ ct + Price + Quantity > } > } > g i i i i i i i i number date text Client Client address text Product money number 10352 31-08-2009 Cash 56746163-R, John Papiro Jr. Blvd. Blue mountain, 35-14A, 236 3 Toontown Brayd en H itch co ck ST39455, Rounded scissors (cebra) box-100 25,40 € 35 3.1. Constructores gramaticales La sintax is de las estru cturas de mensaje puede ser descrita en término s de los siguientes constructores gramaticales. Llamamos subestr uctura a un elemento constitutivo de una estructura de mensaje. De esta manera, LINE , Client y Payment type son sube structur as de OR DER . Exis ten dos tipo s de subestructuras: campos y subest ructuras compl ejas. L lamamos subestructura inicial a la subestructura que consti tuye el primer nivel de una estructura de mens aje. Por ejemp lo, ORDER =< Order num ber + Reque st date + Payment type + Client + DESTINATIONS > . • Campo . Se trata de un elemento infor macion al básico del mensaje; aquel que no est á compues to de otros elementos. Existen do s tipo s de campos. o Campo de datos. Espe cifica un campo que representa un dato cuyo dominio es básico 11 . Por ejemplo, Paymen t type es un campo de dato s textual, de la e structura de mensaje ORDER . o Campo de refere ncia. Especifica un campo cuyo do minio es un objeto de ne gocio. Por ejemplo, Client referencia a un clien te ya conocido por el SI. • Subestructura compleja . Se trata de cualquie r subestruc tura que tiene una composición inter na. Existen tres ti pos de subestructura compleja. o Subestructura de agregación. Especifica una composición de varias subestructuras de manera que qued an agrupadas. Se representa mediante paré ntesis angulares < > . Por ejemplo, LINE =< Product + Price + Quantity > espe cifica que una línea de pedido consiste de información sobre un pr oducto, su pre cio, y la canti dad solicitada por el c liente. o Subestructura de ite rac ió n. Especifica un conjunto o repe tici ón de aquell as sube structuras que contiene. Se repres enta mediante llaves { } . Por ejemplo, un pedido pu ede tener varios destinos y, para cada dest ino, se define un co njunto de líneas de ped ido. Tanto DESTINATIONS como LINES son subestructu ras de iteración. LINES ={ LINE =< Product + Price + Quantity > } o Subestructura de esp ecialización. Especi fica una o más variantes; es decir, alterna t ivas estructurales 12 . No hay ningún ejem plo de su best ruc tu ra de especia lización en la Table 6; la 11 Los dominios básico s (v .g. números, texto) se describen con ma yor deta lle más adelante. 16 estructura de mensaje de la Table 7 especifica que el trabajo de un estudiante pued e ser bien de tipo THEORY , en cuyo caso los campos Subject y Title caracterizan el trabajo, o bien de tipo PRACTICE , en cuyo cas o lo hacen los camp os Programming language y Functionality . Table 7. Fragmento de una estructura de mens aje que incluye especialización FIELD OP DOMAIN < ... Type of work + TYPE = [ THEOR Y = < Subject + Title > | PRACTICE = < Pro g rammin g lan g ua ge + Functionality > ] + ... > i i i i i [theo|prac] Subject text Language text Para mayor des ambigua ción, la Table 8 presenta los constructores gram aticales de las EM u sando la notación Backus ‐ Naur Form extendida (EBNF) [ISO/I EC 1996]. Table 8. Grámatica EBNF de las Estructuras de Mensaje 13 message structure = structure name, ’ =’, initial sub structure; initial substructure = aggregation subst ructure | itera tion substructu re; aggregation substructur e = ’<’, substructure list, ’>’; iteration substruct ure = ’{’, substructure list, ’}’; specialisation substruc ture = ’[’, substructure list,{ ’|’, su bstructure list },’]’; substructure list = substructure, { ’ +’, substructur e }; complex substructure = aggregation subst ructure | itera tion substructu re | specialisation su bstructure; substructure = substructure name , ’=’, complex substructure | field; En la prácti ca, la sintaxis es más flexib le. La s intaxis de las estructuras de mensaje permite construir estructuras equivalentes por medio de los siguientes mecanis mos: (i) Los nombre s de las subestructuras complejas pueden omitir se. (ii) Un a subestruct ura de iter ac ión a su vez agrega su contenido (hay una estructura de agregac ión que pu ede hacers e explíc ita o dejarse imp lícita). Las siguientes estru cturas son equi valentes. (iii) Del mismo mo do, ca da una de las variantes al ternativas de una subestructura de espec ializac ión ll eva i mp líc ita una agregación. Esto permite adaptar la notación a las contingencias de cada proy ecto y faci lit a su uso. De este mod o, la Table 9 prese nta cuatro estructuras de mensaje sem ánticamente equivalentes. 12 Es más común el uso con dos o más variant es. El uso con una sola variante representa la opcionalidad de dicha variante; es dec ir, que un mensaje puede inc luir o no la sube structura que contiene la variante. 13 Los elem entos stru cture name , substr ucture name y fie ld son cadenas de caracteres. 17 Table 9. Cuatro estructuras de mensaje equivalent es A = < a + b + C = { D = < e + f + g > } > A = < a + b + { D = < e + f + g > } > A = < a + b + C = { e + f + g } > A = < a + b + { e + f + g } > 3.2. Especificación de campo s Para caracterizar un campo, se pueden especificar las siguientes propiedades. • Nombre . Cada cam po debe tener un nombre sig ni fic ativ o (v.g. Request date ). • Operación de adqu isición . Espe cifica la procedenc ia de la informac ión que representa el campo. o Introducción i . La información del camp o la provee el actor primar io. o Generación g . La informac ión del cam po puede ser automáticamente gener ada por el SI. o Derivación d . La informac ión de l campo puede ser derivada de la memor ia del SI porqu e ya se conoce; es decir, fue comuni cada en un suceso comunicati vo anterior. La derivac ión lleva asociada un a fórmula de deriva ción. • Dominio . Espe cif ica el tipo de información que contiene el campo. • Ejemp lo. Un ejemplo de valor para el campo, aportado por la organi zació n. • Descr ipción. Una exp licac ión que fac ilite comprender el si gnificado del ca mpo . • Etiqueta . Un tex to breve que describe el campo cuando se pre senta en un formulario de interfaz gráfica de usuario. • Vinculación con memoria . Describe la correspondencia del campo con una columna de tabla en una base de datos o con un atributo en un diagrama de clas es. • Obligatoriedad . Indica si el campo debe necesariamente tomar valor o no. Es posible especificar esto usando una especia lización con una so la varian te (v.g. [ a ] ). • In icialización . El valor por de fecto asociado a un campo se puede especi ficar me diante una función o una fórmu la de derivaci ón. • Visibilidad . Indica si el camp o es visible en un formulario de int erfaz . Se recomienda desple gar la estructura de mensaje verticalmente y especificar las propiedades de los campos hor izontalment e (mediante columnas). Por motivos de espacio, se puede separar la descripción de los campos en una tabla apart e. Las Estructuras de Mensaje pue den extenderse co n aquellas pro piedade s que un ingeniero de métodos o un ana lista considere oportunos. Como se discute a continua ción no todas las propi edades son recomendadas en tiempo de análisis. 4. USOS DE LA S ES TRUCTURAS DE MENSAJE Las Estructuras de Mensaje pueden ser empl eadas en diferentes etapas del ciclo de vida de desarrollo de software. Dependien do de si se emp lean en tie mpo de análisis o de diseño , exist en diferencias sintácticas y pragmáti cas a tener en cuenta. La Table 10 prese nta recomendaci ones acerca del uso de las prop iedades de campos en función de la etapa del desarrollo en que se usa una estructura de mensaje . 18 Table 10. Aplicabilidad de las p ropiedades de los campos a la etapa de desarrollo Nomb re Operación de adquisición Dominio Ejemplo Descripción Etiqueta Vinculación con memoria Obligatoriedad Inicialización Visibilidad i g d Análisis ++ ++ ++ ‐‐ ++ ++ ++ ‐‐ ‐‐ ‐‐ ‐‐ ‐‐ Diseñ o Memori a ++ ++ ++ ++ ++ ++ ++ ‐ ++ + ‐ ‐ Interfaz ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ + LEYENDA : ++ muy recomendado + recomendado ‐ no r ecomendado ‐‐ desaconsejado 4.1. Creación y uso de Estructuras de Mensaje en tiempo de análisis En tiempo de análisis, las Estructuras de Mensaje permiten especificar en detalle las interacciones comunicativas que tien en lugar en la práctica organizaci onal. De esta manera, ofrecen una perspectiva comunica tiva al modelado de procesos de negocio y actúan como requisitos para el SI. En el contexto del Análisi s de Comunicaciones, para cada su ceso comunicativo debe especificarse la estructura de mensaje que desc ribe la nueva inform ación signif icativa que se aporta el SI. A continuación se enumeran al gunas fuentes de información y técni cas para obtener in formación y analizar los mensa jes intercambi ados con el SI. Los actores de la organización de semp eñan un papel pr imordial en el análisis de SI, pu esto que conocen de primera mano la prácti ca organizacional. El analista empleará técnicas como entrevistas o ses ione s JA D [August 1991]. Se re alizarán las pregunta s ad ecuadas para definir qué información se intercambia en cada suce so comunicativo y el an alista distingu irá la nueva informac ión de la información derivada. Los formularios del negocio son un soporte t ecnológico para las interacciones comun icati vas y, por tanto, una fu ente important e para el análisis . En este se ntido, las pant allas del software preexis tente resultan equivalentes (omitimos la argum entación para ellas). Los formulari os pueden ser usados para la introducción de datos (formularios de entrada), para la presentación de datos (formularios de salida), o para ambos prop ósit os. En ti empo de análisis, lo s form ularios de ent rada permiten identificar sucesos comuni cativos que aportan nueva información al SI. El analis ta debe realizar (con ayuda de los usuarios ) las siguientes inve stigaciones: − Si el formulario se re llena todo de una vez o de mane ra iterativa en d iferentes momentos; se identifican lo s sucesos comun icativos corres pondiente s. Por ejemplo, el formu la rio de pedido que muestra la Fig. 6 es afectado por más de un suceso comuni cativo 10 [España, González et al. 2011]: la solicitud de un pedido, la as ig nac ión de un prove edo r y la respuesta del proveedor. − Cuál es el orden temporal en que ocu rren los sucesos comunicativos. − Cuáles son lo s actores pri marios de los sucesos ( aquellos que son la fuente de info rm ac ión con la cual se rellena el form ula rio ). − Qué mens aje se transmi te en cada suceso comunicativo (los ca mpos del formulario que so n afectados po r el suceso). Obsérv ese qu e la estructura de me nsaje en la Table 6 no incluye camp os como Supplier o Planned delivery date , que corresponden a suce sos comunicativos posteriores Si existen especificaciones previas de procesos de negocio o de procedimientos de calidad, esta documentac ión tamb ién puede usarse com o entrada para el an álisis. Usando est as fuent es y técnicas, el analista ide ntificará su ce so s comunicativos y especi ficará , mediante estru ctur as de mensaje, la nuev a informac ión sig ni fic ativ a comunic ada en cada su ce so. Esta in fo rma ció n la provee p rin ci pa lme nt e el actor primario; cuando así ocurre, se especifica cam po 19 con una operació n de adquisición de int roducción (v.g. la c antidad de artículos de un producto determinado que el cliente desea: Quantity i ). Excepciona lmente, algunos elementos de inform ación no son provistos por el act or pr imario sino que los genera el propio SI; en este caso se especifica una operación de generación (v.g. los núm eros de pe dido, as í como lo s de factu ra, su elen venir pre ‐ impresos en las li bretas de for mu lar ios: Order number g ). Fig. 6. Ejemplo de un formulario de pedido Respecto al dominio , en tiempo de análisis se recomi enda el uso de cin co tipos básicos para lo s campos de datos: text , number , mo ne y , date , tim e . Por ej emplo , el dominio de Qua ntity es number . Par a los campo s de referenc ia, el domin io es el tipo de objeto de negocio. Por ejemplo , el campo Client identifica un client e que ya ha sido r egistrado en el sistema de información ; por lo tanto, su dominio es Client (de manera similar, Address se re fiere a una direc ción del clien te y Product ident ifi ca un producto del catál ogo). Además, si lo s valores que puede tomar el campo están restringidos a un conjunto p redefinido y sin ex pectativas de ser modificado, el do minio se puede expresar mediante una subestr uctura de espe cialización (v.g. el dominio de Type of work en el ejemplo de la Table 7 es [theo|prac] ). Además, para faci litar la comprensión de la especifica ción de an álisis, se proveerá un ejem plo (v.g. Request date , 31-08-2009 ) y una descripción para cada campo. En tiempo de aná lisis se desac onseja la especifi cación de campos d erivados y de aquellas propiedades que constituy en aspectos de diseño (ver Table 10). Los camp os derivados, no constituyen nueva informac ión y contribuyen a un a sobre ‐ especificación inneces aria. Es conveniente relegar la especifi cación de la derivación a la etapa de diseño. Para ev itar especificar campos derivados, cada vez que se debe identif icar un objeto de negocio previamente conocido por el SI (v.g. un cliente) bastará con inc luir un campo de referencia (v. g. Client i Client ), y se evitar á incluir la información que lo caracter iza (v.g. su nombre). Igualmente, se evitará incluir campos cuyo contenido se puede deri var de l re sto de la infor mac ión del mensaje (v.g. importes tota les como Amount o Total ). En cualqui er caso, si se atiende a la estruc tura de mensaje de la Table 6, se pu ede observ ar que aparece el campo Price correspondi ente al pr ecio del producto. En realidad, este campo está infringie ndo las gu ías metodol ógica s recién enun ciadas. Se trata de informaci ón ya co nocida por el SI (es parte del catálogo de la co mpañía). El an alista ha incluido este campo para registrar el prec io del producto en el momento en que se realiza el pedido y garantizar que, pese a que se actualicen los 20 precios de l catálogo anualmente, la inform ación de los pedidos y las fact uras permanecerá invariab le. Sin embargo , esta solo es una solu ción de diseño entr e varias posibles (v.g. un histórico de precios). En caso de inclu ir estos as pec to s de diseño en tiemp o de an álisis, el an ali sta debe ser plename nte cons ciente y justific ar la decisión. 4.2. Uso de Estructuras de Mens aje en tiempo de diseño En tiempo de diseño, las Est ruct uras de Comunicación permiten establecer la trazabil idad entre la documentac ión de análisis, la especificación de la memoria del sistema (por ej emp lo un diagrama de clases o un esquema de bases de datos relacional) y la especifi c ación de la interfaz de usuario. Es más, es posib le def inir procedimientos para derivar la memoria del sistema a parti r de la espe cificaci ón de an álisis y para razonar sistemáticamente el diseñ o de la interfaz. El proc ed imie nt o resum ido par a derivar la memoria del sistema es el sigu iente 14 . Prime ro se ordenan los sucesos co munica tivos en fu nci ón de sus precedencias temporales. De spués se trat a cada suceso, procesando su est ructura de mensaje correspondient e y obteniendo de ella una vis ta del diag rama de clases. De esta forma, el diagrama de clases completo se co nstruye integrando increment almente las vist as co rrespond ientes a todos los sucesos comunicativos. La Fig. 7 (hac ia la derecha) presenta la derivación de la vista correspondiente al suce so de solic itud de un pedido. Un ej emplo más extenso y detallado está disponible online [España, González et al. 2011]. El procedim iento resumido par a razonar la interfa z de usuari o es el siguiente. Primero se especifica n las normas de estilo de la interfaz. A c ontinu ación se identifican contextos editoriales (conjuntos de formularios o panta llas que soport arán un conjunto de sucesos co municativos ed itorialmente compatibles). Después se fragmentan las estructuras de comuni caci ón (v.g. nor malizándo las en 1ª forma normal) y se asignan los fragmentos a estructu ras abstractas de interfaz (v.g. registro, conjunto de registr o). Se encapsula n las estructura s abstractas de interfa z en formul arios. Cada formulario se es pecif ica detalladamente, estableciendo la int eracción posible y las facili dades editoriales (filtros, or denaci ón). El comportamiento de la int erfaz se puede especifi car mediante tablas de dis paros. Por último , se especi fican listados y formular ios de salida adicionales. La Fig. 7 (hacia la izq ui erd a) presenta el raz onamiento de la int er faz del SI en términos de patrones abstractos de interf az. Las guías metodológi c as están descritas co n detalle en [España 2005]. Fig. 7. Deriva ción de un dis eño de int erfaz y una vista de diagrama de clases correspondiente a un suces o de solicitud de un pedido 14 Se describ e la deri vaci ón de di agram as de clas es porque este proced imiento es parte de los trabajos en marcha. Se puede razona r de maner a análoga pa ra esquemas relacional es. 21 En tiempo de diseño, es frecue nte especificar cam pos der ivados (v.g. el imp orte de cada línea, Amount d (:Price * :Quantity) ).También se especifica n propiedades de campos que especifican aspectos de diseño (v.g. el campo Request date podr ía tene r asociada la fórmula tod ay() para indicar que su valor de inicia lización es la fecha actual). 5. SOPO RTE TECNOL ÓGICO A LA S ESTRUC TU RAS DE MEN SA JE El desarro llo de so ftware dirigido por modelos (DSD M) es ya una realidad [Pastor and Molina 2007]. Sin embargo, la comunidad ado lece de un conjunto bien integrado de herramientas CA SE que cubra desde lo s requisitos a la generación automática de código y aproveche las vent ajas de las transformaciones de mode los en to das sus etapas. En esta sección se presentan lo s sop ortes tecnológicos que se están des arrollando para las Estructuras de Mensaj e. Est os soportes extiende n una herramienta CASE en des arrollo que persigu e la integrac ión del Análisis de Comunicaci ones en entornos DSDM [Ruiz, Españ a et al. 2010]. Se han elegido dos entorn os de desarrollo alternativos: Xtext y Eclipse Model ing Framework. 5.1. Soporte a las Estructuras de Mensaje mediante Xtext Las Estruct uras de Mensaj e son un lenguaje de texto estructurado que puede especifi carse usando la notación Backus ‐ Naur Form extendida (ver Table 8). Hemos aprovechado esta característica que facilita su desarrollo en entornos de de finición de lenguajes específi cos de dominio (DSL) . La Fig. 8.a muestra la gramática definida en el entorn o Xtext, un entor no basado en Eclipse para el desarrollo de DSL textuale s [Behren s, Clay et al. 2010]. Este entorno permite la generación automática de editores textuales para los DSL definidos. La Fig. 8.b muestra la espe cifica ción de la e structura de mensaje ORDER realiz ada en base a la definición en Xtext. Una ventaja de est e entor no es qu e se puede integrar co n otros desarrollos basados en Eclipse. 22 grammar org.xtext.examp le.mydsl.CAMS w ith org.eclipse.xtext.c ommon.Terminals generate cAMS "http://www.xtext.o rg/example/myds l/CAMS" MessageStruc : strucName +=StrucNa me (initialSubstruc += InitialSubstruc ); StrucName : strucName=ID '=' ; InitialSubstr: (aggregationSubstru c +=Aggregation Substruc) | (iterationSubstruc +=It erationSubstruc ); AggregationSubstruc : '<' (substrucList += SubstrucList) '> ' ; IterationSubstruc: '{' (substrucList += SubstrucList) '} ' ; SpecialisationSubst ruc: '[' (substrucList += SubstrucList) ( '|' (substrucList +=SubstrucList) ) ']' ; SubstrucList: (substruc+=Substruc ) ( '+' (substruc+=Substruc)) *; Substruc: (field +=Field) | substrucName=ID '=' (complexSubstruc+=C omplexSubstruc) ; Field: fieldName=ID; ComplexSubstruc: (aggregationSubstru c+=AggregationS ubstruc)| (iterationSubstruc+ =IterationSubst ruc)| (specialisationSubs truc+=Specialis ationSubstruc); a) DSL en Xtex para la especificación de Estructuras de Mensaje b) Ejemplo de Estructura de Mensaj e Fig. 8. Soporte para Estructuras de mensaje en el entorno Xtext 5.2. Soporte a las Estructuras de Mensaje mediante EMF El paradigma DSDM puede dotar a los modelos de requisitos de un valor añadido: el potencial para derivar de ellos los mod elos conceptuales que serv irán para la generación autom ática de código. Con este fin, [Ruiz, España et al . 20 10] define un proceso para integrar el Análisis de Comun icaciones en un entorno DSDM y presenta un metamodelo que especifica un a parte del método. Para cr ear este metamodelo se hiz o uso de las herramie ntas de modela do de UML de Eclip se Modeling Fra mework (EMF) y se gener ó el metamodel o Ecore correspondiente. En este art ículo se presenta una extensión del metamodel o de Análisis de Com unicaci ones que permite el modelado de Estructuras de Mensaje. En la Fig. 9, las metaclase s preex istentes aparecen con marco gris, mientr as las metaclas e s añadi das al metamodelo se resaltan con marco negro. 23 Fig. 9. Vista del metamodelo de Análisis de Comunicaciones ext end ido para dar soporte a las Estruc turas de Me nsaje La Fig. 10 mue stra la estructura de mensaje ORDER como una in stanciació n del metamodelo, en forma de árbol Ecore. El árbol repre senta gráficamente la com posición de subestructuras complej a s, quedan do implíc itos lo s operado res = y + . El tipo de cada sube structur a se almacena en la propiedad Type de la metaclase COMPLEX _ SUBST RUCTURE (v.g. la solapa Properties muestra que la subestruct ura compleja DESTINATIONS es de tipo iter ac ión ). Por un lado, la implementación en Xtext garantiza el c umplimient o de la gramática defini da en EBNF para las Estructu ras de Mensaje y ofrece un entorno de ed ic ión de estructuras de mensaje más eficiente y usable. Por otro lado, la implement ación basada en EMF extiende la herramienta CASE para Análisis de Com unicaciones y su metamodelo Ecor e ofre ce la posibilida d de definir transformaciones modelo a modelo mediante leng uajes como ATL Transformation Lan guage (ATL [Jouault and Kurtev 2005]) o Query/View/Transformation (QVT [OMG 2008]). En cualquier caso, ambas aproximaciones de implem entación son comple mentarias, puesto que ambos entornos (Xtext y EMF) son integrables (esto se planea como trabajo futuro) . Fig. 10. Eje mplo de Estructu ra de Mens aje soportada en el entorno EM F 24 6. TRABAJOS REL ACIONADO S Existen varias ap rox imac ion es comunicat ivas al an álisis de sistemas de informac ión. Por ej emplo , Action Workflow [Medina ‐ Mora, W inog rad et al. 1992], SAMPO [Auramäki, Lehtinen et al. 1988], Business Ac tion Theo ry [Goldkuhl 1996], DEMO [Dietz 1999], Communi cation Analysis de Cronholm y Goldkunhl [Cronholm and Goldkuhl 2004], SANP [Chang and Woo 1994], Organisat ional Semiotics [Stamper 1997]. Co mpartimo s con ellas la per spectiva co municativa y numerosos fundamentos tomados de la teoría de la comun icación. Sin embargo, el Análisis de Comunicaciones difiere en varios fun damento s c onceptuales, en la estructura de requisitos suby acente y en las gu ías par a la modular idad de proc eso s de negocio. Véase [España, González et al. 2009] para una comp aración más det a llad a. Adiciona lmente, a diferencia de las aproximaciones me ncionadas arriba, el Análisis de Comunicaciones en fatiza la e specifi c ación de lo s mensaje s que corresponden a las interacciones comunicativas entrantes, para lo cual se proponen las Estructur as de Mensa je. Un ancestro notable de las Estruc turas de Mens aje es Backus ‐ Naur Form (BNF). BNF es una notaci ón para gramáti cas libres de contexto propuesta por Backus y Naur en el desarrollo del compilador de Algol 60 [Backus, Bauer et al. 1963]. Los c onstructores gram aticales son la secuen cia, representada mediante cont igüidad, y la alter nativa, representada mediant e una barra vertica l. Exten sio nes poster iores in corporan las llaves {,} para repeti c iones y lo s paréntesis rectos [,] para la opci onalidad. El Anál isis Estructurado de Sistemas adapta la notaci ón BNF para la especificaci ón de estructuras de datos [DeMarco 1979]. Fortuna et al. [Fortuna and Borges 20 05] proponen extender Casos de Uso mediante con una notación basada en BNF para espec ificar interfaces informaciona les , con una intención similar a las Estructuras de Mensaje. Sin embargo, ninguna de las notaci ones ante riores incl uye un operador par a paren t izar expl íc itam ent e las secuen cia s. Esto impide describir subestructuras dentro de estruct uras y ob liga a fragmentar las estructuras complejas. Por ejemplo, la primera estr uctu ra (a) present a una ambigüed ad que so lo se puede eliminar fragmenta ndo la estructura en dos partes (b ) o, como propone Estr ucturas de Mensaje, parentizando la ag regación (c). Un a ventaja de (c) sobre (b) es que (c) preserva la unidad del mens aje. a) Vehículo = Matrícula + Marca + Modelo + Mo tor = Cilindrada + Válvulas + Combustible + Color b) Vehículo = Matrícula + Marca + Modelo + Motor + Color Motor = Cilindrada + Válvu las + Combustible c) Vehículo = Matrícula + Marca + Modelo + Motor =< Cilindrada + Válvulas + Combustible >+ Color Otras técnicas que permiten modelar la int eracción ent re los actores y el SI pueden cumplir una función si milar a las Estructuras de Mensaje; por ejemp lo Diagramas de Secuencia UML o arb oles de tareas como Co ncurTaskTrees [Panach, España et al. 200 8]. Sin embar go la experiencia nos ha demostrado la convenien cia de una not aci ón más ligera, como las Estructura s de Mensaje, que tienen la ventaja de poder ser descrita s textualmente. 25 7. DISCUSIÓN Y TRABAJO S FUTURO S Los sistemas de información (S I) son soportes a la comuni caci ón organizacion al. En este ar tíc ulo se presentan las Estructu ras de Mensaje, una técnica que permite especificar las interacciones comunicativas entre los actores organi zacionales y el SI. Además de detallar la gramática de la s Estructuras de Men saje, se explican sus usos en tiemp o de an álisis y de diseño del SI. En tiempo de análisis, facilitan la identi fica ción de sucesos comunicat ivos (ac tividad es del negocio que aportan nueva información significativa al SI) y complementan la descripción de los procesos de negocio. En tiempo de diseño , permite n der ivar la memoria del SI y razona r el diseñ o de la interfaz. Se proveen guías metodológicas y ejemplos ilustrativos. Las Estructuras de Mensaje for man parte del método de in gen iería de requisitos Análisis de Comunicaciones. Sin emba rgo, en el cas o de que una organización desee continuar u sando un método en parti cular, es pos ible ex tenderlo con Estructuras de Men saje (e sto ya se ha hecho para Casos de Uso); facilita su adop ción el hecho de ser una técnica basada en otras ya conocidas (BNF, diccionarios de da tos) . Conviene hacer notar que, si las Est ructuras de Mensaje se usan en combinación con otras técnicas para la especificación de la in ter ac ció n (v .g. Dia gra mas de Secuencia), pueden apare cer redunda ncias. En este caso se aconseja la definición de reg las par a derivar unos modelos a partir de otros, o estab lecer procedimientos para verificar la consistencia. Un aspecto clave en el uso de las Estructuras de Mensaje es la distin ción cla ra entre análisis y diseño. Este artículo provee de guías para el uso de la técnic a en amba s etapas. Permiten prevenir que un analista e specifique aspectos de diseño en tiempo de análi sis, sin ser consciente de ello (algo qu e puede provocar la falta de experiencia con la técnica). Este riesgo de sobrecarga de trabajo y de sobre ‐ especifi cación del modelo de requisitos disminuye con la práctica, al interioriza r la form a de uso de la técni ca. Al t ratarse de una notación textua l, las Es truc tura s de Men saj e ofrecen la ventaja de pe rmitir la espe cificaci ón mediante un procesador de textos o configura ndo campos text uales en herramientas CASE existentes. En cualquier caso, las expe rienc ias en desarrollos industriales , doc encia en másteres de ingeniería del software y experimentos de laboratorio (v.g. [España, Co ndori ‐ Fernández et al. 2010]), nos han co nvencido de ofrecer un soporte más versátil. Este artículo presenta do s herramientas que sopo rt an la técnica: una basada en la tecnol ogía Xtext y otra basad a en Eclipse Modeling Framework. Com o trabajo futuro se planea integrar amba s herramientas par a aprovechar la usab ilidad de la primera y la capacidad para soportar transformaciones de model o s de la segunda. Actualmente se está traba jando en la derivación de modelos conceptual es a partir de modelo s de requisitos que incluyen Estru cturas de Mensaje, usando reglas de ATL Tranformation Language. 26 8. REFERENCES August, J. H. (1991). Joint Ap plic at ion Desig n: the gro up session approac h to system design . Upper Saddle River, NJ, USA, Yourdon Pr ess. Auramäki, E., E. Lehtine n and K. Lyytinen ( 1988). "A sp eech ‐ act ‐ ba sed office modeling appro ach." ACM Transactions on Information Systems 6 (2): 126 ‐ 152. Backus, J. W., F. L. Ba uer, J. Green, C. Katz , J. McCarthy, A. J. Perlis, H. Rutisha user, K. Samelson, B. Vauquois, J. H. Wegstein, A. v. Wijngaarden and M. Woodger (19 63). "Rev ised report on the algorithm language ALGOL 60 ." Commun. ACM 6 (1): 1 ‐ 17. Behrens, H., M. Cl ay, S. Effti nge, M. Eysholdt , P. Friese, J. Köh nlein, K. Wannheden, S. Zarne kow an d and contri butors (2010). Xtext user guide (v 1.0.1) http://www. eclipse.org /Xtext/doc umentat ion/1_0_ 1/xtex t.pdf , Accessed 2010 ‐ 11. Cronholm, S. an d G. Gold kuhl (2004). Communication Anal ysis as perspective and met hod fo r requiremen ts engineering. Req uirements engi neering fo r socio ‐ technical systems . J. L. Mate and A. Silva (ed.), Idea Group, Inc. : 340 ‐ 358. Chang, M. K. and C. C. Woo (199 4). "A spee ch ‐ act ‐ ba sed negotiat ion protocol: design, implementation, an d test use ." ACM Trans. Inf. Syst. 12 (4): 360 ‐ 382. DeMarco, T. (1979). Structured an a lys is and syst em specific ation , Yourdon Press. Dietz, J. L. G. (1 999). Understan ding and modelling business processes with DEMO. 18th Internati onal Conference on Conceptual Mode ling (ER 1999) . Par is, France, Springer ‐ Verlag : 188 ‐ 202. España, S. ( 2005). Guía meto dológica para especificación de interfaces gráficas de usuario basada en estructura de ad quisició n de datos, Methodological guide for the specif ication of graph ical user inter fac es based in c om mun ic atio n structures (in Spanish). Bachel or thesis, Facul tad de Informática de Valencia, Universida d Politécnica de Valenc ia, Valencia, Spain. España, S., N. Condori ‐ Fernán dez, A. González and O. Pastor (2010) . "An empiric al comp arat iv e evaluati on of requir ements engineering methods ." Journal of the Brazilian Computer Society 16 (1): 3 ‐ 19. España, S., A. González and Ó. Pasto r (2 009). C omm un ica tio n Ana lysis: a requirements engineering method fo r in formation systems. 21st International Conference on Advanced Informatio n Systems (CA iSE'09) . Amsterdam, The Neth erlands, Springer LNCS 5565 : 530 ‐ 545. España, S., A. González, Ó. Pastor and M. Ruiz (2 011). Integration of Communication Anal ysis and the OO ‐ Method: Manual derivati on of the conceptual model. The SuperStationery Co. lab demo. Techn ical re port ProS ‐ TR ‐ 2011 ‐ 01, ProS Resear ch Centre, Un iversidad Politécnica de Valenc ia, Spain, http://arxiv.org/pdf/1101.0105 Fortuna, M. H. and M. R. S. Borges (2005) . Modelagem informac ional de requisitos. VII I Workshop em Engenh aria de Requ isitos (WER 2005) . J. Araújo, A. D. Toro and J. F. e. Cu nha. Porto, Portugal : 269 ‐ 280. Goldkuhl, G. (1 996). Generic business frameworks and action modelling. International wo rkshop on the Langu age Action Perspective on Commun ication Mode lling (LAP 1996) . Tilburg, The Netherlands. González, A. (2 004). Algunas c onsideracion es sobre el uso de la ab st rac ció n en el análisis de los sistemas de información de gestión (PhD thesis) Some considerat ions on the use of abst rac tio n in managem ent info rma ti on syst ems ana lys is (in Spanish). PhD thesis the sis, Departamento de Sistemas Informáticos y Comput ación, Univer sidad Politécnica de Valenc ia, Valenc ia. González, A., S. Espa ña and Ó. Pastor (2008). Towar ds a communicational per spective for en terpr ise Information Systems mo delling . IFIP WG 8.1 Working Conference on The Practice of Enterprise Modeli ng (PoEM 2008) . J. Stirna and A. Persson. Stockholm, Sweden, Springe r LNBIP 15 : 62 ‐ 76. González, A., S. España and Ó. Pastor (2009). Un ity crite ria fo r Business Proc ess Mode lling: A theoretical argument ation for a Softwar e Engineering recurrent problem. Third Internat ional Conference on Researc h Chall enges in Information Sci ence (RCIS 2009) . Fes, Moroc co, IEEE : 173 ‐ 182. ISO/IEC (1996). Information technology ‐ ‐ Syntactic m etalanguage ‐‐ Extended BNF ISO /IEC 14977:1996, 27 Jouault, F. and I. Kurtev (2005). Transformi ng mo dels with ATL. Satellite Events at the MoDELS 2005 Conference. Montego Bay, Jamaica : 128 ‐ 138. Medina ‐ Mora, R., T. Winograd, R. Flores and F. Flores (1 992). The action workflow appr oach to workflow manag ement technology. Proceedings of the 1992 AC M conference on Computer ‐ supported coope rative work . Toronto, Ontario, Canada, AC M : 281 ‐ 288. OMG (2008). Meta Object Facility (MOF) 2.0 Query/View/Transformation spe ci fic at ion (ver sio n 1.0) http://www.omg.o rg/spec/QVT/1.0/ , Accessed 05/2010. Panach, J., S. Españ a, I. Peder iva and O. Pastor ( 2008). "Capturing inter ac ti on requirements in a model transformation technology based on MDA ." Journal of Universal Computer Science (JUCS) . Spec ial issue "Des igning the Human ‐ Computer Interaction: Trends and Challenges" 14 (9): 1480 ‐ 1495. Pastor, O. and J. C. Moli na (2007). Model ‐ Driven Architecture in practice: a software production environment based on conceptual modeling . New York, Springer. Ruiz, M., S. España, A. Gonzalez and O. Pastor (201 0). Análisis de Comunicaciones como un enfoque de requisitos para el desarrollo dirigido por modelo s. VII Taller so bre Desarro llo de Softwar e Dirigido por Modelos (D SDM 20 10), Jornadas de Ingeniería de Softw are y Bases de Datos (JISBD ) O. Av ila ‐ García , J. Cabot, J. Muñoz, J. R. Ro mero an d A. Valleci llo. Valencia, España : 70 ‐ 77. Stamper, R. K. (1 997). Organ izat iona l semio tics. Information Systems: an emergi ng d iscipline . F. Stowell and J. Mingers (ed.). London, McGraw Hill : 267 ‐ 283.
Original Paper
Loading high-quality paper...
Comments & Academic Discussion
Loading comments...
Leave a Comment