Xeración automática de prognósticos meteorolóxicos a curto prazo con técnicas avanzadas de xeración de linguaxe natural

ESCOLA T´ ECNICA SUPERIOR DE ENXE ˜ NAR´ IA jGALiWeather Xeraci´on autom´atica de progn´osticos meteorol´oxicos a curto prazo con t´ecnicas avanzadas de xeraci´on de linguaxe natural. Autor: Diego Iglesias Freire Directores: Alberto Bugar´ın Diz Alejandro Ramos Soto Grao en Enxe˜nar´ıa Inform´atica Julio 2016 Traballo de Fin de Grao presentado na Escola T´ecnica Superior de Enxe˜nar´ıa da Universidade de Santiago de Compostela para a obtenci´on do Grao en Enxe˜nar´ıa Inform´atica D. Alberto Bugar´ın Diz, Catedr´atico da Universidade de Santiago de Compostela, e D. Alejandro Ramos Soto, Investigador do Centro Singular de Investigaci´on en Tecnolox´ıas da Informaci´on(CiTIUS) da Universidade de Santiago de Compostela, INFORMAN: Que a presente memoria, titulada jGALiWeather: Xeraci´on autom´atica de progn´osticos meteorol´oxicos a curto prazo con t´ecnicas avanzadas de xeraci´on de linguaxe natural., presentada por D. Diego Iglesias Freire para superar os cr´editos correspondentes ao Traballo de Fin de Grao da titulaci´on de Grao en Enxe˜nar´ıa Inform´atica, realizouse baixo a nosa direcci´on no Centro Singular de Investigaci´on en Tecnolox´ıas da Informaci´on(CiTIUS) da Universidade de Santiago de Compostela. E para que as´ı conste aos efectos oportunos, expiden o presente informe en Santiago de Compostela, a 7 de xullo de 2016: O director, O codirector, O alumno, Alberto Bugar´ın Diz Alejandro Ramos Soto Diego Iglesias Freire i ii Agradecementos A Andrea, por estar a´ı todos estes anos, polo seu apoio continuo e, sobre todo, pola s´ua paciencia. ´ A mi˜na familia, por seguir estando a´ı a pesar dos meus cambios de humor. A Alberto e Alejandro, por ser os mellores titores que un alumno poidera desexar e por estar sempre a mi˜na disposici´on. Aos meus compa˜neiros de carreira, que converteron estes 5 anos nunha experiencia fabulosa. Aos meus amigos, por perdoar as mi˜nas continuas ausencias. iii iv ´ Indice xeral 1. Introduci´on 1 1.1. Obxectivos............................... 3 1.2. Organizaci´on do documento . . . . . . . . . . . . . . . . . . . . . 3 2. Xesti´on do proxecto 5 2.1. Xesti´on do alcance . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Descrici´on do alcance do proxecto . . . . . . . . . . . . . . 5 2.1.2. Obxectivos........................... 6 2.1.3. Criterios de aceptaci´on . . . . . . . . . . . . . . . . . . . . 6 2.1.4. Restrici´ons do proxecto . . . . . . . . . . . . . . . . . . . . 7 2.1.5. Entregables do proxecto . . . . . . . . . . . . . . . . . . . 7 2.2. Metodolox´ıa de desenvolvemento . . . . . . . . . . . . . . . . . . 7 2.2.1. Metodolox´ıa ´axil - Scrum . . . . . . . . . . . . . . . . . . . 8 2.2.2. Aplicaci´on de Scrum no proxecto . . . . . . . . . . . . . . 9 2.3. Xesti´on da configuraci´on . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1. Xesti´on do c´odigo fonte . . . . . . . . . . . . . . . . . . . . 9 2.3.2. Xesti´on da documentaci´on . . . . . . . . . . . . . . . . . . 10 2.4. Xesti´ondotempo........................... 11 2.5. Xesti´onderiscos ........................... 19 2.6. Estimaci´on de custos . . . . . . . . . . . . . . . . . . . . . . . . . 22 3. Especificaci´on de requisitos 25 3.1. Historias de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.1.1. Historias de Usuario: Cliente . . . . . . . . . . . . . . . . . 27 3.1.2. Historias de Usuario: Desenvolvedor de software . . . . . . 31 4. Arquitectura e Ferramentas 37 4.1. Arquitectura do sistema . . . . . . . . . . . . . . . . . . . . . . . 37 4.2. Patr´ons de dese˜no . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.3. Ferramentas.............................. 40 4.3.1. Librar´ıas............................ 40 4.3.2. Outras Ferramentas . . . . . . . . . . . . . . . . . . . . . . 43 v 5. Dese˜no e Implementaci´on 45 5.1. jGALiWeather............................. 45 5.1.1. Diagramas de Fluxo de Datos . . . . . . . . . . . . . . . . 46 5.1.2. Implementaci´on da aplicaci´on . . . . . . . . . . . . . . . . 53 5.1.3. Descrici´on do funcionamiento da aplicaci´on . . . . . . . . . 58 5.2. InterfaceWeb............................. 60 5.2.1. Controlador RESTFul . . . . . . . . . . . . . . . . . . . . 61 5.2.2. Xeolocalizaci´on . . . . . . . . . . . . . . . . . . . . . . . . 62 5.2.3. Interface Responsive . . . . . . . . . . . . . . . . . . . . . 63 5.3. Proveedordedatos .......................... 67 6. Probas 69 6.1. Verificaci´on .............................. 70 6.2. Validaci´on............................... 79 7. Conclusi´ons 83 7.1. Posiblesmelloras ........................... 84 7.1.1. Soporte para outros idiomas . . . . . . . . . . . . . . . . . 84 7.1.2. Adaptaci´on da aplicaci´on coma servizo web . . . . . . . . 84 7.1.3. Predici´ons especializadas . . . . . . . . . . . . . . . . . . . 84 A. Manuais de usuario 85 A.1.Requisitosprevios........................... 85 A.2.Instalaci´on............................... 85 A.3.Configuraci´on............................. 86 A.4.Execuci´on ............................... 87 Bibliograf´ıa 89 vi ´ Indice de figuras 1.1. GALiWeather en uso na web de MeteoGalicia). . . . . . . . . . . 2 2.1. Estructura de carpetas. . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2. Estrutura de descomposici´on do traballo (EDT). . . . . . . . . . . 12 2.3. Cronograma da planificaci´on (Gantt). . . . . . . . . . . . . . . . . 15 2.4. Gr´afico Burn-Down do Sprint 1. . . . . . . . . . . . . . . . . . . . 16 2.5. Gr´afico Burn-Down do Sprint 2. . . . . . . . . . . . . . . . . . . . 17 2.6. Gr´afico Burn-Down do Sprint 3. . . . . . . . . . . . . . . . . . . . 17 2.7. Gr´afico Burn-Down do Sprint 4. . . . . . . . . . . . . . . . . . . . 18 2.8. Gr´afico Burn-Down do Sprint 5. . . . . . . . . . . . . . . . . . . . 18 4.1. Arquitectura do sistema. . . . . . . . . . . . . . . . . . . . . . . . 37 4.2. Arquitectura da aplicaci´on xeradora de progn´osticos. . . . . . . . 38 4.3. Patr´onMVC. ............................. 40 4.4. Funci´ons de pertenza do conxunto borroso .alto”. . . . . . . . . . 41 4.5. Funci´on de pertenza trapezoidal. . . . . . . . . . . . . . . . . . . 42 5.1. Fluxo de de tarefas da aplicaci´on. . . . . . . . . . . . . . . . . . . 46 5.2. Diagrama de Contexto. . . . . . . . . . . . . . . . . . . . . . . . . 47 5.3. DFDdenivel1............................. 47 5.4. DFD de nivel 2 - Establecer configuraci´on. . . . . . . . . . . . . . 48 5.5. DFD de nivel 2 - Ler datos meteorol´oxicos . . . . . . . . . . . . . 50 5.6. DFD de nivel 2 - Xerar progn´osticos meteorol´oxicos en linguaxe natural................................. 51 5.7. DFD de nivel 2 - Gardar progn´osticos . . . . . . . . . . . . . . . . 52 5.8. Estrutura de ficheiros do paquete algorithm. ........... 55 5.9. Estrutura de ficheiros do paquete database............. 55 5.10. Estrutura de ficheiros do paquete data................ 56 5.11. Estrutura de ficheiros do paquete configuration. ......... 57 5.12. Estrutura de ficheiros do paquete nlg. ............... 58 5.13. Plataforma web en funcionamento. . . . . . . . . . . . . . . . . . 61 5.14. Prototipo da aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . 63 5.15. Interface responsive da aplicaci´on. . . . . . . . . . . . . . . . . . . 65 5.16. Interface responsive para Tablets. .................. 66 vii 4CAP´ ITULO 1. INTRODUCI ´ ON  Cap´ıtulo 2: Xesti´on do proxecto. Neste cap´ıtulo descr´ıbense as xestiones do alcance, da configuraci´on, do tempo e de riscos seguidas durante este proxecto. Ademais indicase e explicase a metodolox´ıa seguida e faise unha hipot´etica estimaci´on de custos.  Cap´ıtulo 3: Especificaci´on de requisitos. Neste cap´ıtulo faise un an´alise dos diferentes requisitos identificados, utilizando historias de usuario para representalos.  Cap´ıtulo 4: Arquitectura e ferramentas. Neste cap´ıtulo mostrase a arquitectura do sistema a alto nivel. Por outra parte descr´ıbense as diferentes ferramentas e tecnolox´ıas utilizadas ao longo do proxecto.  Cap´ıtulo 5: Dese˜no e Implementaci´on. Neste cap´ıtulo explicase o dese˜no a baixo nivel das diferentes aplicaci´ons integradas no sistema, as´ı como detallarase o seu funcionamento e como se implementaron.  Cap´ıtulo 6: Probas. Neste cap´ıtulo se detallan as diferentes probas feitas para validar e verificar a aplicaci´on.  Cap´ıtulo 7: Conclusi´on. Neste cap´ıtulo establ´ecense as diferentes conclusi´ons derivadas da realizaci´on do proxecto e ind´ıcanse as posibles modificaci´ons ou ampliaci´ons a facer nun futuro.  Ap´endice A: Manual de usuario. Neste ap´endice se describen tanto os pasos para instalar a aplicaci´on como para manexar a mesma.  Bibliograf´ıa: Referencias ao material utilizado para a realizaci´on desta memoria. Cap´ıtulo 2 Xesti´on do proxecto A xesti´on de proxectos software ´e unha parte esencial da enxe˜nar´ıa de software levada a cabo ao longo de todo o proxecto, que busca lograr que o produto final se axuste aos obxectivos, necesidades e restrici´ons impostas. Unha boa xesti´on non asegura o ´exito dun proxecto pero unha mala xesti´on asegura o fracaso do mesmo. Neste cap´ıtulo se explican de forma detallada a xesti´on do alcance, da configuraci´on, dos tempos e dos riscos do proxecto, as´ı coma a metodolox´ıa de traballo escollida neste caso. Adicionalmente incl´uese unha an´alise dos posibles custos deste proxecto. 2.1. Xesti´on do alcance A xesti´on do alcance incl´ue t´odolos procesos necesarios que permiten asegurar que o proxecto incl´ue todo o traballo requirido, e s´o o traballo requirido, para completar o proxecto satisfactoriamente. Normalmente relaci´onase principalmente coa definici´on e o control das tarefas a considerar ou omitir no proxecto [7]. 2.1.1. Descrici´on do alcance do proxecto jGALiWeather estar´a dividida en dous servizos: un servizo de xeraci´on de predici´ons meteorol´oxicas textuais a curto prazo e un servizo de xeraci´on de predici´ons textuais para a calidade do aire a curto prazo. Para xerar esta predici´ons utilizar´a as seguintes variables meteorol´oxicas de interese a curto prazo a catro d´ıas vista:  Estado do ceo: Datos sobre cobertura nubosa e precipitaci´ons para a ma˜n´a, a tarde e a noite. Estes datos pres´entanse como c´odigos num´ericos asociados a un determinado estado do ceo (21 distintos en total). 5 6CAP´ ITULO 2. XESTI ´ ON DO PROXECTO  Vento: Similar ao anterior, util´ızanse c´odigos num´ericos (34 en total) para representar a direcci´on e a intensidade do vento nos tres momentos do d´ıa.  Temperatura (m´axima e m´ınima): Proporcionase a temperatura m´axima e m´ınima esperada para cada d´ıa en grados Celsius.  Calidade do aire: Proporciona un c´odigo num´erico para o nivel de calidade do aire de forma que pode ser bo, admisible, malo ou moi malo. Esta variable, a diferencia das demais, proporcionase s´o a tres d´ıas vista. Os diferentes m´odulos da aplicaci´on ser´an independentes entre eles e as predici´ons textuais ter´an que estar escritas en ingl´es. Ademais deberase desenvolver unha interface web que mostre os datos anteriores xunto coas predici´ons en linguaxe textual para os 314 municipios galegos. 2.1.2. Obxectivos O obxectivo xeral de jGALiWeather ´e o dese˜no, implementaci´on e proba dunha nova aplicaci´on na que se van aplicar t´ecnicas de xeraci´on de linguaxe natural m´ais sofisticadas cas orixinalmente utilizadas en GALiWeather, coa utilizaci´on de recursos de Xeraci´on de Linguaxe natural (NLG) coma a librar´ıa Java SimpleNLG [6]. Este obxectivo xeral pode dividirse nos seguintes obxectivos espec´ıficos:  Dese˜nar unha nova aplicaci´on (jGaliWeather) na linguaxe de programaci´on Java a partir da aplicaci´on GALiWeather.  Producir un novo m´odulo de xeraci´on de predici´ons meteorol´oxicas textuais en ingl´es utilizando a librar´ıa Simple NLG.  Integrar os diferentes m´odulos de xeraci´on de linguaxe natural en jGALiWeather.  Crear unha interface gr´afica para visualizar a informaci´on xerada por jGALiWeather. 2.1.3. Criterios de aceptaci´on O proxecto ser´a aceptado se a aplicaci´on jGALiWeather ´e capaz de realizar previsi´ons meteorol´oxicas en ingl´es de forma precisa e se proporciona unha interface web para a visualizaci´on dos diferentes datos meteorol´oxicos. 2.2. METODOLOX´ IA DE DESENVOLVEMENTO 7 2.1.4. Restrici´ons do proxecto  O proxecto debe de constar, como m´ınimo, de 412,5 horas de traballo.  O proxecto debe ser entregado antes de 08/07/16. 2.1.5. Entregables do proxecto Os produtos a entregar ao finalizar o proxecto son:  C´odigo fonte do software desenvolvido.  Executables.  Manual de instalaci´on.  Memoria do proxecto.  Base de datos cos datos meteorol´oxicos. 2.2. Metodolox´ıa de desenvolvemento Nun proxecto de desenvolvemento de software ´e crucial a correcta elecci´on da metodolox´ıa a utilizar. De non ser as´ı, o proxecto pode sufrir retrasos, sobrecustos ou incluso pode fracasar na s´ua totalidade. Por esta raz´on ´e necesario analizar t´odalas caracter´ısticas, necesidades e limitaci´ons do proxecto ´a hora de determinar a metodolox´ıa a utilizar. Podemos diferenciar dous grandes grupos de metodolox´ıas: as metodolox´ıas tradicionais e as metodolox´ıas ´axiles. O primeiro grupo caracter´ızase por levar a cabo unha documentaci´on exhaustiva de todo o proxecto e por centrarse en cumprir un plan de proxecto definido ao inicio do mesmo. Isto implica uns altos custos ´a hora de realizar un cambio e unha falta de flexibilidade notable. As chamadas metodolox´ıas ´axiles bas´eanse na adaptabilidade dos diferentes procesos do proxecto solucionando os problemas comentados anteriormente das metodolox´ıas tradicionais [9]. Debido a que o equipo de desenvolvemento deste proxecto est´a formado por unha soa persoa que carece da experiencia necesaria para realizar unha planificaci´on inicial correcta, ´optase pola utilizaci´on dunha metodolox´ıa ´axil. Ademais disto, existen outras raz´ons para esta decisi´on, tales coma que o proceso est´a menos controlado ou se utilizan menos roles (ao tratarse dun equipo unipersoal non ´e necesario un control exhaustivo ou moitos roles). 8CAP´ ITULO 2. XESTI ´ ON DO PROXECTO 2.2.1. Metodolox´ıa ´axil - Scrum Scrum ´e un proceso ´axil que se pode usar para xestionar e controlar desenvolvementos complexos de software e produtos utilizando pr´acticas iterativas e incrementais [9]. En 1986, Ikujiro Nonaka e Hirotaka Takeuchi identificaron e definiron un enfoque integral que incrementaba a velocidade e flexibilidade do desenvolvemento de produtos comerciais. Compararon este novo enfoque de traballo en grupo ao avance en formaci´on de scrum dos xogadores de rugby. A´ında que existiron varias referencias por persoas de importancia dentro do sector a o uso do enfoque de Nonaka e Takeuchi no desenvolvemento de software ao longo dos anos, non foi ata 1995 cando Jeff Sutherland e Ken Schwaber presentaron un art´ıculo de forma conxunta dando forma ao Scrum que co˜necemos hoxe en dia. Scrum non ´e unha metodolox´ıa, ´e un marco de traballo. Isto quere dicir que Scrum non define exactamente o que debe facerse sen´on que proporciona unha serie de boas pr´acticas a levar a cabo para asegurar o ´exito de proxecto [10]. Scrum conf´ıa en que un equipo debe estar auto-xestionado e ser multi-disciplinar. Este equipo apoiase en dous roles espec´ıficos: o Scrum Master e o Product Owner. O primeiro pode entenderse coma un adestrador para o equipo, que axuda aos membros do equipo a usar Scrum para obter o m´aximo rendemento. O Product Owner representa aos clientes ou os usuarios e gu´ıa ao equipo a constru´ır o produto correcto. Durante cada iteraci´on ou sprint, o equipo crea un novo incremento do software. Ao principio de cada sprint cel´ebrase unha reuni´on entre o equipo e o Product Owner na que se deciden as caracter´ısticas que se van implementar nese sprint. Esas caracter´ısticas prove˜nen da pila do produto que cont´en t´odolos requisitos priorizados que deben de ser implementados. A pila do produto pode modificarse nas reuni´ons de inicio de cada sprint pero durante o mesmo debe manterse inalterada. Os items esc´ollense mediante consenso entre o Product Owner, que determina o alcance e a prioridade dos mesmos, e o equipo, que estima a cantidade de traballo ´a que pode comprometerse. O resultado de cada sprint debe ser unha nova versi´on operativa do software. Este proceso xunto cunha duraci´on de sprint relativamente curta (normalmente de 2 a 4 semanas) fan que a probabilidade de ´exito sexa moi alta. Isto ´e debido a 2.3. XESTI ´ ON DA CONFIGURACI ´ ON 9 que existen versi´ons operativas do software durante todo o proxecto, facendo posible que o Product Owner logre entender mellor as s´uas necesidades, permitindo facer os cambios pertinentes. Scrum reco˜nece que ´e moi posible que os clientes poidan cambiar os seus pensamentos sobre o que queren e o que necesitan durante o proxecto. Por esa raz´on, centrase en maximizar as habilidades do equipo para facer entregas r´apidas e responder aos cambios emerxentes. 2.2.2. Aplicaci´on de Scrum no proxecto Como Scrum est´a moi orientado a maximizar o rendemento do equipo de traballo, ´e moi dif´ıcil aplicar moitas das s´uas practicas debido a que neste proxecto dispo˜nemos dun equipo unipersoal. Sen embargo, si se utilizaran t´ecnicas coma a organizaci´on do traballo en sprints, as reuni´ons ou o uso de gr´aficos Burn-Down. Neste proxecto tivemos sprints de 3 semanas de duraci´on e ao principio de cada un fixose unha reuni´on cos Product Owner (titores) na que se mostrou o traballo feito no sprint anterior e se planificou o seguinte. Durante o sprint o traballo controlouse con gr´aficos Burn-Down para determinar se existe alg´un perigo para o ´exito do sprint. 2.3. Xesti´on da configuraci´on A xesti´on da configuraci´on ´e un proceso cuxo prop´osito ´e establecer e manter a integridade dos produtos de traballo identificando os elementos ou produtos que van ser controlados, definindo un procedemento para o control deses produtos e o rexistro do estado dos produtos [8]. Neste proxecto os elementos de traballo son os ficheiros de c´odigo fonte e t´odolos arquivos que forman a documentaci´on do proxecto. ´ A hora de crear un plan de xesti´on de configuraci´on parece m´ais acertado tratar estes dous tipos de elementos de traballo de forma independente, xa que as necesidades de control e mantemento da integridade son diferentes. 2.3.1. Xesti´on do c´odigo fonte O c´odigo fonte almac´enase nun repositorio Git aloxado en Github. Git ´e unha ferramenta moi potente que permite o control eficiente das versi´ons dunha aplicaci´on cando esta ten un gran n´umero de arquivos de c´odigo fonte. Para aumentar a seguridade aloxouse o repositorio na plataforma Github, o que eliminou a dependencia da integridade dun ´unico ordenador de traballo. 10 CAP´ ITULO 2. XESTI ´ ON DO PROXECTO Ao remate de cada nova funcionalidade faise un Commit local para gardar os cambios realizados. Cada Commit leva asociado un comentario no que se debe explicar os cambios realizados nesa instant´anea. Cando remata a xornada de traballo executase un Push para subir todos os cambios ao repositorio remoto e as´ı estar cubertos fronte a posibles fallos ou perda de informaci´on do ordenador de traballo. 2.3.2. Xesti´on da documentaci´on Para manter a documentaci´on a salvo de posibles fallos no ordenador de traballo utilizamos a ferramenta Google Drive, que permite ter todos os nosos documentos aloxados na nube. Ademais deste incremento da seguridade, o manter os documentos na nube permite aos titores do traballo ter en todo momento acceso a documentaci´on para consultala cando lles sexa necesario. Para manter os documentos ordenados e poder acceder a eles o m´ais r´apido posible empr´egase a estrutura de carpetas que se mostra na figura 2.1. Figura 2.1: Estructura de carpetas. Os documentos manter´an a nomenclatura: <Nome> <Versi´on>.<Extensi´on> 2.4. XESTI ´ ON DO TEMPO 11 A versi´on de cada documento increm´entase cando hai suficientes cambios importantes, sendo criterio do dono do proxecto decidir isto. Para manter un control de cambios sobre os documentos utilizamos as ferramentas que proporcionan a suite Microsoft Office e o editor L A T EXTexmaker. Para poder aumentar a versi´on dun documento ´e condici´on necesaria que t´odolos cambios realizados na versi´on anterior sexan aceptados polo dono do proxecto. 2.4. Xesti´on do tempo A xesti´on do tempo incl´ue os procesos necesarios para lograr a conclusi´on do proxecto a tempo [7]. Eses procesos son os seguintes:  Definici´on das actividades: identifica as actividades espec´ıficas que deben ser realizadas para producir os diferentes produtos entregables do proxecto.  Establecemento da secuencia das actividades: identifica e documenta as dependencias entre as actividades.  Estimaci´on dos recursos: estima o tipo e cantidade de recursos para realizar cada actividade.  Desenvolvemento do cronograma: analiza as secuencias das actividades, a duraci´on das actividades, os requisitos de recursos e as restrici´ons para crear o cronograma do proxecto.  Control do cronograma: controla os cambios no cronograma do proxecto. Para representar o traballo executado durante o proxecto utilizamos a EDT da figura 2.2, especificado previamente no anteproxecto. Unha EDT (estrutura de descomposici´on do traballo) ´e unha descomposici´on xer´arquica, orientada ao produto entregable, do traballo que ser´a executado polo equipo do proxecto en porci´ons de traballo m´ais pequenas e f´aciles de manexar, onde cada nivel descendente da EDT representa unha definici´on cada vez m´ais detallada do traballo do proxecto. 12 CAP´ ITULO 2. XESTI ´ ON DO PROXECTO Figura 2.2: Estrutura de descomposici´on do traballo (EDT). 2.4. XESTI ´ ON DO TEMPO 13 A continuaci´on descr´ıbense as diferentes etapas identificadas dunha forma m´ais detallada. Indicarase os recursos que far´an falta para a s´ua realizaci´on ademais da s´ua duraci´on estimada ao principio do proxecto. As estimaci´ons son moi inexactas por tratarse de estimaci´on iniciais e non das estimaci´on feitas no inicio de cada sprint. A dedicaci´on ser´a de 21 horas/semana que polas 20 semanas de duraci´on do proxecto da unha aproximaci´on de 412,5 horas de traballo totais. Existen dous roles diferenciados ao longo do proxecto: o Product Owner interpretado polos titores do proxecto e o desarrollador interpretado polo estudante. Etapa de preparaci´on Esta fase abarca t´odalas actividades de estudo previas ao inicio do proxecto. Estudi´aronse as tecnolox´ıas utilizadas ao longo do proxecto, coma a linguaxe Python ou a librar´ıa SimpleNLG, o marco de traballo Scrum e, o m´ais importante, a aplicaci´on GALiWeather. Foi necesario estudar a estrutura e as funcionalidades da aplicaci´on GALiWeather dado que gran parte do proxecto baseouse nela. Todo este estudio e formaci´on realizouse mediante a documentaci´on oficial e as diferentes lecturas e tutoriais que se poden encontrar na web. Todas estas actividades son realizadas exclusivamente polo desarrollador. Tempo estimado 1 semana Etapa de iniciaci´on Nesta etapa os Product Owner e o desarrollador traballan conxuntamente para determinar a s´uas necesidades con respecto ´a aplicaci´on e crear as diferentes historias de usuario. Por outra parte, se fai unha estimaci´on inicial da duraci´on dos sprints para realizar unha planificaci´on inicial. Esta planificaci´on axuda dunha maneira gr´afica a determinar a organizaci´on das tarefas e determinar que ´e posible realizar durante o proxecto tendo en conta a s´ua duraci´on. Como produtos xerados por esta fase temos a pila de produto coas historias de usuario e un diagrama de Gantt inicial. Tempo estimado 1 semana 20 CAP´ ITULO 2. XESTI ´ ON DO PROXECTO Riscos do proxecto R01 - An´alise de requisitos err´onea Descrici´on Os requisitos identificados non se axustan as necesidades do cliente. Probabilidade 10 % Impacto (d´ıas) 10 d´ıas Exposici´on (d´ıas) 1 d´ıa Estratexia de minimizaci´on O desenvolvemento baseado en sprints fai que os erros na captura de requisitos se detecten desde fases moi tempranas do proxecto. R02 - Atraso con respecto a planificaci´on Descrici´on Atraso con respecto a planificaci´on inicial debido a falta de experiencia coas tecnolox´ıas. Probabilidade 40 % Impacto (d´ıas) 20 d´ıas Exposici´on (d´ıas) 8 d´ıas Estratexia de minimizaci´on A planificaci´on das tarefas en d´ıas ideais ten en conta os posibles atrasos que podan aparecer durante os sprints. Estratexia de continxencia Reaxustar a planificaci´on inicial deixando de lado os requisitos con menor importancia. R03 - Alcance do proxecto impreciso Descrici´on O alcance do proxecto non cumpre as necesidades do cliente. Probabilidade 10 % Impacto (d´ıas) 20 d´ıas Exposici´on (d´ıas) 2 d´ıas Estratexia de prevenci´on Consultar cos titores o documento do alcance tan pronto como este estea feito. 2.5. XESTI ´ ON DE RISCOS 21 Riscos de dispo˜nibilidade R04 - Acceso denegado ´a BBDD de Meteogalicia Descrici´on Meteogalicia non da o seu consentimento para acceder aos seus datos meteorol´oxicos. Probabilidade 20 % Impacto (d´ıas) 10 d´ıas Exposici´on (d´ıas) 2 d´ıas Estratexia de continxencia Crear unha BBDD propia a partir dos datos recollidos da p´axina web de Meteogalicia. R05 - Indispo˜nibilidade dos titores Descrici´on Os titores non est´an dispo˜nibles para facer as reuni´ons de planificaci´on dos diversos sprints. Probabilidade 5 % Impacto (d´ıas) 5 d´ıas Exposici´on (d´ıas) 0.25 d´ıas Estratexia de continxencia Busca dunha canle de comunicaci´on alternativo para facer a reuni´on ou atraso da reuni´on para outra data. Riscos do produto R06 - Fallo no ordenador persoal Descrici´on Un fallo ou avir´ıa no ordenador de traballo produce a perda da informaci´on do proxecto. Probabilidade 5 % Impacto (d´ıas) 5 d´ıas Exposici´on (d´ıas) 0.25 d´ıas Estratexia de prevenci´on A utilizaci´on de soluci´ons na nube para o almacenamento de arquivos reduce a probabilidade de que se produza algunha perda de informaci´on. 22 CAP´ ITULO 2. XESTI ´ ON DO PROXECTO R07 - Falta de soporte por parte das tecnolox´ıas utilizadas Descrici´on Algunha das tecnolox´ıas utilizadas presentan errores que impiden o desenvolvemento do produto. Probabilidade 10 % Impacto (d´ıas) 20 d´ıas Exposici´on (d´ıas) 2 d´ıas Estratexia de continxencia Busca de novas alternativas para substitu´ır as tecnolox´ıas actuais do proxecto. R08 - Mala usabilidade da plataforma Descrici´on A web non ´e suficientemente clara e sinxela de usar para os usuarios. Probabilidade 10 % Impacto (d´ıas) 5 d´ıas Exposici´on (d´ıas) 0.5 d´ıas Estratexia de continxencia Ter unha reuni´on cos titores para identificar os problemas de usabilidade e as posibles soluciones a eses problemas. 2.6. Estimaci´on de custos Debido ´a natureza do Traballo de Fin de Grado, os custos manexados neste apartado son puramente te´oricos. Os custos directos div´ıdense en custos de persoal, de material e de software. Para todos os produtos software e materiais establecese que a vida ´util sera de 3 anos de amortizaci´on dos cales s´o se utilizaron durante 3 meses a tempo completo neste proxecto. Custos de persoal O equipo de desenvolvemento esta formado por unha persoa co rol de AnalistaProgramador xa que realiza tanto o an´alise como o desenvolvemento do software. Segundo un estudio salarial feito por Vitae Consultores estima o salario medio dun Analista-Programador Java na provincia da Coru˜na en 23.000ebrutos anuais [24]. Estimase que un terzo do salario bruto dun traballador son os custos que ten 2.6. ESTIMACI ´ ON DE CUSTOS 23 que asumir a empresa pola s´ua contrataci´on e que ´o ano hai 1.800 horas laborais nunha xornada est´andar de 8 horas diarias. Tendo en conta estes datos podemos conclu´ır co custo total dun Analista-Programador ´e de 17,00e/hora. Custos materiais Para este proxecto soamente necesitase un PC de sobremesa para o ´unico traballador do proxecto que podemos estimalo nuns 75,00ede amortizaci´on. Custos de software Durante este proxectos utiliz´aronse as seguintes ferramentas software:  Windows 10 Pro (23,25e)  Netbeans IDE (0,00e)  Microsoft Office (23,25e)  TexMaker (0,00e)  PyCharm IDE (0,00e)  Librar´ıas e SDKs (0,00e)  Microsoft Project (64,08e)  Apache Tomcat (0,00e) Custos totais A todos este custos hai que engadirlle gastos indirectos asociados a facturas de servizo b´asicos, alugamentos, etc. que na USC para proxectos TIC establecese nun 21 % adicional do custos directos do proxecto. Concepto Cantidade Custo Unitario Custo Total Analista-Programador 412.5 horas 17,00e/hora 7012,50e Ordenador Persoal - - 75,00e Software - - 110,58e Custos Indirectos - - 1511,60e Total 8709,67e Cadro 2.1: Custos totais do proxecto. 24 CAP´ ITULO 2. XESTI ´ ON DO PROXECTO Cap´ıtulo 3 Especificaci´on de requisitos O an´alise de requisitos ´e o proceso de estudo das necesidades dos usuarios para chegar a unha definici´on dos requisitos do sistema, do hardware ou do software, as´ı coma de estudo e refinamento deses requisitos [12]. Esta tarefa ´e esencial para o ´exito de calquera proxecto xa que dela depende que o produto creado se axuste as necesidades do cliente (O produto pode ser excepcional a nivel t´ecnico pero non serve de nada se non lle aporta valor ao cliente). Neste proxecto nos afastamos das t´ecnicas de especificaci´on de requisitos m´ais cl´asicas e pesadas, nas que os requisitos son descritos de forma moi estrita e formal, para utilizar historias de usuario, empregadas por diversas metodolox´ıas ´axiles. Unha historia de usuario ´e un requisito escrito de forma breve e nunha linguaxe entendible polo cliente ou usuario. As historias de usuario deben cumprir 6 caracter´ısticas (INVEST) [13]:  Independente: p´odense desenvolver en calquera orde.  Negociable: non ´e un contrato expl´ıcito, s´o unha intenci´on que pode ser modificada co tempo.  Valorable: sempre lle debe dar valor ao cliente.  Estimable: deben de estar suficientemente claras como para poder estimalas.  Pequena (Small): as historias pequenas son m´ais f´aciles de estimar.  Verificable (Testable): ´e a ´unica forma de saber se unha historia est´a acabada. Mark Coehn recomenda utilizar o seguinte modelo para escribir historias de usuario: Como <tipo de usuario>, quero <obxectivo>, xa que <raz´on> 25 26 CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Neste proxecto utilizamos solo as d´uas primeiras partes do modelo omitindo a raz´on da historia. Esta ultima parte ten coma fin que os integrantes de proxectos de longa duraci´on poidan recordar a importancia dunha historia cando haxan pasado varios meses de desenvolvemento. Como este ´e un proxecto corto e con poucos integrantes non ´e necesario gardar esta informaci´on. Se unha historia de usuario describe unha restrici´on engadiremos a palabra ’Restrici´on’ ao final da descrici´on. Ademais, a cada historia de usuario se lle engadir´a un identificador, un titulo, unha estimaci´on, uns criterios de aceptaci´on e un apartado de notas no que se engadir´a calquera outra informaci´on en caso de que sexa necesario. As estimaci´ons faranse en d´ıas ideais. Un d´ıa ideal ´e equivalente a un d´ıa no que non se sufre ningunha distracci´on durante a xornada de traballo. Un desenvolvedor de software nun d´ıa normal de traballo, ademais de traballar nas tarefas planificadas, pasa moito tempo respondendo correos, asistindo a reuni´ons, corrixindo bugs, etc.. Os d´ıas ideais serven para estimar o tama˜no dunha historia para poder comparalas entre elas, ´a vez que da unha primeira idea do tempo que levar´a desenvolvela. As historias de usuario dispo˜nen dun nivel de importancia que indica o impacto que ter´a cada unha no valor final do produto e no ´exito do proxecto. Definimos tres niveis de importancia:  Obrigatorio: Indica que esta historia ´e crucial para o ´exito do proxecto. Se non esta presente na versi´on final do produto o proxecto considerarase un fracaso.  Desexable: O proxecto considerase un ´exito a´ında que a historia non est´e implementada pero a s´ua presenza aumentara de forma significativa o valor final do produto.  Opcional: A historia ter´a un impacto m´ınimo no valor final do produto. 3.1. HISTORIAS DE USUARIO 27 3.1. Historias de Usuario 3.1.1. Historias de Usuario: Cliente HU-01 - Xerar predici´ons meteorol´oxicas Solicitante Usuario Descrici´on quero poder xerar un progn´ostico meteorol´oxico en linguaxe natural (ingl´es) a partires dos datos de predici´on a 4 d´ıas vista. Estimaci´on 7 d´ıas Importancia Obrigatorio C. Aceptaci´on O requisito considerarase cumprido cando 50 progn´osticos aleatorias repartidas nos deferentes per´ıodos do ano son similares a os xerados nos mesmos per´ıodos por GALiWeather. Notas HU-02 - Xerar predici´ons da calidade do aire Solicitante Usuario Descrici´on quero poder xerar un progn´ostico do estado da calidade do aire en linguaxe natural (ingl´es) a partires dos datos de predici´on meteorol´oxicos a 3 d´ıas vista. Estimaci´on 3 d´ıas Importancia Obrigatorio C. Aceptaci´on O requisito considerarase cumprido cando a aplicaci´on sexa capaz de xerar os mesmos progn´osticos que os realizados por un experto en calidade do aire tendo como entrada os mesmos datos meteorol´oxicos. Notas 28 CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS HU-03 - Xerar predici´ons en portugu´es Solicitante Usuario Descrici´on quero que os progn´osticos sexan escritos en portugu´es. Estimaci´on 5 d´ıas Importancia Opcional C. Aceptaci´on A aplicaci´on ´e capaz de xerar progn´osticos meteorol´oxicos entendibles por unha persoa da lingua portuguesa. Notas HU-04 - Xerar predici´ons en franc´es Solicitante Usuario Descrici´on quero que os progn´osticos sexan escritos en franc´es. Estimaci´on 5 d´ıas Importancia Opcional C. Aceptaci´on A aplicaci´on ´e capaz de xerar progn´osticos meteorol´oxicos entendibles por unha persoa da lingua francesa. Notas HU-05 - Engadir m´ais par´ametros Solicitante Usuario Descrici´on quero que nas predici´ons se faga referencia ´a presi´on atmosf´erica e ´a humidade. Estimaci´on 6 d´ıas Importancia Opcional C. Aceptaci´on A aplicaci´on ´e capaz de xerar progn´osticos en linguaxe natural facendo referencia ´a humidade e ´a presi´on atmosf´erica. Notas 3.1. HISTORIAS DE USUARIO 29 HU-06 - Facer predici´ons sen todos os par´ametros Solicitante Usuario Descrici´on quero obter progn´osticos a´ında que non estean dispo˜nibles todos os datos meteorol´oxicos. Estimaci´on 4 d´ıas Importancia Opcional C. Aceptaci´on A aplicaci´on ´e capaz de xerar progn´osticos en linguaxe natural coherentes a´ında que so se proporcione un dato meteorol´oxico. Notas HU-07 - Mellorar as predici´ons Solicitante Usuario Descrici´on quero que as predici´ons en ingl´es se correspondan mellor coa forma de falar dun ingl´es nativo. Estimaci´on 5 d´ıas Importancia Desexable C. Aceptaci´on Un experto en ingl´es valida todas as posibles predici´ons xeradas pola aplicaci´on. Notas 36 CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Cap´ıtulo 4 Arquitectura e Ferramentas A arquitectura dun sistema software ´e definida polo IEEE como o conxuntos dos conceptos fundamentais e as propiedades dun sistema no seu entorno, plasmados nos seus elementos, relaci´ons e nos principios do seu dese˜no e evoluci´on. De forma m´ais simple podemos dicir que a arquitectura dun software define, de maneira abstracta, os compo˜nentes que levan a cabo as diferentes tarefas de computaci´on, as s´uas interfaces e a forma en que se comunican entre eles. Esta arquitectura sempre debe dese˜narse en base a uns requisitos e restrici´ons [14, 15]. Este capitulo centrarase no dese˜no a alto nivel da arquitectura da aplicaci´on e na descrici´on das diferentes tecnolox´ıas e ferramentas usadas para cumprir os obxectivos do proxecto. 4.1. Arquitectura do sistema Unha vez analizados os requisitos da aplicaci´on identif´ıcanse tres partes ben diferenciadas dentro da aplicaci´on: a interface web, a aplicaci´on que xera os progn´osticos meteorol´oxicos en linguaxe natural e o provedor de datos. Figura 4.1: Arquitectura do sistema. 37 38 CAP´ ITULO 4. ARQUITECTURA E FERRAMENTAS Na figura 4.1 podemos ver como o usuario interactua coa interface web onde pode visualizar os progn´osticos meteorol´oxicos para os vindeiros d´ıas do municipio galego que eles seleccionen. A interface comunicase cunha API de servizos web que encargase de obter os datos meteorol´oxicos pertinentes da base de datos. Por ultimo, a parte mais importante da aplicaci´on ´e o xerador de progn´osticos que obt´en os datos meteorol´oxicos da base de datos para procesalos e convertelos en un texto en linguaxe natural. Ese texto ´e almacenado na base de datos para que as´ı a API de servizos web poda facilit´aselo ´a interface. Todos os datos meteorol´oxicos almacenados na base de datos son obtidos diariamente por unha aplicaci´on provedora directamente da p´axina web de MeteoGalicia. Como a frecuencia de actualizaci´on dos datos ´e moi baixa (1 vez cada 24 horas) non ´e necesario que os progn´osticos se xeren individualmente a petici´on do usuario. Neste caso ´e moito m´ais eficiente facelo de forma as´ıncrona, ´e dicir, ter os textos xa xerados e gardados na base de datos diminu´ındo o tempo de resposta do servidor ao non ter que xerar un texto en cada unha das petici´ons dos clientes. Este proceso ´e similar ao de MeteoGalicia coa condici´on de que eles actualizan os seus datos de predici´on 2 veces cada 24 horas. Figura 4.2: Arquitectura da aplicaci´on xeradora de progn´osticos. A aplicaci´on xeradora div´ıdese en 4 m´odulos, como se mostra na figura 4.2:  Un modulo de acceso a datos, encargado de ler e escribir os datos meteorol´oxicos e predici´ons da base de datos correspondente.  Un m´odulo parser encargado de ler todos os datos relativos ´a configuraci´on da aplicaci´on e implementar as tarefas de logging.  Un m´odulo que converte os datos de entrada en descrici´ons ling¨u´ısticas intermedias.  Un m´odulo que converte esas descrici´ons ling¨u´ısticas en textos en linguaxe natural. 4.2. PATR ´ ONS DE DESE ˜ NO 39 O funcionamento da aplicaci´on detallarase en m´ais profundidade no capitulo 5 desta memoria. 4.2. Patr´ons de dese˜no Os patr´ons de dese˜no [16] son o esqueleto das soluci´ons a problemas com´uns no desenvolvemento de software. Noutras palabras, brindan unha soluci´on xa probada e documentada a problemas de desenvolvemento de software que est´an suxeitos a contextos similares. Existen tres categor´ıas de patr´ons de dese˜no:  Patr´ons de creaci´on: inicializaci´on e configuraci´on de obxectos.  Patr´ons estruturais: separan a interface da implementaci´on.  Patr´ons de comportamento: describen a comunicaci´on entre obxectos ou clases. Neste proxecto util´ızanse os seguintes patr´ons de dese˜no:  Patr´on Singleton: Restrinxe a instanciaci´on dunha clase ou valor dun tipo a un solo obxecto. Permite garantir que unha clase s´o te˜na unha instancia e proporcionar un punto de acceso global a ela. Isto cons´eguese creando na nosa clase un m´etodo que cree unha instancia do obxecto s´o se a´ında non existe algunha. Para asegurar que a clase non pode ser instanciada novamente se regula o alcance do construtor fac´endoo privado.  Patr´on MVC: O patr´on MVC (Modelo-Vista-Controlador) pl´antea a separaci´on do problema en tres capas: o modelo, que representa a realidade; o controlador, que controlar os eventos da aplicaci´on; e a vista, que ´e utilizada para interaccionar co usuario.  Patr´on DAO: O patr´on DAO (Data Access Object) utilizase para abstraer e encapsular todos os accesos ´a base de datos. O DAO manexa a conexi´on coa base para obter e almacenar os datos. 40 CAP´ ITULO 4. ARQUITECTURA E FERRAMENTAS Figura 4.3: Patr´on MVC. 4.3. Ferramentas 4.3.1. Librar´ıas SimpleNLG: Xeraci´on de Texto en Linguaxe Natural Para a xeraci´on de texto en linguaxe natural utilizarase a librar´ıa SimpleNLG [6]. SimpleNLG ´e unha librar´ıa escrita en Java que permite a un programa xerar frases ortogr´afica, sint´atica e gramaticalmente correctas en ingl´es. ´ A hora de crear unha estructura sintactica e convertila en texto, estos son os pasos que a libraria segue: 1. Inicializaci´on dos compo˜nentes b´asicos necesarios; cos obxectos l´exicos necesarios. 2. Uso das operaci´ons proporcionadas pola API para configurar as caracter´ısticas (features) dos compo˜nentes. 3. Combinaci´on dos compo˜nentes para formar estruturas m´ais grandes e complexas. 4. Proporcionar a estrutura resultante ao linealizador, aplicando as inflexi´ons correctas e ordenaci´on linear dependendo das features, antes de devolver o texto resultante. 4.3. FERRAMENTAS 41 A librar´ıa foi desenvolvida polo grupo de ling¨u´ıstica computacion (CLAN) da Universidade de Aberdeen e incl´ue un extenso tutorial ademais da documentaci´on da API e un foro de consultas. SimpleNLG perm´ıtenos traballar coas estruturas ling¨u´ısticas m´ais com´uns (oraci´ons nominais, verbais, enumeraci´ons, preguntas, etc.) e combin´andoas entre elas podemos formar textos realmente complexos. Ademais existen varias adaptaci´ons da librar´ıa para dar soporte a idiomas coma o Franc´es ou o Portugu´es. Fuzzy4j: L´oxica Difusa en Java Nos operadores ling¨u´ısticos facemos uso da l´oxica difusa ou borrosa (fuzzy logic) [18] para transformar os datos do estado do ceo en descrici´ons ling¨u´ısticas o m´ais precisas posible. A l´oxica difusa perm´ıtenos introducir valores intermedios entre a afirmaci´on completa ou a negaci´on absoluta de igual maneira que poida definirse termos e expresi´ons que non son totalmente certas nin totalmente falsas. Por exemplo, podemos considerar intuitivamente que unha persoa ´e alta se mide m´ais de 1.8 metros, pero de igual maneira consideramos a unha persoa como alta se mide 1.79 metros. Sen embargo, se o concepto de persoa alta def´ınese seguindo unha aproximaci´on booleana, unha persoa que mida 1.79 metros poder´ıa ser considerada como baixa, tal e como se ilustra nas funci´ons de pertenza da Fig. 4.4 (esquerda), mentres que empregando definici´ons borrosas a altura pode definirse coma un concepto gradual (Fig. 4.4 dereita). Figura 4.4: Funci´ons de pertenza do conxunto borroso .alto”. 42 CAP´ ITULO 4. ARQUITECTURA E FERRAMENTAS Fuzzy4j [17] ´e unha librar´ıa Java que implementa as funci´ons mais com´uns dentro da l´oxica difusa nas areas dos conxuntos difusos, agregaci´on difusa e controladores difusos. Neste caso solo utilizaremos a funci´on trapezoidal para obter unha descrici´on da evoluci´on do estado do ceo. Figura 4.5: Funci´on de pertenza trapezoidal. Jersey: Servizos RESTFul en Java Os datos almacenados na base de datos ser´an accesibles pola interface web grazas aos diferentes servizos REST implementados. A Transferencia de Estado Representacion (Representational State Transfer) ou REST [19] ´e un estilo de arquitectura software para sistemas hipermedia distribu´ıdos como a World Wide Web. O t´ermino orixinouse no ano 2000, nunha tese doutoral sobre a web escrita por Roy Fielding, un dos principais autores da especificaci´on do protocolo HTTP e pasou a ser amplamente utilizado pola comunidade de desenvolvemento. Rest se asenta sobre o protocolo HTTP que permite a comunicaci´on sen estado entre o cliente e o servidor de maneira que cada mensaxe HTTP cont´en toda a informaci´on necesaria para comprender a petici´on. A s´ua vez proporciona un conxunto de operaci´ons ben definidas (POST, GET, PUT e DELETE) e unha sintaxe universal, polo que cada recurso ´e direccionable unicamente a trav´es da s´ua URI. Neste proxecto utilizouse a librar´ıa Jersey [21] que facilita o desarrollo de servizos RESTful grazas a que proporciona unha API est´andar e portable. As petici´ons na interface realizaranse en JavaScript mediante a tecnolox´ıa AJAX. 4.3. FERRAMENTAS 43 Outras librar´ıas Outras librar´ıas utilizadas pero con menos peso sobre o desempe˜no da aplicaci´on son:  JDBC de SQLite: Proporciona as funci´ons para ler e almacenar os datos da base de datos.  Librar´ıa Lang3 de Apache Commons: Proporciona funci´ons para o tratamento de arrays.  JavaTuples: Proporciona estruturas de datos para traballar con tuplas.  jQuery: Biblioteca JavaScript que permite simplificar a maneira de interactuar cos documentos HTML, manipular a arbore DOM, manexar eventos, desenvolver animaci´ons e engadir interacci´on coa t´ecnica AJAX [22]. 4.3.2. Outras Ferramentas Desenvolvemento Co obxectivo de maximizar a produtividade e reducir o tempo de aprendizaxe e adaptaci´on as deferentes ferramentas, o entorno de traballo seleccionado foi o seguinte:  Sistema Operativo: Windows 10 Pro.  IDE: Netbeans IDE para a codificaci´on de jGALiWeather e PyCharm IDE para revisar o c´odigo fonte da aplicaci´on orixinal en Python, GALiWeather.  Servidor de aplicaci´ons: Utilizamos o servidor Apache Tomcat por ter un 60 % da cota de mercado actual.  Base de Datos: Utilizamos unha base de datos SQLite xa que foi a que se proporcionou dende o CiTIUS cos datos meteorol´oxicos proporcionados por MeteoGalicia nos ´ultimos anos. Documentaci´on Para a realizaci´on da documentaci´on do proxecto se utilizaron a seguintes ferramentas:  Microsoft Office: Suite ofim´atica para a realizaci´on da documentaci´on durante a transcurso do proxecto. 44 CAP´ ITULO 4. ARQUITECTURA E FERRAMENTAS  TexMaker: IDE de L A T EX utilizado na realizaci´on desta memoria.  Microsoft Project: Utilizado para a creaci´on de diagramas de Gantt para xustificar os prazos do proxecto.  Draw.io: Aplicaci´on web para a creaci´on de diagramas en xeral. Cap´ıtulo 5 Dese˜no e Implementaci´on O dese˜no ´e o proceso que traduce os requisitos nunha representaci´on do software de forma que poida co˜necerse a arquitectura, funcionalidade e incluso, a calidade do mesmo antes de comezar coa codificaci´on. Ademais, realizar un dese˜no previo da aplicaci´on ´e unha forma de resolver problemas nas fases m´ais temp´eranas do proxecto, aforrando costes. En Scrum o dese˜no ´e continuo e vaise actualizando e completando en cada sprint. Neste capitulo definirase o dese˜no de jGALiWeather e como se realizou a codificaci´on a partir dese dese˜no. Debido as grandes diferencias entre una aplicaci´on web (interface de visualizaci´on) e unha aplicaci´on cl´asica (xerador de progn´osticos e parser), os dese˜nos e implementaci´ons destes dous programas abordarase en secci´ons separadas. A ocorrencia do risco R04, fixo necesaria a busca dunha maneira alternativa de obter datos meteorol´oxicos actualizados. Ao final decidiuse crear un parser que recuperara a informaci´on necesaria directamente do c´odigo HTML da web de MeteoGalicia. Esta aplicacaci´on tamen ter´a a s´ua propia secci´on. A partir de agora lle chamaremos jGALiWeather ´a aplicaci´on xeradora de textos en linguaxe natural, interface web ´a aplicaci´on web de visualizaci´on dos datos e proveedor de datos ao programa encargado de parsear a web de Meteogalicia para proveer datos meteorol´oxicos actualizados ´a base de datos. 5.1. jGALiWeather jGALiWeather emprega datos de predici´on simb´olico-num´ericos e informaci´on experta adicional para xerar as predici´ons textuais finais. Esta tarefa div´ıdese en dous procesos independentes. En primeiro lugar, os datos conv´ertense en descrici´ons ling¨u´ısticas (codificadas nun linguaxe intermedio). Estas descrici´ons cr´eanse empregando un m´etodo computacional que abstrae os datos en etiquetas ling¨u´ısticas. O proceso final converte estas descrici´ons en textos en ingl´es. A figura 5.1 45 52 CAP´ ITULO 5. DESE ˜ NO E IMPLEMENTACI ´ ON – Descrici´on: Exec´utanse os diferentes operadores ling¨u´ısticos para cada concello convertendo os datos meteorol´oxicos en descrici´ons ling¨u´ısticas intermedias. Existen os seguintes operadores: dous operadores distintos para o estado do ceo, un operador para o vento, un operador para a chuvia, un operador para n´eboa, outro para a temperatura e un ultimo operador para o ´ındice da calidade do aire.  Proceso 3.3: Creaci´on de progn´osticos en texto. – Precondici´on: As descrici´ons ling¨u´ısticas intermedias son v´alidas. – Postcondici´on: Dev´olvense os progn´osticos textuais para cada localizaci´on. – Descrici´on: Cada unha das diferentes descrici´ons ling¨u´ısticas conv´ertense nun progn´ostico textual utilizando t´ecnicas NLG. DFD de nivel 2 - Gardar progn´osticos Na figura 5.7 podemos ver o DFD resultante da explosi´on do proceso 4 do diagrama de fluxo de datos de nivel 1 da figura 5.3. Figura 5.7: DFD de nivel 2 - Gardar progn´osticos Especificaci´ons de proceso:  Proceso 4.1: Integrar progn´osticos individuais. – Precondici´on: Existen progn´osticos individuais para cada tipo de dato meteorol´oxico. 5.1. JGALIWEATHER 53 – Postcondici´on: Dev´olvense todos os progn´osticos integrados para cada localizaci´on. – Descrici´on: As estruturas de datos da librar´ıa SimpleNLG utilizadas para crear progn´osticos individuais para cada tipo de dato x´untanse para crear un texto m´ais complexo albergando todo eses progn´osticos independentes.  Proceso 4.2: Almacenar progn´osticos. – Precondici´on: Os progn´osticos textuais son v´alidos. – Postcondici´on: Existen novas entradas na t´aboa de progn´osticos da base de datos. – Descrici´on: Neste proceso os progn´osticos de cada localizaci´on eng´adense ´a base de datos indicando a data no que se engadiron. 5.1.2. Implementaci´on da aplicaci´on jGALiWeather ´e unha aplicaci´on autom´atica de consola, polo que non dispo˜ne de interface gr´afica e os ´unicos elementos que a compo˜nen son as estruturas de datos e os m´odulos que procesan eses datos. De maneira m´ais detallada, a aplicaci´on ten a seguinte estrutura de paquetes e clases:  Clase PredictionSummarizer. Clase encargada de levar a cabo a xeraci´on de progn´osticos textuais a curto prazo. Para elo s´ervese das funcionalidades que proporcionan os m´odulos do resto de paquetes.  Paquete algorithm. Cont´en os operadores que converten os datos de entrada en descrici´ons ling¨u´ısticas intermedias: – Paquete weather operators. Cont´en os operadores ling¨u´ısticos que converten os datos de predici´on meteorol´oxica en descrici´ons intermedias: ◦Clase SkyStateAOperator. Esta clase implementa un operador que xera unha descrici´on ling¨u´ıstica da cobertura nubosa, inclu´ındo informaci´on do estado do ceo en diferentes subper´ıodos cronol´oxicos. ◦Clase SkyStateBOperator. Esta clase implementa un operador que xera unha descrici´on ling¨u´ıstica da cobertura nubosa, inclu´ındo informaci´on do estado do ceo para todo o per´ıodo, utilizando cuantificadores. 54 CAP´ ITULO 5. DESE ˜ NO E IMPLEMENTACI ´ ON ◦Clase RainOperator. Esta clase implementa un operador que xera unha descrici´on ling¨u´ıstica das precipitaci´ons, inclu´ındo informaci´on sobre a intensidade das mesmas. ◦Clase WindOperator. Esta clase implementa un operador que xera unha descrici´on ling¨u´ıstica do vento, inclu´ındo informaci´on acerca dos episodios de vento e os cambios na direcci´on ou na intensidade. ◦Clase FogOperator. Esta clase implementa un operador que xera unha descrici´on ling¨u´ıstica da n´eboa, inclu´ındo informaci´on sobre os per´ıodos de n´eboa. ◦Clase TemperatureOperator. Esta clase implementa un operador que xera unha descrici´on ling¨u´ıstica das temperaturas, inclu´ındo informaci´on acerca da variaci´on na temperatura. – Paquete ica operators. Cont´en un conxunto de operadores que extraen a informaci´on relevante dos datos de predici´on meteorol´oxica e un operador que xera a descrici´on intermedia de calidade do aire: ◦Clase ICASkyStateOperator. Esta clase implementa un operador que mide o ratio de aparici´on de cada episodio de cobertura nubosa posible. ◦Clase ICAWindOperator. Esta clase implementa un operador que mide o ratio de aparici´on de per´ıodos de vento relevantes. ◦Clase ICARainOperator. Esta clase implementa un operador que mide o ratio de aparici´on de per´ıodos de precipitaci´ons relevantes. ◦Clase ICAConditionsOperator. Esta clase implementa un operador que incl´ue regras expertas para determinar a situaci´on meteorol´oxica m´ais precisa posible, tendo en conta os valores do vento, das choivas e da cobertura nubosa adquiridos dos demais operadores. ◦Clase ICAOperator. Esta clase implementa un operador que obt´en a tendencia do estado da calidade do aire base´andose nas s´uas variaci´ons.  Paquete database. Cont´en a clase de conexi´on coa base de datos, que implementa consultas para a obtenci´on e actualizaci´on da informaci´on: – Clase DatabaseConnector. Esta clase permite conectarse a unha base de datos cuxa estrutura sexa similar ´a que implementa MeteoGalicia, co fin de extraer os datos meteorol´oxicos e de calidade do aire para a s´ua conversi´on en textos en linguaxe natural. 5.1. JGALIWEATHER 55 Figura 5.8: Estrutura de ficheiros do paquete algorithm. Figura 5.9: Estrutura de ficheiros do paquete database.  Paquete data. Conten estruturas de datos necesarias para o correcto funcionamento da aplicaci´on e unha serie de filtros para comprobar a validez dos datos: – Paquete data filters. Cont´en os filtros utilizados na aplicaci´on: ◦Clase DataFilter. Clase que determina se os datos de entrada son v´alidos e elimina os datos inv´alidos, no caso de que sexa posible. ◦Clase DataLengthFilter. Clase que determina se o n´umero de datos de entrada ´e soportado pola aplicaci´on. ◦Clase MeteorologicFilter. Clase que simplifica os valores num´ericos que indican o estado do ceo en caso necesario.  Paquete configuration. Cont´en os m´odulos encargados de ler todos os datos relativos ´a configuraci´on da aplicaci´on e un m´odulo que implementa as tarefas de logging: – Paquete configuration reader. Cont´en as estruturas de datos e a clase de procesamento de datos necesarias para obter a configuraci´on xeral da aplicaci´on: – Clase ConfigurationReader. Clase que lee e proporciona ao resto de m´odulos a informaci´on almacenada no arquivo de configuraci´on xeral da aplicaci´on (configuration.xml). 56 CAP´ ITULO 5. DESE ˜ NO E IMPLEMENTACI ´ ON Figura 5.10: Estrutura de ficheiros do paquete data. – Paquete variable reader. Cont´en as estruturas de datos e a clase de procesamento de datos necesarias para obter a definici´on das variables que se utilizan para a xeraci´on dos textos: ◦Clase VariableReader. Clase que lee a informaci´on das variables da aplicaci´on (variables.xml) e proporciona dita informaci´on ao resto de m´odulos da aplicaci´on. – Paquete partition reader. Cont´en unha serie de estruturas de datos e unha clase encargada de procesar eses datos para obter a informaci´on referente as partici´ons: ◦Clase PartitionReader. Clase que lee a informaci´on que define as partici´ons num´ericas asociadas a etiquetas no arquivo de configuraci´on correspondente (partitions.xml). – Paquete template reader. Cont´en unha serie de estruturas de datos e unha clase encargada de procesar eses datos para obter a informaci´on referente aos modelos: ◦Clase TemplateReader. Clase que lee a informaci´on que define os modelos necesarios para xeraci´on de texto en linguaxe natural no arquivo de configuraci´on correspondente (partitions.xml). – Paquete logger: ◦Clase GALiLogger. Clase encargada de proporcionar servizos de logging ao resto de m´odulos da aplicaci´on, c´o fin de informar do estado da execuci´on ao longo do proceso. 5.1. JGALIWEATHER 57 Figura 5.11: Estrutura de ficheiros do paquete configuration.  Paquete nlg. Cont´en un conxunto de m´odulos que permiten a conversi´on de descrici´ons ling¨u´ısticas en textos en linguaxe natural: – Clase DescriptionAggregator. Esta clase encargase de agregar os textos finais de cada variable meteorol´oxica para proporcionar unha predici´on textual completa. – Paquete nlg generators. Cont´en os compo˜nentes que, para cada variable meteorol´oxica de entrada, converten unha descrici´on ling¨u´ıstica nunha predici´on textual. Ditos compo˜nentes combinan co˜necemento experto con t´ecnicas de xeraci´on de linguaxe natural, mediante as funci´ons proporcionadas pola librar´ıa SimpleNLG. ◦Clase SkyCoverageGeneratorLevel1. Clase encargada de xerar unha descrici´on cronol´oxica do estado do ceo. ◦Clase SkyCoverageGeneratorLevel2. Clase encargada de xerar unha descrici´on cuantitativa do estado do ceo. ◦Clase RainGenerator. Clase encargada de xerar unha descrici´on cronol´oxica dos episodios de precipitaci´ons. ◦Clase WindGenerator. Clase encargada de xerar unha descrici´on dos episodios de vento. 58 CAP´ ITULO 5. DESE ˜ NO E IMPLEMENTACI ´ ON ◦Clase FogGenerator. Clase encargada de xerar unha descrici´on dos episodios de n´eboa. ◦Clase TemperatureGenerator. Clase encargada de xerar unha descrici´on do estado das temperaturas e a s´ua tendencia. ◦Clase ICAGenerator. Clase encargada de xerar unha descrici´on xeral do estado do ´ındice de calidade do aire. – Paquete precipitation nlg. Cont´en compo˜nentes e estruturas de datos utilizados para a xeraci´on de textos en linguaxe natural para os episodios de precipitaci´ons. – Paquete wind nlg. Da mesma maneira que o paquete anterior, cont´en compo˜nentes e estruturas de datos utilizados para xerar textos de predici´on do vento. Figura 5.12: Estrutura de ficheiros do paquete nlg. As clases non comentadas nesta secci´on tr´atanse de clases que te˜nen un papel secundario ou auxiliar de cara as clases e m´odulos explicados anteriormente. 5.1.3. Descrici´on do funcionamiento da aplicaci´on Lectura dos ficheiros de configuraci´on Para poder levar a cabo o resto de tarefas, ambos servizos precisan dun conxunto de informaci´on almacenada en arquivos de configuraci´on. En concreto, os seguintes ficheiros son necesarios para o funcionamento da aplicaci´on:  Arquivo de configuraci´on xeral (configuration.xml): Cont´en a informaci´on de conexi´on ´a base de datos e a localizaci´on do resto dos ficheiros. 5.1. JGALIWEATHER 59  Arquivo de definici´on de variables (variables.xml): Define as variables que se utilizan na xeraci´on dos textos de predici´on operativa.  Arquivo de definici´on de partici´ons de variables (partitions.xml): Define partici´ons num´ericas asociadas a etiquetas ling¨u´ısticas, utilizadas na xeraci´on de descrici´ons ling¨u´ısticas.  Arquivo de definici´on de elementos textuais (template.xml): Cont´en as palabras e expresi´ons utilizadas no proceso de xeraci´on de texto en linguaxe natural. O m´odulo configuration reader ´e o encargado de ler os ficheiros de configuraci´on e cargar a informaci´on que conte˜nen, para po˜nela a disposici´on dos demais m´odulos [1]. Obtenci´on de datos de predici´on Unha vez cargados todos os datos de configuraci´on, a aplicaci´on conectase ´a base de datos para obter os datos de cada municipio. O m´odulo database ´e o encargado de administrar esta conexi´on e de executar as diferentes consultas. Filtrado de datos de predici´on Os datos obtidos deben pasar por unha serie de filtros que garanten a integridade dos datos e por tanto o correcto funcionamento dos m´odulos de xeraci´on de descrici´ons ling¨u´ısticas e linguaxe natural. O m´odulo data filters cont´en un conxunto de filtros que controlan a aparici´on de datos non v´alidos e o n´umero de datos v´alidos dispo˜nibles. Xeraci´on de descrici´ons ling¨u´ısticas Para a predici´on a curto prazo (m´odulo weather operator) e o estado de calidade do aire (m´odulo ica operators), un conxunto de operadores extraen a informaci´on relevante dos datos de entrada e xeran descrici´ons ling¨u´ısticas para cada municipio, que consisten en conxuntos de etiquetas ling¨u´ısticas xunto con referencias temporais. En concreto entre ambos m´odulos implementan sete operadores principais:  Estado do ceo 1: Proporciona unha descrici´on cronol´oxica do estado do ceo.  Estado do ceo 2: Proporciona unha descrici´on cuantitativa do estado do ceo. 60 CAP´ ITULO 5. DESE ˜ NO E IMPLEMENTACI ´ ON  Precipitaci´on: Proporciona unha descrici´on cronol´oxica dos episodios de precipitaci´ons.  Vento: Proporciona unha descrici´on cronol´oxica dos episodios de vento intenso.  N´eboa: Proporciona unha descrici´on cronol´oxica dos episodios de n´eboa dos datos.  Temperatura: Proporciona unha descrici´on do estado das temperaturas e a s´ua tendencia.  Calidade do aire: Proporciona unha descrici´on xeral do estado do ´ındice de calidade do aire. Xeraci´on de texto en linguaxe natural Para cada operador de xeraci´on de descrici´ons ling¨u´ısticas existe un xerador de texto en linguaxe natural asociado, que converte a descrici´on nun texto adaptado ao estilo meteor´ologo e que proporciona informaci´on relevante e facilmente comprensible polos usuarios. O paquete nlg simpleNLG cont´en os m´odulos encargados desta tarefa, sendo nlg generators o m´odulo principal, no que se han implementado todos os operadores de xeraci´on de linguaxe natural. Estes operadores, utilizando as descrici´ons ling¨u´ısticas e as funcionalidades da librar´ıa SimpleNLG, devolven textos de predici´on en ingl´es. Os m´odulos auxiliares precipitation nlg ewind nlg util´ızanse para xeraci´on de textos de precipitaci´ons e vento, cuxa estrutura ´e m´ais complexa. Por ultimo, o m´odulo nlg aggregator, ´e o encargado de agrupar os textos das distintas variables meteorol´oxicas nun ´unico texto. Exportaci´on de progn´osticos Unha vez se haxan xerado os textos para todos os municipios, estes son gardados na base de datos para que sexan accesibles dende a interface web. 5.2. Interface Web ´ A interface web ´e unha Single Page Application, noutras palabras, a aplicaci´on web ten unha sola paxina ou vista e actualizase o seu contido como resposta ´as acci´ons do usuario. Grazas a este concepto podemos intercambiar datos c´o servidor de maneira r´apida e flu´ıda. Ademais reducimos o m´aximo posible a carga 5.2. INTERFACE WEB 61 do servidor, xa que non s´o non ten que renderizar paxinas HTML en cada petici´on dun cliente sen´on que gran parte do procesamento trasladase aos clientes. A figura 5.13 mostra o dese˜no da ´unica vista da interface web. Figura 5.13: Plataforma web en funcionamento. 5.2.1. Controlador RESTFul A arquitectura da aplicaci´on modelase seguindo o patron de dese˜no MVC (Modelo-Vista-Controlador) cuxo funcionamento esta explicado no apartado 4.2. O controlador esta composto por un servizo RESTFul que accede ´a base de datos para recuperar os datos meteorol´oxicos para que sexan accesibles dende o cliente. Este acceso realizase mediante URIs (Uniform Resource Identifier) e neste caso dispo˜nemos dunha ´unica URI, como se mostra na t´aboa 5.1. URI M´etodo jgaliweather api/v1/meteorologicalData/{id}GET Cadro 5.1: URI e m´etodo empregado. 68 CAP´ ITULO 5. DESE ˜ NO E IMPLEMENTACI ´ ON Gracias a esta URL m´ais aos identificadores anteriormente recuperados, a aplicaci´on pode parsear a p´axina devolta dunha forma sinxela coas funcionalidades proporcionadas pola librar´ıa Jsoup. Os datos recuperados son:  Estado do ceo.  Vento.  Temperatura.  Probabilidade de chuvia.  ´ Indice de calidade do aire. Por ´ultimo, todos estes datos eng´adense ou actual´ızanse (se xa exist´ıan datos para esa data) na base de datos para que poidan ser utilizados tanto por jGALiWeather coma pola interface web. Cap´ıtulo 6 Probas As probas intentan demostrar que un programa cumpre co seu prop´osito, as´ı como descubrir defectos no programa antes de pasalo a produci´on [23]. O proceso de probas ten d´uas metas distintas:  Avalidaci´on do software: Demostrar ao desenvolvedor de software e ao cliente que o software cumpre cos requisitos. Isto implica que exista, polo menos, unha proba de validaci´on por cada requisito.  Averificaci´on do software: Encontrar situaci´ons onde o comportamento do software sexa incorrecto, indesexable ou non est´e de acordo coa s´ua especificaci´on. Neste cap´ıtulo, detallarase as probas realizadas para validar e verificar o software que poden ser de dous tipos:  Probas unitarias: As probas unitarias son o proceso de probar compo˜nentes do programa, como funci´ons ou clases. Este tipo de probas enfocarase en comprobar a funcionalidade dos obxectos ou m´etodos.  Probas do sistema: As probas do sistema consisten na integraci´on dunha parte ou a totalidade dos compo˜nentes do sistema para probar o sistema coma un todo. A metodolox´ıa Scrum utilizada neste proxecto outorga m´ais importancia as probas durante o desenvolvemento do software do que lle dan outras metodolox´ıas m´as cl´asicas. Isto ´e debido ´a restrici´on de entregar unha versi´on do software funcional ao final de cada sprint. Ao final de cada sprint se lle entrega ao cliente unha versi´on totalmente operativa do software co fin de obter retroalimentaci´on da s´ua opini´on e facer balance do cumprimento das historias de usuario (validaci´on do software). 69 70 CAP´ ITULO 6. PROBAS 6.1. Verificaci´on Unha proba unitaria ´e unha forma de probar o correcto funcionamento dun compo˜nente dun programa. Estes compo˜nentes, xeralmente, son unidades encargadas de realizar unha tarefa ou funcionalidade especifica. Para verificar o software utilizaremos este tipo de probas, que neste caso probar´an as distintas funcionalidades de cada un dos m´odulos do programa para determinas se realizan a s´ua tarefa correctamente devolvendo os datos requiridos. Para implementar os test unitarios utilizamos a librar´ıa JUnit.JUnit ´e un framework que permite realizar a execuci´on de clases Java de maneira controlada, para poder avaliar que cada un dos m´etodos da clase se comporta como se espera [20]. Ademais o entorno de desenvolvemento utilizado (NetBeans IDE) proporciona os plug-ins necesarios para xerar modelos para que a creaci´on das probas dunha clase se realice de maneira autom´atica, reducindo o tempo de desenvolvemento de cada proba. As probas div´ıdense en 4 apartados (1 por cada m´odulo) da seguinte maneira:  Probas do m´odulo de configuraci´on: proban as funcionalidades relacionadas coa lectura dos ficheiros de configuraci´on.  Probas do m´odulo de acceso a datos: proban as funcionalidades relacionadas coa lectura dos datos almacenados na base de datos.  Probas do m´odulo de operadores ling¨u´ısticos: proban as funcionalidades relacionadas coa conversi´on dos datos de predici´on en descrici´ons ling¨u´ısticas intermedias.  Probas do m´odulo NLG: proban as funcionalidades relacionadas coa xeraci´on de textos en linguaxe natural. Nas t´aboas seguintes det´allanse as probas unitarias realizadas, indicando o seu identificador, unha descrici´on curta, a entrada proporcionada, o resultado esperado e o resultado obtido. 6.1. VERIFICACI ´ ON 71 Probas do m´odulo de configuraci´on CP-01 Descrici´on Proba os m´etodos que len o ficheiro de configuraci´on principal da aplicaci´on. Entrada Ficheiro de configuraci´on principal da aplicaci´on. Resultado esperado Devolve a ruta correcta dos demais ficheiros de configuraci´on. Resultado obtido Correcto CP-02 Descrici´on Proba os m´etodos que len o ficheiro coas estruturas ling¨u´ısticas. Entrada Ficheiro de templates da aplicaci´on. Resultado esperado Devolve a palabra clear ao ler o labelset Ce o label C. Resultado obtido Correcto CP-03 Descrici´on Proba os m´etodos que len o ficheiro coas variables. Entrada Ficheiro de variables da aplicaci´on. Resultado esperado Devolve correctamente o rango dos valores do vento. Resultado obtido Correcto 72 CAP´ ITULO 6. PROBAS CP-04 Descrici´on Proba o m´etodo apply da clase ObjectSet. Entrada Lista de obxectos cos valores: 1, 3, 24 e 15. Dados estos valores comprobase se o valor 24 esta entre eles. Resultado esperado Devolve o valor 1. Resultado obtido Correcto CP-05 Descrici´on Proba os m´etodos que len o ficheiro coas partici´ons. Entrada Ficheiro de partici´ons da aplicaci´on. Resultado esperado Devolve correctamente un valor de ObjectSet, un CrispInterval e un FuzzySet. Resultado obtido Correcto Probas do m´odulo de operadores ling¨u´ısticos CP-06 Descrici´on Proba que o operador ling¨u´ıstico encargado da temperatura realiza correctamente a s´ua tarefa. Entrada Valores para a temperatura: 15, 16, 17, 15, 15, 16, 17 e 15. Resultado esperado Devolve a seguinte descrici´on ling¨u´ıstica: VH WC SI C PV Resultado obtido Correcto 6.1. VERIFICACI ´ ON 73 CP-07 Descrici´on Proba que o operador ling¨u´ıstico encargado da n´eboa realiza correctamente a s´ua tarefa. Entrada Valores num´ericos para o estado do ceo: 106, 115, 120, 125, 106, 105, 106, 106, 130, 106, 101 e 106. Resultado esperado Devolve a seguinte descrici´on ling¨u´ıstica: [[0, 0], [2, 2], [3]] [[1]] [[3]] Resultado obtido Correcto CP-08 Descrici´on Proba que o operador ling¨u´ıstico encargado do vento realiza correctamente a s´ua tarefa. Entrada Valores num´ericos para o vento: 320, 320, 320, 320, 320, 301, 332, 317, 332, 302, 317 e 332. Resultado esperado Devolve a seguinte descrici´on ling¨u´ıstica: 0-4 320 320 320 320 320 6-8 332 317 332 10-11 317 332 Resultado obtido Correcto 74 CAP´ ITULO 6. PROBAS CP-09 Descrici´on Proba que o operador ling¨u´ıstico encargado da chuvia realiza correctamente a s´ua tarefa. Entrada Valores num´ericos para a chuvia: 110, 117, 111, 107, 118, 103, 109, 104, 113, 119, 105 e 108. Resultado esperado Devolve a seguinte descrici´on ling¨u´ıstica: 0-4IIPPI 6 SN 8-9 ST ST 11 P Resultado obtido Correcto CP-10 Descrici´on Proba que o operador ling¨u´ıstico encargado da descrici´on cronol´oxica do estado do ceo realiza correctamente a s´ua tarefa. Entrada Valores num´ericos para o estado do ceo: 115, 115, 115, 115, 115, 115, 115, 115, 115, 115, 115 e 115. Resultado esperado Devolve a seguinte descrici´on ling¨u´ıstica: V Resultado obtido Correcto CP-11 Descrici´on Proba que o operador ling¨u´ıstico encargado da descrici´on cuantitativa do estado do ceo realiza correctamente a s´ua tarefa. Entrada Valores num´ericos para o estado do ceo: 115, 115, 115, 115, 115, 115, 115, 115, 115, 115, 115 e 115. Resultado esperado Devolve a descrici´on ling¨u´ıstica axeitada. Resultado obtido Correcto 6.1. VERIFICACI ´ ON 75 Probas do m´odulo de operadores ling¨u´ısticos CP-12 Descrici´on Proba que o operador ling¨u´ıstico encargado do vento no m´odulo do ICA realiza correctamente a s´ua tarefa. Entrada Valores num´ericos para o vento: 317, 320, 320, 317, 320, 320, 332, 317 e 332. Resultado esperado Devolve a seguinte descrici´on ling¨u´ıstica: [3.0,6.0,3.0] Resultado obtido Correcto CP-13 Descrici´on Proba que o operador ling¨u´ıstico encargado do estado do ceo no m´odulo ICA realiza correctamente a s´ua tarefa. Entrada Valores num´ericos para o estado do ceo: 110, 103, 111, 107, 108, 101, 109, 102 e 113. Resultado esperado Devolve a descrici´on ling¨u´ıstica axeitada. Resultado obtido Correcto CP-14 Descrici´on Proba que o operador ling¨u´ıstico encargado da chuvia no m´odulo ICA realiza correctamente a s´ua tarefa. Entrada Valores num´ericos para a chuvia: 110, 103, 111, 107, 108, 101, 109, 102 e 113. Resultado esperado Devolve a seguinte descrici´on ling¨u´ıstica: [2.0,4.0,2.0] Resultado obtido Correcto 76 CAP´ ITULO 6. PROBAS CP-15 Descrici´on Proba que o operador ling¨u´ıstico encargado do ICA realiza correctamente a s´ua tarefa. Entrada Valores num´ericos para o ICA: 5, 1 e 3. Resultado esperado Devolve a seguinte descrici´on ling¨u´ıstica: -+I Resultado obtido Correcto CP-16 Descrici´on Proba que o operador ling¨u´ıstico encargado das condici´ons do ICA realiza correctamente a s´ua tarefa. Entrada Valores num´ericos para o vento: 317, 320, 320, 317, 320, 320, 332, 317 e 332. Valores num´ericos para o estado do ceo: 110, 103, 111, 107, 108, 101, 109, 102 e 113. Valores num´ericos para a chuvia: 110, 103, 111, 107, 108, 101, 109, 102 e 113. Resultado esperado Devolve a seguinte descrici´on ling¨u´ıstica: [RW, RW, RW] Resultado obtido Correcto Probas do m´odulo NLG CP-17 Descrici´on Proba que o xerador de texto en linguaxe natural encargado da descrici´on cuantitativa do estado do ceo realiza correctamente a s´ua tarefa. Entrada Valores num´ericos para o estado do ceo: 103, 103, 101, 101, 101, 101, 101, 101, 101, 101, 103 e 101. Resultado esperado Devolve o seguinte texto: Clear skies in general for the next few days, although it will occasionally be partly cloudy. Resultado obtido Correcto 6.1. VERIFICACI ´ ON 77 CP-18 Descrici´on Proba que o xerador de texto en linguaxe natural encargado da n´eboa realiza correctamente a s´ua tarefa. Entrada Valores num´ericos para o estado do ceo: 104, 103, 106, 106, 101, 103, 102, 102, 102, 103, 108 e 108. Resultado esperado Devolve o seguinte texto: There will be morning fog on Saturday and night fog on Friday. Resultado obtido Correcto CP-19 Descrici´on Proba que o xerador de texto en linguaxe natural encargado da temperatura realiza correctamente a s´ua tarefa. Entrada Valores num´ericos para a temperatura: 15, 16, 17, 15, 15, 16, 17 e 15. Resultado esperado Devolve o seguinte texto: Temperature will be very high for this period of the year, with minimums in slight increase although they will oscillate and maximums without changes. Resultado obtido Correcto 84 CAP´ ITULO 7. CONCLUSI ´ ONS estas carec´ıan de importancia tendo en conta os obxectivos do proxecto polo que a valoraci´on final segue sendo positiva. 7.1. Posibles melloras A continuaci´on ind´ıcanse algunhas melloras coas que se poder´ıa ampliar jGALiWeather: 7.1.1. Soporte para outros idiomas Unha das principais vantaxes de utilizar SimpleNLG para desenvolver o m´odulo de xeraci´on de texto ´e que existen varias adaptaci´ons da librar´ıa que dan soporte a outros idiomas coma franc´es ou portugu´es. Estas adaptaci´ons fan que pensar en crear novos m´odulos para xerar textos noutros idiomas sexa algo moi sinxelo. Ademais a isto hai que engadirlle que dispo˜nemos dun dese˜no modular que permite engadir novos m´odulos ´a aplicaci´on de maneira relativamente sinxela. En relaci´on ao anterior, tam´en ser´ıa interesante integrar jGALiWeather no actual servizo dispo˜nible para o publico unha vez estivesen dispo˜nibles recursos similares a SimpleNLG en galego e castel´an. 7.1.2. Adaptaci´on da aplicaci´on coma servizo web Unha mellora interesante ser´ıa o transformar a aplicaci´on nun servizo web que calquera poder´ıa utilizar para xerar os seus progn´osticos persoais enviando os seus propios datos de entrada. Para facer isto necesitariamos modificar a maior´ıa dos operadores ling¨u´ısticos da aplicaci´on xa que agora mesmo est´an moi centrados na utilizaci´on dos datos extra´ıdos de MeteoGalicia, os cales te˜nen un formato, canto menos, curioso. 7.1.3. Predici´ons especializadas Outra posible mellora seria engadir m´odulos que, seguindo unha estratexia similar ´a de jGALiWeather, xerasen predici´ons en linguaxe natural a partir de datos num´ericos dando servizos m´ais especializados, coma poder´ıa ser o estado do mar para mari˜neiros ou surfistas, ou predici´ons con datos de interese para pilotos de avi´ons comerciais. Isto precisar´ıa partir dunha predici´on operativa especializada elaborada previamente. Ap´endice A Manuais de usuario A.1. Requisitos previos A aplicaci´on jGALiWeather trae consigo todas as librar´ıas e dependencias necesarias para a s´ua execuci´on, por lo que en principio non se require ningunha librar´ıa ou programa externo preinstalado, coa excepci´on da maquina virtual de Java. Os sistemas operativos compatibles abarcan desde Windows 7 hasta Windows 10 (soamente foi probada nestes sistemas, a´ında que deber´ıa de ser compatible con calquera sistema operativo cunha maquina virtual de Java). A.2. Instalaci´on A instalaci´on de jGALiWeather realizase a trav´es dun arquivo comprimido que ten no seu interior todos os executables necesarios. 85 86 AP´ ENDICE A. MANUAIS DE USUARIO O ´unico paso necesario ser´ıa descomprimir o arquivo anterior, o que nos devolver´ıa a seguinte estrutura de carpetas: Na carpeta jgaliweather encontramonos o executable da aplicaci´on xeradora de progn´osticos en linguaxe natural xunto cunha carpeta para aloxar os ficheiros de log se non lle especificamos unha diferente. Na carpeta parser encontramonos c´o executable da aplicaci´on que parsea a web de MeteoGalicia para almacenar os datos meteorol´oxicos na base de datos. Na carpeta tomcat encontrase un servidor tomcat con t´odolos recursos necesarios para despregar a interface web. A carpeta Configuration conten t´odolos ficheiros de configuraci´on dos que dependen as aplicaci´ons para o seu correcto funcionamento. A base de datos esta aloxada na carpeta principal. A.3. Configuraci´on Os ficheiros que se encontran no subdirectorio Configuration son os encargados de almacenar a informaci´on de configuraci´on usada polas diferentes aplicaci´ons. Este conxunto de ficheiros permiten configurar o programa en diversos A.4. EXECUCI ´ ON 87 aspectos. Os arquivos variables.xml epartitions.xml conte˜nen informaci´on que define os datos de entrada e as operaci´ons matem´aticas da aplicaci´on e non deben ser modificados baixo ning´un concepto. Do mesmo modo, o arquivo templates.xml conten informaci´on necesaria para a xeraci´on das predici´ons en linguaxe natural e non deben ser editados por norma xeral. O ´unico ficheiro que pode ser editado ´e configuration.xml. Ficheiros de configuraci´on xeral O ficheiro de configuraci´on configuration.xml define unha serie de par´ametros necesarios para a correcta execuci´on da aplicaci´on, que poden ser modificados para configurar as rutas de acceso ao resto de ficheiros de configuraci´on e a conexi´on ´a base de datos. As etiquetas <inpath>definen as rutas aos demais ficheiros de configuraci´on mentres que as etiquetas <database>permiten definir os datos de conexi´on das bases de datos que fagan falta. Por defecto, nada m´ais descomprimir o instalador, a aplicaci´on ´e totalmente operativa polo que non se recomenda nin modificar este ficheiro nin modificar a estrutura de carpetas. A.4. Execuci´on Neste apartado descr´ıbense os detalles de execuci´on das tres aplicaci´ons que integran este proxecto. jGALiWeather: Xerador de predici´ons Esta aplicaci´on admite unha serie de par´ametros de entrada para a s´ua execuci´on, que determinan a ubicaci´on do ficheiro de configuraci´on principal, o directorio de logs, a data da predici´on e se se vai xerar a predici´on para o ICA. Un exemplo do comando de execuci´on de jGALiWeather ser´ıa: java -jar jGALiWeather.jar -noica -date 2016-07-06 -configuration file “ruta” -log directory “ruta” -noica: Bandeira, que no caso de estar presente, non se xerar´ıan as predici´ons do ICA. 88 AP´ ENDICE A. MANUAIS DE USUARIO -date “data”: Indica para que data a aplicaci´on debe xerar as predici´ons. O formato utilizado ´e AAAA-MM-DD. Por defecto se utiliza a data actual. -configuration file: Determina a ruta onde se encontra o ficheiro de configuraci´on principal. -log directory: Indica o directorio onde se gardaran os ficheiros de log (o directorio debe ser creado previamente). -h ou –help: Mostra unha pequena explicaci´on dos diferentes par´ametros. A aplicaci´on pode executarse sen necesidade de utilizar ning´un dos argumentos anteriores dado que disp´on de valores por defecto para o seu correcto funcionamento nese caso. Se todos os datos son correctos a aplicaci´on se executar´a e almacenar´a os textos que conte˜nen as predici´ons meteorol´oxicos na base de datos. Parser MeteoGalicia Esta aplicaci´on ´e unha aplicaci´on autom´atica de consola cuxo ´unico argumento (ademais do par´ametro de axuda similar ao de jGALiWeather) ´e –configuration file que indica a ruta do ficheiro de configuraci´on principal: java -jar parser meteogalicia.jar -configuration file “ruta” No caso de omitir este par´ametro a aplicaci´on utilizar´ıa a ruta por defecto. Interface web Proporcionase un servidor Apache Tomcat totalmente operativo que trae no seu interior a aplicaci´on web de visualizaci´on de datos despregada. Polo tanto con s´o iniciar o servidor xa teremos a interface de visualizaci´on a nosa disposici´on. O servidor iniciase mediante a execuci´on do script catalina start.bat aloxado na carpeta tomcat. No caso de querer deter a execuci´on do servidor utilizariamos o script catalina stop.bat. C´o servidor activo a aplicaci´on estar´a dispo˜nible na URL: http://localhost:8080/web jGALiWeather/ Bibliograf´ıa [1] A. Ramos, A. J. Bugar´ın, S. Barro e F. D´ıaz, GALiWeather: Aplicaci´on para la generaci´on autom´atica de predicciones meteorol´ogicas en lenguaje natural, Manual de usuario registro software (n´umero de asiento registral 03/2014/1259), 2014. [2] A. Ramos, A. J. Bugar´ın, S. Barro e J. Taboada, Linguistic Descriptions for Automatic Generation of Textual ShortTerm Weather Forecasts on Real Prediction Data, IEEE Transactions on fuzzy systems, 23 (1), 4457, 2015. [3] E. Reiter and R. Dale. Building Natural Language Generation Systems. Cambridge University Press, 2000. [4] E. Reiter. An architecture for data-to-text systems. In S. Busemann, editor, Proceedings of the 11th European Workshop on Natural Language Generation, pages 97–104, 2007. [5] D. Woods, Why Big Data Needs Natural Language Generation to Work (http://www.forbes.com/sites/danwoods/2015/07/09/why-big-data-needsnatural-language-generation-to-work). Consultado o 6 de xullo do 2016. [6] A. Gatt, E. Reiter. SimpleNLG: A Realisation Engine for Practical Applications. Proceedings of the 12th European Workshop on Natural Language Generation (ENLG 2009), 9093, 2009. [7] Project Management Institute. Gu´ıa de los Fundamentos de la Direcci´on de Proyectos (Gu´ıa del PMBOK ® ), 3 ª ed., 2004. Dispo˜nible en http://www.fnmt.es/documents/10179/119827/Descargar+Documentaci´on+- +Gesti´on+de+Proyectos/b34b9d76-9e62-4fcb-adbd-a0e5d675b4b4 [8] Instituto Nacional de Tecnolog´ıas de la Comunicaci´on(INTECO). Gu´ıa Pr´actica de Gesti´on de Configuraci´on. 2008. [9] Instituto Nacional de Tecnolog´ıas de la Comunicaci´on(INTECO). Ingenier´ıa del Software: Metodolog´ıas y ciclos de vida. 2009. 89 90 BIBLIOGRAF´ IA [10] H. Kniberg. Scrum and XP from the trenches, 2 ª ed., 2015. Dispo˜nible en http://www.infoq.com/resource/minibooks/scrum-xp-from-thetrenches-2/en/pdf/Scrum-and-XP-from-the-Trenches-2nd-edition.pdf [11] CMMI ® para Desarrollo. Versi´on 1.3, 2010. Dispo˜nible en http://www.sei.cmu.edu. [12] Instituto de Enxe˜neiros El´ectricos e Electr´onicos (IEEE). IEEE Standard 610, 1990. [13] B. Wake, INVEST in Good Stories, and SMART Tasks (http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/). Consultado o 25 de febreiro do 2016. [14] Instituto de Enxe˜neiros El´ectricos e Electr´onicos (IEEE). ISO/IEC/IEEE 42010, 2013. [15] Arquitectura de software. Artigo da wikipedia (https://es.wikipedia.org/wiki/Arquitectura de software). Consultado o 25 de xunio do 2016. [16] ¿Qu´e es un Patr´on de Dise˜no?. MSDN de Microsoft (https://msdn.microsoft.com/es-es/library/bb972240.aspx). Consultado o 25 de xunio del 2016. [17] fuzzy4j - Fuzzy logic library for Java. Dispo˜nible en https://github.com/sorend/fuzzy4j. Consultado o 25 de xunio del 2016. [18] M.I. Dur´an e T. Benito, L´ogica Borrosa, 2009. Dispo˜nible en http://www.it.uc3m.es/jvillena/irc/practicas/08-09/10.pdf. [19] Representational State Transfer. Artigo da wikipedia (https://es.wikipedia.org/wiki/Representational State Transfer). Consultado o 25 de xu˜no do 2016. [20] JUnit. Artigo da wikipedia (https://es.wikipedia.org/wiki/JUnit). Consultado o 25 de xu˜no do 2016. [21] Jersey - RESTful Web Services in Java. Dispo˜nible en https://jersey.java.net/. Consultado o 25 de xu˜no del 2016. [22] jQuery. Dispo˜nible en http://jquery.com/. Consultado o 25 de xu˜no del 2016. [23] I. Sommerville, Ingenier´ıa de software, 9 ª ed., 2012. [24] Gu´ıa Salarial Sector TI Galicia 2015-2016. 2014. Dispo˜nible en http://www.vitaedigital.com/download/NTY2/Guia Salarial Sector TI Galicia 20152016.pdf. Consultado o 25 de xu˜no del 2016.