Tecnicatura Superior en Programación

Presentación del tema: "Tecnicatura Superior en Programación"— Transcripción de la presentación:

1 Tecnicatura Superior en Programación
Metodología de Sistemas 2016 Díaz Gastón

2 Diagramas de Clases Introducción
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. El lenguaje UML ofrece una notación que muestra los detalles de diseño en los diagramas de estructura – o clase – estática.

3 Diagramas de clases del Diseño
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: Clases, asociaciones y atributos. Interfaces, con sus operaciones y constantes. Información sobre los tipos de atributos. Navegabilidad. Dependencia.

4 Diagramas de Clases 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. Craig Larman no define concretamente un Diagrama de Clases de Diseño. Podemos llegar a su concepto a través de ejemplos. Veamos el diagrama de la figura siguiente:

5 Diagramas de Clases Ejemplo
CAJA IntroducirProducto() Venta fecha estaTerminada: Booleano hora Captura 1 Navegabilidad Métodos Casilla de tres secciones para la definición de clase Información sobre tipos

6 Diagramas de Clases 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.

7 Como elaborar un diagrama de clases del diseño
Diagramas de Clases Como elaborar un diagrama de clases del diseño Aplique la siguiente estrategia para elaborar diagramas de clases: Identifique todas las clases que participan en la solución del software. Para ello analice los diagramas de interacción. Dibújelas en un diagrama de clases Duplique los atributos provenientes del modelo conceptual Agregue los nombres de los métodos analizando los diagramas de interacción Incorpore la información sobre los tipos de atributos y los métodos Agregue las asociaciones necesarias para dar soporte a la visibilidad requerida de los atributos Agregue flechas de navegabilidad a las asociaciones para indicar la dirección de la visibilidad de atributos Agregue las líneas de relaciones de dependencia para indicar la visibilidad no relacionada con los atributos

8 CREACIÓN de diagramas de clases del diseño
1. Identificación de las clases de software y su ilustración: 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. Podremos encontrarlas con solo examinar todos los diagramas de interacción, y listarlas: VentaLineadeProductos CAJA Venta CatalogodeProductos Tienda EspecificaciondeProductos Pago

9 CREACIÓN de diagramas de clases del diseño
El siguiente paso consiste en dibujar un diagrama de clases para estas, e incluir atributos y asociaciones del modelo conceptual. CAJA CatalogodeProductos cantidad EspecificaciodeProducto descripcion CUP Tienda direccion nombre Venta fecha estaterminada hora VentasLineadeProducto Cantidad Pago monto

10 CREACIÓN de diagramas de clases del diseño
2. Agregar los nombres de los métodos: Para identificar los métodos de las clases se analizan los Diagramas de Colaboración. 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.

11 CREACIÓN de diagramas de clases del diseño
Nombres de los Métodos tomados de los Diagramas de Colaboración / Interacción: Venta fecha estaTerminada hora hacerLineadeProducto() 3: hacerLineadeProducto(especif, cant) :CAJA :Venta

12 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() Total() VentaLineadeProducto Subtotal() Pago cantidad

13 CREACIÓN de diagramas de clases del diseño
3. Nombre de los métodos: Aspectos. Los siguientes aspectos especiales deben tenerse en cuenta con respecto a los nombres de los métodos: Interpretación de los mensajes Crear(). Descripción de los Métodos de Acceso. Interpretación de los mensajes dirigidos a multiobjetos. Sintaxis dependiente del estado.

14 CREACIÓN de diagramas de clases del diseño
4. Nombre de los métodos: Crear. El mensaje “Crear” es la forma en que, en UML, indicamos: instanciación e inicialización. 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. En Java invoca el operador new, seguido de la llamada al constructor. 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.

15 CREACIÓN de diagramas de clases del diseño
5. Nombres de los Métodos: Métodos de “Acceso”. Los Métodos de Acceso son aquellos que recuperan (Método Accesor) o establecen (Método Mutador) el valor de los atributos. 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).

16 CREACIÓN de diagramas de clases del diseño
6. Nombre de los Métodos: “Multiobjetos”. Un mensaje a un Multiobjeto se interpreta como si estuviera destinado al objeto contenedor/colección. 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.

17 CREACIÓN de diagramas de clases del diseño
Mensaje a Multiobjeto: 2.1 : especif := encontrar(cup) :CatalogodeProductos :EspecificaciondeProductos especif:=especificacion(cup) El mensaje encontrar está destinado al objeto contenedor, no a una EspecificaciondeProducto.

18 CREACIÓN de diagramas de clases del diseño
Por lo tanto el método “encontrar” no forma parte de la clase especificaciondeProducto. Estas clases contenedor/colección son clases predefinidas de las bibliotecas y rara vez sirve mostrarlas explícitamente en el Diagrama.

19 CREACIÓN de diagramas de clases del diseño
7. Nombre de los métodos: sintaxis dependiente del lenguaje Algunos lenguajes (Smalltalk) tienen una forma sintáctica para los métodos distinto al formato básico de: nombredelmetodo (listadeparametros). Recomendamos utilizar el formato básico de UML, aun cuando el lenguaje de implementaron planeada aplique otra sintaxis.

20 CREACIÓN de diagramas de clases del diseño
8. Agregar mas información sobre tipos: Es opcional mostrar el tipo de los atributos, los parámetros del método y los valores de devolver método. La cuestión de si debe incluirse o no esta información deberá considerares dentro del siguiente contexto:

21 CREACIÓN de diagramas de clases del diseño
El Diagrama de Clases Orientado al Diseño deberá elaborase teniendo en cuenta que: Si vamos a crearlo en una herramienta CASE con generación automática de código, se requerirán detalles completos. Si vamos a crearlo para que lo lean los diseñadores del software, el exceso de detalles puede influir negativamente.

22 CREACIÓN de diagramas de clases del diseño
Incorporación de Información sobre los “Tipos”: 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

23 CREACIÓN de diagramas de clases del diseño
9. Incorporación de asociaciones y de navegabilidad: 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”. 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. La navegabilidad significa visibilidad, generalmente visibilidad de atributo.

24 CREACIÓN de diagramas de clases del diseño
Descripción gráfica de la navegabilidad, o sea de la visibilidad de los atributos CAJA IntroducirProducto() TerminarVenta() EfectuarPago() Venta Fecha EstaTermin: Booleano hora Se termina() Total() Captura 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

25 CREACIÓN de diagramas de clases del diseño
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: A envía un mensaje a B A crea una instancia de B A necesita mantener una conexión con B 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:

26 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() total() VentaLineadeProducto cantidad Subtotal() Pago alberga 1 usa Mira-en * Registro terminados captura 1..* contiene describe Pagada_por Asociaciones con Símbolos de Navegabilidad:

27 CREACIÓN de diagramas de clases del diseño
10. Agregación de las “Relaciones de Dependencia”: 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. Se denota con una línea punteada y con flecha. 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.

28 CREACIÓN de diagramas de clases del diseño
En cambio, la visibilidad simple de atributos se indica con una flecha normal de asociación y con una flecha de navegabilidad. Por ejemplo, si en el ejercicio del punto de Venta, se prevé que CAJA 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. Así, CAJA puede tener una visibilidad de corto plazo localmente declarada en EspecificaciondeProducto.

29 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() total() VentaLineadeProducto cantidad Subtotal() Pago alberga 1 usa Mira-en * Registro terminados captura 1..* contiene describe Pagada_por Dependencia de CAJA que conoce sobre EspecificaciondeProducto Se recomienda cuando existe un parámetro y visibilidad global o declarada localmente Relaciones de dependencia que indican una visibilidad no relacionada con atributos