Diagramas de clases

60,344 views
59,896 views

Published on

5 Comments
6 Likes
Statistics
Notes
No Downloads
Views
Total views
60,344
On SlideShare
0
From Embeds
0
Number of Embeds
6,766
Actions
Shares
0
Downloads
1,130
Comments
5
Likes
6
Embeds 0
No embeds

No notes for slide

Diagramas de clases

  1. 1. Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
  2. 2. Contenidos de la Unidad 4 Diseño Orientado a Objetos II <ul><li>Diseño orientado a Objetos II </li></ul>Craig Larman., Cap. 21 <ul><li>Diagrama de Clases. </li></ul>  <ul><ul><li>Generalización. </li></ul></ul>  <ul><ul><li>Agregación. </li></ul></ul>  <ul><ul><li>Composición. </li></ul></ul>  B. Visibilidad entre Objetos   Craig Larman., Cap. 20 C. Paquetes, Estratos y Particiones Craig Larman., Cap. 22 D. Diagrama de actividad.   E. Diagrama de Transición de estado.  
  3. 3. Diagramas de Clases Craig Larman, Cap. 21 Ingeniería en Sistemas de Información
  4. 4. <ul><li>Una vez terminados los diagramas de interacción para el ciclo actual de desarrollo de la aplicación, podemos identificar la especificación de las clases de software (y las interfaces) que participan en la solución de software y complementarlas con detalles de diseño: los métodos. </li></ul><ul><li>El lenguaje UML ofrece una notación que muestra los detalles de diseño en los diagramas de estructura – o clase – estática. </li></ul>Diagramas de Clases Introducción
  5. 5. Diagramas de Clases Actividades y Dependencias <ul><li>La definición de este tipo de diagrama se lleva a cabo en la fase de diseño del ciclo de desarrollo. Su preparación exige crear antes: </li></ul><ul><li>  </li></ul><ul><li>Diagramas de interacción: a partir de ellos el diseñador identifica las clases de software que intervienen en la solución, así como los métodos de clases. </li></ul><ul><li>Modelo conceptual: a partir de este el diseñador agrega detalles a la definición de clases. </li></ul>
  6. 6. <ul><li>El Diagrama de Clases de Diseño describe gráficamente las especificaciones de las Clases de Software y las Interfaces en una aplicación. Normalmente contiene la siguiente información: </li></ul><ul><li>Clases, asociaciones y atributos. </li></ul><ul><li>Interfaces, con sus operaciones y constantes. </li></ul><ul><li>Información sobre los tipos de atributos. </li></ul><ul><li>Navegabilidad. </li></ul><ul><li>Dependencia. </li></ul>Diagramas de clases del Diseño
  7. 7. <ul><li>A diferencia del Modelo Conceptual , un Diagrama de este tipo contiene las definiciones de las entidades de software en vez de conceptos del mundo real. </li></ul><ul><li>Craig Larman no define concretamente un Diagrama de Clases de Diseño . Podemos llegar a su concepto a través de ejemplos. </li></ul><ul><li>Veamos el diagrama de la figura siguiente: </li></ul>Diagramas de Clases
  8. 8. Diagramas de Clases Ejemplo CAJA IntroducirProducto() Venta fecha estaTerminada: Booleano hora IntroducirProducto() Captura 1 Navegabilidad 1 M é todos Casilla de tres secciones para la definici ó n de clase Informaci ó n sobre tipos
  9. 9. <ul><li>Además de las asociaciones y de los atributos básicos, se ha ampliado el diagrama para incluir los métodos de cada clase, la información sobre los tipos de atributos, su visibilidad y navegación entre objetos. </li></ul>Diagramas de Clases
  10. 10. <ul><li>Comparación entre el modelo conceptual y los diagramas de clases de diseño </li></ul><ul><li>En el Modelo Conceptual una Venta no representa una definición de software; sino una abstracción de un concepto del mundo real sobre el cual queremos afirmar algo. </li></ul><ul><li>En cambio, “ Venta ” en los Diagramas de Clases de Diseño expresa --para sistemas computarizados – la definición de UNA CLASE como componente del software . </li></ul>Diagramas de Clases
  11. 11. Diagramas de Clases CAJA Venta fecha estaTerminada: Booleano hora Captura 1 1 Modelo Conceptual Concepto: abstracci ó n CAJA IntroducirProducto() Venta fecha estaTerminada: Booleano hora IntroducirProducto() Captura 1 1 Diagrama de Clases del Dise ñ o Componente del sofware
  12. 12. Diagramas de Clases Como elaborar un diagrama de clases del diseño <ul><li>  </li></ul><ul><li>Aplique la siguiente estrategia para elaborar diagramas de clases: </li></ul><ul><li>  </li></ul><ul><li>Identifique todas las clases que participan en la solución del software. Para ello analice los diagramas de interacción. </li></ul><ul><li>Dibújelas en un diagrama de clases </li></ul><ul><li>Duplique los atributos provenientes del modelo conceptual </li></ul><ul><li>Agregue los nombres de los métodos analizando los diagramas de interacción </li></ul><ul><li>Incorpore la información sobre los tipos de atributos y los métodos </li></ul><ul><li>Agregue las asociaciones necesarias para dar soporte a la visibilidad requerida de los atributos </li></ul><ul><li>Agregue flechas de navegabilidad a las asociaciones para indicar la dirección de la visibilidad de atributos </li></ul><ul><li>Agregue las líneas de relaciones de dependencia para indicar la visibilidad no relacionada con los atributos </li></ul>
  13. 13. <ul><li>1. Identificación de las clases de software y su ilustración: </li></ul><ul><li>El primer paso en la preparación de diagramas como parte del modelo de la solución del software es identificar las clases que intervienen en la solución del software. </li></ul><ul><li>Podremos encontrarlas con solo examinar todos los diagramas de interacción, y listarlas: </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO VentaLineadeProductos CAJA Venta CatalogodeProductos Tienda EspecificaciondeProductos Pago
  14. 14. <ul><li>El siguiente paso consiste en dibujar un diagrama de clases para estas, e incluir atributos y asociaciones del modelo conceptual. </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO CAJA CatalogodeProductos cantidad EspecificaciodeProducto descripcion cantidad CUP Tienda direccion nombre Venta fecha estaterminada hora VentasLineadeProducto Cantidad Pago monto
  15. 15. <ul><li>Nótese que muchos conceptos del Modelo Conceptual (ej.: Cajero , Gerente y Producto ), no aparecen en el diseño. </li></ul><ul><li>No es necesario – en el actual ciclo de desarrollo – representarlos en el software. </li></ul><ul><li>Pero en ciclos ulteriores podemos incorporarlos al diseño, en caso de que se requiera su agregación. </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  16. 16. <ul><li>2. Agregar los nombres de los métodos: </li></ul><ul><li>Para identificar los métodos de las clases se analizan los Diagramas de Colaboración . </li></ul><ul><li>Por ejemplo, si el mensaje hacerLineadeProducto se envía a una instancia de la clase Venta , entonces deberá definir el método hacerLineadeProducto en Venta . </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  17. 17. <ul><li>Nombres de los Métodos tomados de los Diagramas de Colaboración / Interacción : </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO Venta fecha estaTerminada hora hacerLineadeProducto() 3: hacerLineadeProducto(especif, cant) : CAJA :Venta
  18. 18. <ul><li>En términos generales, el conjunto de los mensajes enviados a la clase X a través de los diagramas de colaboración indica la mayoría de los métodos que ha de definir la clase X. </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  19. 19. CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO CAJA TerminarVenta() IntroducirProducto() EfectuarPago() CatalogodeProductos Especificacion() EspecificaciodeProducto Descripcion Cantidad CUP Tienda Direccion nombre agregarVenta() Venta fecha estaTerminada hora Setermina() HacerLineadeProducto() EfectuarPago() Total() VentaLineadeProducto Cantidad Subtotal() Pago cantidad
  20. 20. <ul><li>3. Nombre de los métodos: Aspectos. </li></ul><ul><li>Los siguientes aspectos especiales deben tenerse en cuenta con respecto a los nombres de los métodos: </li></ul><ul><li>Interpretación de los mensajes Crear(). </li></ul><ul><li>Descripción de los Métodos de Acceso. </li></ul><ul><li>Interpretación de los mensajes dirigidos a multiobjetos. </li></ul><ul><li>Sintaxis dependiente del estado. </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  21. 21. <ul><li>4. Nombre de los métodos: Crear. </li></ul><ul><li>El mensaje “ Crear ” es la forma en que, en UML , indicamos: instanciación e inicialización . </li></ul><ul><li>Cuando traducimos el Diseño a un Lenguaje de Programación Orientado a Objetos , hay que expresarlo en términos de sus expresiones de instanciación e inicialización . </li></ul><ul><li>En Java invoca el operador new , seguido de la llamada al constructor. </li></ul><ul><li>Por ser la inicialización una actividad común, se acostumbra omitir los métodos relacionados con la creación y los constructores procedentes del diagrama de clases de diseño . </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  22. 22. <ul><li>5. Nombres de los Métodos: Métodos de “Acceso”. </li></ul><ul><li>Los Métodos de Acceso son aquellos que recuperan ( Método Accesor ) o establecen ( Método Mutador ) el valor de los atributos . </li></ul><ul><li>Una estructura común consiste en contar con un Accesor y un Mutador por cada atributo y declarar privados todos los atributos (para obligar el encapsulamiento ). </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  23. 23. <ul><li>Métodos de “Acceso” : Continuación: </li></ul><ul><li>Normalmente estos métodos no se incluyen en el diagrama de clases por la elevada razón de ruido : para N atributos hay 2N métodos sin el menor interés . </li></ul><ul><li>Por ejemplo no se muestra el método “ obtener precio ” de especificaciondeProducto , porque está presente implícitamente, al tratarse de un Método Accesor Simple . </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  24. 24. <ul><li>6. Nombre de los Métodos: “ Multiobjetos ”. </li></ul><ul><li>Un mensaje a un Multiobjeto se interpreta como si estuviera destinado al objeto contenedor/colección. </li></ul><ul><li>Por ejemplo, el siguiente mensaje encontrar dirigido a un multiobjeto ha de interpretarse como si estuviera destinado a un objeto contenedor/colección; por ejemplo una tabla hastable (cálculo de dirección) o un dictionary (diccionario) de Smalltalk. </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  25. 25. <ul><li>Mensaje a Multiobjeto: </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO 2.1 : especif := encontrar(cup) :CatalogodeProductos :EspecificaciondeProductos especif:=especificacion(cup) El mensaje encontrar est á destinado al objeto contenedor, no a una EspecificaciondeProducto.
  26. 26. <ul><li>Por lo tanto el método “ encontrar ” no forma parte de la clase especificaciondeProducto . </li></ul><ul><li>Estas clases contenedor/colección son clases predefinidas de las bibliotecas y rara vez sirve mostrarlas explícitamente en el Diagrama. </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  27. 27. <ul><li>7. Nombre de los métodos: sintaxis dependiente del lenguaje </li></ul><ul><li>Algunos lenguajes ( Smalltalk ) tienen una forma sintáctica para los métodos distinto al formato básico de: </li></ul><ul><li>nombredelmetodo (listadeparametros) . </li></ul><ul><li>Recomendamos utilizar el formato básico de UML , aun cuando el lenguaje de implementaron planeada aplique otra sintaxis. </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  28. 28. <ul><li>8. Agregar mas información sobre tipos: </li></ul><ul><li>Es opcional mostrar el tipo de los atributos, los parámetros del método y los valores de devolver método. </li></ul><ul><li>La cuestión de si debe incluirse o no esta información deberá considerares dentro del siguiente contexto: </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  29. 29. <ul><li>El Diagrama de Clases Orientado al Diseño deberá elaborase teniendo en cuenta que: </li></ul><ul><li>Si vamos a crearlo en una herramienta CASE con generación automática de código, se requerirán detalles completos. </li></ul><ul><li>Si vamos a crearlo para que lo lean los diseñadores del software, el exceso de detalles puede influir negativamente. </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  30. 30. <ul><li>Incorporación de Información sobre los “Tipos”: </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO Venta fecha : fecha estaTerminada : Booleano hora : hora seTermina() hacerLineadeProducto(especif : EspecificaciondeProd, cant : Entero) efectuarPago(efectivoOfrecido : Cantidad) total() : Cantidad Tipo de resultado a devolver al m é todo Vac í o, sin valor a devolver
  31. 31. <ul><li>9. Incorporación de asociaciones y de navegabilidad: </li></ul><ul><li>Se da nombre de papel al final de una asociación ; en los Diagramas de Clases orientados al Diseño podemos adornar el papel con una “ Flecha de Navegabilidad ”. </li></ul><ul><li>La navegabilidad es una propiedad del papel e indica la posibilidad de navegar unidireccionalmente en una asociación, desde el objeto fuente hasta el destino . </li></ul><ul><li>La navegabilidad significa visibilidad , generalmente visibilidad de atributo . </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  32. 32. <ul><li>Descripción gráfica de la navegabilidad, o sea de la visibilidad de los atributos </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO CAJA IntroducirProducto() TerminarVenta() EfectuarPago() Venta Fecha EstaTermin: Booleano hora IntroducirProducto() Se termina() EfectuarPago() Total() 1 Captura 1 La clase CAJA probablemente tenga un atributo que apunta a un objeto venta La flecha de navegabilidad indica que los objetos CAJA est á n conectados unidireccionalmente con los objetos Venta La ausencia de la flecha de navegabilidad indica que no existe conexi ó n de Venta a CAJA
  33. 33. <ul><li>La interpretación usual de una asociación con una flecha de navegabilidad es la visibilidad de atributo, desde la clase fuente hasta la destino. </li></ul><ul><li>Cuando se implementa un lenguaje de programación orientado a objetos, suele traducirse como si la clase fuente tuviera un atributo que se refiere a una instancia de la clase destino. </li></ul><ul><li>La visibilidad y las asociaciones requeridas entre las clases se indican con los diagramas de interacción. </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  34. 34. <ul><li>A continuación se mencionan 3 situaciones comunes que revelan la necesidad de definir una asociación con flecha de navegabilidad de A a B : </li></ul><ul><li>A envía un mensaje a B </li></ul><ul><li>A crea una instancia de B </li></ul><ul><li>A necesita mantener una conexión con B </li></ul><ul><li>Basándose en el criterio anterior de asociaciones y de navegabilidad, el análisis de los diagramas de colaboración, se produce el siguiente diagrama de clases: </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  35. 35. CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO Asociaciones con Símbolos de Navegabilidad: CAJA terminarVenta() introducirProducto() efectuarPago() CatalogodeProductos especificacion() EspecificaciodeProducto Descripcion Cantidad CUP Tienda direccion nombre agregarVenta() Venta fecha estaTerminada hora seTermina() hacerLineadeProducto() efectuarPago() total() VentaLineadeProducto cantidad Subtotal() Pago cantidad alberga 1 1 1 1 usa 1 1 Mira-en 1 * Registro terminados captura 1 1 1 1..* contiene 1 1..* contiene describe 1 * Pagada_por 1 1
  36. 36. <ul><li>10. Agregación de las “ Relaciones de Dependencia ”: </li></ul><ul><li>El lenguaje UML incluye una relación general de dependencia, la cual indica que un elemento (de cualquier tipo como clases, casos de uso y otros) conoce la existencia de otro. </li></ul><ul><li>Se denota con una línea punteada y con flecha. </li></ul><ul><li>En el Diagrama de Clases , la Relación de Dependencia sirve para describir la visibilidad entre atributos que no se relacionan ; es decir: la visibilidad de parámetro global o declarada localmente . </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  37. 37. <ul><li>En cambio, la visibilidad simple de atributos se indica con una flecha normal de asociación y con una flecha de navegabilidad . </li></ul><ul><li>Por ejemplo, si en el ejercicio del punto de Venta, se prevé que C AJA gestione la devolución de algún ítem que se iba a comprar originariamente, pero que luego el Cliente desiste de su adquisición, entonces se puede prever una relación de dependencia directa y temporal con EspecificaciondeProducto , para concretar esta operación excepcional. </li></ul><ul><li>Así, CAJA puede tener una visibilidad de corto plazo localmente declarada en EspecificaciondeProducto . </li></ul>CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO
  38. 38. CREACIÓN DE DIAGRAMAS DE CLASES DEL DISEÑO Relaciones de dependencia que indican una visibilidad no relacionada con atributos CAJA terminarVenta() introducirProducto() efectuarPago() CatalogodeProductos especificacion() EspecificaciodeProducto Descripcion Cantidad CUP Tienda direccion nombre agregarVenta() Venta fecha estaTerminada hora seTermina() hacerLineadeProducto() efectuarPago() total() VentaLineadeProducto cantidad Subtotal() Pago cantidad alberga 1 1 1 1 usa 1 1 Mira-en 1 * Registro terminados captura 1 1 1 1..* contiene 1 1..* contiene describe 1 * Pagada_por 1 1 Dependencia de CAJA que conoce sobre EspecificaciondeProducto Se recomienda cuando existe un par á metro y visibilidad global o declarada localmente

×