Lenguaje de Modelamiento Unificado

923 views
747 views

Published on

básico pero muy completo a la vez :)

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
923
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
54
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Lenguaje de Modelamiento Unificado

  1. 1. Unidad 2.2: UML (Lenguaje deModelamiento Unificado)
  2. 2. Diagramas de UML State State Use Case Diagrams de Diagramas Use Case Diagrams State Use Case Diagrams de Diagramas Clases State Use Case Diagrams Diagrams de Diagramas Diagrams de Diagramas Casos de Uso Diagrams Diagrams Objetos Secuencia Scenario State Scenario State Diagrams de Diagramas Diagrams de Diagramas Diagrams Diagrams Colaboración Modelo Componentes Scenario Component Scenario Component Diagramas de Diagrams Diagrams de Diagramas Diagrams Diagrams Distribución Estados Diagramas de Actividad“Un modelo es una descripción completa de un sistema desde una perspectiva concreta”
  3. 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. 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. 5. … Casos de Uso Ejemplo: Sistema Caso de uso X Actor A Actor B Caso de uso Y
  6. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. … EjemplosEn el paquete tipos de venta: Venta Normal Venta en Rebajas Cliente Vendedor Venta en Oferta
  16. 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. 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. 18. … Ejemplos Realizar préstamo Socio Encargado tarjeta caducada <<extend>> <<extends>> Solicitar nueva tarjeta
  19. 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. 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 <<include>> Caso de uso destino Caso de uso origen En UML 1.3 se estereotipa como <<include>> lo que antes llevaba el estereotipo <<uses>>
  21. 21. … Ejemplos Reintegro cuenta corriente <<include>> <<uses>> Cliente Validar operación <<uses>> <<include>> Reintegro cuenta crédito
  22. 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. 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. 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. 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. 26. … Casos de Uso: Relaciones Ejemplo: <<extend>> <<extends>> Transferencia por Internet Giro por Internet Cliente <<includes>> <<include>> Transferencia Giro Identificación
  27. 27. … Casos de Uso El segundo elemento, narración del caso de uso, describe los detalles de cada evento.
  28. 28. RF- <id del requisito> <nombre del requisito funcional>Versión <numero de versión y fecha>Autores <autor>Fuentes <fuente de la versión actual>Objetivos asociados <nombre del objetivo>Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso { concreto cuando <evento de activación> , abstracto durante la realización de los casos de uso <lista de casos de uso>}Precondición <precondición del caso de uso>Secuencia Paso AcciónNormal 1 {El <actor> , El sistema} <acción realizada por el actor o sistema>, se realiza el caso de uso < caso de uso RF-x> 2 Si <condición>, {el <actor> , el sistema} <acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x> 3 4 5 6 nPostcondición <postcondición del caso de uso>Excepciones Paso Acción 1 Si <condición de excepción>,{el <actor> , el sistema} }<acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>, a continuación este caso de uso {continua, aborta} 2 3Rendimiento Paso Cota de tiempo 1 n segundos 2 n segundosFrecuencia esperada <nº de veces> veces / <unidad de tiempo>Importancia {sin importancia, importante, vital}Urgencia {puede esperar, hay presión, inmediatamente}Comentarios <comentarios adicionales>
  29. 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
  30. 30. Caso de Programar Procedimiento.usoActoresPropósitoTipoResumenReferenciacruzadasSección Principal. Acción de los actores. Respuesta del sistema.Flujo 1. 2.normal 3. 4.de 5..eventos. 6. 7. 8. 9. 10 11Flujos alternativos.Línea 3:Línea 7:Línea 8:
  31. 31. Diagrama de Secuencia
  32. 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. 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. 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. 35. Diagrama de secuencia Asignación de nombres a los eventos:  Para una mayor claridad deben comenzar con un verbo en infinitivo.
  36. 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” 36Sesión 1
  37. 37. RunningExample – DSSModificar CapitalCursonormal delos eventos 37 Sesión 1
  38. 38. Eventos y operaciones Evento del sistema  hecho externo de entrada que un actor produce en un sistema. Operación del 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. 38Sesión 1
  39. 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 39Sesión 1
  40. 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 40Sesión 1
  41. 41. DSS de “Modificar Capital” Actor externo Sistema como caja negra Mensaje con parámetrosValor(es) deretornoasociado con elmensaje previo tiempo 41 Sesión 1
  42. 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. 42Sesión 1
  43. 43. Modificar CapitalCurso normal de los eventosAcción del actor Respuesta del Sistema1. El contribuyente solicita modificarcapital 2. El sistema muestra capital inicial, enterado y por enterar actuales3. El contribuyente ingresa:nuevo capital inicial, nuevo capitalenterado, nuevo capital por enterar y lafecha asociadanúmero de número de repertorio,nombre de notaria, fecha de escritura4. El contribuyente confirma loscambios al capital 5. El sistema almacena cambios al capitalSesión 1 43
  44. 44. Elaborando un DSS Consideramos ahora el caso de uso “Modificar Capital” a fin de identificar los eventos del sistema  Primero debemos determinar los actores que 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) 44Sesión 1
  45. 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 comandos45Sesión 1
  46. 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 46Sesión 1
  47. 47. RunningExample – DSSModificar Capital Curso normal de los eventos 47 Sesión 1
  48. 48. Diagramas de Secuencia : Libro : Ficha socio : Ficha libro : Préstamo : Socio : Encargado Coger libro Solicitar préstamo Verificar situación socio Situación socio ok Verificar situación libro Situación libro ok Introducir préstamo Autorizar préstamo
  49. 49. … Diagramas de Secuencia A B C m1 m2 m3 m4 m5
  50. 50. … Diagramas de Secuencia Quien llama Línea telefónica Llamado Ejemplo descuelga tono marcarLas bandasrectangulares indicación de llamada timbrerepresentan los descuelgaperiodos deactividad de los diga?objetos
  51. 51. … Diagramas de Secuencia Un objeto puede enviarse a sí mismo un mensaje: a mensaje reflexivo
  52. 52. … Diagramas de Secuencia Normalmente no es necesario indicar el retorno del control: a b El retorno se considera implícito cuando el envío es síncrono
  53. 53. … Diagrama de Secuencia En el caso asíncrono el retorno, si existe, se debe representar: a : aa b : aa
  54. 54. Tipos de Control El Diagrama de Secuencia refleja de manera indirecta las opciones de control Un control centralizado tiene una forma como esta:
  55. 55. … Tipos de control Un control descentralizado tiene una forma como esta:
  56. 56. … Estructuras de control Podemos representar iteraciones en el envío de mensajes, p.e., mientras se cumpla una condición: While X Loop end Loop
  57. 57. … Estructuras de control La iteración puede expresarse también como parte del mensaje: *[condición] Mensaje
  58. 58. … Estructuras de control Las bifurcaciones condicionales pueden representarse de esta forma: If condición else end if
  59. 59. Diagrama de Colaboración
  60. 60. Mensaje Mensaje entre objetos que es representado por una expresión de mensaje y una pequeña flecha indicando la dirección del mensaje Muchos mensajes pueden navegar a través de cada link Un nº de secuencia es agregado para mostrar el orden secuencial de los mensaje en el flujo de control actual Puede haber automensajes también  this 60Sesión 1
  61. 61. Creación de instancias Cualquier mensaje puede ser usado para crear instancias La convención es llamar a estos métodos create, o usar un estereotipo de tipo <<create>> Puede incluir argumentosSesión 1 61
  62. 62. Link Camino de conexión entre dos objetos  Indica que alguna forma de navegación o visibilidad entre los objetos es posible  Es una instancia de asociación A lo largo de estos links pueden navegar los mensajes Puede haber múltiples mensajes en ambas direcciones en un mismo link (carretera de doble vía) 62Sesión 1
  63. 63. Secuencia de mensajes numerados 63Sesión 1
  64. 64. Mensajes condicionales Siguiendo al número de secuencia se incluye una cláusula condicional en paréntesis cuadrados El mensaje es enviado sólo si la condición es ciertaSesión 1 64
  65. 65. Caminos condicionalesexclusivos Expresiones de secuencia se modifican con una letra de camino condicional  La primera letra usada es a por convención 65Sesión 1
  66. 66. Loops Expresiones que describen un ciclo se identifican con un asterisco y una expresión condicional  Mientras la expresión condicional sea verdadera el ciclo continúaSesión 1 66
  67. 67. Iteración sobre una colección Describen iteraciones sobre todos los miembros de una colecciónSesión 1 67
  68. 68. Mensajes a métodos estáticos Para llamar a métodos static se usa el estereotipo <<metaclass>> para representar la clase que contiene tal método  La clase Calendar es una instancia de metaclassSesión 1 68
  69. 69. Mensajes polimórficos Mensajes a clases abstractasSesión 1 69
  70. 70. Reflexión sobre Diagramas de Interacción www.dsic.upv.es/~uml
  71. 71. Problemas típicos Problemas típicos de su uso: • En los proyectos de desarrollo, no se aprecia el valor de llevar a cabo el diseño de objetos mediante estos diagramas • Por lo anterior, se diseñan de manera vaga, e imprecisa 71Sesión 1
  72. 72. DSS UML no define nada que se llame diagrama de secuencia “del sistema”, sino que simplemente diagrama de secuencia El apellido señalado corresponde a un uso específico del diagrama de secuencia, en que precisamente el sistema es visto como caja negra. 72Sesión 1
  73. 73. Comparación Uno elige cuál quiere usar Diagrama de secuencia  Ha habido más esfuerzo en su notación y semántica  Herramientas dan mayores opciones de notación detallada  Es más fácil ver secuencia del flujo de llamados (de arriba hacia abajo)  Pero está forzado a extender hacia la derecha lo nuevos objetos 73Sesión 1
  74. 74. Comparación Diagrama de comunicación  Es mucho más eficiente en el uso de espacio  Más fácil de modificar  Más difícil ver la secuencia de llamadas  Menos opciones de notación 74Sesión 1
  75. 75. Diagrama de comunicación 1: Coger libro : Libro : Socio 2: Solicitar préstamo : Ficha s ocio 3: Verificar situación socio 8: Autorizar préstamo 4: Situación socio ok 6: Situación libro ok : Encargado : Présta 7: Introducir préstamo mo 5: Verificar situación libro : Ficha li bro 75Sesión 1
  76. 76. Running Example Desarrolle un diagrama de comunicación que represente lo mismo que este diagrama de secuencia 76Sesión 1
  77. 77. Referencias [LARMAN]  Larman, Craig.  Applying UML and Patterns. An Introduction to Object Oriented Analysis and Design.  Prentice Hall, 1998. [OO Head First]  Brett D. McLaughlin, Gary Pollice, Dave West.  Head First Object-Oriented Analysis and Design: A Brain Friendly Guide to OOA&D.  OReilly Media, Inc., 2006. 77Sesión 1
  78. 78. 1: Coger libro : Libro: Socio 2: Solicitar préstamo : Ficha s ocio 3: Verificar situación socio8: Autorizar préstamo 4: Situación socio ok6: Situación libro ok : Encargado : Présta 7: Introducir préstamo mo 5: Verificar situación libro : Ficha li bro
  79. 79. Mensajes Un mensaje desencadena una acción en el objeto destinatario Un mensaje se envía si han sido enviados los mensajes de una lista (sincronización): A.1, B.3 / 1:Mensaje B A
  80. 80. … Mensajes Un mensaje se envía iterada y secuencialmente a un conjunto de instancias: 1 *[i:=1..n] : Mensaje B A
  81. 81. … Mensajes Un mensaje se envía iterada y concurrentemente a un conjunto de instancias: 1 *| | [i:=1..n] : Mensaje B A
  82. 82. … Mensajes Un mensaje se envía de manera condicionada: [x>y] 1: Mensaje B A
  83. 83. … Mensajes Un mensaje que devuelve un resultado: 1: distancia:= mover(x,y) B A
  84. 84. Diagrama de Clases
  85. 85. TemarioEl Modelo de DominioPosibles Elementos del DominioBuscando elementos del Dominio en el ejemploUna primera representación gráfica: usando unaherramienta UMLRevisando nuestro mono: Conceptos y AtributosRevisando nuestro mono: Conceptos en Asociación2da Iteración: profundizando relacionesCorrijamos nuestro mono inicial 85Sesión 1
  86. 86. El Modelo de DominioYa conocemos una forma básica de representar yespecificar requerimientos  En torno a las Interacciones usuario-sistema  En forma de Casos de UsoSin embargo, aún no conocemos “de qué se habla”en esas interacciones representadas  No sabemos el detalle de los objetos, lugares, transacciones, etc. que intervienen en la interacción usuario-sistemaEl Modelo de Dominio nos permite identificar estoselementos y representarlos gráficamente  Identificando Conceptos o Elementos del Dominio  Identificando sus Relaciones  Identificando sus Atributos 86Sesión 1
  87. 87. El Modelo de Dominio¿Entonces ya llegamos a las Clases y los Objetos?  Nones, estamos recién descubriendo lo conceptos  Algunos de ellos eventualmente se convertirán en Clases de nuestro sistema, otros pasarán al triste olvido  Pero esa es una Decisión de Diseño, nuestra tarea ahora es entender, hacer al Análisis  Debemos identificar conceptos no guiándonos en la implementación, sino en el contexto del problema a resolver (Dominio)  Al igual que los casos de uso, el Dominio representado debe ser validado por el Cliente  Una pista: si un Cliente no puede entender algunos de los Elementos del Dominio que hemos identificado, probablemente estos No Sean Elementos del Dominio 87Sesión 1
  88. 88. Posibles Elementos del Dominio [Larman]Como primera regla, podemos fijarnos en los Sustantivosdentro de una explicación del problema  Pero este enfoque es muy mecánico; La ambigüedad del lenguaje puede llevarnos a identificar más de un elemento de dominio que representan lo mismoPodemos intentar identificando:  Objetos físicos o tangibles  Lugares  Transacciones  Roles de la Gente (Cliente, Vendedor)  Contenedores de Conceptos  Otros sistemas  Sustantivos Abstractos (“Sed”)  Organizaciones  Eventos (Emergencia)  Reglas/Políticas  Grabaciones/Logs 88Sesión 1
  89. 89. Buscando elementos del Dominio en el ejemploRevisemos nuestro ejemplo para identificar los Conceptos oElementos del Dominio  Basándonos en la lista anterior  Nombrándolos como sustantivosNombremos además las relaciones que existen entre ellos  Los nombres deben ser verbos en presente (“realiza”, “paga”, etc.)Representemos gráficamente nuestros conceptos, con “cajasy lineas” Cliente compra Auto 89Sesión 1
  90. 90. Formato de la relación
  91. 91. Una primera aproximación gráficaLa lista anterior tiene varios de los conceptos deldominio  Pero la representación gráfica es fundamental  Podemos entenderla como un mapa, que nos permite navegar entre los conceptos entendiendo sus relacionesRealizaremos una representación gráfica usandoUML  UML provee distintos diagramas para modelar Análisis y Diseño  Pero ninguno en particular llamado “Modelo de Dominio”   Usaremos el Diagrama de Clases de UML para dibujar nuestro primer diagrama de Dominio  Se puede decir que el Modelo de Dominio es un Diagrama de Clases de Análisis, donde no existen decisiones de DiseñoPodemos ocupar cualquier herramienta quesoporte UML para hacer nuestro diagrama 91Sesión 1
  92. 92. Revisando nuestro mono: Conceptos de Asociación• Cuando modelamos un dominio, descubrimos que ciertos atributos sólo se dan entre la relación entre dos conceptos• Veamos la siguiente alternativa para modelar Sociedad y Socios: Persona Sociedad es socio de• % de Participación de Capital y Utilidad sólo tienen sentido como atributos de la relación entre persona y Sociedad – No todas las personas tiene % de participación – El % de participación de cada socio no es atributo de la sociedad• Para representar estas situaciones, podemos ocupar Conceptos originados en las relaciones Socio +participacionCapital +participacionUtilidad Persona Sociedad es socio de 92 Sesión 1
  93. 93. 2da Iteración: profundizando relaciones Ahora que identificamos los conceptos, estudiemos mejor sus relaciones  Algunas de ellas parecen ambiguas  Necesitamos identificar cardinalidad en las relaciones  Es decir, cuántos de uno se relacionan con cuántos de otro  Por ejemplo: Socio tiene Sociedad +participacionCapital 1 * +participacionUtilidad • Ejemplos de Cardinalidades: – 0..1 – 1..1 – 0..* – 1..* – 1..8 (número máximo –* específico) 93 Sesión 1
  94. 94. 2da Iteración: profundizando relaciones Podemos enriquecer nuestro modelo agregando otros tipos de relaciones:  Identificando relaciones del tipo “es-un”: Super Clases y Clases  Distinguiendo distintos tipos de asociación del tipo “tiene” entre los conceptos  Asociaciones Fuertes, o Composición, en las cuales los conceptos “contenidos” existen sólo si existe el concepto “contenedor” (por ejemplo, mano-dedos)  Asociaciones Débiles, o Agregación, en las cuales los conceptos “contenidos” pueden existir si no existe el contenedor (por ejemplo grupo de contactos-contacto) 94 Sesión 1
  95. 95. Sintaxis de un modelo de dominio Tipos de relaciones  “ES-UN”  Conceptos comparten las mismas relaciones (y comportamiento)  Nos lleva a relaciones de herencia  Composición, o Asociaciones Fuertes,  Conceptos “contenidos” existen sólo si existe el concepto “contenedor” (por ejemplo, mano-dedos)  Agregación, o Asociaciones Débiles,  Conceptos “contenidos” pueden existir si no existe el contenedor (por ejemplo grupo de contactos- contacto)Sesión 1 95
  96. 96. 2da Iteración: profundizando relaciones La notación de UML permite expresar estas asociaciones: ListaContactos 1 * Contacto +lista +contactos +lista 1 *+contacto +grupos * GrupoContactos 1 +grupo Si la Lista de Contactos es eliminada, se perderán todos los contactos y los grupos Si se elimina un Grupo de Contactos, los Contactos siguen existiendo en la Lista de Contactos También es conveniente identificar los roles de cada concepto en la relación 96 Sesión 1
  97. 97. Algunas Reflexiones ¿Cómo asegurarme que he modelado todo lo que corresponde?  “Todo lo que Corresponde” = Todos los Requerimientos Identificados Podemos generar una Matriz de Trazabilidad  Filas: Casos de Uso  Columnas: Requerimientos  Marcamos en la matriz qué casos de uso resuelven qué requerimientos  Todos los Requerimientos deben estar resueltos en a lo menos un Caso de Uso (estamos haciendo todo lo solicitado)  Todos los Casos de Uso deben resolver por lo menos un Requerimiento (no estamos inventando funcionalidades) 97Sesión 1
  98. 98. Referencias [LARMAN]  Larman, Craig. Applying UML and Patterns. An Introduction to Object Oriented Analysis and Design. Prentice Hall, 1998. 98Sesión 1
  99. 99. Clases: Notación Gráfica Cada clase se representa en un rectángulo con tres compartimientos:  nombre de la clase motocicleta  atributos de la clase color cilindrada  operaciones de la clase velocidad maxima arrancar acelerar frenar
  100. 100. Asociación La asociación expresa una conexión bidireccional entre objetos Una asociación es una abstracción de la relación existente en los enlaces entre los objetos Univ. de Murcia:Universidad Un enlace Antonio:Estudiante Universidad Estudiante Una asociación
  101. 101. … Asociación  Ejemplo: maridocasado-con 0.. 1 0.. 1 trabaja-para * Compañía mujer Persona * nombre emplea-a jefe nombre 0.. 1 s. s. dirección Administra * empleado
  102. 102. Asociación Cualificada * 0..1 Aerolínea nro_billete Viajero Tablero fila 1 1 columna Cuadro AjedrezReduce la multiplicidad del rol opuesto al considerar el valordel cualificador
  103. 103. … Agregación: Caracterización Las caracterizaciones 1, 3, 4 y 5 están incluidas en el concepto más amplio de multiplicidad Objeto Agregado Multiplicidad Mínima Multiplicidad Mínima 0 nulos permitidos 0 flexible >0 nulos no permitidos >0 estricta Multiplicidad Máxima Multiplicidad Máxima 1 univaluado 1 disjunto >1 multivaluado >1 no disjunto Objeto Componente
  104. 104. Ejemplos coche Persona +Hijos 1 * 0..2 +Padre 1 motor
  105. 105. … Ejemplos 1 contiene Agregación Polígono 3.. * Punto {ordenado} * * PersonaCuenta Asociación excluyente or * Empresa 1 * está-autorizado-en * Usuario Estación Autorización Clase de asociación prioridad privilegios camb_privil
  106. 106. ... Jerarquías deGeneralización/Especialización Abstracciones más generales. vehiculo vehiculo terrestre vehiculo aéreo camion coche avion helicoptero
  107. 107. ... Jerarquías deGeneralización/Especialización La especialización es una técnica muy eficaz para la extensión y reutilización coche funcionando estropeado
  108. 108. ... Jerarquías deGeneralización/Especialización Un ejemplo de Especialización Estática: vehiculo aéreo avion helicoptero
  109. 109. ... Jerarquías deGeneralización/Especialización Un ejemplo de Especialización Dinámica: coche funcionando estropeado
  110. 110. ... Jerarquías deGeneralización/Especialización Ejemplo: varias especializaciones a partir de la misma superclase: comercial vehiculo aéreo militar avion helicoptero
  111. 111. ... Jerarquías deGeneralización/Especialización  Ejemplo: especializaciones dinámicas de la misma superclase:de menos de 1000kms cochede más de 1000 kms funcionando estropeado
  112. 112. ... Jerarquías de Generalización/Especialización Un ejemplo combinado: vehiculo comercial vehiculo terrestre vehiculo aéreo estática estática estática militar camion avion helicoptero de menos de 1000kms coche dinámica de más de 1000 kms dinámica funcionando estropeado
  113. 113. ... Jerarquías deGeneralización/Especialización El siguiente es un ejemplo de clasificación no equilibrada: vehiculo terrestre camion coche Harley Davidson
  114. 114. ... Jerarquías deGeneralización/Especialización Por regla general, es mejor limitar el número de subclases a cada nivel a costa de aumentar el número de objetos por clase y reservar los atributos para cualificar afinadamente los objetos A veces, una especialización dinámica tiene un equivalente a través de una especialización estática y una asociación ...
  115. 115. ... Jerarquías deGeneralización/Especialización Ejemplo: mariposa oruga crisálida Lepidóptero Aspecto mariposa estadio 1 oruga crisálida Lepidóptero
  116. 116. Diagrama de Estados
  117. 117. … Diagramas de Estados alta baja número_préstamos = 0 sin préstamos prestar devolver[ número_préstamos = 1 ] número_préstamos > 0 con préstamos prestar devolver[ número_préstamos > 1 ]
  118. 118. … Diagramas de Estados Ejemplo de un Diagrama de Estados para la clase persona: contratar en el paro en activo perder empleo jubilarse jubilarse jubilado
  119. 119. … Diagramas de Estados La comunicación bidireccional puede representarse mediante comunicación asíncrona. Por ejemplo en un Diagrama de Colaboración: 1: una pregunta un otro objeto objeto 2: la respuesta
  120. 120. … Diagramas de Estados Si la comunicación es síncrona el cliente debe esperar la respuesta. Con lo cual en el cliente tendríamos: a plantear pregunta espera respuesta recibir respuesta c
  121. 121. … Diagramas de Estados Las guardas permiten condicionar la transición: Evento[ condición ] a b
  122. 122. Acciones Podemos especificar la ejecución de una acción como consecuencia de la transición: Evento[ condición ] / acción a b Dicha acción también se considera instantánea
  123. 123. … Acciones  Podemos especificar el envío de un evento a otro objeto como consecuencia de la transición: aEvento( arg1, arg2 )[ condición ] / ^otro_objeto.evento(arg2) b
  124. 124. … Acciones Se puede especificar el hacer una acción como consecuencia de entrar, salir o estar en un estado: estado A entry: acción por entrar exit: acción por salir do: acción mientras en estado
  125. 125. .. Acciones Se puede especificar el hacer una acción cuando ocurre en dicho estado un evento que no conlleva salir del estado: estado A on evento_activador( arg1 )[ condición ]: acción por evento
  126. 126. Actividades Las actividades son similares a las acciones pero tienen duración y se ejecutan dentro de un estado del objeto Las actividades pueden interrumpirse en todo momento, cuando se desencadena la operación de salida del estado
  127. 127. … Actividades Cuando una actividad finaliza se produce una transición automática de salida del estado [ not condición ] a b do: actividad [ condición ] b
  128. 128. Generalización de Estados Podemos reducir la complejidad de estos diagramas usando la generalización de estados Distinguimos así entre superestado y subestados Un estado puede contener varios subestados disjuntos Los subestados heredan las variables de estado y las transiciones externas
  129. 129. Generalización de Estados Ejemplo: e1 a b e2 e2 c
  130. 130. Generalización de Estados Quedaría como: e1 a b e2 c
  131. 131. … Generalización de Estados Las transiciones de entrada deben ir hacia subestados específicos: e1 a b e2 e0 c
  132. 132. … Generalización de Estados Es preferible tener estados iniciales de entrada a un nivel de manera que desde los niveles superiores no se sepa a qué subestado se entra: e1 a b c e2 e0
  133. 133. … Generalización de Estados Ejemplo: e1 e1
  134. 134. Historial  Por defecto, los autómatas no tienen memoria  Es posible memorizar el último subestado visitado para recuperarlo en una transición entrante en el superestado que lo engloba
  135. 135. … Historial Ejemplo: a d2 in h x y out d1 H
  136. 136. … Historial También es posible la memorización para cualquiera de los subestados anidados (aparece un * junto a la H) a d2 in h x y out d1 H*
  137. 137. … Historial Ejemplo: Enjuague Lavado Secado H Cerrar Puerta Abrir Abrir Cerrar Puerta Espera
  138. 138. … Destrucción de Objeto Ejemplo: crash En vuelo despegar aterrizar Crear(matricula) En tierra
  139. 139. … Transiciones temporizadas  Ejemplo: a / Abrir ranuraSi en 30 segundos no seintroduce el dinero setermina la actividad esperar dinero anular transacciónpasando a anular la entry: Mostrar mensajetransacción. En do: Esperar 30 segundos exit: cerrar ranuracualquier caso se cierrala ranura. Depósito efectuado b
  140. 140. … Transiciones temporizadas Ejemplo v.2: a / Abrir ranura esperar dinero Temporizador (30 segundos) entry: Mostrar mensaje anular transacción exit: cerrar ranura Depósito efectuado b
  141. 141. Diagrama de Actividades
  142. 142. Ejemplos [no hay café] [no zumo] Buscar Bebida [hay café [hay zumo] Poner café en filtro Añadir agua al depósito Coger tazaPoner filtro en máquina Coger zumo Encender máquina ^cafetera.On Café en preparación indicador de fin Servir café Beber
  143. 143. ...Ejemplos (con bandas) Pasajero Vendedor Airline Solicitar pasaje Verificar existencia vuelo Dar detalles vuelo Informar alternativas y precios Seleccionar vuelo Solicitar pago Reservar plazas Confirmar Pagar pasaje plaza reservada Emitir billete
  144. 144. Diagrama de Componentes
  145. 145. … Diagramas de Componentes La representación gráfica es la siguiente: Especificación Cuerpo Genérico Package Package Generic specification body package
  146. 146. Subsistemas Los distintos componentes pueden agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación Son paquetes estereotipados en <<subsistemas>> <<subsistema>> NewPackage4
  147. 147. Diagrama de Distribución
  148. 148. Diagramas de Distribución Servidor Central Control y Análisis Acceso a BD Comment Comment Rutinas de Coneccion Comment Terminal de Consulta Interfaz de Terminal Rutinas de Coneccion Comment CommentPunto de Venta Rutinas de Coneccion Comment Gestión de Cuentas Interfaz de Terminal Comment Comment
  149. 149. … Diagramas de Distribución  Ejemplo de conexión entre nodos: <<Procesador> <<dispositivo>> Nodo <<<<TCP/IP>>>> nodo2 conexión1 conexión7 <<RDSI>>En Rational Rose podemos dispositivdistinguir entre el dispositivo por oestereotipado y el dispositivo consu propio símbolo
  150. 150. Paquetes
  151. 151. Paquetes en UML Los paquetes ofrecen un mecanismo general para la organización de los modelos agrupando elementos de modelado Se representan gráficamente como: Nombre de paquete

×