Aspectos Avanzados de la Tecnología de Objetos

1. Aspectos Avanzados de laTecnología de Objetos 3. Modelo de objetos representados en los lenguajes de programación Dr. Juan José Aranda Aboy

2. Contenidos • Identificación de requisitos. • Patrones de diseño de la “pandilla de los cuatro” (Gang of Four - GoF). • Diseño de objetos con responsabilidades: Patrones GRASP. • Diagramas de secuencia y contratos de operaciones. Dr. Juan José Aranda Aboy

3. Objetivos específicos • Conocer cómo definir apropiadamente los requisitos del sistema. • Definir los patrones. • Aprender a aplicar los patrones GRASP y GoF al diseño de casos. Dr. Juan José Aranda Aboy

4. Introducción • Aún existe un espacio vacío entre la academia y la industria respecto al desarrollo de software. • Los problemas del mundo real son: • Complejos: integrados por millones de líneas de código; • Diversos respecto a plataformas: hardware, sistemas operativos y lenguajes; • Basados en trabajo de equipos: reusabilidad, seguridad, tratamiento de errores; y • Dinámicos: su éxito depende de la adaptación a los nuevos cambios. Dr. Juan José Aranda Aboy

5. Para la demanda del mundo real El mundo académico ha desarrollado: • El diseño orientado a objetos - DOO (Object-Oriented Design – OOD) • Los patrones de diseño (Design Patterns – DP) • Los marcos para desarrollo (Frameworks) • Las componentes (Components) • Otras tecnologías y herramientas, como: • Diseño por contrato (Design By Contract) • Programación extrema (Extreme Programming – XP) Dr. Juan José Aranda Aboy

6. Algunos elementos • Con alto costo, excelentes prestaciones: • Sun, IBM, Microsoft, Oracle, … • Frameworks: • MFC, Swing, Struts, JSF, … • Frameworks de Componentes: • COM, JavaBeans • Frameworks para Computación Distribuida: • CORBA, COM+, EJB, .NET Dr. Juan José Aranda Aboy

7. Algunas herramientas • Alto costo … • Borland Toghether, IBM Rational, Enterprise Architect, Visual Paradigm, … • Entornos integrados para desarrollo (Integrated Development Environments - IDE) • NetBeans, Eclipse, JBuilder, Visual Studio, … • Herramientas para diseño (Design Tools) y editores UML. • Control de la configuración. • Herramientas para comprobación (Testing Tools). Dr. Juan José Aranda Aboy

8. Causas del rediseño de sistemas • Dependencia de la plataforma de hardware o de software. • Dependencia de la representación o de la implementación • Especificación de una clase posteriormente a la creación del sistema • Dependencia de algoritmos • Acople demasiado estrecho • Abuso de la herencia. • Poca habilidad para cambiar clases de manera simple. • Etc. Dr. Juan José Aranda Aboy

9. Reutilización ¿Qué se puede reutilizar? • La Arquitectura • El Código • El Diseño • La Documentación • Las Pruebas desarrolladas ¿Por qué reutilizar? • Ahorra tiempo y esfuerzo de desarrollo. • Aumenta la confiabilidad de los productos. • Reduce el tiempo de ciclo de mercado • Centra la atención de los desarrolladores en la modularidad. • Evita emplear tiempo en tareas rutinarias ajenas a la lógica del negocio. Dr. Juan José Aranda Aboy

10. Fundamentación • En este complejo mundo real, existen muchas cosas, pero … • Realizan solamente una parte (pequeña) de la tarea. • No “arreglan” los errores humanos. • Tienen una elevada curva de aprendizaje. • Requieren una arquitectura. • En consecuencia, necesitamos aún conocer muchas cosas. • El diseño orientado a objetos OOD es la base existente actualmente para alcanzar estos objetivos. Dr. Juan José Aranda Aboy

11. Características del OOD • El diseño orientado a objetos es difícil. • Los errores son caros. • Se reutiliza el diseño realizado por expertos. • Puede afirmarse que Patrón = Experiencia Documentada • Los beneficios esperados son: • Obtener las clases correctas con mayor rapidez. • Lenguaje técnico común para diseño. • Formato consistente. • Infraestructuras codificadas. Dr. Juan José Aranda Aboy

12. Categorías de patrones • Los patrones existen en casi todas las áreas de la Ingeniería de Software, siendo utilizados mas para describir el proceso que el artefacto que se obtiene. • Según la escala o nivel de abstracción, se clasifican en: • Patrones arquitecturales: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas software. Promueven poco acoplamiento entre subsistemas. Especifican como deben interacuar subsistemas entre si. Ejemplo: Modelo – Vista – Controlador (MVC) • Patrones de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas software. • Idiomas: Patrones de bajo nivel específicos para un lenguaje de programación o entorno concreto. • Además, también es importante reseñar el concepto de Antipatrón de Diseño, que con una forma semejante a la de un patrón, intenta proporcionar soluciones a problemas comunes que generan consecuencias negativas en el software. • En esta unidad trabajaremos solamente los patrones de diseño. Dr. Juan José Aranda Aboy

13. Programación orientada a objetos (OOP) • Sabemos que una interfaz es un contrato para sus clientes. • Una clase implementa interfaces. • Los objetos son instancias de clases que solamente pueden accederse mediante sus interfacespúblicas. • La idea es que existan solamente dos relaciones entre clases: • Herencia : Estática y eficiente, pero expone y acopla módulos. • Composición : Esconde mejor los detalles ante el cliente y permite cambios dinámicamente. • Una tendencia central, explicitada por el grupo de los cuatro (Gang of Four - GoF) compuesto por Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides; es favorecer el empleo de la Composición sobre el uso de la Herencia. Dr. Juan José Aranda Aboy

14. Patrones de Diseño (Design Patterns) • Son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. • Un patrón de diseño es una solución a un problema no trivial de diseño que es • Efectiva: ya se resolvió el problema satisfactoriamente en ocasiones anteriores; y • Reusable: se puede aplicar a diferentes problemas de diseño en distintas circunstancias. Dr. Juan José Aranda Aboy

15. Breve reseña histórica • En 1979 el arquitecto Christopher Alexander aportó al mundo de la arquitectura el libro “The Timeless Way of Building”, en el que proponía el aprendizaje y uso de una serie de patrones para construir edificios de mayor calidad: "Cada patrón describe un problema que ocurre 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." • Dichos patrones, publicados en “A Pattern Languaje”, son un intento de formalizar y plasmar de una forma práctica generaciones de conocimiento arquitectónico. • Los patrones no son principios abstractos que requieran su redescubrimiento para obtener una aplicación satisfactoria ni son específicos a una situación particular o cultura, son algo intermedio. Dr. Juan José Aranda Aboy

16. Breve reseña histórica (2) • Un patrón define una posible solución correcta para un problema de diseño dentro de un contexto dado, describiendo las cualidades invariantes de todas las soluciones. • Más tarde, en 1987, Ward Cunningham y Kent Beck usaron varias ideas de Alexander para desarrollar cinco patrones de interacción hombre-ordenador (HCI) y publicaron un artículo en OOPSLA-87 titulado “Using Pattern Languages for OO Programs”. • No obstante, no fue hasta principios de los 90's cuando los patrones de diseño tuvieron un gran éxito en el mundo de la informática a partir de la publicación del libro “Design Patterns” escrito por el GoF, en el que se recogían 23 patrones de diseño comunes. Dr. Juan José Aranda Aboy

17. Objetivos de los patrones de diseño Los patrones de diseño pretenden: • Proporcionar catálogos de elementos reusables en el diseño de sistemas software. • Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente. • Formalizar un vocabulario común entre diseñadores. • Estandarizar el modo en que se realiza el diseño. • Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente. Asimismo, no pretenden: • Imponer ciertas alternativas de diseño frente a otras. • Eliminar la creatividad inherente al proceso de diseño. • No es obligatorio utilizar los patrones siempre, sólo en el caso de tener el mismo problema o similar al que soluciona el patrón, pero teniendo en cuenta siempre que en un caso particular puede no ser aplicable. Abusar o forzar el uso de los patrones puede ser un error. Dr. Juan José Aranda Aboy

18. Estructuras o plantillas de patrones • Para describir un patrón se utilizan plantillas más o menos estandarizadas de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicación entre diseñadores. • Varios autores han propuesto plantillas distintas, pero que definen los mismos conceptos básicos. • La plantilla comúnmente utilizada es la desarrollada por el GoF; y consta de los apartados: • Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente en inglés). • Clasificación del patrón: Creacional, Estructural o de Comportamiento. • Intención: ¿Qué problema resuelve el patrón? • También conocido como: Otros nombres de uso común para el patrón. • Motivación: Escenario de ejemplo para la aplicación del patrón. • Aplicabilidad: Criterios de aplicabilidad del patrón. Dr. Juan José Aranda Aboy

19. Estructuras o plantillas de patrones (2) • Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón. • Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón. • Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes. • Consecuencias: Positivas y negativas en el diseño derivadas de la aplicación del patrón. • Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón. • Código de ejemplo: Código fuente ejemplo de implementación del patrón. • Usos conocidos: Ejemplos de sistemas reales que usan el patrón. • Patrones relacionados: Referencias cruzadas con otros patrones. Dr. Juan José Aranda Aboy

20. Categorías de patrones de diseño • Creacionales (Creational)– Reemplazan los problemas explícitos de creación, evitando dependencias de la plataforma. Tratan las cuestiones relacionadas con la creación de objetos. GoF describe cinco. • Estructurales (Structural)– Describen maneras comunes de organizar las clases y objetos en un sistema. Manejan clases sin cambios, bajo acoplamiento y ofrecen alternativas a la herencia. GoF describe siete. • Comportamiento (Behavioral) – Proporcionan estrategias para modelar como los objetos colaboran entre si en un sistema y ofrecen comportamientos especiales apropiados para una amplia variedad de aplicaciones. Ocultan la implementación y algoritmos, por lo que permiten configurar los objetos de manera sencilla y dinámica. GoF describe once. Dr. Juan José Aranda Aboy

21. Patrones Creacionales • Abstract Factory (Fábrica abstracta): Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre sí y haciendo transparente el tipo de familia concreta que se esté usando. • Builder (Constructor virtual): Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto. • Factory Method (Método de fabricación): Centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística para elegir el subtipo que crear. • Prototype (Prototipo): Crea nuevos objetos clonándolos de una instancia ya existente. • Singleton (Instancia única): Garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia. Dr. Juan José Aranda Aboy

22. Patrones Estructurales • Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podría utilizarla. • Bridge (Puente): Desacopla una abstracción de su implementación. • Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase. • Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente. • Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema. • Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información. • Proxy : Mantiene un representante de un objeto. Dr. Juan José Aranda Aboy

23. Patrones de Comportamiento • Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada. • Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma. • Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo. • Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos. • Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto. • Memento (Recuerdo): Permite volver a estados anteriores del sistema. Dr. Juan José Aranda Aboy

24. Patrones de Comportamiento (2) • Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de él. • State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno. • Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución. • Template Method (Método plantilla): Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura. • Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de clases sin modificar las clases sobre las que opera. Dr. Juan José Aranda Aboy

25. Patrones de diseño GoF en NB55 Dr. Juan José Aranda Aboy

26. Patrones de diseño EJB Dr. Juan José Aranda Aboy

27. Aplicación en ámbitos concretos • Además de su aplicación directa en la construcción de software en general, y derivado precisamente del gran éxito que han tenido, los patrones de diseño han sido aplicados a múltiples ámbitos concretos produciéndose lenguajes de patrones y catálogos completos. En particular : • Patrones de interfaces de usuario; esto es, aquellos que intentan definir las mejores formas de construir interfaces hombre-máquina (HCI, GUI). • Patrones para la construcción de sistemas empresariales, en donde se requieren especiales esfuerzos en infraestructuras software y un nivel de abstracción importante para maximizar factores como la escalabilidad o la mantenibilidad del sistema. • Patrones para la integración de sistemas (EAI), es decir, para la intercomunicación y coordinación de sistemas heterogéneos. • Patrones de workflow, esto es para la definición, construcción e integración de sistemas abstractos de gestión de flujos de trabajo y procesos con sistemas empresariales: BPM . Dr. Juan José Aranda Aboy

28. Catálogo de Patrones J2EE (Core J2EE Patterns) Dr. Juan José Aranda Aboy

29. Patrones GRASP • El diseño de objetos se describe como: Después de identificar requisitos y crear el modelo del dominio, añada métodos a las clases y defina el paso de mensajes entre los objetos para satisfacer sus requisitos. • La decisión acerca de cuales métodos y donde colocarles, así como de la interacción entre objetos es importante. • Hace falta una explicación cuidadosa que sea aplicable mientras se realizan los diagramas y la programación. • Para esto, utilizaremos los Patrones Generales de Software para Asignación de Responsabilidades (General Responsibility Assignment Software Patterns-GRASP), que son un conjunto de "Buenas Prácticas" de aplicación recomendables en el diseño de software. Dr. Juan José Aranda Aboy

30. ¿Por qué GRASP? • Los patrones GRASP describen los principios fundamentales del diseño de objetos y la asignación de responsabilidades, expresados como patrones. • Son pares problema / solución con un nombre que codifican buenos consejos y principios relacionados con la asignación de responsabilidades. • Constituyen un apoyo para la enseñanza que ayuda a la comprensión acerca del diseño de objetos esencial, y aplica el razonamiento para el diseño de manera sistemática, racional y explicable. • Con ellos es posible comunicar los principios básicos detallados y el razonamiento que se requiere para entender el diseño de objetos general. • La asignación hábil de responsabilidades es extremadamente importante en el diseño de objetos. • Lo patrones de GRASP no compiten con los patrones de diseño, sino que ayudan a encontrarlos. Los patrones de diseño son más concretos. Dr. Juan José Aranda Aboy

31. Responsabilidades y métodos • UML define una responsabilidad como un contrato u obligación de un clasificador. • Están relacionadas con las obligaciones de un objeto en cuanto a su comportamiento. • Se asignan a las clases de los objetos durante el diseño de objetos. • Su granularidad influirá en la conversión de responsabilidades a clases y métodos. • Los métodos se implementan para cumplir con responsabilidades, pero una responsabilidad puede utilizar métodos que actúan solos ó que colaboran con otros objetos ó métodos. Dr. Juan José Aranda Aboy

32. Tipos de responsabilidades Básicamente, son dos: • Conocer • Conocer los datos privados encapsulados • Conocer los objetos relacionados • Conocer las cosas que puede derivar ó calcular • Hacer • Hacer algo él mismo, como crear un objeto ó realizar un cálculo • Iniciar una acción en otros objetos • Controlar y coordinar actividades entre objetos. Dr. Juan José Aranda Aboy

33. Responsabilidades e interacción • Los diagramas de interacción muestran elecciones en la asignación de responsabilidades a los objetos. • Cuando se crean, ya se han tomado decisiones acerca de las responsabilidades, lo que se refleja en los mensajes que envían a las diferentes clases de objetos. • La decisión respecto a la asignación de responsabilidades tiene su inicio durante la creación de los diagramas de interacción. Dr. Juan José Aranda Aboy

34. Catálogo de patrones GRASP (1) • Experto en Información: Soluciona como asignar una responsabilidad al experto en información. • Creador: Asignar a una clase la responsabilidad de crear instancias de otra clase. • Alta cohesión: Asignar una responsabilidad de modo que la cohesión permanezca alta. • Bajo acoplamiento: Asignar una responsabilidad de modo que el acoplamiento permanezca bajo. • Variaciones permitidas:Es el principio fundamental de protegerse del cambio. Todo lo que es susceptible de modificaciones, quedará lo menos ligado posible, de forma que cuando se produzca la variación, repercuta lo mínimo. • Controlador: Asignar la responsabilidad de recibir o manejar un mensaje de evento del sistema a una clase que representa el sistema global, dispositivo ó subsistema (fachada) ó un escenario de caso de uso en el que tiene lugar el evento del sistema. Dr. Juan José Aranda Aboy

35. Catálogo de patrones GRASP (2) • Fabricación pura: Cuando los problemas se complican, construir clases que se encarguen de construir los objetos adecuados en cada momento: factorías. • Polimorfismo: Cuando se identifican variaciones en un comportamiento, asignar la clase (interfaz) al comportamiento y utilizar polimorfismo  para implementar los comportamientos alternativos. • Indirección: Crear clases intermedias para desacoplar a los servicios de los clientes de dichos servicios. • No hables con extraños: Un método solamente invocará a métodos de: • el mismo objeto (this). • su área de parámetros. • otro objeto creado en su propio ámbito. Dr. Juan José Aranda Aboy

36. Comentarios • Aunque los principios anteriores pueden parecer muy evidentes, es complicado llevarles a cabo en proyectos reales. Hay varios factores que lo dificultan: • La presión del día a día por producir resultados, aunque sean de baja calidad. • La planificación de proyectos a coste fijo y a precios bajos, que quita las ganas de pararse a pensar: ¡más con 50 horas semanales de trabajo! • La poca inversión en formación de muchas empresas debido al modelo de servicios puro propiciado en los últimos años. • Falta de personas de referencia que enseñen y con quienes aprendamos juntos en los equipos de desarrollo. Dr. Juan José Aranda Aboy

37. Ejercicio individual • Estudie el patrón de diseño asignado y prepare un breve informe sobre el mismo. • Determine si el patrón de diseño que le fue asignado puede emplearse en el diseño de nuestro “Sistema de Votación Electrónico”. Caso afirmativo: describa cómo. • NOTA: Utilice como referencia adicional: • Object Oriented Design Directory , en particular las presentaciones incluidas en el archivo oodcourse.zip • “Patterns In Java” Dr. Juan José Aranda Aboy

38. Textos • Larman, C. “UML y Patrones” 2da ed. Pearson Prentice Hall, 2004 (URL en inglés) • Deitel & Deitel “Java, como programar” 5ta ed. Pearson Prentice Hall, 2004 • Eckel, B. “Thinking in Patterns with Java” • Grand, M. “Patterns In Java” • Overview of Design Patterns • 50 patterns • Java Enterprise Design Patterns • Stevens, P. & Pooley,R. “Utilización de UML en Ingeniería del Software con Objetos y Componentes”, Addison Wesley, 2002 (en inglés: “Using UML: software engineering with objects and components”) Dr. Juan José Aranda Aboy

39. Referencias en Internet • Catálogo de Patrones de Diseño J2EE. I.- Capa de Presentación • Catálogo de Patrones de Diseño J2EE. Y II: Capas de Negocio y de Integración • Patrones de GRASP • Wikipedia: • Programación Orientada a Objetos • Patrón de diseño • GRASP • Análisis y Diseño Orientado a Objetos (ADOO) - Curso 2006-2007 Dr. Juan José Aranda Aboy

40. Referencias en Internet(en inglés) • Design Patterns • Pattern Catalog • Object Oriented Design Directory (oodcourse.zip) • The Design Patterns Java Companion • Core J2EE Patterns: Patterns index page • Design Patterns in Java Microsoft • MSDN Domain-Specific Language Tools • MSDN Software Factories • Microsoft patterns & practices Developer Center • Patterns & practices: Web Applications • MSDN Solution Architecture Center Dr. Juan José Aranda Aboy