Modelado de Comportamiento Básico

1. Curso de UML Modelado de Comportamiento Básico

2. Resumen • Diagramas de Interacción • Diagramas de Casos de uso • Diagramas de actividad

3. Interacciones

4. Introducción al modelado de interacciones • Permiten modelar el comportamiento dinámico de las colaboraciones. • Una interacción es un comportamiento que comprende un grupo de mensajes que se intercambian entre un conjunto de objetos dentro de un contexto y con una finalidad. • En el contexto de la interacción podemos encontrar clases, interfaces, componentes, nodos y casos de uso.

5. Links • Un link es una conexión semántica entre objetos. • Podemos decir que un link es una instancia de una asociación donde se pueden aplicar todos los adornos de la asociación salvo por la multiplicidad. • Para matizar UML define 5 estereotipos: • association: el objeto es visible por la asociación. • self: el objeto es visible por que es el invocador de la operación. • global: el objeto es visible por que su alcance contiene al actual. • local: el objeto es visible por ser local al emisor. • parameter: el objeto es visible por ser un parámetro en la operación actual del objeto origen.

6. Mensajes • Un mensaje es la especificación de una comunicación entre objetos. • Para matizar UML define 5 estereotipos: • call: invoca una operación en sobre un objeto. • return: devuelve el valor al emisor. • send: envía una señal a un objeto. • create: Crea un objeto. • destroy: Elimina un objeto.

7. Ejemplo

8. Números de secuencia • Números de secuencia • Indica la ordenación temporal de los mensajes. • Para representar anidamiento se utiliza la notación decimal de Dewey. • Mensajes complejos • iteración: • *[i:=1..n] si queremos especificar un rango (antes del núm. secuencia) • * cuando se quiere especificar iteración no definida • condición: • se precede el número de secuencia con una expresión [x>0] • los distintos caminos tienen diferentes números de secuencia. • UML no impone la notación de corchetes: se puede usar pseudocódigo, etc.

9. Creación, modificación y destrucción de links • Para especificar la vida de los link UML permite estas restricciones: • new: La instancia o link es creado durante la ejecución de esa interacción. • destroyed: La instancia o link es destruido después de la ejecución de esa interacción. • transient: La instancia o link es creado durante la ejecución de esa interacción y destruido después.

10. Representación • En el modelado de una interacción se visualizan objetos y mensajes de dos formas: • Enfatizando la ordenación de los mensajes en el tiempo por medio de diagramas de secuencia. • Enfatizando la organización estructural de los objetos por medio de diagramas de colaboración.

11. Diagrama de secuencia

12. Diagrama de secuencia (II)

13. Diagrama de colaboración

14. Modelado de un flujo de control • Definir el contexto de la interacción. Todo el sistema, una clase o una operación. • Establecer los objetos que participan e identificar sus propiedades iniciales, incluyendo sus atributos, estados y roles. • Si queremos enfatizar la organización estructural identificar los links que los conectan. • Especificar los mensajes entre los objetos. • Adornar cada elemento si se necesita un mayor nivel de detalle.

15. Modelado de flujos de control ordenados en el tiempo • Definir el contexto de la interacción. Todo el sistema, subsistema, una clase, una operación, un escenario de un caso de uso o colaboración. • Establecer los objetos que participan en la interacción y colocarlos en un diagrama de secuencia de izquierda a derecha, situando los mas importantes a la izquierda. • Colocar la línea de vida de cada objeto. • Situar los mensajes, comenzando por el mensaje que inicia la interacción, de arriba a abajo. • Si se necesita adornar la línea de vida de los objetos con su “focus of control”. • Si se necesita adornar cada mensaje con restricciones o propiedades. • Si se necesita incluir precondiciones y postcondiciones para cada mensaje.

16. Modelado de flujos de control por organización • Definir el contexto de la interacción. Todo el sistema, subsistema, una clase, una operación, un escenario de un caso de uso o colaboración. • Establecer los objetos que participan en la interacción y colocarlos en un diagrama de colaboración como vértices del gráfico, situando los mas importantes en el centro del diagrama. • Establecer las propiedades iniciales de cada objeto. • Establecer los links entre los objetos. Primero las asociaciones por ser las mas importantes. • Situar los mensajes, comenzando por el mensaje que inicia la interacción con un numero de secuencia adecuado. • Si se necesita adornar cada mensaje con restricciones o propiedades. • Si se necesita incluir precondiciones y postcondiciones para cada mensaje.

17. Casos de uso

18. <<<<actor>>>> nombreActor nombreActor Términos y conceptos • Actor • Def. Representa un conjunto coherente de roles que un usuario desempeña cuando interactua con los casos de uso. • Se representa mediante un “monigote/stick man”. • UML no distingue entre primarios y secundarios. • Sólo se pueden conectar a los casos de uso mediante asociaciones.

19. Caso de uso Términos y conceptos (II) • Caso de uso • Def. Descripción de un conjunto de secuencias que representan la interacción de elementos externos con el sistema. • Indican “qué” hace y no “como” lo hace. • Se pueden aplicar al sistema completo o a partes. • Se representa mediante una elipse • Se emplean para visualizar el comportamiento de un sistema, subsistema o clase. • El sistema se representa mediante un rectángulo etiquetado con el nombre • Usos comunes: • modelado de contexto de un sistema • modelado de los requisitos de un sistema

20. <<include>> <<extend>> Relaciones • Relaciones: • Asociaciones caso de uso - actor: línea continua. • Generalización: un caso de uso hijo hereda el comportamiento de otro caso de uso base o padre. Flecha continua con punta hueca. También es aplicable a los actores. • Inclusión: un caso de uso base incorpora explícitamente otro caso de uso en un lugar indicado en el caso de uso base. Comportamiento obligado. Dependencia <<include>> • Extensión: un caso de uso base incorpora implícitamente otro caso de uso en un lugar indicado en el caso de uso base. Comportamiento opcional. Dependencia <<extend>>

21. Especificación de casos de uso • Casos de uso y flujo de eventos • Los casos de uso se pueden especificar describiendolos en texto libre, incluyendo donde empieza y acaba, cuando interactua con los actores y que objetos intercambia. • Casos de uso y escenarios • Para especificar el flujo de los casos de uso usaremos diagramas de secuencias. • Casos de uso y colaboraciones • Para enlazar los casos de uso con el análisis usaremos colaboraciones.

22. Otras características • Podemos organizar los casos de uso agrupandolos en paquetes, especificando relaciones de generalización, “include” y “extends”. • Los casos de uso son clasificadores y como tales pueden tener atributos y operaciones que podemos reflejar.

23. Técnicas de Modelado de un elemento • Identificar los actores que interactuan con el elemento. • Organizar actores identificando roles generales y específicos. • Considerar los mecanismos de interacion primarios de los actores con el elemento. • Considerar los mecanismos de interacion excepcionales de los actores con el elemento. • Organizar estos comportamientos en casos de uso aplicando las relaciones “include” y “extends”.

24. Técnicas de modelado de requisitos de sistema • Establecer el contexto del sistema definiendo los actores que le rodean. • Para cada actor, considerar el comportamiento que necesita del sistema. • Nombrar estos comportamientos como casos de uso. • Explosionar los casos de uso en nuevos casos de uso que sean usados por otros. • Modelar las relaciones de los actores y casos de uso en un diagrama de casos de uso. • Adornar los casos de uso con notas que incluyan requisitos no funcionales, algunos podrán aplicarse a todo el sistema.

25. Diagramas de actividad

26. Términos y conceptos • Diagrama de actividades: representa un grafo de actividad. • Muestra el flujo de actividades. • Actividad: ejecución no atómica, en curso en una máquina de estados, que finalmente producen acciones. • Acción: computación atómica que cambia el estado del sistema o que producen el retorno de un valor. • Acciones: llamadas a otras operaciones, envío de señales, creación y destrucción de objetos o cálculos simples. • Un diagrama de actividades contiene: • Estados de actividad y estados de acción • Transiciones • Objetos

27. Estado inicial Estado final Estados de acción • Representación: etiqueta redondeada con una expresión en su interior que indica la acción que realiza. • UML no impone el lenguaje de la expresión. • Los estados de acción no se pueden descomponer. • Su ejecución no puede interrumpirse y tarda un tiempo cero. • Ejemplos: cont:=0; send kiosko.pantallaPrincipal();

28. Estados de actividad • Representación: etiqueta redondeada con una expresión en su interior que indica la actividad en curso. • Pueden tener acciones de entrada y de salida. • UML no impone el lenguaje de la expresión. • Los estados de actividad no son atómicos, por lo que se pueden descomponer y su ejecución puede interrumpirse. • Su ejecución lleva un tiempo determinado distinto de cero.

29. Transiciones • Cambio automático de un estado a otro como consecuencia de la finalización de la actividad o acción del estado origen. • Se representan mediante una línea dirigida no etiquetada. • El flujo de control comienza en un estado inicial y termina en un estado final.

30. Bifurcación • Especifica caminos alternativos. • Se representa mediante un rombo. • Se puede representar una condición alternativa etiquetada con la palabra clave else. • Las iteraciones se pueden representar mediante un estado de acción que establezca un valor para una variable de control y una condición que evalúe la salida del bucle. • UML no impone la notación de las expresiones.

31. División y Unión • Las divisiones representan flujos concurrentes. • Las uniones son sincronizaciones de dichos flujos. • Se representan mediante una línea horizontal. • UML no impone la notación de las expresiones.

32. Ejemplo

33. Calles • Utiles cuando se modelan flujos de trabajo de procesos de organizaciones. • Dividen los estados de actividad en grupos. • Cada grupo representa la parte de la organización responsable. • Cada actividad pertenece a una calle, pero las transiciones pueden cruzarlas.

34. Flujos de objetos • Objetos implicados en el flujo de control de un diagrama de actividades. • Se conectan a la actividad o transición que los crea, destruye o modifica mediante una flecha de dependencia. • Es posible mostrar cambios en los roles, estados y atributos de los objetos. • El estado se representa entre corchetes bajo el nombre del objeto.

35. Ejemplo

36. Envío y recepción de señales • Las señales se pueden especificar en la transición y pueden ser: • Señales de envío • Señales de recepción • Las líneas que son generadas desde estos elementos son discontinuas.

37. Modelado de un workflow • Seleccionar los objetos de negocio que tengan las responsabilidades de mas alto nivel. Y crear una calle para cada uno de ellos. • Identificar las precondiciones del estado inicial y las postcondiciones del estado final. • Comenzando por el estado inicial especificar las actividades y acciones que tienen lugar e incluirlas en el diagrama. • Para acciones complicadas o grupos que aparecen mas de una vez crear estados de actividad. • Identificar las transiciones, crear bifurcaciones, uniones y divisiones donde sea necesario.

38. Modelado de una operación • Recolectar las abstracciones de la operación (parámetros, atributos, clases). • Identificar precondiciones al comienzo de la operación y postcondiciones al final de la operación. • Comenzando por el inicio de la operación especificar las actividades y acciones e incluirlas en el diagrama. • Usar bifurcaciones para especificar las condiciones e iteraciones. • Solo si esta clase es una clase activa se podrán usar uniones y divisiones.