INSTITUTO TECNOLÓGICO DE POCHUTLA.

Ingeniería en sistemas computacionales. V semestre.

Investigación unidad 5 “modelo de implementación” Profesora: Sheily de los santos Vargas.

José Eloy Velázquez Ojeda. Adán Hernández Sánchez. 09/12/2015

Introducción.

En el presente trabajo de investigación de campo se muestran contenidos

acerca de la unidad 5 de la materia fundamentos de ingeniería 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 interacción 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 función de los objetivos de las mismas.

5.1 Diagramas de Componentes

Los diagramas de componentes ilustran las piezas del software, controladores

embebidos, etc. que conformarán un sistema. Un diagrama de componentes

tiene un nivel más alto de abstracción que un diagrama de clase usualmente

un componente se implementa por una o más clases (u objetos) en tiempo de

ejecución. Estos son bloques de construcción, como eventualmente un

componente puede comprender una gran porción de un sistema.

Los componentes son similares en práctica a los diagramas de paquete como

los límites definidos y se usan para agrupar elementos en estructuras lógicas.

La diferencia entre diagramas de paquete y diagramas de componente es que

los diagramas de componente ofrecen un mecanismo de agrupamiento más

rico semánticamente. Con los diagramas de componente todos los elementos

del modelo son privados mientras que los diagramas de paquete solo muestran

ítems públicos.

Representando componentes: Componentes se representan como un

clasificador rectangular con la clave «componente», opcionalmente el

componente se puede mostrar como un rectángulo 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 más métodos

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 también un servicio o comportamiento que un componente requiere. Los

puertos pueden especificar entradas, salidas así como también operar

bidireccionalmente. El siguiente diagrama detalla un componente con un puerto

para servicios En línea conjuntamente con dos interfaces proporcionadas

ordenar entrada y seguimiento así como también una interfaz requerida pago.

5.2 Diagrama de despliegue

Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecución de

un sistema. Esto muestra la configuración de los elementos de hardware

(nodos) y muestra cómo 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 continuación.

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 número de estereotipos estándar 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 mostrarán un icono apropiado en la esquina derecha arriba del

símbolo 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 diseño, reportes de prueba, prototipos, manuales de usuario y

más.

Un artefacto se denota por un rectángulo mostrando el nombre del artefacto, el

estereotipo «artifact» y un icono de documento.

Asociación: En el contexto del diagrama de despliegue, una asociación

representa una ruta de comunicación entre los nodos. El siguiente diagrama

muestra un diagrama de despliegue para una red, mostrando los protocolos de

red como estereotipos y también mostrando multiplicidades en los extremos de

la asociación.

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 verificar que el

comportamiento externo del sistema software satisface los requisitos

establecidos por los clientes y futuros usuarios del mismo. A medida que

aumenta la complejidad de los sistemas software y aumenta la demanda de

calidad, se hacen necesarios procesos y métodos que permitan obtener

buenos conjuntos de pruebas del sistema. 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 especificació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. Actualmente, existe

un amplio número de propuestas que describen cómo 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 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.

¿Qué tipo de pruebas se pueden hacer en ingeniería del software?

Una vez obtenido el código ejecutable de un programa depurado lo máximo

posible, hay que comprobar, exhaustivamente, su funcionalidad. Para ello, se

tiene que ejecutar tantas veces como se considere necesario,

proporcionándole, cada vez, datos de entrada distintos, y comprobando si los

datos de salida son siempre los esperados.

El código ejecutable de un programa es imposible que tenga errores de

sintaxis, ya que, estos habrán sido detectados por el compilador y corregidos

por el programador. Por tanto, las pruebas a realizar se deben centrar en la

búsqueda de errores de ejecución o de lógica.

Para estar totalmente seguros del buen funcionamiento de un programa se

debería probar con todas las combinaciones posibles de entrada, cosa que

suele ser imposible, ya que, éstas podrían ser infinitas. Así pues, las pruebas

tienen que ser muy bien elegidas, intentando abarcar el mayor número de

casos, y poniendo a prueba al programa en aspectos críticos.

Tipos de pruebas:

Pruebas estáticas

Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación.

Pruebas dinámicas

Todas aquellas pruebas que para su ejecución requieren la ejecución de la

aplicación.

Tipos de pruebas por su ejecución

Pruebas automáticas

Pruebas manuales

Niveles de pruebas

Pruebas unitarias

Pruebas de Integración

Pruebas de sistema

Pruebas funcionales

Pruebas funcionales

Pruebas de humo

Pruebas de regresión

Pruebas de aceptación

Alpha testing

Beta testing

Pruebas no funcionales

Pruebas no funcionales

Pruebas de seguridad

Pruebas de usabilidad

Pruebas de rendimiento

Pruebas de internacionalización y localización

Pruebas de escalabilidad

Pruebas de mantenibilidad

Pruebas de instabilidad

Pruebas de portabilidad

Conclusión

En conclusión podemos resaltar, que el modelo de implementación es una fase

muy necesaria para el desarrollo de software, ya que en esta se verifican e

implementan componentes que no se tenían 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 serán de mucha ayuda para

futuras materias que tengan que ver con la ingeniería de software.

Bibliografía.

Alonso, F. & Martínez, L. (2005). Introducción a la ingeniería de software.

Modelos de desarrollo de programas. Zaragoza. España: delta publicaciones.

Somerville, I. (2005). Ingeniería de software. Madrid, España: Pearson

educación.

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