jueves, 13 de mayo de 2010

DIAGRAMAS DE UML

DIAGRAMAS DE CASO DE USO



Un diagrama de casos de uso es una especie de diagrama de comportamiento.
Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.

Relaciones de Casos de Uso:
Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML, el cual describe notación gráfica para esas relaciones.

Inclusión (include o use)Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido.

Extensión (Extend)Es otra forma de interacción, un caso de uso dado, (la extensión) puede extender a otro. Esta relación indica que el comportamiento del caso de uso extensión puede ser insertado en el caso de uso extendido bajo ciertas condiciones.

Generalización En la tercera forma de relaciones entre casos de uso, existe una relación generalización/especialización. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una línea solida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general.

DIAGRAMA DE ACTIVIDADES



Un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general.
La especificación del Lenguaje de Modelado Unificado OMG define un diagrama de actividad como: “… una variación de una máquina estados, lo cual los estados representan el rendimiento de las acciones o subactividades y las transiciones se provocan por la realización de las acciones o subactividades.

DIAGRAMA DE CLASES



Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se relacionan unas con otras. Se dice que los diagramas de clases son diagramas «estáticos» porque muestran las clases, junto con sus métodos y atributos, así como las relaciones estáticas entre ellas: qué clases «conocen» a qué otras clases o qué clases «son parte» de otras clases, pero no muestran los métodos mediante los que se invocan entre ellas.

DIAGRAMA DE COLABORACION



Los diagramas de colaboración muestran las interacciones que ocurren entre los objetos que participan en una situación determinada. Esta es más o menos la misma información que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los diagramas de colaboración fijan el interés en las relaciones entre los objetos y su topología.

En los diagramas de colaboración los mensajes enviados de un objeto a otro se representan mediante flechas, mostrando el nombre del mensaje, los parámetros y la secuencia del mensaje. Los diagramas de colaboración están indicados para mostrar una situación o flujo programa específicos y son unos de los mejores tipos de diagramas para demostrar o explicar rápidamente un proceso dentro de la lógica del programa.

DIAGRAMA DE SECUENCIA



Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada método de la clase. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos.

DIAGRAMA DE COMPONENTES

DIAGRAMA DE ESTADOS


Los diagramas de estado muestran los diferentes estados de un objeto durante su vida, y los estímulos que provocan los cambios de estado en un objeto.

Los diagramas de estado ven a los objetos como máquinas de estado o autómatas finitos que pueden estar en un conjunto de estados finitos y que pueden cambiar su estado a través de un estímulo perteneciente a un conjunto finito. Por ejemplo, un objeto de tipo NetServer puede tener durante su vida uno de los siguientes estados:
-Listo
-Escuchando
-Trabajando
-Detenido
y los eventos que pueden producir que el objeto cambie de estado son
Se crea el objeto
-El objeto recibe un mensaje de escucha
-Un cliente solicita una conexión a través de la red
-Un cliente finaliza una solicitud
-La solicitud se ejecuta y ser termina
-El objeto recibe un mensaje de detención

DIAGRAMA DE TIEMPOS



Diagrama de Tiempo
Los diagramas de tiempos de UML se usan para mostrar el cambio en el estado o valor de uno o más elementos en el tiempo. Este también puede mostrar la interacción entre los eventos de tiempos, las restricciones de tiempos y la duración que los gobiernan.

Línea de vida del estado
Una línea de vida del estado muestra el cambio de estado de ítem en el tiempo. El eje-X muestra el tiempo trascurrido en cualquier unidad que se elija mientras que el eje-Y se nombra con una lista de estados proporcionados. El siguiente es un ejemplo de una línea de vida del estado.

miércoles, 12 de mayo de 2010

DOCUMENTACION DEL DISEÑO DE PRUEBAS

Plan de Pruebas
Señalar:
• El enfoque
• Los recursos
• El esquema de actividades de prueba
• Los elementos a probar
• Las características
• Las actividades de prueba
• El personal responsable
• Los riesgos asociados



Estructura Fijada en el estándar
• Identificador único del documento (para la gestión de
configuración).
• Introducción y resumen de elementos y características a probar.
• Elementos software que se van a probar (p. ej., programas o módulos).
• Características que se van a probar.
• Características que no se prueban.
• Enfoque general de la prueba (actividades, técnicas, herramientas, etc.).
• Criterios de paso/fallo para cada elemento.
• Criterios de suspensión y requisitos de reanudación.
• Documentos a entregar (como mínimo, los descritos en el estándar).
• Actividades de preparación y ejecución de pruebas.
• Necesidades de entorno.
• Responsabilidades en la organización y realización de las pruebas.
• Necesidades de personal y de formación.
• Esquema de tiempos (con tiempos estimados, hitos, etc.).
• Riesgos asumidos por el plan y planes de contingencias para cada riesgo.
• Aprobaciones y firmas con nombre y puesto desempeñado

Especificación del Diseño de Pruebas
􀁺 Objetivo: Especificar los refinamientos
necesarios sobre el enfoque general reflejado
en el plan e identificar las características que
se deben probar con este diseño de pruebas.
􀁺 Estructura Fijada por el estándar:
• Identificador (único) para la especificación. Proporcionar también una referencia del plan asociado (si existe).
• Características a probar de los elementos software (y
combinaciones de características).
• Detalles sobre el plan de pruebas del que surge este diseño, incluyendo las técnicas de prueba específica y los métodos de análisis de resultados.
• Identificación de cada prueba:
• Identificador.
• Casos que se van a utilizar.
• Procedimientos que se van a seguir.
• Criterios de paso/fallo de la prueba (criterios para determinar si una característica o combinación de características ha pasado con éxito la prueba o no).

Ejecución de las pruebas



Documentación de la Ejecución de las pruebas



Historico de Pruebas
Documenta todos los hechos relevantes ocurridos durante la ejecución de las pruebas.
1.-Informe de Incidente:
2.-Documenta cada incidente (p. ej., una interrupción en las pruebas debido a un corte de electricidad, bloqueo del teclado, etc.)
3.-Ocurrido en la prueba y que requiera una posterior investigación.
4.-Informe resumen:
Resume los resultados de las actividades de prueba (las reseñadas en el propio informe) y aporta una evaluación del software, basada en dichos resultados.

RELACION ENTRE DEFECTO, FALLA Y ERROR

Error (error):

Es una equivocación cometida por un desarrollador. Algunos ejemplos de errores son: un error de tipeo, una malinterpretación de un requerimiento o de la funcionalidad de un método. El estándar 829 de la IEEE coincide con la definición de diccionario de error como “una idea falsa o equivocada”. Por ende un programa no puede tener o estar en un error, ya que los programas no tienen ideas; las ideas las tienen la gente.

Defecto (fault, defect):

Un error puede conducir a uno o más defectos. Un defecto se encuentra en un artefacto y puede definirse como una diferencia entre la versión correcta del artefacto y una versión incorrecta. De nuevo coincide con la definición de diccionario, “imperfección”. Por ejemplo, un defecto es haber utilizado el operador “<” en vez de “<=“.

Falla (failure):

En terminología IEEE, una falla es la discrepancia visible que se produce al ejecutar un programa con un defecto, respecto a la ejecución del programa correcto.

Es decir,una falla es el síntoma de un defecto.


DEFINICIONES DE PRUEBAS DE SOFTWARE

Pruebas (test): «una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto»

Caso de prueba (test case): «un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular»

Defecto (defect, fault, «bug»): «un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa»Falla: Puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación.

Fallo (failure): «La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados»

Error (error): tiene varias acepciones: La diferencia entre un valor calculado, observado o medio y el valor verdadero, especificado o teóricamente correcto.

Verificación: El proceso de evaluación de un sistema (o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase.

Validación: El proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario.

martes, 11 de mayo de 2010

PRUEBAS ESTRUCTURALES, FUNCIONALES Y ALEATORIAS

LA COMPLEJIDAD DE MACCABE V(G) (COMPLEJIDAD CICLOMATICA)

*La métrica de Mc Cabe ha sido muy popular en el diseño de pruebas
*Es un indicador del numero de caminos independientes que existen en un grafo.
La complejidad de McCabe se puede calcular de cualquiera de estas 3 formas:

1. V (G) = a - n + 2, siendo a el número de arcos o aristas del grafo y n el número de nodos.
2. V (G) = r, siendo r el número de regiones cerradas del grafo.
3. V(G) = c + 1, siendo c el número de nodos de condición.

El criterio de prueba de McCabe es: Elegir tantos casos de prueba como caminos independientes (calculados como V(G)):
*La experiencia en este campo asegura que:
*V(G) marca el límite mínimo de casos de prueba para un programa
*Cuando V(G) > 10 la probabilidad de defectos en el módulo o programa crece mucho quizás sea interesante dividir el módulo.