Unidad 2E Metodologia Con POO

7/23/2019 Unidad 2E Metodologia Con POO

1/41

1

Unidad IIDiseo de Solucin

Diseo de Objetos conResponsabilidad

Parte 5


2/41

2

Patrones GRASPSon patrones de principios generales para asignar

responsabilidades

Los primeros cinco patrones son:

Experto en Informacin (Experto)Creador

Alta Cohesin

Bajo AcoplamientoControlador


3/41

3

Patrn: Experto

(Experto en Informacin)Problema: Cul es el principio general para

asignar responsabilidades a los objetos?

Solucin: asignar una responsabilidad al expertoen la informacin, es decir, la clase que tiene lainformacin necesaria para realizar esa

responsabilidad


4/41

4

Patrn: Experto

Ejemplo de AplicacinResponsabilidad:Conocer el total de la venta

1. Iniciar la asignacin de responsabilidadesestableciendo claramente la responsabilidad

Quin debera ser el responsable de conocer el

total de una venta?2. Determinar que informacin se necesita para

determinar el total

1. Conocer todas las instancias de LineaDeVenta2. Sumar los subtotales de cada lnea de venta


5/41

5

Patrn: Experto

Ejemplo de Aplicacin3. Siguiendo el patrn Experto en informacin

buscar las clases de objetos que contengan lainformacin necesaria para determinar el total

Observar el Modelo del Dominio o el Modelo deDiseoSi hay clases relevantes en el Modelo de Diseo,observar primero ah

Sino, observar el Modelo del Dominio


6/41

6

Patrn: Experto

Ejemplo de AplicacinAl iniciar el trabajo de diseo, el Modelo de

Diseo (Diagrama de Clases) es mnimo,por lo que se buscan los Expertos enInformacin en el Modelo del Dominio


7/41

7


8/41

8

Patrn: Experto

Ejemplo de AplicacinVenta contiene todas sus lneas de venta, por

lo tanto, la clase Venta es adecuada para estaresponsabilidad

Venta es un experto en informacin para el

trabajo


9/41

9

Patrn: Experto

Ejemplo de Aplicacin4. Agregar una clase de SW al modelo de diseo

con el mismo nombre Venta, y se le asigna laresponsabilidad de conocer su total (getTotal)


10/41

10

Patrn: Experto

Ejemplo de AplicacinQu informacin se necesita para obtener el

subtotal de cada lnea de venta?LineaDeVenta.cantidadEspecificacionDelProducto.precio

LineaDeVenta conoce su cantidad y laespecificacin del producto asociada

Siguiendo el patrn Experto en Informacin,

LineaDeVenta debera determinar el subtotal


11/41

11

Patrn: Experto

Ejemplo de Aplicacin

En un diagrama de interaccin,Venta necesita enviar unmensaje getSubtotal a cada

una de sus lneas de venta ysumar el resultado

*


12/41

12

Patrn: Experto

Ejemplo de AplicacinQu informacin necesita conocer

LineaDeVenta para proporcionar el subtotal?Su cantidad

El precio del producto

EspecificacionDelProducto es el Experto en

Informacin que proporciona su precio

Se le debe enviar un mensaje solicitando su precio


13/41

13

Patrn: Experto


*


14/41

14

Patrn: Experto

Ejemplo de AplicacinResponsabilidad: Conocer el total de una venta

Clases de diseo y responsabilidades asignadas alelaborar el diagrama de interaccin

Venta: conocer el total de la ventaLineaDeVenta: conocer el subtotal de la lnea deventa

EspecificacionDelProducto: conocer el precio delartculo

Principio aplicado:Experto en Informacin


15/41

15

Patrn: CreadorProblema: Quin debera ser el responsable de lacreacin de una nueva instancia de alguna clase?

Solucin: asignar a la clase B la responsabilidad

de crear instancias de la clase A si se cumple unoo ms de los casos siguientes:B agrega objetos de A

B contiene objetos de AB registra objetos de A

B utiliza ms estrechamente objetos de A


16/41

16

Patrn: Creador

Ejemplo de AplicacinB tiene los datos de inicializacin que se pasarn a unobjeto A cuando sea creado (B es un Experto con

respecto a la creacin de A)B es creador de objetos de A

Ejemplo: Quin debera crear una LineaDeVenta?

1. Siguiendo el patrn creador, buscar clases queagregan, contienen, registran, etc.; objetos de la

LineaDeVenta


17/41

17

Patrn: Creador


Venta contiene (agrega) muchos objetos de

LineaDeVenta


18/41

18

Patrn: Creador

Ejemplo de Aplicacin2. Disear interacciones


19/41

19

Patrn: Bajo AcoplamientoProblema: Cmo soportar bajas dependencias,bajo impacto del cambio e incremento de lareutilizacin?

Solucin: Asignar una responsabilidad de maneraque el acoplamiento permanezca bajo


20/41

20

AcoplamientoConceptoEs una medida de la fuerza con que un elemento est

conectado a, tiene conocimiento de, confa en, otros

elementos

Tipos

Bajo (o dbil) acoplamiento no depende de demasiadosotros elementos (clases, subsistemas, sistemas, etc.)

Alto (o fuerte) acoplamiento confa en muchas otrasclases. Problemas que surgen:

Cambios a clases relacionadas fuerzan cambios locales Difciles de entender de manera aislada

Difciles de reutilizar puesto que su uso requiere lapresencia adicional de las clases de las que depende


21/41

21

Patrn: Bajo Acoplamiento

Ejemplo de AplicacinResponsabilidad: crear una instancia de Pagoyasociarla con la Venta

Qu clase debera ser la responsable de esto?Patrn Creador sugiere que sea Registro, ya queRegistroregistra un Pago.

1 Opcin: Registro acopla Pago


22/41

22

Patrn: Bajo Acoplamiento

Ejemplo de AplicacinAsignar a Registrola responsabilidad anterior,acopla la clase Registrocon el conocimiento de la

clase Pago.

Solucin alternativa:Ambos casos asumen que la Ventadebe acoplarse alconocimiento del Pago

2. Opcin, Registrono acopla el conocimiento delPago


23/41

23

2. Opcin: Registro no acopla Pago


24/41

24

Patrn: Alta CohesinProblema: Cmo mantener la complejidadmanejable?

Solucin: Asignar una responsabilidad de manera

que la cohesin permanezca alta

Cohesin funcional: es una medida de la fuerza

con la que se relacionan y del grado defocalizacin de las responsabilidades de unelemento


25/41

25

Patrn: Alta CohesinClase con Baja Cohesin: hace muchas cosas norelacionadas, o demasiado trabajo

Clase con Alta Cohesin: tiene responsabilidades

altamente relacionadas, y no hace gran cantidadde trabajo.


26/41

26

Alta Cohesin.

Ejemplo de AplicacinResponsabilidad: crear una instancia de

Pagoy asociarla con la Venta

Qu clase debera ser la responsable de

esto?

Patrn Creador sugiere que sea Registro, yaque Registroregistra un Pago.


27/41

27

Alta Cohesin.



28/41

28

Alta Cohesin.

Ejemplo de AplicacinLa asignacin de responsabilidad anterior sita laresponsabilidad de realizar un pago en el Registro

Si el sistema posee 50 operaciones, todas recibidas

por Registro, y hace todo el trabajo relacionada concada una, se convertir en un objeto saturado y sincohesin.

Crear pago no hace el Registrocohesivo, pero sesobrecargar incrementalmente con tareas y llegar

a perder cohesin


29/41

29

Alta Cohesin.

Ejemplo de AplicacinSolucin alternativa:

Responsabilidad asignada a la clase Venta

Soporta Alta Cohesin y Bajo Acoplamiento


30/41

30

Diferentes grados de

cohesin funcionalMuy baja cohesin:

Una clase es responsable de muchas cosas en reasfuncionales muy diferentes

Ejemplo: Interfaz_BDR_RPC, responsable de acceso aDB y administrar las llamadas de procedimiento

remotosBaja cohesin:

Una clase tienen la responsabilidad de una tarea

compleja en un rea funcionalEjemplo: Interfaz_BDR, implementa muchas mtodosrelacionados pero similares


31/41

31

Diferentes grados de

cohesin funcionalAlta cohesin:

Una clase tiene una responsabilidad moderada en un

rea funcional y colabora con otras clases para llevar acabo las tareas

Ejemplo: Interfaz_BDRinteracta con todas las clasespersistentes

Moderada cohesin:Una clase tiene responsabilidades ligeras y nicas enunas pocas reas diferentes que estn lgicamente

relacionadas con el concepto de la clase, pero no entreellas

Ejemplo: Compaa, responsable de conocer a susempleados y conocer su informacin financiera


32/41

32

Patrn: ControladorProblema: Quin debe ser el responsable degestionar un evento de entrada al sistema?

Nota: Los elementos de la interfaz de usuario,

como por ej. Ventana, Applet, Vista,Documento; no abordan las tareas relacionadascon los eventos del sistema, slo reciben loseventos y los delegan a un Controlador


33/41

33

Patrn: ControladorSolucin: Asignar la responsabilidad de recibir omanejar un mensaje de evento del sistema a unaclase que representa una de las siguientesopciones:

El sistema global, dispositivo o subsistema (Controlador

de Fachada)Un escenario de caso de uso en el que tiene lugar elevento del sistema, se denomina con el nombre del

caso de uso, por ej. ProcesarVentaManejador,(Controlador de sesin o caso de uso)


34/41

34

Patrn: ControladorControlador: Objeto que no pertenece a la interfazde usuario, responsable de recibir o manejar unevento del sistema.

Quin debera ser el responsable de los eventosde este sistema?

C t l d


35/41

35

Controlador.

Ejemplo de Aplicacin- representa el sistema

global, dispositivo o

subsistema

Registro, SistemaCDV

- representa un receptor

o manejador de todoslos eventos del sistema

de un escenario de caso

de uso

ProcesarVentaManejador,

ProcesarVentaSesion

C t l d


36/41

36

Controlador.


C t l d


37/41

37

Controlador.

Ejemplo de AplicacinDos alternativas posibles son:

P d i ti


38/41

38

Puede existir

uno o mscontroladores


39/41

39

Detalle demtodos/operaciones

Controlador Saturado


40/41

40

Controlador Saturado

(demasiadas responsabilidades)Opciones para evitar un controlador saturado:1. Agregar ms controladores, por ej.:

1. RealizarReservaManejador

2. GestionarHorariosManejador

3. GestionarTarifasManejador

2. Disear un controlador que delegue la responsabilidadde cumplir las tareas a otros objetos

Controlador


41/41

41

Controlador.


Unidad 2E Metodologia Con POO

Documents

Transcript of Unidad 2E Metodologia Con POO