Diagramas UML Esenciales

Diagramas de Casos de Uso

Un caso de uso especifica un conjunto de secuencias de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un actor en particular.

Un actor representa un conjunto coherente de roles que juegan los usuarios de los casos de uso al interactuar con el sistema.

Un caso de uso describe un conjunto de secuencias de interacciones entre actores y el sistema, llamadas escenarios.

Relaciones en Diagramas de Casos de Uso

• Asociación: Entre un actor y un caso de uso (bidireccional).
• Generalización: Un caso de uso hereda el comportamiento y significado de otro.
• Inclusión (<<include>>): El caso de uso fuente incluye el comportamiento del caso de uso al que apunta.
• Extensión (<<extend>>): El caso de uso fuente amplía el comportamiento del caso de uso al que apunta.

Diagramas de Secuencia

Representan una interacción ordenada según la secuencia temporal de eventos. El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes en la interacción, sin un orden prefijado.

Elementos Clave en Diagramas de Secuencia

• Línea de Vida: Representa la evolución de un objeto o actor a lo largo de cierto tiempo.
• Activación: Periodo durante el cual un objeto realiza una acción.
• Mensaje Síncrono: El objeto que envía el mensaje espera el retorno de una respuesta antes de reanudar sus operaciones.
• Mensaje Asíncrono: Muestra simplemente el flujo de control, del que no se espera ninguna respuesta inmediata.
• Mensaje Simple: Describe cómo el control pasa de un objeto a otro. Se utiliza cuando los detalles de la comunicación no se consideran relevantes o para señalar el mensaje de retorno a un mensaje síncrono.

Diagramas de Colaboración

Muestran cómo las instancias específicas de las clases trabajan juntas para alcanzar un objetivo común. A diferencia de los diagramas de secuencia, se enfocan en las asociaciones y el intercambio de mensajes entre objetos, sin tomar en cuenta la dimensión temporal de dichas relaciones.

Componentes de los Diagramas de Colaboración

• Objeto: Se representa con un rectángulo que contiene el nombre y la clase del objeto (ej. objeto: Clase).
• Enlace: Línea recta que une dos objetos que interactúan.
• Colaboración: Una descripción de los objetos afectados (contexto) y la secuencia de los mensajes que intercambian (interacción).

Planificación y Estrategias de Pruebas de Software

Conceptos Fundamentales en Pruebas de Software

• Un defecto en el software es una definición de datos incorrecta o un paso de procesamiento erróneo en el programa.
• Un fallo en el software es la incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas según los requisitos de rendimiento especificados.
• Un error en el software es la diferencia entre un valor calculado, observado o medido y el valor verdadero, especificado o teóricamente correcto.
• Pruebas (testing): Una actividad en la cual un sistema o uno de sus componentes se ejecuta bajo circunstancias previamente especificadas; los resultados se observan, registran y se evalúa algún aspecto.
• Caso de prueba (test case): Un conjunto de entradas, condiciones de ejecución y resultados esperados, desarrollados para un objetivo particular.

Objetivos de las Pruebas de Software

Las pruebas deben centrarse en dos objetivos principales:

• Verificar que el software no realiza acciones no deseadas.
• Verificar que el software realiza las funciones esperadas.

Tipos de Pruebas de Software

Se establecen una serie de condiciones con el objetivo de determinar si la aplicación funciona correctamente. Tienen distintos enfoques:

Enfoque Funcional o de Caja Negra

Se centra en las funciones, entradas y salidas del sistema, sin considerar su estructura interna.

Técnicas de Caja Negra

• Partición por Equivalencia:

  Consiste en dividir los campos de entrada, según el tipo de dato y las restricciones, en clases de datos que posteriormente se convertirán en casos de prueba.

  • Una clase de equivalencia representa un conjunto de estados válidos o inválidos para condiciones de entrada.
  • El dominio de los valores de entrada se dividirá en un número finito de clases de equivalencia.

  Pasos para la Partición por Equivalencia:

  1. Se identifican las clases de equivalencia, tomando cada condición de entrada y dividiéndola en dos o más grupos.
  2. Se definen los casos de prueba: se asigna un número único a cada clase de equivalencia, se escribe un nuevo caso de prueba que cubra la clase de equivalencia válida y se escribe un caso de prueba que cubra una, y solamente una, de las clases de equivalencia inválidas descubiertas.
• Análisis de Valores Límite:

  Esta técnica lleva a la elección de casos de prueba que ejercitan los valores límite (fronteras) de las clases de equivalencia. Complementa a la partición por equivalencia.

Enfoque Estructural o de Caja Blanca

Se centra en la estructura interna del programa, su código y lógica.

Técnicas de Caja Blanca

• Pruebas de Caja Blanca:

  Dado que comprobar todas las combinaciones posibles de casos en un programa es inviable, se trabaja con caminos, decisiones o condiciones.

• Prueba del Camino Básico:

  Se basa en que el diseño de cualquier procedimiento puede representarse mediante un grafo. La complejidad ciclomática es el número de caminos independientes posibles para ejecutar ese conjunto de sentencias.

  Pasos para la Prueba del Camino Básico:

  1. Definir bloques para cada sentencia simple.
  2. Separar las condiciones y numerarlas.
  3. Obtener los caminos independientes para recorrer el grafo.
  4. Preparar los casos de prueba que forzarán la ejecución de cada camino.

Etiquetas: Diagramas de Casos de Uso, Diagramas de Colaboración, Diagramas de Secuencia, pruebas de software, UML