Antipatrones

 

 

 

"AntiPatterns, Refactoring Software, Architectures, and projects in Crisis"

 

W.J. Brown, R.C. Malveau, H.W. "Skip" MacCormick III y T.J. Mowbray

John Wiley & Sons, 1998.

 

 

Definiciones

 

El antipatrón es una forma para capturar la experiencia de los desarrolladores para poder ser asimilada más fácilmente por otros desarrolladores.

 

Los antipatrones capturan las experiencias que repetidamente han arruinado el desarrollo de los proyectos de software y ofrecen sugerencias de solución a estas situaciones.

 

La idea que sobre la que descansan los antipatrones es la creencia de que es más fácil detectar lo que se hace mal que proveer un buen comportamiento.

 

 

Existen formatos para documentar los antipatrones y una versión abreviada para mini antipatrones.

 

En el libro se presentan los antipatrones de los siguientes tipos:

 

 

 

 

Ejemplos de antipatrones de arquitectura

 

 

 

Antipatrón Empresa con sistemas parchados

(Stovepipe Enterprise)

 

También conocido como: Islas de automatización

 

Escala: Empresa

 

Nombre de la corrección: Planeación de la arquitectura para la empresa

 

Tipo de solución: Proceso

 

Causas básicas: Prisa, Apatía, Estupidez

 

Fuerzas desbalanceadas: Administración de cambios, Recursos, Transferencia de Tecnología

 

Evidencia anegdótica: " Podría 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.

 

Síntomas y Consecuencias

 

 

Causas Típicas

 

 

Correccíon (Refactoring)

 

Es esencial coordinar la tecnología a distintos niveles. Se necesitan definir estándares comunes que implicarán la migración de algunos sistemas. Se define la infraestructura común y convenciones comunes para los sistemas.

 

Para cada empresa grande la experiencia dice que es necesario definir los siguientes requerimientos:

 

  1. Modelo de referencia de sistemas abierto
  2. Perfil de tecnología
  3. Ambiente de operación
  4. Perfil de requerimientos de sistemas

 

También se debe de especificar:

 

  1. Arquitectura de la empresa
  2. Arquitectura de facilidades computacionales
  3. Especificación de interoperabilidad
  4. Perfil de desarrollo

 

Ejemplo

 

Soluciones Relacionadas

 

Mencionan otros antipatrones y patrones relacionados

 

Aplicabilidad de otros puntos de vista y escalas

 

 

 

Antipatrón: Sistema parchado (Stovepipe System)

 

También conocido como: Sistema heredado (Legacy system), Especial del Tío Sam, Integración Ad Hoc

 

Escala: Sistema

 

Nombre de la corrección: Marco Arquitectónico

 

Tipo de corrección: Software

 

Causas básicas: Prisa, Avaricia, Ignorancia, Pereza

 

Fuerzas desbalanceadas: Administración de complejidad, cambios

 

Evidencia anegdótica: " El dinero para el proyecto ya casi se acabo, hemos recorrido la fecha de entrega en varias ocasiones, el usuario todavía 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 antipatrón es análogo al de la Empresa nada más aplicado a cualquiera de sus sistemas. Es consecuencia de falta de planeación. El problema consiste en como coordinar varios subsistemas en un sistema global en ausencia de una abstracción común del subsistema y las convenciones que permiten su cooperación.

 

Los subsistemas están integrados de manera ad hoc, usando diversas estrategias y mecanismos. Todos los subsistemas están integrados punto a punto lo que causa gran dependencia.

 

Existen varias dependencias implícitas de configuración, detalles de instalación y estado de sistema.

 

El sistema es difícil 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.

 

 

 

Síntomas y Consecuencias

 

 

Causas Típicas

 

 

Corrección

 

La solución a este problema consiste en la arquitectura de componentes que permite la sustitución flexible de módulos 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 abstracción apropiada. La abstracción tiene que modelar la interoperabilidad sin exponer las diferencias entre subsistema y los detalles de la implementación.

 

Para definir la arquitectura de un componente se debe definir el nivel básico de su funcionalidad para la mayoría de las aplicaciones. En general este nivel corresponde al aspecto de intercambio de datos y sus conversiones. Después definir el conjunto de interfaces que soportan este nivel de funcionalidad. Recomendamos usar ISO IDL.

...

Ejemplo

 

Soluciones relacionadas

 

Aplicabilidad de otros puntos de vista y escalas

 

 

 

Antipatrón Amarrado por el vendedor (Vendor lock-in)

 

También conocido como: Arquitectura dependiente de producto, Esclavitud y sumisión,

 

Escala: Sistema

 

Corrección: Capa aislante

 

Tipo de solución: Software

 

Causas básicas: Pereza, Apatía, Orgullo/Ignorancia

 

Fuerzas desbalanceadas: Administración de la transferencia de tecnología, Administración de cambio

 

 

Critica a Microsoft

 

Forma General

 

El proyecto de software adopta la tecnología 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.

 

 

Síntomas y Consecuencias

 

 

 

Causas típicas

 

 

Excepción Conocida

 

Este patrón es aceptable cuando el código proporcionado por el vendedor cubre la mayoría del código que se necesita para la aplicación.

 

 

Corrección

 

La solución 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

 

Patrón de Envoltura (Object Wrapper)

 

 

 

 

 

Antipatrón Arquitectura Implícita (Architecture by Implication)

 

También conocido como: ¿Qué rollo es esto de arquitectura?

 

Escala: Sistema

 

Corrección: Arquitectura basada en objetivo (Goal Question Architecture)

 

Tipo de corrección: Documentación

 

Causas básicas: Orgullo, Pereza

 

Fuerzas desbalanceadas: Administración de Complejidad, Cambios, Riesgo

 

Forma General

 

El antipatrón se caracteriza por la falta de la especificación de la arquitectura del sistema que se está desarrollando. Usualmente las personas responsables por el proyecto tienen experiencia de sistemas previamente desarrollados por lo tanto consideran que la documentación no es necesaria. Esta confianza exagerada conlleva a riesgos que pueden afectar el éxito del sistema.

 

Por lo general las definiciones de la arquitectura carecen de alguno de los siguientes puntos:

 

 

 

Síntomas y Consecuencias

 

 

 

Causas Típicas

 

 

 

Corrección

 

La solución consiste en la decisión organizacional con respecto a las especificaciones de la arquitectura basadas en múltiples vistas. Cada vista responde a las necesidades de un usuario del sistema. Las vistas comprenden el conjunto de diagramas, tablas o especificaciones que deben ser consistentes.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Antipatrón Diseñado por Comité

 

Conocido también como: Chapa de Oro, Enfermedad de Estandarización, Haz Feliz a Todo Mundo, Partido Político

 

Escala: Global

 

Nombre de Corrección: Facilidad de Reuniones

 

Tipo de Corrección: Proceso

 

Causas básicas: Orgullo, Avaricia

 

Fuerzas desbalanceadas: Administración y Funcionalidad, Complejidad, Recursos

 

Evidencia anegdótica: "Un camello es un caballo diseñado por un comité."

 

Antecedentes

 

La orientación a objetos frecuentemente se describe como la tecnología de dos generaciones. La primera se caracteriza por el análisis centrado en objetos-datos y la segunda por patrones de diseño. La primera generación se basa en la filosofía que "los objetos son cosas tangibles". La consecuencia de esto es que todos los diseños son verticales. Una de las creencias de la primera generación es que el grupo de desarrollo debe ser egalitario, es decir, las decisiones deben de ser tomadas democráticamente. Esto lleva a diseño por comité. Las buenas abstracciones son definidas por grupos muy pequeños, los diseños donde se decide por mayoría invariablemente llevan a perder la abstracción e introducen complejidad.

 

Forma general

 

El diseño complejo de software es producto de trabajo de un comité. Tiene tantos conceptos y variaciones que no es posible que los desarrolladores lo implementen en tiempo razonable. Tampoco es posible verificar el diseño por su complejidad. El diseño carece de claridad conceptual porque demasiada gente a metido su mano en su creación.

 

Síntomas y Consecuencias

 

 

 

Causas Típicas

 

 

Excepciones Conocidas

 

El diseño por comité puede funcionar cuando el comité es pequeño (6-10 personas) y compuesto de expertos reales.

 

Corrección

 

La esencia de la corrección de este antipatrón consiste en reorganizar el proceso de reuniones. Lo primero es tener un reloj en la reunión para tener el tiempo transcurrido muy presente. Poner los objetivos de la reunión en la agenda. Permitir intervenciones de más o menos 25 palabras, añadir comentarios solo si son requeridos.

 

Cada reunión debe contestar dos preguntas: ¿Para que nos reunimos? Y ¿Con qué queremos salir de aquí?.

También es útil repartir roles entre los miembros del equipo: responsable, facilitador, arquitecto, desarrollador, probador y experto en el dominio. Cada quien puede aportar a las reuniones según su especialidad.

Presenta técnicas para mejorar la eficiencia en el trabajo en grupo.

 

Ejemplos

 

SQL y CORBA

 

Mini Antipatrón: Navaja Suiza

 

 

Antipatrón: Reinventando la rueda

 

También conocido como: Diseñando en el vacío, Inventando el hilo negro

 

Escala: Sistema

 

Nombre de la corrección: Minería de Arquitectura

 

Tipo de corrección: proceso

 

Causas básicas: Orgullo e Ignorancia

 

Evidencia anegdótica. "Nuestro problema es único."

 

Forma General

 

Los sistemas se construyen de nuevo para cada cliente aunque existe un traslape de funcionalidad de un sistema a otro. La reusabilidad es muy limitada. La mayoríe de los métodos de desarrollo actuales supone que un sistema se desarrolla por primera vez aislado de los demás.

 

Síntomas y Consecuencias

 

Causas Típicas

 

 

Corrección

 

La minería de arquitecturas en sistemas ya existentes o en la literatura puede ayudar en el diseño de sistemas complejos y evitar errores. Identificar interfaces estándar para el sistema y basar la arquitectura en ellos. Conciliar el conocimiento del diseño top-down con el bottom-up.