Diagramas de Actividad

Diagramas de Actividad
Los diagramas de actividades sirven para representar el
comportamiento dinmico de un sistema.
haciendo hincapi
En la secuencia de actividades que se llevan a cabo y las condiciones
que guardan o disparan esas actividades.

Componentes de los diagramas de actividad

Restricciones
Un estado inicial no puede ser destino de una transicin
Toda actividad tiene al menos un flujo de entrada y otro de Salida.
Puede haber cero o ms estados finales (por ejemplo, un proceso
continuo no tendr estado final)

Componentes de los diagramas de actividad

Restricciones
Una decisin tiene un flujo de entrada y dos o ms de salida

Se puede utilizar la condicin else para representar el flujo que se sigue en caso de
que ninguna de las otras condiciones sea cierta.

Las condiciones de todos los flujos de salida de una decisin deben ser disjuntas y
completas.
Todo flujo de salida de una decisin debe estar etiquetado con una condicin.
Una fusin tiene dos o ms flujos de entrada y un flujo de salida.

Componentes de los diagramas de

actividad
Un diagrama de actividades tambin nos permite representar flujos que ocurren de
forma concurrente (en paralelo).
Tambin permite indicar actividades que se pueden hacer en cualquier orden (si lo
hicieran elementos distintos lo podran hacer a la vez)

Reglas
Una divisin tiene un flujo de entrada y dos o ms flujos de salida.
El flujo de salida de una unin se dispara cuando se han finalizado
todos los flujos de entrada en la unin (todos ellos discurren en
paralelo).

Componentes de los diagramas de

actividad
Para que los diagramas no queden excesivamente complejos
se pueden modularizar haciendo uso de subactividades.

Reglas
Un diagrama de actividades demasiado grande nos debe hacer
pensar que igual conviene incluir alguna subactividad para
simplificarlo

Componentes de los diagramas de

actividad
Se pueden hacer particiones en un diagrama de actividades para
identificar las acciones que tienen alguna caracterstica en comn.
Por ejemplo que se llevan a cabo por un mismo actor.

Reglas
Cada actividad debe estar en una particin
No aconsejan representar diagramas

Tipos de Prueba

PRUEBAS UNITARIAS
Se focaliza en ejecutar cada mdulo (o unidad mnima a ser probada, ej = una clase) lo que
provee un mejor modo de manejar la integracin de las unidades en componentes mayores.
Consiste en:
Particionar los mdulos en pruebas en unidades lgicas fciles de probar.
Por cada unidad hay que definir los casos de prueba (pruebas de caja blanca).
Para esto los casos de prueba deben disearse de forma tal que se recorran todos los
caminos de ejecucin posibles dentro del cdigo bajo prueba; por lo tanto el diseador debe
construirlos con acceso al cdigo fuente de la unidad a probar.

PRUEBAS DE INTEGRACIN
Identificar errores introducidos por la combinacin de programas probados unitariamente.
Determina cmo la base de datos de prueba ser cargada.
Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan
correctamente.
Consiste:
Describe cmo verificar que las interfaces entre las componentes de software funcionan correctamente.
Determina cmo la base de datos de prueba ser cargada.
Determina el enfoque para avanzar desde un nivel de integracin de las componentes al siguiente.

Prueba de Regresin
Determinar si los cambios recientes en una parte de la aplicacin tienen efecto adverso en otras
partes.
Consiste:
En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados durante el
debugging, mantenimiento o desarrollo de la nueva versin del sistema buscando efectos adversos
en otras partes.
La prueba de regresin es una nueva corrida de casos de prueba previos.
Se requiere de polticas para ser creada la prueba de regresin y decidir qu casos
de prueba incluir, para probar eficientemente.

Pruebas de Humo (Smoke Testing o Ad

Hoc)
Toma ste nombre debido a que su objetivo es probar el sistema constantemente buscando que
saque humo o falle.
En algunos proyectos este tipo de prueba va junto con las pruebas funcionales.
Permite detectar problemas que por lo regular no son detectados en las pruebas normales.
Algunas veces, si las Pruebas ocurren tarde en el ciclo de desarrollo est ser una forma de
garantizar el buen desarrollo.

Prueba de Usabilidad
Determina cun bien el usuario podr usar y entender la aplicacin. Identifica las reas de diseo que
hacen al sistema de difcil uso para el usuario.
La prueba de usabilidad detecta problemas relacionados con la conveniencia y practicidad del sistema
desde el punto de vista del usuario.
Consiste en verificar que la aplicacin no presenta los siguientes problemas de usabilidad tpicos:
El sistema es demasiado complejo y difcil de usar.
Es difcil instalar y entender el sistema.
La recuperacin de errores es pobre y los mensajes de error no tienen significado.

Pruebas Funcionales
Se asegura el trabajo apropiado de los requisitos funcionales, incluyendo la navegacin, entrada
de datos, procesamiento y obtencin de resultados.
Las pruebas Funcionales deben enfocarse en los requisitos funcionales, las pruebas pueden
estar basadas directamente en los Casos de Uso (o funciones de negocio), y las reglas del
negocio.
Las metas de estas pruebas son:
Verificar la apropiada aceptacin de datos,
Verificar el procesamiento y recuperacin y la implementacin adecuada de las reglas del negocio.

Pruebas de caja Negra

QUE ES CAJA NEGRA?
En teora de sistemas y fsica, se denomina caja negra a aquel elemento que es
estudiado desde el punto de vista de las entradas que recibe y las salidas o
respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras
palabras, de una caja negra nos interesar su forma de interactuar con el medio
que le rodea.

Pruebas de caja Negra

LO MAS IMPORTANTE
Una caja negra deben estar muy bien definidas sus entradas y salidas, es decir,
su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su
funcionamiento.

Diagrama de Caja Negra

Pruebas de Caja Blanca

Pruebas de Caja Blanca

Concepto:
Las pruebas de caja blanca (tambin
conocidas como pruebas de caja de cristal
o pruebas estructurales) se centran en los
detalles procedimentales del software, por
lo que su diseo est fuertemente ligado al
cdigo fuente

Pruebas de Caja Blanca

La prueba de caja blanca se basa en el diseo de casos de prueba que usa la estructura de control del diseo
procedimental para derivarlos. Mediante la prueba de la caja blanca el ingeniero del software puede obtener
casos de prueba que:
Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de cada mdulo,
programa o mtodo.
Ejerciten todas las decisiones lgicas en las vertientes verdadera y falsa.
Ejecuten todos los bucles en sus lmites operacionales.
Ejerciten las estructuras internas de datos para asegurar su validez.