View
4.731
Download
2
Category
Preview:
Citation preview
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
12 de abr de 2023 Sergio Sánchez Rios
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
12 de abr de 2023 Sergio Sánchez Rios
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
12 de abr de 2023 Sergio Sánchez Rios
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
12 de abr de 2023 Sergio Sánchez Rios
Ejemplo:
Registro Venta
Captura
1 1
.....FechaesCompleta: Booleanhora
Registro VentaCaptura
1 1FechaesCompleta: Booleanhora
finalizarVenta()introducirArticulo(..)realizarPago(..) crearLineaDeVenta(..)
Modelo de Dominio
Modelo de Diseño
Diagramas de ClasesModelo de Dominio v/s Modelo de Diseño
12 de abr de 2023 Sergio Sánchez Rios
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
Diagramas de ClasesModelo de Dominio v/s Modelo de Diseño
12 de abr de 2023 Sergio Sánchez Rios
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
12 de abr de 2023 Sergio Sánchez Rios
Ejemplo:
Registro
.....
.......
VentaFechaesCompletahora
.....
CatalogoDeProductos
.....
.......
EspecificacionDeProductosFechaesCompletahora
.....
Pago
cantidad
.......
Tienda
Direcciónnombre
.......
LineaDeVenta
cantidad
.......
Diagramas de ClasesIdentificación y representación de las clases de software
12 de abr de 2023 Sergio Sánchez Rios
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
12 de abr de 2023 Sergio Sánchez Rios
Ejemplo:
Registro
.....
FinalizarVenta()introduccirArticulo(..)crearNuevaVenta()realizarPago(..)
Venta
FechaesCompletahora
seHaCompletado()crearLineaDeVenta(...)realizarPago(..)getTotal()
CatalogoDeProductos
.....
getEspecificacion(...)
EspecificacionDeProductosFechaesCompletahora
.....
Pago
cantidad
.......
Tienda
Direcciónnombre
añadirVenta(..)
LineaDeVenta
cantidad
getSubTotal()
Diagramas de ClasesAñadir los nombres de los métodos
12 de abr de 2023 Sergio Sánchez Rios
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.
Diagramas de ClasesAñadir los nombres de los métodos
12 de abr de 2023 Sergio Sánchez Rios
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
Diagramas de ClasesAñadir los nombres de los métodos
12 de abr de 2023 Sergio Sánchez Rios
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.
Diagramas de ClasesAñadir los nombres de los métodos
12 de abr de 2023 Sergio Sánchez Rios
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.
Diagramas de ClasesAñadir los nombres de los métodos
12 de abr de 2023 Sergio Sánchez Rios
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
12 de abr de 2023 Sergio Sánchez Rios
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
Diagramas de ClasesIncorporación de asociaciones y navegabilidad
12 de abr de 2023 Sergio Sánchez Rios
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.
Diagramas de ClasesIncorporación de asociaciones y navegabilidad
12 de abr de 2023 Sergio Sánchez Rios
La mayoría, por no decir todas, las asociaciones en los DCD deberían adornarse con las flechas de navegabilidad necesarias.
Registra
Registro
.....
FinalizarVenta()introduccirArticulo(..)crearNuevaVenta()realizarPago(..)
Venta
FechaesCompletahora
seHaCompletado()crearLineaDeVenta(...)realizarPago(..)getTotal()
CatalogoDeProductos
.....
getEspecificacion(...)
EspecificacionDeProductosFechaesCompletahora
.....
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 ClasesIncorporación de asociaciones y navegabilidad
12 de abr de 2023 Sergio Sánchez Rios
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
12 de abr de 2023 Sergio Sánchez Rios
Ejemplo
Registra
Registro
.....
FinalizarVenta()introduccirArticulo(..)crearNuevaVenta()realizarPago(..)
Venta
FechaesCompletahora
seHaCompletado()crearLineaDeVenta(...)realizarPago(..)getTotal()
CatalogoDeProductos
.....
getEspecificacion(...)
EspecificacionDeProductosFechaesCompletahora
.....
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
12 de abr de 2023 Sergio Sánchez Rios
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
12 de abr de 2023 Sergio Sánchez Rios
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.
Patrones Adicionales Polimorfismo
12 de abr de 2023 Sergio Sánchez Rios
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.
Patrones Adicionales Polimorfismo
12 de abr de 2023 Sergio Sánchez Rios
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.
Patrones Adicionales Polimorfismo
12 de abr de 2023 Sergio Sánchez Rios
Ejemplo:
PagoconCheque
Autorizar()
PagoconTarjeta
Autorizar()
PagoenEfectivo
Monto Ofrecido
Autorizar()
PagoconCheque
monto
Según el polimorfismo cada tipo de pago debe autorizarse a si mismo.
Patrones Adicionales Polimorfismo
12 de abr de 2023 Sergio Sánchez Rios
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
12 de abr de 2023 Sergio Sánchez Rios
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.
Patrones Adicionales Fabricación Pura
12 de abr de 2023 Sergio Sánchez Rios
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”.
Patrones Adicionales Fabricación Pura
12 de abr de 2023 Sergio Sánchez Rios
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.
Patrones Adicionales Fabricación Pura
12 de abr de 2023 Sergio Sánchez Rios
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
Patrones Adicionales Fabricación Pura
12 de abr de 2023 Sergio Sánchez Rios
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
12 de abr de 2023 Sergio Sánchez Rios
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
12 de abr de 2023 Sergio Sánchez Rios
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
12 de abr de 2023 Sergio Sánchez Rios
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.
Patrones Adicionales No hables con extraños
12 de abr de 2023 Sergio Sánchez Rios
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
Patrones Adicionales No hables con extraños
12 de abr de 2023 Sergio Sánchez Rios
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
Patrones Adicionales No hables con extraños
12 de abr de 2023 Sergio Sánchez Rios
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()
Patrones Adicionales No hables con extraños
12 de abr de 2023 Sergio Sánchez Rios
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
Recommended