01 conceptos de diseño
TRANSCRIPT
1-Conceptos de Diseño
Dr. Ricardo Quintero
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 se comunican y trabajan en 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.
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).
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ón o 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.
El objeto encapsulando respuestas e información …
Un Objeto
Conoce información
Mantiene conexiones (a otros objetos)
Ejecuta Servicios
Toma decisiones(para hacer lo
correcto)
Pregunta clave…
¿Cómo inventamos estas Máquinas Software?
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).
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 repartir los comportamientos del sistema en objetos que jueguen roles bien definidos.
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.
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.
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.
Estereotipos útiles Los siguientes son estereotipos útiles:
Information Holder: conoce y provee información. Structurer: mantiene relaciones entre los objetos, así como
también información de estas relaciones. Service Provider: 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 Service Provider que maneja de forma privada la información necesaria para éste rol: 1 Rol con 2 Responsabilidades).
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.
Objetos colaborando para resolver problemas mayores que los que pueden resolver solos …
Un Objeto
Conoce información
Mantiene conexiones (a otros objetos)
Ejecuta Servicios
Toma decisiones(para hacer lo
correcto)
Un Objeto
Mensaje solicitando
ayuda
“Una aplicación es una comunidad de objetos
trabajando juntos. Colaboran enviando
mensajes y recibiendo respuestas.
Contribuyen con su Conocimiento y
Servicios”
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.
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á.
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.
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.
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.
Modelo de Dominio
Una Orden
Un Producto
Un Cliente
Un Descuento Una Regla
de Embarque
Una Historia
Crediticia
Una Revisión del Stock
Relaciones
Información
Servicios
Reglas
Procesos
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.
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.
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).
Modelo de Dominio
Una Orden
Un Producto
Un Cliente
Un Descuento Una Regla
de Embarque
Una Historia
Crediticia
Una Revisión del Stock
Relaciones
Información
Servicios
Reglas
ProcesosControl
Interfases
Coordinación
Un verificador de crédito
Un gestor de órdenes
Una ventana
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.
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 Interfase manifiesta 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.
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.
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.
Dos roles: la clase actuando como Fábrica
Un objetoClase
Clientenew
Un cliente
Un cliente
Un cliente
Dos roles: la clase actuando como Fábrica
Un objetoClase
Cliente como
colaborador
Solicitudes porInformación y Serviciosrelacionados con el Cliente
Necesita ayuda
Ofrece ayuda como cualquierotro objeto
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.
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.
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.
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.
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.
Confederación de objetos
Empresa FinancieraACME
Ley ACME
Licenciado
Tu Agente Su asistenteConceptualmente nohay diferencia entre las responsabilidades
de un Objeto y un Subsistema
Tu proveedor de servicio
Un solo objeto que representapúblicamente a todos los objetos
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.
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.
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.
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.
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.
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.
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.
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).
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
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.
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.
Estilo de Control Centralizado
La lógica inicia y
termina aquí …
Los objetos manejan
información…
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.
Estilo de Control Disperso: no centralizado
La lógica inicia aquí … La lógica
finaliza aquí …
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.
Estilo de Control Delegado
La lógica inicia aquí
…
Los coordinadores manejan cada
paso…
La lógica termina aquí …
Los Objetos conocen y hacen algún sub-paso…
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.
Estilo de Capas (aplicación Web)
Presentación
Control y Coordinación de
Aplicación
Servicios e Información del
Dominio
Servicios de Base de Datos y Sistemas
Legados
Browsers…
Servidor Web…
Servidor de Aplicaciones…
Servidor de Base de Datos…
Cada capa tiene roles de objetos característicos…
Presentación
Servicios de Aplicación
Servicios del Dominio
Servicios Técnicos
Interfases (ventanas y
widgets)
Coordinadores y Controladores (de Aplicación)
Contenedores de Información,
Proveedores de Servicios,
Estructuradores, Coordinadores y Controladores de
Dominio
Intefases
Eventos
Resultados
Mensajes
Resultados
Mensajes
Resultados
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).