UNIDAD 5 : MODELO DE
IMPLEMENTACIÓN
El Modelo de
Implementación es comprendido por un conjunto de componentes y subsistemas que
constituyen la composición física de la implementación del sistema. Entre los
componentes podemos encontrar datos, archivos, ejecutables, código fuente y los
directorios. Fundamentalmente, se describe la relación que existe desde los
paquetes y clases del modelo de diseño a subsistemas y componentes físicos.
Un diagrama de
implementación muestra:
Ø Las dependencias entre las partes
de código del sistema (diagramas de componentes).
Ø La estructura del sistema en ejecución (diagrama de despliegue).
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.
Ø
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.
Ø
Archivos
Ø
Código
fuente + Cabeceras
Ø
Librerías
compartidas (DLLs)
Ø
Ejecutables
Ø
Paquetes
- 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.
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.
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.
•
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, 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.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.
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.
muchas gracias por la información me sirvió un montón
ResponderEliminar