unidad 10 mad diagrama de clases

12 de abr de 2023 Sergio Sánchez Rios

Metodologías de Análisis y DiseñoUnidad VIII

Diseño O.O

“Diagrama de Clases”

Sergio Sánchez Rios.

Ingeniero en Informática – Licenciado en Informática

Docente Jornada Parcial Universidad Viña del Mar


Completando los diagramas de interacción, es posible identificar la especificación de las clases que participarán en la solución indicando detalles de su implementación, como por ejemplo los métodos .

Entradas de los Diagramas de Clases

Diagramas de interacción, a partir de ellos el diseñador identifica las clases de software y sus métodos.

Modelo conceptual, a partir de éste el diseñador agregar detalle a la definición de las clases.

Diagramas de ClasesIntroducción


Características

Un diagrama de clases (DCD) representa las especificaciones de las clases e interfaces de software (por ejemplo, las interfaces de java) en una aplicación. Entre la información general que entregan se encuentran:

Clases, asociaciones y atributos.

Interfaces con sus operaciones y constantes.

Métodos.

Información acerca del tipo de los atributos.

Navegabilidad.

Dependencias.

Diagramas de ClasesIntroducción


En el modelo de dominio, una Venta no representa una definición de software, sino que se trata de una abstracción de un concepto del mundo real acerca del cual estamos interesados en realizar una declaración. En cambio, los DCD expresan – para la aplicación de software – la definción de las clases como componentes de software.

Diagramas de ClasesModelo de Dominio v/s Modelo de Diseño


Ejemplo:

Registro Venta

Captura

1 1

.....FechaesCompleta: Booleanhora

Registro VentaCaptura

1 1FechaesCompleta: Booleanhora

finalizarVenta()introducirArticulo(..)realizarPago(..) crearLineaDeVenta(..)

Modelo de Dominio

Modelo de Diseño



Ejemplo:

Registro Venta

Captura

1 1

.....FechaesCompleta: Booleanhora

finalizarVenta()introducirArticulo(..)realizarPago(..) crearLineaDeVenta(..)

Un rectángulo con tres secciones para la definición de clase

Métodos: hay parámetros pero no se especifican.

Navegabilidad Información del tipo



El primer paso de los DCD como parte del modelo de la solución es identificar aquellas clases que participan en la solución software. Se pueden encontrar examinando todos los diagramas de interacción y listando las clases que se mencionan.

En la aplicación de Punto de Venta (primer ciclo) ellas son: Registro, CatalogoDeProductos, Tienda, Pago, Venta, EspecificaciónDelProducto, LineaDeVenta.

El siguiente paso es dibujar un diagrama de clases para estas clases e incluir los atributos que se identificaron previamente en el modelo del dominio que también se utilizan en el Diseño

Diagramas de ClasesIdentificación y representación de las clases de software


Ejemplo:

Registro

.....

.......

VentaFechaesCompletahora

.....

CatalogoDeProductos

.....

.......

EspecificacionDeProductosFechaesCompletahora

.....

Pago

cantidad

.......

Tienda

Direcciónnombre

.......

LineaDeVenta

cantidad

.......

Diagramas de ClasesIdentificación y representación de las clases de software


Se pueden identificar los nombres de los métodos analizando los diagramas de interacción.

:Registro :Venta

2: crearLineaVenta(espec,cant)

Venta

FechaesCompleta: Booleanhora

crearLineaDeVenta(..)

En general, el conjunto de todos los mensajes enviados a una clase X a lo largo de todos los diagramas de interacción indican la mayoría de los métodos que debe definir la clase X.

Diagramas de ClasesAñadir los nombres de los métodos


Ejemplo:

Registro

.....

FinalizarVenta()introduccirArticulo(..)crearNuevaVenta()realizarPago(..)

Venta

FechaesCompletahora

seHaCompletado()crearLineaDeVenta(...)realizarPago(..)getTotal()

CatalogoDeProductos

.....

getEspecificacion(...)


.....

Pago

cantidad

.......

Tienda

Direcciónnombre

añadirVenta(..)

LineaDeVenta

cantidad

getSubTotal()



Se deben tener en cuenta los siguientes aspectos especiales respecto a los nombres de los métodos.

Interpretación del mensaje create(): Por ser la inicialización una actividad muy común, se acostumbra a omitir los métodos de creación. Se supone por default.

Descripción de los métodos de acceso:

Son aquellos que establecen o recuperan el valor de los atributos.

Implican un accesor (métodos de obtención) y un mutador (métodos de cambio) para cada atributo.

Por su amplia utilización se omiten. Se suponen por defecto.



Se deben tener en cuenta los siguientes aspectos especiales respecto a los nombres de los métodos.

Interpretación de los mensajes dirigidos a multiobjetos: Un mensaje a un multiobjeto se interpreta como si estuviera destinado al objeto contenedor /colección.

:lineadeVenta:Venta

1*:st:=getSubTotal()

*

El mensaje getSubTotal() está destinado al objeto contenedor , no a una LineaDeVenta



Interpretación de los mensajes dirigidos a multiobjetos

Estas clases contenedor/colección son clases predefinidas de las bibliotecas, y rara vez sirve mostrarlas explícitamente en el diagrama respectivo porque incorpora ruido y aportan escasa información nueva.



Es opcional mostrar el tipo de los atributos, los parámetros del método y los valores de devolver método.

El diagrama de clases orientado al diseño debería elaborarse teniendo en cuenta la audiencia:

Si vamos a crearlo a una herramienta CASE con generación automática de código se requerirán detalles completos y exhaustivos.

Si vamos a crearlo para los diseñadores de software, el exceso de información puede influir negativamente en su efectiva comprensión.



Cada extremo de la asociación se denomina Rol, y en los DCD el Rol podría decorarse con una flecha de navegabilidad.

La navegabilidad es una propiedad del rol que indica que es posible navegar unidireccionalmente a través de la asociación desde los objetos de la clase origen a la clase destino.

La navegabilidad implica visibilidad – normalmente visibilidad de atributo.

Diagramas de ClasesIncorporación de asociaciones y navegabilidad


Ejemplo:

Registro Venta

Captura

1 1

VentaActual : VentaFechaesCompleta: Booleanhora

finalizarVenta()introducirArticulo(..)realizarPago(..)crearNuvaVenta()

crearLineaDeVenta(..)seHaCompletado()realizarPago(..)getTotal(..)

La flecha de navegabilidad indica que los objetos Registro están conectados unidireccionalmente con los objetos Venta

La ausencia de la flecha de navegabilidad indica que no hay conexiones desde la venta al Registro.

La clase Registro tendrá un atributo que referencia a un objeto

A menudo se excluye el atributo VentaActual puesto que se sobreentiende de acuerdo con la asociación navegable desde el Registro a la Venta



Como base es necesario definir una asociación con una flecha de navegabilidad de A a B cuando:

A envía un mensaje a B.

A crea una instancia de B.

A necesita mantener una conexión con B.



La mayoría, por no decir todas, las asociaciones en los DCD deberían adornarse con las flechas de navegabilidad necesarias.

Registra

Registro

.....


Venta

FechaesCompletahora


CatalogoDeProductos

.....



.....

Pago

cantidad

.......

Tienda

Direcciónnombre

añadirVenta(..)

LineaDeVenta

cantidad

getSubTotal()

Utiliza

1 1

Busca-en

1

1

1 1..+

1

*

1..*

1

1.1

1

1

Contiene

Contiene

Pagada-Mediante

Alberga

11

Captura

1

*Describe



UML incluye una relación de dependencia general, que indica que un elemento (de cualquier tipo, como clases, casos de uso, etc.) tiene conocimiento de otro elemento. Se representa mediante una flecha de línea punteada.

En los diagramas de clase la relación de dependencia es útil para describir la visibilidad entre clases que no es de atributo; en otras palabras, la declaración de visibilidad de parámetros, local y global.

Por ejemplo, el objeto de software Registro recibe un objeto de retorno de tipo EspecificaciónDelProducto a partir del mensaje de especificación que envía al CatalogoDeProductos. El registro tiene una visibilidad local de la EspecificacionDeProducto.

Diagramas de ClasesAñadir relaciones de dependencia


Ejemplo

Registra

Registro

.....


Venta

FechaesCompletahora


CatalogoDeProductos

.....



.....

Pago

cantidad

.......

Tienda

Direcciónnombre

añadirVenta(..)

LineaDeVenta

cantidad

getSubTotal()

Utiliza

1 1

Busca-en

1

1

1 1..+

1

*

1..*

1

1.1

1

1

Contiene

Contiene

Pagada-Mediante

Alberga

11

Captura

1

*Describe

Diagramas de ClasesAñadir relaciones de dependencia


Implica “asignar el mismo nombre a servicios en varios objetos”, cuando los servicios se parecen o están relacionados entre ellos.

Situación

PagoconCheque PagoconTarjeta PagoenEfectivo

Monto Ofrecido

PagoconCheque

monto

¿Quién es responsable de autorizar cada tipo de pago?

Patrones Adicionales Polimorfismo


Nombre Polimorfismo

Problema ¿Cómo manejar las alternativas basadas en el tipo?

La variación condicional es un tema esencial en la programación. Si se diseña un programa mediante la lógica condicional if– then-else o case, habra que modificar la lógica del case cuando surja una variante. Este procedimiento dificulta extender un programa con otras variantes, porque los cambios tienden a requerirse en varios lugares donde exista la lógica condicional.

Solución Cuando por el tipo varían las alternativas o comportamientos afines, las responsabilidades del comportamiento se asignarán – mediante operaciones poliformicas – a los tipos en que el comportamiento presenta variantes.



Observaciones El patrón polimorfismo es concordante con el espíritu del patrón Experto.

Es un principio fundamental en que se fundan las estrategias globales al diseñar cómo organizar un sistema para que se encargue del trabajo.

Beneficios Es fácil agregar las futuras extensiones que requieren las variaciones imprevistas.



Ejemplo:

En la aplicación del punto de venta, ¿quién debería encargarse de autorizar las diversas clases de pagos?.

El comportamiento de autorización varía con el tipo de pago –en efectivo, con tarjeta o con cheque; por eso, conforme al polimorfismo deberiamos asignar esa responsabilidad a cada tipo de pago, implementado con una aplicación polimorfica autorizada.



Ejemplo:

PagoconCheque

Autorizar()

PagoconTarjeta

Autorizar()

PagoenEfectivo

Monto Ofrecido

Autorizar()

PagoconCheque

monto

Según el polimorfismo cada tipo de pago debe autorizarse a si mismo.



Situación

Supongamos, que se necesita soporte para guardar las instancias venta en una base de datos relacional.

En virtud del patrón Experto, en cierto modo se justifica asignar responsabilidades a la clase Venta.

Observaciones

La tarea requiere un número relativamente amplio de operaciones de soporte orientadas a la base de dato, ninguna de las cuales se relaciona con el concepto de Vender.

La clase venta a de acoplarse a la interfaz de la base de datos relacional.

Patrones Adicionales Fabricación Pura


Observaciones

Guarda los objetos en una base de datos relacional es una tarea muy general en que debemos brindar mucho soporte.

Por lo tanto, está asignación aumenta el acoplamiento y la cohesión de clase Venta.



Nombre Fabricación Pura

Problema ¿A quién asignar la responsabilidad cuando está desesperado y no quiere violar los patrones de alta cohesión y Bajo Acoplamiento?

Los diseños O.O se caracterizan por implementar como clases de software las representaciones de conceptos en el dominio de un problema del mundo real; por ejemplo, una Venta y Cliente.

Pese a ello se dan muchas situaciones donde asignar responsabilidades exclusivamente a las clases del dominio origina problemas por una mala cohesión o acoplamiento o bien por un escaso potencial de reutilización.

Solución Asignar un conjunto altamente cohesivo de responsabilidades a una clase artificial que no representa nada en el dominio del problema: una cosa inventada para dar soporte a una alta cohesión, un bajo acoplamiento y reutilización.

La razón exclusiva para la incorporación de la clase artificial es por tanto una decisión de “fabricación pura”.



Observaciones -Para diseñar una Fabricación Pura debe buscarse ante todo un gran potencial de reutilización, asegurándose para ello de que sus responsabilidades sean pequeñas y cohesivas.

-Estas clases tienen a tener un conjunto de responsabilidades de granularidad fina.

- Una fabricación pura suele partirse atendiendo a su funcionalidad y, por lo mismo, es una especie de objeto de función central.

Beneficios Alta cohesión y alto nivel de reutilización

Desventajas Puede perderse el espíritu de los buenos diseños O.O que se centran en los objetos y no en las funciones.

Si se abusa de ello, la creación de clases de Fabricación Pura, originará un diseño centrado en procesos o funciones que se implementa en un O.O.



Ejemplo:

Supongamos, por ejemplo, que se necesita soporte para guardar las instancias Venta en una base de datos relacional.

Si se utiliza el patrón Experto (Venta sería el candidato lógico) se daría origen a un diseño de baja cohesión, alto acoplamiento y bajo potencial de reutilización.

Una solución razonable consiste en crear una clase nueva que se encargue tan solo de guardar los objetos de algún tipo de almacenamiento persistente: una base de datos relacional.

AgentedeAlmacenamientoPersistente

Guardar()

Según la Fabricación Pura



Situación

Dos componentes o servicios de un sistema se encuentran acoplados directamente.

Nombre Inderección

Problema ¿A quién se asignaran las responsabilidades a fin de evitar el acoplamiento directo? ¿De qué, manera se desacoplan los objetos de modo que se obtenga un bajo acoplamiento y se conserve un alto potencial de reutilización?

Solución Se asigna la responsabilidad a un objeto intermedio para que medie entre otros componentes o servicios, y éstos no terminen directamente acoplados. El intermediario crea una indirección entre el resto de los componentes o servicios.

Patrones Adicionales Indirección


Ejemplo 1:

En el ejemplo anterior (Fabricación pura) para desacoplar la Venta y los servicios de la base de datos relacional en el cual se introduce la clase AgentedeAlmacenamientoPersistente tambien es un ejemplo de Indirección. La case AgentedeAlmacenamientoPersistente sirve de intermediario entre la Venta y la Base de datos.

Ejemplo 2 : Patrón Publicar-Suscribir u Observar.

Los objetos se suscriben a eventos ante un AdministradordeEventos; otros publican eventos para el AdministradordeEventos, que los notifica a los suscriptores.

A través de la indirección del AdministradordeEventos se desacoplan los editores y los suscriptores.

Patrones Adicionales Indirección


Nombre No hables con extraños

Problema ¿Cómo asignar responsabilidades para evitar conocer la estructura de objetos indirectos?

Si un objeto cliente tiene que usar un servicio u obtener información a partir de un objeto indirecto, ¿cómo podrá hacerlo sin acoplarse al conocimiento de la estructura interna de su servidor directo o de los objetos indirectos?.

Solución Se asigna la responsabilidad a un objeto directo del cliente para que colabore con un objeto indirecto, de modo que el cliente no necesite saber nada del objeto indirecto.

Esto impone restricciones sobre los objetos a los cuales deberíamos enviar mensajes. Dentro de un método los mensajes sólo pueden ser enviados: El mismo objeto, Un parámetro del método, un atributo, un elemento de una colección que sea atributo de él, un objeto creado en el interior del método.

Patrones Adicionales No hables con extraños


Solución Esto permite que los objetos (cliente) que requieren información de objetos indirectos eviten hablar con extraños “objetos indirectos”, al apoyarse en objetos directos que le permiten obtener dicha información.

Observaciones -No hables con extraños se refiere a no obtener una visibilidad temporal frente a objetos indirectos, que son de conocimiento de otros objetos pero no del cliente.

-La desventaja de conseguir visibilidad ante extraños es la siguiente:

La solución se acopla entonces a la estructura interna de otros objetos. Ello origina un alto acoplamiento.



Ejemplo :

En una aplicación del punto de venta, suponga que una instancia TPDV posee un atributo referente a una Venta, la cual cuenta con un atributo referente a un Pago.

La instancias TPDV soportan la operación montodePago, que devuelve el actual monto ofrecido como pago.

Las instancia Venta soporta la operación pago, la cual devuelve la instancia Pago asociada a la Venta



Ejemplo :

TPDV

terminarVenta()introduccirProducto()

efectuarPago()montodePago()

Venta

Fecha: FechaHora :Hora

estaTerminada:BooleanTotal()

hacerLineadeProducto()efectuarPago()

seTErmino()Pago()

Pago

Monto : Entero

montoOfrecido()

Captura Pagado-Por

:TPDV :Venta

pag:Pago

montodePago()

2: imp:=montoOfrecido() : Float

1: pag: = pago(): Pago

TPDV::MontoPago(){pag: e_venta -> pago()

//viola “No hables con extraños”Return pag->montoOfrecido();}

Está forma viola el patrón



Ejemplo :

La solución, como lo indica el patrón, consiste en agregar la responsabilidad al objeto directo – la Venta, en este caso – para que devuelva a TPDV el monto del pago.

Por lo tanto se agrega una operación montodePago para que TPDV no tenga que hablar con extraños.

:TPDV :Venta

pag:Pago

montodePago()

2: imp:=montoOfrecido() : Float

1: imp: = montodePago()

TPDV::MontoPago(){pag: e_venta -> montodepago()}

A Venta se le agrega la operación

montodePago()



Guía del Tópico:

Software Engineering 6a. ed.– Ian Sommerville – Pearson Education – 2000. (Cap. 6)Ingeniería de Software Teoría y Práctica – Shari Lawrence Pfleeger – Pearson Education – 2002.Utilización de UML en ingeniería del software con objetos y componentes – Perdita Stevens & Rob Pooley – Addison Wesley – 2002. UML y Patrones una introducción al análisis y diseño orientados a objeto y al proceso unificado – Craig Larman – Prentice Hall - 2002.

Bibliografía

unidad 10 mad diagrama de clases

Documents