Vous êtes sur la page 1sur 6

Anlisis y Especificacin de Sistemas Multimedia

Tema Complementario III:


Patrones de Diseo, Refactorizacin y Antipatrones. Ventajas y Desventajas de su utilizacin en el Software Orientado a Objetos

Carles Escriv Cant Rubn Dur Esquembre Antonio Mudarra Martnez Jorge Lilao Chinchilla #AESMcooking

Tema complementario III AESMcooking UA.

ndice
1. 2. 3. Introduccin. .............................................................................................................................. 2 Patrones de Diseo. .................................................................................................................... 2 Refactorizacin. .......................................................................................................................... 3 3.1. 3.2. 3.3. 3.4. 4. 4.1. 4.2. 4.3. 4.4. 4.5. Proceso de refactorizar. ....................................................................................................... 3 Importancia de las pruebas en el desarrollo de software. ............................................... 3 Aspectos favorables. ............................................................................................................ 3 Aspectos desfavorables........................................................................................................ 3 Relacin con patrones de diseo y refactorizaciones. ...................................................... 4 Puntos de vista. .................................................................................................................... 4 Componentes. ....................................................................................................................... 4 Un proceso para el uso de antipatrones. ............................................................................ 4 Catlogo de antipatrones de desarrollo. ............................................................................ 4 The Blob (God Class o Winnebago). ............................................................................. 4 Lava Flow (Dead Code). ................................................................................................ 5 Functional Decomposition (No object oriented AntiPattern). ....................................... 5 Poltergeists (Gipsy, o Proliferation of Classes, o Big DoIt Controller Class). .............. 5 Golden Hammer (Old Yeller, o Head in the Sand). ....................................................... 5 Spaghetti Code. .............................................................................................................. 5

Antipatrones. .............................................................................................................................. 4

4.5.1. 4.5.2. 4.5.3. 4.5.4. 4.5.5. 4.5.6.

4.5.7. Copy-And-Paste Programming (Clipboard coding, Software clonning, o Software propagation). ................................................................................................................................ 5 5. Conclusiones. .............................................................................................................................. 5

Tema complementario III AESMcooking UA.

1. Introduccin.
Hablamos de los conceptos de Patrones de Diseo, Refactorizacin y Antipatrones, y el como su uso aporta una serie de ventajas y desventajas en el desarrollo de software orientado a objetos. Por patrones de diseo y antipatrones entendemos las prcticas buenas y malas a la hora de enfrentarnos a un problema y como hacerle frente, as tambin el cmo prevenirlo. Por Refactorizacin hablamos de la transformacin del cdigo para un mejor entendimiento y mayor simplicidad. Entendemos que si bien la evolucin de la ingeniera del software, las tcnicas estructuradas, los lenguajes de cuarta generacin, las herramientas CASE, la orientacin a objetos y ms, han mejorado los productos software finales, an es necesario mejorar estos resultados. La orientacin a objetos ha resuelto numerosos problemas y abierto muchas puertas, cosas como el encapsulamiento, la herencia o el polimorfismo, aunque muy buenos, no terminan de funcionar por si solos para crear software flexible. En este contexto surge este documento para aclarar esos tres conceptos, Patrones de Diseo, Refactorizacin y Antipatrones, estrechamente relacionados con la experiencia adquirida en el desarrollo de software.

2. Patrones de Diseo.
En esencia y simplificando mucho, un patrn de diseo es una solucin a un problema comn durante el desarrollo de software. Originalmente concebidos para el mundo de la arquitectura, y adaptados posteriormente al mundo de desarrollo de software, los patrones de diseo son un conjunto de normas, de mtodos que se aplican a un determinado problema que se ve repetido en cada desarrollo. En estos patrones se intenta formalizar un vocabulario comn entre diseadores. Su objetivo, adems es el de proporcionar multitud de elementos reusables en el diseo de software, evitando as la reiteracin en la bsqueda de soluciones a problemas ya conocidos y solucionados anteriormente. En ningn caso pretenden imponer esas soluciones frente a otras o suprimir la creatividad del proceso creativo. Los patrones de diseo podramos categorizarlos en tres bloques, que dependen de su objetivo y del nivel de abstraccin en el que son usados. Patrones de arquitectura. Definen una estructura fundamental sobre la organizacin del sistema, se centran en la arquitectura a nivel global. Patrones de diseo. Sirven para subsistemas, algo ms especifico que los patrones de arquitectura, se suelen centrar en mtodos o componentes del sistema, no al sistema en general. Patrones de codificacin o Dialectos. Estos patrones se centran en un lenguaje especfico y en los elementos de diseo ligados a este lenguaje en particular. En general, dependiendo del autor los patrones siguen un mtodo, pero se podra decir que todas se rigen ms o menos por unos estndares, unas plantillas con gran cantidad de elementos comunes. Segn el libro original gracias al cual ganaron popularidad los patrones de diseo, Gang Of Four, en este libro los autores establecan 23 patrones de diseo diferentes, ordenados en tres grupos: Patrones creacionales. Centrados en la instanciacin, intentan una abstraccin de la instanciacin de objetos, ayudando al sistema a ser independiente de este proceso. Patrones estructurales. Se encargan de cmo funciona la herencia y cmo gracias a esta se van creando clases cada vez ms grandes. Patrones de comportamiento. Tienen que ver con algoritmos y asignacin de responsabilidades, las formas de organizar los controles en el sistema ayudan a optimizar y maximizar el mantenimiento y la eficacia.

Tema complementario III AESMcooking UA.

3. Refactorizacin.
Una refactorizacin sirve para limpiar el cdigo, minimizando la probabilidad de introducir errores y a su vez hacerlo mas comprensible y fcil de mantener. La refactorizacin consiste en una transformacin controlada del cdigo fuente que no altera su comportamiento. Podemos utilizar un mal cdigo y transformarlo en un cdigo utilizable para el proyecto.

3.1.

Proceso de refactorizar.

Para poder refactorizar de forma satisfactoria es indispensable que los casos de prueba cumplan con los siguientes requisitos: Deben ser automticos de manera tal que se puedan ejecutar todos a la vez con simplemente hacer clic un botn; Deben ser auto verificables de manera tal de no invertir tiempo en la verificacin de los resultados de los mismos. Estos errores deben ser reportados por cada caso de prueba; Deben ejecutarse de manera independiente uno del otro, de manera tal que los resultados de uno no afecten los resultados del resto.

El primer paso del proceso de refactorizacin es ejecutar las pruebas antes de haber efectuado cualquier cambio. El segundo paso, consiste en analizar los cambios a realizar, y el tercero es, finalmente, la aplicacin del cambio.

3.2.

Importancia de las pruebas en el desarrollo de software.

Las pruebas unitarias para el desarrollo de software realizan otros aportes al margen de comprobar que el cdigo funciona correctamente, entre los que se encuentran: Previenen pruebas de regresin y limitan el debug de cdigo. Facilitan la refactorizacin. Mejoran el diseo de implementacin.

3.3.

Aspectos favorables.

El proceso de refactorizacin tiene algunas ventajas, entre las cuales estn el mantenimiento del diseo del sistema, el incremento de la facilidad de comprensin del cdigo, deteccin de errores en las primeras etapas y un aumento en la velocidad de programacin. Adems de todo esto podemos aadir: La refactorizacin facilita la comprensin del cdigo fuente. La refactorizacin permite detectar errores. La refactorizacin permite programar ms rpido. La velocidad en la programacin se obtiene al reducir los tiempos que lleva la aplicacin de cambios.

3.4.

Aspectos desfavorables.

Los aspectos ms desfavorables de la refactorizacin son las bases de datos, teniendo problemas muy costosos y los cambios en las interfaces teniendo estas no muchas complejidades si se tiene acceso al cdigo fuente.

Tema complementario III AESMcooking UA.

4. Antipatrones.
Los antipatrones son el resultado de una mala decisin sobre como resolver un problema o la aplicacin correcta a un patrn de diseo errneo. Son descripciones de situaciones, o soluciones que producen consecuencias negativas.

4.1.

Relacin con patrones de diseo y refactorizaciones.

Al igual que los patrones de diseo, los antipatrones, proveen un vocabulario comn con el fin de mejorar la comunicacin en el equipo de desarrollo, de manera tal de poder identificar problemas y discutir soluciones. Ambos documentan conocimiento con el fin de ser distribuido para su utilizacin. Mientras que los patrones de diseo documentan soluciones exitosas, los antipatrones documentan soluciones problemticas.

4.2.

Puntos de vista.

Existen tres puntos de vista, o niveles, desde los cuales analizar los antipatrones. Ellos son: Desarrollo: describe situaciones encontradas por programadores en la resolucin de problemas de programacin. Arquitectura: estos antipatrones se centran en los problemas recurrentes relacionados a la estructura del sistema, sus consecuencias y soluciones. Administracin: Parte del trabajo de un gerente implica comunicarse con la gente, y resolver problemas.

4.3.

Componentes.

Los antipatrones estn formados por dos componentes: causas principales (root causes) y fuerzas principales (primal forces). El primer componente, las causas principales, son errores recurrentes presentes en el desarrollo de software cuyo resultado fue el fallo del proyecto, exceso de costos, atrasos de acuerdo a lo planificado u objetivos de negocio no cumplidos.

4.4.

Un proceso para el uso de antipatrones.

Estos son los seis pasos para el estudio de antipatrones : 1. 2. 3. 4. 5. 6. Encontrar el problema. Establecer un patrn de fallas. Refactorizar el cdigo. Publicar la solucin. Identificar debilidades, o posibles problemas del proceso. Corregir el proceso.

4.5.

Catlogo de antipatrones de desarrollo.

Los antipatrones de desarrollo de software describen problemas comunes con los que se encuentran los programadores durante el proceso de desarrollo. A continuacin se enumeran los antipatrones de desarrollos descriptos por (Brown et al, 1998).

4.5.1. The Blob (God Class o Winnebago).


Es una clase que conoce o hace demasiado, suele aparecer en diseos donde una clase monopoliza la
4

Tema complementario III AESMcooking UA.


mayora de los recursos del sistema y el resto de las clases solo encapsulan una pequea parte de informacin.

4.5.2. Lava Flow (Dead Code).


Aparece principalmente en aquellos sistemas que comenzaron como investigacin o pruebas de concepto y luego llegaron a produccin. La principal caracterstica de este anti patrn es la presencia de distintos flujos o corrientes de previos desarrollos que quedaron diseminados, y se hicieron inservibles.

4.5.3. Functional Decomposition (No object oriented AntiPattern).


Cuando desarrolladores experimentados en programacin estructurada, quienes se hallan cmodos con una rutina principal que llama a diversas subrutinas para realizar el trabajo, disean sistemas orientados a objetos suelen traducir sus diseos estructurados a orientados a objetos: traducen cada subrutina como una clase. El resultado de este anti patrn es cdigo estructurado representado en una jerarqua de clases, lo cual suele ser bastante complejo.

4.5.4. Poltergeists (Gipsy, o Proliferation of Classes, o Big DoIt Controller Class).


Las clases poltergeists (fantasmas) se caracterizan por tener pocas responsabilidades dentro del sistema y un ciclo de vida bastante breve, ya que aparecen solamente para iniciar algn mtodo en alguna clase, a menudo en un determinado orden. Son de relativa facilidad de encuentro ya que sus nombres suelen llevar el sufijo controller o manager. Estas clases desordenan el diseo ya que agregan abstracciones innecesarias, son excesivamente complejas, difciles de mantener y comprender.

4.5.5. Golden Hammer (Old Yeller, o Head in the Sand).


En martillo es cualquier tecnologa o herramienta que segn sus programadores es capaz de resolver muchos tipos de problemas y tambin es capaz de resolver algunos para los cuales no fueron programados.

4.5.6. Spaghetti Code.


Este anti patrn consiste en la dificultad de hacer cambios o extensiones por haber perdido claridad y comprensin el cdigo, incluso para el mismo programador.

4.5.7. Copy-And-Paste Programming (Clipboard coding, Software clonning, o Software propagation).


Este anti patrn se basa en al idea de que es mas fcil coger un cdigo que ya esta hecho y funciona, que empezar con un cdigo desde cero. Suele presentar un cdigo con trozos de cdigo muy parecido que suelen ser cogidos de otros programadores mas experimentados.

5. Conclusiones.
Est sobradamente demostrado que estos mtodos funcionan y gracias a su uso se logra agilizar el desarrollo y construir software de calidad y muy flexible. Segn el autor del documento esto se va a ir extendiendo poco a poco por todos los desarrollos hasta ser un estndar. El xito real es gracias a que la experiencia obtenida nos asegura unas soluciones a los problemas de manera rpida y eficaz, y adems se puede prever los posibles problemas anticipndonos a ellos. Por ltimo, el cdigo que acabamos generando aplicando estas formas, es mucho ms claro y optimizado. No son sino ventajas todo lo que nos ofrece realizar estas prcticas.