Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores (Sommerville, 2005).
Los casos de uso del actor de este sistema identificados son mostrados a continuación: CU1: Consultar Mapa.
CU2: Escanear Código. CU3: Realizar Llamada.
25
CU4: Consultar Información. CU5: Leer Libros.
CU6: Ver Galería. CU7: Cambiar Idioma.
En la siguiente figura se muestra el Diagrama de Casos de Uso del Sistema.
Figura 2.1 Diagrama de Casos de Uso del Sistema
2.4. Modelos de Trazabilidad
La trazabilidad en la Ingeniería de Software es una práctica de control que ayuda a obtener el producto en el dominio de la solución lo más exacto y fiable posible a las necesidades expresadas por el cliente en el dominio del problema. A diferencia de productos en otras ramas de la ingeniería, un producto de software es maleable y pueden cambiar su estructura y composición en espacio y tiempo durante el proceso de desarrollo de software y es aquí donde la trazabilidad adquiere gran importancia. La trazabilidad se refiere a la "capacidad para describir y seguir la vida de un requisito en ambas direcciones, hacia
26
delante (forward) y hacia atrás (backward) (esto es, desde su origen, durante su desarrollo y especificación, hasta su desarrollo y uso, y a lo largo de todos los períodos de refinamiento en curso e iteración en alguna de estas fases"(Lindvall y Sandahl, 1996) Se han creado diferentes técnicas y modelos para soportar la práctica de trazabilidad durante el proceso de desarrollo de software. La técnica más común y aplicable a cualquier modelo de desarrollo es la construcción de matrices de trazado, que hacen posible el análisis de la correlación entre elementos de un mismo modelo y entre modelos en diferentes niveles de abstracción.
2.4.1. Matriz de Trazabilidad
La matriz de trazabilidad de requisitos es un cuadro que vincula los requisitos del proyecto desde su origen hasta los entregables que lo satisfacen. La matriz de requisitos ayuda a asegurar que cada requerimiento agrega valor al negocio, mostrándote el vínculo entre requisitos, necesidades de negocio y objetivos de proyecto. De esta forma se puede hacer un seguimiento durante el ciclo de vida, mejorando la ingeniería de requisitos al asegurar que estos sean entregados según especificaciones. (PMOinformatica.com, 2012) La siguiente tabla muestra la matriz de trazabilidad del Sistema.
Tabla 2.1 Matriz de Trazabilidad del Sistema
Requisitos Funcionales/Casos
de Usos CU1 CU2 CU3 CU4 CU5 CU6 CU7
RF1 X RF2 X RF3 X RF4 X RF5 X RF6 X RF7 X
27 2.5. Descripción de los Casos de Uso del Sistema
Caso de Uso Escanear Código.
El visitante en la interfaz principal puede presionar el botón flotante que lo llevará al escáner de códigos QR. En la siguiente tabla se muestran las características esenciales de este caso de uso, así como la conformación del curso normal de los eventos, describiendo pasos necesarios para lograr el cumplimiento del caso de uso.
Tabla 2.2 Descripción del Caso de Uso Escanear Código.
Caso de Uso del Sistema Escanear Código
Actor Visitante
Propósito Escanear el código de los objetos
Resumen El caso de uso comienza cuando el
visitante desea conocer la información del objeto que está observando. El Caso de uso termina cuando el usuario sale de la interfaz del escáner.
Responsabilidades Conocer la información del objeto que
está observando.
Casos de uso asociados -
Requisitos especiales - El visitante debe haber otorgado los permisos de acceso a cámara para poder escanear el código.
Precondiciones -
Descripción IU_QR
Flujo normal de los eventos
28
1. El visitante inicia la aplicación y presiona el botón flotante con el icono del código QR.
3. El visitante acepta los permisos solicitados.
5. El visitante escanea el código colocándolo en el centro de la cámara.
2. Se solicitan los permisos de acceso a cámara.
4. Se muestra la interfaz del escáner.
6. La aplicación muestra una breve información sobre el objeto escaneado.
Flujos alternativos
En el caso de que el visitante niegue los permisos de acceso a cámara se le notifica y permanece en la interfaz principal.
Post condiciones
Caso de Uso Consultar Mapa
El visitante en la interfaz principal puede acceder al menú de navegación y luego seleccionar la localización. En la siguiente tabla se muestran las características esenciales de este caso de uso, así como la conformación del curso normal de los eventos, describiendo pasos necesarios para lograr el cumplimiento del caso de uso.
Tabla 2.3 Descripción del Caso de Uso Consultar Mapa
Caso de Uso del sistema Consultar Mapa
Actor Visitante
Propósito Acceder a la ubicación del Complejo
Escultórico.
Resumen El caso de uso comienza cuando el visitante
desea conocer la ubicación del Complejo Escultórico. El Caso de uso termina cuando el visitante sale de la interfaz de la localización.
Responsabilidades Conocer la ubicación del centro.
Casos de uso asociados -
Requisitos especiales El visitante debe haber otorgado los permisos de lectura y escritura en el almacenamiento del teléfono.
29
Descripción IU_Mapa
Flujo normal de los eventos
Acción del actor Respuesta del sistema
1. El visitante inicia la aplicación y desde el menú de navegación accede a la localización.
3. El visitante acepta los permisos solicitados.
2. Se solicitan los permisos de lectura y escritura en el almacenamiento del teléfono.
4. Se muestra la interfaz del mapa. Flujos alternativos
En el caso de que el visitante niegue los permisos de lectura y escritura en el almacenamiento del teléfono se le notifica y permanece en la interfaz principal.
Post condiciones -
Caso de Uso Consultar Información
El visitante en la interfaz principal puede acceder al menú de navegación y luego seleccionar la información de cada área del Complejo Escultórico.
En la siguiente tabla se muestran las características esenciales de este caso de uso, así como la conformación del curso normal de los eventos, describiendo pasos necesarios para lograr el cumplimiento del caso de uso.
30
Caso de Uso del sistema Consultar Información
Actor Visitante
Propósito Conocer la información de las áreas o
estadísticas del Complejo Escultórico.
Resumen El caso de uso comienza cuando el
visitante desea conocer la información de las aéreas del Complejo Escultórico o sus estadísticas.
El Caso de uso termina cuando el visitante sale de la interfaz accedida. Responsabilidades Conocer las áreas o estadísticas del
centro.
Casos de uso asociados -
Requisitos especiales - -
Precondiciones - -
Descripción
IU_Consultar Información (General)
Flujo normal de los eventos
Acción del actor Respuesta del sistema
1. El visitante inicia la aplicación y desde el menú de navegación accede a la información de cada una de las áreas del
centro. 2. Se muestra la interfaz del aérea
seleccionada. Flujos alternativos
31 2.6. Diagrama de secuencia (Casos de Uso Significativos)
Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes en la interacción, sin un orden prefijado. Cada objeto o actor tiene una línea vertical, y los mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de arriba abajo.(Ferré y Sánchez, 2002).
Un diagrama de secuencia (o varios) puede ilustrar las interacciones entre los objetos para ejecutar un caso de uso. Los diagramas de secuencia son particularmente importantes para los diseñadores debido a que ellos aclaran los roles de los objetos en el flujo y por consiguiente brindan la entrada básica para la determinación de las responsabilidades y las interfaces de las clases.
En la siguiente figura se muestra el Diagrama de Secuencia para el Caso de Uso Escanear Código.
Figura 2.2 Diagrama de Secuencia para el Caso de Uso Escanear Código.
En este ejemplo el visitante accede a escanear código desde el botón flotante en la interfaz gráfica de la aplicación. Al abrir la interfaz cámara la clase controladora chequea si existen permisos para acceder a la misma, si existen dichos permisos la aplicación carga la vista, en caso contrario notifica al visitante de que no cuenta con permisos para acceder a la cámara.
32
En la siguiente figura se muestra el Diagrama de Secuencia para el Caso de Uso Consultar Mapa.
Figura 2.3 Diagrama de Secuencia para el Caso de Uso Consultar Mapa.
En este ejemplo el visitante accede a la localización desde el menú de navegación en la interfaz gráfica de la aplicación. Al abrir la interfaz localización la clase controladora chequea si existen permisos para acceder a la misma, si existen dichos permisos la aplicación carga la vista, en caso contrario notifica al visitante de que no cuenta con permisos para acceder a la localización.
2.7. Mapa de Navegación de la aplicación
El mapa de navegación de un software es una guía gráfica que se elabora para brindarle al usuario un fácil manejo del material computacional. Este esquema muestra la forma como están organizadas las interfaces gráficas de usuario, dentro de este esquema se incluye la imagen de la ventana principal y el despliegue de las demás cuando hay un hipervínculo que la interconecta(Fernando et al., 2009)
En la siguiente figura se muestra el mapa de navegación de la aplicación. Como nodo raíz se encuentra la vista principal, de ella derivan las diferentes vistas de la aplicación.
33
Figura 2.4 Mapa de Navegación de la Aplicación.
2.8. Modelo de Componentes
Un componente de software individual es un paquete de software, un servicio web, o un módulo que encapsula un conjunto de funciones relacionadas (o de datos). Todos los procesos del sistema son colocados en componentes separados de tal manera que todos los datos y funciones dentro de cada componente estén semánticamente relacionados. Debido a este principio, con frecuencia se plantea que los componentes son modulares y cohesivos.
Con respecto a la coordinación a lo largo del sistema, los componentes se comunican uno con el otro por medio de interfaces. Cuando un componente ofrece servicios al resto del sistema, éste adopta una interfaz proporcionada que especifica los servicios que otros componentes pueden utilizar, y cómo pueden hacerlo. Esta interfaz puede ser vista como una firma del componente, el cliente no necesita saber sobre los funcionamientos internos del componente (su implementación) para hacer uso de ella. Este principio resulta en componentes referidos como encapsulados. Cuando un componente necesita usar otro componente para poder funcionar, adopta una interfaz usada que específica los servicios que necesita.
Otro atributo importante de los componentes es que son sustituibles, así que un componente puede sustituir a otro (en tiempo de diseño o tiempo de ejecución), si el componente sucesor cumple los requisitos del componente inicial (expresado por medio
34
de las interfaces). Por lo tanto, los componentes pueden ser sustituidos por una versión más reciente.(Jacobson, 2000)
Los Modelos de Componentes ilustran las piezas del software, controladores embebidos que conformarán un sistema. En la siguiente Figura se muestra el Diagrama de Componentes del Sistema, el cual muestra las diferentes librarías utilizadas como:
Zxing: empleada para el desarrollo del escáner de códigos.
MPAndroidChart: para la visualización de gráficos.
Mapsforge: para el trabajo con los mapas.
Estas sirvieron de gran ayuda a la hora del diseño y la implementación del sistema, logrando mejoras visuales y rapidez en la aplicación.
En la siguiente figura se muestra el modelo de componentes de la aplicación desarrollada.
35 2.9. Diagrama de Despliegue
Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecución de un sistema. Este diagrama muestra la configuración de los elementos de hardware (nodos) y muestra cómo los elementos y artefactos del software se trazan en esos nodos.
En la siguiente figura se muestra el Diagrama de Despliegue del Sistema, el cual contiene los componentes de hardware que se utilizarán. El componente “Plataforma Android” son aquellos usuarios que interactúan con la aplicación mediante diferentes tipos de dispositivos con sistema operativo Android, ya sean teléfonos inteligentes (Smartphone) o tabletas (Tablet). (Sommerville, 2005)
Figura 2.6 Diagrama de Despliegue del Sistema
Conclusiones del capítulo
En este capítulo se obtuvo el modelo del sistema utilizando el lenguaje UML (Lenguaje Unificado de Modelado) manejando todas las facilidades que el mismo brinda. Se implementó un sistema que permite brindar información acerca del Complejo Escultórico “Ernesto Che Guevara” en dispositivos móviles.
36
CAPÍTULO 3. PRUEBAS DE SOFTWARE
3.1. Pruebas de Software
Las pruebas de software son un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación. La creciente percepción del software como un elemento del sistema y la importancia de los costes asociados a un fallo del propio sistema, están motivando la creación de pruebas minuciosas y bien planificadas. (Sommerville, 2005)
Objetivos de las pruebas de software (Pressman y Troya, 2007)
La prueba es un proceso de ejecución de un programa con la intención de descubrir un error.
Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.
Una prueba tiene éxito si descubre un error no detectado hasta entonces.
La prueba no puede asegurar la ausencia de defectos, sólo puede demostrar que existen defectos en el software.
3.2. Estrategias de Pruebas
Al aplicarles las pruebas al software se deben seguir un conjunto de estrategias para lograr que estas se hagan en el menor tiempo posible y con la calidad requerida, además de garantizar que arrojen los resultados esperados.
Características generales de la Estrategia de Prueba. (roger s. pressman, 2002)
1. La prueba comienza en el nivel de módulo y trabaja "hacia fuera", hacia la integración completa del sistema completo.
2. En diferentes puntos es adecuada la utilización de técnicas de prueba distintas. 3. La prueba la lleva a cabo el que desarrolla el software y para grandes proyectos, un grupo de prueba independiente.
4. La prueba y la depuración son actividades diferentes, pero la depuración puede entrar en cualquier estrategia de prueba.
Cualquier producto de ingeniería puede comprobarse de una de estas dos formas: (Pressman y Ince, 2000)
Con un enfoque estructural o Prueba de Caja Blanca. Consiste en centrarse en la estructura interna (implementación) del programa para elegir los casos de prueba. En este caso, la prueba ideal consistiría en probar todos los posibles caminos de ejecución, a través de las instrucciones del código, que puedan trazarse.
37 Con un enfoque Funcional o Prueba de Caja Negra. Consiste en estudiar la
especificación de las funciones, la entrada y la salida para derivar los casos. Aquí la prueba ideal del software consistiría en probar todas las posibles entradas y salidas del programa
En el presente trabajo se utilizó la estrategia de pruebas de especificación (Caja Negra).
3.3. Pruebas de Caja Negra
Las pruebas funcionales o de caja negra son un enfoque para llevar a cabo pruebas donde estas se derivan de la especificación del programa o componente. El sistema es una "caja negra" cuyo comportamiento sólo se puede determinar estudiando las entradas y salidas relacionadas. Otro nombre para estas es pruebas funcionales debido a que al probador sólo le interesa la funcionalidad y no la implementación del software.
Este enfoque se aplica de igual forma a los sistemas que están organizados como funciones o como objetos. El probador introduce las entradas en los componentes del sistema y examina las salidas correspondientes. Si las salidas no son las previstas, entonces la prueba ha detectado exitosamente un problema con el software (Sommerville, 2005)
Las pruebas se diseñan para responder a las siguientes preguntas (roger s. pressman, 2002) • ¿Cómo se prueba la validez funcional?
• ¿Cómo se prueban el comportamiento y el rendimiento del sistema? • ¿Qué clases de entrada harán buenos casos de prueba?
• ¿Cómo se aíslan las fronteras de una clase de datos? • ¿Qué tasas y volumen de datos puede tolerar el sistema?
Para desarrollar la prueba de caja negra existen varias técnicas, entre ellas están (Sommerville, 2005)
1. Técnica de la Partición de Equivalencia: esta técnica divide el campo de entrada en clases de datos que tienden a ejercitar determinadas funciones del software.
2. Técnica del Análisis de Valores Límites: esta Técnica prueba la habilidad del programa para manejar datos que se encuentran en los límites aceptables.
3. Técnica de Grafos de Causa-Efecto: es una técnica que permite al encargado de la prueba validar complejos conjuntos de acciones y condiciones. Fue la técnica usada en el desarrollo de pruebas de caja negra a la aplicación.
38
Tabla 3.2 Escenarios a probar en el Caso de Uso “Consultar Mapa”
Tabla 3.3 Secciones a probar en el Caso de Uso “Escanear Código”
Nombre de la Sección Escenarios de la Sección Descripción de la funcionalidad Flujo Central SC1: Consultar Mapa EC 1.1: El visitante desea acceder el mapa por primera vez.
La aplicación
chequea los permisos de acceso al almacenamiento del dispositivo para copiar el mapa y posteriormente cargarlo. Abrir automáticamente la interfaz del mapa.
EC 1.2:
El visitante desea acceder nuevamente al mapa.
La aplicación
necesitará solo que el usuario cargue el mapa.
Abrir
automáticamente la interfaz del mapa.
Id del escenario
Escenario Variable 1
Permisos
Respuesta del Sistema Resultado de la Prueba
EC 1 Primera vez. V El sistema chequea los permisos de escritura y guarda el mapa en el
almacenamiento interno del teléfono y muestra la vista del mapa.
Prueba superada con éxito.
I El sistema lanza una alerta notificando que no tienes permiso para acceder al almacenamiento interno.
EC 2 Nuevamente V El sistema comprueba que
existe la carpeta creada, sino existe la crea y muestra la vista del mapa.
Prueba superada con éxito.
I El sistema lanza una alerta notificando que no tienes permiso para acceder al almacenamiento interno.
39
Tabla 3.4 Escenarios a probar en el Caso de Uso “Escanear Código”
[Las celdas de la tabla contienen V, I, V indica válido, I indica inválido.]
3.4. Pruebas de Usabilidad
La usabilidad es una característica muy importante que debe poseer todo software, se dice que un sistema tiene buena usabilidad cuando este presenta una interfaz gráfica donde el usuario no necesita ser experto en el área para poder utilizar el sistema.
Nombre de la Sección Escenarios de la Sección Descripción de la funcionalidad Flujo Central SC1: Escanear Código EC 1.1: El visitante desea escanear el código por primera vez.
La aplicación
chequea los permisos de acceso a la cámara. Abrir automáticamente la interfaz de la cámara. EC 1.2: El visitante desea acceder nuevamente al mapa. La aplicación
necesitará solo que el visitante acceda a la cámara. Abrir automáticamente la interfaz de la cámara. Id del escenario Escenario Variable 1 Permisos
Respuesta del Sistema Resultado de la Prueba
EC 1 Primera vez. V El sistema chequea los permisos de acceso a la cámara y carga la interfaz del escáner.
Prueba superada con éxito.
I El sistema lanza una alerta notificando que no tienes permisos para acceder a la cámara.
EC 2 Nuevamente V El sistema comprueba los
permisos y carga la interfaz de la cámara.
Prueba superada con éxito.
I El sistema lanza una alerta notificando que no tienes permiso para acceder a la cámara.
40
La meta de esta prueba de usabilidad es identificar y rectificar las deficiencias de usabilidad y errores existentes. Se intenta asegurar que la aplicación sea fácil de aprender y de usar, su uso sea satisfactorio, provea utilidad y funcionalidad y cumpla las tareas