5.1DIAGRAMA DE COMPONENTES

Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones. Muestran las opciones de realización incluyendo código fuente, binario y ejecutable.

Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. Pueden ser simples archivos, paquetes, bibliotecas cargadas dinámicamente, etc.

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

Ejecutable: Especifica un componente que se puede ejecutar  en un nodo.

Library: Especifica una biblioteca de objetos estática o dinámica.

Table: Especifica un componente que representa una tabla de una base de datos.

File: Especifica un componente que representa un documento que contiene código fuente o datos.

Document: Especifica un componente que representa un documento. Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente se refiere a los servicios ofrecidos por otro componente.

5.2 DIAGRAMA DE DESPLIEGUE

Los Diagramas de Distribución muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos.

Un nodo es un elemento físico que existe en tiempo de ejecución  y representa un recurso computacional, que generalmente tiene algo de memoria y, a menudo, capacidad de procesamiento.

Los nodos se utilizan para modelar la  topología del hardware sobre el que se ejecuta el sistema. Representa típicamente un  procesador o un dispositivo sobre el que se pueden desplegar los componentes.

Los componentes son los elementos que participan en la ejecución de un sistema. Los nodos son los elementos donde se ejecutan los componentes.

Los componentes representan el empaquetamiento físico de los elementos lógicos. Los

Nodos representan el despliegue físico de los componentes.

La relación entre un nodo y el componente que despliega puede mostrarse con una relación de dependencia, o listando los nodos desplegados en un compartimiento adicional dentro del nodo.

Los estereotipos permiten precisar la naturaleza del equipo:

•Procesadores: Nodo con capacidad de procesamiento. Puede ejecutar un componente.

•Dispositivos: Nodo sin capacidad de procesamiento. Representa cualquier otro dispositivo hardware.

Los nodos se relacionan mediante conexiones bidireccionales (en principio) que pueden a su vez estereotiparse.  Las conexiones se modelan como asociaciones, con todas las características que implica.

5.3 MODELO DE PRUEBAS

La fase de pruebas del sistema tiene como objetivo verificar el sistema software para comprobar si este cumple sus requisitos. Dentro de esta fase pueden desarrollarse varios tipos distintos de pruebas en función de los objetivos de las mismas. Algunos tipos son pruebas funcionales, pruebas de usabilidad, pruebas de rendimiento, pruebas de seguridad, etc. Este trabajo se centra en pruebas funcionales de aplicaciones con interfaces gráficas. Estas pruebas verifican que el sistema software ofrece a los actores humanos la funcionalidad recogida en su especificación.

 Modelos de requisitos

Los únicos modelos de requisitos necesarios son los casos de uso y los requisitos de almacenamiento, aunque otros modelos, como por ejemplo modelos de interfaces o modelos de navegación  pueden enriquecer el proceso de prueba. Actualmente existen varias propuestas de modelos de requisitos. En concreto, la propuesta que utilizamos en este trabajo es Web Requirement (WebRE) , la cual está basada en Navigational Development Techniques (NDT) .

 Modelo de comportamiento

Un gran número de técnicas de requisitos están basadas en casos de uso definidos en prosa. Uno de ellos es el modelo WebRE utilizado en el punto anterior. Pero no es sencillo manipular programáticamente casos de uso escritos en prosa. Por este motivo, el primer paso de nuestro proceso sistemático de generación de pruebas consiste en expresar dicha prosa mediante un modelo formal manipulable de manera automática.

Modelo de datos de prueba

Los casos de uso contienen elementos variables cuyos valores o comportamiento difiere de una ejecución de un caso de uso a otra . Algunos ejemplos son la información suministrada por un actor, una opción seleccionada por un actor, o la información mostrada por el sistema como resultado del caso de uso.

Modelo de interfaz abstracta

Los modelos anteriores nos indican lo que una prueba debe hacer (ejecutar un escenario posible de un caso de uso), qué información hay que suministrarle y qué información nos va a devolver. Sin embargo estos modelos aún son demasiado abstractos y no se pueden convertir en modelos dependientes de la plataforma ni en pruebas ejecutables de manera directa. Por este motivo, a partir de los modelos anteriores, se obtienen los modelos de interfaz abstracta y de interacción.

 Modelo de interacción

Una vez que se conocen las interfaces con las que las pruebas interactuarán, expresadas mediante el modelo de interfaz abstracta, se refina el modelo de comportamiento para indicar cómo realizar cada uno de los pasos del caso de uso sobre dicha interfaz.

El objetivo del modelo de interacción es definir cómo realiza las pruebas sus acciones y definir los árbitros. En el contexto de las pruebas, un árbitro es elemento encargado de comprobar si la prueba fue superada o no.

Modelo de interfaz concreta y modelo de acciones

Estos modelos permiten traducir las pruebas abstractas a pruebas ejecutables sobre el sistema. Par ello es necesario conocer las interfaces definitivas, incluir los detalles de dichos interfaces y completar las pruebas abstractas. El objetivo del modelo de interfaz concreta es expresar los elementos de la interfaz abstracta en función de los componentes concretos del sistema a prueba. A partir de este modelo, ya se pueden expresar las pruebas a nivel de implementación. El objetivo del modelo de acción es expresar los elementos del modelo de interacción mediante un lenguaje de una herramienta de prueba concreta.