5.3 MODELOS DE PRUEBA

Objetivos de las pruebas

Ø  Encontrar defectos en el software

Ø  Una prueba tiene éxito si descubre un defecto

Ø  Una prueba fracasa si hay defectos pero no los descubre

*Pruebas de Verificación

    Ver si cumple las especificaciones de diseño

*Pruebas de Validación

    Ver si cumple los requisitos del análisis.

 El proceso de pruebas del software tiene dos objetivos:

1.  Demostrar al desarrollador y al cliente que el software satisface sus requerimientos.

2.   Descubrir defectos en el software: que su comportamiento es incorrecto, no deseable o no cumple su especificación.

Pruebas de “caja blanca”

Pruebas en que se conoce el código a probar

Caja blanca (clear box: caja clara o transparente)

Se procura ejercitar cada elemento del código

Algunas clases de pruebas

Pruebas de cubrimiento

Pruebas de condiciones

Pruebas de bucles

Pruebas de “caja negra”

Pruebas en que se conoce sólo la interfaz

Caja negra (black box: caja opaca)

Se procura ejercitar cada elemento de la interfaz

Algunas clases de pruebas

Cubrimiento  invocar todas las funciones (100%)

Clases de equivalencia de datos

Pruebas de valores límite

Estrategias de prueba del software

Ø  Pruebas de unidades

Ø  Pruebas de integración

Ø  Pruebas de regresión

Ø  Pruebas de validación

Pruebas de unidades:

Ø  Se concentra en el esfuerzo de verificación de la unidad más pequeña del diseño del software: el componente o módulo del software.

Ø  Las pruebas de unidad se concentran en la lógica del procesamiento interno.

Ø  Este tipo de prueba se puede aplicar en paralelo a varios componentes.

Pruebas de integración:

Ø  La prueba de integración es una técnica sistemática para construir la arquitectura del software, mientras, al mismo tiempo, se aplican las pruebas para descubrir errores asociados con la interfaz.

Ø  El objetivo es tomar componentes a los que se aplicó una prueba de unidad y construir una estructura de programa que determine el diseño.

Pruebas de regresión:

Ø  La prueba de integración es una técnica sistemática para construir la arquitectura del software, mientras, al mismo tiempo, se aplican las pruebas para descubrir errores asociados con la interfaz.

Ø  El objetivo es tomar componentes a los que se aplicó una prueba de unidad y construir una estructura de programa que determine el diseño.

Pruebas de validación:

Ø  Las pruebas de validación empiezan tras la culminación de la prueba de integración, cuando se han ejercitado los componentes individuales. Se ha terminado de ensamblar el software como paquete y se han descubierto y corregido los errores de interfaz.

Ø  La prueba se concentra en las acciones visibles para el usuario y en la salida del sistema que éste puede reconocer.

5.2 DIAGRAMAS DE DESPLIEGUE

El Diagrama de Despliegue es un diagrama que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.

Ø  Permiten modelar la disposición física o topología de un sistema.

Ø  Muestra el hardware usado y los componentes instalados en el hardware.

Ø  Muestra las conexiones físicas entre el hardware y las relaciones entre componentes.

Usos que se les da a los diagramas de despliegue son para modelar:

·         Sistemas cliente-servidor

·         Sistemas completamente distribuidos

El elemento principal del diagrama son los NODOS.

 Los nodos representan un recurso físico:

Ø  Computadoras

Ø  Sensores

Ø  Impresoras

Ø  Servidores

Ø  Dispositivos externos

 Los nodos pueden ser interconectados mediante líneas para describir una estructura de red.

Un nodo es un objeto físico en tiempo de ejecución que representa un recurso computacional, generalmente con memoria y capacidad de procesamiento.

Estereotipo de nodo

Ø  Estereotipo, son cosas u objetos q se repiten sin variación.

Ø  El estereotipo de un nodo es la manera de poder verificar que tipo de nodo es el que se está observando.

Ejemplo Grafico

Se muestra número de estereotipos estándar, nombrados «cdrom»,«disk array», «pc client», «unix server». etc. Estos mostrarán un icono apropiado en la esquina derecha arriba del símbolo nodo.

Artefactos

Un artefacto es un producto del proceso de desarrollo de software, que puede incluir los modelos del proceso (modelos de Casos de Uso, modelos de Diseño, etc.), archivos fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos, manuales de usuario etc.

Donde un artefacto es un conjunto de componentes.

Ejemplo Grafico

Un artefacto se denota por un rectángulo mostrando el nombre del artefacto, el estereotipo «artifact» y un icono de documento, como a continuación.

5.1 DIAGRAMAS DE COMPONENTES

Un componente es una parte física de un sistema (modulo, base de datos, programa ejecutable, etc.). Se puede decir que un componente es la materialización de una o más clases, porque una abstracción con atributos y métodos pueden ser implementados en los componentes.

 Respecto a los componentes…

Ø  Es implementado por una o más clases/objetos del sistema.

Ø  Es una unidad autónoma que provee una o más interfaces.

Ø  Las interfaces representan un contrato de servicios que el componente ofrece.

Los componentes pueden ser:

Ø  Archivos

Ø  Código fuente + Cabeceras

Ø  Librerías compartidas (DLLs)

Ø  Ejecutables

Ø  Paquetes

Muestra como el sistema está dividido en componentes y las dependencias entre ellos.

·         Proveen una vista arquitectónica de alto nivel del sistema.

·         Ayuda a los desarrolladores a visualizar el camino de la implementación.

·         Permite tomar decisiones respecto a las tareas de implementación y los Skills requeridos.

En un DC, un componente se representa con un rectángulo en el que se escribe su nombre y en él se muestran dos pequeños rectángulos al lado izquierdo. O también los siguientes:

Representación simple de un Componente

 

Elementos del Diagrama de Componentes

 

Normalmente los diagramas de Componentes contienen:

•         Componentes

•         Interfaces

•         Relaciones de dependencia, generalización, asociación y realización

•         Paquetes o subsistemas

Los componentes se pueden agrupar en paquetes así como los objetos en clases, además pueden haber entre ellos relaciones de dependencia como:

•         Generalización

•         Asociación

•         Agregación

•         Realización

Estereotipos de componentes

UML define cinco estereotipos estándar que se aplican en los componentes

Ø  Executable, componente que se puede ejecutar

Ø  Library, biblioteca de objetos estática o dinámica

Ø  Table, Componentes que representa una tabla de base de datos

Ø  File, componente que representa un documento que contiene código fuente o datos.

Ø  Document, Comp. Que representa un documento.

¿Por qué utilizar un Diagrama de Componentes?

Ø  Nos permite ver el modelado de un sistema o subsistema.

Ø  Permite especificar un componente con interfaces bien definidas.

 

4.6 Herramientas CASE para el diseño

Las herramientas de diseño, permiten al desarrollador crear un modelo del sistema que se va a construir y también la evaluación de la validez y consistencia de este modelo. Proporcionan un grado de confianza en la representación del análisis y ayudan a eliminar errores con anticipación.

• Herramientas de análisis y diseño (Modelamiento).

• Herramientas de creación de prototipos y de simulación.

• Herramientas para el diseño y desarrollo de interfaces.

• Máquinas de análisis y diseño (Modelamiento).

El sistema experto podría incluir herramientas de diseño asistido por computadora (CAD) con el fin de materializar las expectativas de los clientes y las aptitudes de la empresa en el diseño final. Esto se lograría implementando una base de datos histórica (Data Warehouse) con referencias al desarrollo de otros filtros con el fin de comparar problemas, inconvenientes o ventajas que se tuvieron al desarrollar dichos productos. De igual forma, para la parte de los clientes se podría implementar una interfaz inteligente entre el sistema CAD y la base de datos del marketing que generara un diseño base del filtro que implicara las preferencias más significativas de los clientes. A partir de este diseño, los expertos de cada área podrían empezar a buscar un punto de balance entre lo que el cliente quiere y lo que más le conviene a la empresa para así obtener un diseño final de nuestro filtro.

•         Producción.

•         Ventas.

Ventajas de utilizar un Sistema Experto en la IC

Los sistemas expertos propician la efectividad de la empresa en todos sus departamentos, al automatizar algunas de las tareas de la empresa y al concentrar toda la información competente al proceso de desarrollo del producto. De esta forma podemos apreciar las siguientes ventajas al usar los sistemas expertos en la ingeniería concurrente lo que generalmente se conoce como ingeniería concurrente asistida por computadora (CACE):

•          Información integrada. Este aspecto es el que persigue principalmente el sistema experto, pues se pretende juntar una gran cantidad de información que nos sirva de base para desarrollar nuestro producto. Esto promueve el hecho de que todos los participantes del equipo multidisciplinario tengan acceso a la información de los demás de manera previa, con el fin de que las juntas se lleven a cabo lo más rápido posible. La arquitectura del sistema experto podría diseñarse como una arquitectura cliente/servidor con el fin de que los participantes puedan acceder la información en cualquier momento e inclusive al mismo tiempo.

•          Comunicación eficaz. La gran cantidad de información que se encuentra al alcance de los participantes del equipo, propicia que todos conozcan a cierto nivel el proceso de desarrollo visto desde el punto de vista cada departamento, con esto, se evitan discusiones sobre aspectos poco comprendidos en el proceso de diseño. Con el conocimiento general del proceso de desarrollo del producto, la comunicación se vuelve entonces más eficaz, pues cada participante conoce los inconvenientes y las ventajas que se tendrían para cada departamento en función de algún cambio en el diseño del producto.

•          Rápida toma de decisiones. Con la información integrada en un solo núcleo y con la agilización de la comunicación entre los participantes del proyecto, se obtiene una aceleración en la toma de decisiones, producto de tener un equipo de expertos en cada área pero conocen y comprenden a las demás.

La Ingeniería Concurrente (IC) es una filosofía orientada a integrar sistemáticamente y en forma simultánea el diseño de productos y procesos, para que sean considerados desde un principio todos los elementos del ciclo de vida de un producto, desde la concepción inicial hasta su disposición final, pasando por la fabricación, la distribución y la venta. Debe otorgar además una organización flexible y bien estructurada, proponer redes de funciones apoyadas por tecnologías apropiadas y arquitecturas comunes de referencia (ejemplo: computadores en red y en bases de datos).

Retomando lo expuesto anteriormente la ingeniería concurrente es un esfuerzo sistemático para un diseño integrado, concurrente del producto y de su correspondiente proceso de fabricación y de servicio. Pretende que los desarrolladores, desde un principio, tengan en cuenta todos los elementos del ciclo de vida del producto, desde el diseño conceptual, hasta su disponibilidad incluyendo calidad, costo y necesidades de los clientes. Persigue un estudio sistemático, simultáneo, en el momento del desarrollo del producto, de las necesidades de mercado que va a cubrir, de los requisitos de calidad y costos, de los medios y métodos de fabricación, venta y servicio necesarios para garantizar la satisfacción del cliente.

Involucra el trabajo coordinado y simultáneo de los diversos departamentos de la empresa: Marketing, Ingeniería del Producto, Ingeniería del Proceso, Producción, Calidad, Ventas, Mantenimiento, Costos, etc.

La ingeniería concurrente sustituye el típico entorno de trabajo en el desarrollo y fabricación del producto basado en un diagrama secuencial de actuación de los distintos departamentos, por un trabajo concurrente, simultáneo, en equipo, de todos a partir del mismo momento en que se inicia el proceso.

4.5 Diagramas de secuencia del diseño

Los casos de uso deben ser utilizados durante esta etapa, para describir el comportamiento dinámico del sistema, cualquiera de los diagramas de interacción del UML   pueden ser utilizados. Debido a que Rational Rose  no soporta los diagramas de actividad  y ofrece soporte limitado  para los diagramas  de colaboración, utilizando diagramas de secuencia.

En un diagrama de secuencia ponemos varios de los objetos o clases que forman parte de nuestro programa y ponemos qué llamadas van haciendo unos a otros para realizar una tarea determinada.

Hacemos un diagrama de secuencia por cada caso de uso o para una parte de un caso de uso (lo que llamo subcaso de uso). En nuestro ejemplo de ajedrez, podemos hacer diagramas de secuencia para "jugar partida" o bien para partes de "jugar partida", como puede ser "mover pieza".

El detalle del diagrama depende de la fase en la que estemos, lo que pretendamos contar con el diagrama y a quién. En una primera fase de diseño podemos poner clases grandes y ficticias, que representen un paquete/librería o, si nuestro programa está compuesto por varios ejecutables corriendo a la vez, incluso clases que representen un ejecutable.

Si estamos en una fase avanzada, estamos diseñando el programa y queremos dejar bien atados los detalles entre dos programadores, que cada uno va a programar una de las clases que participan, entonces debemos posiblemente ir al nivel de clase real de codificación y método, con parámetros y todo, de forma que los programadores tengan claro que métdos van a implementar, que deben llamar de la clase del otro, etc. Incluso si es un diagrama para presentar al cliente, podemos hacer un diagrama de secuencia en el que sólo salga el actor "jugador" y una única clase "juego ajedrez" que representa nuestro programa completo, de forma que el cliente vea qué datos y en qué orden los tiene que meter en el programa y vea qué salidas y resultados le va a dar el programa.

El siguiente puede ser un diagrama de secuencia de nuestro ejemplo del ajedrez a un nivel de diseño muy preliminar

Aquí ya hemos decidido que vamos a hacer tres librerías/paquetes, una para la interface de usuario, otra para contener el tablero y reglas del ajedrez (movimientos válidos y demás) y otra para el algoritmo de juego del ordenador. Hemos puesto una clase representando cada uno de los paquetes y hemos representado el caso de usa "mover pieza".

En el diagrama de secuencia no se ponen situaciones erróneas (movimientos inválidos, jaques, etc) puesto que poner todos los detalles puede dar lugar a un diagrama que no se entiende o difícil de leer. El diagrama puede acompañarse con un texto en el que se detallen todas estas situaciones erróneas y particularidades. Si se quiere dejar muy claro que un determinado error se contempla, por ejemplo, un movimiento no válido por el usuario, entonces sí se puede poner en el diagrama de secuencia, siempre que no "embarulle" demasiado.

En este diagrama sencillo ya vamos dejando algunas cosas claras, como por ejemplo, que la interface de usuario hace llamadas y, por tanto, ve a los otros dos, mientras que algoritmo sólo ve al tablero/reglas. El tablero/reglas aparentemente ve a la interface de usuario, pero no nos interesa si seguimos un patrón modelo-vista-controlador, así que ese "Refresca pantalla" lo implementaremos con un patrón observador, pero eso son detalles que quizás no vienen al caso ahora