La historia de la arquitectura de software

La historia de la Arquitectura de software

Cada vez que se narra la historia de la AS se reconoce que Edsger Dijikstra quien propuso el establecimiento de una estructuración correcta de los sistemas de SW antes de programar, al igual que el mismo sostenía que las ciencias de la computación eran una rama aplicada de las matemáticas, él también fue uno de los instructores de la noción de SO organizados por capas. También ayudo a precisar docenas de conceptos como “el algoritmo del camino más corto”, stacks, vectores, semáforos, entre otros. De él también podemos hacer referencia  a “niveles de abstracción” que es tan común hoy en día.

Durante NATO 1969, un año después de que se fundara la Ingeniería de Software P.I. Sharp formulo lo siguiente en base a las ideas de Dijkstra

“Pienso que tenemos algo, aparte de la ingeniería de software: algo de lo que hemos hablado muy poco pero que deberíamos poner sobre el tapete y concentrar la atención en ello. Es la cuestión de la arquitectura de software. La arquitectura es diferente de la ingeniería. Como ejemplo de lo que quiero decir, echemos una mirada a OS/360. Partes de OS/360 están extremadamente bien codificadas. Partes de OS, si vamos al detalle, han utilizado técnicas que hemos acordado constituyen buena práctica de programación. La razón de que OS sea un amontonamiento amorfo de programas es que no tuvo arquitecto. Su diseño fue delegado a series de grupos de ingenieros, cada uno de los cuales inventó su propia arquitectura. Y cuando esos pedazos se clavaron todos juntos no produjeron una tersa y bella pieza de software.”

Sharp afirma que con el tiempo probablemente se legue a hablarse de “La escuela de arquitectura de Dijkstra”. Después de esto nadie volvió a tocar el tema, aunque por algunos años “arquitectura” era tomada como una metáfora, pero esta no tenía ni precisión semántica ni consistencia pragmática. En el 69 Fred Brooks Jr y Ken Iverson tomaban como arquitectura a la estructura conceptual de un sistema en la perspectiva del programador. En 1975 Brooks tomo este concepto para designar “la especificación completa y detallada de la interfaz de usuario” y considero al arquitecto como un agente del usuario.

Algo importante durante los 70’s fue el Diseño estructurado y de los primeros modelos explícitos de desarrollo de software, estos modelos se basaron en una estructura más orgánica, evolutiva y cíclica dejado atrás el desarrollo en cascada. También surgieron las primeras investigaciones académicas referentes a diseño de sistemas complejos, esto dio pauta a que de poco en poco se independizara de la implementación y forjara de una manera más especifica.

En esa misma época David Parnas demostró que los criterios seleccionados en la descomposición de un sistema impactan en la estructura de los programas, propuso varios diseños que se debían seguir a fin de obtener una estructura adecuada, así también desarrollo temas como Módulos de ocultamiento de información, estructuras de software y familias de programas todo enfatizado a la calidad de software medible en economía y mantenimiento. Después en 1972 publico un ensayo en que mencionaba la mejora del diseño de estos mediante la flexibilidad y control conceptual del sistema.

El concepto de ocultamiento se fue mezclando con encapsulamiento y abstracción, tras algunos avatares de avance y retroceso. Los arquitectos más escrupulosos distinguen entre encapsulamiento y ocultamiento, considerando a aquél como una capacidad de los lenguajes de programación y a éste como un principio más general de diseño. En este punto Parnas no habla sobre POO sino de módulos y subrutinas ya que los Objetos aun no existían en la programación

Parnas nos dice lo siguiente acerca de las familias de programas:

“Una familia de programas es un conjunto de programas (no todos los cuales han sido construidos o lo serán alguna vez) a los cuales es provechoso o útil considerar como grupo. Esto evita el uso de conceptos ambiguos tales como “similitud funcional” que surgen a veces cuando se describen dominios. Por ejemplo, los ambientes de ingeniería de software y los juegos de video no se consideran usualmente en el mismo dominio, aunque podrían considerarse miembros de la misma familia de programas en una discusión sobre herramientas que ayuden a construir interfaces gráficas, que casualmente ambos utilizan.”

Este concepto soporta la noción de derivar un miembro de la familia a partir de uno ya existente, al igual que se pueden derivar varios miembros de la familia de un punto de decisión en común, aclarando la semejanza y diferencias entre ellos. La significación del concepto de familia de programas para la AS es que ella corresponde a las decisiones cerca del tope del árbol de decisión de Parnas. Es importante considerar que el árbol de Parnas es top-down no sólo porque se construye y recorre de lo general a lo particular, sino porque sus raíces se encuentran hacia arriba (o a la izquierda si el modelo es horizontal).

Durante los 80’s los métodos de desarrollo estructurado demostraron no escalar suficientemente y dejaron el descubrimiento de un nuevo paradigma el de la POO. Lo cual llevo a la investigación de lo que sería el diseño Orientado a Objetos lo cual se puede remontar a la década de 1960 con Simula, un lenguaje de simulación el cual fue el primero en proporcionar tipos de datos abstractos y clases y después se refino con la llegada de Smalltalk, ya en 1980 se toma el concepto de AS para hacer referencia a la configuración morfológica de una aplicación.

...