Arquitectura evolutiva y diseño emergente: Investigación sobre arquitectura y diseño

Descubriendo un diseño y una arquitectura más fáciles de mantener

La arquitectura y el diseño de software generan mucho ruido, pero pocas nueces. Con el fin de analizar estos temas desde una óptica nueva y alternativa, este artículo lanza la serie Arquitectura evolutiva y diseño emergente. La arquitectura evolutiva y el diseño emergente son técnicas ágiles para postergar las decisiones importantes hasta el último momento que la responsabilidad lo permita. En esta entrega introductoria Neal Ford, el autor de la serie, define a la arquitectura y al diseño y luego identifica las distintas cuestiones relacionadas que surgirán a lo largo de esta serie.

Neal Ford, Application Architect, ThoughtWorks Inc.

Neal FordNeal Ford es software architect y Meme Wrangler en Thought Works, consultora de TI global. También diseña y desarrolla aplicaciones, materiales instructivos, artículos para revistas, material de aprendizaje y presentaciones en video/DVD, y es autor o editor de libros que abarcan una variedad de tecnologías, incluyendo el más reciente The Productive Programmer [El programador productivo]. Neal se concentra en diseñar y construir aplicaciones de negocios de gran escala, y es un orador internacionalmente aclamado en las conferencias para desarrolladores de todo el mundo. Consulte su Sitio Web.



05-04-2010

La arquitectura y el diseño en software durante mucho resistieron firmemente cualquier definición precisa porque el desarrollo de software como disciplina todavía no ha captado completamente todos sus vericuetos e implicancias, pero para crear un discurso verbal razonable sobre estos temas, tenemos que empezar por algún lugar. Los artículos de esta serie se ocupan de la arquitectura evolutiva y del diseño emergente, por lo tanto tiene sentido comenzar la serie con algunas definiciones, consideraciones y otros conceptos básicos.

Acerca de esta serie

El objetivo de esta serie es brindar una perspectiva nueva a los conceptos tan analizados frecuentemente pero a la vez evasivos sobre la arquitectura y el diseño de software. Mediante ejemplos concretos, Neal Ford le brinda una base sólida en las prácticas ágiles de la arquitectura evolutiva y el diseño emergente. Al postergar las decisiones importantes sobre arquitectura y diseño hasta el último momento que la responsabilidad lo permita, usted puede evitar que la complejidad innecesaria socave sus proyectos de software.

Definición de arquitectura

La arquitectura en software es uno de los conceptos sobre los que más se habla, sin embargo el que menos se comprende y con el que luchan los desarrolladores. En conferencias, charlas y reuniones de grupos informales de debate se le presta suma atención al tema de la arquitectura, pero seguimos teniendo apenas unas vagas definiciones sobre ella. Cuando hablamos sobre arquitectura, estamos refiriéndonos realmente a varios temas diferentes, pero relacionados entre sí que generalmente se incluyen en las categorías generales de arquitectura de aplicaciones y arquitectura de negocios.

Arquitectura de aplicaciones

La arquitectura de aplicaciones describe las piezas de granularidad gruesa que componen una aplicación. En el mundo Java, por ejemplo, la arquitectura de aplicaciones describe dos cosas: la combinación de marcos usada para construir una aplicación en particular — a la cual llamo la arquitectura a nivel marco— y la separación más tradicional de cuestiones, a la que llamo con el apodo applicationarchitecture (arquitectura de aplicación). Es importante separar a la arquitectura de marco para distinguir cuestiones, ya que la mayoría de los que practican con lenguajes orientados a objetos han descubierto que las clases individuales no funcionan bien como mecanismo de reutilización. (¿Cuándo fue la última vez que usted descargó una clase individual de Internet para usar en un proyecto?). La unidad de reutilización en los lenguajes modernos orientados a objetos es la biblioteca o el marco. Cuando usted inicia un proyecto nuevo en lenguajes de marco rico como el lenguaje Java, uno de los primeros temas que concierne a la arquitectura es la arquitectura a nivel marco de la aplicación. Este estilo de reutilización prevalece de una manera tan arraiga en el mundo Java que comencé a decir que deberíamos dejar de referirnos a la programación Java como un lenguaje orientado a objetos y deberíamos llamarlo lenguaje orientado a marcos. En muchos sentidos, la arquitectura a nivel marcos representa una arquitectura física, descripta por bloques de construcción específicos.

El otro aspecto interesante de la arquitectura de aplicaciones describe cómo se ensamblan las piezas lógicas de la aplicación. Este es el reino de los patrones de diseño y de otras descripciones estructurales, y por lo tanto tiende a ser más abstracto y lógico que físico. Por ejemplo, podemos decir que una aplicación Web adhiere a un patrón Modelo Vista Presentador sin especificar qué marco se usa para lograr la configuración lógica. Esta configuración lógica es la que probablemente más adorne las pizarras de su espacio de trabajo cuando usted comienza a trabajar en partes nuevas de la aplicación.

Arquitectura de negocios

La arquitectura de negocios se ocupa en sí misma de la forma en que la empresa, en su totalidad, (que generalmente significa las aplicaciones que se ejecutan internamente en una gran organización) consume las aplicaciones. Una metáfora útil muy común para indicar la relación existente entre la empresa y la arquitectura de aplicaciones compara a la empresa con la planificación de una ciudad y a la aplicación con la arquitectura de edificaciones. Los planificadores de una ciudad deben pensar en obtener agua, electricidad, cloacas y otros servicios que le permitan funcionar a la ciudad. No pueden tener un edificio que consuma más que su cuota de suministro de agua. La arquitectura de negocios considera las mismas clases de cosas para las aplicaciones: no podemos permitir que una aplicación consuma todo el ancho de banda de la red, y si los servicios de infraestructura colapsan, el desagüe (virtual) hace la copia de seguridad.

La arquitectura de negocios ha captado mucha atención en los últimos años debido a la Arquitectura orientada a servicios (SOA). SOA es un tema profundo en todo su derecho, por lo tanto las entregas futuras de esta serie lo abordarán como un caso especial, tiene aspectos de interés propios ya que desdibuja la línea que separa a la arquitectura de negocios y la arquitectura de aplicaciones al determinar características de la construcción de aplicaciones.

Los párrafos anteriores ofrecen definiciones superficiales de estos conceptos importantes, pero sirven como puntapié inicial para otras definiciones más interesantes y más específicas de la arquitectura, incluyendo algunas definiciones obtenidas de otros.

Definiciones existentes

Mucha gente inteligente ha intentado definir a la arquitectura de software, así que les permitiré que nutran el pensamiento. En su clásico white paper "Who Needs an Architect?" [¿Quién necesita un arquitecto?] (ver Recursos), Martin Fowler comenta varias definiciones, cita la primera de ellas de una publicación que apareció en una lista de distribución sobre Programación extrema:

"El proceso RUP, que se desprende de la definición de IEEE, define a la arquitectura como 'el concepto de más alto nivel de un sistema en su entorno. La arquitectura de un sistema de software (en un determinado punto en el tiempo) es su organización o estructura de componentes significativos que interactúan a través de interfaces, estos componentes están integrados sucesivamente por interfaces y componentes más pequeños.'"

Esta definición se ajusta muy bien al ámbito de la arquitectura de aplicaciones como describí anteriormente. Aunque vaga, capta la esencia de la responsabilidad de la arquitectura: el concepto de más alto nivel.

Fowler luego cita a Ralph Johnson, quien objetó la definición anterior en una respuesta enviada a esa lista de distribución:

"Una definición mejor sería: 'En la mayoría de los proyectos de software exitosos, los expertos desarrolladores que trabajan en el proyecto comparten una interpretación del diseño del sistema de diseño. Esta interpretación compartida se llama "arquitectura." Esta interpretación incluye cómo se divide el sistema en componentes y cómo interactúan los componentes a través de las interfaces.'"

Johnson destaca algo muy importante, que el desarrollo de software se basa en la comunicación más que en la tecnología, y que la arquitectura realmente representa el conocimiento compartido sobre el sistema, nada específicamente referido a lenguajes, marcos y otros temas tecnológicos efímeros.

En el documento anteriormente mencionado, Fowler mismo brinda una de mis definiciones de arquitectura favoritas:

"La arquitectura se refiere a cosas importantes, cualesquiera que éstas sean."

Esta definición es apropiadamente difusa, pero tan descriptiva al mismo tiempo. Muchos de los argumentos sobre arquitectura y diseño giran en torno a una interpretación errónea de qué es importante. Lo que es importante para los analistas de negocios difiere de lo que es importante para un arquitecto de negocios. Esta definición apunta muy bien a que debemos definir nuestros términosdentro de nuestro entornoantes de intentar definir otras cosas.

La definición de Fowler también destaca otro aspecto importante sobre la definición de algo con tantos matices como la arquitectura. "Cosas importantes" no sólo varía entre las personas y los grupos; sino que esas diferencias en realidad pueden ser mutuamente excluyentes. Por ejemplo, virtualmente todas las arquitecturas SOA compensan recíprocamente la flexibilidad y la velocidad. El viejo sistema cliente/servidor que usted está usando ahora casi seguro es más rápido que la versión basada en Web, portlet-motor, basada en servicio que lo reemplaza. A menos que la aplicación nueva haya sido escrita por desarrolladores muy malos, las capas extra que brindan la flexibilidad implican un aumento en el tiempo de respuesta a los usuarios, haciéndola más lenta para ellos. Quizás sea el arquitecto el que deba decirle a los usuarios: "Ah, dicho sea de paso, esta nueva arquitectura SOA que estamos instalando será mejor para nosotros, pero su trabajo ahora será más lento. Disculpas." Tal vez ésta sea la razón por la cual se les paga más a los arquitectos que a los desarrolladores.

Con lo cual queda mi definición favorita de arquitectura:

"Cosas que son difíciles de cambiar posteriormente."

Esta definición se ajusta mejor a la idea de arquitectura evolutiva. Una de las ideas principales que yacen detrás de la arquitectura evolutiva es la posibilidad de postergar definiciones todo lo que se pueda, lo que permite reemplazar por alternativas superiores, según lo demuestra la experiencia reciente. Muchos de los bloques de construcción de este estilo de arquitectura aparecen a lo largo de esta serie de artículos y motivaron la creación de los mismos.

Antes de pasar a otro tema, sería una negligencia de mi parte no referirme al nombre del puesto “arquitecto”. Enoja mucho a los sectores de recursos humanos que nosotros, como industria, tengamos títulos tan pobremente definidos. Muchas organizaciones desean ascender a sus mejores desarrolladores—aquellos que toman decisiones importantes sobre las cosas que son difíciles de cambiar posteriormente—pero no existe un buen término en la industria además de "arquitecto". Tampoco existe una descripción común del puesto, por lo tanto cada empresa define qué significa este rol. Algunos de los arquitectos se parecen al Arquitecto que aparece al final de la película Matrix II (que Fowler categoriza como Architectus Reloadus). Estos arquitectos escribieron un código por última vez hace una década y ahora están tomando las decisiones importantes para su empresa. La única herramienta de desarrollo de software que usan es Visio.

La otra alternativa que existe para definir el rol de arquitecto es el que Fowler llama Architectus Oryzus (llevan ese nombre por David Rice, uno de mis colegas). Estos arquitectos aportan activamente código al proyecto, a la par de otros desarrolladores que se ocupan de las partes más difíciles. Sus responsabilidades también incluyen interactuar con otras partes interesadas del proyecto para asegurarse de que todos hablen el mismo idioma, usen las mismas definiciones y comprendan las partes del sistema que necesitan comprender. Obviamente este rol activo es esencial para alcanzar las metas de la arquitectura evolutiva, y por lo tanto aparecerá reiteradas veces en esta serie.


Definición de diseño

La mayoría de los desarrolladores ya tienen una idea muy clara del diseño, por lo tanto no dedicaré mucho tiempo a definirlo. Representa los elementos básicos que demuestran cómo se ensamblan las diferentes piezas que integran el software, incluye el terreno bien conocido como patrones de diseño, refactorización, marcos y otras cuestiones que atañen diariamente a los desarrolladores. El diseño a grandes rasgos entra en un espectro que abarca desde BDUF (Diseño completo desde el principio) y Cowboy Hacking, como se muestra en la Figura 1:

Figura 1. Especto que abarca el diseño
Spectrum of design Styles

El extremo izquierdo del aspecto que se muestra en la Figura 1 sugiere que usted puede anticipar todas las cientos de miles de cuestiones que emergen cuando desarrolla software y trata de limitar sus respuestas a las mismas. Usted leerá mucho más sobre este tema en las siguientes entregas. Que no dedique mucho tiempo a definir el diseño no significa que no dedique mucho tiempo a hablar sobre él. La mayor parte de esta serie cubre diferentes aspectos sobre la forma en que puede emerger el diseño cuando usted desarrolla en lugar de considerarlo algo fijo e inalterable antes de escribir su primera línea de código.


Temas esenciales sobre arquitectura y diseño

Evolutivo contra emergente

Observe que esta serie se llama arquitectura Evolutiva y diseño emergente. ¿Por qué hacemos esta distinción entre evolutivo y emergente? La arquitectura emergente, como me señalaba uno de mis colegas, no es una idea tan apasionante. Si aceptamos la premisa de que la arquitectura se refiere a cosas que son difíciles de cambiar posteriormente, se dificulta entonces la idea de que una arquitectura pueda emerger. La arquitectura se preocupa de los elementos de infraestructura que deben existir antes de que usted inicie la aplicación. Sin embargo, sólo porque usted no puede dejar que la arquitectura emerja, no significa que ésta no pueda evolucionar. Si usted creó una arquitectura flexible y se ocupó de crear una decisión que no sea irreversible, puede permitirle que evolucione en el tiempo a medida que surjan nuevos temas a considerar.

Habiendo definido a la arquitectura y al diseño, ahora quiero profundizar en las pocas áreas que abarcan los asuntos de interés. Todos estos temas se relacionan con la arquitectura y el diseño a un nivel fundamental, por lo tanto referirme a ellas desde el principio me permite volver luego a ellas posteriormente en esta serie. Primero, hablaré sobre deuda técnica, luego sobre complejidad y por último sobre la tan mentada calidad de genérico.

Capital e intereses

Todo desarrollador es consciente del concepto de deuda técnica, mediante el cual uno realiza compromisos en su diseño en pos de alguna fuerza externa, por ejemplo la presión de un cronograma. La deuda técnica se parece a la deuda de una tarjeta de crédito, al momento uno no tiene suficientes fondos, por lo tanto los pide prestados contra un pago futuro. De igual manera, su proyecto no tiene suficiente tiempo para hacer algo correcto, entonces usted obtiene una solución justo a tiempo y espera usar algún tiempo futuro para volver a ella y modernizarla. Lamentablemente, muchos gerentes parecen no comprender qué significa la deuda técnica, ofreciendo resistencia cuando se trata de volver al trabajo que efectuaron en el pasado.

Construir software no es como cavar una zanja, si usted asume compromisos cuando hace una zanja, sólo logra un ancho irregular o una profundidad desigual. La zanja defectuosa de hoy no le impide cavar una zanja buena mañana, pero el software que construye hoy es la base para lo que construirá mañana. Los compromisos que se hacen ahora por conveniencia hacen que se cree entropía en su software. En el libro The Pragmatic Programmer [El programador pragmático], Andy Hunt y Dave Thomas hablan sobre la entropía en el software y por qué tiene un efecto tan perjudicial (ver Recursos). La entropía es una medición de la complejidad, y si usted agrega complejidad ahora debido a una solución justo a tiempo para un problema, usted debe pagar algún precio por ello para el resto de vida que le queda al proyecto.

Supongamos que usted desea agregar nuevas características a un proyecto existente que hace tiempo que se está ejecutando. Estas características nuevas tienen una cierta complejidad inherente a ellas. Sin embargo, si usted ya tiene una deuda técnica, debe trabajar en función de esas partes comprometidas del sistema para agregar características nuevas. Por ende, el costo de los agregados se asemeja a la metáfora financiera. La Figura 2 muestra la diferencia entre el esfuerzo requerido para agregar una característica nueva en un sistema diseñado de manera “limpia” (por ejemplo, uno con poca o ninguna deuda técnica), contra un sistema típico que contiene un montón de deuda técnica.

Figura 2. Deuda técnica e intereses
Effort to add new features

Podemos pensar en la complejidad inherente como el capital, y en el esfuerzo extra impuesto por los atajos previos para ahorrar tiempo como los intereses. La complejidad en sí misma es un tema interesante.

Complejidad esencial contra complejidad accidental

Los problemas que resolvemos en software tienen una complejidad intrínseca, a la que llamo complejidad esencial. La complejidad que surge de los compromisos que hacemos que generan deuda técnica es diferente, consta de todos los medios externos por los cuales el software se torna complejo y no debería existir en un mundo perfecto. Llamo a esto complejidad accidental. Defino y hablo en profundidad sobre estos términos en mi libro The Productive Programmer (ver Recursos). Estos términos generalmente no son sumamente concretos, existen en un espectro de temas, como el diseño. Algunos ejemplos ayudarán a clarificar la distinción.

Uno de mis colegas trabajó en un sistema de sueldos para una empresa agremiada. Una de las concesiones que el sindicato aseguraba para algunos de sus miembros era un día libre extra al comienzo de la temporada de caza. (Seguramente habrán tenido muy buenos negociadores.) Los empleados en cuestión trabajaban sólo en una de las fábricas, pero computar el día libre extra era una parte legítima del sistema de sueldos de toda la empresa. Este cambio agregaba un montón de complejidad al software, pero era una complejidad esencial porque formaba parte del problema de la empresa que había que resolver.

Otro ejemplo un poco más alejando en el espectro emerge todo el tiempo: seguridad a nivel campo en los formularios de entrada. Mucha gente de negocios piensa que quiere un control de granularidad fina de cada una de las características de seguridad del campo. En realidad, casi siempre odian esto cuando se implementa porque crea una carga de gran magnitud en los usuarios que deben definir y mantener todos los metadatos. La gente de negocios en uno de nuestros proyectos realmente quería esta característica, así que implementamos parte de la misma en una de las pantallas para ellos. Cuando vieron en primera instancia cuánto esfuerzo se requería para que funcionara esa característica, decidieron que como el único acceso a la aplicación era desde una oficina cerrada con llave, podían seguir con más seguridad de granularidad fina. Este es un ejemplo claro de una decisión de diseño que emergió cuando el negocio vio la realidad de lo que pensaban que querían.

En el extremo más apartado del aspecto hacia la complejidad accidental hay meros ejercicios de fontanería como las primeras dos versiones de la tecnología Enterprise JavaBeans (EJB) y herramientas como BizTalk. Unos pocos proyectos necesitan los gastos generales extra generados por estas herramientas, pero no hacen nada más que agregar complejidad a la mayoría de los proyectos que las usan.

Tres cosas tienen a propagar la complejidad accidental. Ya he hablado sobre la primera: las alteraciones de código justo a tiempo debido al cronograma a cumplir u otras presiones externas. La segunda es la duplicación, aquello a lo que los Programadores pragmáticos llaman violaciones al principio DRY (No te repitas). La duplicación es la fuerza individual que más perjudica al desarrollo de software porque se las ingenia para propagarse a muchos lugares sin que los desarrolladores se den cuenta de ello. El ejemplo obvio es el código copy-and-paste (copiar y pegar), pero abundan los ejemplos más sofisticados. Por ejemplo, casi todos los proyectos que usan una herramienta de mapeo relacional de objetos (como Hibernate o iBatis) tienen montones de duplicaciones. Su esquema de base de datos, el archivo de mapeo XML, y los objetos POJO de respaldo tienen información levemente diferente, pero que se superpone. Es posible arreglar esto mediante la creación de una fuente canónica para esa información y la generación de otras partes. La duplicación afecta a los proyectos porque se resiste a los intentos de realizar cambios estructurales o refactorizar en pos de un código mejor. Si usted sabe que necesita cambiar algo en tres lugares diferentes, evitará hacerlo aún cuando esto mejoraría el código a largo plazo.

El tercer facilitador de la complejidad accidental es la irreversibilidad. Cualquier decisión que usted adopte que no pueda revertirse eventualmente conducirá a cierto nivel de complejidad accidental. La irreversibilidad afecta tanto a la arquitectura como al diseño, aunque sus efectos son más comunes y más perjudiciales a nivel arquitectura. Trate de evitar decisiones que sean imposibles o engorrosas de revertir. Uno de los mantras que escuché usar a un colega es esperar hasta el último momento que la responsabilidad lo permita. Esto no significa que usted deba postergar decisiones por mucho tiempo, pero sí por un período lo suficientemente prolongado. ¿En qué último momento que la responsabilidad lo permita usted puede tomar una decisión sobre una cuestión de arquitectura? Cuanto más pueda evitar la decisión, mayores posibilidades dejará abiertas para usted. Pregúntese a si mismo: "¿Necesito tomar esta decisión ahora?" y "¿Qué puedo hacer para poder diferir esta decisión?" Se sorprenderá de las cosas que puede diferir si tan solo aplica cierta ingenuidad a su proceso de toma de decisiones.

La distinción que hice anteriormente entre arquitectura a nivel marco y arquitectura de aplicaciones se relaciona con el principio del Último momento que la responsabilidad lo permita. La arquitectura de aplicaciones tiene a ser una arquitectura lógica. Por ejemplo, supongamos que usted quiere separar las cuestiones del patrón Modelo Vista Presentador. A menudo, usted salta a una implementación física de la arquitectura lógica eligiendo un marco que cumpla con algunos o todos los requisitos. Vea si puede diferir esa decisión porque una vez que ha efectuado la implementación física, ésta limita las otras clases de decisiones que usted debe considerar. Postergar la decisión de marco todo lo que pueda, le ofrece mejores opciones que están menos contaminadas por la realidad.

La mentada calidad de genérico

El último de los temas que preocupan a la arquitectura y al diseño es una expresión que inventé y a la cual llamo la mentada calidad de genérico. Parece que tenemos una enfermedad en el mundo Java: soluciones con sobrecarga de ingeniería que intentan hacerlas lo más genéricas posible. La motivación para esto es clara: si construimos en muchas capas para ampliación, más fácilmente podremos construir sobre ellas posteriormente. Sin embargo, esta es una trampa peligrosa porque la cualidad de genérico agrega entropía, usted daña su capacidad de hacer evolucionar el diseño de maneras interesantes en la etapa inicial del proyecto. Agregar demasiada flexibilidad hace que cada cambio al código base sea más complejo.

Por supuesto que usted puede ignorar la extensibilidad. El movimiento ágil tiene una frase maravillosa que resumen el proceso de decisión para la implementación de características: YAGNI (No lo vas a necesitar). Este es el mantra para evitar sobrecargar de ingeniería a las características simples. Sólo implemente exactamente lo que necesita ahora, y si necesita más cosas más adelante, puede agregarlas llegado el momento. He visto algunos proyectos Java tan recargados de compromisos en arquitectura y diseño, en la cima de la calidad de genérico y extensibilidad, que los proyectos fracasaron. Por supuesto esto es irónico porque planificar para que el proyecto viva todo lo posible es lo que truncó su vida. Aprender a transitar la delgada línea que separa a la extensibilidad de la sobrecarga de ingeniería no es fácil, y es un tema al que volveré a menudo.


Mapa de ruta

Este artículo contiene un montón de conceptos pero ningún código fuente, hecho que lo distingue de todos los otros artículos que siguen en esta serie. Uno de los problemas inherentes a la descripción de temas complejos como la arquitectura y el diseño es la determinación del contexto que tiene que darse para asegurarnos que todos estemos hablando de lo mismo. He presentado el contexto para desarrollar el resto de las partes que integran esta serie, en donde profundizaré en áreas específicas relacionadas con la arquitectura evolutiva y el diseño emergente. Cada artículo se abocará en profundidad a un aspecto ilustrativo particular de uno o ambos de estos conceptos, con muchos detalles y código fuente. Próximamente: hablaré sobre diseño emergente a través de un desarrollo impulsado por pruebas, al que le cambié y ahora llamo diseño impulsado por pruebas.

Recursos

Aprender

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=tecnologia Java
ArticleID=480281
ArticleTitle=Arquitectura evolutiva y diseño emergente: Investigación sobre arquitectura y diseño
publish-date=04052010