Facultad de Informática Departamento de Lenguajes y Sistemas Informáticos e Ingeniería de Software Universidad Pontificia de Salamanca en Madrid 1 Curso.

Presentación del tema: "Facultad de Informática Departamento de Lenguajes y Sistemas Informáticos e Ingeniería de Software Universidad Pontificia de Salamanca en Madrid 1 Curso."— Transcripción de la presentación:

1 Facultad de Informática Departamento de Lenguajes y Sistemas Informáticos e Ingeniería de Software Universidad Pontificia de Salamanca en Madrid 1 Curso de UML Modelado de Comportamiento Básico

2 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 2 Resumen  Diagramas de Interacción  Diagramas de Casos de uso  Diagramas de actividad

3 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 3 Interacciones

4 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 7 Ejemplo

8 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 11 Diagrama de secuencia

12 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 12 Diagrama de secuencia (II)

13 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 13 Diagrama de colaboración

14 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 17 Casos de uso

18 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 18 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. nombreActor >>>

19 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 19 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 Caso de uso

20 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 20 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 > 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 > >

21 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 25 Diagramas de actividad

26 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 27 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(); Estado inicial Estado final

28 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 32 Ejemplo

33 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 35 Ejemplo

36 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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 ©Alberto Caramazana, Héctor Castán, Luis JoyanesOctubre 2000 Universidad Pontificia de Salamanca en Madrid Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 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.