Cuellar Arteaga Marcos Jair 2691

Antipatrones
El antipatrn es una forma para capturar la experiencia de los desarrolladores para poder ser asimilada ms
fcilmente por otros desarrolladores.
Los antipatrones capturan las experiencias que repetidamente han arruinado el desarrollo de los proyectos de
software y ofrecen sugerencias de solucin a estas situaciones.
La idea que sobre la que descansan los antipatrones es la creencia de que es ms fcil detectar lo que se
hace mal que proveer un buen comportamiento.
Hay varios tipos de antipatrones:
Desarrollo de Software
Arquitectura de Software
Administracin de Proyectos de Software
Antipatrn Empresa con sistemas parchados (Stovepipe Enterprise)
Tambin conocido como: Islas de automatizacin
Escala: Empresa
Nombre de la correccin: Planeacin de la arquitectura para la empresa
Tipo de solucin: Proceso
Causas bsicas: Prisa, Apata.
Fuerzas desbalanceadas: Administracin de cambios, Recursos, Transferencia de Tecnologa
Evidencia anegdtica: " Podra tener mi isla (automatizada)? Soy el nico."
Forma General
En la empresa se desarrollan varios sistemas de manera independiente y a distintos niveles. Esto dificulta
iteroperabilidad, reuso e incrementa costos. Se crean islas automatizadas dentro de la misma empresa.
Sntomas y Consecuencias
Tecnologas incompatibles dentro de la misma empresa
Arquitecturas monolticas y no documentadas
Falta de posibilidad de extender los sistemas para satisfacer las necesidades de negocio
Falta de estndares
Falta de rehuso
Falta de interoperabilidad
Causas Tpicas
Falta de estrategia tecnolgica de la empresa
Falta de estndares
Falta de perfil de sistema
Falta de incentivos para la cooperacin en el desarrollo de sistemas
Falta de comunicacin
Falta de conocimiento sobre los estndares tecnolgicos
Falta de interfaces para la integracin de sistemas
Correccin
Es esencial coordinar la tecnologa a distintos niveles. Se necesitan definir estndares comunes que
implicarn la migracin de algunos sistemas. Se define la infraestructura comn y convenciones comunes
para los sistemas.

Antipatrn: Sistema parchado (Stovepipe System)

Tambin conocido como: Sistema heredado (Legacy system), Especial del To Sam, Integracin Ad Hoc
Escala: Sistema
Nombre de la correccin: Marco Arquitectnico
Tipo de correccin: Software
Causas bsicas: Prisa, Avaricia, Ignorancia, Pereza
Fuerzas desbalanceadas: Administracin de complejidad, cambios.
Evidencia anegdtica: " El dinero para el proyecto ya casi se acabo, hemos recorrido la fecha de entrega en
varias ocasiones, el usuario todava no tiene lo que le prometimos y yo no puedo modificar el sistema. Cada
componente ya est tan parchado que no s que hacerle."
Forma General
Este antipatrn es anlogo al de la Empresa nada ms aplicado a cualquiera de sus sistemas. Es
consecuencia de falta de planeacin. El problema consiste en como coordinar varios subsistemas en un
sistema global en ausencia de una abstraccin comn del subsistema y las convenciones que permiten su
cooperacin.
Los subsistemas estn integrados de manera ad hoc, usando diversas estrategias y mecanismos. Todos los
subsistemas estn integrados punto a punto lo que causa gran dependencia.
Existen varias dependencias implcitas de configuracin, detalles de instalacin y estado de sistema.
El sistema es difcil de extender y las extensiones introducen nuevas dependencias punto a punto. La
complejidad del sistema crece lo que causa que las futuras extensiones y el mantenimiento son intratables.
Sntomas y Consecuencias
Gran brecha entre la documentacin de la arquitectura y la implementacin, la documentacin no corresponde
a la implementacin.
Los arquitectos desconocen los aspectos claves de la integracin.
El proyecto rebas el presupuesto y ha pospuesto las fechas de entrega sin razones obvias.
Cambios de requerimientos son muy costosos para implementar y el mantenimiento del sistema tambin tiene
costos inesperados.
El sistema cumple a lo mejor con los requerimientos documentados pero no con las expectativas del cliente.
Causas Tpicas
Se usaron mecanismos mltiples para integrar los subsistemas por lo tanto la arquitectura es difcil de
describir y de modificar.
Falta de abstraccin, todas las interfaces son nicas para cada subsistema.
El uso insuficiente de metadatos. No existen metadatos para dar el soporte a las extensiones y
reconfiguraciones sin cambio de software.
Alto acoplamiento entre las clases requiere del cdigo excesivo por el lado del cliente.
Falta de visin arquitectnica.
Correccin
La solucin a este problema consiste en la arquitectura de componentes que permite la sustitucin flexible de
mdulos de software. Los subsistemas son modelados de manera abstracta de tal forma que presentan
muchas menos interfaces que los subsistemas implementados. El problema clave es encontrar la abstraccin
apropiada. La abstraccin tiene que modelar la interoperabilidad sin exponer las diferencias entre subsistema
y los detalles de la implementacin.
Para definir la arquitectura de un componente se debe definir el nivel bsico de su funcionalidad para la
mayora de las aplicaciones. En general este nivel corresponde al aspecto de intercambio de datos y sus
conversiones. Despus definir el conjunto de interfaces que soportan este nivel de funcionalidad.
Recomendamos usar ISO IDL.

Antipatrn Amarrado por el vendedor (Vendor lock-in)

Tambin conocido como: Arquitectura dependiente de producto, Esclavitud y sumisin,
Escala: Sistema
Correccin: Capa aislante
Tipo de solucin: Software
Causas bsicas: Pereza, Apata, Orgullo/Ignorancia
Fuerzas desbalanceadas: Administracin de la transferencia de tecnologa, Administracin de cambio
Forma General
El proyecto de software adopta la tecnologa de un producto y queda completamente dependiente del
vendedor. Cuando aparecen nuevas versiones del producto cambia el software y aparecen problemas de
interoperabilidad que implican el mantenimiento continuo del sistema.
Sntomas y Consecuencias
Nuevas versiones del producto comercial causan el mantenimiento continuo del software de aplicacin.
Las caractersticas prometidas de productos comerciales nunca se cumplen o su entrega se retrasa, en
consecuencia causa los retrasos en la entrega de aplicacin.
El producto vara mucho de los estndares de sistemas abiertos.
Causas tpicas
El producto vara con respecto a los estndares de sistemas abiertos porque no existen procesos formales
que aseguren la conformancia.
El producto es seleccionado con base en la propaganda e informacin del vendedor y no en una inspeccin
tcnica ms detallada.
No existe enfoque tcnico para aislar el software de aplicacin de la dependencia directa del producto.
La programacin de aplicaciones requiere de conocimiento profundo del producto.
La complejidad y generalidad de la tecnologa del producto excede en gran medida las necesidades de la
aplicacin.
Excepcin Conocida
Este patrn es aceptable cuando el cdigo proporcionado por el vendedor cubre la mayora del cdigo que se
necesita para la aplicacin.
Correccin
La solucin correctiva se conoce como capa aislante. La capa aislante separa el software del vendedor de las
aplicaciones. Esto se puede usar para proporcionar la portabilidad.
Patrones relacionados
Patrn de Envoltura (Object Wrapper)
Conclusin
Tenemos que tener claro que LOS PATRONES DE DISEO NO SON PERFECTOS. Aunque realmente el
problema est en la gente que los usa, pues a veces tendemos a tratarlos como verdades universales.
El uso indiscriminado de los patrones de Software, define a programadores que aprenden un patrn y
rpidamente encuentran un lugar donde abusar de l.
Los antipatrones son soluciones negativas que presentan ms problemas que beneficios. Es importante
comprender bien estos antipatrones para conseguir identificarlos y evitarlos cuanto antes.
Los antipatrones de diseo suelen tener nombres graciosos y son detallados con mucho cinismo, lo cual es
bueno porque los hace fcil de recordar.
Los antipatrones de diseo se clasifican en tres grandes grupos
Desarrollo de Software
Arquitectura de Software
Gestin de Proyectos de Software
W.J. Brown, R.C. Malveau, H.W. "Skip" MacCormick III y T.J. Mowbray John Wiley & Sons, 1998.
http://www.mcc.unam.mx/~cursos/Algoritmos/javaDC99-2/antipatrones.html