5.1 DIAGRAMA DE COMPONENTES

5.1 Diagramas 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:

      Executable: 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.

Los distintos componentes pueden agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación

§ Son paquetes estereotipados en <<subsistemas>>

Los subsistemas organizan la vista de realización de un sistema

      Cada subsistema puede contener componentes y otros subsistemas

       La descomposición en subsistemas no es necesariamente una descomposición funcional

       La relación entre paquetes y clases en el nivel lógico es el que existe entre subsistemas y componentes en el nivel físico

      Paquetes (Categorias) y clases en el nivel lógico. Paquetes (Subsistemas) y componentes en el nivel físico.

5.2 DIAGRAMA DE DESPLIEGUE

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 MODELOS DE PRUEBAS

5.3 Modelos de Pruebas.

En este punto se describen un conjunto de modelos de prueba independientes y dependientes de la plataforma (PITs y PDTs).

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 cuál está basada en Navigational Development Techniques (NDT) .

Modelo de comportamiento

El objetivo del modelo de comportamiento es expresar la misma información contenida en una plantilla de caso de uso de una forma fácilmente manipulable. Las propuestas estudiadas utilizan como modelos de comportamiento diagramas UML de estados, diagramas UML de secuencia o diagramas UML de actividades

Modelo de datos de prueba

Los objetivos del modelo de datos de prueba son dos. En primer lugar, el modelo de datos de prueba expresa todas las variables del caso de uso, su estructura si son tipos complejos (como clientes o compras), las restricciones que puedan existir entre ellos y las particiones de sus respectivos dominios.

En segundo lugar el modelo de datos de prueba expresa los valores de prueba del sistema y los resultados esperados del mismo. Esto se modela mediante un diagrama de objetos.

Modelo de interfaz abstracta

El objetivo del modelo de interfaz abstracta es definir las interfaces que el sistema ofrecerá para poder realizar la funcionalidad expresada en el modelo de casos de uso y en el modelo de comportamiento. No es necesario, sin embargo, entrar en detalles de la implementación de dichas interfaces.

Modelo de interacción

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.

Estos modelos dependen de la arquitectura y herramienta de prueba que se utilice para ejecutar las pruebas generadas, dado que las pruebas abstractas deben ser traducidas a pruebas comprensibles por dicha herramienta.