A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013

Transcripción

1 3.3: Realización de diagramas de secuencia: capas software y patrones GRASP A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013

2 3.3.- Cómo realizar los diagramas de 30 secuencia a partir de los flujos de eventos de casos de uso? Caso de Uso : ACTOR Flujo de Eventos -Actor proporciona -El sistema Flujo de Eventos Alternativo -Si ocurre X : ACTOR.?

3 Cómo realizar los diagramas de secuencia a partir de los flujos de eventos de casos de uso? : ACTOR Caso de Uso Flujo de Eventos -Actor proporciona -El sistema Flujo de Eventos Alternativo -Si ocurre X Usando PATRONES de DISEÑO : ACTOR Aplicando una ARQUITECTURA SOFTWARE en varios niveles/capas.? SOFTWARE en varios

4 Realización de diagramas de secuencia Diseñaremos un diagrama de secuencia a partir del flujo de eventos del caso de uso Tomar Préstamo Copia Libro (TPCL) aplicando una arquitectura software en varios niveles diferenciando los niveles/capas de presentación (interacción con el usuario), lógica del negocio o acceso a datos. aplicando patrones GRASP cuando lo consideremos necesario

5 CU: Tomar Préstamo Copia Libro Tomar Préstamo Copia Libro - No disponible <<extends>> Reservar Libro Socio Flujo de eventos: El socio proporciona p su número de socio y la signatura del libro que quiere tomar en préstamo El sistema comprueba si existe alguna copia no prestada de dicho libro Si no hay copias disponibles: EXTENDS RESERVAR LIBRO Se comprueba que el socio no se pasa de su número máximo ái de libros en préstamo ét Se registra el nuevo préstamo con la fecha actual

6 Modelo del Dominio LIBRO signatura, título, autores, editorial, perpréstamo, fechapublicación,... reserva 1 escopiade 0..* CATÁLOGO * sucopia COPIA_LIBRO numcopia estado: {disp,prest,reser} 0..* 0..* REVISTA título, volumen, número, editorial, fechapublicación,... reservadopor 0..* tomaenpréstamo prestadaa tomóenpréstamo fueprestadaa 0..* 0..* PRÉSTAMO_CL fechaprest HISTÓRICO_CL fechaini, fechafin tomaenpréstamo prestadaa tomóenpréstamo fueprestadaa SOCIO dni, numsocio, nombre, dirección, teléfono, nummaxprest... TRABAJADOR numsegsocial categoría: {trab, encargado} PRÉSTAMO_RV fechaprest HISTÓRICO_REV fechaini, fechafin

7 Capas lógicas en el software: Presentación, lógica del negocio y acceso a datos En los flujos de eventos hay acciones de diferente naturaleza o relacionadas con el/la: Presentación interfaces de usuario y la interacción ió con el mismo Lógica del negocio resolver los problemas del negocio implementar las reglas propias del negocio Acceso a datos Recuperar, insertar, actualizar y borrar objetos del dominio Se dará persistencia a los objetos del modelo del dominio utilizando una BDOO

8 EJ: CU: Tomar Préstamo Copia Libro Socio Tomar Préstamo Copia Libro <<extends>> - No disponible Reservar Libro PRESENTACIÓN LÓGICA DEL NEGOCIO ACCESO A DATOS Flujo de eventos: El socio proporciona su número de socio y la signatura del libro que quiere tomar en préstamo El sistema comprueba si existe alguna copia no prestada de dicho libro. Si no hay copias disponibles/ copias disponibles EXTENDS RESERVAR LIBRO Se comprueba que el socio no se pasa de su número máximo de libros en préstamo Se registra el nuevo préstamo con la fecha actual

9 Patrones de responsabilidad GRASP Patrón CONTROLADOR Patrón EXPERTO Patrón CREADOR Patrón BAJO ACOPLAMIENTO Patrón ALTA COHESIÓN

10 Qué es un patrón? Un PATRÓN es una SOLUCIÓN para un PROBLEMA que se repite Idea propuesta en 1979 por Christopher Alexander, profesor de arquitectura "Cada patrón describe un problema que ocurre ifiiddd infinidad de veces en nuestro entorno, así como la solución al mismo, de tal modo que podemos utilizar esta solución un millón de veces más adelante sin tener que volver a pensarla otra vez. "

11 Qué es un patrón de diseño? La idea de PATRÓN aplicada al DESARROLLO SOFTWARE Un PATRÓN de DISEÑO es una SOLUCIÓN a un PROBLEMA de DISEÑO Un patrón debe ser EFECTIVO: ha servido para resolver problemas similares REUTILIZABLE: aplicable a diferentes problemas de diseño

12 Patrones GRASP GRASP: General l Responsibility Assignment i Software Patterns Los patrones GRASP describen los principios i i fundamentales del diseño de objetos y sus responsabilidades d GRASP: significa entender, comprender El nombre GRASP sugiere la importancia de COMPRENDER (GRASP) los principios fundamentales para diseñar software orientado a objetos de manera correcta Los 5 primeros r patrones GRASP son: EXPERTO, CREADOR, ALTA COHESIÓN, BAJO ACOPLAMIENTO y CONTROLADOR

13 Cómo se representa la interfaz de usuario en un diagrama de secuencia? Se define un objeto de una clase INTERFAZ (también llamada clase FRONTERA) que está especializada en comunicarse con el ACTOR (sabe aceptar eventos de entrada del usuario y mostrar resultados de salida) Ese objeto representará a una interfaz de usuario gráfico habitualmente (interfaz AWT/Swing, página HTML, JSP, ASP.NET, ) Los objetos de clases INTERFAZ/FRONTERA son los Los objetos de clases INTERFAZ/FRONTERA son los que implementan la capa/nivel de PRESENTACIÓN

14 Diagrama de secuencia TPCL (1) : ACTOR 1: dar código libro obj1: IU_CU_TPCL 2: dar código socio 3: pulsar botón 4: A qué MÉTODO de qué OBJETO debe llamar? Invocación a la LÓGICA DEL NEGOCIO

15 Invocación a Lógica del Negocio Patrón CONTROLADOR Nombre: CONTROLADOR PROBLEMA: A quién se le asigna la responsabilidad de recibir o manejar eventos de entrada al sistema? [Un evento de entrada al sistema es un evento generado por un actor externo, que se asocia con una operación del sistema.] SOLUCIÓN: A un objeto (clase) que representa al sistema global, dispositivo o subsistema. Es un único OBJETO para todo el sistema donde se colocan TODAS LAS OPERACIONES DEL SISTEMA. También se suele llamar objeto FACADE (o FACHADA). El CONTROLADOR es el que ofrecerá las q operaciones de la LÓGICA DEL NEGOCIO

16 Diagrama de secuencia TPCL (2) : ACTOR 1: dar código libro lib :Controlador_ obj1: IU_CU_TPCL LogNegocio 2: dar código socio soc 3: pulsar 5: A quién enviar botón 4:tomarPrestamo(lib,soc) esa petición? Controlador_LogNegocio tomarprestamo(lib:int, soc:int)

17 Acceso al nivel de datos / objetos del modelo del dominio A quién le pide el controlador la ejecución de esa operación, en quién delega? Qué objeto/s puede/n ejecutar esa operación? Qué necesita hacer el método? ENCONTRAR ALGÚN DATO/INFORMACIÓN (Patrón EXPERTO) CREAR NUEVOS OBJETOS (Patrón CREADOR) El CONTROLADOR de la LÓGICA del NEGOCIO El CONTROLADOR de la LÓGICA del NEGOCIO puede necesitar acceder al nivel o capa de DATOS

18 Patrón EXPERTO Nombre: EXPERTO PROBLEMA: : A quién se le pide pdeque busque un determinado dato o genere información? SOLUCIÓN: Al objeto (clase clase) que cuenta con los datos o información necesaria COMPRA fecha, código 1 A quién se le pide el total de la compra? 1..* LÍNEA_COMPRA cantidad d * 1 PRODUCTO valor, descripción NOTA IMPORTANTE: si es un objeto del dominio hay que NOTA IMPORTANTE: si es un objeto del dominio, hay que asegurarse de que se encuentra cargado en la memoria principal. En ese caso, ese objeto del dominio sería el EXPERTO.

19 Acceso al nivel de datos para cargar los objetos dl del dominio i Los objetos del dominio que queramos invocar deben estar cargados en la memoria principal. Lo haremos usando un objeto de una clase (AccesoBD) que será: 1) :AccesoBD experto en acceder a la BDOO, o bien 2) controlador de la BDOO c=getcompra(codc1) porque también se encargará de las operaciones de inserción, borrado y modificación, además de las operaciones de recuperación. insertarcompra(codc2)

20 Ejemplo de aplicación de patrón EXPERTO El sistema comprueba si hay alguna copia libre de ese libro Qué objeto puede saber si hay alguna copia libre del libro con la signatura proporcionada? El OBJETO de la clase LIBRO Pero no está cargado en la memoria principal! No sabemos su referencia!

21 Ejemplo de aplicación de patrón EXPERTO Se comprueba que el socio no se pasa de su número máximo de libros en préstamo Qué objeto puede saber si el socio con el número de socio proporcionado p no se pasa de su número máximo de préstamos? El OBJETO de la clase SOCIO Pero no está cargado en la memoria principal! No sabemos su referencia!

22 Ejemplo de aplicación de patrón EXPERTO/CONTROLADOR Qué objeto puede obtener el objeto LIBRO y el objeto SOCIO, conocidas la signatura y el número de socio? El OBJETO que gestiona la BASE de DATOS (AccesoBD)

23 Diagrama de secuencia TPCL (3) : ACTOR obj1: IU_CU_TPCL 1: dar código libro lib 2: dar código socio soc :Controlador_ LogNegocio :AccesoBD 3: pulsar botón 4:tomarPrestamo(lib,soc) 5:l=getLibro(lib) 6:s=getSocio(soc)

24 Diagrama de secuencia TPCL (4) : ACTOR 1: dar código libro lib 2: dar código socio soc obj1: IU_CU_TPCL :Controlador_ LogNegocio :AccesoBD l: Libro s: Socio 3: pulsar botón 4:tomarPrestamo (lib,soc) 5:l=getLibro(lib) 6:s=getSocio(soc) 7:clibre=getCopiaLibre() [hay clibre] 8: max=ismaximo() [max] 9: newprestamo(clibre, s)???

25 Patrón CREADOR Nombre: CREADOR PROBLEMA: Quién debe crear los objetos de una clase A? SOLUCIÓN: Esa responsabilidad se le añadirá a la clase B si se cumple alguna de estas condiciones: La clase B guarda los objetos de la clase A La clase B está formada por objetos de A (AGREGACIÓN/COMPOSICIÓN) GA Ó Cuando hay que crear un objeto de A, B tiene todos los datos de inicialización necesarios (B es un EXPERTO en la creación de A)

26 Patrón CREADOR COMPRA fecha, código 1 Quién crea los objetos de Línea_compra que se guardan en Compra (o que forman la compra)? 1..* LÍNEA_COMPRA cantidad * 1 PRODUCTO valor, descripción

27 Ejemplo de aplicación de patrón CREADOR Se registra el nuevo préstamo con la fecha actual Qué objeto guarda los préstamos? El objeto de la clase SOCIO Nota: también podría ser el objeto de la clase COPIA_LIBRO

28 Diagrama de secuencia TPCL (5) : ACTOR 1: dar código libro lib 2: dar código socio soc obj1: IU_CU_TPCL 3: pulsar botón 4:tomarPrestamo (lib,soc) :Controlador_ LogNegocio 5:l=getLibro(lib) 6:s=getSocio(soc) :AccesoBD l: Libro s: Socio 7:clibre=getCopiaLibre() [hay clibre] 8: max=ismaximo() [max] 9: newprestamo(clibre) : Prestamo 10: new()

29 Ejemplo de aplicación de patrón CREADOR (continuación) Se registra el nuevo préstamo con la fecha actual Qué objeto guarda los préstamos? El objeto de la clase SOCIO Pero el objeto de AccesoBD también, ya que debe dar persistencia al nuevo préstamo!!!!

30 Diagrama de secuencia TPCL (6) (alternativa 1) : ACTOR 1: dar código libro lib 2: dar código socio soc obj1: IU_CU_TPCL 3: pulsar botón 4:tomarPrestamo (lib,soc) :Controlador_ LogNegocio 5:l=getLibro(lib) 6:s=getSocio(soc) :AccesoBD l: Libro s: Socio 7:clibre=getCopiaLibre() [hay clibre] 8: max=ismaximo() [max] 9: p=newprestamo(clibre) 11: store(p) p: Prestamo 10: new()

31 Diagrama de secuencia TPCL (6) (alternativa 2) : ACTOR 1: dar código libro lib 2: dar código socio soc obj1: IU_CU_TPCL 3: pulsar botón 4:tomarPrestamo (lib,soc) :Controlador_ LogNegocio 5:l=getLibro(lib) 6:s=getSocio(soc) :AccesoBD l: Libro s: Socio 7:clibre=getCopiaLibre() store(p) [hay clibre] 8: max=ismaximo() 10: newprestamo(clibre) [no max] 9: newprestamo(clibre, s) p: Prestamo 11: new()

32 Qué alternativa de diseño escoger? :Controlador_ LogNegocio [no max] 9: newprestamo(clibre) s: Socio (l (alternativa 1) p: Prestamo_CL :AccesoBD 10: new() 11: store(p) store(p) :Controlador_ LogNegocio :AccesoBD s: Socio [no max] 9: newprestamo(clibre, s) (alternativa 2) 10: newprestamo(clibre) store(p) p: Prestamo 11: new()

33 Patrón BAJO ACOPLAMIENTO Nombre: BAJO ACOPLAMIENTO PROBLEMA: Cómo reducir las dependencias d entre clases? SOLUCIÓN: Asignar la responsabilidad de manera que el acoplamiento permanezca bajo Existe acoplamiento entreaybsi A usa B (A tiene atributo del tipo B, o bien un método que usa o devuelve B, )

34 Ejemplo: BAJO ACOPLAMIENTO (1) (2) El diseño (2) tiene acoplamiento más bajo: - En ambos Venta está acoplada a Pago - En (1) TPV está acoplada a Pago y a Venta - En (2) TPV está acoplada a Venta, pero no a Pago! Nota: el nivel de acoplamiento no se puede considerar de manera Nota: el nivel de acoplamiento no se puede considerar de manera aislada a otros patrones como el EXPERTO y el ALTA COHESIÓN

35 Patrón ALTA COHESIÓN Nombre: ALTA COHESIÓN PROBLEMA: Cuánto Cá estánrelacionadas las responsabilidades de una clase? Cómo mantener la complejidad manejable? SOLUCIÓN: Asignar una responsabilidad de manera que la cohesión permanezca alta. Una clase tiene baja cohesión, si es una clase que tiene muchas responsabilidades no relacionadas, que hace demasiado trabajo, que no delega. Son clases difíciles de entender, reutilizar, mantener,

36 Ejemplo: ALTA COHESIÓN (1) (2) El diseño (1) tiene una cohesión más baja: - Tiene una clase (TPV) que se encarga de crear el Pago, no ha delegado la creación del Pago en Venta. Nota: el nivel de cohesión no se puede considerar de manera aislada Nota: el nivel de cohesión no se puede considerar de manera aislada a otros patrones como el EXPERTO y el BAJO ACOPLAMIENTO

37 Qué alternativa escoger? (1) Teniendo en cuenta únicamente los patrones ALTA COHESIÓN /BAJO ACOPLAMIENTO parece que la mejor alternativa es la (2) Sin embargo, conviene tener en cuenta quién tiene la responsabilidad de proporcionar p la PERSISTENCIA DE OBJETOS

38 Qué alternativa escoger? (2) La alternativa (1) sería más interesante si quisiéramos que el nivel de ACCESO A DATOS no conociera las CLASES PROVINIENTES DEL MODELO DEL DOMINIO, que simplemente recuperara o diera persistencia a objetos. En ese caso la cohesión de la clase AccesoBD sería mayor, ya que tendría dí menos responsabilidades, pero la cohesión de la clase ControladorLogNegocio sería menor ya que tendría que ocuparse también de la persistencia de los objetos (pidiéndoselo a AccesoBD) La alternativa (2) sería más interesante si quisiéramos que el nivel de ACCESO A DATOS conociera el MODELO DEL DOMINIO, y fuera un experto en RECUPERAR, INSERTAR ACTUALIZAR y BORRAR objetos de la BD). La cohesión de la clase AccesoBD sería menor, ya que tendría más responsabilidades, pero a cambio, la cohesión del controlador aumentaría, ya que las operaciones que implicaran actualizar, insertar, borrar y algunas de las de recuperar en la BD se las pediría a la clase AccesoBD y no a las clases del dominio.

39 Decisión de diseño para el Acceso a Datos Cualquier operación que IMPLIQUE un ACCESO a la BD (RECUPERACIÓN, INSERCIÓN, ACTUALIZADO O BORRADO de un objeto de la BD) se enviará al objeto de la clase ACCESOBD, que será la EXPERTA en comunicación con el SGBDOO. Solamente cuando el controlador de la lógica del negocio conozca la referenciaexacta exacta dl del objeto dld del dominioal i que quiera preguntar (no modificar, insertar o borrar) podrá solicitarle i l la ejecución de algúnmétodo lú :Controlador_ LogNegocio g :AccesoBD (alternativa 2) s: Socio [no max] 9: newprestamo(clibre, s) 10: newprestamo(clibre) store(p) p: Prestamo 11: new()

40 Diagrama de clases para el caso de uso Era la clase IU_CU_TPCL en el diagrama de secuencia Era la clase Acceso BD en el diagrama de secuencia com.db4o.* <<JFrame>> TomarPrestamoCopia +gestorlibro: GestorLibro <<Interfaz Remota RMI>> uses GestorLibro uses Libro +setlogicanegocio(gestorlibro) +tomarprestamo(numsocio, sign) +Copia getcopialibre(socio s) Copia DB4o ServidorGestorBiblioBDOO +tomarprestamo(numsocio, sign) uses +abrirbd() +void cerrarbd() +inicializarbd() +Libro getlibro(string i sign) +Socio getsocio(int ns) +void newprestamo(socio s, Copia c) Reserva Prestamo Era la clase Controlador_ LogNegocio g en el diagrama de secuencia Socio +boolean hasreservadisponible(libro l) +boolean ismaximo()