EOAhKAEI LHAI AJP=?EjJ@AQJ?KJFQC=@KN … · Soporte multipantalla ... 13.Modelo de negocio 81 13.1....

143
Proyecto Fin de Carrera Diseño e implementación de un conjugador verbal como aplicación Android Enero 2016 Autor: Gabriel Yeray Suárez Pérez Tutor: Francisco Javier Carreras Riudavets

Transcript of EOAhKAEI LHAI AJP=?EjJ@AQJ?KJFQC=@KN … · Soporte multipantalla ... 13.Modelo de negocio 81 13.1....

 

  

   

Proyecto Fin de Carrera 

 

Diseño e implementación de un conjugador

verbal como aplicación Android

Enero 2016

Autor: Gabriel Yeray Suárez Pérez

Tutor: Francisco Javier Carreras Riudavets

 

        

 

Agradecimientos

En primer lugar me gustaría agradecer de manera muy especial a mi familia, puessin su apoyo incondicional no habría podido sacar este proyecto adelante.

En segundo lugar, me gustaría agradecer a mi tutor de proyecto, D. Francisco Ca-rreras Riudavets, pues ha sabido guiarme a lo largo de todo el desarrollo de esteproyecto.

Por último, pero no por ello menos importante me gustaría agradecer a mis com-pañeros de carrera Ángel Eliezer Manchón Santana, Luis María González Medina yRubén Domínguez Falcón por acompañarme y ayudarme en esta etapa de mi vida.A los cuales considero ya amigos para toda vida.

i

Índice general

1. Introducción 1

2. Objetivos 3

2.1. Objetivos generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2. Objetivos personales o indirectos . . . . . . . . . . . . . . . . . . . . 4

3. Estado del arte 5

3.1. Competencia en el mercado . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.1. Conjugador Español . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.2. Conjugador de verbos españoles . . . . . . . . . . . . . . . . 7

3.1.3. Verbos españoles . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.4. Conjugador de verbos españoles 2 . . . . . . . . . . . . . . . . 8

3.1.5. Verbos Españoles 2 . . . . . . . . . . . . . . . . . . . . . . . . 9

4. Metodologías de trabajo 11

5. Recursos utilizados 12

5.1. Recursos software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.2. Recursos hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6. Plani�cación temporal 18

ii

7. De�nición del proyecto 20

7.1. Alcance del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7.2. Usuarios �nales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

7.3. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . 22

7.4. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . 23

8. Estudio previo 25

8.1. Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

8.1.1. Historia del sistema operativo Android . . . . . . . . . . . . . 25

8.1.2. Arquitectura de Android . . . . . . . . . . . . . . . . . . . . . 26

8.1.3. Ciclo de vida de una aplicación Android . . . . . . . . . . . . 28

8.1.4. SDK Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8.1.5. Estructura de un proyecto en Android . . . . . . . . . . . . . 31

8.2. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

8.2.1. Uso en el desarrollo en Android . . . . . . . . . . . . . . . . . 34

8.3. Servicio web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

8.3.0.1. REST . . . . . . . . . . . . . . . . . . . . . . . . . . 35

8.3.0.2. SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . 36

9. Análisis 37

9.1. Actor del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

9.2. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . 37

10.Diseño 41

10.1. Diseño arquitectónico . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

10.2. Consultor SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

10.3. Servicio local de notas . . . . . . . . . . . . . . . . . . . . . . . . . . 46

10.4. Procesador de texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

10.4.1. Casos en que se modi�ca la forma verbal . . . . . . . . . . . . 49

10.5. Módulo de almacenamiento . . . . . . . . . . . . . . . . . . . . . . . 50

10.6. Diseño de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

iii

10.6.1. Vistas de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . 52

10.6.2. Adaptación para tabletas . . . . . . . . . . . . . . . . . . . . . 55

10.7. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

11.Implementación 58

11.1. Librerías externas utilizadas . . . . . . . . . . . . . . . . . . . . . . . 58

11.1.1. Librería externa ksoap2 . . . . . . . . . . . . . . . . . . . . . 58

11.1.2. Librería externa ActionBarSherlock . . . . . . . . . . . . . . . 59

11.1.3. Extensiones de esta librería añadidas . . . . . . . . . . . . . . 60

11.2. Desarrollo del Módulo Cosultor SOAP . . . . . . . . . . . . . . . . . 61

11.2.1. Tarea asíncrona . . . . . . . . . . . . . . . . . . . . . . . . . 62

11.2.1.1. Etapas del AsyncTask . . . . . . . . . . . . . . . . . 62

11.3. Desarrollo del servicio local de notas . . . . . . . . . . . . . . . . . . 63

11.4. Desarrollo del módulo de almacenamiento . . . . . . . . . . . . . . . 64

11.5. Implementación del procesador de texto . . . . . . . . . . . . . . . . 67

11.6. Desarrollo de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . 68

11.6.1. Principales componentes de diseño utilizados . . . . . . . . . . 68

11.6.2. Soporte multipantalla . . . . . . . . . . . . . . . . . . . . . . . 73

11.6.3. Tipografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

11.6.4. Animaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

11.6.5. Almacenamiento permanente de datos . . . . . . . . . . . . . 75

11.6.6. Soporte multilenguaje . . . . . . . . . . . . . . . . . . . . . . 76

11.7. Otras funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

11.7.0.1. Sintetizador de voz . . . . . . . . . . . . . . . . . . . 77

11.7.0.2. Compartir . . . . . . . . . . . . . . . . . . . . . . . . 78

11.7.0.3. Copiar . . . . . . . . . . . . . . . . . . . . . . . . . . 79

12.Estimación de costes 80

12.1. Recursos materiales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

12.2. Recursos humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

12.3. Coste total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

iv

13.Modelo de negocio 81

13.1. Marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

13.2. Estimación de ganancias . . . . . . . . . . . . . . . . . . . . . . . . . 82

14.Fase de pruebas 83

14.1. Pruebas de rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . 83

14.2. Pruebas de validación . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

14.3. Pruebas de usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . 84

15.Conclusiones 85

15.1. Conclusiones enfocadas al producto . . . . . . . . . . . . . . . . . . . 85

15.2. Conclusiones personales . . . . . . . . . . . . . . . . . . . . . . . . . 85

15.3. Conclusiones �nales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

16.Trabajos futuros 87

16.1. Ampliaciones del producto . . . . . . . . . . . . . . . . . . . . . . . . 87

16.2. Otras propuestas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

17.Anexo I: Manual de uso 89

18.Anexo II: Comparativa con otras aplicaciones 93

19.Anexo III: Especi�caciones del análisis 98

20.Anexo IV: Diseño de interfaces humanas 123

21.Anexo V: Consecuencia del cambio del diseño arquitectónico 125

Bibliografía 128

v

Índice de �guras

3.1. Icono de la aplicación Conjugador Español . . . . . . . . . . . . . . . 6

3.2. Imágenes del Conjugador Español . . . . . . . . . . . . . . . . . . . . 6

3.3. Icono de la aplicación Conjugador de verbos españoles . . . . . . . . . 7

3.4. Imágenes del Conjugador de verbos españoles . . . . . . . . . . . . . 7

3.5. Icono de la aplicación Verbos españoles . . . . . . . . . . . . . . . . . 7

3.6. Imágenes de Verbos españoles . . . . . . . . . . . . . . . . . . . . . . 8

3.7. Icono de la aplicación Conjugador de verbos españoles 2 . . . . . . . 8

3.8. Imágenes del Conjugador de verbos españoles 2 . . . . . . . . . . . . 9

3.9. Icono de la aplicación Verbos Españoles . . . . . . . . . . . . . . . . . 9

3.10. Imágenes de la aplicación Verbos Españoles . . . . . . . . . . . . . . 10

5.1. Recurso software: IDE Eclipse . . . . . . . . . . . . . . . . . . . . . . 13

5.2. Recurso software: IDE Android Studio . . . . . . . . . . . . . . . . . 13

5.3. Recurso software: Git y GitHub . . . . . . . . . . . . . . . . . . . . . 14

5.4. Recurso software: StarUML . . . . . . . . . . . . . . . . . . . . . . . 14

5.5. Recurso software: Balsamiq Mockups . . . . . . . . . . . . . . . . . . 14

5.6. Recurso software: Inkscape . . . . . . . . . . . . . . . . . . . . . . . . 15

5.7. Recurso software: Trello . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.8. Recurso software: Lyx . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.9. Recurso software: Gmail . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.10. Recurso hardware: Equipo de desarrollo . . . . . . . . . . . . . . . . . 16

5.11. Recurso hardware: Smartphone . . . . . . . . . . . . . . . . . . . . . 17

6.1. Grá�co de la plani�cación temporal . . . . . . . . . . . . . . . . . . . 19

vi

8.1. Arquitectura del S.O. Android . . . . . . . . . . . . . . . . . . . . . . 27

8.2. Ciclo de vida de una aplicación Android . . . . . . . . . . . . . . . . 29

8.3. Imagen del archivo AndroidManifest.xml en Android Studio . . . . . 31

8.5. Imagen del directorio assets en Android Studio . . . . . . . . . . . . . 32

8.4. Imagen directorio java en Android Studio . . . . . . . . . . . . . . . . 32

8.6. Imagen del directorio libs en Android Studio . . . . . . . . . . . . . . 32

8.7. Imagen directorio res en Android Studio . . . . . . . . . . . . . . . . 33

8.8. Imagenes de ejemplo de su�jos . . . . . . . . . . . . . . . . . . . . . . 34

9.1. Diagrama de casos de uso 1 . . . . . . . . . . . . . . . . . . . . . . . 38

9.2. Diagrama de casos de uso 2 . . . . . . . . . . . . . . . . . . . . . . . 39

9.3. Diagrama de casos de uso 3 . . . . . . . . . . . . . . . . . . . . . . . 40

10.1. Diseño arquitectónico . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

10.2. Proceso de las consultas al servicio remoto lematizador . . . . . . . . 44

10.3. Proceso de las consultas al servicio remoto conjugador . . . . . . . . . 45

10.4. Esquema de peticiones para el caso más simple . . . . . . . . . . . . . 45

10.5. Esquema de peticiones para el caso más complejo . . . . . . . . . . . 45

10.6. Diseño: vista principal . . . . . . . . . . . . . . . . . . . . . . . . . . 52

10.7. Diseño: vista panel izquierdo . . . . . . . . . . . . . . . . . . . . . . . 53

10.8. Diseño: vista panel derecho . . . . . . . . . . . . . . . . . . . . . . . . 54

10.9. Diseño: vista de ajustes . . . . . . . . . . . . . . . . . . . . . . . . . . 55

10.10.Vista principal portrait en tableta . . . . . . . . . . . . . . . . . . . . 56

10.11.Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

11.1. Ejemplo de un Action Bar . . . . . . . . . . . . . . . . . . . . . . . . 60

11.2. Ejemplo de Toggle Button combinado con home button . . . . . . . . 60

11.3. Ejemplo de viewPageIndicator . . . . . . . . . . . . . . . . . . . . . . 60

11.4. Clase que de�ne el modulo de consultas SOAP . . . . . . . . . . . . . 61

11.5. De�nición de la clase asíncrona utilizada . . . . . . . . . . . . . . . . 62

11.6. Clases que conformarán este módulo . . . . . . . . . . . . . . . . . . 64

vii

11.7. Clase RegistroInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

11.8. Clase Iden�cadorVerbo, Conjugación y NotasAsociadas . . . . . . . . 66

11.9. Clase procesadora del texto . . . . . . . . . . . . . . . . . . . . . . . 67

11.10.Clases que conforman la construcción del imperativo pronominal . . . 68

11.11.Imagen de Spinner en el ActionBarSherlock . . . . . . . . . . . . . . 69

11.12.Imagen del patrón Fragmet dentro de un ViewPager . . . . . . . . . 70

11.13.Clase del FragmentAdapter y Fragments que se han utilizado . . . . 71

11.14.Imagen del patrón ListView dentro de un FrameLayout . . . . . . . . 72

11.15.Vistas en tabletas portrait y landscape . . . . . . . . . . . . . . . . . 74

17.1. Manual de uso: Vista de la aplicación . . . . . . . . . . . . . . . . . . 89

17.2. Manual de uso: Extracción de información . . . . . . . . . . . . . . . 90

17.3. Manual de uso: Panel derecho . . . . . . . . . . . . . . . . . . . . . . 91

17.4. Manual de uso: Panel izquierdo . . . . . . . . . . . . . . . . . . . . . 92

17.5. Manual de uso: Ajustes . . . . . . . . . . . . . . . . . . . . . . . . . . 92

21.1. Diseño arquitectonico desechado . . . . . . . . . . . . . . . . . . . . . 126

21.2. Grá�co de tiempos obtenidos . . . . . . . . . . . . . . . . . . . . . . 127

viii

ix

Capítulo 1

Introducción

Actualmente, nos encontramos en un periodo de tiempo en el que sin darnos cuen-ta nos hemos visto impulsados hacia el desarrollo de aplicaciones para dispositivosmóviles, donde los usuarios buscan una mayor velocidad, comodidad y tenerlo todoa golpe de dedo.

Es bien sabido por todos que la llegada de los dispositivos móviles ha supuesto elacceso rápido hacia el intercambio de datos e información desde cualquier parte encualquier momento. Pero a pesar de que estamos más conectados, existen limitacionescomo el idioma. Por ello, se han desarrollado multitud de soluciones para facilitarlas cosas y nosotros hemos querido aportar nuestro granito de arena.

Por ese motivo, este proyecto está enfocado al marco de la lengua y procesamientodel lenguaje castellano. Concretamente, se basa en diseñar e implementar una aplica-ción para dispositivos móviles cuyo servicio será el de ofrecer información acerca deun verbo introducido por el usuario. Entre esta información se puede visualizar lasconjugaciones simples, compuestas, indicativo, subjuntivo, imperativo, etc. Ademásde notas acerca de las variantes especiales de las distintos tiempos verbales e infor-mación que identi�ca el tipo de verbo introducido. También se ofrece la posibilidadde elegir entre varios dialectos del habla hispana a la hora de presentar las conjuga-ciones, ya que hay zonas donde varía el tratamiento de las mismas. Además de otrasfuncionalidades que serán mencionadas en contiguos apartados de este documento.

Cabe destacar que el origen de este proyecto parte del grupo de investigación TIP[17](División Text & Information Processing) del Instituto Universitario de Análisis yAplicaciones textuales. Este grupo es artí�ce de una de las bases de datos más com-pletas que existen en lo que a verbos en castellano se re�ere. Sin embargo, ellosconsideraban que no se estaba explotando su�ciente su uso y deseaban buscar alter-nativas para llegar a un mayor número de usuarios, ya que hasta ahora los usuariospodían hacer uso de esta base de datos únicamente mediante su página web.

1

Capítulo 1. Introducción

Por ello, el proyecto se basará parcialmente en el uso de una serie de servicios webSOAP proporcionados por el grupo TIP, los cuales, no solucionan todo el problema.Esto se debe a que es necesario añadir una serie de complementos de forma manuala las formas verbales, ya que son obtenidas de forma indexada pero en solitario.Y antes de ser mostradas necesitaran pasar por proceso que permite añadirle loscomplementos necesarios en cada caso para su perfecta visualización.

Además, sera necesario implementar un sistema de almacenamiento local de notas.Estas indican las peculiaridades de la conjugación del verbo y ha sido necesariaincluirlas localmente debido a que en ocasiones el número de peticiones al servicio delas notas provocaba un tiempo de espera, por parte del usuario, demasiado elevado.

En cuanto al desarrollo, se ha llevado a cabo para dispositivos móviles �Android�.Puesto que se trata de una aplicación destinada al ámbito de la enseñanza y estesistema operativo abarca un mayor número de usuarios a los que irá destinado.

2

Capítulo 2

Objetivos

El presente proyecto supone la creación de una herramienta lingüística destinada parael uso personal de usuarios en proceso de aprendizaje de la lengua española o amantesde ella. Los únicos requisitos para disfrutar de las ventajas y posibilidades que ofrecela aplicación, serían disponer de un dispositivo Android y de una buena conexión aInternet. Dado que existen múltiples herramientas que permiten llevar a cabo estafuncionalidad, nuestra intención es dar un paso más allá. Puesto que además demostrar las formas conjugadas de los verbos permitiremos al usuario interactuar congran parte de los datos visualizados y proporcionamos información adicional referenteal verbo y su conjugación. Con lo que, podemos hablar de dos tipos de objetivos.Aquellos relacionados con la realización del proyecto y los objetivos personales queéste presenta. A continuación se exponen detalladamente los objetivos principalesque se persigue la consecución y desarrollo de este proyecto.

2.1. Objetivos generales

Uno de los puntos fuertes que se pretende alcanzar es el de conseguir una buenainterfaz grá�ca, que consiga una vista atractiva, intuitiva, manejable y simplea la vez. Además la aplicación dispondrá de 2 vistas en función de si se tratade un smartphone o en tabletas en horizontal y en vertical. Esto permitiráal usuario visualizar un número determinado de tiempos verbales en una solavista dependiendo del dispositivo que use. Por supuesto, cuanto mayor sea eldispositivo más información será visible.

Tener acceso a los datos de la forma más rápida y e�ciente posible. Para ello,inicialmente se lleva a cabo una serie de peticiones a varios servicios web SOAP,de los cuales, es propietario el grupo TIP. Estos nos proporcionarán parte dela información de forma estructurada.

3

Capítulo 2. Objetivos

Proporcionar el mayor número de funcionalidades que sea posible, a la hora deusar la información que nos mostraría la aplicación. Puesto que tal y como semencionó anteriormente, los usuarios que van a utilizar la aplicación pueden serde dos tipos de per�les. Usuarios que están aprendiendo el idioma y usuariosamantes de la lingüística castellana. Por tanto, la herramienta deberá ofrecer lasfuncionalidades necesarias para satisfacer los requisitos y exigencias de ambostipos de usuarios.

Otro objetivo sería que el usuario tenga disponible esta aplicación en la tiendade Android, Play Store[13], para mayor número de dispositivos que sea posible.

2.2. Objetivos personales o indirectos

Aprender a desarrollar aplicaciones para dispositivos Android. Debido a que apesar de que usa el lenguaje java no es igual al desarrollo de una aplicaciónjava. Entre otras muchas cosas porque Android nos proporciona sus propiospatrones de diseño y se basan en Actividades como veremos más adelante.

A�anzar conocimientos sobre el lenguaje java, ya que la parte de la implementa-ción de la lógica de la aplicación si será desarrollo en java. Puesto que a lo largode mis estudios en la carrera he usado java, pero ha sido de manera super�cialno tan profunda como Ada, C o C++. Por ello, considero que realizando esteproyecto alcanzaré una mayor profundidad en cuanto a conocimientos sobrejava.

Mejorar mis conocimientos sobre diseño de interfaces humanas. Este aspectoaunque muchos no lo piensen es fundamental para llegar al mayor número deusuarios posibles, ya que se trata de una disciplina relacionada con el estudioy mejora de los factores que in�uyen en la efectividad y e�ciencia del uso delsoftware. De hecho requiere combina técnicas de psicología, ingeniería, diseño,etc.

4

Capítulo 3

Estado del arte

Actualmente la aplicación a desarrollar solo está disponible en soporte web por partedel grupo TIP, donde podemos encontrar un conjugador de verbos que muestra laconjugación simple y compuesta del verbo introducido. Este portal web hace uso devarios servicios web SOAP, los cuales, nos permite tener acceso a una base de datosde más de 14000 verbos previamente conjugados y veri�cados.

Para ver la conjugación de un verbo solo se debe introducir cualquier verbo en cual-quier forma/tiempo. El conjugador también presenta por separado la conjugación deformas en negativo, la conjugación pronominal y la conjugación con el sujeto en fe-menino. Además, incorpora las diferentes conjugaciones, aceptadas por la Asociaciónde Academias de la Lengua Española, correspondientes a distintas zonas geográ�cas,como el �vos� de Río de la Plata, el uso de �ustedes� de Hispanoamérica y Canarias,y el uso de formas de respeto �usted� y �ustedes�.

También se muestran notas sobre la información morfológica y ortográ�ca de todoslos verbos irregulares para ayudar a entender mejor la conjugación por parte dellector. A partir de estas notas se puede obtener el listado de verbos que la cumplen.Igualmente, se muestran otros verbos que siguen el mismo modelo de conjugación,pudiéndose obtener todos los verbos que se conjugan de esa forma. El ConjugadorTIP del portal web incluye un componente más, de cada forma verbal se muestra sufrecuencia de aparición en el Corpus de Referencia del Español Actual (CREA) y lasformas con pronombres enclíticos que aparecen en dicho Corpus.

Partiendo de esta aplicación web, la tarea de este proyecto sería realizar el equivalentepara dispositivos móviles Android en nativo. Para ello, se usará un subgrupo de losservicios web SOAP mencionados que nos permitirán tener acceso parcial a la base dedatos que dispone el grupo TIP. Añadiendo la complejidad de manejar, almacenar yestructurar toda esa información para que sea visible en la pantalla de un smartphoney tableta Android.

5

Capítulo 3. Estado del arte

3.1. Competencia en el mercado

Seguidamente, tras ver cual es la situación actual del sistema pasamos a analizar loque serían nuestros competidores directos, en la propia tienda Play Store. Para ello,hemos seleccionado aquellas aplicaciones gratuitas que supuestamente poseen el mis-mo grupo de usuarios al que va destinada la aplicación que se pretende desarrollar.Como la cantidad de ellas es bastante elevada se han seleccionado las 5 más descar-gadas de la tienda de Google para hacer un pequeño análisis de sus características.

3.1.1. Conjugador Español

Figura 3.1: Icono de la aplicación Conjugador Español

Desarrollador: Cilenis[5]

Descargas: Entre 10.000 - 50.000 instalaciones según Play Store.

Este conjugador de verbos en español para dispositivos Android, en su versión gratui-ta no posee publicidad pero solo permite 5 consultas diarias sobre verbos en españolreconocidos por la Real academia de la Lengua. Además solo permite como entradael verbo en in�nitivo y nos informa de las formas conjugadas simples y compuestas.También, requiere de conexión a Internet y no permite la extracción de la informa-ción visualizada. Su interfaz es simple, poco estructurada, pero intuitiva y agradablea la vista.

Figura 3.2: Imágenes del Conjugador Español

6

Capítulo 3. Estado del arte

3.1.2. Conjugador de verbos españoles

Figura 3.3: Icono de la aplicación Conjugador de verbos españoles

Desarrollador: Feel Good Software[9]

Descargas: Entre 10.000 - 50.000 instalaciones según Play Store

Este conjugador admite la entrada del verbo en cualquier forma salvo re�exiva(pronominal).Su uso no está limitado, pero posee publicidad. La información que obtenemos desalida está compuesta por las formas verbales en tiempos simples y compuestos. Noexiste ninguna forma conocida para extraer la información mostrada. Además re-quiere de conexión a Internet para su uso. También hay que indicar que posee unainterfaz simple, intuitiva, pero poco estructurada y poco atractiva.

Figura 3.4: Imágenes del Conjugador de verbos españoles

3.1.3. Verbos españoles

Figura 3.5: Icono de la aplicación Verbos españoles

Desarrollador: Ian Tipton[15]

7

Capítulo 3. Estado del arte

Descargas: Entre 10.000 - 50.000 instalaciones según Play Store

Este conjugador está limitado a unos 700 verbos y nos restringe a navegar por los700 in�nitivos, agrupados alfabéticamente, para seleccionar al que queremos ver con-jugado. Sin embargo, solo nos muestra, eso sí, muy bien estructurados, los tiemposverbales. Por otra parte, aunque que nos permite seleccionar la forma conjugada,no aparece el menú de acción sobre el mismo. Puede ser que no esté activo en laversión gratuita. Posee publicidad y no requiere conexión a Internet. También poseeuna interfaz agradable, intuitiva y simple.

Figura 3.6: Imágenes de Verbos españoles

3.1.4. Conjugador de verbos españoles 2

Figura 3.7: Icono de la aplicación Conjugador de verbos españoles 2

Desarrollador: CP apps[7]

Descargas: Entre 100.000 - 500.000 instalaciones según Play Store.

Este aplicación nos permite conjugar cualquier tipo de verbo, incluso verbos inven-tados, de forma gratuita sin límites, sin embargo, posee publicidad. No necesita deconexión a Internet para generar las conjugaciones. Pero tiene la desventaja de quela entrada de datos está limitada a introducir verbos en in�nitivo, ya sean en formare�exiva (pronominal) o no. La información que nos muestra está limitada a los tiem-pos verbales simples y compuestos no es posible modi�car ni extraer la información

8

Capítulo 3. Estado del arte

mostrada. Por otra parte, posee una interfaz simple, manejable, pero poco atractiva.Aunque usa colores vivos para resaltar las formas irregulares.

Figura 3.8: Imágenes del Conjugador de verbos españoles 2

3.1.5. Verbos Españoles 2

Figura 3.9: Icono de la aplicación Verbos Españoles

Desarrollador: Appicenter LLC[2]

Descargas: Entre 500.000 - 1.000.000 según Play Store

Esta aplicación es de las más completas. Aunque esta nos restringe a navegar y buscarentre los in�nitivos más comunes que posee para elegir la conjugación del verbo, porello, es algo limitada. Pero tiene la peculiaridad de que requiere de poco espacio,funciona sin Internet, es gratuita y no posee publicidad. Otro de los elementos quela hacen una de las aplicaciones más potentes es que posee una sección de gramáticadonde es posible estudiar las reglas de los verbos regulares. También permite escucharlas formas conjugadas. Sin embargo, carece de una interfaz intuitiva, puesto que loselementos que aparecen en el menú pueden llevar a equívoco. Además de que lainterfaz es poco vistosa, aunque es posible cambiar los colores.

9

Capítulo 3. Estado del arte

Figura 3.10: Imágenes de la aplicación Verbos Españoles

Hay que indicar que en el capítulo 18 puede visualizarse claramente una tabla com-parativa entre estas y la aplicación �nalizada. Donde se tienen en cuenta las carac-terísticas mencionadas y algunos otros para evaluar qué calidad tiene la aplicación adesarrollar.

10

Capítulo 4

Metodologías de trabajo

Ante el desarrollo de un proyecto software es necesario hacer uso de una metodologíade desarrollo que ayude a estructurar, plani�car y controlar todo el proceso. Por ello,el uso de herramientas y técnicas en Ingeniería del Software es muy importante paraalcanzar un mínimo de calidad en la realización y construcción de la aplicación.

El enfoque metodológico que guiará todo el proceso es el modelo basado en pro-totipos, ya que nos permite desarrollar modelos de la aplicación de software quepermiten evaluar la funcionalidad básica de la misma, sin necesidad de incluir todala lógica o características del modelo terminado. El prototipo permite a el tutor,evaluar en forma temprana el producto, e interactuar con el alumno para saber si seestá cumpliendo con las expectativas y las funcionalidades acordadas. Los prototiposno poseen la funcionalidad total del sistema pero sí condensa la idea principal delmismo. Paso a paso crece su funcionalidad y maneja un alto grado de participaciónal tutor. Esta metodología nos permitirá ir añadiendo poco a poco complejidad alproyecto de forma modular.

Cabe destacar, que junto al modelo prototipado, se da por hecho que se aplicará undesarrollo orientado a objetos, así lo obliga el lenguaje de programación utilizadodurante el desarrollo, el cual, modela un sistema como grupo de objetos que inter-actúan entre sí. Esta metodología aporta grandes ventajas como encapsulamiento yla reutilización de clases.

Por otro parte, el lenguaje de modelado que se usará durante el desarrollo del proyectoserá el Lenguaje Uni�cado de Modelado (UML). Este nos permitirá previsualizarlas especi�caciones, la construcción y documentación del sistema. De hecho, ofreceun estándar para describir sistemas, incluyendo aspectos conceptuales tales comoprocesos y funcionalidades, y aspectos concretos como expresiones de lenguajes deprogramación.

11

Capítulo 5

Recursos utilizados

En la realización de proyecto de �n de carrera se han utilizado una serie de herra-mientas hardware y software que serán descritos a continuación.

5.1. Recursos software

A lo largo del desarrollo del proyecto se ha hecho uso de las siguientes herramientas:

Herramientas de desarrollo

Eclipse + SDK android. Eclipse[8] es una plataforma de desarrollo, diseñadapara ser extendida de forma inde�nida. Fue concebida desde sus orígenes paraconvertirse en una plataforma de integración de herramientas de desarrollo. Notiene un lenguaje especí�co, sino que es un IDE genérico. Aunque es bastantepopular entre la comunidad de desarrolladores de lenguaje Java usando el plug-in JDT que viene incluido en la distribución estándar del IDE. Mientras que elSDK de Android, el cual es un kit que se integraría a Eclipse, responde a lassiglas de kit de desarrollo de software de Android. Con él podemos desarrollaraplicaciones y ejecutar un emulador del sistema Android de la versión que sea.Todas las aplicaciones Android se desarrollan en lenguaje Java con este kit.Este se puede encontrar en la web o�cial de desarrolladores Android.

12

Capítulo 5. Recursos utilizados

Figura 5.1: Recurso software: IDE Eclipse

Pero posteriormente se importó el proyecto a Android Studio, ya que estaba destina-do exclusivamente al desarrollo de este tipo de aplicaciones y proporcionaba mayoresfacilidades:

Android Studio[14]. Este es un nuevo entorno de desarrollo integrado para elsistema operativo Android lanzado por Google, diseñado para ofrecer nuevasherramientas para el desarrollo de aplicaciones y alternativa al entorno Eclipse,hasta ahora el IDE más utilizado. En este la estructura de los proyectos aparececon casi todos los archivos dentro del directorio SRC, un cambio a un siste-ma de generación basado en Gradle que proporciona una mayor �exibilidadpara el proceso de construcción. Además, gracias a su sistema de emulaciónintegrado, Android Studio, permite ver los cambios que realizamos en nuestraaplicación en tiempo real, pudiendo además comprobar cómo se visualiza endiferentes dispositivos Android con distintas con�guraciones y resoluciones deforma simultánea. Entre otras muchas características.

Figura 5.2: Recurso software: IDE Android Studio

Sistema de control de versiones

Git[26]: Software de control de versiones pensado en la e�ciencia y la con�a-bilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen ungran número de archivos de código fuente. Para facilitar su uso se ha utilizadotambíen un entorno grá�co llamado, GitHub[10], el cuál, es una plataforma dedesarrollo colaborativo para alojar proyectos utilizando el sistama de controlde versiones Git.

13

Capítulo 5. Recursos utilizados

Figura 5.3: Recurso software: Git y GitHub

Herramientas de diseño

StarUML[22]: Herramienta para el modelado de software basado en los están-dares UML (lenguaje de modelado uni�cado) y MDA (arquitectura dirigida pormodelos). Dispone de una serie de módulos para tener funcionalidad añadida,aunque su funcionalidad básica es muy completa. Inicialmente fue un proyectocomercial, pero en 2005 paso a ser una licencia abierta GNU/GPL.

Figura 5.4: Recurso software: StarUML

Balsamiq Mockups[3]: Herramienta para hacer borradores rápidos de interfa-ces de aplicaciones webs o aplicaciones móviles. Se trata de una herramientasencilla, intuitiva y util para dar forma a las ideas sin complicarse la vida enlos detallas. Solo posee el inconveniente de que no es gratuita y, por ello, suuso ha estado limitado a 30 dias. Que es lo que dura el periodo de prueba.

Figura 5.5: Recurso software: Balsamiq Mockups

Herramienta de creación de imágenes Inkscape[16]. Es un editor de grá�cos vec-toriales en formato SVG, gratuito, libre y multiplataforma. Las característicasde SVG soportadas incluyen formas básicas, trayectorias, texto, canal alfa,transformaciones, gradientes edición de nodos, exportación de SVG a PNG,agrupación de elementos, etc. Su objetivo es proporcionar a los usuarios unaherramienta libre con capacidades similares a Illustrator, CorelDraw, etc. Laprincipal ventaja de usar un editor de grá�cos vectoriales frente a un editor

14

Capítulo 5. Recursos utilizados

de grá�cos en mapa de bits es que permite que la imagen pueda ampliarsesin perder calidad. Permitiendo moverse o estirarse de manera simple y sindistorsión.

Figura 5.6: Recurso software: Inkscape

Herramienta de organización y plani�cación

Trello[27] es una herramienta colaborativa de gestión de tareas. Permite ver enque estas trabajando, que está realizando el resto y en qué parte del procesoestas. Se usa en el desarrollo de proyectos propios o grupales. Se basa en lametodología Kanban. Trello es un tablero que está distribuido por columnas,que se llaman listas. Cada lista se compone de tarjetas, tareas o instancias.Cada tarjeta representa la unidad básica de una lista.

Figura 5.7: Recurso software: Trello

Otras herramientas

Herramienta de escritura de este documento Lyx[25]. Es un programa grá�comultiplataforma que permite la edición de texto usando LATEX, por lo quehereda todas sus capacidades. Realmente, se trata de un procesador de textosen el que el usuario no necesita pensar en el formato �nal de su trabajo, sinosólo en el contenido y su estructura. Por lo que puede ser utilizado para editardocumentos grandes o con formato riguroso con facilidad.

Figura 5.8: Recurso software: Lyx

15

Capítulo 5. Recursos utilizados

Medio de comunicación con el tutor/es Gmail[12]. Servicio de correo electró-nico con posibilidades POP3 e IMap gratuito proporcionado por la empresaestadounidense Google. Este ha captado la atención de los medios de informa-ción por sus innovaciones tecnológicas. Actualmente ofrece una capacidad de15GB. La capacidad de almacenamiento aumentó con motivo del lanzamientode Google Drive, aunque posteriormente, se uni�có el espacio disponible parasu uso con Drive, Google+ y Gmail.

Figura 5.9: Recurso software: Gmail

5.2. Recursos hardware

Los recursos hardware para la realización de este proyecto son muy básicos dado queno se requiere de un hardware especí�co. Por esta razón se ha utilizado el hardwarecon el que el alumno contaba. A continuación se detallan los recursos:

Nombre del sistema: SONY VAIO VPCCA1S1E

CPU: Intel(R) Core(TM) i5-2410M 2.30GHz 2.30 GHz

Grá�ca: AMD Radeon HD 7400M Series

RAM: 4 GB

Disco duro: 320GB SATA 2.5�

Figura 5.10: Recurso hardware: Equipo de desarrollo

16

Capítulo 5. Recursos utilizados

Por otra parte, se ha hecho uso de otros dispositivos, los cuales no eran indispensables,pero sí bastante útiles para hacer pruebas en dispositivos reales de la aplicaciónimplementada. Estos han sido los que se han utilizado.

Smartphone Nombre: Bq E4.5

CPU: Quad Core Cortex A7 hasta 1.3GHz MediaTek

Resolución de pantalla: qHD 540x960 - 240 ppi

RAM: 1 GB

Memoria interna: 8 GB

Figura 5.11: Recurso hardware: Smartphone

Se han usado otros dispositivos pero con menos grado de uso, ya que era menosfrecuente tenerlos a disposición.

17

Capítulo 6

Plani�cación temporal

En este apartado se intenta dejar constancia de la plani�cación que inicialmentetendrá este proyecto. Como se puede ver los tiempos de desarrollo están mostrado demanera porcentual, ya que es muy difícil indicar un tiempo exacto para cada tareaal tratarse de una metodología basada en prototipos.

Recopilación de información y aprendizaje sobre herramientas de desarrollo Android(8.6%):

Estudio del diseño de interfaces humanas

Estudio del SDK de Android

Pruebas de acercamiento a Android

Plani�cación (4.9%)

De�nición de requisitos funcionales.

De�nición de requisitos no funcionales.

Establecer los plazos de entrega de las tareas.

Análisis y diseño (24.7%)

Diseño de los casos de uso

De�nición de clases

De�nición de la interfaz de la aplicación

18

Capítulo 6. Plani�cación temporal

Implementación (37%)

Implementación de las interfaces

Conexión de la aplicación con el servicio web

Desarrollo de procesador de la información

Desarrollo del servicio local de notas.

Validación (12.3%)

De�nición de pruebas

Aplicación de pruebas.

Análisis de resultados.

Corrección de errores.

Documentación (12.3%)

Documentación �nal del proyecto

Realización del manual de uso

En el siguiente grá�co se muestra en resumidas cuentas la plani�cación temporal quesupone el proyecto. Con un total de 860 horas.

Figura 6.1: Grá�co de la plani�cación temporal

19

Capítulo 7

De�nición del proyecto

Antes de entrar en materia sobre el desarrollo del proyecto es importante aclararciertos aspectos de la aplicación a implementar, como su alcance y los objetivosprincipales que se buscan. De esta forma, conviene aclarar el ámbito al que va des-tinado y los tipos de usuarios a los que va destinada la aplicación.

7.1. Alcance del sistema

Con este proyecto se pretende desarrollar una aplicación para dispositivos Androidque mediante una interfaz agradable, intuitiva y sencilla el usuario pueda aprendersobre las conjugaciones de los verbos en el lenguaje castellano. Con independencia deque sean usuarios de smartphone o tableta. Para ello, es necesario implementar unabuena interfaz además de una serie de módulos internos. A continuación se detallade forma resumida el funcionamiento interno de la aplicación.

Por un lado, el sistema debe acceder a dos servicios web a través de consultas SOAP.De las cuales, se obtendrán el identi�cador o identi�cadores del verbo e informaciónacerca del verbo introducido del primer servicio web y las formas conjugadas ademásdel tipo de verbo para todos los tiempos simples del segundo servicio.

Servicio web SOAP 1: Reconocedor

Entrada

(1) Verbo

20

Capítulo 7. De�nición del proyecto

Salida

(1) Entre 1 y 3 identi�cadores del verbo(2) Entre 1 y 3 formas canónicas del verbo (verbo en in�nitivo)(3) Varios identi�cadores de persona, número y tiempo.(4) Pronombre enclítico si lo tiene. Por cada identifcador (3)

Servicio web SOAP 2: Conjugador

Entrada

(1) Identi�cador del verbo(2) Inicial de la forma canónica (verbo en in�nitivo)

Salida

(1) Alrededor de 200 formas verbales(2) Frecuencia del CREA que le corresponde a cada forma verbal(3) Entre 3 valores que indican el tipo de verbo

Hay que indicar también que antes de ser mostrada la información proporcionada porel servicio Conjugador. Esta debe ser procesada puesto que el servicio encargado delas formas verbales solo nos proporcionan los verbos sin ningún tipo de complemento.

forma verbal

Y mediante el procesamiento previo a la visualización se le añadirá, algunos compo-nentes más en función de una serie de condiciones establecidas por las característicasdel verbo y las opciones elegidas por el usuario en la interfaz.

pronombre personal + [negación] + [pronombre re�exivo] + [verbo auxiliar] +forma verbal + [frecuencia del CREA]

Este procesamiento previo a la visualización tiene muchas consideraciones a teneren cuenta para cada uno de los componentes que es posible añadir, pero esto, seespeci�cará más adelante.

Por otro lado, el sistema dispondrá de un modulo local basado en estructuras inde-xadas donde se almacenarán las notas asociadas a las conjugaciones de los verbos.Estás notas ayudan al usuario a conocer determinadas reglas a lo hora de conjugarun verbo, identi�can en que posibles formas (persona, número y tiempo) se ha intro-ducido el verbo y nos indican de que tipo de verbo se trata, además de mostrarnosalgunos ejemplos de verbos que se conjugan igual. A esta información inicialmentese accedía de forma remota, pero por problemas de tiempo de espera, por la grancantidad de peticiones, se extrajo en forma de �cheros de texto y se incluirá en la

21

Capítulo 7. De�nición del proyecto

lógica en la aplicación. Por tanto, este módulo se basará en la lectura de estos �che-ros y almacenamiento en estructuras dinámicas que nos faciliten su búsqueda. Paraello, disponemos de un �chero para las de�niciones, dos para las notas y uno para lapersona/número de la forma introducida por el usuario. La elección de las notas sebasan en los identi�cadores proporcionados por el primer servicio web SOAP.

Por lo tanto, cada vez que se realice una petición de un verbo en la aplicación porparte del usuario se llevará a cabo como mínimo 2 peticiones remotas a los serviciosmencionados y varias peticiones locales en función del número de notas que tengaasociado la conjugación del verbo. Y todo ello, deberá ser almacenado en un modulode almacenamiento puesto que el usuario tendrá la posibilidad de variar entre lasposibles conjugaciones de un mismo verbo.

Con todo esto, conseguimos que el usuario tenga visible la conjugación del verbo in-troducido y notas relacionadas con la conjugación actualmente elegida, ya que existela posibilidad de que un verbo posea múltiples conjugaciones. Además se imple-mentará la interacción con las formas verbales o el tiempo verbal completo para suextracción. Ésta podrá ser mediante la escucha del texto, la copia en el portapapeleso la compartición.

Pero para mostrar toda esta gran cantidad de información será necesario estructurar-la sabiendo que cantidad mostrar en cada uno de los 2 tipos de dispositivos y conocerlas limitaciones que posee cada una de ellas, diseñando así una interfaz acorde a estasrestricciones.

7.2. Usuarios �nales

Puesto que la aplicación resultante se asocia al ámbito lingüístico español, cualquierusuario interesado en el aprendizaje del idioma español, sea estudiante de lenguacastellana o simplemente sea un amante de esta podrá disfrutar de las funcionalidadesque la aplicación ofrece. Para hacer uso de la aplicación no existe ningún requisitoindispensable, basta con tener interés por aprender acerca de las conjugaciones delos verbos en español.

7.3. Requisitos funcionales

El desarrollo de la aplicación deberá cumplir una serie de requisitos y ofrecer ciertasfuncionalidades y opciones a los usuarios para que puedan hacer uso de la forma máscómoda posible de la aplicación. A continuación se pueden ver cuáles serían estasfuncionalidades que debe presentar.

22

Capítulo 7. De�nición del proyecto

Funcionalidad visuales

Permitir la entrada de un verbo mediante teclado.

Dar posibilidad a la elección de la conjugación cuando un verbo posee más deuna forma de conjugar.

Acceso a la visualización de las formas verbales, ya sean formas simples, com-puestas o no personales.

Acceso a la visualización de la persona, número y tiempo del verbo así como alas de�niciones, tipo y notas defectivas, morfológicas, ortográ�cas, de participioirregular y de uso relacionadas con las formas verbales para cada conjugación.

Manipulación cerrada de la formas verbales, entendiéndose como ver las formasverbales en femenino, en negado o en uno de los 4 dialectos disponibles, segúncrea oportuno el usuario.

Visualización si el usuario lo cree oportuno de la frecuencia del crea, que es lafrecuencia de aparición en el Corpus de Referencia del Español Actual (CREA).

Acceso a ajustes de idioma e información acerca del grupo TIP.

Proporcionar una interfaz acorde a un smartphone y dos para tableta, una envertical y otra en apaisado

Funcionalidad de extracción

Reproducción sonora de la forma verbal sea cual sea su estado, haya sido ma-nipulada o no.

Reproducción sonora del tiempo verbal completo sea cual sea su estado.

Extracción de la información mediante copia. Extracción de información me-diante la acción compartir.

7.4. Requisitos no funcionales

Los requisitos no funcionales se complementan con los citados previamente y seenfocan en el diseño o la implementación de la aplicación.

Rendimiento

23

Capítulo 7. De�nición del proyecto

Los problemas de latencia en respuesta a una solicitud de información debenestar dentro de un margen aceptable para el uso �uido de la aplicación.

Igualmente, estos problemas de latencia en respuesta no deben permitir que laaplicación quede bloqueada.

Implantación

El sistema debe garantizar la sincronización al reproducir una forma verbal oun tiempo verbal.

El sistema debe permitir la extracción de parte de la información solicitada ala aplicación, ya sea para enviarla o hacer una copia de ella.

Disponibilidad

El sistema debe estar disponible las 24 horas del día y desde cualquier partedel mundo.

Para hacer uso de la aplicación, basta que el usuario disponga de conexión aInternet.

El sistema presentará disponibilidad para su acceso desde smartphones y ta-bletas Android.

24

Capítulo 8

Estudio previo

8.1. Android

Android es un sistema operativo para el que trabajaremos a lo largo de todo elproyecto y que está destinado a dispositivos móviles basada en un kernel de Linux,desarrollada por Google y más tarde por la Open Handset Alliance. Este sistemaoperativo dispone de un kit de desarrollo que permite a los desarrolladores escribircódigo en Java que se ejecuten en dispositivos mediante las librerías Java desarro-lladas por Google. También se pueden implementar aplicaciones en otros lenguajes,como puede ser C, para posteriormente ser compilada en código nativo y ejecutarlas.

8.1.1. Historia del sistema operativo Android

Muchos creen que Android es un Sistema Operativo relativamente nuevo, sin embar-go, su existencia data del 2005 cuando era propiedad de Android Inc. La cual, enAgosto de ese mismo año fue comprada por Google.

Posteriormente, Google estuvo trabajando en este nuevo sistema operativo y no fuehasta �nales de 2007 cuando se anunció o�cialmente Android a los medios. Finalmen-te, la primera versión 1.0 Apple Pie fue lanzada en 2008 e incluía la primera versiónde Android Market, navegador web y soporte para mensajes de texto, discador pa-ra llamadas y una aplicación para tomar fotos sin ajustes de blancos y resolución.También incluyeron algunas aplicaciones para dar soporte a los servicios de Googlemás populares como Google Maps, Google Talk, etc. Por otro lado, se incluyó unaaplicación capaz de acceder a los servidores de correo de terceros para estándaresPOP3, IMAP4 y SMTP.14 que era capaz de sincronizarse con Gmail Google y Ca-lendar. Tampoco faltó el reproductor de archivos multimedia que por entonces era

25

Capítulo 8. Estudio previo

incapaz de reproducir vídeo. Hay que indicar que ofrecía desde sus inicios el soportepara wi� y bluetooth.

A lo largo de los años la evolución del sistema ha sido rápido debido a la gran de-manda que le ha sido solicitada. Pasando por el Android 2.2 Froyo que fue la versióndel sistema operativo que se consagró como competencia de iOS 4 de Apple. Poste-riormente, con la llegada de Android 3.0 HoneyComb se intentó desdoblar el sistemaoperativo para Tablets añadiendo a este su propio SDK independiente, algo que ten-dría poca vida debido al alto coste que supone mantener 2 plataformas separadas.Más tarde, apareció Android 4.0 Ice Cream Sandwich que signi�có una importanteevolución de Android, ya que volvió a integrar el sistema operativo en sus versionespara Tablets y Smartphones. Además de renovar casi por completo su interfaz deusuario con el nuevo diseño Holo. Tras esto, apareció Android 4.4 Kit Kat, el cual,añadió algunas novedades como el mayor protagonismo de Google Now, mejora en lagestión de archivos y nos permite usar impresoras desde nuestro dispositivo, añademensajería uni�cada y multitarea. Además del modo inmersivo y el podómetro entreotras cosas.

Como se ha visto con el paso de los años han salido distintas versiones cada unamejorando la anterior como es normal, llegando al punto en el que nos encontramosactualmente. Android 5.0 Lollipop donde todos los aspectos del sistemas han sidodepurados y mejorados. Proponiendo una interfaz simple y muy �uida, donde loimportante es la información. Añade las noti�caciones en la pantalla de bloqueo ypodemos ver el tiempo restante de batería. En cuanto a seguridad, contamos concifrado automático lo que mejora la protección de nuestros datos en caso de robo opérdida del dispositivo. Es multiusuario, con lo que podemos crear varios usuarios,etc

Con esto se ha intentado dar un pequeño repaso por las versiones de android másrelevantes a lo largo de su evolución. Para así ver a grosso modo los evolución de losdistintos aspectos del sistema operativo para el que se ha desarrollado la aplicación.

8.1.2. Arquitectura de Android

En esta sección se pretende dejar claro los elementos que componen la arquitecturade Android. Para ello, a continuación se describirán los grupos que conforman estaarquitectura.

26

Capítulo 8. Estudio previo

Figura 8.1: Arquitectura del S.O. Android

Aplicaciones: Este nivel está formado por el conjunto de aplicaciones instala-das en una máquina Android. Todas las aplicaciones han de ejecutarse en lamáquina virtual Dalvik para garantizar la seguridad del sistema. Normalmentelas aplicaciones Android están escritas en Java. Para desarrollar aplicaciones enJava podemos utilizar el Android SDK. Existe otra opción consistente en desa-rrollar las aplicaciones C/C++. Para esta opción podemos utilizar el AndroidNDK(Native Development Kit).

Entorno de aplicación: Proporciona una plataforma de desarrollo libre paraaplicaciones con gran riqueza e innovaciones (sensores, localización, servicios,barra de noti�caciones, etc.). Esta capa ha sido diseñada para simpli�car lareutilización de componentes. Las aplicaciones pueden publicar sus capacidadesy otras pueden hacer uso de ellas (sujetas a las restricciones de seguridad). Estemecanismo permite a los usuarios reemplazar componentes. Los servicios másimportantes que incluye son:

� Views: extenso conjunto de vistas, parte visual de los componentes.

� Resoursce Manager: proporciona acceso a recursos que no son en código

� Activity Manager: maneja el ciclo de vida de las aplicaciones y proporcionaun sistema de navegación entre ellas.

� Noti�cation Manager: permite a las aplicaciones mostrar alertas persona-lizadas en la barra de estado.

� Content Provider: mecanismo sencillo para acceder a datos de otras apli-caciones (como los contactos).

27

Capítulo 8. Estudio previo

Librerías: Android incluye un grupo de librerías C/C++ usadas por varioscomponentes del sistema. Estan compiladas en código nativo del procesador.Muchas de las librerías utilizan proyectos de código abierto. Algunas son: Sys-tem C library (implementan librería C estandar), librerías de medios, libreríasde grá�cos, 3d, SQlite, SSL, entre otras.

Runtime de Android: Está basado en el concepto de máquina virtual utilizadoen Java. Dado las limitaciones de los dispositivos donde ha de correr Android(poca memoria y procesador limitado) no fue posible utilizar una máquinavirtual estándar. Por ello, Google creo una nueva maquina virtual llamadaDalvik que respondiera mejor a estas limitaciones. Esta ejecuta �cheros Dalvikejecutables (.dex), formato optimizado para ahorrar memoria. Además estabasada en registros. Cada aplicación corre en su propio proceso Linux con supropia instancia de la maquina Dalvik. Sin embargo, a partir de Android 5.0se reemplaza Dalvik por ART. Esta nueva máquina virtual consigue reducir eltiempo de ejecución del código Java hasta un 33%.

Núcleo-Linux: Android depende de una versión de Linux 2.6 para los serviciosbásicos del sistema como seguridad, gestión de memoria, gestión de procesos,pila de red y modelo de drivers. El núcleo también actúa como una capa deabstracción entre el hardware y el resto de la pila.

8.1.3. Ciclo de vida de una aplicación Android

Una aplicación en Android va a estar formada por un conjunto de elementos básicosde interacción con el usuario conocidos como �Activities� (Actividades). Son estoslos que realmente controlan el ciclo de vida [11] de las aplicaciones, dado que elusuario no cambia de aplicación, sino de actividad. El sistema va a mantener unapila con los �Activities� previamente visualizados, de forma que el usuario va a poderregresar a la actividad anterior al retornar.

Una aplicación Android corre dentro de su propio proceso. Este es creado con laaplicación y continúa vivo hasta que ya no sea requerido y el sistema reclame sumemoria para asignarla a otra aplicación.

Una característica importante, y poco usual, de Android es que la destrucción de unproceso no es controlado directamente por la aplicación. En realidad es el sistemaquien determina cuando destruir el proceso, basándose en el conocimiento que tieneel sistema de las partes de la aplicación que están trabajando, qué tan importantesson para el usuario y cuanta memoria disponible hay en un determinado momento.

Si tras eliminar el proceso de una aplicación, el usuario vuelve a ella, se crea de nuevoel proceso, pero se habrá perdido el estado que tenía esta aplicación. En estos casos,

28

Capítulo 8. Estudio previo

va a ser responsabilidad del programador almacenar el estado de los �Activities�, siqueremos que cuando sea reiniciada conserve el estado.

Como se puede ver, Android es sensible al ciclo de vida de una actividad, por lotanto, es necesario comprender y manejar los eventos relacionados con el ciclo devida si se quiere crear aplicaciones estables.

Activa (Running): La actividad está encima de la pila, lo que quiere decir quees visible y tiene el foco.

Visible (Paused): La actividad es visible pero no tiene el foco. Se alcanza esteestado cuando pasa a activa otra actividad con alguna parte transparente o queno ocupa toda la pantalla. Cuando una actividad está tapada por completo,pasa a estar parada.

Parada (Stopped): Cuando la actividad no es visible. El programador debeguardar el estado de la interfaz de usuario, preferencias, etc.

Destruida (Destroyed): Cuando la actividad termina al invocarse el método�nish(), o es matada por el sistema.

Cada vez que una actividad cambia de estado se van a generar eventos que podránser capturados por ciertos métodos de la actividad. Seguidamente se muestra unesquema que muestra los métodos que capturan estos eventos.

Figura 8.2: Ciclo de vida de una aplicación Android

29

Capítulo 8. Estudio previo

onCreate (Bundle): Se llama en la creación del �Activity�. Se utiliza pararealizar todo tipo de inicializaciones, como la creación de la interfaz de usuarioo la inicialización de estructuras de datos. Puede recibir información de estadode la actividad (en una instancia de la clase Bundle), por si se reanuda desdeuna actividad que ha sido destruida y vuelta a crear.

onStart(): Nos indica que la actividad está a punto de ser mostrada al usuario.

onResume(): Se llama cuando la actividad va a comenzar a interactuar con elusuario.

onPause(): Indica que la actividad está a punto de ser lanzada a segundo plano,normalmente porque otra actividad es lanzada. Es el lugar adecuado para al-macenar los datos que estaban en edición.

onStop(): La actividad ya no va a ser visible para el usuario. Pero si hay muypoca memoria disponible, es posible que la actividad se destruya sin llamar aeste método.

onRestart(): Indica que la actividad va a volver a ser representada después dehaber pasado por onStop().

onDestroy(): Se llama antes de que la actividad sea totalmente destruida. Perosi hay muy poca memoria disponible, es posible que la actividad se destruyasin llamar a este método.

En resumidas cuentas, el ciclo de vida de una aplicación Android es bastante diferentedel ciclo de vida de una aplicación en otros Sistema Operativo. La mayor diferencia,es que en Android el ciclo de vida es controlado principalmente por el sistema. Enlugar de estar controlado por el usuario.

8.1.4. SDK Android

El mercado de las apps se encuentra en su momento más álgido. Lo cual, llevaa que los medios para el desarrollo de estas se encuentran también en continuaevolución. Inicialmente Google puso a disposición de los desarrolladores únicamenteel paquete de software Android SDK, el cual, incorporaba, y los sigue haciendo, todaslas herramientas para el desarrollo de aplicaciones en Android. En él se incluyenconversor de código, debugger, librerías, emulador, documentación, etc. Todas estasherramientas se han ido ampliando y son accesibles desde línea de comandos. Sinembargo, la mayoría de desarrolladores utiliza un entorno de desarrollo integrado(IDE) que incorpora un editor de texto con todas las herramientas de desarrollo.

30

Capítulo 8. Estudio previo

Aunque no eran las únicas alternativas, Eclipse e intelliJ Idea, eran y son las másrecomendadas.

Posteriormente, en la edición Google I/O 2013 se lanzó una preview de AndroidStudio. Este es un nuevo entorno de desarrollo para Android basado en IntelliJ IDEA.El cual incorpora nuevas características que no han sido incluidas en el tradicionalIDE basado en Eclipse. Actualmente Android Studio ya posee una versión establelo cual lo ha convertido en la mejor opción para el desarrollo de aplicaciones paradispositivos Android. Puesto que solo necesitas tener instalado la máquina virtualde java y este IDE para programar. Evitándose así los engorrosos pasos de inclusióndel SDK Android y demás en otros entornos(IDE) que no los incorporan.

Por otro lado, la evolución en el desarrollo no solo ha afectado en los entornos deprogramación, ya que que muchas de las librerías externas para el desarrollo de de-terminados elementos utilizadas hace 6 meses o un año han sido sustituidas por otrasañadidas en el paquete de desarrollo de Android que llevan a cabo la misma tareapero se usan de otra forma. Debido a esto, el uso de librerías externas podría suponerun problema en dispositivos que dispongan de futuras versiones de SO Android yaque cabe la posibilidad de que no den soporte a las misma.

8.1.5. Estructura de un proyecto en Android

Para crear un proyecto android solo es necesario saber el nombre que vamos a ponerleal proyecto, el nombre del paquete principal donde se aloja el archivo principal,MainActivity.java y la API de Android desde la que vamos a partir. Pero me gustaríaañadir que sea cual sea la interfaz de desarrollo elegida para la implementación deuna aplicación Android, todo proyecto se constituye de las siguientes elementos atener en cuenta:

Fichero AndroidManifest.xml. Este archivo contiene la de�nición XML de losaspectos de control principales de la aplicación, como por ejemplo su identi-�cación (nombre, versión, icono, ... ), sus componentes (pantallas(activities),mensajes, ...), las librerías auxiliares utilizadas, o los permisos necesarios parasu ejecución (acceso a internet, etc).

Figura 8.3: Imagen del archivo AndroidManifest.xml en Android Studio

31

Capítulo 8. Estudio previo

Figura 8.5: Imagen del directorio assets en Android Studio

Directorio src o java. Esta carpeta contendrá todo el código fuente de la apli-cación, código de la interfaz grá�ca, clases auxiliares, etc. Normalmente el IDEcreará el código básico de la pantalla principal de la aplicación, que suele serMainActivity.java, y se añade bajo la estructura del paquete java de�nido pre-viamente.

Figura 8.4: Imagen directorio java en Android Studio

Directorio assets. Contiene �cheros auxiliares necesarios para la aplicación,como por ejemplo �cheros de con�guración, de datos, tipografías, etc.

Directorio libs. Este directorio contiene las librerías externas auxiliares, nor-malmente en formato �.jar� que utilicemos en nuestra aplicación Android.

Figura 8.6: Imagen del directorio libs en Android Studio

32

Capítulo 8. Estudio previo

Directorio res. Contiene todos los �cheros de recursos necesarios para el pro-yecto la mayor parte de�nidos en lenguaje XML: cadenas de texto, colores,imágenes, componentes, etc. Los diferentes tipos de recursos se distribuyenentre las algunas de las siguientes subcarpetas.

Figura 8.7: Imagen directorio res en Android Studio

� Directorio drawable. Contiene imágenes y otros elementos grá�cos usadosen por la aplicación. Para de�nir diferentes recursos dependiendo de laresolución y densidad de la pantalla del dispositivo se suele dividir envarias subcarpetas por defecto.

� Directorio layout. Contiene los �cheros de de�nición XML de las dife-rentes pantallas de la interfaz grá�ca. Cabe destacar el layout �acti-vity_main.xml�, generado normalmente por defecto y que contiene lade�nición de la interfaz grá�ca estática de la pantalla principal de la apli-cación.

� Directorio menu. Contiene la de�nición XML de los menús de la aplica-ción.

� Directorio values. Contiene otros �cheros XML de recursos de la aplica-ción, como por ejemplo cadenas de texto (strings.xml), estilos (styles.xml),colores (colors.xml), arrays de valores (arrays.xml),etc.

Hay que destacar que existen algunas carpetas en cuyo nombre se incluye unsu�jo adicional, como por ejemplo �values-v11� y �values-v14�. Estos su�jos seemplean para de�nir recursos independientes para determinados dispositivossegún sus características. De esta forma, los recursos incluidos en la carpeta�values-v11� se aplicarán tan solo a dispositivos cuya versión de Android sea la3.0 (API 11) o superior. Al igual que el su�jo �-v� existen muchos para referirsea otras características del terminal. Algunos de los su�jos que serán usados son:

Orientación. Por ejemplo, para de�nir distintos layouts dependiendo de la orien-tación del dispositivo se puede dividir en dos subcarpetas. layout layout-port(pantalla en vertical) o layout-land (pantlla en horizontal)

33

Capítulo 8. Estudio previo

Tamaño de la pantalla. Por ejemplo, para de�nir distintos layouts dependiendodel tamaño de la pantalla y de su posición del dispositivo se divide en subcar-petas:

� layout-small (pantallas pequeñas)

� layout-large (tabletas de 7�)

� layout-xlarge (tabletas de 10�)

� layout-large-land (tabletas de 7� en posicion landscape)

Figura 8.8: Imagenes de ejemplo de su�jos

8.2. XML

Dentro de la implementación en Android usaremos la tecnología XML, siglas en inglésde eXtensible Markup Language (Lenguaje de marcas ampliable), es un metalenguajeextensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). Esuna simpli�cación y adaptación del SGML y permite de�nir la gramática de lenguajesespecí�cos (de la misma manera que HTML es a su vez un lenguaje de�nido porSGML). Por lo tanto XML no es realmente un lenguaje en particular, sino unamanera de de�nir lenguajes para diferentes necesidades.

XML no se usa sólo para aplicación en Internet, sino que es un estándar para elintercambio de información estructurada entre diferentes plataformas. Se puede usaren bases de datos, editores de texto, hojas de cálculo y casi cualquier cosa imaginable.Tiene un papel muy importante en la actualidad ya que permite la compatibilidadentre sistemas para compartir la información de una manera segura, �able y fácil.

8.2.1. Uso en el desarrollo en Android

En este caso, XML es esencial a la hora de diseñar la interfaz de usuario, ya que elSDK de Android o sus IDEs permiten hacerlo tanto por código Java como por �cherosXML. Dado que la primera manera puede llegar a ser muy compleja y confusa, esrecomendable usar �cheros XML para esta tarea. De hecho, Android de�ne un grannúmero de elementos personalizados, cada uno representando una subclase de View,clase madre de todos los objetos visuales. Por ejemplo, para de�nir una pantalla se

34

Capítulo 8. Estudio previo

anidan los diferentes elementos y se guardan en un �chero XML dentro del directoriores/layout de la aplicación.

Luego solo es necesario que en el archivo �java/MainActivity.java� se indique me-diante código el �chero del que debe cargar la interfaz de la pantalla de�nida.

Por otra parte, para llevar a cabo la comunicación con los distintos servicios webremotos se utilizará esta tecnología también como se expone a continuación.

8.3. Servicio web

Para acceder a la información que se se visualizará se hará uso de varios métodosde un servicio web [6]. Este en general, es una tecnología que utiliza un conjuntode protocolos y estándares que sirven para intercambiar datos entre aplicaciones.Aplicaciones de software desarrolladas en lenguajes de programación diferentes, yejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para inter-cambiar datos en dispositivos conectados en red, ya sea local o a través de Internet.La interoperabilidad se consigue mediante la adopción de estándares abiertos. Lasorganizaciones OASIS y W3C son los comités responsables de la arquitectura y regla-mentación de servicios WEB. Existen muchos tipos de servicio web pero nosotros noscentraremos en las dos más importantes dejando claro que usaremos SOAP puestoque así lo tiene de�nido el grupo TIP.

8.3.0.1. REST

Siglas de REpresentational State Transfer, REST, es un tipo de arquitectura dedesarrollo web que se apoya totalmente en el estándar HTTP. El término se originóen el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno delos principales autores de la especi�cación del protocolo HTTP y ha pasado a serampliamente utilizado por la comunidad de desarrollo.

Sus principales características son:

Protocolo cliente/servidor sin estado. Toda la información necesaria para com-prender la llamada a la API se encuentra en la propia llamada.

Un conjunto de operaciones bien de�nidas a aplicar a los recursos, las masimportantes: GET, PUT, POST y DELETE. Estas operaciones suelen equipa-rarse a las acciones de Consulta, Modi�cación, Creación y Borrado.

Una sintaxis universal para identi�car recursos.

El uso de hipermedios para obtener y pasar información.

35

Capítulo 8. Estudio previo

8.3.0.2. SOAP

Siglas de Simple Object Access Protocol, SOAP, protocolo estándar que de�ne cómodos objetos en diferentes procesos pueden comunicarse por medio de intercambio dedatos XML. Este protocolo deriva de un protocolo llamado XML-RPC. SOAP fuecreado por Microsoft, IBM y otros. Está actualmente bajo el auspicio de la W3C. Esuno de los protocolos utilizados en los servicios Web.

El protocolo consta de tres partes:

Sobre (envelope): el cuál, de�ne qué hay en el mensaje y cómo procesarlo.

Conjunto de reglas de codi�cación: para expresar instancias de tipos de datos.

La convención: para representar llamadas a procedimientos y respuestas.

Sus principales características son:

Extensibilidad (seguridad y WS-routing son extensiones aplicadas en el desa-rrollo).

Neutralidad (SOAP puede ser utilizado sobre cualquier protocolo de transportecomo HTTP, SMTP, TCP o JMS).

Independencia (SOAP permite cualquier modelo de programación).

Durante el desarrollo del proyecto se llevará a cabo llamadas a un servicio web detipo SOAP, como llamadas a procedimientos remotos. Puesto que únicamente vamosa hacer uso de varios servicios ya montados por el grupo TIP para tener acceso a subase de datos.

36

Capítulo 9

Análisis

9.1. Actor del sistema

Al tratarse de una aplicación para dispositivos móviles a disposición del público en latienda de Play Store. No podemos tener más de un único actor, usuario. Sin embargo,podríamos dividir este en 2 en función del tipo de dispositivo móvil que esté usando,smartphone o tabletas. Pero considerando que los casos de uso no varían entre unoy otro, se desarrollará los casos de uso para ambos. Puesto que la funcionalidad serála misma, sólo varían en sus diseños de interfaz de usuario. Por tanto, solo tenemosun tipo de actor:

Usuario. Este actor tiene control total sobre la aplicación ya que no existeningún otro tipo de actor. De hecho, no posee ningún tipo de restricción en suuso salvo las planteadas por el desarrollador.

9.2. Diagrama de casos de uso

Como se decía al tratarse de un único actor solo hay disponible un único diagramade casos de uso, sin embargo, eso no quita que los casos de usos sean pocos, alcontrario, tendremos todos para este único actor. Por otra parte, los casos de usosestán estrechamente ligados a la interfaz y a la estructuración de la información enesta. A continuación se puede visualizar los diagramas representativos de las accionesposibles desde la interfaz de usuario.

37

Capítulo 9. Análisis

Figura 9.1: Diagrama de casos de uso 1

Resumen de los casos de uso de este diagrama

Acción Breve descripción

Buscar verbo Tarea que lleva a cabo la consulta acerca del verboindicado.

Cambiar conjugación Esta acción solo está disponible si el verbo dispone de másde una forma de conjugarlo y permite elegir una de ellasal usuario

Cambiar de forma Acción que permite al usuario elegir entre visualizar lasformas simples o las formas compuestas

Cambiar de modo Permite movernos entre los distintos modos: indicativo,subjuntivo e imperativo. Estos dependen de la formaelegida.

Cambio manual Permite cambiar de tiempo verbal o tiempos verbalesmostrados mediante el deslizamiento horizontal del dedodel usuario

Acceso a notas Permite visualizar las distintas notas acerca de laconjugación actual del verbo.

Cuadro 9.1: Tabla de casos de uso 1

38

Capítulo 9. Análisis

Figura 9.2: Diagrama de casos de uso 2

Resumen de los casos de uso exclusivos del segundo diagrama

Acción Breve descripción

Modi�caropciones

Permite modi�car distintos aspectos de la aplicación.

Preferenciasgenerales

Permite con�gurar aspectos principales sobre la aplicación.

Seleccionaridioma

Permite elegir entre inglés o español para todas lasetiquetas y los menús de la aplicación.

Ir a la web Permite al usuario obtener información sobre eldepartamento asociado al desarrollo de esta aplicación.

Opciones deconjugación

Permiten llevar a cabo pequeños cambios en lasconjugaciones de los verbos.

Ver negada Permite visualizar las formas conjugadas negadas o no.Ver en femenino Permite visualizar las formas conjugadas con pronombres

femeninos o no.Ver frec. delCREA

Permite visualizar junto a las formas conjugadas lafrecuencia del CREA asociada.

Elegir dialecto Permite cambiar el dialecto de las formas conjugadas,eligiendo entre España, Río de la Plata, Canarias y formade tratamiento formal.

Cuadro 9.2: Tabla de casos de uso 2

39

Capítulo 9. Análisis

Figura 9.3: Diagrama de casos de uso 3

Resumen de los casos de uso exclusivos del tercer diagrama

Acción Breve descripción

Acción conforma verbal

Permite extraer una forma verbal de alguna de lassiguientes formas.

Escuchar formaverbal

Permite extraer o reproducir de forma sonora deuna forma verbal.

Compartirforma verbal

Permite enviar una forma verbal a alguna de lasaplicaciones más usadas.

Copiar formaverbal

Permite usar el portapapeles para copiar unaforma verbal.

Acción contiempo verbal

Permite extraer todas las formas verbales quecomponen un tiempo verbal de alguna de lassiguientes formas.

Escuchar tiempoverbal

Permite reproducir de forma sonora un tiempoverbal completo.

Compartirtiempo verbal

Permite enviar un tiempo verbal completo aalguna de las aplicaciones más usadas

Copiar tiempoverbal

Permite usar el portapapeles para copiar untiempo verbal completo.

Cuadro 9.3: Tabla de casos de uso 3

Si se necesita más información detallada sobre los casos de uso de la aplicación, seremite al lector al capítulo 19, al apartado de Especi�caciones de casos de uso.

40

Capítulo 10

Diseño

10.1. Diseño arquitectónico

El diseño de la arquitectura de software indica la estructura, funcionamiento e in-teracción entre las partes que componen y forman el software. De hecho, consisteen un conjunto de elementos y abstracciones coherentes que proporcionan el marcode trabajo. Este se elige y diseña en base a objetivos y restricciones. Los objetivosson pre�jados por el sistema, mientras que las restricciones son las limitaciones quederivan de la tecnología que dispone para implementar y desarrollar el sistema. Elestilo arquitectónico que se ha escogido, dadas las características del sistema de in-formación y sus funcionalidades, es la arquitectura cliente - servidor. A continuaciónse presenta un diagrama en el que se han detallado los nodos más signi�cativos queintervienen en el sistema. Pero me gustaría indicar que para llegar a este punto sediseño una versión previa que puede verse en el capítulo 21, así como las razones dedesechar el antiguo por este diseño arquitectónico.

41

Capítulo 10. Diseño

Figura 10.1: Diseño arquitectónico

Tal y como se puede ver en la �gura anterior, se distinguen 2 grandes grupos: servidorweb del que se obtendrá parte de información y el cliente, la aplicación Android, quees el nodo el que principalmente se trabajará.

El primer nodo representa al servicio web remoto, donde se encuentra granparte de la información sobre el verbo que deseamos mostrar. Este solo permitepeticiones SOAP y pertenece al grupo TIP. Concretamente como se puede ver�nalmente se usarán 2 servicios el reconocedor y el conjugador.

El nodo cliente representa a todos los dispositivos móviles que usan la apli-cación, es decir, los usuarios. Se trata del proyecto en el que se trabajará enmayor grado. Se compone de múltiples módulos como se puede apreciar en laimagen anterior. A continuación veremos una breve descripción de cada unode ellos.

� Consultor SOAP: Es el encargado de gestionar las peticiones a ambosservicios remotos. Llegando a realizar como máximo 4 peticiones entreambos servicios web. Uno para el reconocedor y hasta 3 para el servicio deconjugación dependiendo del número de identi�cadores de verbo obtengadel reconocedor. Puesto que los identi�cadores de verbo representan alnúmero de conjugaciones diferentes que posee el verbo.

� Servicio local de notas: Este módulo se encarga de leer las notas de �cherosy cargarlas en estructuras dinámicas al iniciarse la aplicación. Para así,tener acceso a ellas durante el uso de la aplicación. Se seleccionarán lasque le corresponden a la conjugación del verbo en el momento que se sepael identi�cador del verbo.

42

Capítulo 10. Diseño

� Modulo de almacenamiento: Este módulo permite almacenar toda la in-formación obtenida de los dos módulos anteriores y clasi�car las notasobtenidas en función de su identi�cador en varios tipos de notas. Paraque así, el usuario pueda elegir entre las distintas conjugaciones sin per-der los datos del resto de conjugaciones de un mismo verbo, entre otrascosas.

� Módulo de procesamiento de texto: Este se encarga de preparar a cadaforma verbal para que sean presentadas de forma adecuada y cumpla conlas características del propio verbo y las seleccionadas por el usuario enel menú de opciones de la interfaz de usuario. Este además tiene asociadootro módulo para la construcción de imperativos pronominales que seráexpondrá más adelante.

� Interfaz de usuario: Esta deberá mostrar la información guardada en elmódulo de almacenamiento de la forma más optima posible. Permitiendoal usuario navegar e interactuar con las distintas conjugaciones, modosy tiempos del verbo elegido. Así como con los distintos tipos de notasasociadas.

A continuación se describe de forma más exhaustiva los distintos módulos que com-ponen el nodo cliente y su diseño interno.

10.2. Consultor SOAP

Esta componente permite al dispositivo conectarse a un servicio remoto, por tanto,requiere conexión a Internet para llevar a cabo su cometido. De esta dependen elresto de componentes para satisfacer las necesidades del usuario y se basa en realizaruna consulta a cada uno de los dos servicios web SOAP del grupo TIP. Este nospermiten tener acceso a los siguientes datos:

En primer lugar, necesitamos el valor numérico que identi�ca a una conjugacióndel verbo (id_conjug), así como su forma canónica (verbo en in�nitivo) y el códigode la persona, número y tiempo(id_persona) a la que representa el verbo que se haintroducido en la interfaz, para ello se hace uso del servicio remoto de reconocimiento.

43

Capítulo 10. Diseño

Figura 10.2: Proceso de las consultas al servicio remoto lematizador

Como se puede ver en la ilustración existe la posibilidad de que para un verbointroducido existan múltiples identi�cadores o códigos de in�nitivo. Puesto que unverbo puede tener varias conjugaciones en función de si tiene distintos signi�cados opor otras razones.

Con los datos obtenidos del reconocedor debemos realizar 2 acciones.

Por un lado, mediante el código o identi�cador de conjugación del verbo po-demos saber las notas que le corresponden en el sistema local de notas. Y conel identi�cador o código de persona, número y tiempo podemos acceder a lasnotas de persona, número y tiempo para saber en que forma está el verbointroducido por el usuario.

Por otro lado, usando también el identi�cador de la conjugación del verboy la inicial de la forma canónica, para colocarla en verbos_x sustituyendolapor la x, podemos hacer la consulta al otro servicio llamado Conjugador, paraasí obtener el tipo de verbo, todas las formas verbales de esa conjugación,sus respectivos índices y frecuencia del CREA. Para ello, será necesario irrecogiendo los elementos que nos interesan de las distintas estructuras xml queforman la respuesta del servicio.

44

Capítulo 10. Diseño

Figura 10.3: Proceso de las consultas al servicio remoto conjugador

Estas 2 peticiones remotas deben realizarse tantas veces como identi�cadores deconjugación no repetidos nos devuelva la consulta al servicio lematizador. Pero nuncaserán más de tres, así está establecido en el sistema remoto. Puesto que en principio,como máximo un verbo tendrá tres formas de conjugarse y, por tanto, tendrá treslistas de notas como máximo. Nuestro almacén estará construido en base a estehecho. A continuación, podemos ver un pequeño esquema de las posibles llamadas aambos servicios remotos:

Figura 10.4: Esquema de peticiones para el caso más simple

Figura 10.5: Esquema de peticiones para el caso más complejo

En la primera �gura podemos ver las consultas del caso más simple y en la segunda esposible visualizar el caso más extremo. Esto dependerá del número de identi�cadoreso códigos de conjugación diferentes encuentre la consulta al servicio reconocedor.

45

Capítulo 10. Diseño

Para acabar con este punto, me gustaría indicar también que en este módulo se debencontrolar las excepciones producidas por la falta de conexión a Internet o la caídapoco probable del servicio remoto. Todas ellas deben ser noti�cadas al usuario en lavista principal.

10.3. Servicio local de notas

El origen de este servicio local es debido a que era necesario reducir el tiempo derespuesta de la aplicación, ya que se producían demasiadas consultas al servicio webremoto y esto provocaba unos tiempos de espera inaceptables. Sobre todo cuando elacceso a Internet era mediante conexión de datos, esto se puede ver en la �gura 21.2.

Por ello, se decidió que parte de las tablas de la base de datos remota fueron extraídasen forma de �cheros y estos a su vez se incluyen dentro de la aplicación, en eldirectorio �Assets�. Para así facilitar la actualización de esta información por partedel grupo TIP en caso de añadir nuevas notas.

Las tablas, en este caso, �cheros asociados a un identi�cador de conjugación seríanlos siguientes:

de�niciones : Sería un �chero que representa una tabla con dos campos, elprimero representa a los identi�cadores de conjugación y el segundo a las de�-niciones asociada.

verbos_notas : Fichero que asocia a cada identi�cador de conjugación uno ovarios identi�cadores de notas.

notas : Fichero que representa una tabla con dos campos, identi�cador de notay la nota asociada.

Por otro lado, el �chero asociados al identi�cador de persona, número y tiempo sería

codFlexiones : Fichero que se compone de dos campos, el identi�cador de per-sona, número y tiempo y su respectiva persona, número y tiempo.

Para su uso, será necesario implementar la lectura de �chero línea a línea y cadacampo estará separado por un carácter particular en todos los �cheros. Toda lainformación será almacenada en estructuras dinámica basadas en colecciones para los�cheros cuya relación es 1 para muchos. Y para los �cheros relacionales de muchos amuchos se usará una colección compuestas por conjuntos basados en listas, puesto queasí es posible agrupar los elementos por identi�cadores. Estas dos tipos de relacionesserán de�nidas en 2 clases por separado para facilitar su uso. Y se realizará la lecturay almacenamiento de las notas en estas estructuras el inicio de la aplicación, ensegundo plano.

46

Capítulo 10. Diseño

10.4. Procesador de texto

Este módulo consiste en modi�car las formas verbales proporcionadas por el consultorSOAP para mostrar de forma adecuada la conjugación del verbo. Para ello, seránecesario añadir complementos que nos permitan construir cada persona del tiempoverbal. O también es posible que sea necesario modi�car la forma verbal, ya que endeterminadas situaciones no representa su forma correcta debido a las limitacionesque posee el servicio conjugador.

Información proporcionada por el servicio remoto asociada al conjugador deverbos.

1. forma verbal

2. frecuencia del CREA

Información �nal que debe o puede ser añadida al ser tratada por este módulo.

[pronombre personal] + [negación] + [pronombre re�exivo] + [verbo auxiliar]+ forma verbal + [pronombre personal en imperativo] + [frecuencia delCREA]

A continuación puede verse un resumen de las distintas consideraciones a tener encuenta durante el proceso de añadido de los diferentes complementos.

Pronombres personales

Estos acompañan normalmente en la mayoría de los casos a la forma verbal siguiendoel criterio de persona y número para asociar cada pronombre a su forma verbal. Estospronombre serían �yo�, �tu�, �él�, �nosotros�, �vosotros� y �ellos�. Sin embargo,en contadas ocasiones varían su asociación con la forma verbal. Estas variacionesdependen de las siguientes opciones de conjugación:

Dialecto: Este varía en función de la elección del usuario y provoca que cambienlas 2ª personas del singular y el plural en función del dialecto elegido. Porejemplo:

� Dialecto España: �tu�, �vosotros�.

� Dialecto Río de la plata: �vos�, �ustedes�.

� Dialecto Canario: �tu�, �ustedes�.

� Dialecto Tratamiento formal: �usted�, �ustedes�.

47

Capítulo 10. Diseño

Femenino: varía la 3ª persona del singular y todas o algunas de las personasdel plural dependiendo del dialecto elegido. Serían:

� Dialecto España: �ella�, �nosotras�, �vosotras� y �ellas�.

� Resto de dialectos: �ella�, �nosotras� y �ellas�.

También cabe la posibilidad de que se trate de un verbo que no posee pronombrepersonal al tratarse de un verbo impersonal. Esto se determina mediante unidenti�cador concreto de nota defectiva. Ocurre, por ejemplo, con una de lasconjugaciones de llover.

Otra variante es la posición en la que se coloca el pronombre personal, puestoque en la mayoría de los caso va al principio de la forma verbal procesada. Conla excepción de las formas en imperativo que se colocan después de la formaverbal.

Negación

Otro aspecto a añadir es la negación de la conjugación, esta es posible agregarla paratodos los casos. Dependerá de la elección del usuario mediante su activación o no enla interfaz de usuario. Además hay que indicar que siempre aparecerá situada antesde la forma verbal.

Pronombre re�exivo

Este elemento podrá ser añadido si las características del verbo lo permiten, es decir,si el valor que identi�ca el tipo de verbo (categoría gramatical) nos lo permite. Estevalor es obtenido de la consulta al servicio remoto �conjugador�. En caso de queel verbo sea pronominal se dará la posibilidad al usuario de agregarle el pronombrere�exivo a todas las formas verbales del verbo mostrado. Estos son �me�, �te�,�se�, �nos�, �os�, �se�. Sin embargo, existen algunos cambios para algunos casosespeciales, como son:

Cambio de dialecto: cambian las 2ª personas del singular y el plural en funcióndel dialecto elegido.

En el caso de los imperativos pronominales el pronombre debe ser incrustadoen el �nal de la propia forma verbal. Por ejemplo, el verbo �estudiar� sin pro-nombre re�exivo sería �estudia tú� y con pronombre re�exivo sería �estudiátetu�. Sin embargo, cuando el mismo verbo en imperativo pronominal es negado

48

Capítulo 10. Diseño

debe colocarse el pronombre re�exivo de la forma típica, �no te estudies tú�.Otra cosa es lo que ocurre con la forma verbal �estudiáte� que será explica-do en la última parte de la sección 10.4.1 en que se modi�ca la propia formaverbal.

Verbo auxiliar

Si se trata de una forma compuesta, debemos mostrar el verbo auxiliar �haber�conjugado seguido de la forma verbal impersonal en participio. La conjugación delverbo �haber� se encuentra en el archivo �strings.xml� de la aplicación, por ello, no esnecesario añadir más consultas al sistema remoto para formar las formas compuestas.

Frecuencia del CREA

La frecuencia del CREA es un valor numérico que representa al número de aparicio-nes de la forma verbal que hay en el Corpus de Referencia del Español Actual. Elcuál, es un banco de datos de la lengua española desarrollado por la Real Academia.Su contenido se incluye de forma estadística escogiendo expresiones de Hispanoamé-rica y España, de toda clase de textos escritos, y cubre los últimos 25 años. Estecomponente aparecerá visible si así lo desea el usuario mediante el menú de opcionesde conjugación que aparecerá en la interfaz.

10.4.1. Casos en que se modi�ca la forma verbal

Durante la construcción de la forma verbal junto a sus complementos hay que teneren cuenta que en algunos casos la propia forma verbal no debe corresponderse conla asociada a su identi�cador. Esto es debido a que en condiciones dependientes delas opciones de conjugación elegidas por el usuario los verbos son conjugados de otraforma la cual viene proporcionada también por el servicio �conjugador� pero conotro identi�cador. A continuación se describen algunos de estos casos:

El dialecto �Tratamiento formal� cambia la 2ª persona del singular por la 3ªpersona del singular del mismo tiempo. Por ejemplo, �tu comes� en este dia-lecto sería �usted come�.

El dialecto �Canario� y de �Tratamiento formal� usan diferentes formas verbalespara la 2ª persona del plural con respecto al resto de dialectos. Por ejemplo,�vosotros coméis� en estos dialectos es �ustedes comen�. De hecho, en amboscasos se usa la 3ª persona del plural en lugar de la 2ª persona del plural delmismo tiempo.

49

Capítulo 10. Diseño

Mientras que el dialecto �Río de la plata� tiene su propia 2ª persona del singular,la cual nos proporciona el servicio web. Por ejemplo, �tu comes� en este dialectosería �vos comés�. Esta forma verbal aparecerá con otro identi�cador peroagrupado con el resto de formas verbales del mismo tiempo.

En las formas en imperativo negadas, se usan las formas del presente del sub-juntivo en vez de la propia forma en imperativo. Por ejemplo, �estudia tú�, 2ªpersona del singular del imperativo, en negado sería �no estudia tú�, pero locorrecto es �no estudies tú�. Siendo �estudies� la 2ª persona del singular delpresente del subjuntivo. Lo mismo ocurre con el resto de formas del imperativocuando es negado.

También debe tenerse en cuenta otras consideraciones en cuanto a la modi�caciónde la propia forma verbal, ya que existen casos en que el servicio no da soporte adeterminadas formas verbales. Esto sucede cuando se trata de un imperativo prono-minal. En estos casos, debe construirse la forma verbal a partir de la que considera elservicio remoto y el pronombre re�exivo que debería acompañarlo. Para su creaciónserá necesario usar dos clases una que separa la forma verbal en silabas y otra quemodi�ca/añade el pronombre a la palabra que constituye la forma. Esta construcciónestaría destinada a formar los imperativos pronominales, ya que se trata de un casoparticular que no es contemplado por el servicio web.

Otro caso similar ocurre con las formas impersonales pronominales, las cuáles, solonecesitan de unir el pronombre a la propia forma verbal por el �nal. Con excepcióndel gerundio que requiere de comprobación para añadirle tilde o no. Por ejemplo,tenemos las formas del verbo comer �in�nitivo: comer� y �gerundio: comiendo�,pues en forma pronominal quedarían de la siguiente forma, �in�nitivo: comerse� y�gerundio: comiéndose�. Sin embargo, en las formas compuestas este proceso se llevaa cabo con el verbo auxiliar �haber� no con la forma verbal.

10.5. Módulo de almacenamiento

Este se encarga de guardar en varios tipos de estructuras los distintos elementosproporcionados por las consultas remotas y el sistema local de notas.

Por una parte, tendríamos una serie de estructuras estáticas que almacenarán lainformación obtenida por los servicios remotos:

Verbo a consultar

Número de conjugaciones obtenidas mediante el servicio remoto Reconocer

50

Capítulo 10. Diseño

Entre 1 y 3 contenedores de formas verbales por conjugación obtenidas me-diante el servicio remoto Conjugador

Entre 1 y 3 estructuras que identi�can el tipo de verbo

Y por otra parte tendríamos estructuras estáticas y los métodos que nos permitiríanalmacenar y clasi�car las notas. Estos últimos se basan en el identi�cador de cadauna de ellas que lo acompañan en el �chero notas. Puesto que:

Del 0 a 1999 son notas importantes.

Del 2000 a 2999 son notas defectivas.

Del 3000 a 3102 son notas morfológicas.

Del 4000 a 4999 son notas ortográ�cas.

Del 5000 a 5999 son notas de uso.

Del 6000 a 6999 son notas de participio irregular.

Del 7000 a 7999 son los verbos similares.

Además este módulo también almacena el estado del sistema completo de formatemporal en un momento dado de manera que se pueda restaurar en ese punto demanera sencilla. Para así poder llevar a cabo el cambio de posición de apaisado avertical o viceversa en en tabletas sin perder el estado de la aplicación.

10.6. Diseño de la interfaz

Este ha sido uno de los componentes donde se dará un mayor énfasis durante eldesarrollo de la aplicación. Puesto que se trata del medio con el que el usuario debeinteractuar y hacer uso de todas las funcionalidades que ofrece la aplicación. Porello, la interfaz a desarrollar debe cumplir los siguientes requisitos mínimos:

Atractiva: Para que la llame la atención del usuario y no pase inadvertida.Este debe ser uno de los puntos fuertes, debido al gran número de competenciadirecta que poseerá la aplicación. En aspecto se deben tener en cuenta loscolores y efectos visuales.

51

Capítulo 10. Diseño

Intuitiva/manejable: Con esto se pretende que el usuario se sienta cómodohaciendo uso de la interfaz y que le permita explorar nuevas posibilidadescon facilidad. Por esa razón, se debe estructurar las acciones correctamente,siguiendo los patrones que poseen las aplicaciones más populares.

Informativa: Deberá mostrar mensajes de ayuda donde visualizar las posiblesacciones que podemos realizar dentro de la aplicación. Por si no se alcanza elnivel intuitivo óptimo y conseguir que el usuario tenga una mejor idea de loque está haciendo o puede hacer.

Evitar sobrecargar de información las vistas: Para ello, no debe colocarse dema-siada información en las vistas. Puesto que esto puede llegar a agotar al usuario.Además, al tratarse de un sistema cuya �nalidad es proporcionar información,que mejor manera de hacerlo que de forma organizada y bien estructurada.

A continuación se puede ver los distintos borradores �nales diseñados para las prin-cipales vistas de la aplicación.

10.6.1. Vistas de la interfaz

Vista Principal: smartphone

Figura 10.6: Diseño: vista principal

Como se puede apreciar en la imagen anterior, en la parte superior de estavista se encuentra el menú de de acceso al resto de vistas y donde el usuariopodrá buscar el verbo que desea conjugar. Este puede ser en cualquier formaconjugada o no.

52

Capítulo 10. Diseño

Debajo de esa sección se puede visualizar 2 botones de acción para �ltrar porformas simples o compuestas. Estos dos son excluyentes el uno del otro, portanto, cuando uno está activo el otro no. Y su tarea será actualizar la vistapara mostrar las formas verbales que correspondan.

Seguidamente tenemos una caja donde visualizar las formas verbales imper-sonales in�nitivo, gerundio y participio. Este último no aparece en las formascompuestas por tanto desaparecería de la vista para ese caso.

Justo debajo tenemos la caja que contiene las formas personales.

� En ella, tenemos los botones que nos permiten movernos de manera másrápida por las formas verbales y tenerlas clasi�cadas según el modo indi-cativo, subjuntivo e imperativo.

� Además tenemos visible el tiempo verbal actualmente elegido, el cual pue-de ser sustituido por las ya citadas pestañas y botones o mediante lospequeños botones que acompañan al titulo del tiempo verbal. También esposible usar el desplazamiento táctil para ello.

Me gustaría recalcar que esta sería la vista base para los casos más comunes, ya queesta varía en función de varios casos particulares, añadiendo patrones puntuales enla barra superior de navegación.

Vista panel izquierdo: Opciones de conjugación

Figura 10.7: Diseño: vista panel izquierdo

53

Capítulo 10. Diseño

Esta vista en realidad es un menú, el cual permanecerá igual para todas los dis-positivos y posiciones. En este, tenemos una lista de opciones que permiten variarla forma en la que visualizamos las conjugaciones. Los cuales son negar, poner enfemenino, en forma pronominal aquellos que nos lo permiten, visualizar la frecuenciadel CREA o cambiar el dialecto. Además en este panel o vista podemos acceder alos ajustes generales de la aplicación.

Vista panel derecho: Información Adicional

Figura 10.8: Diseño: vista panel derecho

Este al igual que la anterior vista permanece igual para todos los dispositivos yposiciones. Salvo en temas de dimensiones y espaciados. Por otra parte su cometidoes muy distinto, ya que permite visualizar información asociada a las conjugacionesde los verbos. Estas notas están clasi�cadas en notas importantes, de�niciones, tipode verbo, notas defectivas, notas morfológicas, notas ortográ�cas, participio irregulary verbos que se conjugan igual. Sin embargo si no existen notas de alguno de los tiposindicados estas no aparecerán.

También me gustaría recalcar que esta sería la vista principal para los casos máscomunes, ya que esta varía en función de los casos particulares.

54

Capítulo 10. Diseño

Vista ajustes

Figura 10.9: Diseño: vista de ajustes

Otra de las vistas que no varía es la de ajustes. Esta da la posibilidad de cambiar elidioma de los menús de la aplicación. Mediante su elección en un cuadro de diálogo.Además de acceder a la web del grupo TIP para más información.

10.6.2. Adaptación para tabletas

Por otra parte, tenemos 2 vistas principales para los dispositivos Android de mayortamaño, las tabletas. Donde es posible visualizar de una forma si el dispositivo estaen modo apaisado y de otra forma si está en modo vertical. La razón de no compartirla vista en todos los dispositivos es debido a la diferencia en cuanto a espacio del quese dispone en un smartphone y una tableta. Ya que es posible ver claramente hasta 5tiempos verbales en una tableta cuando en un dispositivo inferior a 7 pulgadas seríamás complicado representar de forma legible más de una tiempo verbal.

55

Capítulo 10. Diseño

Vista principal: tableta

Figura 10.10: Vista principal portrait en tableta

Esto además de diseño estático supondrá codi�cación extra para introducir el con-tenido en la vista de una forma u otra en función del tipo de dispositivo.

10.7. Diagrama de clases

Para evitar sobrecargar la imagen y fuera visible en una sola página se han supri-mido los atributos y métodos de cada clase, más adelante veremos las clases másimportantes en profundidad

56

Capítulo 10. Diseño

Figura 10.11: Diagrama de clases

57

Capítulo 11

Implementación

A lo largo de esta sección veremos la estructuración interna de los módulos y lassoluciones adoptadas ante la aparición de problemas durante el desarrollo. Tambiénse indicarán los diferentes elementos externos incluidos a lo largo del proyecto, asícomo las razones que nos han llevado a añadir estos componentes.

11.1. Librerías externas utilizadas

11.1.1. Librería externa ksoap2

Como Android no incluye ningún tipo de soporte para el acceso a servicios web detipo SOAP. Se ha hecho uso de una librería externa para hacernos las cosas mássimples. La opción más popular y, por tanto, la más utilizada es la librería �ksoap2-android� [23]. Esta librería es una bifurcación, especialmente adaptado para Android,de la antigua librería kSOAP2 de java. Esta herramienta nos permitirá de formarelativamente fácil y cómoda utilizar servicios web que utilicen el estándar SOAP. Yentre otras cosas nos permite obtener las respuesta ya parseada.

Esta librería así como el protocolo SOAP que se explico anteriormente se basan encinco pasos básicamente:

1. De�nir la petición (request)

2. Con�gurar un sobre (envelope) (de�ne que hay en el mensaje y como proce-sarlo),

3. De�nir el canal de transporte,

58

Capítulo 11. Implementación

4. Hacer la llamada

5. Recoger los datos.

Hay que recordar que para poder hacer uso de las funciones de esta librería es ne-cesario conceder permiso de acceso a Internet a la aplicación, añadiendo la líneacorrespondiente al �android_manifest.xml� del proyecto.

<uses−permis s ion android : name="android . permis s ion .INTERNET"/>

Algo que se debe tener en cuenta es que el código de conexión a un servicio webSOAP explicado anteriormente funciona correctamente sobre dispositivos o emula-dores con versión de Android anteriores a la 3.0. Sin embargo, si intentamos ejecutarla aplicación sobre una versión posterior obtendremos una excepción de tipo "Net-workOnMainThread". Esto es debido a que en versiones posteriores no se permiterealizar operaciones de mínima duración directamente en el hilo principal de la apli-cación. Para solventar esto, es necesario trasladar el código del módulo de conexiónSOAP a una tarea asíncrona que realice las operaciones en segundo plano utilizandoun hilo secundario.

11.1.2. Librería externa ActionBarSherlock

Android 3.0 fue el introductor del �ActionBar�. Por alguna razón desconocida, estepatrón inicialmente no se incluía en el paquete de asistencia de Android. Sin embar-go, esta librería externa �ActionBarSherlock� [19] nos da todas las funcionalidadesde los �Action Bar� adaptados a versiones anteriores de Android. Prácticamenteidéntica de usar a la o�cial, puesto que esta librería lo que hace es utilizar la barrade acción nativa cuando esté disponible o hace una implementación propia de for-ma automática. Esto nos permite desarrollar de forma fácil una aplicación con un�ActionBar� para todas las versiones de Android desde la 2.x en adelante. Quieroindicar que su inclusión en el proyecto surgió durante los inicios del desarrollo deeste proyecto cuando la API para smartphones no incluía las barras de acción, ac-tualmente no es necesario importar esta librería puesto que ya ha sido incluido el�ActionBar� en las últimas versiones de la API. Y se ha dejado así debido a que nosupone ningún problema para las distintas versiones del SO Android y nos permitedar soporte a la versiones más antiguas.

59

Capítulo 11. Implementación

Figura 11.1: Ejemplo de un Action Bar

11.1.3. Extensiones de esta librería añadidas

Librería externa SherlockNavigationDrawer [18]. Este módulo va ligado alanterior y permitirá usar el patrón de diseño �toggle button� que aparecerá en laparte izquierda del icono de la aplicación en la barra de acción de �ActionBarSher-lock�. Debido a que como ocurre con la librería �ActionBarSherlock� en ocasionesno tendremos disponible este componente en la propia API de Android para los S.O.más antiguos.

Figura 11.2: Ejemplo de Toggle Button combinado con home button

Librería/Módulo externo viewPageIndicator[20]. Esta librería es tambiénextensión de �ActionBarSherlock� y es imprescindible para dotar a nuestras aplica-ciones de una experiencia de usuario moderna. �ViewPageIndicator� permite entreotras cosas indicarnos en que página nos encontramos a medida que nos movemospor las distintas páginas que componen el objeto �ViewPager�, contenedor de pági-nas que veremos en la sección 11.6.1 de principales componentes de diseño utilizadospropios de Android.

Figura 11.3: Ejemplo de viewPageIndicator

60

Capítulo 11. Implementación

11.2. Desarrollo del Módulo Cosultor SOAP

Este módulo se compone principalmente de la siguiente clase, AccesoRemoto, la cual,se encargará de llevar a cabo todas las peticiones a ambos servicios remotos usando lalibrería KSOAP vista anteriormente. Las principales funciones de AccesoRemoto sonconsultaReconocedor, que como su propio nombre indica hace la consulta al servicio�Reconocedor�, y consultaConjugador, que hace la consulta al servicio �Conjuga-dor�. Ambas son utilizadas en el método solicitarInfoVerbo el cual se encargará degestionar las peticiones que sean necesarias a ambos servicios. El resto de métodosse usan en estas tres funciones y son complementos auxiliares necesarios para dichasestas funciones.

Figura 11.4: Clase que de�ne el modulo de consultas SOAP

Sin embargo, cuando iniciamos una aplicación Android, el sistema operativo crea unnuevo hilo de procesamiento para la aplicación. En ese hilo, llamado hilo principal,es donde se ejecutan todas las operaciones del programa. Es por ello, que cualquieroperación larga o costosa que realicemos en este hilo va a bloquear la ejecución delresto de componentes de la aplicación y por supuesto también la interfaz, produciendoal usuario un efecto evidente de lentitud, bloqueo, o mal funcionamiento en general,algo que deberíamos evitar a toda costa. En este caso se produce este hecho cuandose producen las consultas a los servicios remotos. Incluso puede ser peor, dado quelas recientes versiones de Android monitorizan las operaciones realizadas en el hiloprincipal y detecta aquellas que superen los 5 segundos forzando su cierre. Con el�n de que la interfaz de la aplicación atienda adecuadamente en todo momento a loseventos generados en la interfaz de usuario, es conveniente que dichas operaciones sehagan en otro hilo de procesamiento diferente del hilo principal.

61

Capítulo 11. Implementación

11.2.1. Tarea asíncrona

La tarea asíncrona es nuestra solución, ya que se ejecuta en un hilo secundario ypermite realizar acciones costosas cuyo resultado queremos que se publique en el hiloprincipal de la interfaz de usuario. En Android es muy frecuente lanzar nuevos hilos.Puesto que tendremos que hacerlo siempre que exista la posibilidad de que una tareapueda bloquear el hilo de la interfaz de usuario. Existen varias herramientas quepermite solucionar este problema, pero nos decantamos por las tareas asíncronas.Debido a que permite ejecutar operaciones en segundo plano y de�nir los resultadosen el hilo principal de la interfaz sin tener que quebrarnos la cabeza manipulando�threads� y �handlers�.

Para utilizar �AsyncTask� debemos:

Crear una subclase de �AsyncTask�, comúnmente como una clase interna pri-vada dentro de la actividad en la que estamos trabajando.

Sobrescribir uno o más métodos de �AsyncTask� para poder realizar el trabajoen segundo plano, además de cualquier otra tarea asociada para poder mostraralguna actualización en el hilo principal de la interfaz de usuario.

Cuando sea necesario, crear una instancia de �AsyncTask� y llamar al métodoexecute() para que empiece a realizar su trabajo.

Figura 11.5: De�nición de la clase asíncrona utilizada

11.2.1.1. Etapas del AsyncTask

Cada vez que una tarea asíncrona se ejecuta, pasa por 4 etapas:

1. onPreExecute(). Se invoca en el hilo principal inmediatamente después de quela tarea es ejecutada. Este paso se utiliza normalmente para con�gurar la tarea.En nuestro caso se muestra la barra de progreso en la interfaz de usuario.

2. doInBackground(Params...). Se invoca en el subproceso en segundo plano in-mediatamente después de que onPreExecute() termina de ejecutarse. En esta

62

Capítulo 11. Implementación

etapa se ejecutan todas las operaciones que deseamos que se realicen en segun-do plano. De hecho, los parámetros de entrada de la tarea asíncrona se pasan enesta etapa. Dentro de esta etapa es posible utilizar el método publishProgress(Progress...) para publicar el progreso en el hilo principal por la ayuda de lasiguiente etapa que es onProgressUpdate (Progress...). En este caso no se hahecho uso de esta herramienta.

3. onProgressUpdate (Progress...). Se invoca en el hilo principal de la actividaddespués de una llamada a publishProgress(Progress...). El momento de la eje-cución es inde�nido. Este método es utilizado para mostrar cualquier tipo deprogreso en la interfaz de usuario mientras la tarea en segundo plano sigueejecutándose. Esta etapa ha sido omitida en nuestro caso,debido a que no semuestra el progreso de forma numérica en el hilo principal.

4. onPostExecute(Result...). Se invoca en el hilo principal después de que el pro-ceso en segundo plano ha sido terminado. El resultado devuelto por todo elproceso se pasa a este método como parámetro.

Para trabajar con una clase AsyncTask hay que tener en cuenta que la instancia dela tarea debe crearse en el hilo principal. Además de que el método execute(Params)debe invocarse en el hilo principal también. Por otra parte, los métodos onPreExe-cute(), onPostExecute(), doInBackground(Params...), onProgressUpdate() no debenllamarse de forma manual.

11.3. Desarrollo del servicio local de notas

Este módulo se basa tres clases, dos de ellas son contenedores que permiten almacenartodas las de�niciones, notas y persona-número-tiempo de los verbos tras ser leídas delos �cheros. La otra permite usar los contenedores con la intención de buscar dichainformación para un verbo concreto.

63

Capítulo 11. Implementación

Figura 11.6: Clases que conformarán este módulo

El ContenedorClaveConjunto permite almacenar pares de clave grupo de va-lores y se utilizara para agrupar los identi�cadores de notas o las de�nicionesque le corresponden a un identi�cador de verbo. Por tanto, solo existiran 2instancias de esta clase la cuál almacenara dichos valores.

El ContenedorClaveValor permite almacenar pares clave valor, en este proyectose utilizarán para almacenar los identi�cadores de verbo (clave) o los identi�-cadores de persona-numero-tiempo (clave) con las notas(valor) o con las notasasociadas a la persona-numero-tiempo(valor) asociados. Por ello, en este casotendremos también 2 instancias de esta clase contenedora.

La carga de estos contenedores a partir de los �cheros se lleva a cabo en un nuevo hilocreado desde el hilo principal cada vez que se inicia la aplicación en el dispositivo.Puesto que no son cantidades exageradamente altas de valores a almacenar, con loque se cargan las estructuras antes de que el usuario realice una búsqueda.

La instancia de la clase AccesoLocal creará y cargará los contenedores ante-riormente mencionados y los utilizará para buscar lo que se le encargue trascompletarse el uso de el AccesoRemoto dentro de la propia clase asíncrona Ta-reaAsincrona. Ya que la búsqueda local también puede tomarse algo de tiempoy así evitamos problemas con la espera de la interfaz de usuario.

11.4. Desarrollo del módulo de almacenamiento

Este módulo se usará para registrar o guardar la información obtenida durante laúltima búsqueda realizada de un verbo, además del estado actual de la interfaz como

64

Capítulo 11. Implementación

se menciono en la sección de diseño de este módulo. Y se compone principalmentede la clase RegistroInfo.

Figura 11.7: Clase RegistroInfo

Esta clase almacena el estado actual de la aplicación, así como el último verbo escritopor el usuario. También guarda toda la información referida a este obtenida tras lasconsultas a los servicios remotos en objetos de la clase Identi�caVerbo y Conjugacion.Además de las consultas al servicio local de notas las cuales son almacenadas en unobjeto de la clase NotasAsociadas. Esta clases están asociadas entre ellas medianteel identi�cador indiceConjugaciones, que va de 0 a 2, y han sido de�nidas de lasiguiente forma.

65

Capítulo 11. Implementación

Figura 11.8: Clase Iden�cadorVerbo, Conjugación y NotasAsociadas

1. Identi�caVerbo. Contiene la información asociada a la persona, número y tiem-po del verbo. De hecho, almacena por una parte los identi�cadores obtenidosdel servicio remoto reconocer y, por otra parte, almacena las notas asociadas adichos identi�cadores que son obtenidas del servicio local.

2. Conjugacion. Como su propio nombre indica almacena las formas verbales sincomplementos y su frecuencia del crea que son directamente obtenidos ambosdel servicio remoto �Conjugador�, pero también guarda el identi�cador de laconjugación que permite diferenciar la conjugación del resto que posea esteverbo. Además de la categoría gramatical o el tipo que posee la conjugación encuestión.

3. NotasAsociadas. Esta última clase tiene por objetivo guardar los identi�cado-res de las notas obtenidos previamente del servicio local de notas usando elidenti�cador del verbo del verbo consultado. Para así, mediante esta clase ge-nerar los contenedores necesario para cada tipo de nota. Y tras buscarlas enlos diccionarios correspondientes almacenarlas de forma clasi�cada.

66

Capítulo 11. Implementación

11.5. Implementación del procesador de texto

Este módulo es el que contiene mayor peso junto al de la interfaz de usuario ya querealiza la tarea de añadir los diferentes complementos que acompañaran a la formaverbal y sus posibles modi�caciones teniendo en cuenta todas las consideraciones,como se indico en la sección 10.4.

Figura 11.9: Clase procesadora del texto

La clase principal ProcesarStringVerbo solo posee un método público, construirLinea,del resto de métodos ya se encargara de usarlos dicha función siempre que se le paselos parámetros correctos. Todo el proceso de�nido en la sección de diseño de estemódulo viene siendo realizada por aquellas funciones que conforman esta clase, porejemplo, el pronombre personal lo añadirá la función anadirPronombrePersonal y asísucesivamente. Salvo el tema de modi�cación de la forma verbal en los imperativospronominales.

67

Capítulo 11. Implementación

Figura 11.10: Clases que conforman la construcción del imperativo pronominal

Para ese caso, usamos una clase llamada ConstructorImperativoPronominal que cons-truye dicha forma a partir de la función pegaPronombreImperativo esta usa el in�niti-vo del verbo y el pronombre re�exivo (me, te, se, nos, os) para unirlo por el �nal. Paraello, debe realizar una serie de comprobaciones basada en la separación de sílabasrealizada mediante la clase SeparadorDeSílabas. Para así, encontrar la sílaba tónicay añadirle una tilde, quitársela o añadir una vocal en caso de que fuese necesario.Estas dos clases vienen dadas por el grupo TIP en lenguaje C y han sido trascritasa java.

11.6. Desarrollo de la interfaz

Esta sección veremos algunos de los aspectos mas importantes puesto que se tratade la parte que conforma el mayor peso de código de la aplicación. Ya que ademásde usar los distintos componente de diseño proporcionados por la API de Androidhay que tener en cuenta los distintos estados en los que pueden encontrarse cada unode ellos a lo largo del uso de la aplicación. Por ese motivo trataremos de indicar losmás importantes.

11.6.1. Principales componentes de diseño utilizados

En esta sección lo que se pretende es dar a conocer los componentes de diseño propiosde Android utilizados teniendo en cuenta que sus características los hace diferentes

68

Capítulo 11. Implementación

del desarrollo para cualquier otra plataforma. Con ello, se verá de forma más claracómo se desarrollo gran parte de la interfaz de usuario.

Adapter. Estos objetos son la clave de toda buena interfaz en Android. Puestoque un objeto Adapter actúa como un puente entre un AdapterView y losdatos de una vista (View). El Adapter(adaptador) proporciona acceso a loselementos de datos. Éste también es responsable de crear una vista (View) paracada elemento en la colección de datos. Se puede decir, que los adaptadoresson colecciones de datos, que asignamos a una vista para que ésta los muestre.

Spinner. Estos objetos proporcionan una manera rápida para seleccionar unvalor de un conjunto. En el estado por defecto, un Spinner muestra su valorseleccionado. Al tocar el spinner muestra un menú desplegable con todos losvalores disponibles, de los cuales el usuario puede seleccionar uno. Esta clasede objetos pertenecen a la familia de los mencionados AdapterView.

Figura 11.11: Imagen de Spinner en el ActionBarSherlock

Fragments. Estos, cuando son utilizados, representan una parte de la interfazde usuario en una actividad. Se pueden combinar múltiples Fragments en unasola actividad para construir una multipantalla y reutilizar los Fragments enmúltiples actividades. Para entendernos, se puede ver un Fragment como unasección modular de una actividad, que tiene su propio ciclo de vida, recibesus propios eventos de entrada, y que se puede añadir o eliminar mientras laactividad esta en ejecución.

69

Capítulo 11. Implementación

Figura 11.12: Imagen del patrón Fragmet dentro de un ViewPager

ViewPager. Esta clase extiende de ViewGroup y permite generar un controla-dor que añade la posibilidad al usuario de cambiar de páginas hacia la izquierday la derecha. Para ello, se debe implementar una clase Adapter (adaptador) detipo PageAdapter que permite ir generando las páginas que se visualizarán. LosPageAdapter se utilizan normalmente con Fragments los cuales, son la formaconveniente de suministrar y gestionar el ciclo de vida de cada página. Existenadaptadores estándar implementados para el uso de Fragments que cubren loscasos de uso más comunes. En nuestro caso se ha utilizado FragmentStatePa-gerAdapter.

70

Capítulo 11. Implementación

Figura 11.13: Clase del FragmentAdapter y Fragments que se han utilizado

Como se puede ver, en nuestro caso tenemos un FragmentAdapter que extiende delmencionado FragmentStatePagerAdapter compartido para ambos tipos de página, lasdel dispositivo smartphone y las de las tabletas. Esta última hereda de las primera. Latarea del Adapter será la de ir generando las vistas de las páginas que cree oportunaspara el ViewPager en función del atributo esTablet.

Drawers. Estos elementos de navegación contienen paneles FrameLayout quemuestras las principales opciones de la aplicación o información que no puedevisualizarse en la vista principal. Se ocultan la mayor parte del tiempo por laderecha o por la izquierda, pero se muestran cuando el usuario pulsa el iconoadecuado de la aplicación en el ActionBar o barra de acción.

71

Capítulo 11. Implementación

Figura 11.14: Imagen del patrón ListView dentro de un FrameLayout

ListView. Clase del grupo View que muestra una lista de elementos desplaza-bles. Los elementos de la lista se insertan automáticamente en la lista usandoun adaptador que obtiene el contenido desde una fuente, con un array o unabase de datos y convierte cada elemento en un View que se coloca en la lista.Dentro del Drawer de la imagen anterior podemos ver una ListView.

ExpandibleListView. Clase que extiende de ListView y que muestra elementosde una lista de desplazamiento vertical de dos niveles. Esto di�ere de la �List-View� al permitir que los elementos de la lista se puedan ampliar para mostrarsus hijos en sublistas.

DialogFragment. Estos cuadros de diálogos se basan en el uso de Fragments. Porello, para crear un cuadro de diálogo es necesario usar la herencia de dicha clase.Posteriormente solo es necesario sobrescribir su método onCreateDialog(), enel cual, se genera el cuadro de diálogo en función de las opciones que se desee.Para este proyecto se ha generado tres cuadros de diálogos diferentes.

� Cuadro de diálogo de alerta. Este es el más simple de los cuadros de diálogopuesto que se limita a mostrar un simple mensaje al usuario cuando nohay conexión a Internet y un botón de OK para con�rmar la lectura.Se construye a través de la clase AlertDialog, realmente de su subclaseAlertDialog.Builder. Su uso es muy sencillo, solo es necesario crear unobjeto de esta subclase e indicarle las propiedades del diálogo mediantesus métodos setTitle, setMessage, setPositiveButton.

� Cuadro de diálogo de selección. En el caso en el que seleccionamos unaforma verbal o su título de tiempo verbal al hacer un longClick sobreella, se muestra un cuadro de diálogo con una lista de acciones: escuchar,

72

Capítulo 11. Implementación

compartir o copiar. Para ello, ha sido necesario usar también la subclaseAlertDialog.Builder, pero esta vez solo se usa el método setItems, al cual,se le indica la lista de acciones que se desean mostrar. Estas acciones estándescritas en la sección 11.7.

� Cuadro de diálogo de selección 2. Por otro lado, tenemos una clase dis-tinta para la selección de dialecto de una lista, ya que el resultado de laselección en la lista modi�ca la vista principal de la aplicación y es ne-cesario saber el resultado de la elección para modi�car el hilo principal.Para ello, será necesario hacer que nuestro cuadro de diálogo sea trata-do en una nueva actividad a parte. Y así obtener el dato retornado poresta actividad mediante onActivityResult. Este método nos permite traerconsigo los parámetros requestCode, resultCode y data. Los 2 primeros seusan para comprobar, es decir, si el requestCode es igual que el que de�ni-mos en la clase de la actividad principal, y si el resultCode tiene el mismovalor que la constante RESULT_OK, entonces extraemos los datos quetrae consigo.

11.6.2. Soporte multipantalla

Otra de las funcionalidades de la aplicación es que como se vio en el diseño de lainterfaz poseemos 3 vistas distintas de la vista principal de la aplicación. Una parasmartphones solo en vertical y 2 para tabletas, una en vertical y otra en apaisado.Esta elección se debe a la diferencia de espacio para mostrar información en buenascondiciones entre uno y otro dispositivo.

Para ello, ha sido necesario añadir una parte de forma estática (recursos xml) y otraparte dinámica (código) para cada uno de los dispositivos.

Por un lado, tenemos los �cheros de con�guración de la vista estática que se agrupanen 3 directorios:

layout/ (directorio para la vista principal de smartphone)

layout-large/ (directorio para la vista principal de tableta en vertical)

layout-large-land/ (directorio para la vista principal de tableta en apaisado)

Estos están compuestos por varios �cheros que permiten establecer propiedades a losdistintos componentes de las vistas.

Por otro lado, en la zona de codi�cación debemos establecer una serie de restriccionesen función de que tipo de dispositivo se trate. En primer lugar, debemos indicarle en

73

Capítulo 11. Implementación

Figura 11.15: Vistas en tabletas portrait y landscape

el �chero android_manifest.xml, en la sección de aplicación, que se permita cambiosen la con�guración de la aplicación por la orientación del dispositivo y por el tamañode pantalla. Para así permitir al usuario de tableta el cambio de vista según laorientación.

android : conf igChanges=" o r i e n t a t i o n | keyboardHidden | s c r e enS i z e "

Pero debemos restringir esta acción en caso de que se trate de un smartphone. Paraello, debemos comprobar antes de cargar la vista en el MainActivity.java si se tratade un smartphone. Si es tal el caso bloqueamos la orientación de la aplicación enexclusivamente en vertical. Ya que la con�guración de la vista en smartphone soloesta implementada en vertical.

i f ( ! i sTab l e t ( ) ) {se tReques tedOr i entat ion ( Ac t i v i t y I n f o .SCREEN_ORIENTATION_PORTRAIT) ;

}

Para hacer la comprobación solo es necesario usar la función isTablet(). Esta funciónpropia determina si la aplicación se está ejecutándo en un tableta o no compro-bando la con�guración actual de la misma. Esta se usa también para indicarle aAdapterFragment que Fragment debe cargar como se puede ver en la �gura 11.13.

74

Capítulo 11. Implementación

11.6.3. Tipografía

Para el desarrollo de la aplicación se ha utilizado dos tipografías externas con el�n de conseguir una interacción más cercana y asociada al aprendizaje en algunoselementos de la interfaz de usuario. Las fuentes utilizadas son:

Blokletters-Viltstift [21]

WC_RoughTrad [28]

Para su uso ha sido necesario usar la clase Typeface, esta permite especi�car el tipode letra y estilo de una fuente la cual puede asociarse a distintos elementos Viewcomo son botones o cajas de texto. Hay que indicar que ambas tipografías son delicencia gratuita para uso no comercial, así que si �nalmente se pone precio a estaaplicación o sacamos partido de ella de alguna forma debemos ponernos en contactocon sus autores o buscar alternativas a estas tipografías.

11.6.4. Animaciones

También se ha incluido a la interacción del usuario simples animaciones realizadas através de los siguientes elementos.

Shape. Se generan mediante un archivo XML que de�ne una forma geométrica ,incluyendo colores, degradados y transformaciones de este. Se suelen almacenaren el directorio drawable del proyecto. Y se suelen utilizar en distintos tipos deView como botones, cajas de texto, etc.

Selector. Viene de�nidos por un archivo XML y determinan varios estado vi-suales de un objeto View. Para de�nir los diferentes estados usa Items y estos asu vez poseen como atributo un Shape. También se almacenan en el directoriodrawable del proyecto.

11.6.5. Almacenamiento permanente de datos

Puesto que a la hora de realizar la aplicación es posible cambiar ajustes como el idio-ma o el dialecto es necesario almacenar datos en el dispositivo de forma permanentepara evitar que el usuario tenga que con�gurar la aplicación cada vez que la inicie.Para ello, Android nos permite guardar pares de datos mediante SharedPreferenceseste método está ideado para almacenar pares clave-valor con datos primitivos(ints,booleans, strings) y no debe utilizarse para almacenar grandes cantidades de infor-mación.

75

Capítulo 11. Implementación

Pero en este caso como decíamos solo necesitamos guardar dos valores primitivosrelacionados con las opciones seleccionadas en los ajustes de la aplicación. Por ello,nos centramos en el uso de SharedPreferences. Que se basa en el uso de un archivode con�guración para almacenar los datos en cuestión.

La clase SharedPreferences permite usar sus métodos, funciones y procedimientospara leer y escribir en el �chero de con�guración de la aplicación. Esta guardará susdatos de con�guración en uno (o varios) �cheros de tipo XML, ubicados dentro dela carpeta de instalación de la aplicación.

11.6.6. Soporte multilenguaje

Otro de los aspectos que se ha tenido en cuenta es el de que personas que no sabennada sobre el lenguaje español tengan la posibilidad de usar la aplicación en inglés.Manteniendo siempre el contenido que presentamos intacto, es decir, en español. Solovarían los menús, las opciones y ajustes.

La realización de esta funcionalidad no fue muy complicada gracias a la forma en laque trabajan los �cheros de idiomas en las aplicaciones Android. Basta con tener unarchivo xml de strings por cada idioma en el que se quiera visualizar la aplicación,que contenga conjuntos de pares clave-valor indicando que contenido es el que sedesea poner en cada idioma. Y ya el sistema operativo seleccionará por defecto el�chero que crea oportuno en función del idioma del propio S.O. Pero también esposible cambiarlo en los ajustes de la aplicación.

A continuación se muestra una pequeña parte del archivo de strings de cada idiomacomo ejemplo.

Directorio: res/values/strings

<resource s><s t r i n g name="drawer_open">Abierto</s t r i ng><s t r i n g name="drawer_close ">Cerrado</s t r i ng>

<s t r i n g name="simple_button">Formas Simples</s t r i ng><s t r i n g name="compuesto_button">Formas Compuestas</s t r i ng>

Directorio: res/values-en/strings

<resource s><s t r i n g name="drawer_open">Open</s t r i ng><s t r i n g name="drawer_close ">Close</s t r i ng>

<s t r i n g name="simple_button">Simple forms</s t r i ng><s t r i n g name="compuesto_button">Compound forms</s t r i ng>

76

Capítulo 11. Implementación

Como se puede ver para que esta funcionalidad sea posible es necesario tener encuenta el nombre que se le asigna al directorio que contiene las strings y se debeasignar el mismo nombre clave a las strings para tener su equivalencia. El primeroes el de español por defecto y el segundo se usará en dispositivos donde el S.O. estécon�gurado en inglés. Pero siempre existirá la posibilidad de cambiarlo en la vistade ajustes de la aplicación.

Pero para poder cambiar el lenguaje en la vista de ajustes es necesario previamente,darle permisos a la aplicación de que se apliquen cambios cuando es modi�cado elidioma. Para ello, es necesario añadir en el android_manifest.xml a la aplicación:

android : conf igChanges=" l o c a l e "

11.7. Otras funcionalidades

Tras implementar todo lo indicado previamente se ha añadido algunas funcionalida-des más que mejoran las características de la aplicación. Estas son:

11.7.0.1. Sintetizador de voz

Uno de las funcionalidades añadidas más interesantes es el uso del sintetizador devoz TextToSpeech (TTS). El cual, nos permite reproducir cualquier texto que lesuministramos en todos los dispositivos Android puesto que se trata de una libreríaque fue añadida en las primeras versiones del sistema operativo.

Su uso es bastante simple, ya que es su�ciente con generar un objeto de la clase Text-ToSpeech. Esta clase se caracteriza por su constructor, el cual, usa dos parámetrosde entrada. Estos son el contexto en donde nos encontramos y el evento que genera.

miLector = new TextToSpeech ( context , this ) ;

Pero también es necesario sobrescribir el método onInit de la interfaz TextToS-peech.OnInitListener para que la clase funcione correctamente y sea posible capturarexcepciones que se puedan producir al usar este tipo de objetos.

77

Capítulo 11. Implementación

@Overridepublic void on In i t ( int s t a tu s ){

i f ( s t a tu s != TextToSpeech .ERROR){Locale spani sh = new Locale ( " es " , "ES" ) ;miLector . setLanguage ( spani sh ) ;miLector . setSpeechRate ( 0 . 8 )

preparado= true ;} else {

preparado=fa l se}

}

Como se puede visualizar uno de los elementos de la clase TextToSpeech() que sedebe usar es el método setLanguage(). Dicho método nos permite indicarle qué idio-ma debe usar para llevar a cabo la reproducción de voz. En este caso siempre sedebe reproducir en español. También es posible modi�car la velocidad del sinteti-zador a la hora de reproducir el sonido. Para ello, solo es necesario usar la funciónsetSpeechRate().

Por último, solo nos queda ver la instrucción que nos permite escuchar en el momentodeseado el texto a reproducir. Este método es speak(), este posee 3 parámetros. Eltexto a reproducir, el tipo de encolado de las reproducciones, en nuestro caso se borrauna vez reproducido el texto, y un tercero que suele ponerse como nulo que se usacon la �nalidad de de�nir parámetros de la reproducción como puede ser el volumen,etc.

miLector . speak ( texto , TextToSpeech .QUEUE_FLUSH, null ) ;

11.7.0.2. Compartir

Otra de las funcionalidades añadidas a la aplicación es la de permitir al usuariocompartir la información que está visualizando. Para ello, es necesario habilitar laacción usando una serie de elementos en el código. Solo será necesario usar un intenten el que se debe especi�car la acción que deseamos lanzar. Existen varias accionesdisponibles pero nos centraremos en ACTION_SEND, la cual, indica que el intentenviará datos de una actividad a otra, cosa que puede hacerse incluso entre activi-dades en distintos procesos. Para enviar datos solo es necesario especi�car el dato ysu tipo. Posteriormente el sistema identi�cará las actividades que pueden recibirlo yse las mostrará al usuario.

78

Capítulo 11. Implementación

In tent env io In t en t= new In tent ( ) ;env io In t en t . AddFlags ( Act i v i tyF lag s . NewTask ) ;env io In t en t . s e tAct ion ( Intent .ACTION_SEND) ;env io In t en t . putExtra ( In tent .EXTRA_TEXT, texto ) ;env io In t en t . setType ( " text / p l a i n " ) ;contexto . s t a r tAc t i v i t y ( env io In t en t ) ;

11.7.0.3. Copiar

La última de las funcionalidades añadidas han sido la del uso del portapapeles paracopiar la conjugación o la forma verbal concreta que desee el usuario. Se basa en eluso de un objeto llamado ClipboardManager al que se le establece un Clip, el cual,guarda el texto a copiar. Para su posterior pegue en otra aplicación del sistema. Suuso es bastante simple, solo es necesario usar las 3 siguientes líneas de código.

ClipboardManager c l i pboa rd = ( ClipboardManager ) contexto . getSystemServ ice( contexto .CLIPBOARD_SERVICE) ;

ClipData c l i p = ClipData . newPlainText ( " l a b e l " , textoACopiar ) ;c l i pboa rd . setPr imaryCl ip ( c l i p ) ;

79

Capítulo 12

Estimación de costes

12.1. Recursos materiales

No ha sido necesario ningún recurso material más allá de un ordenador personal losu�ciente potente como para hacer uso de Android Studio o Eclipse para trabajarcon él. Así como para hacer uso de los distintos emuladores de dispositivos móvilesde los que disponemos mediante el AVD manager de Android. Por ello, el costepara obtener este ordenador personal es de 789 ¿ + 23¿ para darse de alta comodesarrollador Android y poder subir la aplicación a Play Store.

12.2. Recursos humanos

En esta sección se evaluará el coste del trabajo realizado por el estudiante. Para llevara cabo esta tarea la mejor aproximación es tener en cuenta un sueldo razonable parael desarrollador y calcular el total requerido para el tiempo trabajado. Considerandoun sueldo de 12 ¿ la hora dada la situación laboral en el sector en España, el totalen recursos humanos sería el siguiente:

12¿/hora x 860 horas = 10.320 ¿

12.3. Coste total

Concepto Precio

Recursos materiales 812 ¿Recursos humanos 10.320 ¿

Total 11.132 ¿

80

Capítulo 13

Modelo de negocio

En cuanto al modelo de negocio existen dos posibilidades para la aplicación. Que estasea gratuita (con limitaciones o publicidad) o que sea de pago, ambos modelos tienensus ventajas pero tenemos que conocer bien qué ofrece cada uno y cómo podemossacar provecho de él.

Gratis (con limitaciones o publicidad) siempre resulta muy atractivo para los usuariospotenciales. No pierden nada por probarla por lo que saben que el riesgo es cero. Siles gusta se quedará en su smartphone o tableta, si no se desinstalará y sólo habráninvertido unos cuantos minutos en trastear con ella.

Sin embargo, las aplicaciones gratuitas se asocia a veces con productos poco elabo-rados. Provocando que tenga atractivo las aplicaciones de pago por parte del sectorconsumidor como ocurre especialmente en plataformas como iOS donde la idea deque si es de pago tiene que ser bueno.

Sabiendo esto hemos llegado a la conclusión de que la mejor apuesta sería publicar2 versiones.

La primera gratuita basándonos en que el usuario probará la aplicación y nospermitirá generar ingresos mediante el añadido de publicidad.

Y una segunda versión premium que permitirá al usuario usar la aplicación porunos 0.99¿. Puesto que se supone que es el tope para muchos usuarios que nocreen necesario pagar más por una app.

13.1. Marketing

Los medios más económicos para darse a conocer son las redes sociales, es por ello,que se deberían usar las más populares para aumentar las posibilidades de conseguir

81

Capítulo 13. Modelo de negocio

el mayor número de usuarios y fomentar el uso entre los posibles miembros de nuestromercado. Estas serían facebook y twitter.

13.2. Estimación de ganancias

Puesto que no disponemos de un histórico de las ganancias por cada una de lasaplicaciones competidoras ni tan siquiera de una ellas. Lo que hemos hecho ha sidorecoger los datos que nos aporta Play Store para estimar las ganancias que podríaproducir nuestra aplicación a lo largo de una año. Para ello, comprobamos las des-cargas de cada uno de nuestros competidores y el tiempo que llevan en la plataformaPlay Store. Con esto obtenemos las descargas por año de las versiones gratuitas ylas de pago.

Competidores Desc. Desc. premiun Meses Desc./año Desc./año premiun

C1 30000 300 41 8703 87,03C2 30000 - 17 20849 -C3 30000 750 22 16463 411,58C4 300000 - 33 110092 -C5 750000 5000 68 132809 885,39

Cuadro 13.1: Descargas de los competidores y promedio anual

Una vez tenemos estos datos, podemos saber que el número de descargas premiumserá de 1.364% del total de descargas gratuitas y partiendo de que del coste dela aplicación solo obtendremos bene�cios del 70% de la venta, puesto que el 30%restante se lo quedará el servicio de Play Store.

Por otra parte, en cuanto a las descargas gratuitas partimos de que cada usuariode la versión gratuita usará de media 3 veces la aplicación con lo que cada uso nosaportará ganancias por publicidad.

Tipo de aplicación Precio Descargas Bene�cios anuales

Premium 0,99x0,7 = 0,693 788 546,11¿Free (Publicidad) 0,02 56995 3419,71¿

Cuadro 13.2: Estimación de ganancias

Para terminar solo nos queda indicar que la estimación total anual sería de unos3965,82¿ y en 3 años habríamos recuperado la inversión con unos 11897,46 ¿.

82

Capítulo 14

Fase de pruebas

En este punto se pretende dejar constancia de las pruebas realizadas a lo largodel desarrollo del proyecto. Durante esta fase se somete a evaluación la aplicación,permitiendo así veri�car su calidad y si cumple con todos los requisitos indicadosdurante la fase de análisis.

La fase de prueba se lleva a cabo a lo largo del ciclo de vida del proyecto, no seproduce solo al �nal. Puesto que se integra dentro de cada etapa del desarrollo. Deesta forma, los errores se detectan lo antes posibles y son corregidos antes de queel proyecto se vuelva más complejo y dependiente. Durante la implementación serealizaron diversos tipos de pruebas a continuación expondremos algunas de ellas.

14.1. Pruebas de rendimiento

Este tipo de pruebas, en ingeniería de software, son aquellas que se realizan desde unaperspectiva que nos permite determinar lo rápido que ejecuta una tarea un sistemaen determinadas condiciones. De tal forma que puede servir para validar y veri�cardeterminados atributos de la calidad del sistema, como la �abilidad y uso de recursos.El objetivo de este tipo de pruebas es averiguar el tiempo dedicado a la ejecución dedistintas partes del programa para detectar los puntos problemáticos y áreas dondesea posible llevar a cabo una optimización del rendimiento.

Para realizar este tipo de pruebas se usó una clase cronómetro que mide los tiemposde repuestas de algunas funciones y procedimientos del sistema. Como son las distin-tas peticiones a los diferentes servicios remotos. Estas pruebas han estado activadasdurante gran parte del desarrollo, incluso gracias a ellas, se rediseño la arquitecturadel sistema, ya que los tiempos de espera sin el sistema local de notas eran muygrandes inicialmente. Este factor propicio gran parte del retraso en el desarrollo dela aplicación.

83

Capítulo 14. Fase de pruebas

14.2. Pruebas de validación

Las pruebas de validación consisten en la revisión que permite veri�car que el siste-ma de software implementado cumple con las expectativas y logra su cometido. Esuna parte del proceso de pruebas software de un proyecto, que utiliza técnicas deevaluación, inspecciones y tutoriales. La validación es un proceso de comprobaciónpara saber que lo que se ha especi�cado es lo que el usuario realmente quería.

Consiste en evaluar el sistema o parte de este durante o al �nal del desarrollo paradeterminar si satisface los requisitos iniciales. Este tipo de pruebas se hacían a medidaque se mostraban los distintos prototipos al tutor. Puesto que en esos momentos secomprobaba si se llevaban a cabo las tareas especi�cadas.

Un caso de este tipo de pruebas fue cuando se corrigió el error de que todo verbosolo tiene una conjugación posible, lo cual, no es cierto y no se contemplaba. Y tuvoque implementarse una lista desplegable en el menú que solo es visible para aquellosverbos que tuviesen más de una conjugación. De hecho, con este tipo de pruebas secorrigieron muchos errores de análisis.

14.3. Pruebas de usabilidad

Estas pruebas están centradas en el usuario �nal para evaluar un producto mediantepruebas con el mismo. Se centran en medir la capacidad de un producto en cumplirel propósito par el cual fue diseñado. Este tipo de pruebas miden la facilidad de uso.Consisten en seleccionar a un grupo de usuarios de la aplicación y solicitarles quelleven a cabo las tareas para las cuales fue diseñada, mientras que el diseñador/desa-rrollador toman nota de la interacción, particularmente de los errores y di�cultadescon las que se encuentran los usuarios.

Es importante tener en cuenta que no es necesario que se trate de una aplicacióncompletamente terminada, pudiendo tratarse de un prototipo.

Esta tipo de pruebas se han llevado a cabo 2 veces a lo largo del desarrollo, la primera,se realizó casi justo al �nal de la implementación, de la cual, se han obtenido muchasindicaciones para la mejora en la usabilidad. La segunda fue realizada previa a abrirlaal público. Esta última no ha sido tan enriquecedora, pero si nos ha permitido ponerla aplicación en la tienda con algo de seguridad en cuanto a la calidad que deseamosproporcionar.

84

Capítulo 15

Conclusiones

15.1. Conclusiones enfocadas al producto

El resultado obtenido del desarrollo de este proyecto ha sido una aplicación de grannivel de calidad, puesto que será publicada en Play Store. Cuyo uso es el de obtenerlas conjugaciones de un verbo e información relacionada con estas. Esta podrá serutilizada exclusivamente en plataformas Android. De hecho, el producto es usable apartir de la versión 2.3 de Android en adelante. Dado que se plani�co desde el iniciode su desarrollo abarcar el mayor número de dispositivos posible.

15.2. Conclusiones personales

La realización de este proyecto me ha aportado conocimientos sobre varias tecnologíasque no dominaba pero sobretodo de cómo desarrollar una aplicación que tenga unafunción práctica y útil para un gran grupo de usuarios. Además, a través de su estudiohe podido experimentar cómo evoluciona la tecnología de desarrollo Android, la cual,todavía sigue realizando avances rápidamente.

Por otra parte, el desarrollo ha sido muy interesante dado al gran abanico de posi-bilidades que ofrece Android, siendo imposibles recogerlas todas en este documento.Sin embargo, exitían ciertas limitaciones en cuanto a los emuladores, aunque es esteaspecto ha mejorado mucho con Android Studio. Aún así, son un buen punto deapoyo para realizar las primeras pruebas de una manera rápida y sencilla.

85

Capítulo 15. Conclusiones

15.3. Conclusiones �nales

Por último, solo nos queda indicar que el proyecto ha sido un exito, puesto que seha consiguido alcanzar todos los objetivos planteados inicialmente. Consiguiendo así,una aplicación vistosa y con una gran cantidad de funcionalidades. Podrían mejorarsealgunos aspectos o añadirse algunas funcionalidades más, pero cumple con todo lonecesario para que los usuarios hagan uso de ella.

86

Capítulo 16

Trabajos futuros

Con este proyecto se abren algunas líneas de desarrollo futuro, por una parte, ten-dríamos las mejoras de la aplicación en sí. Dentro del sistema operativo Android,mis propuestas serían las siguientes:

16.1. Ampliaciones del producto

La principal forma de mejorar la aplicación es con la implementación de todoel sistema de información en local. Para así, evitar la necesidad de conexióna Internet para el uso de la aplicación. Lo cual, podría suponer un problemapara el departamento TIP, puesto que tendrían que mantener dos sistemas deinformación y no uno como hasta ahora. Además del peso en memoria quetendría la aplicación, puesto que almacenaría mucha mas información.

Otra posible mejora de la aplicación sería usar la geolocalización para deter-minar el dialecto por defecto que se debe asociar a la aplicación, en función deque zona de habla hispana se encuentre más cercana.

Añadir un historial de búsqueda a la interfaz de búsqueda de verbos o unsistema de recomendaciones. Aunque ya la mayoría de versiones de Androiddispone del sistema de recomendaciones en su interfaz de teclado.

Tener en cuenta nuevos tipos de dispositivos como son los televisores Android,para tener una buena interfaz acorde a sus características.

87

Capítulo 16. Trabajos futuros

16.2. Otras propuestas

Por otra parte, no hay que olvidarse de la competencia y sus productos en esteterreno. Sería lo ideal disponer de una aplicación equivalente para cada sistema ope-rativo disponible. Pero igual eso sería proponer demasiado. Sin embargo, si entraríadentro de lo posible desarrollar una aplicación equivalente para iPhone. Puesto quese trata del SO que mayor competencia hace actualmente a Android.

88

Capítulo 17

Anexo I: Manual de uso

En el siguiente apartado se procede a explicar las operaciones que se pueden realizaren nuestra aplicación.

Vista principal

Para empezar a hacer uso de la herramienta y aprovechar todas las posibilidadesque ofrece el sistema, es necesario buscar un verbo mediante el icono de la lupa parabuscar.

Figura 17.1: Manual de uso: Vista de la aplicación

1. En primer lugar hay que tener en cuenta que un verbo puede tener múltiplesformas de ser conjugado normalmente en función de su signi�cado. Por ello,hay verbos que nos darán la posibilidad de cambiar la conjugación a visualizar

89

Capítulo 17. Anexo I: Manual de uso

mediante una lista expandible como la que aparece en la Figura 11.11. Tras esto,lo siguiente sería usar las pestañas superiores para �ltrar por formas simples oformas compuestas.

2. Y dentro de la forma elegida podemos usar las pestañas secundarias para mo-vernos por los modos indicativo, subjuntivo e imperativo si estamos en formassimples o indicativo y subjuntivo si estamos en formas compuestas. Y tambiénusar nuestro dedo para desplazarnos manualmente mediante el deslizamientolateral por los distintos tiempos.

Esto puede ser confuso para el usuario, pero para evitarlo disponemos de una pequeñarepresentación de las distintas páginas que conforman los tiempos que componenla forma actual en la parte inferior de la aplicación Figura 11.3. Y a medida queavanzamos usando nuestro dedo llegará a cambiar el modo en el que nos encontramos.Pudiendo ser indicativo, subjuntivo o imperativo esto se cambiará automáticamenteal cambiar de modo mediante el recorrido con nuestro dedo como se puede ver en laimagen Figura 11.12.

Una vez elegido el tiempo verbal que se desea visualizar es posible extraer dichainformación de forma conjunta o cada forma verbal. Para ello, basta con mantenerpulsado el texto que indica el título del tiempo verbal para extraer todas las formasque construyen el tiempo verbal. O también extraer únicamente una de las formasverbales que componen el tiempo verbal en cuestión.

La extracción se puede realizar de tres formas: para escuchar, para compartir o paracopiar

Figura 17.2: Manual de uso: Extracción de información

90

Capítulo 17. Anexo I: Manual de uso

Vista más información

Para acceder a esta vista que en realidad solo es un panel lateral situado a la derechade la vista principal solo es necesario pulsar el botón superior derecho y para volverlo mismo o pulsar el botón volver del propio dispositivo Android.

Pero centrémonos en esta vista, aquí podemos visualizar la persona, modo y tiempodel verbo introducido en primer lugar, el tipo de verbo que es en la conjugaciónactual, la de�nición de su signi�cado o signi�cados si los tiene, notas asociadas alámbito morfológico, ortográ�co, defectivo, etc. Así como una pequeña lista de losverbo que se conjugan de la misma forma. Para visualizar todo ello, solo hace faltausar la lista expandible que aparece en esta vista.

Figura 17.3: Manual de uso: Panel derecho

Vista de opciones

Esta vista es accesible mediante el botón superior izquierdo de la vista principal.Y nos permite visualizar la conjugación del verbo de distintas formas a las vistashabitualmente. Estas son negadas, con pronombres personales en femenino, en formapronominal si el tipo del verbo así lo permite y visualizar la frecuencia del Crea.Además de cambiar el dialecto de forma permanente. Las posibles opciones sonEspaña, Rio de la Plata, Canarias, Tratamiento formal.

Por otra parte esta vista nos permite también acceder a la vista de ajustes generalesde la aplicación mediante el botón ajustes.

También permite al usuario visualizar notas acerca del uso de la aplicación.

91

Capítulo 17. Anexo I: Manual de uso

Figura 17.4: Manual de uso: Panel izquierdo

Vista de ajustes generales

En esta vista el usuario puede realizar 2 acciones

1. Puede cambiar el idioma de la aplicación, no el de su contenido solo el de losmenús y botones. Las posibilidades son español, es la opción por defecto, einglés.

2. Puede acceder a la página web del grupo TIP para más información.

Figura 17.5: Manual de uso: Ajustes

92

Capítulo 18

Anexo II: Comparativa con otrasaplicaciones

En esta sección pretendemos hacer un breve análisis de cada una de las aplicacionesque se presentan como competencia directa de la desarrollada durante este proyecto.A continuación puede verse brevemente el análisis de las principales característicasde cada una de ellas y que la última de todas sería nuestra aplicación.

1. Conjugador Español

Interfaz (Muybuena)

- Simple- Agradable a la vista- Poco estructurada

Funcionalidad(Poco �able)

- Nos informa únicamente de los tiempos verbales delverbo introducido en in�nitivo.- Uso limitado de la versión gratuita a 5 consultas.- No posee publicidad

Manejabilidad(Buena)

- Simplemente se basa en el desplazamiento vertical paraver toda la información.

Requiereconexión aInternet

Si

93

Capítulo 18. Anexo II: Comparativa con otras aplicaciones

2. Conjugador de verbos españoles

Interfaz (Buena) - Básica- Poco atractiva- Poco estructurada

Funcionalidad(Su�ciente)

- Nos informa únicamente los tiempos verbales del verbointroducido en cualquier forma.- Posee publicidad que puede incomodar el uso de laaplicación para el usuario.

Manejabilidad(Muy buena)

- Se basa también en el desplazamiento vertical para vertoda la información.- Posee la capacidad de cambiar la vista en función de laposición del dispositivo Android.

Requiereconexión aInternet

Si

3. Verbos españoles

Interfaz (Muybuena)

- Simple- Agradable- Bastante intuitiva

Funcionalidad(Su�ciente)

- Nos informa únicamente los tiempos verbales del verboelegido de un listado de verbos.- Posee publicidad que puede incomodar el uso de laaplicación para el usuario.- Esta limitada en 700 verbos a conjugar

Manejabilidad(Muy buena)

- Se basa también en el desplazamiento vertical para vertoda la información y 3 pestañas que permiten cambiarentre modo indicativo, subjuntivo e imperativo.

Requiereconexión aInternet

No

94

Capítulo 18. Anexo II: Comparativa con otras aplicaciones

4. Conjugador de verbos españoles 2

Interfaz (Buena) - Básica- Poco atractiva (Aunque resalta las formas verbalesirregulares).- Intuitiva

Funcionalidad(Poco �able)

- Nos informa únicamente los tiempos verbales del verbointroducido ya sea un verbo o no lo tomará comoin�nitivo de un verbo- Posee publicidad que puede incomodar el uso de laaplicación para el usuario.

Manejabilidad(Muy buena)

- Se basa únicamente el desplazamiento vertical para vertoda la información.

Requiereconexión aInternet

No, pero como se menciona anteriormente conjugacualquier palabra introducida sea o no verbo.

5. Verbos Españoles 2

Interfaz(Su�ciente)

- Básica- Poco vistosa (Aunque es posible cambiar los colores).- Poco intuitiva.

Funcionalidad(Excelente)

- Nos informa de los tiempos verbales del verbo elegido deuna lista limitada.- Posee una sección de gramática donde es posibleestudiar las reglas de los verbos regulares.- Permite escuchar las formas verbales.- No posee publicidad

Manejabilidad(Buena)

- Se basa en el desplazamiento vertical para ver toda lainformación sobre los tiempos verbales.- Para acceder a la vista de la sección de gramática solohay que usar el menú de la cabecera, el cuál no es muyintuitivo.

Requiereconexión aInternet

Si

95

Capítulo 18. Anexo II: Comparativa con otras aplicaciones

6. Conjugador TIP

Interfaz (Muybuena)

- Simple- Atractiva.- Intuitiva

Funcionalidad(Excelente)

- Nos informa de los tiempos verbales del verbointroducido en cualquier tiempo verbal.- Identi�ca el verbo introducido (tiempo, persona, número)- Posee notas asociadas a las conjugaciones que permitenver que reglas se aplican en estas- Permite escuchar las formas verbales.- Permite compartir las formas verbales.- Permite copiar las formas verbales.- No posee publicidad

Manejabilidad(Excelente)

- Se basa en el uso de pestañas que estructuran mejor lainformación y deslizamiento lateral para cambiar detiempo verbal- Posee un menú de navegación para acceder a lasopciones y a las notas asociadas.

Requiereconexión aInternet

Si

Para resumir solo nos queda ver de forma uni�cada las distintas puntuaciones asocia-das a los distintos aspectos destacados en los distintos análisis que se han evaluadodurante el análisis.

App/Características Interfaz Funcionalidad Manejabilidad InternetConjugador español Si

Conjugador deverbos españoles

Si

Verbos españoles NoConjugador de

verbos españoles 2No

Verbos españoles 2 Si

Conjugador TIP SiLeyenda: rojo(Poco �able), naranja (Su�ciente), amarillo(Buena), verde(Muy

buena), Azul(Excelente)

Cuadro 18.1: Comparativa con otras aplicaciones

96

Capítulo 18. Anexo II: Comparativa con otras aplicaciones

Como se puede ver la calidad �nal de las aplicaciones en general no es del todo bueno,puede ser que por ello sean todas gratuitas. Por tanto, considerando el análisis vistopodemos decir que la mejor aplicación vista es la nuestra el Conjugador TIP segúnlos criterios de calidad analizados en todas las aplicaciones La única desventaja esque requiere de conexión a Internet para su uso, pero, por otro lado, no se encuentralimitada a un grupo de verbos reducido como ocurre con aquellas que no requierenconexión a Internet que solo disponen de 700 verbos aproximadamente.

97

Capítulo 19

Anexo III: Especi�caciones delanálisis

Para comodidad en la lectura del documento se ha querido detallar la especi�caciónde los casos de uso de los usuarios en este apartado. De tal forma, que si el lectordesea obtener información detallada sobre algún caso de uso concreto, tendrá laposibilidad de buscarlo en esta sección.

Modelo de casos de usos

En este apartado se determinan los casos de uso del sistema. Lo primero que veremosserán los actores y luego se expondrán los casos de uso de cada uno de ellos. Cada casode uso se especi�cará con una �cha descriptiva que poseerá los siguientes campos:

Identi�cación: valor numérico secuencial único que reconoce al caso de uso.

Nombre: es el apelativo que se le ha asignado al caso de uso y debe ser lo másexplicativo posible.

Actores: Indica a los usuarios del sistema que participan en la realización de laoperación que implica el caso de uso.

Descripción: texto explicativo que detalla las razones y el resultado del caso deuso.

Precondiciones: establece qué es lo que debe cumplirse siempre antes de co-menzar un escenario de caso de uso.

98

Capítulo 19. Anexo III: Especi�caciones del análisis

Post-condiciones: detallan que debe cumplirse cuando el caso de uso se com-pleta con éxito.

Flujo normal: describe el camino de éxito típico que se alcanza cuando todosale según lo planeado

Flujo alternativo: Indica todo los escenarios posibles, ya sean de éxito comode fracaso, que puede presentar el caso de uso en cuestión. La combinación del�ujo normal y del �ujo alternativo debe satisfacer todos intereses.

Id 01Nombre Buscar verboCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción Permite al usuario escribir el verbo a buscar y teneracceso a la información sobre éste.

Precondición 1. El usuario debe haber ejecutado la aplicación.2. El usuario deberá buscar un verbo

PostCondición El sistema debe buscar la información relacionada coneste verbo y mostrarla en la vista de la aplicación.

Flujo normal 1. El usuario le da a buscar verbo.2. El sistema trata de reconocer al verbo3. El verbo es reconocido y se obtiene a la información yla información es mostrada

Flujo alternativo 2. El verbo no es reconocido3. Se informa al usuario y la información no es mostrada

Cuadro 19.1: Tabla de caso de uso Buscar verbo

99

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 02Nombre Cambiar conjugaciónCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción Permite al usuario elegir entre las distintas conjugacionesque posee éste, ya que solo es posible visualizar una en lavista de la aplicación.

Precondición 1. El usuario debe haber ejecutado la aplicación2. El usuario debe haber buscado un verbo con multiplesconjugaciones.3. Al menos debe tener 2 formas de conjugarse distintas.

PostCondición Cambia la conjugación visualizada en la vista principalFlujo normal 1. El usuario le da a buscar verbo con varias formas de

conjugarse.2. El usuario le da a una lista desplegable y selecciona laconjugación que desee.

Flujo alternativo 1. No hay lista desplegable puesto que no se haencontrado ningún verbo o la conjugación del verbo noposee ninguna nota asociada

Cuadro 19.2: Tabla de caso de uso Cambia conjugación

100

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 03Nombre Cambia formaCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción

Permite al usuario elegir mediante pestañas entrevisualizar las formas simples o compuestas de laconjugación del verbo. Por defecto, aparece seleccionadaslas formas simples.

Precondición1. El usuario debe haber ejecutado la aplicación2. El usuario debe haber pulsado alguna de las pestañasque indican la forma

PostCondiciónEl sistema debe mostrar las formas que determine elusuario.

Flujo normal

1. Si se eligen formas simples. Se debe visualizar tiemposen formas simples2. Si se eligen formas compuestas. Se deben visualizartiempos en formas compuestas

Flujo alternativo

Cuadro 19.3: Tabla de caso de uso Cambia forma

101

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 04Nombre Cambia modoCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción

Permite al usuario elegir mediante pestañas entrevisualizar los tiempos en indicativo, subjuntivo eimperativo de la conjugación del verbo. Por defecto,aparece seleccionado el modo indicativo.

Precondición1. El usuario debe haber ejecutado la aplicación2. El usuario debe haber pulsada alguna de las pestañasque indican el modo a visualizar

PostCondiciónEl sistema debe mostrar los tiempos en el modo quedetermine el usuario.

Flujo normal

1. Si se elige modo indicativo. Se debe visualizar el primertiempo en modo indicativo.2. Si se elige modo subjuntivo. Se deben visualizar elprimer tiempo en modo subjuntivo.3. Si se elige modo imperativo. Se debe visualizar elimperativo.

Flujo alternativoEn el caso de tener formas compuestas seleccionadasdesaparecerá la opción de imperativo, con lo que no podráser elegida

Cuadro 19.4: Tabla de caso de uso Cambia modo

102

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 05Nombre Cambio deslizanteCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción

Permite al usuario moverse mediante el deslizamientousando su dedo por los distintos tiempos verbales de laforma y conjugación elegida. El modo cambiaráautomaticamente una vez se alcance una tiempo verbalque le pertenezca.

Precondición1. El usuario debe haber ejecutado la aplicación2. El usuario deberá deslizar el dedo por una parte de lapantalla de izquierda a derecha o viceversa.

PostCondiciónEl sistema deberá hacer las transiciones de las vistascuando detecte el desplazamiento gestual.

Flujo normalCada desplazamiento hacia la izquierda o hacia la derechamostrara un nuevo tiempo verbal.

Flujo alternativoEn el caso de no tener mas tiempos que mostrar hacia unade las dirección, no se realizarán transiciones en esadirección.

Cuadro 19.5: Tabla de caso de uso Cambia modo

103

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 06Nombre Acceso a notasCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción

Permite al usuario visualizar las notas asociadas a laconjugacion del verbo seleccionada actualmente. Estaspueden ser genericas, importantes, morfológicas,ortográ�cas, defectivas, sobre participio irregular, de uso yde verbo que se conjugan de la misma forma.

Precondición1. El usuario debe haber ejecutado la aplicación3. El usuario deberá pulsar el botón que le da acceso a lavista de las notas.

PostCondición Se muestra la vista de notas

Flujo normalAl pulsar el botón se mostrara un listado de las distintasnotas.

Flujo alternativoSi no se ha buscado ningun verbo se mostrará una listavacia.

Cuadro 19.6: Tabla de caso de uso Acceso a notas

104

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 07Nombre Modi�car opcionesCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción

Esta acción permite al usuario cambiar distintos aspectosde la aplicación ya sean opciones de conjugación de lasformas verbales mostradas o preferencias generales delsistema.

Precondición1. El usuario debe haber ejecutado la aplicación3. El usuario deberá pulsar el botón que le da acceso a lavista de opciones.

PostCondición Se muestra la vista de opciones.

Flujo normalAl pulsar el botón se mostrara un listado de opcionessobre la conjugación y el acceso a preferencias generales.

Flujo alternativoSi no se ha buscado ningun verbo se mostrará una listavacia.

Cuadro 19.7: Tabla de caso de uso Modi�car opciones

105

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 24Nombre Opciones de conjugaciónCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

DescripciónEste acción nos permite acceder a la variación de loscomplementos de las formas verbales.

Precondición1. El usuario debe haber ejecutado la aplicación3. El usuario deberá pulsar el botón que le da acceso a lavista de opciones.

PostCondición Se muestra la vista de opciones de conjugación.

Flujo normalAl pulsar el botón se mostrará un listado compuesto deopciones de la conjugación, negación, femenino,pronominal, frecuencia del crea y dialecto.

Flujo alternativo

Cuadro 19.8: Tabla de caso de uso Opciones de conjugación

106

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 08Nombre Preferencias generalesCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

DescripciónEsta acción permite al usuario cambiar distintas opcionesgenerales del sistema.

Precondición

1. El usuario debe haber ejecutado la aplicación2. El usuario deberá pulsar el botón que le da acceso a lavista de opciones.3. El usuario deberá pulsar ajustes.

PostCondición Se muestra la vista de opciones generales.

Flujo normalAl pulsar el botón se mostrará un listado compuesto deopciones de idioma e ir a la web del grupo TIP.

Flujo alternativo

Cuadro 19.9: Tabla de caso de uso Preferencias generales

107

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 09Nombre Selecciona idiomaCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

DescripciónEsta acción permite al usuario cambiar el idioma generalde la aplicación, solo de los menús no del contenido.

Precondición

1. El usuario debe haber ejecutado la aplicación2. El usurio deberá pulsar el botón que le da acceso a lavista de opciones.3. El usuario deberá pulsar ajustes.4. El usario deberá pulsar en selección de idiomas.

PostCondiciónSe muestra un cuadro de dialogo con las opciones deidioma posibles.

Flujo normalAl elegir uno de los idiomas mostrados se actualizarátodos los textos de todas las vistas de la aplicación.

Flujo alternativo

Cuadro 19.10: Tabla de caso de uso Selecciona idioma

108

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 10Nombre Ir a la webCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

DescripciónEsta acción permite al usuario acceder a la pagina web delgrupo TIP abriendo el navegador web por defecto.

Precondición

1. El usuario debe haber ejecutado la aplicación2. El usurio deberá pulsar el botón que le da acceso a lavista de opciones.3. El usuario deberá pulsar ajustes.4. El usuario deberá pulsar en ir a la web.

PostCondición Se abre el navegador web con la web web del grupo TIP

Flujo normal1. La aplicación queda en segundo plano.2. El navegador web pasa a ser la aplicación en primerplano.

Flujo alternativo

Cuadro 19.11: Tabla de caso de uso Ir a la web

109

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 11Nombre Ver negadaCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

DescripciónEsta acción permite al usuario ver los distintos tiemposverbales con el verbo negado o no. Esto va en función dela decisión del usuario.

Precondición

1. El usuario debe haber ejecutado la aplicación2. El usuario deberá pulsar el botón que le da acceso a lavista de opciones.3. El usuario deberá elegir mediante una caja de check siquiere ver negada la conjugación o no.

PostCondición Se actualizarán todos los tiempos visualizados

Flujo normalAl elegir si desea o no ver los verbos negados seactualizará todos los textos del tiempo verbal de la vistaprincipal de la aplicación.

Flujo alternativo

Cuadro 19.12: Tabla de caso de uso Ver negada

110

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 12Nombre Ver en femeninoCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción

Esta acción permite al usuario ver los distintos tiemposverbales con el pronombre personal en femenino enaquellos casos que sea posible. Esto va en función de ladecisión del usuario.

Precondición

1. El usuario debe haber ejecutado la aplicación2. El usuario deberá pulsar el botón que le da acceso a lavista de opciones.3. El usuario deberá elegir mediante una caja de check siquiere ver en femenino la conjugación o no.

PostCondición Se actualizarán todos los tiempos visualizados

Flujo normalAl elegir si desea o no ver los verbos en femenino seactualizará todos los textos del tiempo verbal de la vistaprincipal de la aplicación.

Flujo alternativo

Cuadro 19.13: Tabla de caso de uso Ver en femenino

111

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 13Nombre Ver pronominalCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción

Esta acción permite al usuario ver los distintos tiemposverbales en forma pronominal o no. Esto va en función dela si la categoría gramatical del verbo lo permite y ladecisión del usuario.

Precondición

1. El usuario debe haber ejecutado la aplicación2. El usuario deberá pulsar el botón que le da acceso a lavista de opciones.3. El usuario deberá elegir mediante una caja de check siquiere ver en pronominal la conjugación o no.

PostCondición Se actualizarán todos los tiempos visualizados

Flujo normalAl elegir si desea o no ver los verbos en pronominal seactualizará todos los textos del tiempo verbal de la vistaprincipal de la aplicación.

Flujo alternativo

Cuadro 19.14: Tabla de caso de uso Ver pronominal

112

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 14Nombre Ver frecuencia del creaCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

DescripciónEsta acción permite al usuario ver los distintos tiemposverbales acompañados de su frecuencia del crea o no. Estova en función de la decisión del usuario.

Precondición

1. El usuario debe haber ejecutado la aplicación2. El usuario deberá pulsar el botón que le da acceso a lavista de opciones.3. El usuario deberá elegir mediante una caja de check siquiere ver la frecuencia del crea o no.

PostCondición Se actualizarán todos los tiempos visualizados

Flujo normalAl elegir si desea o no ver la frecuencia del crea seactualizará todos los textos del tiempo verbal de la vistaprincipal de la aplicación.

Flujo alternativo

Cuadro 19.15: Tabla de caso de uso Ver frecuencia del crea

113

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 15Nombre Elegir dialectoCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción

Esta acción permite al usuario cambiar entre 4 posiblesdialectos de la lengua española a la hora de conjugar losverbos. Los que tenemos disponibles son España, Rio de laplata, Canarias y tratamiento formal.

Precondición

1. El usuario debe haber ejecutado la aplicación2. El usuario deberá pulsar el botón que le da acceso a lavista de opciones.3. El usuario deberá pulsar en selección de dialecto.

PostCondición Motrará un cuadro de dialogo con las posibles acciones

Flujo normalAl elegir un dialecto se actualizará todos los textos deltiempo verbal de la vista principal de la aplicación.

Flujo alternativo

Cuadro 19.16: Tabla de caso de uso Elegir dialecto

114

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 16Nombre Acción con forma verbalCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción Esta acción permite al usuario escuchar la forma verbal

Precondición1. El usuario debe haber ejecutado la aplicación2. El usuario debe haber buscado un verbo existente3. El usuario deberá mantener pulsada la forma verbal.

PostCondición Motrará un cuadro de dialogo con las posibles acciones.Flujo normal Al elegir una acción se realizará.Flujo alternativo No elegir ninguna acción.

Cuadro 19.17: Tabla de caso de uso Acción sobre forma verbal

115

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 17Nombre Acción con tiempo verbalCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

DescripciónEsta acción permite al usuario elegir entre 3 posiblesfuncionalidades escuchar, compartir o copiar el tiempoverbal completo

Precondición

1. El usuario debe haber ejecutado la aplicación2. El usuario debe haber buscado un verbo existente3. El usuario deberá mantener pulsada título del tiempoverbal.

PostCondición Motrará un cuadro de dialogo con las posibles opciones.Flujo normal Al elegir una de las acciones se realizará.Flujo alternativo No elegir ninguna acción.

Cuadro 19.18: Tabla de caso de uso Acción sobre tiempo verbal

116

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 18Nombre Escuchar forma verbalCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción Esta acción permite escuchar el forma verbal

Precondición

1. El usuario debe haber ejecutado la aplicación2. El usuario debe haber buscado un verbo existente3. El usuario deberá mantener pulsada la forma verbal.4. El usuario deberá elegir escuchar entre las accionesdisponibles

PostCondiciónFlujo normal Se escuchará la forma verbal elegida por el usuarioFlujo alternativo

Cuadro 19.19: Tabla de caso de uso Escuchar forma verbal

117

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 19Nombre Compartir forma verbalCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

DescripciónEsta acción permite compartir la forma verbal para usarlaen otras aplicaciones

Precondición

1. El usuario debe haber ejecutado la aplicación2. El usuario debe haber buscado un verbo existente3. El usuario deberá mantener pulsada la forma verbal.4. El usuario deberá elegir compartir entre las accionesdisponibles

PostCondición

Flujo normalSe abrira un listado de las aplicaciones a las que podemoscompartir la forma verbal elegida por el usuario

Flujo alternativo

Cuadro 19.20: Tabla de caso de uso Compartir forma verbal

118

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 20Nombre Copiar forma verbalCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción Esta acción permite copiar forma verbal en el portapapeles

Precondición

1. El usuario debe haber ejecutado la aplicación2. El usuario debe haber buscado un verbo existente3. El usuario deberá mantener pulsada la forma verbal.4. El usuario deberá elegir copiar entre las accionesdisponibles.

PostCondiciónFlujo normal Se copiará la forma verbal elegida por el usuarioFlujo alternativo

Cuadro 19.21: Tabla de caso de uso Copiar forma verbal

119

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 21Nombre Escuchar tiempo verbalCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción Esta acción permite escuchar el tiempo verbal completo

Precondición

1. El usuario debe haber ejecutado la aplicación2. El usuario debe haber buscado un verbo existente3. El usuario deberá mantener pulsado el título del tiempoverbal.4. El usuario deberá elegir escuchar entre las accionesdisponibles.

PostCondición

Flujo normalSe escucharán todas las formas verbales que componen eltiempo verbal elegido por el usuario

Flujo alternativo

Cuadro 19.22: Tabla de caso de uso Escuchar tiempo verbal

120

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 22Nombre Compartir tiempo verbalCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción Esta acción permite compartir el tiempo verbal completo

Precondición

1. El usuario debe haber ejecutado la aplicación2. El usuario debe haber buscado un verbo existente3. El usuario deberá mantener pulsado el título del tiempoverbal.4. El usuario deberá elegir compartir entre las accionesdisponibles.

PostCondición

Flujo normalSe compartiran todas las formas verbales que componen eltiempo verbal elegido por el usuario

Flujo alternativo

Cuadro 19.23: Tabla de caso de uso Compartir tiempo verbal

121

Capítulo 19. Anexo III: Especi�caciones del análisis

Id 23Nombre Copiar tiempo verbalCreado por Gabriel Yeray Suárez PérezFecha decreación

11/09/2014

Modi�cado por Gabriel Yeray Suárez PérezFecha demodi�cación

21/04/2015

Actor principal UsuarioPersonalinvolucrado

Usuario

Descripción Esta acción permite copiar en el portapapeles el tiempoverbal completo

Precondición 1. El usuario debe haber ejecutado la aplicación2. El usuario debe haber buscado un verbo existente3. El usuario deberá mantener pulsado el título del tiempoverbal.4. El usuario deberá elegir copiar entre las accionesdisponibles.

PostCondiciónFlujo normal Se copiarán todas las formas verbales que componen el

tiempo verbal elegido por el usuarioFlujo alternativo

Cuadro 19.24: Tabla de caso de uso Copiar tiempo verbal

122

Capítulo 20

Anexo IV: Diseño de interfaceshumanas

La interfaz de una aplicación es uno de los aspectos más importantes, ya que esuno de los puntos más relevantes para que los usuarios hagan uso de la aplicación.Aunque también es la capa que hay entre el usuario y el corazón funcional de laaplicación.

Sin embargo, los objetivos de las interfaces humanas son más amplios de lo queparece, ya que buscan conseguir reducir la complejidad del software, que el softwareesté disponible para el mayor colectivo de personas posibles, reducir el esfuerzo ymejorar la productividad del usuario procurando la comodidad en el manejo delsoftware entre otras cosas.

Pero lo que nos interesa es alcanzar una buena interfaz software y para ello noscentraremos en los siguientes conceptos:

Interacción: esta una acción sobre un objeto que tiene una in�uencia o respuestasobre el actor.

Comunicación: que se basa en la transmisión de información mediante un có-digo común entre emisor y receptor.

Percepción: es un proceso que realiza el usuario para adquirir información delentorno a través de los sentidos.

Comprensión: es la capacidad del usuario para procesar la información sensoriale integrarla con sus intenciones.

El entendimiento de estos conceptos nos permiten profundizar más en los aspectos atener en cuenta durante el desarrollo de una buena interfaz software.

123

Capítulo 20. Anexo IV: Diseño de interfaces humanas

Darle el control al usuario: Con esto se quiere dejar claro que el usuario es el queinicia las acciones, ya que debe jugar un papel activo y no reactivo. Sin embargo,llegado el caso de que que se automatice una tarea, el usuario debe poder controlarla.Puesto que en ningún momento debe perderse la interactividad.

Aprovechar la realimentación (feedback): Esta nos ayuda a con�rmar que el softwareestá respondiendo a las acciones del usuario. Pero para que sea e�caz debe ser opor-tuna y adecuada. Permitir la manipulación directa: Proporciona una realimentaciónconstante sobre la tarea desempeñada. El usuario puede hacer las operaciones conrapidez, con menos errores y con menor esfuerzo mental.

Establecer coherencia: Permite a los usuarios aprovechar sus conocimientos existentesen nuevas tareas. Además, ayuda a que la interfaz sea familiar y predecible.

Integridad estética: El diseño grá�co debe ayudar a que el usuario comprenda lainformación que se presenta. Debe estar de�nido un estilo para la composición yorganización y los elementos visuales ayudan a captar la atención del usuario.

Permitir reversibilidad: El usuario no debe sentirse atemorizado al realizar las ope-raciones y debe poder deshacer operaciones que haya ejecutado.

Darle accesibilidad: Se debe intentar que el software sea utilizable y accesible apersonas con discapacidad.

124

Capítulo 21

Anexo V: Consecuencia del cambiodel diseño arquitectónico

Durante el desarrollo de este proyecto hubo un diseño arquitectónico previo que fuerehecho debido a la multitud de peticiones a los servicios remotos y su lentitud derespuestas de los servicios SOAP en general, sobretodo en el uso de Internet medianteconexión de datos. Esta falta de velocidad de respuesta se eliminó añadiendo partede la información a pedir en la propia aplicación mediante el servicio local de notas,el cuál, como se ha visto incluye las de�niciones, las notas y la identi�cación depersona, número y tiempo. A continuación se puede ver la arquitectura que teníainicialmente el proyecto.

125

Capítulo 21. Anexo V: Consecuencia del cambio del diseño arquitectónico

base de datos

servicios web

reconocedor

conjugador

interfazde

usuario

consultorSOAP

módulo de almacenamiento

módulo de procesado de texto

app

servicio remoto

obtenerIdsNotas

notas

forma canónica

módulo principal

Figura 21.1: Diseño arquitectonico desechado

En este caso, se ha obtenido toda la información básica de forma remota de lasiguiente forma:

Servicio Reconocedor, en este caso, nos permitía únicamente obtener los iden-ti�cadores de las posibles conjugaciones que pueda tener el verbo pasado porparámetro.

Servicio Conjugador, este necesita del identi�car de conjugación obtenido pre-viamente para obtener la conjugación que le corresponda a este.

Servicio Forma canónica, este otro permitía saber la forma canónica (in�nitivo)del verbo y necesitaba de un identi�cador obtenido de alguno de los elementosque componen la respuesta del servicio Conjugador para hacer la petición.

Servicio obtenerIdsNotas, este necesitaba del identi�cador obtenido en Recono-cer para obtener los identi�cadores de notas asociadas a dicha conjungación ala que representa el identi�cador

Servicio Notas, este permitía acceder al texto al que hace referencia alguno delos identi�cador de notas obtenido en el servicio anterior.

El problema es que solo son paralelizables aparentemente las peticiones propias delservicio Conjugador, las de IdsNotas y posteriormente las propias del servicio de

126

Capítulo 21. Anexo V: Consecuencia del cambio del diseño arquitectónico

Notas por separado. Sin embargo no es posible paralelizar las consultas al servicioConjugador puesto que la mayoría de identi�cadores obtenidos del servicio �Recono-cedor� no poseen conjugación y por razones de rendimiento en el sistema remoto esmejor realizar las peticiones a este servicio de forma secuencial. Por tanto, a pesar deparalelizar las peticiones que fuesen posibles el tiempo de espera era demasiado alto.Por ello, obtamos por incorporar parte de la información a la aplicación obteniendoasí los siguientes resultados de una serie de pruebas de tiempos sobre un grupo deverbos de distinto tipo.

Figura 21.2: Grá�co de tiempos obtenidos

Como se puede ver los resultados indican una gran mejoría en cuanto al tiempo derepuesta, por ello, consideramos que el cambio ha sido muy bueno para la experienciadel usuario en cuanto al uso de la aplicación. Lo cual no quiere decir que sea lamejor solución, ya que el coste en cuanto a peso en memoria de la aplicación haaumentado un 10% al añadir los distintos �cheros que contienen la información delas notas, identi�cadores-notas, de�niciones y persona-tiempo-modo. Además de lasnuevas clases añadidas para llevar a cabo la carga de la información y búsqueda deesta. Lo cuál, no quiere decir que sea tampoco la peor opción. Podríamos decir que esla mejor solución que hemos encontrado para facilitar el mantenimiento de la propiaaplicación.

127

Capítulo 21. Anexo V: Consecuencia del cambio del diseño arquitectónico

128

Bibliografía

[1] Ableson, Frank; Sen, Robi. Android: guía para desarrolladores 2ª ed. AnayaMultimedia, 2011.

[2] Appicenter LLC. Verbos españoles, 2015. URL http://www.appicenter.net/.

[3] Balsamiq Studios LLC. Balsamiq mockups, 2015. URL https://balsamiq.

com/products/mockups/.

[4] Burnette, Ed. Android. Anaya Multimedia, 2010.

[5] Cilenis, Language Technology. Conjugador Español, 2015. URL http://

cilenis.com/es/.

[6] Colaboradores de Wikipedia. Wikipedia, la enciclopedia libre, 2015. URLhttps://es.wikipedia.org/.

[7] CP apps. Conjugador de verbos españoles, 2015. URL https://sites.google.

com/site/cpappsonline/.

[8] Eclipse Foundation. Eclipse, 2015. URL http://www.eclipse.org/.

[9] Feel Good Software. Conjugador de verbos españoles, 2015. URLfeelgoodsoftware.blogspot.com/.

[10] GitHub, Inc. Github: Build software better, together, 2015. URL https://

github.com/.

[11] Google, Inc. Android developers, 2015. URL developer.android.com.

[12] Google, Inc. Gmail, 2015. URL https://www.gmail.com/.

[13] Google, Inc. Google play, 2015. URL https://play.google.com/store.

[14] Google, Inc. Android studio, 2015. URL https://developer.android.com/

sdk/index.html.

129

Bibliografía

[15] Ian Tipton. Verbos Españoles, 2015. URL http://itipton.com/.

[16] Inkscape Team. Inkscape, 2015. URL https://inkscape.org/es/.

[17] Instituto Universitario de Análisis y Aplicaciones Textuales. Text & informationprocessing, 2015. URL http://tip.iatext.ulpgc.es/.

[18] Jafelle, Nicolas. Sherlocknavigationdrawer, 2015. URL https://github.com/

nicolasjafelle/SherlockNavigationDrawer.

[19] Jake Wharton. Actionbarsherlock library, 2012. URL http://

actionbarsherlock.com/.

[20] Jake Wharton. viewpageindicator library, 2015. URL http://

viewpagerindicator.com/.

[21] LeFly. Tipografía blokletters viltstift, 2005. URL http://www.dafont.com/

es/blokletters.font.

[22] MKLab. Staruml, 2015. URL http://staruml.io/.

[23] Simpligility Technologies inc. Ksoap2 library, 2015. URL http://

simpligility.github.io/ksoap2-android/index.html.

[24] Stack Exchange, Inc. Stack over�ow, 2008. URL https://stackoverflow.com.

[25] The LyX Team. LyX - The Document Processor [Computer software and ma-nual], 2009. URL http://www.lyx.org/. Retrieved February 16, 2009, fromhttp://www.lyx.org.

[26] Linus Torvalds. git �distributed-is-the-new-centralized, 2005. URL https://

git-scm.com/.

[27] Trello, Inc. Trello es la manera gratuita, �exible y visual de organizarlo todocon cualquiera., 2015. URL https://trello.com/.

[28] wcfonts. Tipografía wc roughtrad, 2005. URL http://www.wcfonts.com/.

130

Bibliografía

131