Ensayo De Arquitectura De Software

Arquitecturas de software

Evolución de las arquitecturas de software. Cómo eran antes y cómo son ahora.

Antes se realizaban los sistemas sin una base, los programadores realizaban los sistemas sin una arquitectura previa, simplemente tiraban código, hacían que el sistema funcionara pero no como ahora que aparte de hacer el software funcional se sabe que está bien hecho. Eso gracias a las arquitecturas de software actualmente la que utilizamos MVC por ejemplo.

Hace ya tiempo Dijkstra, quien sostenía que las ciencias de la computación eran una rama aplicada de las matemáticas y sugería seguir pasos formales para descomponer problemas mayores, fue uno de los introductores de la noción de sistemas operativos organizados en capas que se comunican sólo con las capas adyacentes y que se superponen “como capas de cebolla”. Inventó o ayudó a precisar además docenas de conceptos: el algoritmo del camino más corto, los stacks, los vectores, los semáforos, los abrazos mortales. De sus ensayos arranca la tradición de hacer referencia a “niveles de abstracción” que ha sido tan común en la arquitectura subsiguiente.

Una novedad importante en la década de 1970 fue el advenimiento del diseño estructurado y de los primeros modelos explícitos de desarrollo de software. Estos modelos comenzaron a basarse en una estrategia más orgánica, evolutiva, cíclica, dejando atrás las metáforas del desarrollo en cascada que se inspiraban más bien en la línea de 7 montaje de la ingeniería del hardware y la manufactura. Surgieron entonces las primeras investigaciones académicas en materia de diseño de sistemas complejos o “intensivos”.

Poco a poco el diseño se fue independizando de la implementación, y se forjaron herramientas, técnicas y lenguajes de modelado específicos.

Hoy en día toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera más comprensible si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí, evidente dado que describen la misma cosa.

Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura:

• La visión estática: describe qué componentes tiene la arquitectura.

• La visión funcional: describe qué hace cada componente.

• La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y cómo interactúan entre sí.

Las vistas o modelos de una arquitectura de software pueden expresarse mediante uno o varios lenguajes.

Qué ha cambiado y por qué.

La arquitectura de software ha cambiado en el aspecto de que ahora si hace honor a su nombre pues a diferencia de antes ahora si es está estructurada, ya no se realiza un sistema simplemente empezando a codificar, ahora existen formas de realizar una buenas estructura lo que era requerido para el desarrollo de software de calidad, para así reducir el número de errores, encontrar fallas entre muchos otros.

Se ha demostrado que los criterios seleccionados en la descomposición de un sistema impactan en la estructura de los programas y propuso diversos principios de diseño que debían seguirse a fin de obtener una estructura adecuada.

- Qué criterios tomar la hora de decidirse por una arquitectura para nuestro proyecto.

Debemos tomar en cuenta que las partes fundamentales que representen riesgo al momento de que se nos presenten inconvenientes.

Si hay partes en la arquitectura que son propensa a cambiar y de que impacto serán en nuestro proyecto, tener a la mano soluciones para posibles cambios es lo ideal o si ya de plano tenemos que cambiar todo.

No es bueno intentar cambiar la arquitectura, y tampoco el hacer suposiciones que no se puede verificar. Tenemos que tener opciones para el futuro, por si hay algún cambio que pueda afectar.

Habrá aspectos de su diseño que se deben fijar al inicio del proceso, que pueden representar costo significativo si se requiere rediseño. Identificar estas áreas de forma rápida e invertir el tiempo necesario para hacerlo bien.

Hay que tener en mente construir algo que pueda cambiar, que soporte el cambio por si hay más necesidades o diversas situaciones que puedan surgir, hay que enfocarnos en eso es hacerlo flexible y no estar con la mentalidad de que sea duradero.

Utilizar las herramientas de diseño, sistemas como UML nos ayudará a encontrar los requerimientos y decisiones arquitectónicas y de diseño, y analizar su impacto modelado. Pero no debemos profundizar mucho en eso porque de ser así nos estaríamos contradiciendo en lo antes mencionado que hay que crear un proyecto flexible, entonces no formalizar el modelo en la medida en que suprime la capacidad de iterar y adaptar el diseño fácilmente.

Se requiere usar modelos y visualizaciones como herramienta de comunicación y colaboración ya que se necesita comunicación eficiente del diseño, las decisiones que toma, y continua cambios en el diseño, es fundamental para la buena arquitectura. Usar modelos, vistas y otras visualizaciones de la arquitectura para comunicar y compartir su diseño eficiente con todas las partes interesadas, y que permitan la rápida comunicación de cambios en el diseño.

Identificar las decisiones clave de ingeniería. Utilizar la información a la que fácilmente podemos acceder para comprender las decisiones de ingeniería clave y las áreas donde los errores son más a menudo se ha realizado. Invertir en conseguir que estas decisiones claves desde el primer momento para que el diseño es más flexible y menos probable que se rompa por los cambios.

Considerar el uso de un enfoque incremental e iterativo para una optima realización de la arquitectura.

Fuentes

Microsoft aplication architecture guide 2nd Edition.

Biblioteca ITSON.

...