INSTITUTO TECNOLGICO DE POCHUTLA.

Ingeniera en sistemas computacionales. V semestre.

Investigacin
unidad 5 modelo
de implementacin
Profesora: Sheily de los santos Vargas.

Jos Eloy Velzquez Ojeda.

Adn Hernndez Snchez.
09/12/2015

Introduccin.

En el presente trabajo de investigacin de campo se muestran contenidos

acerca de la unidad 5 de la materia fundamentos de ingeniera de software, en
el cual comprenderemos la utilidad de diagramas de componentes los cuales
son tienen cabida en el desarrollo de un sistema ya que en l se muestran
todos los componentes en general que aportan acciones al sistema.
Por otra parte abordaremos el tema de diagramas de despliegue, el cual se
refiere a la interaccin general de todos los componentes de la arquitectura del
software.
Por ultimo estudiaremos el tema de modelo de pruebas, ste 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 funcin de los objetivos de las mismas.

5.1 Diagramas de Componentes

Los diagramas de componentes ilustran las piezas del software, controladores
embebidos, etc. que conformarn un sistema. Un diagrama de componentes
tiene un nivel ms alto de abstraccin que un diagrama de clase usualmente
un componente se implementa por una o ms clases (u objetos) en tiempo de
ejecucin. Estos son bloques de construccin, como eventualmente un
componente puede comprender una gran porcin de un sistema.
Los componentes son similares en prctica a los diagramas de paquete como
los lmites definidos y se usan para agrupar elementos en estructuras lgicas.
La diferencia entre diagramas de paquete y diagramas de componente es que
los diagramas de componente ofrecen un mecanismo de agrupamiento ms
rico semnticamente. Con los diagramas de componente todos los elementos
del modelo son privados mientras que los diagramas de paquete solo muestran
tems pblicos.
Representando componentes: Componentes se representan como un
clasificador rectangular con la clave componente, opcionalmente el
componente se puede mostrar como un rectngulo con un icono de
componente en la esquina derecha arriba

Interfaces requeridas: El conector Ensamble une la interfaz requerida del

componente (Componente1) con la interfaz proporcionada de otro componente
(Component2); esto permite que un componente provea los servicios que otro
componente requiere. Las interfaces son colecciones de uno o ms mtodos
que pueden o no contener atributos

Componentes con puertos: Usar puertos con diagramas de componentes

permite que se especifique un servicio o comportamiento a su entorno as
como tambin un servicio o comportamiento que un componente requiere. Los
puertos pueden especificar entradas, salidas as como tambin operar
bidireccionalmente. El siguiente diagrama detalla un componente con un puerto
para servicios En lnea conjuntamente con dos interfaces proporcionadas
ordenar entrada y seguimiento as como tambin una interfaz requerida pago.

5.2 Diagrama de despliegue

Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecucin de
un sistema. Esto muestra la configuracin de los elementos de hardware
(nodos) y muestra cmo los elementos y artefactos del software se trazan en
esos nodos.
Nodo: Un Nodo es un elemento de hardware o software. Esto se muestra con
la forma de una caja en tres dimensiones, como a continuacin.

Instancia de nodo: Una instancia de nodo se puede mostrar en un diagrama.

Una instancia se puede distinguir desde un nodo por el hecho de que su
nombre esta subrayado y tiene dos puntos antes del tipo de nodo base. Una
instancia puede o no tener un nombre antes de los dos puntos. El siguiente
diagrama muestra una instancia nombrada de una computadora.

Estereotipo de nodo: Un nmero de estereotipos estndar se proveen para

los nodos, nombrados cdrom, cd-rom, computer, disk array, pc,
pc client, pc server, secure, server, storage, unix server, user
pc. Estos mostrarn un icono apropiado en la esquina derecha arriba del
smbolo nodo

Artefacto: Un artefacto es un producto del proceso de desarrollo de software,

que puede incluir los modelos del proceso de archivos fuente, ejecutables,
documentos de diseo, reportes de prueba, prototipos, manuales de usuario y
ms.
Un artefacto se denota por un rectngulo mostrando el nombre del artefacto, el
estereotipo artifact y un icono de documento.

Asociacin: En el contexto del diagrama de despliegue, una asociacin

representa una ruta de comunicacin entre los nodos. El siguiente diagrama
muestra un diagrama de despliegue para una red, mostrando los protocolos de
red como estereotipos y tambin mostrando multiplicidades en los extremos de
la asociacin.

Nodo como contenedor: Un nodo puede contener otros elementos, como

componentes o artefactos. El siguiente diagrama muestra un diagrama de
despliegue para una parte del sistema embebido y muestra un artefacto
ejecutable como contenido por el nodo madre (motherboard).

5.3 Modelos de pruebas.

Uno de los objetivos de la fase de pruebas del sistema es
comportamiento externo del sistema software satisface
establecidos por los clientes y futuros usuarios del mismo.
aumenta la complejidad de los sistemas software y aumenta

verificar que el
los requisitos
A medida que
la demanda de

calidad, se hacen necesarios procesos y mtodos que permitan obtener

buenos conjuntos de pruebas del sistema. Este trabajo describe los modelos
necesarios para generar de manera sistemtica un conjunto de pruebas que
permitan verificar la implementacin de los requisitos funcionales de un sistema
software.
Una de las tcnicas ms empleadas para la especificacin 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 rpidos de
construir, fciles de modificar y entender por los clientes y futuros usuarios del
sistema y pueden aplicarse a distintos tipos de sistemas. Actualmente, existe
un amplio nmero de propuestas que describen cmo generar pruebas del
sistema a partir de los casos de uso.
Los casos de uso contienen elementos variables cuyos valores o
comportamiento difiere de una ejecucin de un caso de uso a otra. Algunos
ejemplos son la informacin suministrada por un actor, una opcin
seleccionada por un actor, o la informacin mostrada por el sistema como
resultado del caso de uso.
Qu tipo de pruebas se pueden hacer en ingeniera del software?
Una vez obtenido el cdigo ejecutable de un programa depurado lo mximo
posible, hay que comprobar, exhaustivamente, su funcionalidad. Para ello, se
tiene que ejecutar tantas veces como se considere necesario,
proporcionndole, cada vez, datos de entrada distintos, y comprobando si los
datos de salida son siempre los esperados.
El cdigo ejecutable de un programa es imposible que tenga errores de
sintaxis, ya que, estos habrn sido detectados por el compilador y corregidos
por el programador. Por tanto, las pruebas a realizar se deben centrar en la
bsqueda de errores de ejecucin o de lgica.
Para estar totalmente seguros del buen funcionamiento de un programa se
debera probar con todas las combinaciones posibles de entrada, cosa que
suele ser imposible, ya que, stas podran ser infinitas. As pues, las pruebas
tienen que ser muy bien elegidas, intentando abarcar el mayor nmero de
casos, y poniendo a prueba al programa en aspectos crticos.

Tipos de pruebas:
Pruebas estticas
Son el tipo de pruebas que se realizan sin ejecutar el cdigo de la aplicacin.
Pruebas dinmicas

Todas aquellas pruebas que para su ejecucin requieren la ejecucin de la

aplicacin.
Tipos de pruebas por su ejecucin
Pruebas automticas
Pruebas manuales

Niveles de pruebas
Pruebas unitarias
Pruebas de Integracin
Pruebas de sistema

Pruebas funcionales
Pruebas funcionales
Pruebas de humo
Pruebas de regresin
Pruebas de aceptacin
Alpha testing
Beta testing

Pruebas no funcionales
Pruebas no funcionales
Pruebas de seguridad
Pruebas de usabilidad
Pruebas de rendimiento

Pruebas de internacionalizacin y localizacin

Pruebas de escalabilidad
Pruebas de mantenibilidad
Pruebas de instabilidad
Pruebas de portabilidad

Conclusin
En conclusin podemos resaltar, que el modelo de implementacin es una fase
muy necesaria para el desarrollo de software, ya que en esta se verifican e
implementan componentes que no se tenan contemplados en los modelos
anteriores, como es el caso de los controladores o la portabilidad del sistema
en diferentes arquitecturas o sistemas operativos.
Cabe destacar que este, como los modelos vistos anteriormente, son de gran
utilidad y de suma importancia para poder desarrollar un sistema, que sea
robusto y cumpla con las expectativas previstas por el usuario y por los
desarrolladores al inicio del proyecto, y que nos sern de mucha ayuda para
futuras materias que tengan que ver con la ingeniera de software.

Bibliografa.
Alonso, F. & Martnez, L. (2005). Introduccin a la ingeniera de software.
Modelos de desarrollo de programas. Zaragoza. Espaa: delta publicaciones.
Somerville, I. (2005). Ingeniera de software. Madrid, Espaa: Pearson
educacin.
http://www.sparxsystems.com.ar/resources/tutorial/uml2_deploymentdiagram.html
http://www.sparxsystems.com.ar/resources/tutorial/uml2_componentdiagram.html
http://farova2.blogspot.mx/2008/10/modelo-de-pruebas-de-software.html