Unidad 2.2:

1. Unidad 2.2: UML (Lenguaje de Modelamiento Unificado)

2. State Diagrams State Diagrams Diagramas de Clases Use Case Diagrams Use Case Diagrams State Diagrams Diagramas de Casos de Uso State Diagrams Use Case Diagrams Diagramas de Objetos Use Case Diagrams Diagramas de Secuencia Scenario Diagrams State Diagrams Scenario Diagrams State Diagrams Diagramas de Componentes Diagramas de Colaboración Modelo Component Diagrams Scenario Diagrams Component Diagrams Scenario Diagrams Diagramas de Distribución Diagramas de Estados Diagramas de Actividad Diagramas de UML “Un modelo es una descripción completa de un sistema desde una perspectiva concreta”

3. ... Diagramas de UML • Diagrama de Casos de Uso • Diagrama de Clase (incluyendo Diagrama de Objetos) • Diagramas de Comportamiento • Diagrama de Estados • Diagrama de Actividad • Diagramas de Interacción • Diagrama de Secuencia • Diagrama de Colaboración • Diagramas de implementación • Diagrama de Componentes • Diagrama de Despliegue

4. … Casos de Uso • Existen dos elementos primordiales cuando se realiza la modelación de C.U. • Diagramas de casos de uso: ilustra gráficamente el sistema como una colección de casos, actores y sus relaciones. • Comunica a un alto nivel el alcance de los eventos de negocio que el sistema debe procesar. • El diagrama de casos de uso es muy sencillo, pero con éste comienza un importante proceso llamado descomposición funcional.

5. … Casos de Uso • Ejemplo:

6. … Casos de Uso • Un C.U representa un objetivo individual del sistema y describe una secuencia de actividades y de interacciones del usuario para alcanzar el objetivo. • Un C.U por sí solo no se considera como requerimiento funcional, pero la historia (el escenario) que relata el C.U consiste en uno o más requerimientos. • Inicialmente los CU se definen durante la etapa de los requerimientos del ciclo de vida y se refinarán adicionalmente a lo largo de éste

7. … Casos de Uso: Actores • Los C.U se inician o son generados por los usuarios externos llamados Actores. • Un actor inicia la actividad del sistema, un caso de uso, con el propósito de terminar alguna tarea de negocios que produzca algo con valor apreciable. • Un actor representa un papel desempeñado por un usuario que interactúa con el sistema y no significa que retrate a una persona o puesto de trabajo. De hecho un actor no tiene porqué ser humano, puede ser una organización, otro sistema de información o un dispositivo externo tal como un sensor de calor.

8. … Casos de Uso: Actores • Existen principalmente 4 tipos de actores: • Actor primario de negocios: El interesado que se beneficia principalmente de la ejecución de un CU al recibir algo d valor medible u observable. Este actor puede o no iniciar un evento de negocios. • Ej: En el evento de negocio de un empleado que recibe el cheque como pago (algo con valor medible) del sistema de nómina cada viernes, el empleado no inicia el evento pero es el receptor primario de algo de valor.

9. … Casos de Uso: Actores • Actor primario del sistema: El involucrado que tiene una interfaz directa con el sistema para iniciar u ocasionar el evento de negocios o de sistema. • Esto actores pueden interactuar con los actores primarios de negocios con el propósito de usar el sistema real. Ellos facilitan el evento a través del uso directo del sistema para beneficio del actor primario de negocios. • Ej :Un dependiente de una tienda de abarrotes que selecciona los artículos para el cliente que compra abarrotes ó una operadora que proporciona información del directorio a un cliente.

10. … Casos de Uso : Actores • Actor externo servidor: El involucrado que responde a una solicitud desde el caso de uso. • Actor externo receptor: El involucrado que no es el actor primario pero que recibe algo de valor medible u observable (salida) proveniente del caso de uso. • Ej: Un almacén recibe una orden de embalaje para preparar un flete después de que un cliente ha colocado una orden.

11. … Casos de Uso : Actores • En muchos sistemas de información hay eventos de negocios ocasionados por el calendario o la hora del reloj. • Ej: El sistema de facturación de una compañía de tarjetas de crédito genera automáticamente sus estados de cuenta en el quinto día de cada mes. (fecha de facturación). • Un banco concilia sus transacciones con cheques todos los días a las 5 pm. • Estos eventos son ejemplo de eventos temporales, ¿Quién sería el actor?, el actor de un evento temporal es el tiempo.

12. … Casos de Uso: Relaciones • Una relación: se ilustra como una línea entre dos símbolos en el diagrama de casos de uso. El significado de las relaciones puede diferir dependiendo de cómo se dibujen las líneas y que tipo de símbolos conectan

13. … Casos de Uso: Relaciones • Asociaciones: Existe una relación entre un actor y un CU siempre que el caso describa una interacción entre éstos. • Se representa con una línea continua que conecta al actor y al CU. • Una Asociación que contiene una cabeza de flecha en el extremo que toca al CU, indica que el caso fue iniciado por el actor. • Las asociaciones sin cabeza de flecha indican una interacción entre el CU y el actor externo servidor o receptor.

14. Casos de Uso: Relaciones • UML define cuatro tipos de relación en los Diagramas de Casos de Uso: • Comunicación: Actor Caso de Uso

15. … Ejemplos En el paquete tipos de venta:

16. … Casos de Uso: Relaciones • Extensión: Un CU puede contener una funcionalidad compleja que consiste de varios pasos que hacen difícil entender la lógica del caso. • Con objeto de facilitar el CU y hacer que se entienda más fácilmente, podemos extraer los pasos más complejos para formar su propio caso. • El caso resultante de llama caso de extensión, ya que extiende la funcionalidad del VU original. • Un CU puede tener muchas relaciones de extensión, pero un CU de extensión puede ser invocado solamente por el CU que se está extendiendo • Se representa mediante una línea con cabeza de flecha (continua o segmentada) que comienza con el CU de extensión y que apunta al CU que se está extendiendo.

17. … Casos de Uso: Relaciones • Extensión: el Caso de Uso origen extiende el comportamiento del Caso de Uso destino <<extend>> Caso de uso destino Caso de uso origen

18. <<extend>> … Ejemplos

19. … Casos de Uso: Relaciones • Uses (o Inclusión): Comúnmente se puede descubrir dos o más CU que ejecuten pasos de funcionalidad idéntica. Lo mejor es extraer estos pasos comunes para formar un caso de uso separado que sea propio llamado, CU resumen. • Un CU resumen representa una forma de “reuso” y es una herramienta excelente para reducir la redundancia entre los CU. • Un CU resumen está disponible como referencia (o uso) para cualquier otro CU que requiera su funcionalidad. • Se representa mediante una línea con cabeza de flecha (continua o segmentada) que comienza en el CU Oficial y apunta al CU que se esté usando.

20. … Casos de Uso: Relaciones • Inclusión: una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino • En UML 1.3 se estereotipa como <<include>> lo que antes llevaba el estereotipo <<uses>> <<include>> Caso de uso destino Caso de uso origen

21. … Ejemplos <<include>> <<include>>

22. … Casos de Uso: Relaciones • Dependencia: Como administrador de proyecto o desarrollador líder, es de mucha ayuda saber cuáles CU tienen una dependencia sobre otros CU, con objeto de determinar la secuencia en que es necesario desarrollar los CU. • Ej Bancario: Hacer un retiro no puede ejecutarse hasta que haya ocurrido el caso de uso Abrir una Cta Bancaria. Debido a esto el equipo de desarrollo probablemente escogerá desarrollar el CU Abrir una cuenta bancaria primero y en segundo lugar haga un depósito y en tercer lugar haga un retiro.

23. … Casos de Uso: Relaciones • Un diagrama de CU que modele las dependencias de CU del sistema mediante el uso de relaciones de dependencia proporciona un modelo que es una herramienta excelente para propósitos de planeación y de programación. • Esta relación se representa con una línea con cabeza de flecha que comienza en un CU y que apunta al CU del cual depende. <<depende de>>

24. … Casos de Uso: Relaciones • Herencia: Cuando dos o más actores comparten un comportamiento común (En otras palabras, pueden iniciar el mismo caso de uso), lo mejor es extrapolar este comportamiento común y asignarlo a un nuevo actor resumen con objeto de reducir la comunicación redundante en el sistema.

25. … Casos de Uso: Relaciones • Herencia: el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía Caso de uso destino Caso de uso origen

26. … Casos de Uso: Relaciones • Ejemplo: <<extend>> Transferencia por Internet <<include>> Transferencia

27. … Casos de Uso El segundo elemento, narración del caso de uso, describe los detalles de cada evento.

29. … Casos de Uso • Proceso de la modelación de casos de Usos para los requerimientos: • Paso 1: Identificar a los actores del negocio • Paso 2: Identificar los casos de uso para los requerimientos de negocios. • Paso 3: Construir el diagrama del modelo de casos de uso • Paso 4: Narraciones de los CU para los requerimientos de documentos para los negocios

31. Diagrama de Secuencia

32. Diagrama de Secuencia • Antes del diseño (cómo funcionará el software) se debe investigar y definir su comportamiento como “caja negra” • El comportamiento del sistema es una descripción de lo que hace, • …sin explicar la manera en que lo hace • Parte de esa descripción es un diagrama de secuencia del sistema

33. Los diagramas de secuencia • Es un artefacto creado de manera rápida y fácil que muestra los eventos de entrada y salida relacionados con el sistema que se está estudiando. • UML incluye la notación de los diagramas de secuencia para representar los eventos que parten de los actores externos hacia el sistema.

34. Diagrama de secuencia • El comportamiento del sistema es una descripción de qué hace el sistema, sin explicar cómo lo hace. • Def: Es un dibujo que muestra para un escenario específico de un caso de uso, los eventos que generan los actores externos, el orden y los eventos entre los sistemas. Todos los sistemas se tratan como cajas negras. • Los diagramas destacan los eventos que cruzan los límites del sistema desde los actores a los sistemas.

35. Diagrama de secuencia • Asignación de nombres a los eventos: • Para una mayor claridad deben comenzar con un verbo en infinitivo.

36. Relación caso de uso/DSS • Caso de uso (CU) describe cómo actores externos interactúan con el sistema a construir • Durante la interacción, el actor genera eventos del sistema para un sistema, • usualmente esto requiere que alguna operación del sistema maneje el evento • DSS hace concretos y explícitos los eventos que son implícitos en el CU • Veamos un DSS del curso normal de “Modificar Capital”

37. RunningExample – DSS Modificar Capital • Curso normal de los eventos

38. Eventos y operaciones • Eventodel sistema • hecho externo de entrada que un actor produce en un sistema. • Operacióndel sistema • acción que el sistema ejecuta en respuesta a un evento del sistema. • ej., un contribuyente genera un evento “modificarCapital”, el cual causa la ejecución de la operación “modificarCapital”. • El nombre del evento y de la operación pueden ser (y generalmente son) idénticos. • La diferencia es que el evento “X” es el estímulo y la operación “X” es la repuesta. • Lo mismo sucede con los mensajes y los métodos en Orientación a Objetos y UML.

39. DSS • Diagrama que muestra • los eventos generados por actores externos, • … su orden • …y los eventos inter-sistemas • …para un escenario particular de un CU • Todos los sistemas son tratados como cajas negras • Foco en los eventos que cruzan la frontera entre actores y sistemas

40. DSS • Los casos de uso del sistema (escenarios y eventos) son input para su creación • El tiempo se describe (avanza) hacia abajo • El orden de los eventos debe seguir el mismo orden del escenario que representan • Los eventos del sistema pueden incluir parámetros • Usa diagrama de secuencia de UML • Serán input para • contratos de operación • y diseño de objetos

41. DSS de “Modificar Capital” Sistema como caja negra Actor externo Mensaje con parámetros Valor(es) de retorno asociado con el mensaje previo tiempo

42. Elaborando un DSS • Para elaborar un DSS para un escenario, y: • Trace una línea que represente el sistema como una caja negra • Identifique los actores que operan directamente sobre el sistema • Trace una línea para cada uno de ellos. • A partir del escenario identifique los eventos (“externos”) del sistema que son generados por los actores • Muéstrelos gráficamente en el diagrama. • A la izquierda del diagrama puede incluir o no el texto del caso de uso.

43. Modificar Capital

44. Elaborando un DSS • Consideramos ahora el caso de uso “Modificar Capital” a fin de identificar los eventos del sistema • Primero debemos determinar los actoresque interactúan directamente con el sistema de software • Usuarios • OJO! Sólo quien actúa directamente con el sistema • Ej. En la venta de un producto: el cliente interactúa con el cajero, pero no directamente con el sistema de ventas; => cajero es generador de eventos, cliente no • Ej. Contribuyente/Representante Electrónico • Otros sistemas • Colaboraciones con sistemas externos (de pago, etc) • Ej. No hay (aún :P)

45. Elaborando un DSS • Los eventos de un sistema (y sus operaciones asociadas) deben expresarse en el nivel de propósito • …y no en el nivel del medio de entrada o de elementos de la interfaz • Ej. “modificarCapital” es preferible a “ApretarBotonAceptar” porque capta mejor el propósito de la operación • Mantiene un carácter abstracto y no se pronuncia sobre qué interfaz sirve para capturar el evento del sistema (decisiones de diseño) • Es más claro si el nombre de un evento del sistema comienza con un verbo • ej. agregar, introducir, terminar, efectuar • esto recalca que los eventos están orientados a comandos

46. DSS • Guideline: • Haz un DSS para el escenario principal de cada caso de uso, y para escenarios alternativos frecuentes o complejos • ¿Por qué son importantes? • Investigan y definen el comportamiento del sistema como una caja negra • Describen qué es lo que sistema hace, sin explicar cómo lo hace • Junto con CU y contratos de operación del sistema

47. RunningExample – DSS Modificar Capital • Curso normal de los eventos

48. Diagramas de Secuencia

49. … Diagramas de Secuencia

50. … Diagramas de Secuencia • Ejemplo Las bandas rectangulares representan los periodos de actividad de los objetos