Unidad 5 Modelo de Implementacion

7/23/2019 Unidad 5 Modelo de Implementacion

1/14

[Escriba aqu]

GLOBALTEC

Modelo de im lementacin

UNIDAD 5

Integrantes del Equipo:

Cinthia Guadalupe Ramrez Montes

Lezly Susette Reyes Norman

Franklin Iztcoatl Monreal Cristerna

Bernardo Dvila Jimnez

Alfredo Pablo Hernndez


2/14

GlobalTec

Fundamentos de Ingeniera del Sofware UNIDAD 4

Ingeniera en Sistemas Computacionales Pgina 3 de 14

ontenido

5.1 Diagramas de Componentes .......................................................................................................... 4

5.2 Diagrama de despliegue .................................................................................................................. 7

5.3 Modelos de pruebas ........................................................................................................................ 11

Referencias .............................................................................................................................................. 14


3/14

GlobalTec



5.1 Diagramas de Componentes

Los Diagramas de Componentes ilustran las piezas del software, controladoresembebidos, etc. que conformarn un sistema. Un diagrama de Componentes tiene unnivel ms alto de abstraccin que un diagrama de claseusualmente un componente seimplementa por una o ms clases (u objetos) en tiempo de ejecucin. Estos son bloquesde construccin, como eventualmente un componente puede comprender una granporcin de un sistema (Figura 5.1.1).

Figura 5.1.1

El diagrama de abajo muestra algunos componentes y sus relaciones internas. Losconectores Ensamble vinculan las interfaces proporcionadas suministrada por elProducto y el Cliente a las interfaces requeridas especificadas por orden. Una relacinde dependencia traza los detalles de la cuenta asociada del cliente a la interfaz requerida,pago, indicada por orden.


4/14

GlobalTec



Los componentes son similares en prctica a los diagramas de paquete como los lmitesdefinidos y se usan para agrupar elementos en estructuras lgicas. La diferencia entreDiagramas de Paquete y Diagramas de Componente es que los diagramas decomponente ofrecen un mecanismo de agrupamiento ms rico semnticamente. Con losDiagramas 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 clasificadorrectangular con la clave componente, opcionalmente el componente se puede mostrarcomo un rectngulo con un icono de componente en la esquina derecha arriba (Figura5.1.2).

Figura 5.1.2

Interfaces requeridas: El conector Ensamble une la interfaz requerida del componente(Componente1) con la interfaz proporcionada de otro componente (Component2); estopermite 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(Figura 5.1.3).

Figura 5.1.3


5/14

GlobalTec



Componentes con puertos: Usar puertos con Diagramas de Componentes permite quese especifique un servicio o comportamiento a su entorno as como tambin un servicioo comportamiento que un componente requiere. Los puertos pueden especificarentradas, salidas as como tambin operar bi-direccionalmente. El siguiente diagramadetalla un componente con un puerto para servicios En Lnea conjuntamente con dos

interfaces proporcionadas Ordenar Entrada y Seguimiento as como tambin una interfazrequerida Pago (Figura 5.1.4).

Figura 5.1.4


6/14

GlobalTec



5.2 Diagrama de despliegue

Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecucin de unsistema. Esto muestra la configuracin de los elementos de hardware (nodos) y muestracmo 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 formade una caja en tres dimensiones, como a continuacin (Figura 5.2.1).

Figura 5.2.1

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 estasubrayado y tiene dos puntos antes del tipo de nodo base. Una instancia puede o notener un nombre antes de los dos puntos. El siguiente diagrama muestra una instancianombrada de una computadora (Figura 5.2.2).

Figura 5.2.2


7/14

GlobalTec



Estereotipo de nodo: Un nmero de estereotipos estndar se proveen para los nodos,nombrados cdrom, cd-rom, computer, disk array, pc, pc client, pcserver, secure, server, storage, unix server, user pc. Estos mostrarn unicono apropiado en la esquina derecha arriba del smbolo nodo (Figura 5.2.3).

Figura 5.2.3

Artefacto: Un artefacto es un producto del proceso de desarrollo de software, que puedeincluir los modelos del proceso (e.g. modelos de Casos de Uso, modelos de Diseo, etc.),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, como a continuacin (Figura 5.2.4).

Figura 5.2.4


8/14

GlobalTec



Asociacin: En el contexto del diagrama de despliegue, una asociacin representa unaruta de comunicacin entre los nodos. El siguiente diagrama muestra un diagrama dedespliegue para una red, mostrando los protocolos de red como estereotipos y tambinmostrando multiplicidades en los extremos de la asociacin (Figura 5.2.5).

Figura 5.2.5

Nodo como contenedor: Un nodo puede contener otros elementos, como componenteso artefactos. El siguiente diagrama muestra un diagrama de despliegue para una partedel sistema embebido y muestra un artefacto ejecutable como contenido por el nodomadre (motherboard) (Figura 5.2.6).


9/14

GlobalTec



Figura 5.2.6


10/14

GlobalTec



5.3 Modelos de pruebas

Uno de los objetivos de la fase de pruebas del sistema es verificar que el comportamientoexterno del sistema software satisface los requisitos establecidos por los clientes yfuturos usuarios del mismo. A medida que aumenta la complejidad de los sistemassoftware y aumenta la demanda de calidad, se hacen necesarios procesos y mtodosque permitan obtener buenos conjuntos de pruebas del sistema. Este trabajo describelos modelos necesarios para generar de manera sistemtica un conjunto de pruebas quepermitan verificar la implementacin de los requisitos funcionales de un sistema software.

La fase de pruebas del sistema tiene como objetivo verificar el sistema software paracomprobar si este cumple sus requisitos. Dentro de esta fase pueden desarrollarse variostipos distintos de pruebas en funcin de los objetivos de las mismas. Algunos tipos sonpruebas funcionales, pruebas de usabilidad, pruebas de rendimiento, pruebas deseguridad, etc. Este trabajo se centra en pruebas funcionales de aplicaciones coninterfaces grficas. Estas pruebas verifican que el sistema software ofrece a los actoreshumanos la funcionalidad recogida en su especificacin.

Una de las tcnicas ms empleadas para la especificacin funcional de sistemassoftware son los casos de uso. Las principales ventajas de los casos de uso son queocultan los detalles internos del sistema, son rpidos de construir, fciles de modificar yentender por los clientes y futuros usuarios del sistema y pueden aplicarse a distintostipos de sistemas. Actualmente, existe un amplio nmero de propuestas que describencmo 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 informacinsuministrada por un actor, una opcin seleccionada por un actor, o la informacinmostrada por el sistema como resultado del caso de uso.

Los objetivos del modelo de datos de prueba son dos. En primer lugar, el modelo dedatos de prueba expresa todas las variables del caso de uso, su estructura si son tiposcomplejos (como clientes o compras), las restricciones que puedan existir entre ellos ylas particiones de sus respectivos dominios. Esto se realiza mediante un diagrama declases segn la notacin propuesta en el Testing Profile de UML. Dicho diagrama declases puede extraerse automticamente. Las clases se obtienen a partir de losrequisitos funcionales y las distintas particiones se obtienen a partir de las condiciones

evaluadas en las alternativas del diagrama de comportamiento. Este diagrama de clasespuede refinarse posteriormente aadiendo particiones adicionales si fuera necesario.


11/14

GlobalTec



Qu tipo de pruebas se pueden hacer en ingeniera del software?

Una vez obtenido el cdigo ejecutable de un programa depurado lo mximo posible, hayque comprobar, exhaustivamente, su funcionalidad. Para ello, se tiene que ejecutartantas 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. Portanto, las pruebas a realizar se deben centrar en la bsqueda de errores de ejecucin ode lgica.

Para estar totalmente seguros del buen funcionamiento de un programa se deberaprobar 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 bienelegidas, intentando abarcar el mayor nmero de casos, y poniendo a prueba al

programa en aspectos crticos.En un programa tan simple como el de este ejemplo, las pruebas a realizar pueden llevarpoco tiempo. Sin embargo, cuando se desarrolla una aplicacin grande, las pruebaspueden tardar semanas o incluso meses. Las pruebas no slo se deben centrar en lacomprobacin del tratamiento de los datos, sino tambin en aspectos como: laadaptacin de la aplicacin al resto del sistema informtico o la interaccin del softwarecon otras aplicaciones ya existentes. Una aplicacin informtica de tal envergadurapuede estar formada por cientos o miles de programas, y todos ellos deben ser probadosindividual y conjuntamente. Antes de implantar un software de estas caractersticas, lonormal es hacer simulaciones con datos reales para verificar su buen funcionamiento.

Para corregir los errores de ejecucin o de lgica encontrados en la fase de pruebas,casi siempre, por no decir siempre, hay que modificar el algoritmo y, en algunos casos,incluso hay que volver a analizar el problema, volviendo a pasar por todas las fases dedesarrollo; de lo cual se deduce que, cuanto mejor se haga el anlisis y el diseo de unaaplicacin, la probabilidad de encontrar errores en la fase de pruebas ser menor.


12/14

GlobalTec



Tipos de pruebas:

Pruebas estticasSon el tipo de pruebas que se realizan sin ejecutar el cdigo de la aplicacin.

Pruebas dinmicasTodas 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


13/14

GlobalTec



Referencias

o Diagrama de despliegue

http://www.sparxsystems.com.ar/resources/tutorial/uml2_deploymentdiagram.html

o Diagrama de componentes

http://www.sparxsystems.com.ar/resources/tutorial/uml2_componentdiagram.html

o Modelos de pruebas

http://ceur-ws.org/Vol-227/paper07.pdf

http://farova2.blogspot.mx/2008/10/modelo-de-pruebas-de-software.html http://es.wikipedia.org/wiki/Pruebas_de_software

http://www.carlospes.com/curso_de_ingenieria_del_software/05_01_pruebas.php
http://www.sparxsystems.com.ar/resources/tutorial/uml2_componentdiagram.htmlhttp://www.sparxsystems.com.ar/resources/tutorial/uml2_componentdiagram.htmlhttp://ceur-ws.org/Vol-227/paper07.pdfhttp://ceur-ws.org/Vol-227/paper07.pdfhttp://farova2.blogspot.mx/2008/10/modelo-de-pruebas-de-software.htmlhttp://farova2.blogspot.mx/2008/10/modelo-de-pruebas-de-software.htmlhttp://es.wikipedia.org/wiki/Pruebas_de_softwarehttp://es.wikipedia.org/wiki/Pruebas_de_softwarehttp://es.wikipedia.org/wiki/Pruebas_de_softwarehttp://farova2.blogspot.mx/2008/10/modelo-de-pruebas-de-software.htmlhttp://ceur-ws.org/Vol-227/paper07.pdfhttp://www.sparxsystems.com.ar/resources/tutorial/uml2_componentdiagram.html


14/14

GlobalTec



Unidad 5 Modelo de Implementacion

Documents

Transcript of Unidad 5 Modelo de Implementacion