La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Ing. Darío Guillermo Cardacci Centro de Altos Estudios en Tecnología Informática Facultad de Tecnología Informática Universidad Abierta Interamericana.

Presentaciones similares


Presentación del tema: "Ing. Darío Guillermo Cardacci Centro de Altos Estudios en Tecnología Informática Facultad de Tecnología Informática Universidad Abierta Interamericana."— Transcripción de la presentación:

1 Ing. Darío Guillermo Cardacci Centro de Altos Estudios en Tecnología Informática Facultad de Tecnología Informática Universidad Abierta Interamericana. Montes de Oca 745. Capital Federal. Argentina

2 MOTIVACIÓN El diseño de software es naturalmente difícil, incluso utilizando buenas técnicas Diseñar la experiencia es valiosa Sin embargo ¿Cómo capturar, representar, transmitir y reutilizar todo esto?

3 OTROS PROBLEMAS Rigidez Fragilidad Inmovilidad del código Flexibilidad Extensibilidad Complejidad

4 CUÁL ES LA MEJOR SOLUCIÓN ¿Implementar métodos concretos en sub clases concretas? ¿Delegar en clases menos especializadas dentro de una jerarquía (super clases)? ¿Componer o heredar? ¿Inversión de control o control directo? ¿Definir clases abstractas? ¿Definir algoritmos abstractos? ¿Cuál es la mejor solución?

5 LOS HECHOS CONCRETOS Permanentemente adquirimos experiencia Dominio Problema No se transmite en forma ordenada Los expertos aprenden por ensayo y error Los expertos manejan un metalenguaje ad-hoc

6 QUÉ ES UN PATRON "Un patrón describe un problema que ocurre una y otra vez en un contexto, así como la solución, de tal manera que se puede usar millones de veces más adelante sin tener que volver a pensarla otra vez "

7 1977. Publicó A Pattern Language: Towns, Buildings, Construction Publicó The Timeless Way of Building. QUIÉN FUE CHRISTOPHER ALEXANDER

8 1987. Ward Cunningham y Kent Beck publicaron un artículo en OOPSLA-87 (Object-Oriented Programming, Systems, Languages, and Applications) titulado Using Pattern Languages for OO Programs, 5 patrones HCI (interacción hombre-ordenador) 90's Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides (GoF - Gang of Four) publicaron el libro Design Patterns: Elements of Reusable Object- Oriented Software en el que se recopilaban 23 patrones de diseño.Erich Gamma Design Patterns HITOS

9 Coplien y Schmidth. Pattern Languages of Program Design Bushmann et al. Pattern-Oriented Software Architecture: A System of Patterns HITOS

10 TIPOS DE PATRONES de Diseño de Arquitectura de Análisis de Testing para Web para Ambientes Distribuidos de Negocios de Procesos y Organizacionales …

11 LENGUAJE DE PATRÓN En diseño, un lenguaje de patrón es un método estructurado para describir una serie de buenas prácticas de diseño en un área particular. Descubrir y nombrar los problemas más comunes en el campo de interés. Describir las características principales de las soluciones efectivas para llegar al objetivo marcado. Ayudar al diseñador a moverse de un problema a otro de una forma lógica.

12 CÓMO DOCUMENTAR UN PATRÓN "Contexto" - ¿Bajo qué condiciones resolverá esta solución el problema? "Sistema de fuerzas" - Se puede considerar como el problema o el objetivo "Solución" - Una configuración que pone las fuerzas en equilibrio o resuelve el problema presentado

13 CARACTERÍSTICAS DE UN PATRÓN Resolver un problema recurrenteCon una solución probadaQue no sea evidenteSe describe de manera abstracta UN PATRÓN SE DESCUBRE NO SE INVENTA

14 ELEMENTOS DE UN PATRÓN SEGÚN GoF Nombre del patrón: Nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan 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. Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.

15 ELEMENTOS DE UN PATRÓN SEGÚN GoF 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: 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.

16 ELEMENTOS DE UN PATRÓN SEGÚN GoF 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.

17 PATRONES DE GoF

18 ANTIPATRONES Los antipatrones son soluciones negativas que presentan más problemas que los que solucionan. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. William J. Brown, Raphael C. Malveau, Thomas J. Mowbray

19 ANTIPATRONES ¿Por qué estudiar antipatrones? Proveen experiencia del mundo real para reconocer problemas recurrentes en la industria del software, ofreciendo también una solución para sus implicaciones más comunes. Establecen un vocabulario común para identificar problemas y discutir soluciones. Un buen programador procurará evitar los antipatrones siempre que sea posible, lo que requiere su reconocimiento e identificación.

20 ANTIPATRONES DE DISEÑO Acoplamiento secuencial ( sequential coupling ): Construir una clase que necesita que sus métodos se invoquen en un orden determinado. BaseBean: Heredar funcionalidad de una clase utilidad en lugar de delegar en ella. Fallo de clase vacía ( empty subclass failure ): Crear una clase que no supera el test de la subclase vacía, es decir, que se comporta de manera diferente cuando se invoca desde una subclase que añade modificación alguna. Llamar a super ( callsuper ): Obligar a las subclases a llamar a un método de la superclase que ha sido sobrescrito. Modelo de dominio anémico ( anemic domain model ): Usar un modelo del dominio sin ninguna lógica de negocio. Esto no es un enfoque orientado a objetos porque cada objeto debería tener tanto propiedades como comportamiento asociado. Objeto sumidero ( object cesspool ): Reusar objetos no adecuados realmente para el fin que se persigue.

21 ANTIPATRONES DE DISEÑO Objeto todopoderoso ( god object ): Concentrar demasiada funcionalidad en una única parte del diseño (clase). Poltergeist : Emplear objetos cuyo único propósito es pasar la información a terceros objetos. Problema del círculo-elipse ( circle-ellipse problem ): Crear variables de tipo pensando en los valores de posibles subtipos. Problema del yoyó ( yo-yo problem ): Construir estructuras (por ejemplo, de herencia) que son difíciles de comprender debido a su excesiva fragmentación. Singletonitis: Abuso de la utilización del patrón singleton. YAFL ( yet another layer, y otra capa más): Añadir capas innecesarias a un programa, biblioteca o framework. Esta tendencia se extendió bastante después de que se publicase el primer libro sobre patrones.

22 EJEMPLO Una aplicación necesita tener una y solo una instancia de una clase determinada.

23

24

25

26

27

28 Referencias [Alexander79] Alexander, Christopher: A Timeless Way of Building, Oxford University Press, [AIX77] Alexander, Christopher et al.: A Pattern Language, Oxford University Press, [BMMM98] Brown, W., Malveau, R., Mc Cormick III, H., Mowbray, T.: Antipatterns: Refactoring Software, Architectures and Project in Crisis, Wiley and Sons, [Buschman96] Buschmann, Frank et al.: Pattern Oriented Software Architecture, Volume 1: A System of Patterns, Willey & Sons, [Cueva04] Cueva Lovelle, Juan Manuel: Tecnología de Objetos: Patrones de Diseño, [Evitts00] Evitts, Paul: A UML Pattern Language, SAMS Publishing, [Fowler03] Fowler, Martin: Enterprise Application Architecture Patterns, Addison Wesley, [Fowler97] Fowler, Martin: Analysis Patterns: Reusable Object Models, Adisson Wesley, [Fowler99] Fowler, Martin: Refactoring: Improving the Design of Existing Code, Adisson Wesley, [Gall75] Gall, John: Systemantics: How Systems Work and Especially How They Fail, New York, Quadrangle, [GoF95] Gamma E., Helm, R., Johnson, R., Vlissides J.: Design Patterns: Elements of Reusable Object Oriented Software, Addison Wesley, [Hillside03] Hillside Group: Home of the Patterns Library, [Hophe03] Hophe, Gregor, Woolf, Robert: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Addisson Wesley, [Kerievsky04] Kerievsky, Joshua: Refactoring to Patterns, Addison-Wesley, [McCormick98] McCormick, Hays: Antipatterns Tutorial, [Microsoft03] Microsoft Corp: Enterprise Solution Patterns, Microsoft Press, [Microsoft04] Microsoft Corp: Enterprise Development Reference Architecture, Microsoft Press, [PPR04] C2 WikiWikiWeb: Portland Pattern Repository [SAG04] Software Architecture Group at University Illinois at Urbana-Champaign, [ST01] Shalloway, Alan; Trott James: Design Patterns Explained: A New perspective on Object Oriented Design, Pearson Education, [Vlissides98] Vlissides, John: Pattern Hatching: Design Patterns Applied, Addison Wesley, 1998.

29 Gracias por su atención UAI – Rosario 2007


Descargar ppt "Ing. Darío Guillermo Cardacci Centro de Altos Estudios en Tecnología Informática Facultad de Tecnología Informática Universidad Abierta Interamericana."

Presentaciones similares


Anuncios Google