UNIDAD 5 : MODELO DE IMPLEMENTACIN

El Modelo de Implementacin es comprendido por un conjunto de

componentes y subsistemas que constituyen la composicin fsica de la
implementacin del sistema. Entre los componentes podemos encontrar
datos, archivos, ejecutables, cdigo fuente y los directorios.
Fundamentalmente, se describe la relacin que existe desde los paquetes y
clases del modelo de diseo a subsistemas y componentes fsicos.
Un diagrama de implementacin muestra:
Las dependencias entre las partes
componentes).

de cdigo del sistema (diagramas de

La estructura del sistema en ejecucin (diagrama de despliegue).

5.1 DIAGRAMAS DE COMPONENTES

Un componente es una parte fsica de un sistema (modulo, base de datos,
programa ejecutable, etc.). Se puede decir que un componente es la
materializacin de una o ms clases, porque una abstraccin con atributos y
mtodos pueden ser implementados en los componentes.
Respecto a los componentes
Es implementado por una o ms clases/objetos del sistema.
Es una unidad autnoma que provee una o ms interfaces.
Las interfaces representan un contrato de servicios que el componente
ofrece.
Los componentes pueden ser:
Archivos
Cdigo fuente + Cabeceras
Libreras compartidas (DLLs)

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

Proveen una vista arquitectnica de alto nivel del sistema.

Ayuda a los desarrolladores a visualizar el camino de la

implementacin.

Permite tomar decisiones respecto a las tareas de implementacin y

los Skills requeridos.

En un DC, un componente se representa con un rectngulo en el que se

escribe su nombre y en l se muestran dos pequeos rectngulos al lado
izquierdo. O tambin los siguientes:
Representacin simple de un Componente

Elementos del Diagrama de Componentes

Normalmente
Componentes contienen:

los

diagramas

de

componentes

interfaces

Relaciones de dependencia, generalizacin, asociacin y realizacin

Paquetes o subsistemas
Los componentes se pueden agrupar en paquetes as como los objetos en
clases, adems pueden haber entre ellos relaciones de dependencia como:

generalizacin

asociacin

agregacin

realizacin
Estereotipos de componentes
UML define cinco estereotipos estndar que se aplican en los componentes

Executable, componente que se puede ejecutar

Library, biblioteca de objetos esttica o dinmica
Table, Componentes que representa una tabla de base de datos
File, componente que representa un documento que contiene cdigo 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 disposicin fsica o topologa de un sistema.
Muestra el hardware usado y los componentes instalados en el hardware.
Muestra las conexiones fsicas 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 fsico:

Computadoras
Sensores
Impresoras

 Servidores
Dispositivos externos
Los nodos pueden ser interconectados mediante lneas para describir una
estructura de red.
Un nodo es un objeto fsico en tiempo de ejecucin que representa un
recurso computacional, generalmente con memoria y capacidad de
procesamiento.

Estereotipo de nodo
Estereotipo, son cosas u objetos q se repiten sin variacin.
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 nmero de estereotipos estndar, nombrados cdrom,disk
array, pc client, unix server.. etc. Estos mostrarn un icono apropiado
en la esquina derecha arriba del smbolo 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
Diseo, etc.), archivos fuente, ejecutables, documentos de diseo, reportes
de prueba, prototipos, manuales de usuario etc.

Donde un artefacto es un conjunto de componentes.

Ejemplo Grafico
Un artefacto se denota por un rectngulo mostrando el nombre del
artefacto, el estereotipo artifact y un icono de documento, como a
continuacin.

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 Verificacin
Ver si cumple las especificaciones de diseo
*Pruebas de Validacin
Ver si cumple los requisitos del anlisis.
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 especificacin.

Pruebas de caja blanca

Pruebas en que se conoce el cdigo a probar
Caja blanca (clear box: caja clara o transparente)
Se procura ejercitar cada elemento del cdigo
Algunas clases de pruebas
Pruebas de cubrimiento
Pruebas de condiciones
Pruebas de bucles

Pruebas de caja negra

Pruebas en que se conoce slo 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 lmite
Estrategias de prueba del software
Pruebas de unidades
Pruebas de integracin
Pruebas de regresin
Pruebas de validacin
Pruebas de unidades:
Se concentra en el esfuerzo de verificacin de la unidad ms pequea del
diseo del software: el componente o mdulo del software.
Las pruebas de unidad se concentran en la lgica del procesamiento interno.
Este tipo de prueba se puede aplicar en paralelo a varios componentes.
Pruebas de integracin:
La prueba de integracin es una tcnica sistemtica 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 diseo.
Pruebas de regresin:
La prueba de integracin es una tcnica sistemtica 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 diseo.
Pruebas de validacin:
Las pruebas de validacin empiezan tras la culminacin de la prueba de
integracin, 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.

Bibliogrfias :
http://es.scribd.com/doc/7884665/Arquitectura-de-Software-IIDiagrama-de-Componentes-y-Despliegue
http://www.slideshare.net/techmi/curso-uml-25-diagramas-deimplementacion