Unidad 5
description
Transcript of Unidad 5
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