Your SlideShare is downloading. ×
Sesion 13 diseño iii    diseño de objetos
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Sesion 13 diseño iii diseño de objetos

532
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
532
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
33
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Diseño: Diseño de ObjetosLic. César Alcántara Loayza
  • 2. Términos  Application logic: Software cuya principal función es controlar las interacciones con el actor manejando el comportamiento de la interface de usuario.  Transaction logic: Unidad de trabajo estandarizada, reusable que puede ser referida por cualquier número de aplicaciones. Por ejemplo una transacción de “deposito” puede ser accedida vía una aplicación ATM, home banking u otra aplicación de cajero..CAL/Fundamentos 2
  • 3. Introducción  Su aplicación (sistema) debería hacer lo que el usuario espera que haga. El diseño de objetos es la fase en la cual ud. decide como hace su aplicación para que concuerde con estas espectativas.  Se han definido estas espectativas en el inicio del proyecto usando los casos de uso. Ud. ha definido todos los recursos que el sistema necesita manejar, durante el análisis del problema usando el modelo de objetos y los diagramas de interacción.CAL/Fundamentos 3
  • 4. Introducción  Durante el análisis arquitectural ud. particionó el sistema en unidades basadas en los casos de uso del dominio del problema (particiones de dominio) y la arquitectura mas adecuada para soportar los objetivos del sistema.CAL/Fundamentos 4
  • 5. Introducción  Ahora en la fase de diseño de objetos se trabajará en cada partición para definir los mecanismos de control dentro del software y las interfaces entre estas piezas de software.CAL/Fundamentos 5
  • 6. Herramientas – Diseño de O.  Ya hemos usado la mayoría de herramientas del diseño de objetos:  El modelo de objetos  Los diagramas de interacción  Especificacion de CUS (Narrativa - escenarios)  Continuaremos usando estas herramientas. Pero ahora añadiremos diferentes detalles a los diagramas. Adicionalmente usaremos el diagrama de estados para modelar el ciclo de vida de los objetos y comportamientos específicos al estado.CAL/Fundamentos 6
  • 7. Productos Trabajo Del Diseño 5 Modelo de 4 Objetos 6 escenario s 1 3 7 2 Diagrama Modelo de Especificacion 10 De Estados casos de uso CUS 9 Diagrama de 11 Secuencia 8 ColaboraciónCAL/Fundamentos 7
  • 8. Productos Trabajo Del Diseño  1. El modelo de casos de uso identifica la comunicación entre los actores y el sistema. El díalogo es la base para los diagramas de interacción. Los recursos usados para soportar el diálogo vienen a ser los objetos del modelo de objetos.CAL/Fundamentos 8
  • 9. Productos Trabajo Del Diseño  2. La descripción de los casos de uso se pueden modelar usando la especificación narrativa, modelo de análisis y diagramas colaboración que definan la lógica en la interacción entre los actores y el sistema. La evaluación de la lógica podría resultar en cambios al alcance y definiciones de los casos de uso.CAL/Fundamentos 9
  • 10. Productos Trabajo Del Diseño  3. La especificación narrativa de CUS representan la lógica para un caso de uso o una operación individual.  4. Siempre que una operación requiera lógica significante,se puede emplear el diagrama de actividad para ayudar en su diseño. Esto a su vez puede resultar en el descubrimiento de otras operaciones mas pequeñas y reusables que puedan proporcionar soporte para las mas grandes y complejas. (...)CAL/Fundamentos 10
  • 11. Productos Trabajo Del Diseño  (...) Cada operación también revela los atributos que los objetos necesitan para invocar la operación. Estos atributos son agregados a la definición de la clase para los objetos cuyo propósito se acerca mas a los propósitos del atributo.CAL/Fundamentos 11
  • 12. Productos Trabajo Del Diseño  5. Los diagramas de clase proporcionan la definición de objetos. Cada operación y cada atributo descubierto por su uso en otros diagramas son agregados al diagrama de clase. El diagrama de clase es el repositorio definitivo y la fuente de todo para la generación de código.CAL/Fundamentos 12
  • 13. Productos Trabajo Del Diseño  6. El diagrama de estados identifica acciones y actividades que se traducen en operaciones y lógica de operaciones. Cada operación nueva se agrega a la clase que define el objeto.  7. El diagrama de estados representa el ciclo de vida de un objeto único. Cada evento que el objeto puede responder es representado con un cambio de estados y comportamientos. Los comportamientos específicos de estado son representados como acciones y actividades.CAL/Fundamentos 13
  • 14. Productos Trabajo Del Diseño  8. Los diagramas de interacción modelan los eventos entre objetos y al hacer así identifican las interfaces que los objetos necesitan para recibir los eventos.  9. Los diagramas de interacción se pueden usar para derivar los diagramas de estados al identificar estados candidatos y los eventos que causan las transiciones entre estados.CAL/Fundamentos 14
  • 15. Productos Trabajo Del Diseño  10. Las definiciones de clase proporcionan los objetos que participan en los diagramas de interacción. Las interfaces, descubiertas en los diagramas de interacción, se traducen en operaciones para las clases que definen a los objetos participantes. Cada operación a su vez identifica los atributos de la clase en la forma de parametros de entrada (argumentos) y valores de retorno.CAL/Fundamentos 15
  • 16. Productos Trabajo Del Diseño  11. Los escenarios individuales en una especificación narrativa pueden formar la base para la comunicación de objetos en un diagrama de interacción. Los diagramas de interacción frecuentemente identifican intefaces complejas que requieren mayor análisis usando otros diagramas, entre ellos diagramas de actividad.CAL/Fundamentos 16
  • 17. Diagramas de Interacción  Para beneficiarse de los diagramas, necesitamos comprender la relación entre los diagramas.  Los diagramas:  Presentan una descripción consisa de lo que ud. conoce y decide acerca del sistema  Representan diferentes vistas de sistema.CAL/Fundamentos 17
  • 18. Diagramas de Interacción  Juntos, sin embargo, los diferentes diagramas representan un cuadro completo de cómo está estructurado el sistema y como trabajan los objetos. Al comparar las diferentes vistas, se pueden identificar inconsistencias y mejorar el modelo general.CAL/Fundamentos 18
  • 19. Diagrama De Estados  En muchos sistemas, existen al menos unas pocas clases de objeto clave que sufren cambios sustanciales durante su tiempo de vida. Para estos objetos, un único evento puede resultar en muchas respuestas diferentes basadas en las condiciones actuales del objeto. La condición del objeto es referida como el estado del objeto.CAL/Fundamentos 19
  • 20. Diagrama De Estados  Estado del objeto: El estado se define por los valores de los atributos y las relaciones del objeto. Por ejemplo, cuando se abre una cuenta de crédito, un intento de comprar un artículo resultaría en una comparación del monto comprado y el crédito disponible. Cuando la cuenta de crédito es cerrada, un intento de comprar artículos resultaría en un error.CAL/Fundamentos 20
  • 21. Diagrama De Estados  Igualmente, una relación puede provocar una respuesta diferente. Por ejemplo, cuando en el sistema de boletaje un AsientoPresentación no está asociada con un NivelDePrecio, no puede venderse. Una vez que se establezca el enlace con el NivelDePrecio, el AsientoPresentación se puede vender.CAL/Fundamentos 21
  • 22. Diagrama De Estados  El diagrama de estados no se usará para todas las clases del modelo. El diagrama de estados es una herramienta de propósito especial que se emplea solo para objetos que poseen substancial comportamiento de estados específico. ¿cómo reconocer esos objetos? ...CAL/Fundamentos 22
  • 23. Diagrama De Estados  Una técnica es revisar los diagramas de interacción e identificar aquellos objetos que participan en muchos, o mas aún en todos, los escenarios. Específicamente, busque aquellos objetos que tengan mas flechas de evento entrantes, pues cada evento entrante tiene el potencial de cambiar el estado actual del objeto.CAL/Fundamentos 23
  • 24. Diagrama De Estados  El objeto permanece en una condición o estado hasta que algo le ocurra al objeto que active un cambio en el estado llamado “transición”. A B CCAL/Fundamentos 24
  • 25. Revisión D. Estados Notación  Revisar la notación del diagrama de estados en la presentación:  UML – Diagrama de Estados.  En el siguiente ejemplo se ayuda a empezar la construcción de un diagrama de estados usando un diagrama de secuencia como fuente. Los ejemplos son muy pequeños de modo que se puede enfocar en los mecanismos mas que en la complejidad del dominio del problema. Pero la misma estrategia se puede emplear a medida que la complejidad del dominio se incrementa.CAL/Fundamentos 25
  • 26. Revisión D. Estados Notación  Identifique los estados. aGestionFacilidad aPresentación aAsientoPresentación CrearPresentación CrearAsientoPresentación El objeto no existe hasta que el el evento lo crea. El Hecho objeto comienza en un Hecho estado inicial: “sin precio, no seleccionado, y no vendido” Caso de Uso: Planear Presentación Escenario: Programar Presentación con éxitoCAL/Fundamentos 26
  • 27. Revisión D. Estados Notación  Identifique los eventos que activan la transición entre estados. aGestionFacilidad aPresentación aAsientoPresentación CrearPresentación CrearAsientoPresentación Transición eventos Hecho Hecho Caso de Uso: Planear Presentación Escenario: Programar Presentación con éxitoCAL/Fundamentos 27
  • 28. Revisión D. Estados Notación  Dibuje el diagrama de estados aGestionFacilidad aPresentación aAsientoPresentación CrearPresentación CrearAsientoPresentación Hecho Hecho Sin precio No separado No vendido Caso de Uso: Planear Presentación Escenario: Programar Presentación con éxitoCAL/Fundamentos 28
  • 29. Revisión D. Estados Notación  Mezcle el nuevo diagrama con el diagrama previo para formar un único diagrama de estados para el AsientoPresentación. aGestionFacilidad aAsientoPresentación Sin precio Precio(NivelDePrecio) No separado No vendido Hecho Precio(NivelDePrecio Sin precio No separadoCaso de Uso: Planear Presentación No vendidoEscenario: Programar Presentación con éxito CAL/Fundamentos 29
  • 30. Construir Un D. De Estados  Ejercicio:  Ver documento Word.  Diseño III – Construir Diagrama de EstadosCAL/Fundamentos 30
  • 31. Patron Diseño de Estado  Cuando un objeto exhibe un conjunto de comportamientos específicos de estado, el código puede ser muy grande, complejo y dificil de seguir. Para cada comportamiento que el objeto pueda manifestar, la implementación puede ser diferente por cada estado del objeto. Por ejemplo, un objeto relativamente simple con seis estados y seis comportamientos podría necesitar 36 bloques de código de implementación – un bloque por cada comportamiento para cada estado.CAL/Fundamentos 31
  • 32. Patron Diseño de EstadoCAL/Fundamentos 32
  • 33. Patron Diseño de Estado  Una técnica para para cubrir la complejidad de comportamientos de estados específico es el patrón diseño de estados. Este patrón usa el concepto de delegación para separar la implementación de un comportamiento del objeto que es responsable por el comportamiento.CAL/Fundamentos 33
  • 34. Patron Diseño de Estado  Por ejemplo, muchos de nosotros somos responsables de declarar impuestos. Sin embargo, para algunos de nosotros, el proceso es extremadamente complejo y requiere asistencia de un experto. Retenemos la responsabilidad final de declarar impuestos, pero delegamos el proceso a un especialista que lo hace por nosotros.CAL/Fundamentos 34
  • 35. Patron Diseño de Estado  Cuando el especialista en impuestos termina el nos entrega resultados. La delegación también se puede aplicar a objetos, por ejemplo, una póliza de seguros proporciona interfaces para enviar reclamos y cancelar la póliza. Pero la implementación de estas interfaces depende del estado (condición) de la póliza. En la siguiente imagen se muestran los componentes del patrón diseño de estados usado para delegar la implementación de estas interfaces.CAL/Fundamentos 35
  • 36. Patron Diseño de EstadoCAL/Fundamentos 36
  • 37. Patron Diseño de Estado  Cuando los comportamientos de un objeto difieren dependiendo de un estado de objeto, ud. puede definir nuevos objetos que represente el estado del objeto. Cada unico tipo de estado de objeto tiene su propia implementación para cada comportamiento. Cuando el objeto necesita un comportamiento este “delega” el comportamiento a un objeto de estado apropiado. Una vez que el comportamiento está completo, el objeto estado regresa el control al objeto original.CAL/Fundamentos 37
  • 38. Patron Diseño de Estado  Veamos el ejemplo Java:  Void SubmitClaim(Claim) { state.SubmitClaim(Claim) }  Note como la operación simplemente invoca otra operación del mismo nombre sobre el objeto referido por el atributo estado. La interface no tiene realmente una implementación de su propiedad.CAL/Fundamentos 38
  • 39. Patron Diseño de Estado  Transformar el diagrama de estados en el patron de estados: El diagrama de estados proporciona una descripción explícita de los estados de un objeto. Para crear el patrón de estados en su diagrama de clases vea los siguientes cuadros y siga los pasos.CAL/Fundamentos 39
  • 40. Patron Diseño de Estado  El patrón de estados no es adecuado para todas las aplicaciones de comportamiento específico de estado. Sin embargo, cuando uno encara un numero grande de estados y una variedad de comportamientos, el patrón puede pagar buenos dividendos en facilidad de mantenimiento y comprensión.CAL/Fundamentos 40
  • 41. Patron Diseño de Estado Crear un atributo sobre la clase Base llamado estado o estatus o AsientoPresentación estado algo similar que convenga al propósito.CAL/Fundamentos 41
  • 42. Patron Diseño de Estado Sin precio No Disponible No separado No vendido Para cada estado en el diagrama Precio(NivelPrecio) de estados, crear su RemoverPrecio() Con precio No separado correspondiente definición de No vendido Disponible clase. Cancel() Select() con precio Reembolsar() separado Separado No vendido AsientoPresentación Compra(TipoPrecio) estado con precio Vendido No separado vendido NoDisponible Disponible Separado VendidoCAL/Fundamentos 42
  • 43. Patron Diseño de Estado Dibuje una relacion de generalización desde cada objeto estado hacia la única superclase. AsientoPresentación EstadoAsientoPresentación estado NoDisponible Disponible Separado VendidoCAL/Fundamentos 43
  • 44. Patron Diseño de Estado AsientoPresentación EstadoAsientoPresentación estado : EstadoAsientoPresentacion 0..* 1 NoDisponible Disponible Separado Vendido El tipo de dato del atributo de Estado/Estatus de la clase base debería referirse a la nueva superclase (esto permitirá que la clase base se refiera a cualquier subclase estado a través de este atributo). El símbolo de agregación se usa comunmente para indicar que la generalizacion de estado es “parte de” el maquillaje de la clase base.CAL/Fundamentos 44
  • 45. Patron Diseño de Estado Para cada evento en el diagrama de transición de Sin precio estados: a) agregue una interface correspondiente al No separado objeto base. B) agregue una interface correspondiente No vendido (identica) a la superclase estado (esto provocará que Precio(NivelPrecio) RemoverPrecio() cada subclase estado herede las interfaces). Con precio No separado No vendido AsientoPresentación Cancel() Select() EstadoAsientoPresentación estado : EstadoAsientoPresentacion Reembolsar() con precio Select() Select() Cancel() separado Cancel() 0..* 1 Reembolsar() No vendido Reembolsar() Comprar() Compra(TipoPrecio) Comprar(TipoPrecio) Precio() Precio(NivelPrecio) RemoverPrecio() RemoverPrecio() con precio No separado vendido NoDisponible Disponible Separado VendidoCAL/Fundamentos 45
  • 46. Patron Diseño de Estado Un ejemplo Java para delegar comportamiento: Void Compra(TipoPrecio) {Estado.Compra(TipoPrecio)} AsientoPresentación EstadoAsientoPresentación estado : EstadoAsientoPresentacion Select() Select() Cancel() Cancel() 0..* 1 Reembolsar() Reembolsar() Comprar() Comprar(TipoPrecio) Precio() Precio(NivelPrecio) RemoverPrecio() RemoverPrecio() Para implementar las interfaces del objeto base, invoque la interface correspondiente sobre el atributo que NoDisponible Disponible Separado Vendido retiene la referencia a la subclase estado.CAL/Fundamentos 46
  • 47. Resúmen  Los estados y los comportamientos específicos de estado son elementos importantes de cualquier diseño final de aplicación. El diagrama de estados es una herramienta especificamente diseñada para representar el estado del objeto, los eventos de transición de estados y el comportamiento específico de estado en la forma de acciones y actividades.CAL/Fundamentos 47
  • 48. Resúmen  Los estados son representados por los valores de los atributos del objetos. Las acciones activadas por eventos representan la implementación de los eventos que causan el cambio actual en el estado. Las actividades representan comportamientos internos al estado del objeto.CAL/Fundamentos 48
  • 49. Resúmen  Aplicando patrones para simplificar el modelo: El patrón diseño de estados es una forma de manejar la complejidad del comportamiento específico de estado y evitar codificación complicada. El patrón de diseño de estado está diseñado específicamente para distribuir y aislar el comportamiento específico de estado. Este arreglo hace que la solución sea visible a nivel de modelo.CAL/Fundamentos 49
  • 50. Resúmen  (...) En cualquier momento un problema puede resolverse a nivel de modelo en vez de con el código, el tiempo y costos de mantenimiento se reducen considerablemente.CAL/Fundamentos 50
  • 51. Resúmen  Actualizar los productos del trabajo. Cada vez que se agrega una nueva clase al modelo debe reconciliar el producto del trabajo nuevamente. La comprensión de la relación entre los productos del trabajo proporciona un conjunto de herramientas que le ayudan a entender completamente y describir el rol de cada nuevo recurso y su relación con los otros elementos del modelo.CAL/Fundamentos 51
  • 52. Resúmen  Una forma que ud. conozca si su modelo está bien diseñado es si es capaz de añadir nuevas características con poco o ningún cambio al modelo. Los cambios debería ser aislados en pequeños subconjuntos de componentes del modelo. En contraste, un pobre diseño rápidamente crecerá en tamaño y complejidad con cada comportamiento adicional. Un simple cambio puede resultar en múltiples y frecuentemente cambios redundantes en muchas partes del modelo.CAL/Fundamentos 52