AntipatronesCuellar Arteaga Marcos Jair 2691

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 SoftwareArquitectura de SoftwareAdministracin de Proyectos de SoftwareAntipatrnEmpresa con sistemas parchados (Stovepipe Enterprise)Tambin conocido como: Islas de automatizacinEscala: EmpresaNombre de la correccin: Planeacin de la arquitectura para la empresaTipo de solucin: ProcesoCausas bsicas: Prisa, Apata.Fuerzas desbalanceadas: Administracin de cambios, Recursos, Transferencia de TecnologaEvidencia anegdtica: " Podra tener mi isla (automatizada)? Soy el nico."Forma GeneralEn 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 ConsecuenciasTecnologas incompatibles dentro de la misma empresaArquitecturas monolticas y no documentadasFalta de posibilidad de extender los sistemas para satisfacer las necesidades de negocioFalta de estndaresFalta de rehusoFalta de interoperabilidadCausas TpicasFalta de estrategia tecnolgica de la empresaFalta de estndaresFalta de perfil de sistemaFalta de incentivos para la cooperacin en el desarrollo de sistemasFalta de comunicacinFalta de conocimiento sobre los estndares tecnolgicosFalta de interfaces para la integracin de sistemasCorreccin 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 HocEscala: SistemaNombre de la correccin: Marco ArquitectnicoTipo de correccin: SoftwareCausas bsicas: Prisa, Avaricia, Ignorancia, PerezaFuerzas 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 GeneralEste 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 ConsecuenciasGran 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 TpicasSe 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.CorreccinLa 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.

AntipatrnAmarrado por el vendedor (Vendor lock-in)Tambin conocido como: Arquitectura dependiente de producto, Esclavitud y sumisin,Escala: SistemaCorreccin: Capa aislanteTipo de solucin: SoftwareCausas bsicas: Pereza, Apata, Orgullo/IgnoranciaFuerzas desbalanceadas: Administracin de la transferencia de tecnologa, Administracin de cambioForma GeneralEl 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 ConsecuenciasNuevas 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 tpicasEl 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 ConocidaEste patrn es aceptable cuando el cdigo proporcionado por el vendedor cubre la mayora del cdigo que se necesita para la aplicacin.CorreccinLa solucin correctiva se conoce comocapa aislante. La capa aislante separa el software del vendedor de las aplicaciones. Esto se puede usar para proporcionar la portabilidad.Patrones relacionadosPatrn 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 gruposDesarrollo de SoftwareArquitectura de SoftwareGestin 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