2. La Metáfora de la Célula Alan Kay utiliza la metáfora del Sistema Biológico para para explicar lo que deben ser los Objetos Software. Como las células, los Objetos Software no saben que es lo que sucede internamente en cada objeto, pero secomunican y trabajanen conjunto para realizar tareas complejas. En contraste, un Software Monolítico, es como un reloj mecánico que contiene innumerables engranes que funcionan sin inteligencia y en relación únicamente con los engranes adyacentes. “Cuando construyes un reloj de engranes, eventualmente alcanzas un nivel de complejidad que pone límites en si mismo” dice Alan Kay.
3. La Metáfora de la Célula Un Objeto Software puede ser como una máquina que: Toma decisiones. Hace cosas. Conoce cosas. Colabora con muchos otros objetos potenciales. Viviendo en una máquina encerrada: Es un Todo en un nivel. Y una Parte en otro. El comportamiento del objeto está estrictamente limitado a aquello para lo que se le diseñó. Pero el comportamiento dinámico del Sistema Software surge a partir de las interacciones de muchos objetos (cada uno contribuyendo y jugando un rol responsable).
4. La Maquinaria de Objetos Una Aplicación Software debe estar construida a partir de partes (los objetos). Estas partes interactúan enviando mensajes para solicitar alguna informacióno acción de otras partes. A lo largo de su tiempo de vida, cada objeto se mantiene responsable de responder a un conjunto fijo de solicitudes. Para atender estas peticiones, los objetos encapsulan respuestas y la información en la que se basan para estas respuestas.
5. El objeto encapsulando respuestas e información … Ejecuta Servicios Conoce información Un Objeto Toma decisiones (para hacer lo correcto) Mantiene conexiones (a otros objetos)
7. Respuesta clave … Construir una Aplicación Orientada a Objetos significa inventar la maquinaria apropiada en la cual representamos: Información del mundo real. Procesos. Interacciones. Relaciones. Errores Objetos que no existen en la realidad (damos vida a cosas inanimadas). Descomponemos en objetos simples a objetos complejos (y difíciles de entender).
8. Respuesta clave … La medida del éxito es: que tan claramente inventamos la realidad del software que satisface los requisitos de la aplicación (y no que tanto se asemeja al mundo real). Al conectarse los objetos entre sí deben trabajar en concierto para construir máquinas muy complejas. Para manejar la complejidad, debemos repartirlos comportamientos del sistema en objetos que jueguen roles bien definidos.
9. Perspectivas complementarias para el diseño de aplicaciones Enfocados en el comportamiento, es posible diseñar una aplicación usando varias perspectivas complementarias: Una Aplicación = Un conjunto de objetos que interactúan Un Objeto = Una implementación de uno o más roles Un Rol = Un conjunto de responsabilidades relacionadas Una Responsabilidad = Una obligación para realizar una tarea o conocer una información Una Colaboración = Una interacción de objetos o roles (o ambos) Un Contrato = Un acuerdo enmarcando los términos de la colaboración.
10. Roles Dentro de la maquinaría cada objeto tiene un propósito específico (el rol que juega dentro de un cierto contexto). Objetos que juegan el mismo rol pueden ser intercambiados. Así podemos definir Rol: “Un conjunto de responsabilidades que se pueden utilizar de forma intercambiable” Un rol es un slot en la maquinaría del software a ser llenado con un objeto apropiado conforme el programa se ejecuta.
11. Estereotipos de Roles de Objetos Para enfocarse en las responsabilidades del objeto podemos utilizar Estereotipos de Roles. Los Estereotipos son caracterizaciones de los roles necesarios de las aplicaciones. A fin de construir objetos consistentes y fáciles de utilizar, es ventajoso estereotipar objetos ignorando los detalles específicos de los comportamientos y pensando en ellos a alto nivel.
12. Estereotipos útiles Los siguientes son estereotipos útiles: InformationHolder: conoce y provee información. Structurer: mantiene relaciones entre los objetos, así como también información de estas relaciones. ServiceProvider: realiza trabajo y, en general, ofrece servicios de cómputo. Coordinador: reacciona a eventos delegando tareas a otros. Controller: toma decisiones y dirige otras acciones. Interfacer: transforma información y solicitudes entre diferentes partes del sistema. Un objeto podría satisfacer más de un estereotipo, aunque podría tener asignada más de 1 responsabilidad (Un objeto ServiceProvider que maneja de forma privada la información necesaria para éste rol: 1 Rol con 2 Responsabilidades).
13. Roles, Responsabilidades y Colaboraciones Una Aplicación implementa un sistema de Responsabilidades. Las Responsabilidades son asignadas a los Roles. Los Roles colaboran para llevar a cabo las Responsabilidades. Una buena aplicación está estructurada para satisfacer efectivamente estas responsabilidades. Diseñar colaboraciones obliga a considerar objetos como participantes colaboradores y no como entidades aisladas. El Diseño es un proceso iterativo e incremental de visualizar objetos y sus responsabilidades e inventar colaboraciones flexibles dentro de pequeños vecindarios.
14. Objetos colaborando para resolver problemas mayores que los que pueden resolver solos … Ejecuta Servicios Conoce información Toma decisiones (para hacer lo correcto) Un Objeto Mantiene conexiones (a otros objetos) “Una aplicación es una comunidad de objetos trabajando juntos. Colaboran enviando mensajes y recibiendo respuestas. Contribuyen con su Conocimiento y Servicios” Mensaje solicitando ayuda Un Objeto
15. Objetos colaborando para resolver problemas mayores que los que pueden resolver solos … Un objeto puede ser más inteligente si hace algo con lo que conoce. Entre más inteligente el objeto, menos detalles debe conocer el cliente que utiliza sus servicios. Así los clientes se enfocan a resolver el problema, no en poner atención a detalles que sus colaboradores pueden resolver. Hacer objetos inteligentes tiene un efecto neto de elevar el IQ de toda la sociedad de objetos.
16. Objetos colaborando para resolver problemas mayores que los que pueden resolver solos … Parte del valor de un objeto está determinado por sus vecinos. Al concebir el diseño hay que considerar constantemente (respecto los vecinos): ¿Provee un servicio útil? ¿Es fácil hablar con él? ¿Es una “carga” porque continuamente solicita ayuda? ¿Sus efectos son los deseados? Entre menos demandas hace un objeto, más fácil será de utilizar. Entre más tome cuidado, más útil será.
17. Contratos de Objetos Un Contrato de un Objeto describe las condiciones bajo las cuales se garantiza su trabajo y los efectos que dejará una vez que el trabajo se complete. El Contrato de un Objeto responde a las preguntas: ¿Con cuales objetos interactúa? ¿Bajo que circunstancias es utilizado? ¿Cuáles son los efectos a largo plazo que tendrá el objeto con su ambiente? Profundiza nuestro conocimiento de las responsabilidades del objeto y soporta nuestra confianza respecto a su diseño. Todo esto sin indicar como se cumplen con las responsabilidades.
18. Condiciones de Uso y Garantías de Efecto Posterior Las Condiciones de Uso y las Garantías de Efecto Posterior definen los contratos. Las Condiciones de Uso responden a la pregunta: ¿Bajo que condiciones puede el objeto garantizar sus servicios? Las Garantías de Efecto Posterior responden a la pregunta: ¿Qué esperan los demás objetos de mí? Cuando un objeto se utiliza fuera de sus Condiciones de Uso no está obligado a satisfacer la petición. Las Condiciones de Uso en Diseño OO se reducen a las condiciones correctas bajo las cuales serán invocados los servicios aglutinados en las interfases de los objetos.
19. Objetos de Dominio Los Objetos de Dominio ofrecen una base común sobre la cual desarrolladores y usuarios pueden converger y discutir la aplicación. Los Objetos de Dominio representan conceptos que son familiares a usuarios y expertos en un campo específico de interés. Ej.- En una aplicación bancaria: cuentas, depósitos, tasas de interés, etc. Para los desarrolladores estos objetos del dominio son solamente el punto inicial para construir un Modelo del Dominio útil para desarrollar las representaciones internas de éstos y conceptos adicionales que existirán en la maquinaria del software.
20. Modelo de Dominio Un Producto Relaciones Procesos Una Orden Una Revisión del Stock Una Historia Crediticia Un Cliente Información Reglas Un Descuento Una Regla de Embarque Servicios
21. Modelo de Dominio Los objetos en el Modelo de Dominio incorporan la lógica de la aplicación y sus interacciones. El M. de D. captura, al nivel más abstracto, la semántica de la aplicación y sus respuestas al ambiente. No se representan todos los conceptos del dominio solamente los que son necesarios para soportar la aplicación.
22. Objetos Específicos de la Aplicación Similarmente, necesitamos objetos para traducir las entradas del usuario (clics de mouse, tecleo) a comandos para objetos apropiados de la aplicación. Estos objetos transforman o filtran la información de usuario y después llaman a los objetos apropiados para la acción. Podrían también secuenciar al movimiento de pantallas, cambiar vistas o refrescar imágenes. Estos objetos específicos de aplicación proveen al Modelo de Dominio de comportamientos específicos del programa y se aglutinan con la aplicación.
23. Objetos Específicos de la Aplicación Al iniciar una típica aplicación existe al menos 1 objeto de arranque que crea la población inicial de objetos y luego les pasa el control. Conforme el usuario navega a través de la aplicación, este grupo inicial de objetos responde a acciones de usuario ya sea satisfaciendo requisitos de la aplicación o creando y delegando trabajo a nuevos grupos de objetos diseñados para propósitos específicos. Conforme la ejecución continua, nuevos ciudadanos de esta comunidad de objetos nacen, viven y mueren (acorde a las necesidades –y diseño- de la aplicación).
24. Modelo de Dominio Un Producto Relaciones Control Procesos Un gestor de órdenes Una Orden Un verificador de crédito Una Revisión del Stock Una Historia Crediticia Coordinación Un Cliente Información Una ventana Interfases Reglas Un Descuento Una Regla de Embarque Servicios
25. Vista del Usuario y Vista del Diseñador Ambas vistas representan dos niveles diferentes de pensamiento sobre aplicaciones y objetos. La Vista del Usuario maneja una representación de conceptos del alto nivel (la información, servicios y reglas del dominio). La Vista del Diseñador inventa aspectos de coordinación y conectividad a otros sistemas y dispositivos, razona sobre la aplicación a un nivel diferente, más bajo: procesos de computadora, computaciones, traducciones, ejecución condicional, delegación, entradas, salidas. La clave para desarrollar una aplicación exitosa recae en nuestra habilidad para vincular estas dos vistas sin comprometer ninguna.
26. Interfases Eventualmente un objeto expresa sus responsabilidades sobre conocer (know) y hacer (do) a otros en métodos que contienen código. Una Interfase describe el vocabulario utilizado en el diálogo entre un objeto y sus clientes: “Bolea mis zapatos. Dame mis zapatos. Serán cinco pesos. Aquí está tu recibo”. La Interfasemanifiesta los servicios y explica como solicitarlos. Frecuentemente es importante conocer, además, las condiciones bajo las cuales un servicio puede ser invocado. Entre más se publique sobre el comportamiento de un objeto, más probable será que se utilice de acuerdo a su intención en el diseño. La interfase debe ser pública, la implementación privada u oculta.
27. Clases El término Clase se utiliza en matemáticas y en la vida real para describir “conjuntos de cosas”. Las clases son abstractas y conceptuales, las instancias concretas, objetos físicos. Esta noción aplica también a los objetos software, aunque las clases software poseen características que son específicas al mundo del software.
28. Dos roles Si una clase software ofrece dos conjuntos distintos de servicios (usualmente a dos tipos de clientes), la clase se dice que juega dos roles: Primero, juega un rol que no tiene analogía en el mundo real: la clase actúa como una fábrica para crear las instancias requeridas del programa. Segundo, actúa como un objeto en sí mismo, con su propio conjunto de responsabilidades. Ofrece información y servicios a otros objetos a través de su propia interfase.
29. Dos roles: la clase actuando como Fábrica Un cliente Un cliente Un cliente Clase Cliente Un objeto new
30. Dos roles: la clase actuando como Fábrica Solicitudes por Información y Servicios relacionados con el Cliente Clase Cliente como colaborador Un objeto Necesita ayuda Ofrece ayuda como cualquier otro objeto
31. Dos roles Cada instancia realiza sus tareas en dos contextos: Se comporta de acuerdo a reglas establecidas por la comunidad donde vive. Controla sus acciones de acuerdo a sus reglas y datos privados. Las reglas suelen estar representadas en condicionales en métodos. Los datos representan el estado del objeto. Incluyen, además, referencias a otros objetos las cuales permiten que pueda “ver” a otros y, subsecuentemente, interactuar con ellos.
32. Relaciones entre objetos Existen sólo dos tipos de relaciones entre objetos: Composición Herencia Tienen analogía con el árbol familiar: La Composición es como un Matrimonio entre Objetos: es dinámica, sucede durante el tiempo de vida de los objetos y puede cambiar. La Herencia es como los Nacimientos en la familia: una vez que sucede es para siempre. Así como ambos existen en el árbol familiar, ambos también existen en cualquier sistema orientado a objetos.
33. Composición Es posible extender las capacidades de un objeto a través de su composición con otros. Cuando carece de alguna característica que requiere para satisfacer sus responsabilidades, se delega simplemente a algún objeto con el cual tenga referencia (o conexión). Esto ofrece un escenario muy flexible: conforme el programa continua su ejecución los componentes se conectan entre sí, dinámicamente, de acuerdo a las condiciones de la aplicación. La Composición es uno de los mecanismos básicos para lograr la comunicación entre objetos; otros incluyen el paso de objetos ayuda en solicitudes o la creación de objetos.
34. Herencia La Herencia es otra forma de extender las capacidades de un objeto. A diferencia de la Composición, que es dinámica (en tiempo de ejecución), la Herencia es estática (en tiempo de compilación). En ocasiones las clases delegan su responsabilidad de crear objetos a sus subclases. Estas clases abstractas definen muchas de las características de las instancias, pero requieren de las subclases para completar algunos detalles y realizar la manufactura actual.
35. Organizaciones de Objetos Conforme se descompone la aplicación en piezas lógicas se pueden identificar objetos o roles y definir clases que implementen roles específicos. Se pueden diseñar elementos que posean cierta integridad lógica, pero que se puedan descomponer en piezas más pequeñas. Estos agrupamientos lógicos de colaboradores (confederaciones de objetos) suelen llamarse subsistemas o vecindades de objetos. Los subsistemas sirven a propósitos mayores de los que en lo individual pudieran realizar cualquier objeto. La sinergia de los esfuerzos corporativos entre los miembros del subsistema crea una nueva entidad conceptual, de más alto nivel.
36. Confederación de objetos Un solo objeto que representapúblicamente a todos los objetos Empresa Financiera ACME Ley ACME Tu proveedor de servicio Licenciado Tu Agente Su asistente Conceptualmente no hay diferencia entre las responsabilidades de un Objeto y un Subsistema
37. Componentes Son piezas de elementos de diseño cuya intención es utilizarlas en diferentes aplicaciones. Se pueden actualizar o reemplazar un componente sin reconfigurar el resto del sistema. Los aspectos internos del componente están ocultos, sus servicios están disponibles a través de una interfase bien definida. Para adaptarlos para su uso, un componente puede proveer interfases que permitan a sus clientes conectar componentes de ayuda o establecer propiedades para controlar aspectos de su operación.
38. Patrones Los pioneros de tecnología de objetos generaron muchas aplicaciones y estrategias de objetos para resolver problemas. Esta experiencia puede ser transmitida a las siguientes generaciones mediante Patrones. Un Patrón captura la experiencia de practicantes expertos presentando soluciones a problemas recurrentes comunes en un formato predecible y fácil de leer.
39. Frameworks Un Framework es un diseño general para resolver un problema de software. A diferencia de un patrón (una idea para resolver un problema familiar), un Framework ofrece una biblioteca de clases que los desarrolladores pueden particularizar o extender para satisfacer una situación particular. El éxito del Framework depende de que tan útil es a los desarrolladores y que tan fácil se pueden particularizar sus servicios a las necesidades. Problemas donde se han aplicado con éxito los Frameworks: GUI, Simulación, Ambientes de Programación (Eclipse), Aplicaciones Web.
40. Frameworks-Ventajas Ventajas al desarrollador: Eficiencia: menos diseño y codificación. Riqueza: el expertise del dominio se captura en el Framework. Consistencia: los desarrolladores se familiarizan con la filosofía impuesta por el Framework. Predecibilidad: el Framework lleva consigo varias iteraciones de desarrollo y pruebas.
41. Frameworks-Desventajas Desventajas al desarrollador: Complejidad: suelen tener una curva de aprendizaje pronunciada. Suelen requerir una estrategia específica para resolver un problema (si lo único que tienes es un martillo, todo parecerá clavo). Rendimiento: suele intercambiar flexibilidad y reusabilidad por rendimiento.
42. Frameworks Los Frameworks ofrecen soluciones genéricas pero carecen de comportamientos específicos que varían de aplicación en aplicación. Los comportamientos que se dejan incompletos son llamados hooks: implementaciones que se difieren a los programadores para aplicaciones específicas. Al codificar los hooks el programador debe aceptar una inversión en el control: nuestro código llama a otros objetos y se les pide que hagan el trabajo a favor nuestro.
43. Arquitectura No hay una única definición de Arquitectura de una aplicación. Una Arquitectura es una colección de comportamientos y un conjunto de descripciones sobre como se impactan unos a los otros. La Arquitectura, entonces, debe incluir aspectos estructurales y dinámicos. Los detalles internos de cómo un grupo de objetos realizan una tarea no deberían considerarse al diseñar una Arquitectura. En Arquitectura las interfases deben decirlo todo.
44. Estilos Arquitectónicos Representan estilos para organizar los objetos software. Hay 2 aspectos que se deben considerar cuando se piensa en un estilo arquitectónico: Estilos de Interacción de Componentes: muestran componentes o capas del sistema y describen como se les permite interactuar (capas, pipes & filters, blackboard). Estilos de Control: enfoques para distribuir responsabilidades para toma de decisiones y coodinación dentro y entre capas o componentes (desde altamente centralizado hasta distribuido).
45. Estilos Arquitectónicos Cada combinación de Estilo Arquitéctonico soporta 1 o más características de calidad en un proyecto: Usabilidad Disponibilidad Seguridad Rendimiento Mantenibilidad Flexibilidad Portabilidad
46. Estilos Arquitectónicos Para soportar estos y otros atributos de calidad antes de realizar cualquier análisis, diseño, codificación podemos empezar seleccionando el Estilo Arquitectónico que los soportará. Seleccionar el Estilo Arquitectónico puede tener un alto impacto.
47. Estilo de Control Centralizado Hace una clara distinción entre datos y algoritmos. Cuando 1 Objeto Inteligente Central requiere computar datos, la pide a los Repositorios de Datos, los procesa y los regresa al mismo repositorio o a otro. La lógica de la aplicación está centralizada en los objetos inteligentes. El código puede ser difícil de leer porque está incrustado en una gran cantidad de lógica no afín, aunque sólo buscas en 1 solo lugar.
48. Estilo de Control Centralizado Los objetos manejan información… La lógica inicia y termina aquí …
49. Estilo de Control Disperso: no centralizado En el otro extremo, se dispersa la lógica a través de toda la población de objetos, manteniendo cada objeto pequeño y construyendo la menor dependencia entre ellos. No hay una entidad central. Para determinar el funcionamiento, se debe trazar la secuencia de solicitudes a servicios a través de muchos objetos, por esto no es muy reutilizable.
50. Estilo de Control Disperso: no centralizado La lógica inicia aquí … La lógica finaliza aquí …
51. Estilo de Control Delegado Establece un compromiso (o balance) entre los 2 extremos mencionados. Cada objeto encapsula mucho de lo que se necesita para realizar las responsabilidades, pero en ocasiones requiere la ayuda de otros objetos capaces. Cada objeto tiene una pieza sustancial del pastel. Como cada objeto es muy capaz de realizar sus responsabilidades, por tanto es más usable. Las Funciones del Sistema se organizan en pools de responsabilidad que pueden utilizarse en forma relativamente aislada.
52. Estilo de Control Delegado Los Objetos conocen y hacen algún sub-paso… Los coordinadores manejan cada paso… La lógica inicia aquí … La lógica termina aquí …
53. Estilo de Capas Agrupa responsabilidades en capas. Cada capa tiene un número bien definido de capas vecinas (1 o 2). Los objetos que viven en cada capa se comunican principalmente con objetos de la misma capa. Si los servicios que un objeto requiere no están en la capa los buscará en la capa adyacente. El Estilo de Capas contribuye a simplicidad, mantenibilidad y reusabilidad.
54. Estilo de Capas (aplicación Web) Browsers… Presentación Control y Coordinación de Aplicación Servidor Web… Servidor de Aplicaciones… Servicios e Información del Dominio Servidor de Base de Datos… Servicios de Base de Datos y Sistemas Legados
55. Cada capa tiene roles de objetos característicos… Interfases (ventanas y widgets) Presentación Eventos Resultados Coordinadores y Controladores (de Aplicación) Servicios de Aplicación Contenedores de Información, Proveedores de Servicios, Estructuradores, Coordinadores y Controladores de Dominio Mensajes Resultados Servicios del Dominio Mensajes Resultados Servicios Técnicos Intefases
56. Comunicando objetos en/entre capas La comunicación entre objetos tiende a seguir estas reglas: Los Objetos colaboran principalmente dentro de su propia capa. Cuando residen en capas diferentes, los objetos cliente suelen estar arriba de los objetos servidores. Los mensajes (peticiones) fluyen hacia “abajo”. La información (resultados) fluye hacia “arriba”. Cuando los mensajes fluyen hacia “arriba” los objetos cliente están en las capas bajas están débilmente acoplados a los servidores. Esto generalmente mediante un mecanismo de eventos. Sólo las capas más altas y bajas están expuestas al mundo “exterior”. Suelen manejar objetos específicos de plataforma (widgets en la capa alta,; interfases a redes, dispositivos y sistemas externos en las capas bajas).
