Arquitectura de software

En los inicios de la informtica, la programacin se consideraba un arte y se desarrollaba como tal, debido a la dificultad que entraaba para la mayora de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guas generales, con base a las cuales se puedan resolver los problemas. A estas, se les ha denominado Arquitectura de Software, porque, a semejanza de los planos de un edificio o construccin, estas indican la estructura, funcionamiento e interaccin entre las partes del software. En el libro "An introduction to Software Architecture", David Garlan y Mary Shaw definen que la Arquitectura es un nivel de diseo que hace foco en aspectos "ms all de los algoritmos y estructuras de datos de la computacin; el diseo y especificacin de la estructura global del sistema es un nuevo tipo de problema".

Arquitectura
 
La Arquitectura del Software es el diseo de ms alto nivel de la estructura de un sistema. Una Arquitectura de Software, tambin denominada Arquitectura lgica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco

Una arquitectura de software se selecciona y disea con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de informacin, pero no solamente los de tipo funcional, tambin otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interaccin con otros sistemas de informacin. Las restricciones son aquellas limitaciones derivadas de las tecnologas disponibles para implementar sistemas de informacin. Unas arquitecturas son ms recomendables de implementar con ciertas tecnologas mientras que otras tecnologas no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real. La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computacin, sus interfaces y la comunicacin entre ellos. Toda arquitectura debe ser implementable en una arquitectura fsica, que consiste simplemente en determinar qu computadora tendr asignada cada tarea.

La arquitectura de software, tiene que ver con el diseo y la implementacin de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto nmero de elementos arquitectnicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeo de un sistema, as como requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad. Kruchten, Philippe

Breve resea histrica

En los aos 1960 ya se acariciaba el concepto de arquitectura de software en los crculos de investigacin (por ejemplo, por Edsger Dijkstra). No obstante, toma popularidad en los aos 1990 tras reconocerse la denominada crisis del software y como tema de inters de la incipiente disciplina de la ingeniera del software.

Modelos o vistas
Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera ms comprensible si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripcin 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 nmero y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura: La visin esttica: describe qu componentes tiene la arquitectura. La visin funcional: describe qu hace cada componente. La visin dinmica: describe cmo se comportan los componentes a lo largo del tiempo y como interactan entre s. Las vistas o modelos de una arquitectura de software pueden expresarse mediante uno o varios lenguajes. El ms obvio es el lenguaje natural, pero existen otros lenguajes tales como los diagramas de estado, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados nicamente para un modelo o vista. Afortunadamente existe cierto consenso en adoptarUML (Unified Modeling Language, lenguaje unificado de modelado) como lenguaje nico para todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser capaz de describir determinadas restricciones de un sistema de informacin (o expresarlas de manera incomprensible).

  

Arquitecturas ms comunes
Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de informacin. Lo habitual es adoptar una arquitectura conocida en funcin de sus ventajas e inconvenientes para cada caso en concreto. As, las arquitecturas ms universales son: Monoltica. Donde el software se estructura en grupos funcionales muy acoplados.

Cliente-servidor. Donde el software reparte su carga de cmputo en dos partes independientes pero sin reparto claro de funciones.

Arquitectura de tres niveles. Especializacin de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentacin (interfaz de usuario), otra para el clculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relacin con la siguiente.

Otras arquitecturas afines menos conocidas son: En pipeline. Entre pares. En pizarra. Orientada a servicios. Dirigida por eventos. Mquinas virtuales

     

http://es.wikipedia.org/wiki/Arquitectura_de_software

Modularidad Como se ha explicado un sistema complejo puede dividirse en piezas ms simples llamadas mdulos, un sistema compuesto de mdulos es llamado modular. El principal beneficio de la modularidad es que permite la aplicacin del principio de separacin de intereses en dos fases: al enfrentar los detalles de cada mdulo por separado ignorando detalles de los otros mdulos, y al enfrentar las caractersticas globales de todos los mdulos y sus relaciones para integrarlos en un nico sistema coherente. Si estas fases son ejecutadas en ese orden se dice que el sistema es diseado de abajo hacia arriba (bottom up), en el orden inverso se dice que el sistema es diseado de arriba hacia abajo (top down). El principio de modularidad tiene tres 3 objetivos principales: capacidad de descomponer un sistema complejo, capacidad de componerlo a partir de mdulos existentes y comprensin del sistema en piezas (o pedazos). La posibilidad de descomponer un sistema se basa en dividir en subproblemas de forma top down el problema original y luego aplicar el principio a cada subproblema en forma recursiva. Este procedimiento refleja el bien conocido principio de Divide y Vencers (Divide & Conquer).

La posibilidad de componer un sistema est basada en obtener el sistema final de forma bottom up a partir de componentes elementales. Idealmente en la produccin de software se quisiera poder ensamblar nuevas aplicaciones tomando mdulos de una biblioteca y combinndolos para formar el producto requerido; estos mdulos deberan ser diseados con el objetivo expreso de ser reusables. La capacidad de comprender cada parte de un sistema en forma separada ayuda a la modificabilidad del sistema. Debido a la naturaleza evolutiva del software muchas veces se debe volver hacia atrs al trabajo previo y modificarlo. Si el sistema solo puede ser comprendido como un todo las modificaciones sern difciles de aplicar y el resultado ser poco confiable. Cuando se hace necesario reparar el sistema, la modularizacin apropiada ayuda a restringir la bsqueda de la fuente de error a componentes separados. Un mtodo de diseo que merezca ser llamado modular, debera satisfacer adems de los objetivos anteriores los dos siguientes: 1. Continuidad modular: Se satisface si un pequeo cambio en la especificacin de un problema provoca slo cambios en un solo mdulo o en un nmero pequeo de mdulos. 2. Proteccin modular: Si produce arquitecturas en las cuales el efecto de una situacin anormal ocurrida en un mdulo durante la ejecucin, queda confinado a ese mdulo (o se propaga slo a unos pocos vecinos). De los objetivos expuestos para asegurar la modularidad, se derivan cinco reglas: 1. Correspondencia directa: Conexin de un sistema de software con los sistemas externos con que est relacionado. La estructura modular obtenida, debe seguir siendo compatible con cualquier otra estructura modular en el dominio del problema. 2. Pocas interfaces de mdulos: Cada mdulo debe comunicarse con el menor nmero de mdulos posible. 3. Interfaces pequeas (acoplamiento dbil): Si dos mdulos se comunican, deben intercambiar la menor informacin posible. 4. Interfaces explcitas: Siempre que dos mdulos A y B se comuniquen, esto debe ser obvio a partir del texto de A, del de B o de ambos. 5. Ocultar informacin: Mostrar slo lo necesario. Para alcanzar estos objetivos los mdulos en los que se divida el sistema deben tener alta cohesin y bajo acoplamiento. Un mdulo tiene alta cohesin si todos sus elementos estn fuertemente relacionados y son agrupados por una razn lgica, esto es todos cooperan para alcanzar un objetivo comn que es la funcin del mdulo. La cohesin es una propiedad interna de cada mdulo, por el contrario el acoplamiento caracteriza las relaciones de un mdulo con otros. El acoplamiento mide la interdependencia de dos mdulos, por ejemplo si el mdulo A hace una llamada a una rutina provista por el mdulo B o accede a una variable declarada por el mdulo B. Si dos mdulos dependen fuertemente uno del otro tienen un alto acoplamiento lo que los vuelve difciles de analizar, comprender, modificar, testear o

reusar en forma separada. Idealmente se quiere que los mdulos de un sistema tengan bajo acoplamiento. Una estructura modular con alta cohesin y bajo acoplamiento permite ver los mdulos como cajas negras cuando se describe la estructura global del sistema y luego encarar cada mdulo por separado cuando se analiza o describe la funcionalidad del mdulo. http://www.revistaciencias.com/publicaciones/EkEppkkyAlHWhlhKZu.php

Ocultamiento de la informacin El principio de ocultamiento de la informacin sugiere que los mdulos se han de caracterizar por decisiones de diseo que los oculten unos a otros. Los mdulos deben especificarse y disearse de forma que la informacin (procedimientos y datos) contenida dentro de un mdulo sea accesible a otros mdulos nicamente a travs de las interfaces formales establecidas para cada mdulo
http://www.chaco.gov.ar/UTN/disenodesistemas/apuntes/de/Unidad_1.html