Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Curso Uml 2.1 Diagramas De Cu Y Clases

47,062 views

Published on

Capitulo 2.1 Diagrama de casos de usos y Diagrama de Clases, del workshop de 20 horas de UML y Proceso Unificado

Published in: Technology, Business

Curso Uml 2.1 Diagramas De Cu Y Clases

  1. 1. Curso UML Emilio Avilés Ávila http://www.techmi.es
  2. 2. Workshop (20 horas) Workshop UML y Proceso Unificad para empresas y profesionales
  3. 3. Temario <ul><li>Introducción </li></ul><ul><li>Diagramas </li></ul><ul><ul><li>Casos de Uso </li></ul></ul><ul><ul><li>Diagramas de Clases </li></ul></ul><ul><ul><li>Diagramas de Interacción </li></ul></ul><ul><ul><li>Diagramas de Comportamiento </li></ul></ul><ul><ul><li>Diagramas de implementación </li></ul></ul><ul><ul><li>Otros diagramas </li></ul></ul><ul><li>Proceso Unificado </li></ul>
  4. 4. Tema 2 Diagramas
  5. 5. Objetivos <ul><li>Introducción </li></ul><ul><li>Diagramas </li></ul><ul><ul><li>Casos de Uso </li></ul></ul><ul><ul><li>Diagramas de Clases </li></ul></ul><ul><ul><li>Diagramas de Interacción </li></ul></ul><ul><ul><li>Diagramas de Comportamiento </li></ul></ul><ul><ul><li>Diagramas de implementación </li></ul></ul><ul><ul><li>Otros diagramas </li></ul></ul><ul><li>Proceso Unificado </li></ul><ul><li>Conocer el modelo de casos de uso </li></ul><ul><li>Identificar las partes de un CU (Actores) </li></ul><ul><li>Relaciones entre CU include y extends. </li></ul><ul><li>Diferencia entre Clase y Objeto. </li></ul><ul><li>Partes de una clase UML. </li></ul><ul><li>Técnicas para modelar clases. </li></ul><ul><li>Elementos de un diagrama de clases. </li></ul><ul><li>Diferenciar los 4 tipo de relaciones entre clases. </li></ul><ul><li>Estereotipos. </li></ul>
  6. 6. Tema 2.1 Casos de Uso
  7. 7. 2.1 – Casos de Uso <ul><li>¿Qué es un caso de uso? </li></ul><ul><ul><li>Un caso de uso es una secuencia de interacciones entre uno o varios actores y el sistema. </li></ul></ul><ul><ul><li>Unidad discreta de interacción o de trabajo. </li></ul></ul><ul><ul><li>Tiene lugar bajo ciertas circunstancias: </li></ul></ul><ul><ul><ul><li>Es iniciada por un actor . </li></ul></ul></ul><ul><ul><ul><li>Se puede describir como una secuencia de actividades . </li></ul></ul></ul><ul><ul><ul><li>Produce un resultado de valor observable para algún actor. </li></ul></ul></ul>
  8. 8. 2.1 – Casos de Uso
  9. 9. 2.1 – Casos de Uso <ul><li>¿Por qué utilizar Casos de Uso? </li></ul><ul><ul><li>Un caso de uso ayuda a contestar las siguientes preguntas: </li></ul></ul><ul><ul><li>¿ Quién hace qué? </li></ul></ul><ul><ul><li>¿ Cuándo lo hace? </li></ul></ul><ul><ul><li>¿ Qué actividades se realizan? </li></ul></ul><ul><ul><li>¿ Qué elementos del sistema se utilizan? </li></ul></ul>
  10. 10. 2.1 – Casos de Uso <ul><li>Alcance de caso de uso </li></ul><ul><ul><li>Determinar el alcance de un caso de uso consiste en identificar que elementos forman parte de dicho caso de uso. </li></ul></ul><ul><ul><li>Tan importante como identificar lo que forma parte del caso de uso es identificar lo que NO forma parte del caso de uso. </li></ul></ul>
  11. 11. 2.1 – Casos de Uso <ul><li>Ejemplo: R eserva de Billete </li></ul>
  12. 12. 2.1 – Casos de Uso <ul><li>Ejercicio práctico </li></ul><ul><ul><li>Determinar cuales de las siguientes afirmaciones no caen dentro del alcance del caso de uso de reserva de billete aéreo </li></ul></ul><ul><ul><ul><li>…. Suerte!!! </li></ul></ul></ul>
  13. 13. 2.1 – Casos de Uso <ul><li>Elementos del Caso de Uso </li></ul><ul><ul><li>Descripción : Describe la funcionalidad que se construirá en el sistema propuesto. </li></ul></ul><ul><ul><li>Relaciones : Inclusiones o Extensiones de funcionalidades con otros Caso de Uso. </li></ul></ul>
  14. 14. 2.1 – Casos de Uso <ul><li>Descripción Caso de Uso </li></ul><ul><ul><li>Comentarios y notas describiendo CU. </li></ul></ul><ul><ul><li>Requisitos : Que permite el CU al usuario </li></ul></ul><ul><ul><li>Restricciones : reglas acerca de qué se puede y qué no se puede hacer </li></ul></ul><ul><ul><ul><li>Pre-condiciones, Post-condiciones o invariantes </li></ul></ul></ul><ul><ul><li>Escenarios : descripciones secuenciales de los pasos que se toman para llevar a cabo el CU. </li></ul></ul><ul><ul><ul><li>Pueden incluir escenarios base, excepcionales y caminos de proceso alternativos </li></ul></ul></ul><ul><ul><li>Atributos adicionales fase de implementación, número de versión, rango de complejidad, estereotipo y estado </li></ul></ul>
  15. 15. 2.1 – Casos de Uso <ul><li>Actores </li></ul><ul><ul><li>Representan elementos externos al sistema que colaboran con el mismo. </li></ul></ul><ul><ul><ul><li>Usuarios. </li></ul></ul></ul><ul><ul><ul><li>Clientes. </li></ul></ul></ul><ul><ul><ul><li>Otros sistemas. </li></ul></ul></ul><ul><ul><ul><li>Dispositivos externos (p. ej. temporizadores). </li></ul></ul></ul><ul><ul><li>Tipos: </li></ul></ul><ul><ul><ul><li>Internos: Toman parte activa en el caso de uso. </li></ul></ul></ul><ul><ul><ul><li>Externos: Disparan el caso de uso o reciben su salida. </li></ul></ul></ul>
  16. 16. 2.1 – Casos de Uso <ul><li>Actores (II) </li></ul><ul><ul><li>Los actores no forman parte del sistema , sino que representan elementos que interactúan con él. </li></ul></ul><ul><ul><li>Un actor puede introducir, recibir, o introducir y recibir información desde o hacia el sistema. </li></ul></ul><ul><ul><li>Alcance o rol : </li></ul></ul><ul><ul><li>Conjunto de CU a </li></ul></ul><ul><ul><li>los que tiene acceso. </li></ul></ul>
  17. 17. 2.1 – Casos de Uso <ul><li>Diagramas de Caso de Uso </li></ul><ul><ul><li>Organizan los comportamientos y funcionalidad del sistema. </li></ul></ul><ul><ul><li>Describe, posiblemente en lenguaje natural, una forma en que un `` actor '' del mundo real (persona, organización o sistema externo) interacciona con el modelo. </li></ul></ul><ul><ul><li>Muestra requisitos funcionales . </li></ul></ul><ul><ul><li>Escenario : Camino dentro de un CU. </li></ul></ul><ul><ul><ul><li>Muestra una combinación específica de condiciones en un caso de uso. </li></ul></ul></ul>
  18. 18. 2.1 – Casos de Uso
  19. 19. 2.1 – Casos de Uso <ul><li>Relaciones entre CU </li></ul><ul><ul><li>CU – Actor: </li></ul></ul><ul><ul><ul><li>Asociación ``comunica'‘ (<<comunicates>>) </li></ul></ul></ul><ul><ul><ul><li>En general navegable en ambas direcciones </li></ul></ul></ul><ul><ul><ul><li>La dirección refleja quien inicia la comunicación. </li></ul></ul></ul><ul><ul><li>CU – CU: </li></ul></ul><ul><ul><ul><li>Pueden ser de dos tipos </li></ul></ul></ul><ul><ul><ul><ul><li><<include>> (Incluye) </li></ul></ul></ul></ul><ul><ul><ul><ul><li><<extends>> (Extiende) </li></ul></ul></ul></ul>
  20. 20. 2.1 – Casos de Uso <ul><li>Relaciones Diagrama CU </li></ul><ul><ul><li>``usa'' (<<include>>) </li></ul></ul><ul><ul><ul><li>Un CU puede incluir funcionalidad de otro como parte del procesamiento normal. </li></ul></ul></ul><ul><ul><ul><li>Los CU incluidos se llamaran en el escenario base . </li></ul></ul></ul><ul><ul><ul><li>Un CU puede ser incluido por uno o más Casos de Uso. </li></ul></ul></ul><ul><ul><ul><li>Se reduce la duplicación de funcionalidad al factorizar el comportamiento común. </li></ul></ul></ul>
  21. 21. 2.1 – Casos de Uso <ul><li>Ejemplo ``usa'' (<<include>>) </li></ul><ul><ul><li>El C.U. Incluido por si solo no tiene sentido , es decir, no podría ser llamado por un actor. </li></ul></ul><ul><ul><li>Siempre es llamado por el C.U. que lo incluye (no es opcional). </li></ul></ul>
  22. 22. 2.1 – Casos de Uso <ul><li>Relaciones Diagrama CU </li></ul><ul><ul><li>``extiende'' (<<extends>>) </li></ul></ul><ul><ul><ul><li>Un CU puede extender comportamiento de otro caso de uso. </li></ul></ul></ul><ul><ul><ul><li>Típicamente cuando ocurren escenarios excepcionales . </li></ul></ul></ul><ul><ul><ul><li>Por ejemplo: </li></ul></ul></ul><ul><ul><ul><ul><li>Si antes de modificar un tipo particular de orden de cliente, un usuario debe obtener la aprobación de alguna autoridad superior, entonces el Caso de Uso <obtener aprobación> puede extender opcionalmente el Caso de Uso normal <modificar orden>. </li></ul></ul></ul></ul>
  23. 23. 2.1 – Casos de Uso <ul><li>Ejemplo <<extends>> </li></ul><ul><ul><li>Un caso de uso extiende a otro cuando agrega tareas adicionales al primero. </li></ul></ul><ul><ul><li>Los puntos de extensión pueden ir unidos a una condición que debe cumplirse para indicar la extensión (Factura > 300) </li></ul></ul>
  24. 24. 2.1 – Casos de Uso <ul><li>Resumen: Relaciones Diagrama CU </li></ul><ul><ul><li>``comunica'' (<<communicates>>): </li></ul></ul><ul><ul><ul><li>Relación Actor – CU. </li></ul></ul></ul><ul><ul><ul><li>Denota participación del actor en el CU. </li></ul></ul></ul><ul><ul><li>``usa'' (<<include>>) </li></ul></ul><ul><ul><ul><li>Relación de dependencia de dos CU. </li></ul></ul></ul><ul><ul><ul><li>Denota inclusión de comportamiento de 1 en otro. </li></ul></ul></ul><ul><ul><ul><li>Repetición del comportamiento del CU. </li></ul></ul></ul><ul><ul><li>``extiende'' (<< extends>>): </li></ul></ul><ul><ul><ul><li>Relación de dependencia de dos CU. </li></ul></ul></ul><ul><ul><ul><li>Denota especialización de 1 en otro. </li></ul></ul></ul><ul><ul><ul><li>Variación del comportamiento normal del CU. </li></ul></ul></ul>
  25. 25. 2.1 – Casos de Uso <ul><li>Ejercicio práctico </li></ul><ul><ul><li>Modelar el diagrama de Casos de Usos de una maquina expendedora de café </li></ul></ul><ul><ul><ul><li>Representar los CU </li></ul></ul></ul><ul><ul><ul><li>Representar los Actores </li></ul></ul></ul><ul><ul><ul><li>Representar todas las posibles Relaciones </li></ul></ul></ul><ul><ul><ul><li>…. Suerte!!! </li></ul></ul></ul>
  26. 26. 2.1 – Casos de Uso
  27. 27. 2.1 – Casos de Uso <ul><li>Modelo Casos de Usos </li></ul><ul><ul><li>Combinación de Casos de Uso y sus diagramas. </li></ul></ul><ul><ul><li>Suelen venir acompañado de un Glosario . </li></ul></ul>
  28. 28. 2.1 – Casos de Uso <ul><li>Herencia vs Extends </li></ul><ul><ul><li>Además de las relaciones entre CU y Actor, y las dependencias de entre CU ( <<include>> y <<extends>>) pueden existir relaciones de herencia . </li></ul></ul><ul><ul><li>NO CONFUNDIR! </li></ul></ul><ul><ul><li>Generalización (Herencia): </li></ul></ul><ul><ul><ul><li>El caso de uso derivado (particular o heredero) puede modificar alguna de las tareas del caso de uso base (general). </li></ul></ul></ul><ul><ul><li>Extensión: </li></ul></ul><ul><ul><ul><li>El caso de uso que extiende NO puede modificar las tareas del caso de uso del cual se extiende. Solamente puede agregar tareas nuevas en los puntos de extensión. </li></ul></ul></ul>
  29. 29. 2.1 – Casos de Uso <ul><li>Ejemplo Herencia en Actores Polimorfismo </li></ul>
  30. 30. Tema 2.2 Diagrama de Clases
  31. 31. 2.2 – Diagrama de Clases <ul><li>Previo… Objetos </li></ul><ul><ul><li>Representación de una entidad: </li></ul></ul><ul><ul><ul><li>Conceptual o real. </li></ul></ul></ul><ul><ul><ul><li>Con unos límites definidos. </li></ul></ul></ul><ul><ul><ul><li>Con significado dentro del modelo. </li></ul></ul></ul><ul><ul><li>Cada objeto se caracteriza por: </li></ul></ul><ul><ul><ul><li>Identidad </li></ul></ul></ul><ul><ul><ul><li>Estado ( propiedades o atributos) </li></ul></ul></ul><ul><ul><ul><li>Comportamiento (Métodos o Operaciones) </li></ul></ul></ul>
  32. 32. 2.2 – Diagrama de Clases <ul><li>Clases </li></ul><ul><ul><li>Descripción de un grupo de objetos con: </li></ul></ul><ul><ul><ul><li>Propiedades comunes (atributos). </li></ul></ul></ul><ul><ul><ul><li>Comportamiento común (operaciones). </li></ul></ul></ul><ul><ul><ul><li>Relaciones comunes. </li></ul></ul></ul><ul><ul><li>Por lo tanto un clase será una plantilla ( template) para la creación de objetos: </li></ul></ul><ul><ul><ul><li>Cada objeto de dicha clase será una instancia de ella. </li></ul></ul></ul><ul><ul><ul><li>No pudiendo ser instancia de más de una clase. </li></ul></ul></ul>
  33. 33. 2.2 – Diagrama de Clases <ul><li>Diagrama de Clases: Introducción </li></ul><ul><ul><li>Diagrama que muestra una colección de elementos declarativos (estáticos) de un modelo, como clases y tipos, junto con sus contenidos y relaciones . </li></ul></ul><ul><ul><li>Son la espina dorsal de UML. </li></ul></ul><ul><ul><li>Elementos que forman un Diagrama de clases </li></ul></ul><ul><ul><ul><li>Clases </li></ul></ul></ul><ul><ul><ul><li>Relaciones </li></ul></ul></ul>
  34. 34. 2.2 – Diagrama de Clases <ul><li>Diagrama de Clases: Perspectivas </li></ul><ul><ul><li>Conceptual : </li></ul></ul><ul><ul><ul><li>Permite representar los conceptos del dominio. </li></ul></ul></ul><ul><ul><li>Especificación: </li></ul></ul><ul><ul><ul><li>Cuando se trata de representar las interfaces del software y no el software en sí. </li></ul></ul></ul><ul><ul><li>Implementación: </li></ul></ul><ul><ul><ul><li>Es en esta perspectiva donde realmente tenemos clases , siendo ésta la perspectiva más utilizada. </li></ul></ul></ul>
  35. 35. 2.2 – Diagrama de Clases <ul><li>Clase en UML </li></ul>
  36. 36. 2.2 – Diagrama de Clases <ul><li>Clase en UML </li></ul><ul><ul><li>Tienen un nombre que las distingue de otras clases. </li></ul></ul><ul><ul><li>Al dibujar una clase NO hay por qué representar toda su información . </li></ul></ul><ul><ul><li>Los estereotipos permiten organizar la información de una clase. </li></ul></ul>
  37. 37. 2.2 – Diagrama de Clases <ul><li>Clase en UML: Visibilidad </li></ul><ul><ul><li>public +: Cualquier clase externa con visibilidad hacia la clase dada puede utilizar la característica (ya se atributo u operación). </li></ul></ul><ul><ul><li>protected #: Cualquier descendiente de la clase puede utilizar la característica. </li></ul></ul><ul><ul><li>private -: Sólo el propio clasificador puede utilizar la característica. </li></ul></ul>
  38. 38. 2.2 – Diagrama de Clases <ul><li>Clase en UML: Alcance </li></ul><ul><ul><li>Característica especifica si la propiedad aparece en cada instancia de la clase o si sólo hay una instancia la propiedad para todas las instancias de la clase. </li></ul></ul><ul><ul><ul><li>instancia : Cada instancia de la clase tiene su propio valor. </li></ul></ul></ul><ul><ul><ul><li>clasificador : Sólo hay un valor para todas las instancias del clasificador. </li></ul></ul></ul><ul><ul><li>Se denota subrayando la característica. </li></ul></ul>
  39. 39. 2.2 – Diagrama de Clases <ul><li>Clase en UML: Atributos Inicialización </li></ul><ul><ul><li>Se puede especificarse un valor inicial y un conjunto de propiedades del atributo. </li></ul></ul>
  40. 40. 2.2 – Diagrama de Clases <ul><li>Clase en UML: Operaciones </li></ul><ul><ul><li>Donde cada uno de los parámetros en parameter list se denota igual que un atributo. </li></ul></ul><ul><ul><li>Los demás elementos son los mismos que encontramos en la notación de un atributo. </li></ul></ul>
  41. 41. 2.2 – Diagrama de Clases <ul><li>Clase en UML: Alcance </li></ul><ul><ul><li>Característica especifica si la propiedad aparece en cada instancia de la clase o si sólo hay una instancia la propiedad para todas las instancias de la clase. </li></ul></ul><ul><ul><ul><li>instancia : Cada instancia de la clase tiene su propio valor. </li></ul></ul></ul><ul><ul><ul><li>clasificador : Sólo hay un valor para todas las instancias del clasificador. </li></ul></ul></ul><ul><ul><li>Se denota subrayando la característica. </li></ul></ul>
  42. 42. 2.2 – Diagrama de Clases <ul><li>Clase en UML: Paramétrica </li></ul><ul><ul><li>Se corresponde con el concepto de clases molde ( template ) en C++ o genéricos Java </li></ul></ul><ul><ul><li>Ejemplo </li></ul></ul><ul><ul><ul><li>La clase Lista que utiliza un parámetro formal Tipo </li></ul></ul></ul><ul><ul><ul><li>Pudiendo representar una lista de diferentes tipos de objetos dependiendo del valor del parámetro </li></ul></ul></ul>
  43. 43. 2.2 – Diagrama de Clases <ul><li>Técnicas para modelar Clases (I) </li></ul><ul><ul><li>Modelado del vocabulario </li></ul></ul><ul><ul><ul><li>Identificar las palabras que utilizan los usuarios o programadores para describir el problema o la solución. </li></ul></ul></ul><ul><ul><ul><li>Identificar responsabilidades para cada abstracción identificar. </li></ul></ul></ul><ul><ul><ul><li>Proporcionar atributos y operaciones para cada clase. </li></ul></ul></ul>
  44. 44. 2.2 – Diagrama de Clases <ul><li>Técnicas para modelar Clases (II) </li></ul><ul><ul><li>Modelado de Responsabilidades </li></ul></ul><ul><ul><ul><li>Identificar un conjunto de clases que colaboren entre ellas para llevar a cabo algún comportamiento y sus responsabilidades. </li></ul></ul></ul><ul><ul><ul><li>Dividir las clases con demasiadas responsabilidades y agrupar las que tienen pocas, verificando que no hay solapamiento de responsabilidades. </li></ul></ul></ul><ul><ul><ul><li>Verificar la granularidad de las responsabilidades. </li></ul></ul></ul>
  45. 45. 2.2 – Diagrama de Clases <ul><li>Relaciones: Origen </li></ul><ul><ul><li>Todo los sistemas se construyen a partir de muchas clases y objetos para lograr ofrecer el comportamiento deseado. </li></ul></ul><ul><ul><li>Esto implica una colaboración entre ellos que impone la existencia de unas relaciones. </li></ul></ul>
  46. 46. 2.2 – Diagrama de Clases <ul><li>Relaciones: Tipos </li></ul><ul><ul><li>Asociación : Relación semántica. </li></ul></ul><ul><ul><li>Composición : Relación de Composición. </li></ul></ul><ul><ul><ul><li>Agregación: Relación de pertenencia </li></ul></ul></ul><ul><ul><li>Dependencia : Relación de Necesidad. </li></ul></ul><ul><ul><li>Generalización : Relación taxonómica. </li></ul></ul>
  47. 47. 2.2 – Diagrama de Clases <ul><li>Relación de Asociación </li></ul><ul><ul><li>Relación semántica entre instancias con tipo. </li></ul></ul>
  48. 48. 2.2 – Diagrama de Clases <ul><li>Relación de Asociación </li></ul><ul><ul><li>No es un flujo de datos sino una relación estructural entre objetos instanciados. </li></ul></ul><ul><ul><li>“ Los objetos de una clase conocen de la otra” </li></ul></ul><ul><ul><li>Desde el punto de vista </li></ul></ul><ul><ul><ul><li>conceptual representan relaciones. </li></ul></ul></ul><ul><ul><ul><li>especificación representan responsabilidades. </li></ul></ul></ul><ul><ul><ul><li>Implementación representan punteros. </li></ul></ul></ul>
  49. 49. 2.2 – Diagrama de Clases <ul><li>Relación de Asociación : Notación </li></ul><ul><ul><li>Verbo activo o frase verbal que recoge el significado de la asociación </li></ul></ul><ul><ul><li>Rol opcional que denota propósito </li></ul></ul><ul><ul><li>Multiplicidad (número de objetos) </li></ul></ul><ul><ul><li>Navegabilidad : Sentido de la dirección. </li></ul></ul>
  50. 50. 2.2 – Diagrama de Clases <ul><li>Relación de Agregación </li></ul><ul><ul><li>Relación de Composición : Una clase está compuesta de otras. </li></ul></ul><ul><ul><li>Relación de Agregación : Una clase tiene otra clase de otras. </li></ul></ul>
  51. 51. 2.2 – Diagrama de Clases <ul><li>Relación Asociación: Cualificadores </li></ul><ul><ul><li>En ocasiones, la asociación no es mediante una referencia, sino por un campo clave o token. </li></ul></ul><ul><ul><li>Por tanto para acceder al objeto habrá que implementar alguna función de búsqueda. </li></ul></ul>
  52. 52. 2.2 – Diagrama de Clases <ul><li>Relación de Agregación </li></ul><ul><ul><li>Un asociación representa un relación estructural por igual, al mismo nivel. </li></ul></ul><ul><ul><li>Un agregación es una asociación especializada por el cual un todo se relaciona con sus partes . </li></ul></ul><ul><ul><li>También se la suele denominar como la relación ``parte de'' </li></ul></ul><ul><ul><li>UML ofrece una variedad más fuerte de agregación llamada composición. </li></ul></ul><ul><ul><ul><li>Los objetos parte viven y mueren con el todo . </li></ul></ul></ul>
  53. 53. 2.2 – Diagrama de Clases <ul><li>Relación de Dependencia </li></ul><ul><ul><li>Un elemento del modelo necesita a otro para su implementación o especificación. </li></ul></ul><ul><ul><li>El cambio en uno puede afectar al otro. </li></ul></ul>
  54. 54. 2.2 – Diagrama de Clases <ul><li>Relación de Dependencia </li></ul><ul><ul><li>Va más ligada a operaciones entre Clases. </li></ul></ul><ul><ul><li>Una clase utiliza otra como argumento de una de sus operaciones. </li></ul></ul><ul><ul><li>También se encuentran relaciones de dependencia entre paquetes. </li></ul></ul><ul><ul><ul><li>Si un paquete A depende de un paquete B , entonces hay una o más clases en el paquete A que inician comunicación con una o más clases públicas del paquete B . </li></ul></ul></ul>
  55. 55. 2.2 – Diagrama de Clases <ul><li>Relación de Generalización </li></ul><ul><ul><li>Relación taxonómica entre un clasificador más general y otro más específico. </li></ul></ul><ul><ul><li>El específico hereda las características y es instancia indirecta del general. </li></ul></ul>
  56. 56. 2.2 – Diagrama de Clases <ul><li>Relación de Generalización </li></ul><ul><ul><li>Una clase comparte estructura y/o comportamiento con otras clases. </li></ul></ul><ul><ul><li>Superclase: Clase que guarda la información </li></ul></ul><ul><ul><li>Subclase: Descendientes de la superclase. </li></ul></ul><ul><ul><ul><li>Hereda todos los atributos, operaciones y relaciones definidos en su superclase. </li></ul></ul></ul><ul><ul><ul><li>Pueden ampliar información de la superclase. </li></ul></ul></ul><ul><ul><ul><li>Puede tener su propia implementación de una operación de la superclase ( Polimorfismo) </li></ul></ul></ul>
  57. 57. 2.2 – Diagrama de Clases <ul><li>Generalización vs Especialización </li></ul><ul><ul><li>Generalización: </li></ul></ul><ul><ul><ul><li>Proporciona la capacidad de crear superclases que encapsulan la estructura y el comportamiento común a varias clases. </li></ul></ul></ul><ul><ul><li>Especialización: </li></ul></ul><ul><ul><ul><li>Proporciona la capacidad de crear subclases que representan refinamientos de una superclase, generalmente añadiendo estructura y comportamiento a las nuevas subclases. </li></ul></ul></ul><ul><ul><ul><ul><li>Las operaciones heredadas pueden ser rescritas </li></ul></ul></ul></ul><ul><ul><ul><ul><li>La subclase no debería proporcionar una estructura o comportamiento menor que el de su superclase. </li></ul></ul></ul></ul>
  58. 58. 2.2 – Diagrama de Clases <ul><li>Herencia: Conceptos avanzados. </li></ul><ul><ul><li>Clases Abstractas : Sin instancias directas. </li></ul></ul><ul><ul><ul><li>En UML se especifica que una clase es abstracta escribiendo su nombre en cursiva . </li></ul></ul></ul><ul><ul><li>Clase Final : no puede tener descendentes. </li></ul></ul><ul><ul><ul><li>En UML se utiliza para ello la restricción {leaf}. </li></ul></ul></ul><ul><ul><li>Clase sin antecesores </li></ul></ul><ul><ul><ul><li>Asociando la restricción {root} a una clase. </li></ul></ul></ul><ul><ul><li>Restringir el número de instancias </li></ul></ul><ul><ul><ul><li>Su multiplicidad que será un número cardinal en la esquina superior derecha del icono de la clase. </li></ul></ul></ul>
  59. 59. 2.2 – Diagrama de Clases <ul><li>Estereotipos </li></ul><ul><ul><li>Permite “ extender ” el lenguaje UML para los diagramas de clases. </li></ul></ul><ul><ul><ul><li>Asppage, vista, modelo, controlador, persistencia… </li></ul></ul></ul><ul><ul><ul><li>Se representan por <<estereotipo>> </li></ul></ul></ul><ul><ul><ul><li>También son aplicables a la relación (por ejemplo, para indicar patrones como el Observer). </li></ul></ul></ul>
  60. 60. 2.2 – Diagrama de Clases <ul><li>Estereotipos: Tipos Comunes </li></ul><ul><ul><li>Entidad ( entity ): </li></ul></ul><ul><ul><ul><li>reflejar entidades del mundo real </li></ul></ul></ul><ul><ul><ul><li>modela la información de larga vida y su comportamiento asociado . </li></ul></ul></ul><ul><ul><li>Frontera ( boundary ): maneja comunicaciones entre el entorno del sistema y el sistema </li></ul></ul><ul><ul><li>Control ( control ) comportamiento secuenciado específico de uno o varios CU </li></ul></ul><ul><ul><li>Utilidad ( utility ) </li></ul></ul><ul><ul><li>Excepción ( exception ). </li></ul></ul>
  61. 61. 2.2 – Diagrama de Clases <ul><li>Estereotipos: <<Interfaz>> </li></ul><ul><ul><li>Cuando una clase trabaja con objetos que deben implementar una interfaz. </li></ul></ul><ul><ul><li>Puede indicar con una relación de dependencia con la interfaz y el estereotipo <<uses>> o la forma alternativa indicada a continuación. </li></ul></ul>
  62. 62. 2.1 – Casos de Uso <ul><li>Ejercicio práctico </li></ul><ul><ul><li>Dado el siguiente modelo conceptual </li></ul></ul><ul><ul><li>Representar como sería el Diagrama de Clases correspondiente: </li></ul></ul><ul><ul><ul><li>…. Suerte!!! </li></ul></ul></ul>
  63. 63. 2.2 – Diagrama de Clases <ul><li>Solución al Ejercicio práctico </li></ul>
  64. 64. 2.1 – Casos de Uso <ul><li>Ejercicio práctico </li></ul><ul><ul><li>Modelar el diagrama de clases: </li></ul></ul><ul><ul><ul><li>Una aplicación necesita almacenar información sobre empresas, sus empleados y sus clientes. </li></ul></ul></ul><ul><ul><ul><li>Ambos se caracterizan por su nombre y edad. </li></ul></ul></ul><ul><ul><ul><li>Los empleados tienen un sueldo bruto, los empleados que son directivos tienen una categoría, así como un conjunto de empleados subordinados. </li></ul></ul></ul><ul><ul><ul><li>De los clientes además se necesita conocer su teléfono de contacto. </li></ul></ul></ul><ul><ul><ul><li>La aplicación necesita mostrar los datos de empleados y clientes. </li></ul></ul></ul><ul><ul><ul><li>…. Suerte!!! </li></ul></ul></ul>
  65. 65. 2.2 – Diagrama de Clases <ul><li>Posible Solución al Ejercicio </li></ul>
  66. 66. 2.1 – Casos de Uso <ul><li>Ejercicio práctico </li></ul><ul><ul><li>Modelar el diagrama de clases de un cliente que se va de cañas y le ponen una tapa. </li></ul></ul><ul><ul><ul><li>Debe de pedir al menos una caña (bebida) para que le pongan. </li></ul></ul></ul><ul><ul><ul><li>Puede pagar con tarjeta de crédito como en efectivo. </li></ul></ul></ul><ul><ul><ul><li>…. Suerte!!! </li></ul></ul></ul>
  67. 67. 2.2 – Diagrama de Clases <ul><li>Posible Solución al Ejercicio </li></ul>
  68. 68. 2.1 – Casos de Uso <ul><li>Ejercicio práctico: Biblioteca </li></ul><ul><ul><li>Una biblioteca tiene copias de libros. Estos últimos se </li></ul></ul><ul><ul><li>caracterizan por su nombre, tipo (novela, teatro, poesía, </li></ul></ul><ul><ul><li>ensayo), editorial, año y autor. </li></ul></ul><ul><ul><li>Los autores se caracterizan por su nombre, nacionalidad </li></ul></ul><ul><ul><li>y fecha de nacimiento. </li></ul></ul><ul><ul><li>Cada copia tiene un identificador, y puede estar en la </li></ul></ul><ul><ul><li>biblioteca, prestada, con retraso o en reparación. </li></ul></ul><ul><ul><li>Los lectores pueden tener un máximo de 3 libros en </li></ul></ul><ul><ul><li>préstamo. </li></ul></ul><ul><ul><li>Cada libro se presta un máximo de 30 días, por cada día </li></ul></ul><ul><ul><li>de retraso, se impone una “multa” de dos días sin </li></ul></ul><ul><ul><li>posibilidad de coger un nuevo libro. </li></ul></ul><ul><ul><li>Realiza un diagrama de clases y añade los métodos </li></ul></ul><ul><ul><li>necesarios para realizar el préstamo y devolución de </li></ul></ul><ul><ul><li>libros. </li></ul></ul><ul><ul><ul><li>… . Suerte!!! </li></ul></ul></ul>
  69. 69. 2.2 – Diagrama de Clases <ul><li>Posible Solución a la biblioteca </li></ul>
  70. 70. 2.1 – Casos de Uso <ul><li>Ejercicio práctico: Redes de ordenadores </li></ul><ul><ul><li>Especificar un diagrama de clases que describa redes de ordenadores. </li></ul></ul><ul><ul><li>Los elementos que se pueden incluir en la red son: </li></ul></ul><ul><ul><ul><li>Servidor, PC, Impresora. </li></ul></ul></ul><ul><ul><ul><li>Hub, Cable de red. </li></ul></ul></ul><ul><ul><li>Los PCs pueden conectarse con un único Hub, los servidores con uno o varios. </li></ul></ul><ul><ul><li>Los Servidores y PCs pueden generar mensajes, con una cierta longitud. </li></ul></ul><ul><ul><li>Los Hubs tienen un número de puertos, algunos de los cuales puede usarse para conectar con otros Hubs. Tienen cierta probabilidad de “perder” mensajes. </li></ul></ul><ul><ul><li>Las impresoras pueden averiarse, con cierta probabilidad, durante cierto tiempo. </li></ul></ul>
  71. 71. 2.2 – Diagrama de Clases <ul><li>Posible Solución a la Redes </li></ul>
  72. 72. Conclusiones <ul><li>Introducción </li></ul><ul><li>Diagramas </li></ul><ul><ul><li>Casos de Uso </li></ul></ul><ul><ul><li>Diagramas de Clases </li></ul></ul><ul><ul><li>Diagramas de Interacción </li></ul></ul><ul><ul><li>Diagramas de Comportamiento </li></ul></ul><ul><ul><li>Diagramas de implementación </li></ul></ul><ul><ul><li>Otros diagramas </li></ul></ul><ul><li>Proceso Unificado </li></ul><ul><li>Conocer el modelo de casos de uso </li></ul><ul><li>Identificar las partes de un CU (Actores) </li></ul><ul><li>Relaciones entre CU include y extends. </li></ul><ul><li>Diferencia entre Clase y Objeto. </li></ul><ul><li>Partes de una clase UML. </li></ul><ul><li>Técnicas para modelar clases. </li></ul><ul><li>Elementos de un diagrama de clases. </li></ul><ul><li>Diferenciar los 4 tipo de relaciones entre clases. </li></ul><ul><li>Estereotipos. </li></ul>
  73. 73. Referencias <ul><li>Guía básica Curso UML.pdf </li></ul><ul><li>Tutorial Sparx </li></ul><ul><ul><li>http://www.sparxsystems.com.ar/resources/tutorial/use_case_model.html </li></ul></ul><ul><ul><li>http://www.sparxsystems.com.ar/resources/tutorial/logical_model.html </li></ul></ul>

×