5.1 DIAGRAMA DE COMPONENTES

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado. Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes.

Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.

Es un acercamiento basado en la re utilización para definir, implementar, y componer, componentes débilmente acoplados en sistemas. 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). Debido a este principio, con frecuencia se dice que los componentes son modulares y cohesivos. Estas interfaces 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 Tiene como objetivo convertir el diseño de datos,  Interfaces y arquitectura en una representación Intermedia que se pueda transformar fácilmente  en código fuente. El nivel de abstracción debe ser muy próximo al Código.

•    Programación estructurada
•    Notaciones de diseño
•    Notaciones gráficas 
•    Notaciones tabulares
•    Lenguaje de diseño de programas
•    Referencias bibliográficas

Programación estructurada es una de las técnica de diseño procedimental más Importantes. Se trata de un conjunto de construcciones con las que  Se puede restringir el diseño procedimental de un Software a un número de operaciones predecibles. Tipos de construcciones estructuradas: secuenciales, Condicionales y repetitivas.

5.2. DIAGRAMA DE DESPLIEGUE

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo. Este tipo de diagrama debemos también añadir que no van a existir actores para relacionarse con los nodos (no es un diagrama de casos de uso) si no que las relaciones que pueda haber siempre serán entre los nodos y por ejemplo con una base de datos.

USOS: Algunos de los usos que se les da a los diagramas de despliegue son para modelar:

• Sistemas empotrados: Un sistema empotrado es una colección de hardware con una gran cantidad de software que interactúa con el mundo físico.

• Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribución física de los componentes software del sistema a través de nodos.

• Sistemas completamente distribuidos: En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores. Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro. El diseño de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topología del sistema.

5.3. MODELOS DE PRUEBA

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.

Este trabajo describe los modelos necesarios para generar de manera sistemática un conjunto de pruebas que permitan verificar la implementación de los requisitos funcionales de un sistema software.

Una de las técnicas más empleadas para la espcecificación funcional de sistemas software son los casos de uso. Las principales ventajas de los casos de uso son que ocultan los detalles internos del sistema, son rápidos de construir, fáciles de modificar y entender por los clientes y futuros usuarios del sistema  y pueden aplicarse a distintos tipos de sistemas y  Actualmente, existe un amplio número de propuestas que describen cómo generar pruebas del sistema a partir de los casos de uso.
 Aunque la generación de pruebas se adapta a la filosofía propuesta por MDA, tal y como mostraremos a continuación, ninguna de estas propuestas define su proceso en base a las técnicas de MDA. Por este motivo, una de las principales carencias es la falta de modelos que recojan la información necesaria en el proceso de generación de pruebas.

• Modelos de requisitos
• Modelo de comportamiento
• Modelo de datos de prueba
• Modelo de interfaz abstracta
• Modelo de interacción

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. 

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.

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.

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.

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.