Construcció d'un dataset per a l'extracció de models de processos de negoci a partir de textos

Grau en Enginyeria Inform` atica Especialitat en Computaci´ o Treball de Fi de Grau Construcci´o d’un dataset per a l’extracci´o de models de processos de negoci a partir de textos Guillem Pla Bertran Director Josep Carmona Vargas Codirector Llu ´ ıs Padr´ o Cirera Tutora del GEP Olga Pons Peregort 22/06/2022 Resum La definici´o formal de processos de negoci en est`andards com BPMN 2.0 ´es un pas crucial per a la transformaci´o digital de les organitzacions. Moltes organitzacions tenen els seus processos documentats en text, i crear-ne els models formals t´e un elevat cost de personal especialitzat. L’objectiu del projecte ´es crear un conjunt de dades anotades que relacionin textos amb els models formals que els descriuen, per tal que puguin ser usades per entrenar sistemes neuronals de Deep Learning per fer aquesta tasca. Abstract Formally defining business processes in standards such as BPMN 2.0 is a crucial step in the digital transformation of organizations. Many organizations have their processes documented in text, and creating formal models has a high cost of specialized staff. The goal of the project is to create a set of annotated data that relate texts to the formal models that describe them, so that they can be used to train Deep Learning neural systems to do this task. ´ Index 1 Introducci´o 8 2 Context 9 2.1 Actorsimplicats ................................ 9 2.2 Business Process Model and Notation . . . . . . . . . . . . . . . . . . . . 9 2.2.1 ElementsdeBPMN .......................... 10 2.3 Natural Language Processing . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4 Natural Language Generation . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5 Problemaaresoldre .............................. 16 3 Justificaci´o 21 4 Abast 23 4.1 Objectius .................................... 23 4.2 Possiblesobstacles ............................... 24 5 Metodologia 25 5.1 M`etodeKanban................................. 25 5.2 Eines....................................... 25 5.3 Validaci´o .................................... 26 6 Planificaci´o temporal 27 6.1 Definici´odetasques .............................. 27 6.1.1 Recursos necessaris . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1.2 Gesti´o del Projecte - GP . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1.3 Generaci´o del dataset - GD . . . . . . . . . . . . . . . . . . . . . . 29 6.1.4 Crear model Deep Learning - MD . . . . . . . . . . . . . . . . . . 30 6.1.5 Documentaci´o - DO . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.2 EstimacionsiGantt .............................. 33 6.3 Plans alternatius i obstacles . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.4 Canvis en la planificaci´o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.4.1 Canvis als objectius . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.4.2 Canvisalscostos............................ 37 2 7 Pressupost 38 7.1 Costosdepersonal ............................... 38 7.2 Costospertasca ................................ 38 7.3 Costosgen`erics ................................. 39 7.3.1 Maquinari................................ 39 7.3.2 Programari ............................... 40 7.3.3 Teletreball................................ 40 7.4 Total dels costos per personal i gen`erics . . . . . . . . . . . . . . . . . . . 41 7.4.1 Conting`encia .............................. 41 7.4.2 Imprevistos............................... 42 7.5 Cost total del projecte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.6 Controldegesti´o................................ 42 8 Informe de sostenibilitat 44 8.1 Dimensi´oecon`omica .............................. 44 8.2 Dimensi´oambiental .............................. 45 8.3 Dimensi´osocial................................. 45 9 Soluci´o plantejada 46 9.1 Einesutilitzades ................................ 46 9.1.1 Camunda ................................ 46 9.1.2 Freeling ................................. 47 9.1.3 SimpleNLG............................... 48 9.1.4 jBPT .................................. 48 9.1.5 RPST .................................. 49 9.2 An`alisi d’alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 9.2.1 ParserBPMN.............................. 50 9.2.2 FreeLing................................. 51 9.2.3 SimpleNLGijBPT........................... 51 9.3 Implementaci´o ................................. 51 9.3.1 Llegir els models BPMN . . . . . . . . . . . . . . . . . . . . . . . . 52 9.3.2 An`alisi morfosint`actica . . . . . . . . . . . . . . . . . . . . . . . . . 53 9.3.3 Generar frases simples . . . . . . . . . . . . . . . . . . . . . . . . . 56 9.3.4 Crearelpar`agraf............................ 57 10 An`alisis del Dataset 61 10.1 Models BPMN utilitzats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 10.2Contingutdedataset.............................. 62 10.3 An`alisi de les descripcions . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 11 Treball futur 66 11.1Tractarelsr´ıgids ................................ 66 11.2 Aconseguir resultats m´es naturals . . . . . . . . . . . . . . . . . . . . . . . 67 11.3 Crear model Deep Learning . . . . . . . . . . . . . . . . . . . . . . . . . . 68 3 12 Conclusions 69 12.1Gesti´odeltemps ................................ 69 12.2Metodologia................................... 69 12.3 Coneixements adquirits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 12.4 Aportacions d’aquest treball . . . . . . . . . . . . . . . . . . . . . . . . . . 70 13 Agra¨ıments 72 Bibliografia 73 A Models BPMN i descripcions i B Codi liv 4 ´ Index de figures 2.1 Representaci´o dels diferents tipus d’Esdeveniments. Font: Elaboraci´o pr`opia....................................... 10 2.2 Representaci´o dels diferents tipus d’Activitats. Font: Elaboraci´o pr`opia. . 11 2.3 Representaci´o dels diferents tipus de Gateways. Font: Elaboraci´o pr`opia. . 12 2.4 Representaci´o dels diferents tipus de Connectors. Font: Elaboraci´o pr`opia. 12 2.5 Representaci´o d’una Swimlane. Font: Elaboraci´o pr`opia. . . . . . . . . . . 13 2.6 BPMN d’exemple. Font: camunda.com . . . . . . . . . . . . . . . . . . . . 17 2.7 Descripci´o robotitzada del BPMN d’exemple de la figura 2.6. Font: Elaboraci´opr`opia. ................................. 18 2.8 Descripci´o m´es natural del BPMN d’exemple de la figura 2.6. Font: Elaboraci´opr`opia. ................................. 18 2.9 Exemple d’un BPMN m´es complex. Font: bpmn-miwg . . . . . . . . . . . 19 2.10 Descripci´o del BPMN de la figura 2.9. Font: Elaboraci´o pr`opia. . . . . . . 20 4.1 Subobjectius de cada part del projecte. Font: Elaboraci´o pr`opia. . . . . . 23 5.1 Metodologia Kanban. Font: Pixabay. . . . . . . . . . . . . . . . . . . . . . 26 6.1 Diagrama de Gantt del projecte. Visualitzat en la web Asana. Font: Elaboraci´opr`opia................................ 34 9.1 Logotip de Camunda. Font: camunda.com . . . . . . . . . . . . . . . . . . 47 9.2 Exemple de conversi´o d’un graf BPMN a un arbre RPST. Font: The Refined Process Structure Tree. Jussi Vanhatalo, Hagen V¨olzer, Jana Koehler ..................................... 49 9.3 Tipus de fragments d’un RPST. Font: J. Vanhatalo et al. Data & Knowledge Engineering 68 (2009) 793–818 . . . . . . . . . . . . . . . . . . . . . 50 9.4 Diagrama que mostra la relaci´o entre els m`oduls del projecte. Font: Elaboraci´opr`opia ................................. 52 9.5 Part d’un BPMN parsejat guardat com a JSON. Visualitzat en la web JSON Editor. Font: Elaboraci´o pr`opia . . . . . . . . . . . . . . . . . . . . 53 9.6 Exemple d’un JSON retornat pel Freeling. Font: Elaboraci´o pr`opia . . . . 54 9.7 Exemple simple de creaci´o d’una frase amb SimpleNLG. Font: Elaboraci´o pr`opia ...................................... 56 5 9.8 JSON modificat pel m`odul Sentences Generator. Visualitzat en la web JSON Editor. Font: Elaboraci´o pr`opia . . . . . . . . . . . . . . . . . . . . 57 9.9 Fragments de l’arbre RPST del model d’exemple Cook. Font: Elaboraci´o pr`opia ...................................... 58 9.10 Arbre RPST del model d’exemple Cook. Font: Elaboraci´o pr`opia . . . . . 59 9.11 Exemple simple de combinaci´o de frases amb SimpleNLG. Font: Elaboraci´opr`opia .................................... 60 9.12 Diagrama de classes pr`opies utilitzades en crear el par`agraf. Font: Elaboraci´opr`opia ................................. 60 6 ´ Index de taules 6.1 Taula de les tasques. Font: Elaboraci´o pr`opia. . . . . . . . . . . . . . . . . 32 7.1 Rols del projecte i la facturaci´o per hora. Font: Elaboraci´o pr`opia. . . . . 38 7.2 Taula del cost per cada tasca. Font: Elaboraci´o pr`opia. . . . . . . . . . . 39 7.3 Costos del maquinari. Font: Elaboraci´o pr`opia. . . . . . . . . . . . . . . . 40 7.4 Costos pel programari. Font: Elaboraci´o pr`opia. . . . . . . . . . . . . . . 41 7.5 Costos de personal i gen`erics. Font: Elaboraci´o pr`opia. . . . . . . . . . . . 41 7.6 Taula amb els costos dels imprevistos. Font: Elaboraci´o pr`opia. . . . . . . 42 7.7 Taula amb els costos totals del projecte. Font: Elaboraci´o pr`opia. . . . . . 42 10.1 Taula de l’an`alisi dels models. Font: Elaboraci´o pr`opia. . . . . . . . . . . 64 10.2 Taula de l’an`alisi de les descripcions generades per model. Font: Elaboraci´opr`opia.................................... 65 7 1 Introducci´o El diccionari de l’Institut d’Estudis Catalans [1] defineix un proc´es com una manera de descabdellar-se una acci´o progressiva. ´ Es a dir, que qualsevol conjunt d’accions que realitzem en el dia a dia es pot definir com a un proc´es. De la mateixa manera, en una empresa es duen a terme una llarga llista d’accions que permeten aconseguir els objectius marcats. Evidentment, en una empresa els processos no s´on tan simples com les que es realitzen di`ariament. En conseq¨u`encia, ´es molt important que cada una de les tasques estigui ben definida. La definici´o formal de processos de negoci en est`andards com BPMN 2.0 ´es un pas crucial per a la transformaci´o digital de les organitzacions, ja que permet gestionar els processos que es duen a terme en una empresa. Moltes organitzacions tenen els seus processos documentats en text, i crear els models formals t´e un elevat cost de personal especialitzat. Automatitzar la creaci´o de diagrames BPMN seria molt ´util per a les empreses. Una manera per a aconseguir aix`o seria utilitzar models de Deep Learning. Malauradament, per entrenar aquests models es necessita una gran quantitat de dades que no sempre ´es f`acil d’aconseguir. Per evitar l’escassetat de dades, en aquest treball es pret´en crear un programa que generi un dataset de diagrames BPMN enlla¸cats amb la corresponent descripci´o en llenguatge natural. 8 al text final. En aquest apartat s’exposa qu`e ´es aquesta tecnologia i com es fa servir. NLG ´es un subcamp de l’intel.lig`encia artificial i de la ling¨u´ıstica computacional. S’ocupa de la construcci´o de sistemes inform`atics que poden produir textos comprensibles pels humans a partir d’una font d’informaci´o no ling¨u´ıstica [16]. El seu objectiu principal ´es convertir la informaci´o que contenen els ordinadors en un escrit entenedor i automatitzar l’escriptura de narratives orientades a les dades [17]. Les aplicacions de NLG utilitzen regles basades en la morfologia, el l`exic, la sintaxi i la sem`antica per a escollir com redactar les respostes de forma adequada. Aquest proc´es es fa en tres etapes [18]: •Planificaci´o del text: Es formula el contingut general i s’ordena de forma l`ogica. •Planificaci´o de les frases: S’organitzen les frases tenint en compte els signes de puntuaci´o i afegint pronoms o conjuncions quan sigui necessari. •Realitzaci´o: Es genera la frase considerant la precisi´o gramatical i assegurant que es respecten les normes de puntuaci´o i conjugaci´o. Existeixen tres tipus d’eines de Natural Language Generation [17]: •B`asic: Nom´es transforma dades en text. •Basat en plantilles: Encaixa les dades en plantilles de text. •Avan¸cat: Dedueix caracter´ıstiques a partir de les dades i utilitza el context per a adaptar el missatge. Es poden trobar similituds entre Natural Language Generation (NLG), Natural Language Processing (NLP) i Natural Language Understanding (NLU), ja que totes tres treballen la mateixa disciplina. Tanmateix, existeixen matisos que les diferencien. El programari NLG ´es capa¸c d’escriure, per`o no pot llegir. Aix`o el diferencia de NLP que llegeix dades desestructurades de llenguatge hum`a i les converteix en dades estructurades que es poden entendre. Aquesta part de NLP s’anomena Natural Language Understanding [19]. NLG i NLU s´on subseccions d’un domini de NLP m´es general que compren tot el programari que interpreta o produeix llenguatge hum`a. NLP s’encarrega d’entendre les dades en funci´o de la gram`atica i el context. NLP converteix text en dades estructurades i NLG genera un escrit basat en dades estructurades [19]. Aquesta tecnologia ´es tan vers`atil que s’utilitza en molts camps. Els principals camps s´on generaci´o autom`atica d’informes, subt´ıtols d’imatges, chatbot, escriptura creativa i 15 humor computacional [16]. Per`o, tamb´e es fa servir en disciplines com pol´ıtica, banca i finances, fabricaci´o i assegurances [20]. Hi ha diverses eines que es poden fer servir per a desenvolupar projectes de NLG. Es poden diferenciar en eines comercials i eines de codi lliure. A continuaci´o, es mostren exemples de cada tipus amb una breu descripci´o [19]. Algunes eines comercials s´on: •Arria NLG:´ Es una de les empreses l´ıders mundialment en tecnologies NLG. El seu programari ´es una forma d’intel.lig`encia artificial que transforma dades estructurades en llenguatge natural [21]. •AX Semantics: Aquesta companyia ofereix serveis de NLG en camps com el comer¸c electr`onic, periodisme i dades. Utilitza IA i machine learning per a entrenar el motor NLP. •Wordsmith:´ Es un motor NLG que permet als usuaris convertir dades en text en qualsevol format o escala. Algunes llibreries de codi obert s´on: •NaturalOWL:´ Es un conjunt d’eines de codi obert que s’utilitza per a generar descripcions sense fer gaire programaci´o. •GPT-3:´ Es un model de llenguatge autoregressiu que fa servir Deep Learning per produir textos que simulen la redacci´o humana [22]. Ha estat creat per l’empresa OpenAI. •SimpleNLG:´ Es un dels realitzadors de codi oberts m´es utilitzats. Aquesta API de Java ha sigut desenvolupada pel fundador de Arria. Les seves funcionalitats s´on b`asiques, per`o s´on senzilles de fer anar i estan ben documentades. ´ Es l’eina que s’ha decidit fer servir en aquest treball, en l’apartat [23] se’n parla m´es a fons. 2.5 Problema a resoldre Com s’ha comentat anteriorment, el modelatge dels processos empresarials ´es una part vital a l’hora d’establir el funcionament d’un projecte. Moltes empreses tenen textos que expliquen com estan definits les accions a realitzar, per`o no ho tenen modelat en un llenguatge formal. El modelatge pot arribar a comportar fins al 60% del temps gastat en els projectes de gesti´o de processos. Una possible soluci´o per a automatitzar la creaci´o dels diagrames a partir de descripcions en llenguatge natural ´es fer servir t`ecniques modernes d’Intel.lig`encia Artificial. En aquest cas concret es podria entrenar un model de Deep Learning a partir d’un conjunt 16 de diagrames que tenen associat la seva descripci´o en llenguatge natural. Lamentablement, tal com Matthew Stewart [24] explica, un dels reptes de l’aprenentatge autom`atic ´es la manca de dades i la falta de bones dades. Aconseguir els conjunts de dades adequats ´es complex, ja que per motius de privacitat i confidencialitat molt poques empreses alliberen les descripcions dels seus processos. En aquest projecte es pret´en abordar el problema de l’escassetat de dades. Es far`a generant descripcions sint`etiques, que semblin m´ınimament reals, i que permetin entrenar algorismes de forma fiable i controlada. A continuaci´o, en la figura 2.6 es mostra un exemple d’un model BPMN que representa el proc´es de preparaci´o d’un `apat. Per a il.lustrar el que es pret´en fer al treball el model est`a acompanyat d’una descripci´o en llenguatge natural generat a m`a, per`o l’objectiu ´es aconseguir generar una descripci´o similar autom`aticament. Figura 2.6: BPMN d’exemple. Font: camunda.com En aquest cas la descripci´o de la figura 2.7 ´es senzilla perqu`e l’exemple utilitzat ho era, per`o no sempre ser`a aix´ı. Tamb´e s’hauria de vigilar que no sembli un text molt artificial, per`o aix`o ja ´es m´es complicat. En la figura 2.8 es pot observar una descripci´o m´es propera al llenguatge utilitzat per un hum`a. Aquest hauria de ser l’objectiu final a assolir de cara a tenir un bon conjunt de dades, per`o no ´es tan senzill d’aconseguir. En l’exemple 2.8 podem veure que s’hi ha afegit una s`erie de connectors per a fer-lo menys robotitzat. Cal tenir en compte que l’objectiu del projecte ´es generar un conjunt de dades que es pugui fer servir per a entrenar un model d’aprenentatge autom`atic. 17 When hunger is noticed, a recipe is chosen. Then the question ’desired components?’ is asked. If the answer is salad, then a salad is prepared. If the answer is something real, then the question ’desired dish?’ is asked. If the answer is pasta, then pasta is cooked, otherwise if the answer is steak, then a steak is cooked. Then the meal is eaten and hunger is satisfied. Figura 2.7: Descripci´o robotitzada del BPMN d’exemple de la figura 2.6. Font: Elaboraci´o pr`opia. Once the hunger is noticed, a recipe is chosen. If salad is chosen as a desired component, then a salad is prepared. Besides of that, it is possible to select something real. In that case, the desired dish mush be chosen between pasta and steak. If the desired dish is pasta, then pasta is cooked, otherwise a steak is cooked. Finally, the meal is eaten and hunger is satisfied. Figura 2.8: Descripci´o m´es natural del BPMN d’exemple de la figura 2.6. Font: Elaboraci´o pr`opia. Aix`o implica que si tots els registres contenen construccions similars, el model aprendr`a poc. Per aix`o, s’hauria d’intentar fer servir sin`onims o connectors equivalents per a cada registre. A m´es, un model pot comptar amb moltes m´es activitats i ramificacions. Aix`o pot complicar la generaci´o de la frase per qu`e cal decidir quan s’ha de fer un nou par`agraf. Tamb´e cal estructurar b´e el text perqu`e quan diverses ramificacions s’ajuntin s’entengui el conjunt sencer del par`agraf. Aquests reptes s´on els que s’intentaran superar en el transcurs d’aquest projecte. En la figura 2.9 s’hi mostra un exemple d’un BPMN real i m´es complex. En la figura 2.10 s’hi pot veure una possible descripci´o ideal feta a m`a. Malgrat estar escrita per un hum`a, es pot veure com en alguns casos costa de seguir, sobretot quan hi ha bifurcacions, frases molt llargues o activitats que assenyalen a altres activitats esmentades anteriorment. Si fins i tot costa que una persona faci una descripci´o acurada i f`acil d’entendre d’un model complex, un programa autom`atic tamb´e ho tindr`a complicat. 18 Figura 2.9: Exemple d’un BPMN m´es complex. Font: bpmn-miwg 19 The process starts once the candidate has accepted the offer, then the HR Department sends him the contract. If the contract terms aren’t accepted, then the HR Department reviews the terms of the contract and sends it again. If the contract terms are accepted, then get signature on the contract and notify the responsible department. Then the HR Department informs the employee of company policies, introduces him to company mission, vision and values, performs training for time reports, sick leave and holidays and registers him for medical insurance. At the same time, the responsible department requests the preparations for a new employee, the event new employee in department X happens. Once the previous activities are done, the responsible department introduces the new employee to the team and performs training for the position. Then, at the same time, the events input from IT ready, input from Payroll ready, input from facilities ready happen. Once the previous activities are done, the responsible department compiles the welcome package and finally gives him he welcome package. Figura 2.10: Descripci´o del BPMN de la figura 2.9. Font: Elaboraci´o pr`opia. 20 3 Justificaci´o Donat que el modelatge de processos amb l’est`andard BPMN ´es molt espec´ıfic l’estat de l’art no ´es molt extens. Tot i aix`o, es poden trobar diverses aplicacions similars, encara que no fan ben b´e el que es pret´en en aquest treball. Aquests projectes fets anteriorment els podem classificar entre els que transformen d’un diagrama BPMN a text natural i els que ho fan a l’inrev´es. Abans, desenvolupar una eina que automatitz´es qualsevol proc´es requeria molt esfor¸c i dedicaci´o, ja que, s’havien de tenir en compte totes les possibles combinacions en els possibles inputs. Aix`o feia que en certs camps, com ara el de convertir un text natural, fos pr`acticament impossible d’aconseguir. Per sort, m`etodes com el Deep Learning permeten generar contingut de forma r`apida i eficient. Per`o, per aconseguir un model funcional es requereix un conjunt de dades molt gran i divers, i no sempre ´es f`acil obtenir-lo [25]. Per a solucionar el problema plantejat en aquest treball no disposem d’un bon dataset que ens permeti generar un model de Deep Learning fiable. ´ Es per aix`o, que la part principal d’aquest treball consisteix a crear una aplicaci´o que generi un conjunt de dades variat i amb prou registres. Aix`o es far`a convertint diversos diagrames a un llenguatge natural que sigui entenedor per qualsevol persona sense coneixement de BPMN. En aquest cas s’ha decidit que es far`a servir l’angl`es, ja que ´es un dels m´es parlats al m´on. Per a fer aquesta primera part, hi ha un treball del 2016 titulat Transformant Models BPMN a Llenguatge Natural [26] que fa quelcom semblant. En el treball es llegeix el fitxer BPMN, despr´es es crea un RSPT (Refined Program Structure Tree) per a guardar la informaci´o necess`aria per solucionar el problema i tamb´e es fa servir una xarxa de Petri per a extreure l’estructura del proc´es. Finalment, es fa la generaci´o del text analitzant cada element i concatenant els diferents missatges seguint l’estructura dels arbres creats anteriorment. 21 La segona part del projecte consisteix a entrenar una xarxa neuronal que sigui capa¸c d’interpretar una descripci´o en llenguatge natural i que ho converteixi en un model BPMN. Per a fer aix`o, es far`a servir el dataset que hem creat a la primera part. De treballs anteriors i aplicacions existents que converteixin de text a diagrames n’hi ha algunes que s’esmenten a continuaci´o. Per`o cap d’elles fa servir un model de Deep Learning. Per tant, en aquest cas caldr`a entrenar el model des de zero. Process Talks [27] ´es una aplicaci´o web que permet modelar processos a partir d’una explicaci´o informal, sigui escrivint o parlant. L’eina fa servir regles i patrons que analitzen l’estructura sint`actica de les frases i treuen informaci´o de qui realitza cada acci´o, o quina acci´o precedeix una altra. Aquesta implementaci´o ´es costosa de mantenir i no ´es escalable, ja que, ´es complicat traspassar-la a nous idiomes. Per aix`o, l’objectiu del projecte ´es crear una alternativa basada en Machine Learning. A part d’aquesta aplicaci´o web, tamb´e podem trobar un treball de recerca anomenat Process Model Generation from Natural Language Text [28]. Podem veure que es combinen algunes eines existents en el processament del llenguatge natural per a obtenir uns millors resultats. L’avaluaci´o mostra que per a un conjunt de 47 parells de text-model de la ind´ustria i els llibres de text, generen de mitjana el 77% dels models correctament. Com s’ha pogut veure hi ha poques implementacions que serveixin de cara a plantejar una soluci´o. Tanmateix, s’intentar`a aprofitar el m`axim de recursos disponibles per a reduir costos i temps. 22 4 Abast 4.1 Objectius El principal objectiu del projecte ´es crear un conjunt de dades anotades que relacionin textos amb els models formals que els descriuen. Les dades han de servir per a ser usades per entrenar sistemes neuronals que donats un text en llenguatge natural el converteixin a un diagrama BPMN. Com ja s’ha dit anteriorment a l’apartat de Justificaci´o, el projecte es pot dividir en dos parts. La primera i principal ´es la Generaci´o del Dataset i la segona ´es la d’Entrenar un model de Deep Learning com a demostraci´o que el dataset ´es ´util. En la figura 4.1 es pot veure les diferents parts del projecte i els subobjectius que t´e cadascuna d’elles. Figura 4.1: Subobjectius de cada part del projecte. Font: Elaboraci´o pr`opia. En fase de generaci´o del dataset el que es busca ´es tenir un conjunt de dades amb suficients registres i amb descripcions prou variades que serveixi per a poder entrenar despr´es un model. Per a generar les dades cal crear un programa que llegeixi (en angl`es parse) els elements d’un diagrama BPMN i emmagatzemi la informaci´o necess`aria en un fitxer JSON. Caldr`a 23 extreure i modificar els elements que es necessitin. Un cop fet aix`o nom´es caldr`a fer la tria dels atributs que es volen. Despr´es s’identificaran els verbs, objectes i complements de les frases de cada element utilitzant un software d’an`alisis ling¨u´ıstic anomenat FreeLing [29] [30] [31] [32] [33]. Tot seguit, es procedir`a a crear les descripcions en llenguatge natural, utilitzant un software de generaci´o de llenguatge natural anomenat SimpleNLG[23]. Un cop s’hagi desenvolupat el programa anterior, simplement caldr`a repetir el proc´es de generaci´o de text per a cada un dels models BPMN i emmagatzemar el conjunt de les dades en un format adequat per a poder-ho utilitzar despr´es. La segona part del projecte ´es la de crear un model de Deep Learning que serveixi com a demostraci´o que el conjunt de dades generat ´es utilitzable. En aquest pas s’haur`a de carregar el dataset generat anteriorment, entrenar el model i provar que retorna el resultat que es vol. Si no s’ha obtingut un resultat satisfactori, es pot polir el model canviant par`ametres. 4.2 Possibles obstacles ´ Es molt com´u que quan es comen¸ca a fer un projecte es trobin obstacles i problemes que no s’havien plantejat. Quan aix`o passa pot ser que el projecte s’endarrereixi molt. Per tant, s’ha d’intentar tenir en compte el conjunt de riscos que poden sorgir. Un dels obstacles que pot apar`eixer ´es que no es disposi de prou diagrames BPMN i, per tant, no poder crear un dataset amb gaires registres. Tamb´e pot oc´orrer que la utilitzaci´o de llibreries no sempre funcioni correctament. En aquest cas s’haur`a d’invertir molt m´es temps a crear alternatives. Tenir suficient informaci´o disponible per a fer un projecte ´es important, i el fet que no es pugui trobar prou documentaci´o sobre un tema ´es un risc a tenir en compte. A m´es a m´es, s’ha de tenir present que el temps ´es limitat, per tant, ´es possible que no sempre es puguin assolir tots els objectius marcats. 24 Carregar dataset - MD-C Per a crear un model de Deep Learning primer es carrega el dataset desitjat. Aix´ı doncs, s’haur`a de llegir el fitxer que cont´e les dades amb una llibreria adequada. En principi sembla una tasca f`acil, per`o la lectura de fitxers sempre pot donar problemes. I m´es quan el conjunt de dades ha sigut autogenerat. S’estima que la durada d’aquesta tasca ´es d’unes 26 hores. Aquesta tasca no es pot iniciar fins que no s’hagi finalitzat tot l’apartat de Gesti´o de Projectes (GP) i l’apartat de Generaci´o del Dataset (GD). Entrenar model - MD-E A continuaci´o, ja es pot entrenar el model usant les dades carregades. D’entrada, en aquesta tasca s’ha de definir quina arquitectura es vol fer servir en el model. Despr´es es definiran uns par`ametres i es procedir`a a entrenar el model predictiu. Si no s’han obtingut uns bons resultats, es pot canviar els par`ametres amb la intenci´o de millorar la generaci´o final del text, per`o no ´es necessari. S’estima que la durada d’aquesta tasca ´es d’unes 48 hores. Aquesta tasca no es pot iniciar fins que no s’hagi finalitzat la tasca de carregar el dataset (MD-C). Provar model - MD-P Aquesta tasca consisteix a comprovar si els resultats s´on prou bons. Com que no es tracta d’un proc´es de classificaci´o autom`atic validar que la sortida obtinguda ´es un proc´es manual i, per tant, cost´os. Aquesta tasca es dur`a a terme pr`acticament alhora que la d’entrenar el model. S’estima que la durada d’aquesta tasca ´es d’unes 38 hores. Aquesta tasca no es pot iniciar fins que no s’hagi finalitzat la tasca d’entrenar un model (MD-E). 6.1.5 Documentaci´o - DO La documentaci´o ´es una tasca molt important del treball, ja que ´es la que permet explicar com s’ha organitzat, realitzat i quins resultats s’ha obtingut. S’ha de dur a terme parall·lelament durant tot el desenvolupament. En aquest apartat s’espera invertir unes 120 hores en total. Mem`oria - DO-M Aquesta tasca es far`a alhora que la resta del projecte i contextualitzar`a el treball, es detallaran tots els passos que s’han seguit i es justificar`a cada decisi´o presa. S’estima que la durada d’aquesta tasca ´es d’unes 90 hores. Presentaci´o - DO-P En aquesta tasca es crear`a una presentaci´o que contindr`a un breu resum del projecte elaborat. Aquesta ser`a un ajut visual de cara a la presentaci´o que es faci d’aquest treball davant del tribunal que avalu¨ı el projecte. Tamb´e s’hi ha de tenir en compte el temps 31 per a preparar l’explicaci´o oral. S’estima que la durada d’aquesta tasca ´es d’unes 30 hores. La tasca no es pot iniciar fins que no s’hagi finalitzat la resta del treball (GP, GD, MD, DO-M). Codi Nom Tasca Temps Estimat Depend`encies Temporals Recursos GP-C Contextualitzaci´o i abast 15 h - R1, R2 GP-T Planificaci´o temporal 13 h GP-C R1, R2 GP-M Metodologia 13 h GP-C R1, R2 GP-P Pressupost 13 h GP-C R1, R2 GP-S Informe de sostenibilitat 13 h GP-C R1, R2 GP-I Instal.laci´o programari 20 h - R1, R2 GD-O Obtenir models BPMN 13 h - R1, R2, R3 GD-P Parsejar BPMN 27 h GD-O R1, R2, R3 GD-I Identificar verbs 47 h GD-P R1, R2, R3 GD-D Crear descripcions 70 h GD-I R1, R2, R3 GD-C Crear dataset 33 h GD-C R1, R2, R3 MD-C Carregar dataset 26 h GD R1, R2, R3 MD-E Entrenar model 48 h MD-C R1, R2, R3 MD-P Provar model 38 h MD-E R1, R2, R3 DO-M Mem`oria 90 h - R1, R2 DO-P Presentaci´o 30 h DO-M R1, R2 Taula 6.1: Taula de les tasques. Font: Elaboraci´o pr`opia. 32 6.2 Estimacions i Gantt En aquest apartat s’utilitza un diagrama de Gantt per a visualitzar l’ordre i duraci´o de cadascuna de les tasques descrites anteriorment. Un diagrama de Gantt [40] ´es un tipus de gr`afic que il.lustra el calendari d’un projecte. Aquest diagrama mostra les tasques que s’han d’executar en l’eix vertical i en l’eix horitzontal mostra el moment d’inici, el moment de finalitzaci´o i la duraci´o de cada tasca. Com s’ha comentat anteriorment en l’apartat de Planificaci´o temporal 6 en cada setmana es disposa de 21 h per a executar les diferents tasques. A continuaci´o, es mostra el diagrama de Gantt. 33 Figura 6.1: Diagrama de Gantt del projecte. Visualitzat en la web Asana. Font: Elaboraci´o pr`opia 34 6.3 Plans alternatius i obstacles En tot projecte s’ha de tenir previst que puguin apar`eixer inconvenients. En conseq¨u`encia cal pensar b´e quins problemes poden sorgir en cada fase del treball i proposar una soluci´o alternativa. A continuaci´o s’explica quins plans es poden seguir en cas que apareguin alguns obstacles. •Un dels principals problemes que sorgeix a quasi tots els projectes ´es la manca de temps. Per abordar aquest obstacle s’ha decidit que no cal crear cap tasca alternativa, sin´o que s’intentar`a treballar m´es hores de les proposades per poder arribar a temps a la data l´ımit. Tamb´e s’ha tingut present aix`o a l’hora d’assignar la c`arrega a cada tasca. Es pot veure que el temps estimat total per a la realitzaci´o del projecte ´es d’unes 509 hores, per`o en TFG s’haurien de dedicar unes 540 hores. Llavors es t´e unes 31 hores que es poden realitzar de m´es i continuar acabant a temps el pla. A m´es, en l’an`alisi de temps dedicat a cada tasca tamb´e s’ha tingut en compte que entrenar i provar el model no sortir`a b´e de seguida. Per tant, en els temps estimats ja t´e en compte que es pugui tardar a obtenir un resultat desitjable. •Un altre dels problemes que pot apar`eixer ´es que la informaci´o sobre el tema del treball no sigui gaire extensa, aix`o suposa un problema per qu`e costa m´es entendre com s’ha de procedir. La soluci´o ´es espr´emer al m`axim la informaci´o disponible i aprendre a partir de la investigaci´o pr`opia. •Un altre problema que pot sortir ´es que el dataset creat no sigui prou divers o que no es tinguin gaires models BPMN per a crear el dataset. Si un d’aquests casos apareix, implicaria que mai es podria obtenir un bon model de Deep Learning. Com que aix`o no ´es tolerable s’hauria de crear una nova tasca anomenada Crear models BPMN inventats (GD-O). Es tractaria d’usar data augmentation per a obtenir m´es models BPMN i aix´ı intentar aconseguir un dataset m´es divers. Evidentment, aix`o ´es complicat de realitzar i no garanteix uns bons resultats, per`o s’hauria de provar. La realitzaci´o d’aquesta tasca podria durar unes 15-25 hores. •L’´ultim possible obstacle que s’ha analitzat ´es que no es disposi de recursos suficients per a entrenar el model. En aquest cas, la soluci´o proposada ´es executar el codi en servidors al n´uvol amb m´es velocitat de processament que les nostres m`aquines en local. Aquests podran ser tant de pagament com gratu¨ıts. S’intentar`a utilitzar sempre l’opci´o m´es econ`omica. Si cal fer servir aquests serveis, no comportar`a un temps afegit, ja que, la posada a punt d’aquests servidors ´es molt r`apida i intu¨ıtiva. 35 6.4 Canvis en la planificaci´o Durant el transcurs del treball es va decidir endarrerir la data de finalitzaci´o del treball. Aquesta va passar de ser del gener del 2022 al juny del 2022. Aquest canvi es va fer perqu`e compaginar el projecte, amb la feina i una assignatura de la universitat va ser impossible. Aix`o implica que s’ha tingut m´es dies dels que es van calcular inicialment, per`o el nombre estimat d’hores dedicades totals ´es el mateix. Tamb´e hi va haver un endarreriment en la primera etapa del projecte, la de parsejar els models BPMN. En la planificaci´o temporal inicial no es va tenir en compte que aquesta etapa podia tardar tant, ja que semblava una part f`acil del projecte. Es va intentar buscar eines o programes que llegissin els models. Malauradament, l’eina escollida va resultar ser poc fiable i es va haver de comen¸car de nou. A m´es a m´es, es va intentar programar de zero un parser que llegeixi cada model, per`o finalment es va decidir utilitzar la llibreria Camunda. Els motius d’aquesta decisi´o s’expliquen m´es endavant en l’apartat d’An`alisi d’alternatives 9.2. Un altre obstacle que es va trobar durant la realitzaci´o del treball ´es que l’´us de la llibreria jBPT 9.1.4 va resultar ser m´es complicat del que s’esperava. Aquesta eina no est`a ben documentada i fa temps que els desenvolupadors no hi introdueixen canvis ni millores. Aix`o ha provocat que l’aprenentatge hagi sigut un proc´es llarg i complex, en el que ha calgut experimentar amb les classes i funcions de la llibreria per a entendre el seu funcionament. En aquesta experimentaci´o tamb´e s’ha trobat que rec´orrer un arbre RPST 9.1.5 no ´es trivial, ja que, un dels m`etodes que cal fer servir (obtenir els fills d’un node de l’arbre) no funciona correctament perqu`e retorna els fills desordenats. Aix`o ha implicat crear funcions que resolguin aquest comportament erroni. A causa dels obstacles esmentats anteriorment es va haver d’adaptar la planificaci´o temporal. Es va canviar la data d’entrega i es va decidir dedicar menys hores setmanalment. Tamb´e es va ampliar el nombre total d’hores dedicades a la tasca de llegir els models BPMN. Aix`o va comportar que la tasca d’entrenar un model de Deep Learning amb les dades del dataset se suprim´ıs de la planificaci´o. 6.4.1 Canvis als objectius Com s’ha comentat pr`eviament, els objectius van variar lleugerament, ja que en la planificaci´o inicial estava previst crear un model predictiu, per`o aquest objectiu es va haver de suprimir. Es considera que no ´es una gran p`erdua perqu`e no era l’objectiu principal, sin´o una forma d’ensenyar la feina feta. Tot i aix`o, l’objectiu principal era generar un conjunt de dades i aquest s’ha mantingut en la planificaci´o alternativa. 36 6.4.2 Canvis als costos No hi ha hagut canvis als costos finals del treball. Malgrat que s’ha desenvolupat el treball amb m´es dies no hi ha hagut un augment de les hores de feina i, per tant, els costos de personal s’han mantingut. Tampoc s’han incrementat els costos per software perqu`e no es tenia cap llic`encia mensual. 37 7 Pressupost En aquest apartat s’elabora una an`alisi econ`omica del projecte amb la finalitat de decidir si ´es factible dur-lo a terme. Cal analitzar i estimar les seg¨uents classes de costos: costos de personal, costos de les tasques, maquinari, programari i costos d’espai de treball. Tamb´e s’ha de tenir en compte els possibles contratemps que puguin sorgir i fer una estimaci´o del que poden costar. A continuaci´o es detallen les classes esmentades. 7.1 Costos de personal Abans de res, s’ha de definir quins rols hi ha involucrats en el projecte. En aquest cas, hi ha el c`arrec de Cap de Projecte, que ´es la persona encarregada de planificar, supervisar i dirigir-lo durant la realitzaci´o d’aquest. ´ Es un rol compartit entre els codirectors del TFG i l’autor d’aquest. Tamb´e existeix el rol de programador, que ´es la persona que dissenya, escriu i depura el codi del projecte. En aquest cas el rol nom´es l’executa l’autor del TFG. A la taula 7.1 es pot veure el sou brut, el que s’ha de pagar de Seguretat Social (SS) i la retribuci´o total de cadascun dels c`arrecs esmentats anteriorment. Els sous bruts han sigut extrets de la p`agina web Glassdoor [41]. Rol Sou brut SS Retribuci´o Cap de projecte 22,5 e/hora 6,75 e/hora 29,25 e/hora Programador 12 e/hora 3,6 e/hora 15,6 e/hora Taula 7.1: Rols del projecte i la facturaci´o per hora. Font: Elaboraci´o pr`opia. 7.2 Costos per tasca El temps de desenvolupar cada tasca ´es diferent, per tant, cal calcular per a cada una de les activitats el seu cost. El temps de cada tasca est`a descrit a l’apartat de Planificaci´o 38 temporal 6. Tamb´e cal considerar que cada tasca pot ser desenvolupada pel Cap del Projecte o pel Programador. Les activitats associades a la Gesti´o del Projecte (GP) 6.1.2 i a la Documentaci´o 6.1.5 les dur`a a terme ´ıntegrament el Cap del Projecte. Les tasques de Generaci´o del Dataset 6.1.3 les desenvolupar`a el Programador. En canvi, les tasques d’Entrenament del Model 6.1.4 les faran el Cap del Projecte i el Programador, aix`o s´ı, el Programador ´es el que hi ha d’invertir m´es temps. En aquestes tasques el Cap del Projecte simplement ajudar`a a dissenyar el model i decidir`a si ´es correcte o no. Codi Nom Tasca Cap del projecte Programador Cost GP-C Contextualitzaci´o i abast 15 h 0 h 438,75 e GP-T Planificaci´o temporal 13 h 0 h 380,25 e GP-M Metodologia 13 h 0 h 380,25 e GP-P Pressupost 13 h 0 h 380,25 e GP-S Informe de sostenibilitat 13 h 0 h 380,25 e GP-I Instal.laci´o programari 0 h 20 h 312,00 e GD-O Obtenir models BPMN 0 h 10 h 156,00 e GD-P Parsejar BPMN 0 h 14 h 218,40 e GD-I Identificar verbs 0 h 31 h 483,60 e GD-D Crear descripcions 0 h 47 h 733,20 e GD-C Crear dataset 0 h 28 h 436,80 e MD-C Carregar dataset 0 h 36 h 561,60 e MD-E Entrenar model 16 h 56 h 1.341,60 e MD-P Provar model 12 h 52 h 1.162,20 e DO-M Mem`oria 90 h 0 h 2632,50 e DO-P Presentaci´o 30 h 0 h 877,50 e Taula 7.2: Taula del cost per cada tasca. Font: Elaboraci´o pr`opia. En la taula 7.2 s’hi troba el codi i nom de totes les tasques que s’han de realitzar. Tamb´e s’hi veu el temps que hi dediquen tant el Cap del Projecte com el Programador. I finalment tamb´e hi ha el cost total de cada tasca, aquest s’ha calculat en funci´o del preu per hora calculat a la taula 7.1. En total el cost de totes les tasques ´es de 10.875,15 e. 7.3 Costos gen`erics En aquest apartat s’expliquen els costos gen`erics que t´e el projecte. Aquests costos s´on la suma dels costos de maquinari, de programari i del teletreball. A continuaci´o es detallen cadascun d’ells. 7.3.1 Maquinari En tot projecte inform`atic es necessita un maquinari per a dur-lo a terme. En aquest cas s’ha fet servir un monitor Newskill Icarus RGB IC27QRS 27”, un port`atil Acer Aspire 3 39 A315-51-59SU, un ratol´ı Logitech G603 i un teclat Logitech G213. A la taula 7.3 s’hi veu el seu preu de mercat l’octubre del 2021 i tamb´e el seu cost amortitzat. Per a calcular el cost amortitzat s’ha de tenir en compte que el maquinari t´e un temps de vida estimat de 4 anys. Per a fer el c`alcul de les hores reals que permet treballar cada eina cal tenir en compte que un any disposa d’uns 231 dies h`abils (251 dies laborables menys 20 dies de vacances) i que 1 dia h`abil compta de 8 hores. Com ja s’ha explicat a l’apartat de Planificaci´o 6, es calcula que es far`a servir aquestes eines unes 540 hores. Per tant, la f´ormula que es fa servir ´es la seg¨uent. 4 anys ·231 dies laborables ·8 hores = 7392 hores h`abils 540 hores de projecte 7392 hores h`abils = 0,073 Per tant, es multiplica el preu de mercat de cada producte per 0,073 per a obtenir el cost amortitzat. Nom del maquinari Preu de mercat Cost amortitzat Monitor 239 e17,45 e Port`atil 519 e37,89 e Ratol´ı 49 e3,50 e Teclat 62 e4,53 e Total 869 e63,37 e Taula 7.3: Costos del maquinari. Font: Elaboraci´o pr`opia. 7.3.2 Programari Actualment, al mercat hi ha disponible una gran quantitat de programari. Aquest pot ser gratu¨ıt o de pagament. Normalment, es pot trobar software gratu¨ıt de qualitat que ens permet executar la tasca i a m´es estalviar diners. Per a dur a terme aquest treball s’ha intentat reduir al m`axim els costos de programari. ´ Es per aix`o que el llistat de programes que es mostra a la taula 7.4 ´es totalment gratu¨ıt. Alguns dels serveis que es faran servir tamb´e tenen una versi´o de pagament, per`o en principi amb la versi´o m´es b`asica d’aquests ens ´es suficient. Tamb´e ´es important comentar que el PyCharm Edu ´es nom´es gratu¨ıt per a estudiants, com que l’autor d’aquest treball ho ´es es pot fer servir, si no ens costaria 19,90 eal mes. 7.3.3 Teletreball Com que el treball es realitza en mig d’una pand`emia, ´es millor evitar els espais p´ublics i, per tant, el treball es fa ´ıntegrament a casa. S’ha de calcular quant costa el fet d’estar teletreballant a casa. Aix`o implica el mobiliari (taules, cadires, etc.), la llum, el lloguer 40 Figura 9.1: Logotip de Camunda. Font: camunda.com Tal com explica Charles Humble [48] aquesta plataforma t´e un motor de processament de models BPMN 2.0 implementat en Java. Consta tamb´e de Cockpit, una eina de seguiment i administraci´o. Un plugin per a Eclipse i un producte anomenat Cycle que es fa servir per sincronitzar diagrames BPMN amb els executables desenvolupats amb Modeler. Com es pot veure, Camunda Platform ´es una eina molt completa, tanmateix, en aquest projecte nom´es es fa servir com a parser dels models BPMN. ´ Es a dir, l’eina s’utilitza per a llegir els diagrames emmagatzemats en XML i convertir-los en objectes de Java. Aquests contenen m`etodes de consulta que permeten extreure els atributs que es consideren m´es importants i despr´es guardar-los en una altra estructura de dades. En aquest cas, es guarden en un fitxer JSON. 9.1.2 Freeling Tal com s’ha explicat en l’apartat Abast 4 en aquest treball tamb´e es fa servir FreeLing [29] [30] [31] [32] [33]. ´ Es un projecte de codi obert dirigit per Llu´ıs Padr´o, un dels directors d’aquest treball. Es va crear amb l’objectiu de compartir amb la comunitat els resultats de la recerca realitzada pel grup de recerca en processament del llenguatge natural de la UPC. FreeLing es desenvolupa i es mant´e pel Centre de Recerca TALP [49], a la Universitat Polit`ecnica de Catalunya. Tamb´e rep moltes contribucions externes de part de la comunitat. ´ Es una llibreria de C++ que permet l’an`alisi del llenguatge en molts idiomes. Alguns d’aquests idiomes s´on l’angl`es, el catal`a, el portugu`es, el rus, l’alemany, el castell`a, entre d’altres. Alguns dels principals serveis que inclou aquesta llibreria s´on la tokenitzaci´o de text, divisi´o de frases, una an`alisi morfol`ogica, reconeixement de paraules compostes, etiquetatge PoS, etc. En aquest projecte es fa servir una versi´o modificada del Freeling que utilitza una gram`atica per a buscar frases en forma d’accions, com per exemple ”enviar missatge al client”. Aquesta adaptaci´o retorna un JSON amb informaci´o sobre el predicat, l’objecte directe i altres complements de la frase. Tamb´e retorna informaci´o sobre el g`enere, 47 el n´umero, el temps del nucli de cada component de l’acci´o. 9.1.3 SimpleNLG SimpleNLG [23] ´es una API de Java per a generar textos en llenguatge natural. El codi original va ser desenvolupat per Ehub Reiter al departament de ci`encies de la computaci´o de la universitat d’Aberdeen, per`o com que ´es un projecte de codi obert, ha tingut diverses contribucions per part de la comunitat. Tamb´e existeix una versi´o de l’API per a Python, desenvolupada per Brad Jascob [50]. Aquesta adaptaci´o ´es pr`acticament igual a l’original, malgrat tot, no totes les classes i els m`etodes han pogut ser replicats. Aquesta eina implementa un sistema l`exic i morfol`ogic que calcula les formes flexionades, un realitzador que genera textos de forma sint`actica, i un microplanificador. Originalment, es va desenvolupar per a crear textos en angl`es, avui en dia ja funciona amb el franc`es, l’itali`a, el brasiler, el neerland`es, l’alemany o el gallec. En aquest projecte es fa servir la funcionalitat del realiser o realitzador. Aquesta permet crear frases a partir de crides a funcions. Les frases es poden crear mitjan¸cant un text ostring, o b´e, definint per separat els components d’una frase (subjecte, complements, predicat, etc.). Aquesta flexibilitat ´es molt pr`actica perqu`e permet crear una frase de SimpleNLG de la manera m´es convenient. Amb les dades obtingudes pr`eviament pel Freeling 9.1.2 es pot generar una frase nova. La utilitat d’aix`o ´es que es pot ajuntar la persona que realitza l’acci´o (lane) amb la mateixa acci´o (text de l’element BPMN) i crear una frase amb sentit. Despr´es, aquestes frases es concatenaran, fent servir les CoordinatedPhrase i els DocumentElement, per a formar par`agrafs que descriuran el proc´es BPMN. 9.1.4 jBPT La llibreria de Java jBPT [51] ´es un conjunt de tecnologies que ajuden a la investigaci´o sobre disseny, execuci´o i avaluaci´o de processos empresarials. Aquesta llibreria ofereix una `amplia gamma d’an`alisis i utilitats que es poden ampliar f`acilment perqu`e ´es de codi obert. Vas ser desenvolupada l’any 2012 per Artem Polyvyanyy i Matthias Weidlich entre molts d’altres. Algunes de les seves funcionalitats s´on les t`ecniques per calcular RPST, arbres de flux de treball, descomposici´o modular d’un arbre, desenvolupar i desenredar d’un sistema de xarxa de Petri, entre moltes altres. En el projecte es fa servir per a guardar el model BPMN com a un graf i posteriorment convertir-lo a un Refined Process Structure Tree (RPST) 9.1.5. Aix`o permet llegir el BPMN com un arbre i, per tant, evitar cicles. En l’´ultima part del treball aix`o ´es molt ´util de cara a ajuntar les frases en un sol par`agraf. 48 9.1.5 RPST Un RPST (Refined Program Structure Tree) ´es un arbre que s’utilitza per a parsejar models BPMN, aquests contenen en els seus nodes la informaci´o necess`aria per a emmagatzemar els elements d’un model i les relacions entre ells. Formalment, es pot descriure de la seg¨uent manera. Un RPST ´es l’arbre dels fragments can`onics d’un model de proc´es G, de manera que el pare d’un fragment can`onic F´es el fragment can`onic m´es petit de Gque cont´e F[52]. Aquests arbres van ser creats per Jussi Vanhatalo, Hagen V¨olzer i Jana Koehler amb la intenci´o de millorar les t`ecniques de parseig de BPMN que existien. La seva soluci´o aconsegueix una descomposici´o m´es fina. L’arbre resultant de parsejar un BPMN amb aquesta t`ecnica ´es ´unic, modular i granular. A m´es, es pot calcular en temps lineal. Figura 9.2: Exemple de conversi´o d’un graf BPMN a un arbre RPST. Font: The Refined Process Structure Tree. Jussi Vanhatalo, Hagen V¨olzer, Jana Koehler Els nodes d’aquests arbres s’anomenen fragments. Cada fragment representa una secci´o del model parsejat. Aquesta secci´o t´e un element d’entrada i un de sortida. Vol dir que per arribar a tots els elements BPMN que s´on dins del fragment cal haver passat abans per l’element d’entrada, i tots els elements de dins el fragment han d’arribar a l’element de sortida. Cada fragment de l’arbre pot tenir m´es fragments com a fills. Aix`o implica que els RPST donen una forma ordenada de poder rec´orrer el model. En un RPST hi ha diferents tipus de fragments [52]. •Trivials: S´on fragments que contenen exactament una aresta. •Pol´ıgon: Un pol´ıgon ´es un graf que cont´e almenys tres nodes, exactament tantes arestes com nodes, de manera que hi ha un cicle que cont´e tots els seus nodes i totes les seves arestes. En la figura 9.3 els grafs P1 i P2 ho s´on. •Bond o Vincles: S´on grafs que cont´e exactament dos nodes i almenys dues arestes entre ells. En la figura 9.3 els grafs B1 i B2 ho s´on. 49 •R´ıgid: S´on fragments que no s´on ni un component trivial, ni pol´ıgon, ni enlla¸c. Aquests s´on els m´es dif´ıcils de treballar, ja que per llegir els elements no hi ha un ordre clar establert. En aquest treball s’ha decidit no tractar-los perqu`e no hi ha prou temps de crear una estrat`egia per processar-los. En la figura 9.3 els grafs T1 iT2 ho s´on. Figura 9.3: Tipus de fragments d’un RPST. Font: J. Vanhatalo et al. Data & Knowledge Engineering 68 (2009) 793–818 9.2 An`alisi d’alternatives En aquest apartat s’expliquen les decisions que s’han pres i el motiu de cada una d’elles. 9.2.1 Parser BPMN Inicialment, es va pensar que seria millor desenvolupar el projecte en Python, ja que ´es m´es f`acil de fer servir i l’autor est`a m´es acostumat a utilitzar-lo. Per aix`o es va comen¸car a buscar parsers de BPMN que es poguessin fer servir en aquest llenguatge. Desafortunadament, no existeixen llibreries fiables i es va haver d’optar per un projecte de codi obert anomenat python-bpmn-engine [53]. Aquest no comptava amb una bona documentaci´o i no feia exactament el qu`e es volia i finalment es va descartar usar-lo. 50 Amb els directors del projecte es va proposar implementar un parser des de zero en Python, o b´e fer servir la llibreria Camunda. Fer-lo de nou tenia els avantatges de ser en un llenguatge m´es tractat pel desenvolupador i que es podia dissenyar com es volgu´es. Per contra, implicava moltes hores de feina per a tenir una versi´o final. Finalment, despr´es d’aconseguir instal.lar el Camunda es va fer servir aquesta llibreria. Est`a molt ben documentada i ja t´e molts m`etodes creats. Per tant, els ´unics problemes van ser a l’hora d’instal.lar-la i d’aprendre el seu funcionament. 9.2.2 FreeLing La llibreria FreeLing es va escollir perqu`e un dels directors va participar en el seu desenvolupament. Aix`o implica que durant el treball s’ha tingut suport de primera m`a per part d’un dels creadors. Ha sigut especialment ´util quan s’ha trobat algun problema amb l’eina perqu`e ha sigut molt senzill de resoldre. 9.2.3 SimpleNLG i jBPT En el cas d’aquestes dos llibreries tamb´e van ser propostes dels directors del projecte. Tot i que tamb´e s’ha estudiat si existeixen alternatives millors, no se n’ha trobat. En el cas de SimpleNLG tamb´e es va analitzar si era millor fer servir la llibreria en Python o Java. Al final es va decidir en Java, ja que era el llenguatge original i estava plenament documentat i desenvolupat. 9.3 Implementaci´o En aquesta secci´o s’explica com s’ha desenvolupat cada part del projecte. El desenvolupament del projecte s’ha dividit en cinc parts diferents. Cada m`odul ´es independent de la resta, aix`o vol dir que sempre que es disposi d’una entrada adequada el m`odul pot executar-se sense executar la resta. Aix`o permet una gran flexibilitat tant a l’usuari del programa, com als desenvolupadors. Tots els m`oduls llegeixen els fitxers corresponents (el path s’indica abans d’iniciar el programa), els tracten i generen nous fitxers. Aquests fitxers de sortida s´on els que, m´es tard, es poden utilitzar com a entrada de la resta de m`oduls. Malgrat ser independents, la primera execuci´o (quan encara no s’ha obtingut cap fitxer de sortida) cal fer-la seq¨uencialment i en el mateix ordre que estan descrits a continuaci´o. En la figura 9.4 s’observa el conjunt de m`oduls que conformen el projecte i com es relacionen entre ells. Una aresta entrant indica l’extensi´o dels fitxers d’entrada, i una aresta sortint indica l’extensi´o dels arxius de sortida. Si hi ha un asterisc davant del nom de l’extensi´o, vol dir que aquell m`odul llegeix o escriu m´ultiples arxius. Tamb´e s’hi indica el directori on s’emmagatzema cada arxiu per defecte. 51 Figura 9.4: Diagrama que mostra la relaci´o entre els m`oduls del projecte. Font: Elaboraci´o pr`opia 9.3.1 Llegir els models BPMN Aquest m`odul ´es l’encarregat de llegir (parsejar) els models BPMN i obtenir la informaci´o necess`aria per a poder tractar-los m´es tard. El programa busca per defecte els models a la carpeta ../bpmn_models, per`o es pot canviar passant un argument amb el path desitjat a l’executable del programa. Dins d’aquesta carpeta s’hi busquen tots els arxius .bpmn que hi hagi (encara que estiguin en subcarpetes). Aquests arxius s´on XML modificats que serveixen per a especificar els diagrames. Per a llegir aquests fitxers s’ha fet servir la llibreria Camunda. Tal com s’ha explicat en l’apartat 9.1.1, la llibreria ens serveix per a convertir l’entrada en objectes de Java. D’aquesta manera es poden llegir i tractar els elements que es consideren necessaris. Aquests elements es guarden dins de la carpeta ../bpmn_parsed en un fitxer JSON. En un mateix model BPMN pot haver-hi varis Start Events (esdeveniments inicials). Aix`o pot passar quan hi ha diversos subprocessos dins del model. Aix`o suposava un problema a l’hora de crear l’arbre RPST en el m`odul d’unir les frases 9.3.4. Per evitar dificultats s’ha decidit tractar cada subproc´es com si fos un model BPMN diferent. Per a cada arxiu es guarden tots els seus elements (esdeveniments, activitats i portes). I per cada element s’emmagatzema l’identificador, el nom, el tipus, el lane al qual pertany i l’identificador i nom de l’aresta de cada element que segueix. En la figura 9.5 s’hi veu un exemple d’un BPMN parsejat. 52 Figura 9.5: Part d’un BPMN parsejat guardat com a JSON. Visualitzat en la web JSON Editor. Font: Elaboraci´o pr`opia 9.3.2 An`alisi morfosint`actica Per a obtenir l’an`alisi morfosint`actica dels noms de cada element d’un BPMN, s’ha creat un client de Freeling 9.1.2 en Python.´ Es imprescindible que per a c´orrer aquest programa estigui executant-se una imatge personalitzada del Docker del Freeling. Aquesta imatge ha estat adaptada pels directors del projecte per a poder-la fer servir en aquest projecte de fi de grau. La figura 9.6 mostra un exemple d’una frase processada amb aquest programa. En aquest treball, nom´es cal fer servir els seg¨uents elements: •predL: Indica el lema del nucli cel predicat. Es fa servir per obtenir el verb de la frase. •objW: Indica les paraules que formen l’objecte directe de l’acci´o. •objMSD: Indica la informaci´o morfol`ogica del nucli de l’objecte directe (g`enere, numero, temps, etc.). •compW: Indica les paraules que formen els complements de l’acci´o (a qui s’envia, on s’envia, des d’on, etc.). 53 Figura 9.6: Exemple d’un JSON retornat pel Freeling. Font: Elaboraci´o pr`opia En el cas que alguna frase no segueixi el format acceptat pel Freeling (nom´es accepta accions) pot ser que no es retorni res. Llavors, no es pot aprofitar tot el potencial del SimpleNLG, ja que aquesta eina necessita que li indiquis clarament quins s´on els elements de la frase. ´ Es a dir, cal indicar el verb, els subjecte, els adjectius, etc. En aquests casos es pot obviar l’an`alisi o b´e tractar l’element abans d’enviar-lo. Obviar l’an`alisi implica crear un objecte de SimpleNLG com si fos un string, per tant, no ´es recomanable. ´ Es millor intentar fer un pretractament. Per`o ´es complex, ja que no sempre cal actuar igual. Un dels problemes que t´e Freeling ´es detectant frases que contenen un signe d’interrogaci´o. Per aix`o, el que es fa ´es suprimir l’interrogant abans d’enviar-los al Freeling. Actualment, aquest ´es l’´unic pretractament que reben les frases abans de ser processades pel Freeling. El client est`a configurat amb uns par`ametres per defecte que permeten carregar els arxius d’entrada, la connexi´o amb el Docker i escriure la sortida. Els par`ametres i els seus valors per defecte s´on aquests: •-l o--lang: Configura l’idioma del Freeling. Per defecte en. •-p o--parsedpath:Path dels JSON d’entrada. Per defecte ../bpmn_parsed. •-dh o--host:Host de la imatge de Freeling. Per defecte 172.17.0.2. •-lp o--langport:Port del detector d’idioma de Freeling. Per defecte 50005. •-fp o--freelingport:Port del Freeling. Per defecte 60006. 54 •-r o--resppath:Path dels JSON de sortida. Per defecte ../freeling_responses/. L’entrada que rep el client ´es el conjunt de fitxers JSON que s’ha creat en el m`odul anterior. Un cop llegit un fitxer, es processa i s’envia el nom de cada element a l’analitzador de frases. Un cop analitzat, es rep un objecte JSON. Es prepara la informaci´o retornada i s’afegeix en el JSON original per a formar un arxiu nou. Aquests arxius s´on la sortida del programa. 55 9.3.3 Generar frases simples En aquest m`odul s’agafen els noms de cada element i es processen amb SimpleNLG 9.1.3 fent servir la informaci´o recopilada en el bloc anterior. Es tracta de preparar els noms dels elements perqu`e tinguin un aspecte m´es natural, en comptes del format d’acci´o (verb + objecte). Hi ha frases que han de ser dutes a terme per una persona o entitat, en BPMN es defineix com a lane. Sempre que un element en tingui, aquest ser`a afegit com a subjecte de la frase. Figura 9.7: Exemple simple de creaci´o d’una frase amb SimpleNLG. Font: Elaboraci´o pr`opia L’entrada del programa s´on els arxius .json que s’han creat anteriorment. Per defecte, es busquen en la carpeta ../freeling_responses/, per`o aquest path es pot canviar enviant un argument a l’executable amb la ruta desitjada. Aquest m`odul est`a programat en Java, ja que la versi´o de SimpleNLG era m´es fiable i estable en aquest llenguatge. Un cop s’ha processat cada frase d’un model, es modifica el JSON original per a contenir la informaci´o nova. Aquesta ´es un string finalSentence que cont´e la frase final generada. I tamb´e un objecte de JSON finalPhrase, que cont´e els elements necessaris per a poder reconstruir una frase en SimpleNLG. Aix`o ens ser`a ´util en el m`odul seg¨uent per a poder utilitzar les noves frases creades. Aquesta informaci´o es guarda en la ruta ../sentences_generated/. En la figura 9.8 s’hi pot observar un exemple d’un fitxer JSON generat per aquest programa. 56 cicle es perdi l’ordre l`ogic del proc´es. Alguns exemples s´on C.4.0.1.txt,C.7.0.1.txt. Tamb´e s’ha trobat que no es genera una descripci´o satisfact`oria quan el proc´es (o subproc´es) t´e m´es end event que start event. Aix`o ´es un problema derivat de la llibreria jBPT 9.1.4, ja que no genera correctament els arbres RPST 9.1.5 quan tenen m´ultiples end event. Un exemple molt clar ´es aquest C.4.0.1.txt, que tot i ser un BPMN simple no ´es capa¸c de trobar un dels camins que porta a un dels end event. En algunes descripcions es pot observar que manquen molts elements. Aix`o acostuma a passar en els models amb molts elements, per`o no s’ha pogut detectar el perqu`e. Podria ser que, en el moment de llegir els models, algun dels elements no s’hagu´es guardat correctament i, per tant, m´es tard no es pot trobar. Alguns exemples s´on C.5.0.1.txt, FU Berlin.1.txt,FU Berlin.2.txt,Muenster.3.txt,Potsdam.1.txt. En la taula 10.2 s’hi mostra l’an`alisi detallada de les descripcions aconseguides per a cada model. Per a cada model s’han analitzat les seves descripcions tenint en compte els criteris esmentats anteriorment. Cada model pot tenir un o m´es processos, aix`o implica que s’ha generat una descripci´o per a cada proc´es. En els models amb diverses descripcions generades s’ha tingut en compte l’an`alisi m´es restrictiva. ´ Es a dir, es mostra el resultat de la que ha tingut un pitjor resultat. Aquesta decisi´o s’ha basat en el fet que en un model tots els processos s´on necessaris perqu`e s’entengui correctament. 63 Model Real Complexitat N. start event N. end event Cont´e r´ıgids A10 No Senzill 1 1 No A20 No Senzill 1 1 No A21 No Senzill 1 1 No A30 No Senzill 1 2 No A40 No Complex 4 5 No A41 No Complex 4 5 No B10 No Complex 4 5 No B20 No Complex 9 10 S´ı C10 S´ı Complex 2 4 No C11 S´ı Complex 1 2 S´ı C20 S´ı Complex 5 6 S´ı C30 S´ı Complex 1 3 S´ı C40 S´ı Complex 4 4 No C50 S´ı Complex 2 4 No C60 S´ı Complex 3 7 No C70 S´ı Senzill 1 1 No C80 S´ı Senzill 1 1 No Cologne S´ı Complex 2 2 No cook S´ı Senzill 1 1 No Frankfurt S´ı Complex 2 2 No FU Berlin S´ı Complex 2 2 No Hohenheim S´ı Complex 4 4 No IIS Erlangen S´ı Complex 2 2 No model 01 No Senzill 1 1 No Muenster S´ı Complex 4 4 No OrderFullfillement S´ı Senzill 3 7 No payment S´ı Complex 1 2 No Potsdam S´ı Complex 2 2 No TU Munich S´ı Complex 2 2 No Wuerzburg S´ı Complex 2 2 No Taula 10.1: Taula de l’an`alisi dels models. Font: Elaboraci´o pr`opia. 64 Model Segueix ordre Tots els elements S’ent´en Valoraci´o C10 No S´ı No Acceptable C11 No S´ı No Acceptable C20 No S´ı No Acceptable C30 S´ı No S´ı Acceptable C40 No S´ı No Acceptable C50 S´ı No No Acceptable C60 S´ı S´ı S´ı Satisfactori C70 No No No No satisfactori C80 S´ı S´ı S´ı Satisfactori Cologne S´ı S´ı S´ı Satisfactori cook S´ı S´ı S´ı Satisfactori Frankfurt S´ı No No Acceptable FU Berlin S´ı No No Acceptable Hohenheim No No S´ı Acceptable IIS Erlangen S´ı No No Acceptable Muenster S´ı No No Acceptable OrderFullfillement No No No No satisfactori payment S´ı No S´ı Acceptable Potsdam No No No No satisfactori TU Munich S´ı S´ı S´ı Satisfactori Wuerzburg No No No No satisfactori Taula 10.2: Taula de l’an`alisi de les descripcions generades per model. Font: Elaboraci´o pr`opia. 65 11 Treball futur Un cop acabat el projecte, cal pensar quins han de ser els seg¨uents passos a realitzar. Aquest apartat se centra, principalment, en la feina que es volia fer des d’un principi i que no s’ha pogut aconseguir per diversos factors, per`o tamb´e s’hi planteja una idea per seguir la recerca en aquest camp. 11.1 Tractar els r´ıgids Tal com s’ha comentat en l’apartat 9.1.5, els fragments r´ıgids d’un arbre RPST s´on complexos de tractar, ja que en contenir cicles no hi ha una forma f`acil de descriure’ls en text natural. Per aix`o, una de les possibles millores a fer seria dissenyar una estrat`egia per a tractar-los. Artem Polyvyanyy desenvolupa en la seva tesi doctoral [56] un m`etode que reestructura els models amb r´ıgids i els converteix en versions equivalents ben estructurades. Un proc´es est`a ben estructurat, si per a cada node amb m´ultiples arcs de sortida (bifurcaci´o), hi ha un node corresponent amb m´ultiple arcs d’entrada (uni´o) i viceversa, de manera que el fragment del model entre la bifurcaci´o i la uni´o forma un component single-entry-single-exit (SESE) [57]. Si no es compleix aquesta condici´o, es considera que el model ´es desestructurat. Malgrat tot, no tots els models es poden convertir, per tant, pr`eviament cal comprovar que es puguin convertir. La llibreria de Java que es pot fer servir es diu bpstruct [57]. Aquesta eina transforma els processos desestructurats i els estructura correctament. ´ Es una millora que permetria augmentar la quantitat de diagrames BPMN que es poden processar correctament amb aquest programa. Aix`o seria interessant perqu`e, actualment, 66 si es vol fer servir el conjunt de dades per a entrenar un model d’aprenentatge autom`atic, ser`a molt complicat que el model sigui capa¸c de generar correctament els BPMN amb r´ıgids. 11.2 Aconseguir resultats m´es naturals Una altra millora consistiria a implementar estrat`egies perqu`e les descripcions resultants siguin menys automatitzades, m´es variades i semblin m´es reals. Cal tenir en compte que desenvolupar aquest canvi pot millorar la qualitat del model generat amb el dataset resultant. Hi ha diverses formes d’aconseguir-ho, per`o una senzilla d’implementar seria ampliar la quantitat de connectors que es fan servir en l’apartat 9.3.4. A continuaci´o es concreten algunes millores que es poden aplicar. Una possibilitat podria ser afegir un connector al davant d’un end event. Serviria per indicar clarament que el proc´es acaba en aquell punt. Algunes construccions que es podrien afegir s´on Finally,To conclude,And finally,Lastly,The process finishes when. Actualment, no es fa cap control de la llargada d’una frase. Aix`o no es va considerar prioritari durant el projecte perqu`e no hi havia gaires frases amb una extensi´o molt gran. Aix´ı i tot, alguna oraci´o pot ser massa llarga. Per tant, si s’afegeix un control del nombre de paraules per frase, es pot millorar la llegibilitat d’algunes les descripcions. N’´es un exemple la descripci´o C.2.0.4.txt. Tractar els diferents tipus de bifurcacions ´es complicat a causa del fet que n’hi ha de diversos tipus i no totes estan estructurades de la mateixa forma. Hi ha bifurcacions que no tenen nom a les arestes que porten cap als diferents camins. Aix`o comporta que la construcci´o escollida en aquest treball quedi artificial. Es pot veure als models TU Munich.2.txt iIIS Erlangen.2.txt. Una futura modificaci´o podria processar de forma diferent les bifurcacions d’aquest tipus. En aquest mateix sentit, tamb´e es podria diferenciar la forma en qu`e es tracten les inclusive gateway de les exclusive gateways. Es podria afegir uns connectors que deixin clar el tipus de bifurcaci´o. Hi ha models que despr´es d’una bifurcaci´o els camins es tornen a unir. Quan els camins s´on senzills i curts no es fa dif´ıcil entendre que els camins s’han tornat a unir, per`o quan s´on m´es llargs es pot fer complicat seguir el flux del proc´es. Es podria incorporar un connector que indiqui quins camins s’estan unint i en quin moment. Per acabar, tamb´e es podria millorar el pretractament de les frases abans d’enviar-les al Freeling. Com s’ha comentat en l’apartat 9.3.2, hi ha vegades que una frase no es detectada correctament pel Freeling i aquest no retorna res o retorna una an`alisi 67 err`onia. Aix`o implica que la informaci´o no es pot processar d’una forma `optima. Si s’aconsegueix fer un bon pretractament per la majoria de casos, es milloraria la qualitat de les descripcions. Un exemple de mala detecci´o en el Freeling ´es el model cook.1.txt, on s’observa la frase Once the noticed is hungered, per`o hauria de mostrar Once the hunger is noticed. 11.3 Crear model Deep Learning Finalment, per a continuar investigant en el camp dels models BPMN, es proposa crear un model Deep Learning que rebi una descripci´o en llenguatge natural d’un BPMN i el transformi en el diagrama corresponent. Aquest model s’entrenaria amb les dades que s’han generat en aquest treball. Inicialment, es va considerar fer una petita prova del conjunt de dades amb un model senzill, per`o per manca de temps no s’ha pogut dur a terme. Realitzar aquesta prova seria important per a validar el dataset, o b´e, saber si cal fer-hi modificacions. Aconseguir tenir un model fiable que converteixi de text a diagrama, seria molt positiu per a tota persona que treballi dissenyant diagrames BPMN. Li estalviaria temps i esfor¸cos en dibuixar el diagrama i, per tant, podria dedicar-se, plenament, a descriure el proc´es. 68 12 Conclusions Un cop acabat el projecte, ´es important fer una an`alisi de com ha anat el treball i extreure’n conclusions i fer una autocr´ıtica que ha de servir per millorar en treballs futurs. En aquest apartat s’avaluen q¨uestions, a escala personal, com la gesti´o del temps, els coneixements adquirits. Tamb´e es fa un breu resum de les principals contribucions d’aquest treball. 12.1 Gesti´o del temps Primer de tot, cal remarcar que la gesti´o del temps en aquest treball no ha sigut prou bo. En la planificaci´o inicial 6 es va fallar a l’hora de calcular les hores disponibles per a desenvolupar el treball. No es va tenir prou en compte que treballar a temps complet, estudiar una assignatura de la universitat i fer el treball eren incompatibles. Mentre va existir la c`arrega de l’assignatura no es va avan¸car pr`acticament res amb el projecte. M´es tard, el projecte es va poder dur a terme de forma continuada, per`o seguir amb la feina ha implicat no poder-hi dedicar moltes hores setmanalment. Tot aix`o ha comportat diversos endarreriments en la data d’entrega. De cara al futur, aquesta gesti´o del temps cal millorar-la per a evitar aquests retards en nous projectes. 12.2 Metodologia El fet de treballar en una empresa durant el treball tamb´e ha aportat coses bones. Inicialment, el coneixement de metodologies de treball era gaireb´e esc`as. En la secci´o de metodologia 5 s’explica com s’escull Kanban. Aquesta ´es totalment v`alida per aquest projecte, per`o com que no es tenia prou coneixement sobre eines de gesti´o de projectes, 69 ´es possible que no s’hagi aprofitat tot el seu potencial. En la feina es treballava amb Scrum (molt similar a la que fem servir, per`o m´es r´ıgida) i aix`o ha perm`es descobrir noves eines, com Azure DevOps, que estan especialitzades en Agile. Aquests instruments permeten controlar i categoritzar millor la feina a realitzar. I, per tant, saber f`acilment quines tasques cal prioritzar. 12.3 Coneixements adquirits El projecte ha servit per millorar molt a t´ıtol personal. Durant el desenvolupament s’han apr`es nocions de gesti´o de projectes, com decidir qu`e s’ha d’implementar i qu`e no, prioritzar la feina, comunicar-se amb els directors del projecte i corregir la feina a partir del seu feedback. Tamb´e s’ha millorat la capacitat d’organitzar un projecte de software i tamb´e de programar en Java. Al principi, tractar amb aquest llenguatge va ser complicat perqu`e es tenia un nivell b`asic. Per`o, a poc a poc s’ha apr`es a fer-lo anar millor. A m´es a m´es, el descobriment i aprenentatge de les llibreries Camunda,Freeling,SimpleNLG ijBPT ha sigut molt positiu. Ja que, ´es possible que algun dia es dugui a terme algun projecte personal amb alguna d’aquestes eines. I finalment, s’han adquirit molts coneixements sobre els models BPMN. Quan es va comen¸car el treball no es coneixia l’exist`encia d’aquests. Gr`acies al treball s’ha fet una recerca que ha portat a aprendre qu`e s´on, per a qu`e es fan servir i com fer-los servir en projectes software. 12.4 Aportacions d’aquest treball En aquest treball de fi de grau s’ha aconseguit crear un programa que, donada una entrada de diversos models BPMN, generi una descripci´o en llenguatge natural per a cada un dels models. El programa llegeix (parseja) els models, analitza morfosint`acticament les frases dels elements, genera unes frases simples fent servir l’an`alisi morfosint`actica i finalment, genera la descripci´o unint les frases i afegint connectors entre elles perqu`e quedi m´es natural. Tamb´e s’ha creat un dataset, format per parells de models BPMN i les seves descripcions en llenguatge natural. Aquest conjunt de dades es podria fer servir per a entrenar un model de Deep Learning. Per a desenvolupar el programa s’han estudiat i emprat diverses eines que han ajudat a obtenir un millor resultat. Per llegir els models s’ha fet servir Camunda, per fer l’an`alisi 70 morfosint`actica s’ha fet anar Freeling, per crear i combinar frases simples s’ha fet servir SimpleNLG i per a generar i rec´orrer arbres RPST s’ha utilitzat jBPT. Despr´es d’haver utilitzat aquestes eines, es pot concloure que la inclusi´o d’eines de NLP i NLG, com s´on Freeling iSimpleNLG, ha perm`es obtenir un resultat m´es real en la generaci´o de descripcions en llenguatge natural a partir de models BPMN. Aix`o demostra el potencial que tenen aquestes llibreries quan s’utilitzen juntes en la generaci´o de qualsevol text en llenguatge natural. Com s’ha comentat en l’apartat d’An`alisis del Dataset 10 durant el desenvolupament d’aquest projecte s’han trobat complicacions que no han perm`es obtenir uns resultats `optims. La documentaci´o d’aquests problemes pot guiar a futurs estudis a millorar i a resoldre aquestes dificultats m´es f`acilment. I per acabar, el programa s’ha dissenyat de forma modular. De tal manera que cada secci´o realitza una funci´o independentment de les altres. Per tant, resulta senzill aprofitar i reutilitzar algun dels m`oduls sense necessitat de fer-los servir tot. A m´es a m´es, tal com s’explica en l’ap`endix B, el codi est`a publicat de forma open source. Per tant, qualsevol que ho consideri pot consultar-lo o modificar-lo. 71 13 Agra¨ıments Vull comen¸car aquesta secci´o agraint a la FIB i a la UPC la gran formaci´o acad`emica que m’han donat durant el grau. La preparaci´o donada m’ha perm`es tenir una gran base per aprendre i millorar f`acilment en la majoria de llenguatges i eines de programaci´o. Tamb´e vull donar gr`acies al Josep i al Llu´ıs per la feina que han fet com a directors del treball. M’han ensenyat eines molt ´utils, m’han introdu¨ıt a l’`ambit del modelatge de processos empresarials i m’han donat grans consells per a millorar el meu projecte. Finalment, tamb´e vull agrair a la meua fam´ılia, a la Maria i a l’Ares el fet d’haver-me aconsellat i d’haver estat al meu costat durant el desenvolupament del treball, ja que aix`o m’ha servit per continuar endavant i poder arribar fins aqu´ı. 72 C10 C.1.0.png Figura A.1 ii C.1.0.1.txt C.1.0.1.txt Once the received is invoiced, the invoice is scanned, the original is archived, approver to be assigned then is assigned. If the answer is null then invoice review needed then review and document result. If the answer is null then 7 days. C.1.0.2.txt C.1.0.2.txt Once team assistant invoices the received, team assistant assigns, approver approves the invoice then the condition does invoice the approved is checked, accountant prepares the bank transfer, accountant archives the invoice then accountant invoices the processed, the condition does review the successful is checked then invoice not processed, rechnung kl¨aren then the condition does review the successful is checked, the condition does invoice the approved is checked then approver approves the invoice. iii C11 C.1.1.png Figura A.2 iv C.1.1.1.txt C.1.1.1.txt Once the received is invoiced, is assigned, the invoice is approved then the condition does invoice the approved is checked, the bank transfer is prepared, the invoice is archived then the processed is invoiced, the condition does review the successful is checked then invoice not processed, the invoice is approved, the condition does invoice the approved is checked then rechnung kl¨aren then the condition does review the successful is checked. v C20 C.2.0.png Figura A.3 vi C.2.0.1.txt C.2.0.1.txt Once the credit card information is received, the payment is taken then the result is sent. C.2.0.2.txt C.2.0.2.txt Once the items are picked, the truck is loaded then the items are delivered. C.2.0.3.txt C.2.0.3.txt Once the products are browsed on amazon, the item is added to cart then the condition done shopping is checked then the products are browsed on amazon, checkout then the items are received. C.2.0.4.txt C.2.0.4.txt Once the order is payed then the condition does retry is checked then the order is payed, the condition payment accepted is checked then the order is sent, the condition payment accepted is checked then the condition does retry is checked. vii C.2.0.5.txt C.2.0.5.txt Once picker receives the order, picker picks the items, picker places in bin, receive and package items then packager sends to carrier dock. viii C30 C.3.0.png Figura A.4 ix C.3.0.1.txt C.3.0.1.txt Once the customer request is received, the customer request is analysed then the condition service type is checked. The condition the level is serviced is checked. If the answer is premium then the repair is performed then the completed is repaired. If the answer is standard then the repair is performed then the completed is repaired. x C40 C.4.0.1.png Figura A.5 xi C.5.0.2.png Figura A.10 xviii C.5.0.1.txt C.5.0.1.txt Once customer interested in bank offer, private customer account manager interviews the customer, prove/provide identity, the condition legal entity or individual is checked then corporate account manager documents the identity of the economic owner then the condition identity of the economic owner certifiable is checked. C.5.0.2.txt C.5.0.2.txt Once is checked for connected clients, check if group of connected clients exists, the condition does group of connected clients existing is checked then document group of connected clients according to capital requirements regulation crr. xix C60 C.6.0.png Figura A.11 xx C.6.0.1.txt C.6.0.1.txt Once the travel request is received then the flights and hotel offer is made. If the answer is null then the approved is offered, the credit card information is requested, booking is made, the credit card is charged, booking is confirmed then booking confirmed. If the answer is null then 24 hours, the customer offer expired is notified then the expired is offered. If the answer is null then the request is canceled, the customer record is updated then the cancelled is requested. C.6.0.2.txt C.6.0.2.txt Once if the answer is null then the hotel is bookedif the answer is null then the flight is booked then the booked is traveled. C.6.0.3.txt C.6.0.3.txt Once booking. If the answer is null then hotel. If the answer is null then flight. xxi C70 C.7.0.png Figura A.12 xxii C.7.0.1.txt C.7.0.1.txt Once hiring manager jobs the vacancy, hiring manager writes the description, recruitment completes the advertisement then hiring manager approves the advertisement then the condition advertisement approved is checked then recruitment completes the advertisement. If the answer is null then recruitment publishes on homepage. If the answer is null then recruitment selects the other platforms then recruitment publishes on other platforms then vacancy advertised. xxiii C80 C.8.0.png Figura A.13 xxiv C.8.0.1.txt C.8.0.1.txt Once vacation request received, the vacation information is fetched then the approval is vacationed. If the answer is manual validation required then manually approve vacation if the answer is approved then the employee of approval is notified, remaining vacation is updated then the approved is vacationed by manager if the answer is refused then the employee of refusal is notified then vacation refused by manager. If the answer is refused then the employee of refusal is notified then the refused is vacationed. If the answer is approved then the employee of approval is notified, remaining vacation is updated then the approved is vacationed. xxv Cologne Cologne.png Figura A.14 xxvi Cologne.1.txt Cologne.1.txt Once the online is applied, the online protoc¨al is sent then the documents are sent by post. If the answer is null then is payed for aptitude test. If the answer is null then the aptitude test is taken then is waited for results. If the answer is null then accepted. If the answer is null then rejected. Cologne.2.txt Cologne.2.txt Once documents received, the documents are checked then is evaluated. If the answer is null then is kept in the applicant pool. If the answer is null then is invited to an aptitude test then rank students according to gpa and the test results. If the answer is null then the letter of acceptance is sent. If the answer is null then the letter of rejection is sent. xxvii Hohenheim Hohenheim.png Figura A.18 xxxiv Hohenheim.1.txt Hohenheim.1.txt Once applicant chooses the master program, complete and send application form online then applicant receives the application number and passwort. If the answer is null then applicant prints the online application form. If the answer is null then applicant prints the online application form, applicant sends the all the requirements to the secretarial office for students, waiting for the response then rejection, enrollment then enrollment. Hohenheim.2.txt Hohenheim.2.txt Once the application is received. If the answer is null then rank application on scale from 1 to 10. If the answer is null then assessment of application. If the answer is null then proof of uni degree provided then proposed as reserved. If the answer is null then high ranking requirements are met then proposed as accepted. If the answer is null then requirements are not met or low ranking then proposed as rejected then final confirmation by head of the university. Hohenheim.3.txt Hohenheim.3.txt Once receiving the written applications then checking if complete. If the answer is null then is marked as complete then the documents are sent to selection committee. If the answer is null then mark as not complete then rejection. If the answer is null then the applicant status is updated. If the answer is null then publishing the letters. Hohenheim.4.txt Hohenheim.4.txt xxxv Once the online applications are documented then the an application number and password is allocated to each applicant. xxxvi IIS Erlangen IIS Erlangen.png Figura A.19 xxxvii IIS Erlangen.1.txt IIS Erlangen.1.txt Once enrollment administrations receives the application. If the answer is null then enrollment administrations checks the application in time. If the answer is null then enrollment administrations checks the application complete then the condition complete and in time is checked. Hand application over to examining board then examining board receives the application. If the answer is null then examining board scores the motivation. If the answer is null then examining board scores the qualifications. If the answer is null then score bachelors grade then examining board sums the scores. IIS Erlangen.2.txt IIS Erlangen.2.txt Once the application is completed. If the answer is null then the certificate of english language is added. If the answer is null then the certificate of bachelor degree is added. If the answer is null then the application form is filled. If the answer is null then create and add english letter of motivation. If the answer is null then create and add cv. If the answer is null then the condition german is checked then the certificate of german language is added, the certificates of further language skills are added then the certificates of further language skills are added then the certificates of qualification are added then the certificates of qualification are added, compare and send application then the interview is taken. xxxviii Muenster Muenster.png Figura A.20 xxxix Muenster.1.txt Muenster.1.txt Once applicant chooses the courses of studies then applicant completes the online interview. If the answer is null then applicant receives the rejection for course of studies. If the answer is null then applicant receives the application form, upload bachelor’s degree / transcript of records / diploma supplement, applicant uploads the cv, applicant uploads the course description, applicant uploads the language certificate then applicant uploads the language certificate, applicant uploads the university entrance certificate then applicant uploads the letter of motivation, print out and sign application form, applicant collects the additional required documents then applicant sends the application form and documents. Muenster.2.txt Muenster.2.txt Once the application is received. If the answer is null then check and evaluate application. If the answer is null then the transcript of applicant is created then ranking is created. If the answer is null then the applicant is marked as suitable. If the answer is null then the applicant for interview is invited, the interview is done then the qualification is discussed. If the answer is null then mark applicant as not suitable then the information is sent to application office. Muenster.3.txt Muenster.3.txt Once receive and sort application then the citizenship is checked. If the answer is null then the application is checked in time eu countries. If the answer is null then the application is checked in time non-eu countries, the condition in time is checked, the application complete is checked then the application system is updated. If the answer is null then the rejection is sent. If the answer is null then the acceptance is sent. xl Muenster.4.txt Muenster.4.txt Once the responses are checked then the condition does meet the basic requirements is checked. If the answer is yes then the application form is sent. If the answer is no then the interview is rejected then the status of application is updated. xli OrderFullfillement Order Fulfillment and Procurement.jpg Figura A.21 xlii Procurement.jpg Figura A.22 xliii TU Munich TU Munich.png Figura A.26 l TU Munich.1.txt TU Munich.1.txt Once documents received then admission office checks the bachelor ’s degree. Admission office checks the documents, forward documents then department of informatics evaluates. If the answer is null then department of informatics sends the letter of rejection. If the answer is null then department of informatics sends the letter of acceptance. If the answer is null then department of informatics sends the interview invitation then department of informatics conducts the interview. If the answer is null then department of informatics sends the letter of acceptance. If the answer is null then department of informatics sends the letter of rejection. TU Munich.2.txt TU Munich.2.txt Once the online is applied, the documents are sent by post then is waited for results. If the answer is null then accepted. If the answer is null then rejected. If the answer is null then invited to an interview then is gone to the interview if the answer is null then accepted if the answer is null then rejected. li Wuerzburg Wuerzburg.png Figura A.27 lii Wuerzburg.1.txt Wuerzburg.1.txt Once precheck of documents, checking for completeness then the condition does complete is checked then checking for completeness then the condition does complete is checked. Wuerzburg.2.txt Wuerzburg.2.txt Once the uni is chosen. If the answer is null then is filled in online form of application then the german application is sent. If the answer is null then is filled in printed form of application for international students then the international application is sent then waiting for response. If the answer is null then the commitment is received then is matriculated. If the answer is null then the rejection is received. liii Ap`endix B Codi Tot el codi desenvolupat en aquest projecte, els models utilitzats i les descripcions generades es poden trobar al seg¨uent repositori de Github https://github.com/guillempla/TFG. El codi est`a publicat sota la llic`encia GNU General Public License v3.0. liv