Diagramas de Casos de Uso e Interacción

Diagramas Casos de Uso

1. Diagramas de casos de uso. Indican cómo los diferentes actores trabajan con el sistema, muestran la funcionalidad del mismo conforme a las tareas a realizar, y las dependencias de funcionalidad.

2. Tipos de relaciones. Inclusión. Para incluir un caso de uso, es necesario otro. Normalmente, se indica la dirección de inclusión. Extensión. Posible modificar el comportamiento de un usecase creando una nueva acción que modifica la anterior. Límite de un sistema. Muestra diferentes sistemas delimitando cada uno de ellos. Generalización. Crea una jerarquía de usecase en los que unos se especializan a partir de un caso padre.

3. Simbología casos de uso. Caso de uso. Representa cada una de las funcionalidades del sistema. Óvalo, verbo infinitivo. Actor. Hace referencia a las entidades que tienen relación en el usecase. Se refiere al tipo de rol de usuario en el sistema Sistema. Rectángulo. Agrupa diferentes casos de uso en un módulo. El actor se puede relacionar con ellos. Relaciones. Líneas continuas con terminaciones diferentes dependiendo del tipo de relación.

4. Formas de documentar. 2 maneras - Crear un diagrama UML con los casos de uso indicados. - Añadir un documento detallado con toda la descripción del caso de uso. Condiciones, precondiciones, postcondiciones, etc.

5. Requisitos funcionales/no funcionales Funcional: es necesario describir detalladamente los requisitos del sistema, cómo debe estar y cómo va a quedarse cuando se ejecute la funcionalidad. No funcionales: información que no añade una funcionalidad concreta, pero es requisito a la hora de ejecutar un usecase ej. tiempo de ejecución

Diagramas de Interacción

1. Diagramas de Interacción. Registra cómo se comportan los objetos en un estado de acción. Se tiene en cuenta cómo interactúan los objetos que forman el sistema.

2. Tipos de diagramas de interacción. Diagrama de secuencia: permite representar la interacción siguiendo un formato en el cual cada objeto se añade a la derecha siguiendo el flujo. Diagrama de colaboración: permiten ilustrar cómo los objetos interactúan siguiendo un formato de gráfico o red, situándolos libremente.

3. Diferencias entre diagrama secuencia y colaboración. Ambos pueden ser usados a elección del diseñador, aunque las herramientas CASE dan más importancia al diagrama de secuencia debido a su mayor potencia. Se puede decir que es más fácil entender un flujo en un diagrama de secuencia debido a sus mejores notaciones y semántica. Por otra parte, los de colaboración permiten un uso más eficiente del espacio, más esquematizado, y pudiéndose distribuir tanto vertical como horizontalmente.

4. Diagramas de secuencia y elementos. Permiten mostrar el flujo de intercambio de mensajes entre los diferentes objetos a través del tiempo. A tener en cuenta: - Estructurar correctamente la representación de las diferentes líneas (líneas de vida). - Tener en cuenta el tipo de relación o mensajes que se envían:

- Síncronos. Los objetos quedan bloqueados hasta que finaliza la llamada al método de otro objeto. Flecha con punta rellena. - Asíncronos. La ejecución y terminación son inmediatas (no así la funcionalidad). Flecha con punta abierta.

Diagramas de Actividad y Tiempo

1. Especialización de los diagramas de casos de uso que permite mostrar el flujo de funcionamiento y control en un sistema en determinados usecase (ejecución a finalización). También muestra el proceso secuencial, concurrente y paralelo, de manera dinámica.

2. Elementos diagrama de actividad. Estado inicial: comienzo de diagrama de actividad. Actividad: formada por acciones, es un comportamiento relacionado con los objetos, teniendo una secuencia lógica de ejecución. Acciones: tarea que es ejecutada por una actividad. Se representan como nodos que forman parte de la misma. - Nodos objetos: instancia con valor menor. Objetos que se pueden utilizar. Representa y retiene datos de la ejecución de una acción. - Nodos de control: Marcador para asegurar la ejecución en orden cronológico de la actividad. - Nodos ejecutables: permiten llevar a cabo una determinada acción.

4. Definición diagramas de tiempo.utiliza una onda temporal para mostrar cómo varía un elemento a lo largo del tiempo objetivo es mostrar al usuario los cambios en los estados acorde a su propia línea de vida.

5. Métodos de planificación temporal permiten organizar la planificación de un proyecto para que podamos tener el mejor resultado y aprovechar mejor los recursos disponibles. Red de tareas: usan la representación mediante una estructura de red del proyecto. Diagrama de barras: utilización de un diagrama de barras usando una escala temporal. PERT: tipo especial para controlar proyectos con un gran número de actividades. Método de Roy: parecido a PERT, pero con variantes a la hora de construir la red.

Diagrama de Estados

1. Permite modelar el comportamiento dinámico de una clase o conjunto de ellas en respuesta a un estímulo o un evento externo. No confundir con diagrama de flujo

2. Uso. Hacemos uso para responder a algún tipo de evento o procesamiento, o modelar el comportamiento dinámico del sistema y comprender cómo reaccionan los objetos o clases ante un evento externo o interno. Proviene de los Autómatas Finitos Deterministas (AFD)

3. Estado representa condiciones y circunstancias de un objeto perteneciente a una clase en un momento determinado del tiempo. Es algo volátil que no tiene por qué perdurar.transiciones permiten pasar de un estado a otro, por lo que, al ser un diagrama determinista, ante las mismas circunstancias, la transición tiene que ir al mismo estado. La transición que obliga a volver al mismo estado se denomina bucle.

4 Bifurcaciones: punto desde el que se puede transitar a estados diferentes dependiendo de las condiciones. Uniones: permiten pasar a un estado al venir de estados diferentes (convergencia). Eventos: cada suceso que ocurre en un momento determinado de tiempo

5. Pasos para la elaboración. 1. Identificar estados inicial y de finalización. 2. Identificar los diferentes estados y objetos que pueden existir en ellos, uniéndolos con los correspondientes atributos. 3. Etiquetar los eventos que puedan servir para lanzar la transición.

Pruebas en el Desarrollo de SW

1. Planificación de pruebas. Conjunto de pruebas necesarias para comprobar que se cumple una funcionalidad acorde a unas condiciones y una eficiencia determinadas. La planificación previa es necesaria ya que es tiempo a invertir en el desarrollo.

2. Calidad del producto depende de garantizar las funcionalidades que requiere el cliente conforme a la etapa de análisis y diseño, y va ligada al tiempo, tanto de ejecución de la prueba como comprobar que el software satisface la dicha prueba.

3. Tipos de pruebas funcionales. Unitarias: comprueba el correcto funcionamiento de una cantidad de código. Integración: se llevan a cabo tras las unitarias. Se comprueba que el resto de elementos se pueden integrar correctamente realizando pruebas en grupo. Componentes: comprueban que los componentes con varias funcionalidades satisfacen las necesidades y se comportan correctamente. Regresión: al solucionar un error, puede surgir otro de manera colateral. Estas pruebas se encargan de que no se vuelvan a producir errores que anteriormente se habían solucionado.

Proceso de Pruebas

1. Enfoques de pruebas.

Enfoque exploratorio: permite definir pruebas de manera personal, libre y bajo la responsabilidad del diseñador de las pruebas, por lo que no existe metodología.

Enfoque basado en cajas: los diseñadores realizarán las pruebas conforme a la información que tengan del sistema. A más información, pueden dirigirse a puntos más concretos.

2. Basados en cajas.

Caja blanca: el nivel de conocimiento de la implementación es muy alto. Se dirigen a una parte determinada del código y requieren un alto nivel de conocimiento de programación.

 Caja negra: se realizan las pruebas funcionales que se supone que el código debería realizar, por lo que no se centra en los detalles de implementación.

Caja gris: combina pruebas de caja blanca y negra. Su objetivo es encontrar los errores debido a la existencia de una mala estructura o un uso incorrecto de las aplicaciones.