Abstract— The livings being are the most complex and evolved

machines. They have been evolving during three thousands of millions of years from very simple elements to become sophisticated living machines. The livings being have been improving their constitution and capabilities adapting themselves to the restrictions imposed by the context. These restrictions include the fight for the supremacy within the same species as well as between different ones. This evolution could be performed because every living being has a record about all its essence: the DNA. With all the information of every living being in its DNA, as if it were requirements of a software system, the species have been transferring its constitutional information to its descendent. The concept of reutilization exists in software development too. Nevertheless, the reutilization of living being is extremely superior compared with the reutilization in software engineering. In this paper we analyze the evolution of the living being and with compared it with software development, in order to enrich the reutilization of knowledge in software development.These instructions give you guidelines for preparing papers for IEEE TRANSACTIONS and JOURNALS. Use this document as a template if you are using Microsoft Word 6.0 or later. Otherwise, use this document as an instruction set. The electronic file of your paper will be formatted further at IEEE. Define all symbols used in the abstract. Do not cite references in the abstract. Do not delete the blank line immediately above the abstract; it sets the footnote at the bottom of this column. Keywords— Computers and information processing. Software

Engineering. Design Patterns. Software Requirements.

I. INTRODUCCIÓN AWKINS [1] afirma que la vida inteligente alcanzó su mayoría de edad cuando pudo proponer explicaciones al

problema de su propia existencia. Encontrando respuestas a preguntas tales como ¿Existe un significado de la vida?, ¿Por qué existimos?, ¿Qué es el hombre? Al respecto, el eminente zoólogo G.G.Simpson [1] afirma: “Deseo insistir ahora en que todos los intentos efectuados para responder estos interrogantes antes de 1859 carecen de valor, y en que asumiremos una posición correcta si ignoramos dichas respuestas por completo”. En 1859 Charles Darwin publica su obra fundamental: “El origen de las especies por medio de la selección natural (o la preservación de las razas preferidas en la lucha por la vida)”, estableciendo que la explicación de la diversidad observada en la naturaleza se debe a las modificaciones acumuladas por la evolución a lo largo de

M. Solinas, Universidad Nacional de Córdoba (UNC), Córdoba, Córdoba, Argentina, msolinas@efn.uncor.edu.

L. Antonelli, Universidad Nacional de La Plata (UNLP), La Plata, Buenos Aires, Argentina, lanto@lifia.info.unlp.edu.ar

sucesivas generaciones. Los organismos vivos existieron sobre el planeta tierra durante más de tres mil millones de años, sin saber por qué, antes de que su existencia, fuese comprendida por uno de ellos. Por un hombre llamado Charles Robert Darwin.

Hoy hay trabajos como los del matemático Gregory Chaitin [2] , que intentan plantear una “teoría matemática de la evolución y la creatividad biológica”, aunque reconoce que los avances logrados hasta el momento aún lo dejan lejos de ese objetivo. Por otro lado, si pudiéramos escanear todo el software existente hasta el momento y “secuenciarlo”. Encontraríamos estructuras que se repiten una y otra vez? O sería una interminable cadena de creatividad sin límites? Existen tales estructuras? Se las puede modelar? Se las puede reutilizar para construir aplicaciones que difieran una de otra, sin sospechar que internamente están utilizando las mismas estructuras? Podrían estas estructuras, evolucionar como lo han hecho los seres vivos, en una secuencia de “n” transformaciones hasta dar cumplimiento a todo tipo de requerimientos para la construcción de una aplicación? Todas estas preguntas tienen que ver con la Ingeniería de Software e intentamos en este trabajo de posicionamiento, mostrar lo que los autores interpretan como una nueva puerta que podría abrirse en el camino hacia nuevos paradigmas para la producción de software. El trabajo se organiza de la siguiente manera: La sección II presenta la analogía entre software natural y artificial. La sección III es un resumen de las ideas de G. Chaitin sobre la construcción de un proceso evolutivo. En la sección IV hablamos sobre el ADN, para luego especular sobre una analogía con los Patrones de Diseño, presentados en la sección V. En la sección VI presentamos una forma conocida de modelar requerimientos expresados en lenguaje natural. Por último en VII cerramos con algunas conclusiones.

II. SOFTWARE DE TRES MIL MILLONES DE AÑOS El término “software” tal cual hoy lo conocemos, fue

utilizado por primera vez por John W. Tukey en 1957. Tukey fue un estadístico que acuñó muchos términos que ahora son de uso común, pero las dos palabras más famosas inventadas por él están relacionadas con la informática. Mientras trabajaba con John von Neumann en los primeros diseños de computadoras, Tukey introdujo la palabra "bit" como contracción de "Dígito binario" (Binary Digit). Tukey usó el término “Computer Software” en un contexto computacional en un artículo de 1958 en “American Mathematical Monthly”.

Así el concepto “software” como hoy lo conocemos, no tiene tantos años como se podría imaginar. Aún no ha

M. Solinas, Member, IEEE and L. Antonelli

Software Evolution and Design Patterns

D

IEEE LATIN AMERICA TRANSACTIONS, VOL. 11, NO. 1, FEB. 2013 347

cumplido sus primeros cien años. A pesar de ello, hay que reconocer que ha producido asombrosos cambios en nuestras vidas en muy poco tiempo.

Conjuntamente con el microprocesador han sido los impulsores del nacimiento, crecimiento y desarrollo de las tecnologías de la información y las comunicaciones (TICs). El impacto ha sido tal, que la Biología en su esencia, ha sido tocada por el desarrollo de las TICs. Hay autores que en sus trabajos consideran a los seres vivos como sistemas de información.

El físico Freeman Dyson [3] unió las ciencias de la información y la vida dentro de un solo marco conceptual: “El hardware procesa la información; el software la encarna. Estos dos componentes tienen sus análogos exactos en la célula; la proteína es el hardware; el ácido nucleido, el software.”

El biólogo francés Pierre Grassé ha expuesto detalladamente la nueva forma de conceptualizar la naturaleza basada en el lenguaje de las TICs. Grassé comienza poniendo la vida, en general, en un marco de TICs: “La información forma y anima el organismo vivo. La evolución es, en última instancia, el proceso mediante el cual una criatura modifica su información y adquiere otra”. Desarrolla un modelo cibernético del organismo vivo. Empieza con las hélices de ADN que constituyen el código genético, el cuál para él, representa la inteligencia de la especie. Está dispuesto a conceder que el ADN es “...el depositario y el distribuidor de la información…”. Por otro lado, compara el código genético de un organismo con una biblioteca y sostiene que ni ésta ni aquél crean la información; son meros almacenes de información. Tanto el ADN como la biblioteca clasifican y almacenan. Es aquí cuando Grassé aplica el principio de realimentación a los sistemas vivos.

“El ADN tiene que recibir mensajes de otras partes de la

célula o de los órganos [...] o del mundo exterior (estímulos sensoriales, feromonas, etc.).”

Vale la pena hacer una pausa para reflexionar sobre una realidad que se insinúa al principio. El software tal cual lo conocemos, tiene una antigüedad que no alcanza los cien años. Por otro lado, si consideramos la analogía entre ADN y software, llegamos a que hay un “software natural” que ha evolucionado a lo largo de tres mil millones de años. Esto de por sí es un resultado impactante, derivado de la teoría de la evolución de Charles Darwin, con la cual podemos o no estar totalmente de acuerdo, pero ha hecho posible este tipo de especulaciones. G.Chaitin opina lo mismo [4].

Por primera vez en la historia de la humanidad se especula sobre esta idea y observamos en los laboratorios de las ciencias naturales, un “software natural” que ha producido múltiples y variadas “aplicaciones” (seres vivos) mediante un proceso de evolución de tres mil millones de años. Quién puede pasar indiferente al observar la variedad, complejidad y creatividad de la vida natural.

Para completar la idea, le llamamos “software natural” (ADN) en contraposición al “software artificial” creado por el

hombre. Este último, a pesar de su corta evolución ha dado sus frutos y nos asombra día a día la creatividad de sus aplicaciones, pero comparado con los resultados a la vista, de tres mil millones de años de evolución, me animo a decir que estamos aún lejos de llegar a la edad de piedra de la evolución del “software artificial”, lo cual puede resultar molesto para aquellos que se dedican a producirlo.

Sin embargo, esta realidad es una oportunidad para observar en detalle las evidencias de la evolución en los seres vivos desde la mirada de la Ingeniería de Software. Luego intentar construir modelos de procesos de evolución análogos a los observados en los seres vivos, que puedan ser de aplicación al “software artificial”. Por último utilizar esos modelos para construir software que evolucione de forma autónoma a partir de “genes artificiales” que copien los procesos de evolución de los “genes naturales”. En este punto caben dos preguntas: conocemos esos procesos con claridad? y segundo, conocemos los genes artificiales?

III. VIDA COMO SOFTWARE EN EVOLUCIÓN Al momento de construir modelos de los procesos de

evolución observados en los seres vivos, Gregory Chaitin [2] ha hecho aportes que consideramos relevantes. Intentamos repasar algunas ideas que podrían aplicarse en otro contexto, diferente al que se enfocó el autor.

En sus primeros trabajos se propuso modelar la evolución biológica estudiando la evolución de mutaciones randómicas de software y a eso le llamo metabiología. La primera propuesta consistía en cambiar, eliminar o insertar uno o más bits en un programa en código binario. Luego propuso que una mutación M debe ser un algoritmo para mapear el organismo A en el organismo A’ = M(A). Por otro lado, asoció una probabilidad de ocurrencia de la mutación M, proporcionada por algoritmos que se desprenden de la teoría de la información y depende del tamaño en bits del programa que representa M. A partir de esta consideración surgen dos puntos importantes:

1) Está en condiciones de mostrar que la evolución

randómica así planteada es acumulativa. Una propuesta anterior no lo era y cuando una línea de evolución no convergía había que lanzar el proceso nuevamente.

2) Esto también le permitió construir un modelo en donde se desarrollan estructuras jerárquicas.

Estos logros le hacen pensar que está en la dirección

correcta pero reconoce que aún hay muchas lagunas y está lejos de poder etiquetarla como una teoría matemática de la evolución y la creatividad biológica, que es a lo que apunta. De más está decir, que sería de gran utilidad poder disponer de tal teoría. De todos modos, continuemos revisando algunos conceptos relevantes del trabajo, que son de utilidad para una propuesta de software que pueda evolucionar de forma autónoma.

En Ciencias de la Computación, “the hill-climbing algorithm”, es una técnica de optimización matemática que pertenece a la familia de “busqueda local”. Es un algoritmo

348 IEEE LATIN AMERICA TRANSACTIONS, VOL. 11, NO. 1, FEB. 2013

iterativo que comienza con una solución arbitraria para un problema, luego intenta encontrar una mejor solución mediante cambios incrementales a un elemento simple de la solución. Si el cambio produce una mejor solución, se le produce un cambio incremental a la nueva solución y se repite hasta que pueda encontrarse la mejor solución.

Lo útil de este punto es establecer una terminología: Una mutación M es exitosa, si A’=M(A) cumple mejor con los objetivos propuestos para A; sino, se considera que M falla. Entonces, una mutación es un algoritmo arbitrario que transforma, mapea el organismo original en un nuevo organismo. Toma como entrada un organismo y produce, como salida, otro organismo y esa mutación tiene asociada una probabilidad de ocurrencia. Por otro lado, si en algún momento podemos construir un organismo de software que pueda mutar con un probabilidad de ocurrencia, esta probabilidad debería estar asociada a un conocimiento de la distancia a la que está ese nuevo organismo, de cumplir con un objetivo en particular. Para el contexto en el que se podría aplicar esta idea en la Ing.de Software, el cumplimiento de un objetivo, está asociado al cumplimiento de un requerimiento, funcional, no funcional, de seguridad, etc.

En el primer trabajo de Chaitin, lo que se propone como programa mas evolucionado, es aquel que logre calcular el entero mayor. Un organismo es más evolucionado que otro en la medida en que logra calcular un entero mayor. Otra idea más que relevante, si nos proponemos que un “organismo artificial” evolucione a través de mutaciones, es poder cuantificar esa evolución y determinar en un momento que tan lejos estamos de lo que pretendemos lograr como nuevo organismo artificial evolucionado. Nuevamente, si pretendemos construir en algún momento este organismo de software, deberíamos conocer la “distancia de mutación”. Qué tan costoso es ir desde el organismo A al organismo B? Sin entrar en detalles, es una medida a tener en cuenta para intentar modelar mutaciones que puedan transformar un programa A en un programa B.

Este proceso de mutar organismos, también debería poder detenerse en algún momento. La evolución debería estar bajo el control de un meta-organismo, un oráculo. El criterio para la detención debería ser el cumplimiento de un conjunto de requerimientos. De ese modo, se podría pensar en un organismo que parte de un estado inicial primigenio, y evoluciona a lo largo de “n” estados. En cada una de las “i” mutaciones, con i < n, el software va dando cumplimiento parcial a un conjunto cada vez mayor de requerimientos. Cuando llega a la mutación “n”, da cumplimiento al total o a una determinada proporción de los requerimientos, satisfactoria para el diseñador de software.

IV. LA ESPIRAL INMORTAL Somos máquinas de supervivencia [1]. Y esta frase incluye

a todos los animales, plantas, bacterias y virus. Cada uno presenta una apariencia muy variada tanto en el aspecto exterior como en sus órganos internos. El pulpo no se parece en nada a un ratón y ambos son muy diferentes a un roble. Sin embargo, en la química fundamental son casi uniformes, y en

especial, en lo referente al soporte de los genes, son básicamente el mismo tipo de moléculas para todos nosotros, desde las bacterias hasta los elefantes.

Todos somos máquinas de supervivencia para un mismo tipo de replicador, las moléculas denominadas ADN (ácido desoxirribonucleico). Hay muchas maneras de prosperar en el mundo y los replicadores han construido una vasta gama de máquinas para prosperar explotándolas. Un mono es una máquina que preserva los genes en las copas de los árboles, un pez es una máquina que preserva los genes en el agua. El ADN opera de maneras muy creativa.

Una molécula de ADN es una larga cadena de pequeñas moléculas denominadas nucleótidos. De la misma manera que las moléculas de proteínas son cadenas de aminoácidos, así las moléculas de ADN son cadenas de nucleótidos. Una cadena de ADN es muy pequeña para ser vista directamente, pero su forma exacta ha sido ingeniosamente determinada por medios indirectos. Consiste en un par de cadenas de nucleótidos enrollados en una elegante espiral: la “doble hélice”; la espiral inmortal. Los nucleótidos que la componen son sólo de cuatro tipos distintos, cuyos nombres podemos abreviar como A, T, C y G. Son los mismos en todos los animales y plantas. Lo que difiere es el orden en que están ensartados. El componente G de un hombre es idéntico, en todos los detalles, al componente G de un caracol. Pero la secuencia de los componentes en un hombre no sólo es diferente de la de un caracol, sino que lo es también de la secuencia de los demás hombres.

Este ADN, podría ser considerado como un conjunto de instrucciones, información, de cómo hacer un cuerpo, escritas en un alfabeto A, T, C, G de los nucleótidos.

V. PATRONES DE DISEÑO Después de este breve comentario sobre lo que es el ADN, extraído en su mayoría del “El Gen Egoista” de Richard Dawkins, quizás debamos pensar en empezar a hacer ciertas analogías con las estructuras que hoy conocemos que son comunes en el “software artificial” construido por el hombre hasta el momento. Conocemos de la existencia del concepto de patrón de diseño, desde la publicación por parte de Christopher Alexander de su libro "A Pattern Language", en el año 1977 donde se puede leer su teoría de cómo el lenguaje de patrones puede ayudar a entender los objetos no como objetos aislados en sí, sino como elementos de interacción humana. Él define un patrón de diseño como: "…una descripción de un problema que ocurre una y otra vez en nuestro entorno, así como la solución a ese problema, de tal modo que se pueda aplicar la solución un millón de veces, sin hacer lo mismo dos veces…". Esta descripción que menciona da nombre al patrón; luego describe el problema que trata y ofrece una solución. Finalmente habla de las consecuencias, ventajas e inconvenientes, que tiene esta solución. Por ejemplo, uno de sus patrones de diseño de edificios, llamado originalmente "South facing outdoors", constata que la gente no usará un espacio abierto si no es soleado (exceptuando climas muy

SOLINAS AND ANTONELLI : SOFTWARE EVOLUTION AND DESIGN PATTERNS 349

cálidos) y propone la solución de colocar siempre los espacios abiertos, como un jardín, en la parte sur del edificio (para nuestro hemisferio sería al norte, pero la idea es totalmente aplicable). Posteriormente los patrones fueron introducidos en el dominio del desarrollo de software por diferentes caminos. Algunos desarrolladores fueron inspirados directamente por los trabajo de Alexander. Otros utilizaron fuentes similares, redescubriendo y reinventando aproximaciones sobre los diseños que ya se conocían. Frecuentemente se pueden encontrar soluciones similares para resolver un problema que tiene en cuenta una funcionalidad en particular, que resisten el paso del tiempo y cuyas consecuencias son muy bien conocidas. Los patrones de diseño de software, actualmente están documentados y presentados en varios libros [5] [6], artículos, sitios web [7] y conferencias “Pattern Language Of Programs” (PLOP) [8]. Ahora bien, los patrones de diseño no aparecieron con Alexander, existían como soluciones conocidas en el cuerpo de conocimiento de Arquitectura, construido durante años de historia de la humanidad. Alexander los identificó como abstracción y les dio un nombre propio. En el caso de los patrones de software ocurre algo similar. Se han descubierto y se siguen descubriendo, en el “software artificial” que ha generado el hombre, desde que se creó el primer programa de computadora. Es como si viviéramos una etapa en donde la humanidad está construyendo “software artificial” reutilizando y creando los componentes básicos que en el futuro serán el “ADN artificial” del software del futuro. Nuevamente la pregunta de arriba: Si pudiéramos escanear todo el “software artificial” de la humanidad y “secuenciarlo”, encontraríamos estructuras que se repiten una y otra vez? O sería una interminable cadena de creatividad sin límites? Obviamente que encontraríamos ceros y unos. Después de todo, es el lenguaje del hardware, que por ahora nos permite entretenernos construyendo software. Y no vemos que esta capa pueda llegar a cambiar en el mediano plazo. Sin embargo a un nivel de abstracción más alto, más próximo al problema real que a la solución. Encontraríamos un universo infinito de creatividad de soluciones de software? Es muy probable que no, y está claro que el descubrimiento de los patrones de diseño nos está diciendo que no. Existen estructuras más complejas que meros ceros y unos que se repiten una y otra vez en el “software artificial”. Quizás este proceso de descubrimiento de patrones de diseño tenga cierta analogía con la identificación de los componentes del ADN y su secuenciación. El ADN del software tiene forma de patrón de diseño. Las únicas evidencias que tenemos de esto, es la documentación de patrones de diseño que se puede consultar y que permanentemente se ve enriquecida en las conferencias PLOP. No lo podemos probar. No hemos realizado los experimentos para intentarlo, pero la analogía que existe entre un dominio y el otro es muy fuerte. Qué valor tendría esto para la construcción de software? Si estos son los genes, si los patrones de diseño son el ADN, tenemos el diccionario para construir cualquier obra literaria. Ahora el problema es cómo tomar esas palabras del diccionario para que en un “caldo de cultivo” primigenio, evolucionen hacia un conjunto de requerimientos.

VI. REQUERIMIENTOS DE SOFTWARE Independientemente del modelo de proceso, lenguaje, plataforma o herramienta que se seleccione, cuando se pretende construir software, hay algo que no va a cambiar. Es la necesidad de satisfacer requerimientos. Funcionales, no funcionales, de seguridad, etc. Ellos guiarán en todo momento la construcción de software. Si bien es una idea aceptada y conocida, en el contexto de este trabajo, es importante. Trasladada esta idea de “requerimientos”, a la evolución de los seres vivos, la Ingeniería de Requerimientos podría ser el equivalente a lo que estudia la epigenética [9]. Término utilizado por C.H.Waddington en 1953 para referirse al estudio de las interacciones entre genes y medio ambiente que se producen en los organismos. De pronto la evolución de los genes está influenciada por el medio ambiente en donde existen. Cabe la siguiente pregunta: qué posibilidades de sobrevivir tiene un “software natural/artificial” que no se adapte a su medio ambiente, que no cumpla con la especificación de requerimientos que los inspiró? No por mucho tiempo. Qué queremos decir con esto? Que los requerimientos son una de los aspectos que deben conducir las mutaciones de “software artificial”, de manera autónoma. Construir una métrica de cumplimiento de requerimientos, antes y después de una mutación, nos permitiría evaluar a qué distancia estamos de cumplir con lo que queremos construir. A qué proporción de los requerimientos estamos dando cumplimiento. El otro aspecto son los patrones de diseño. Aquellas mutaciones que me lleven en la dirección de organismos más próximos a cumplir con los requerimientos, por ejemplo de seguridad, deberían ser las más probables. Aquellas mutaciones que estén más próximas a producir un patrón de diseño, también deberían ser las más probables. Y un oráculo debería estar chequeando esta evolución para que llegado un determinado momento pueda detener el proceso y poner a consideración del ser humano que describió los requerimientos, el producto de la evolución. En un escenario futuro como este, la intervención del ser humano en la construcción de software quedará reducida a especificar requerimientos. En este punto la pregunta es si existe al menos a nivel experimental, algún mecanismo, herramienta, método que nos permita elicitar requerimientos directamente a partir del lenguaje natural.

A. LEL y Requerimientos Los términos de un Léxico Extendido del Lenguaje (LEL), proponen un método para formalizar un modelo contextual de requerimientos utilizando lenguaje natural, a partir del cual poder comenzar a analizar, diseñar y construir software. Se puede revisar la bibliografía específica de Leonardi [10] y Antonelli [11]. Quizás los términos de LEL puedan ser un punto de partida para poder elicitar requerimientos y comportamiento e introducirlos en un entorno que pueda evolucionar de forma autónoma a partir de ellos, utilizando patrones de diseño, a través de “n” mutaciones. Solinas [12] ha mostrado que es posible modelar patrones de seguridad utilizando LEL y

350 IEEE LATIN AMERICA TRANSACTIONS, VOL. 11, NO. 1, FEB. 2013

Escenarios. Cabría experimentar con patrones de diseño en general, ya no específicos del dominio de la seguridad. Aquí el problema está en encontrar las transformaciones que puedan llevar a un término de LEL a colaborar de forma autónoma entre ellos para conformar patrones de diseño. Es un primer paso. Luego, sostener la búsqueda, siempre autónoma, de otros patrones de diseño que permitan ir dando cumplimiento a requerimientos parciales. Las mutaciones así controladas, con la medida del cumplimiento de los requerimientos en todo momento, deberían permitir construir algo que tuviese un comportamiento similar al software que hoy conocemos. Una de las propiedades de los seres vivos: moléculas, es la replicación con el objetivo de construir estructuras más complejas y estables utilizando un mismo componente. Pero las copias no son perfectas. Ocurren errores. Qué podría ocurrir si en un proceso simulado de evolución, con objetoides vinculados a términos de LEL y por ende a requerimientos, pudiesen instanciarse, pero con cierta probabilidad de que no todas las copias fuesen iguales. Ya no tendría objetos que tuviesen tan solo un conocimiento y un comportamiento. Además tendrían asociada una probabilidad de replicarse con errores y de pronto ser diferentes a la clase que les dio origen. Cómo se comportarían en su relación con las estructuras más complejas de las que forman parte? Podrían dar lugar a comportamientos no buscados, a estructuras no esperadas, a soluciones diferentes. Otro punto interesante a tener en cuenta y que se observa en los seres vivos, es que las copias no son hechas a partir de un único original. Las copias se hacen a partir de otras copias, las cuales a su vez fueron hechas a partir de otras copias. De este modo los errores empiezan a ser acumulativos y los comportamientos muy diferentes. Pero, oh sorpresa, son estos errores los que hacen posible la evolución. Quizás esto nos esté dando una pista de que lo que hoy conocemos como Programación Orientada a Objetos (POO) está incompleta y podría contemplar estas posibilidades que a los seres vivos les viene dando buenos resultados. Los seres vivos evolucionan dejando en el camino aquellas mutaciones que no son viables. Esto ayuda a que permanezca la información de aquellas que son exitosas, guardada en su ADN. Ese ADN está presente en todos los seres vivos. Pero no existe un único ser vivo experto que guarde toda la información, sino que está distribuida en múltiples seres vivos que se han adaptado a micro escenarios con éxito y continúan viviendo en ellos. Hoy existen múltiples variantes de software, adaptado a escenarios diferentes, sobreviviendo a requerimientos siempre cambiantes. En todos ellos se puede encontrar patrones de diseño. Quizás en el camino de experimentación podamos encontrar, como en la física estadística, diagramas de cambios de fase que nos indiquen cambios en la pendiente del comportamiento del conjunto que nos conduzca a la solución buscada. O nos eviten continuar avanzando en direcciones que no son las correctas.

VII. CONCLUSIONES Son demasiadas preguntas y pocas respuestas, pero una fuerte sospecha de que en el estudio de la evolución y

diversidad de los seres vivos está la solución a la construcción del software del futuro. Los patrones de diseño podrían llegar a constituir el ADN del software construido por la humanidad. O quizás haya componentes elementales que conforman los patrones de diseño y que aún no se han descubierto, análogos a los nucleótidos A, T, C y G para el ADN. Construir software será una tarea automática que tendrá más que ver con la evolución de los seres vivos, que con los métodos que hoy se conocen y la tarea de los futuros profesionales que construyan software estará más próxima al dominio del problema que al de la solución. Mientras el ser humano siga siendo el demandante del todo el software que hoy se construye, será el lenguaje natural el medio para expresar inicialmente los requerimientos. Si en el futuro se construye un artefacto que permita evolucionar software de manera autónoma, deberá entender el lenguaje natural y poder interpretar requerimientos a partir de él.

REFERENCIAS [1] Dawkins Richard, El Gen Egoista 14a edición, Barcelona: Salvat

Editores s.a., 2002. [2] Chaitin Gregory, «Life as Evolving Software,» de A Computable

Universe: Understanding and Exploring Nature as Computation, Hector Zenil, 2012.

[3] Dyson Freeman , Origins of Life Revised Edition, USA: Cambridge Univesity Press, 1999.

[4] Chaitin Gragory, «G J Chaitin Home Page,» [En línea]. Available: http://www.umcs.maine.edu/~chaitin/. [Último acceso: Abril 2012].

[5] Gamma Erich, Helm Richard, Johnson Ralph, Vlissides John, Design Patterns: Elements of Reusable Object-Oriented Software, USA: Addison-Wesley, 1995.

[6] Sherman Alpert, Kyle Brown, Bobby Woolf, The Design Patterns Smalltalk Companion, USA: Addison-Wesley, 1998.

[7] «The Hillside Group,» [En línea]. Available: http://www.hillside.net/. [Último acceso: Abril 2012].

[8] «PLoP 2012,» The Hillside Group, [En línea]. Available: http://www.hillside.net/plop/2012/. [Último acceso: Abril 2012].

[9] «Epigenética?,» [En línea]. Available: http://epigenome.eu/es/. [Último acceso: Abril 2012].

[10] Leonardi, C., Leite J.C., Rossi G., «Una Estrategia de Modelado Conceptual de Objetos basada en Modelos de Requisitos en Lenguaje Natural,» Universidad Nacional de La Plata, La Plata, Argentina, 2001.

[11] Antonelli L., «Traceability en la elicitación y especificación de requerimientos,» Universidad Nacional de La Plata, La Plata, Argentina, 2003.

[12] Solinas M., «Elicitación y Trazabilidad de Requerimientos utilizando Patrones de Seguridad,» Universidad Nacional de La Plata, La Plata, Argentina, 2012.

[13] Rifkin Jeremy, El Siglo de la Biotecnología, Barcelona: Paidós Ibérica s.a., 2009.

Solinas M. (M’96) IEEE member since 1996. Since 2007 have been Professor of Fac.de Ciencias Exactas Físicas y Naturales (FCEFyN)’ Computer Department at Universidad Nacional de Córdoba (UNC). Became Masters in Software Engineering at the Universidad Nacional de La Plata in 2012. Categorized as a researcher since 2004, serves on the

“Laboratorio de Arquitectura de Computadoras” (LAC) of Computer Departament at UNC FCEFyN. Your work area is the Software Engineering and Computer Security. Msc.Solinas are Computer Society member and has published papers in local and international conferences in the area of software

SOLINAS AND ANTONELLI : SOFTWARE EVOLUTION AND DESIGN PATTERNS 351

engineering and development for Astronomy. Founding member of the Sub-Section Cordoba Argentina Section of IEEE.

Antonelli L. Obtained a degree in Computer Science at Universidad Nacional de La Plata (UNLP) in Argentina in 1998. He joined Laboratorio de Investigación en Informática Avanzada (LIFIA) a research laboratory at UNLP in the same year. In 2003 he became Magister in Software Engineering and now he is waiting to present his doctoral dissertation. He is involved in teaching activities for the bachelor and master’s

degree, and he participates as a requirements and software engineering in software development projects from government and private organisms.

352 IEEE LATIN AMERICA TRANSACTIONS, VOL. 11, NO. 1, FEB. 2013