Int3rfac3s (2º trimestre) Repaso de clase

Desarrollo de interfaces 2º trimestre (Temas 8 - 15). .

Contraseña.

Comenzamos... .

Casi todos los desarrollos de software están basados en dos grupos de pruebas claramente diferenciados. Las pruebas de caja negra en las cuales se evalúa la aplicación desde un punto de vista externo, es decir, sin preocuparnos del “interior”. Las pruebas de caja blanca, estas se basan en la evaluación del código interno del software. Las pruebas de caja amarilla, en las cuales se evalúa el color de la interfaz de la aplicación. Las pruebas de caja verde, estas se basan en medir el consumo eléctrico del software. Las pruebas de caja negra y caja blanca son lo mismo, solo cambia el nombre según la empresa que las use. Caja negra se hace a oscuras y caja blanca con la luz encendida.

Fases de pruebas en diferentes tipos atendiendo al tipo de FUNCIONALIDAD evaluada en cada caso. Este tipo de pruebas evalúan funcionalidades concretas, examinando todos los caminos posibles implementados en el desarrollo de un algoritmo, función o clase. Tras realizar las pruebas unitarias, se utilizan este tipo de pruebas en toda la aplicación ya totalmente integrada. Este tipo de pruebas es volver a verificar aquello que ya había sido evaluado previamente y había generado algún tipo de error. Este tipo de pruebas se centran, en la evaluación de los sistemas de protección y autenticación de una aplicación. En algunas ocasiones, es necesario manejar una gran cantidad de datos, puesto que puede que el software no soporte un acceso masivo, por lo que será necesario comprobar este tipo de acceso. Son realizadas por un desarrollador, experto o no en el software a testear. Utilizan herramientas que permiten agilizar este proceso de evaluación.

La depuración de código, se centra en la revisión del código para la detección de posibles errores y la corrección de los mismos. Podemos encontrar tres tipos de errores atendiendo al desarrollo del código: Este tipo de errores se producen por un FALLO en la SINTAXIS del lenguaje de programación utilizado. Este tipo de errores se producen cuando la SINTAXIS es CORRECTA, pero se ha implementado algún tipo de operación cuyo resultado es erróneo. Este tipo de errores son producidos por un FALLO EN EL DISEÑO DE LA LÓGICA del programa, es decir, el resultado no es el esperado.

Las PRUEBAS DE INTEGRACIÓN permiten evaluar el funcionamiento de todos los módulos desarrollados de manera conjunta. Estas pruebas COMIENZAN con la evaluación de los niveles MÁS BAJOS. Estas pruebas se realizan desde el módulo PRINCIPAL hasta los SUBORDINADOS. Hay dos subtipos: Una integración primero en profundidad y otra integración primero en achura.

Se denominan PRUEBAS DE REGRESIÓN a la nueva ejecución de un conjunto de pruebas que ya había sido ejecutado con anterioridad para evaluar si las NUEVAS MODIFICACIONES y cambios que se hayan realizado sobre el código HAN PODIDO PROVOCAR FALLOS que ANTES NO EXISTÍAN. Se localizan errores que se han producido por la introducción de últimos cambios y modificaciones. Este tipo se produce cuando la introducción de cambios muestra errores que nada tienen que ver con las modificaciones realizadas, pero que su inclusión los ha dejado al descubierto. Reciben este nombre los errores producidos cuando al realizar la integración de las diferentes partes de un programa, se producen errores que de forman individual no ocurrían.

TIPOS DE PRUEBAS. Permiten evaluar el funcionamiento de todos los módulos desarrollados de manera conjunta. Consiste en la ejecución de un conjunto de pruebas que ya había sido ejecutado con anterioridad para evaluar si las nuevas modificaciones y cambios que se hayan realizado sobre el código han podido provocar fallos que antes no existían. Se basan en la evaluación de todas las funcionalidades especificadas en los requisitos de diseño de una herramienta o aplicación software. Se utilizan para la evaluación del software y su comportamiento ante un aumento de peticiones, es decir, ante un incremento de la carga de trabajo. Se utilizan para la evaluación del tiempo de RESPUESTA Y VELOCIDAD de procesamiento del software. Se utilizan para la evaluación de la CAPACIDAD DE RECUPERACIÓN del software ante una SOBRECARGA de datos. Se utilizan para la evaluación de la capacidad de procesamiento del software ante la llegada de una CANTIDAD GRANDE DE DATOS. Estas pruebas están diseñadas para: • Garantizar los aspectos relativos a la integridad de los datos. • Evaluar los diferentes mecanismos de protección que pueden estar incorporados en una determinada aplicación software. Utilizan herramientas que permiten agilizar el proceso de EVALUACIÓN de las APLICACIONES IMPLEMENTADAS. Las realiza el DESARROLLADOR para PROBAR EL CÓDIGO que se está implementando.

Pruebas: Se basan en el análisis y evaluación de una herramienta o aplicación software mediante un grupo de usuarios reales que pueden detectar ERRORES QUE LOS EXPERTOS NO HAN SIDO CAPACES DE ENCONTRAR. Se utilizan para COMPROBAR SI UNA APLICACIÓN, en el caso de desarrollo de software, CUMPLE con el funcionamiento contenido en las especificaciones de diseño, tanto desde un punto de vista FUNCIONAL como de RENDIMIENTO.

Versiones. Esta será probada por un grupo de individuos que SIMULA SER EL CLIENTE FINAL. Es una versión casi definitiva del producto, en este caso, se trata de la primera versión de un producto que SERÁ PROBADA por los CLIENTES que habían realizado el encargo del desarrollo.

INCLUSIÓN DE DATOS desde base de datos: Tras la creación del informe y la conexión de éste con las tablas contenedoras de los datos, será posible utilizar estos campos para su importación en un informe. Los campos de la base de datos pueden utilizarse en el informe sin necesidad de crear una conexión previa con las tablas. Para importar datos al informe hay que escribirlos a mano uno por uno en un bloc de notas. La base de datos se conecta al informe usando un cable USB entre MySQL y JasperReports.

Para EL DISEÑO DE UN INFORME se debe diferenciar : Se utilizan como si fueran etiquetas y son las habituales para la creación de los títulos. Son los elementos que se van a utilizar para la inclusión de los datos contenidos en las tablas.

Los subinformes son informes incluidos dentro de otros informes. Se caracterizan porque: Son de gran utilidad a la hora de trabajar con datos relacionales puesto que permiten obtener varias consultas diferentes en un mismo informe de una forma más organizada y por lo tanto, más fácil de comprender por el usuario de este tipo de información. Sólo sirven para cambiar el color del informe principal. No puede incluir datos ni consultas, solo imágenes decorativas. Son de gran utilidad a la hora de trabajar con datos relacionales puesto que permiten obtener una sóla consulta en un mismo informe de una forma más estricta y difícil de comprender por el usuario.

Diferencias entre los informes y los subinformes: Puede contener subinformes. Tiene encabezado y pie de página. Existe como objeto independiente y principal. No puede contener más subinformes. No tiene encabezado ni pie de página. No tiene existencia por sí solo.

¿Para qué sirve el editor de expresiones en un informe?. Para personalizar la cadena de texto con la que se incluyen los datos en el informe. Para eliminar automáticamente todos los datos de la base de datos. Para cambiar únicamente el color de fondo del informe. Para crear tablas en la base de datos desde el informe.

¿Qué permiten hacer los parámetros en un informe?. Crear distintos resultados usando un mismo fichero de diseño y seleccionar qué dato se muestra en cada momento. Convertir automáticamente el informe en una aplicación móvil. Eliminar la conexión con la base de datos para que el informe funcione sin datos. Cambiar únicamente el tipo de letra y los colores del informe.

¿Qué elementos visuales se pueden incluir en un informe para mejorar la presentación de los datos?. Imágenes y gráficos, como gráficos de barras, lineales o circulares. Solo texto plano, porque los informes no permiten elementos visuales. Únicamente imágenes guardadas en una ruta absoluta del ordenador del desarrollador. Solo gráficos circulares, ya que los gráficos de barras y lineales no son compatibles.

Es posible tener una vista del código generado o de la vista de diseño. En este caso, será posible visualizar el entorno de desarrollo de tres formas distintas: Se muestra el código de desarrollo. Parece el lienzo de diseño sobre el que se sitúan y distribuyen los elementos. Una combinación de las dos anteriores.

Los layout permiten definir las siguientes características de diseño: (Sin los layout, los elementos ocuparían todo el contenedor. ). Posición, dimensión y distribución de los elementos. Color, sonido y animación de los elementos. Usuario, contraseña y permisos de la aplicación. Base de datos, consultas y conexión al servidor.

Paleta de componentes. En este bloque, aparecen los componentes cuyo uso es más habitual, como cajas de texto o botones. Elementos que permiten añadir a la interfaz cadenas de texto tales como números de teléfono, fechas…. Elementos de tipo botón o un compartimento similar (checkbox, togglebutton, radiobutton…). Elementos “extra” que permiten personalizar la interfaz de desarrollo (calendarios, barras de progreso…). Elementos extremadamente importantes en el desarrollo de interfaces, puesto que permiten definir la posición del resto de elementos, su dimensión y la distribución de estos. Aunque similares a los layouts, estos son un tipo de View utilizado para realizar ciertas distribuciones dinámicas. Elementos relativos a Google, como mapas o anuncios.

Relaciona. Elementos de tipo botón. Aparece en forma de botones de texto, imagen o icono. "pulsados". Permiten al usuario INTRODUCIR cualquier tipo de texto en una caja. "Diseño de formularios". Este elemento permite MOSTRAR un mensaje en forma de cadena de texto o similar a un usuario. "una etiqueta de texto". Permiten a los usuarios seleccionar una o más opciones de entre las que son mostradas por la aplicación. Permite al usuario conmutar entre dos estados. Utilizado para modelar los menús desplegables en una aplicación con Android.

Layouts: RelativeLayout. determina el valor del ANCHO del elemento. determina el valor de la ALTURA del elemento. Determina la POSICIÓN en la que debe situarse un elemento dentro del contenedor en el que se encuentra. Determina la distancia con respecto a los MÁRGENES del contenedor y la alineación. Se asigna como dimensión el TAMAÑO COMPLETO del elemento PADRE. Se utiliza para indicar que la dimensión del elemento se ajusta al CONTENIDO del mismo.

RELACIONA: Permite colocar los elementos de manera relativa al elemento contenedor padre. "es el que permite mayor libertad". Los elementos quedan distribuidos en forma de tabla, por lo que se indicarán las filas y las columnas que lo componen. Crea una rejilla formada por un conjunto de líneas verticales y horizontales en cuyos “huecos” se colocarán los elementos. permite alinear los elementos uno tras otro en una dirección concreta (vertical u horizontal).