Está en la página 1de 6

Arquitectura del software

La Arquitectura del Software es el diseo de ms alto nivel de la estructura de un sistema. Una Arquitectura de Software, es tambin denominada Arquitectura lgica. 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. 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, losdiagramas de flujo de datos, etc. Estos lenguajes son apropiados nicamente para un modelo o vista. Afortunadamente existe cierto consenso en adoptar UML (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

En resumen cada escenario plantea retos, condiciones y necesidades diferentes, por lo que tenemos que preguntarnos que herramientas, personas, presupuestos, conocimiento y tiempo necesitamos para cada escenario. El arquitecto del software es entonces el encargado de establecer a que nivel con que estrategias y que herramientas son necesarias para realizar una implementacin que satisfaga los requisitos. DISEO DE LA ARQUITECTURA DEL SOTFWARE Es la representacin que capacita al ingeniero del software para: Analizar la efectividad del diseo para la consecucin de los requisitos fijados. Considerar las alternativas arquitectnicas en una etapa en la cual hacer cambios en el diseo es relativamente fcil. Reducir los riesgos asociados a la construccin del software. En el diseo arquitectnico, un componente del software puede ser tan simple como un mdulo de programa, pero tambin puede ser algo complicado como incluir base de datos y software intermedio (middleware) que permiten la configuracin de una red de clientes y servidores. El diseo de la arquitectura del software tiene en cuenta 2 niveles de la pirmide, el diseo de datos y el diseo arquitectnico. El diseo de datos nos facilita la representacin de los componentes de datos de la arquitectura. El diseo arquitectnico se centra en la representacin de la estructura de los componentes del software, sus propiedades e interacciones.

Por qu es importante la arquitectura? Facilitan la comunicacin entre todas las partes interesadas en el desarrollo de un sistema basado en computadora. Destaca decisiones tempranas de diseo que tendrn un profundo impacto en todo el trabajo de ingeniera del software. Constituye un modelo relativamente pequeo e intelectualmente comprensible de cmo est estructurado el sistema y de cmo trabajan juntos sus componentes. DISEO DE DATOS El diseo de datos tambin llamado arquitectura de datos, crea un modelo de datos y/o informacin que se representa con un nivel de abstraccin (visin de datos cliente/usuario). Este modelo de datos, es refinado en progresivas representaciones especficas de la implementacin, que pueden ser procesadas por un sistema basado en computadora. Al nivel de los componentes del programa, el diseo de las estructuras de datos y de los algoritmos asociados requeridos para su manipulacin, son la parte esencial en la creacin de aplicaciones de alta calidad. Al nivel de aplicacin, la traduccin de un modelo de datos en una base de datos es el punto clave para alcanzar los objetivos de negocio del sistema. Al nivel de negocios, el conjunto de informacin almacenada en las diferentes bases de datos y reorganiza en el almacn de datos facilita la minera de datos o el descubrimiento de conocimiento que puede influir en el prximo xito del negocio. Modelado de datos, estructura de datos, base de datos y almacn de datos. Los objetos de datos son modelados utilizando diagramas de entidad-relacin y el diccionario de datos. La actividad de diseo de datos traduce esos elementos del modelo de requisitos en estructuras de datos a nivel de los componentes del software y, cuando es necesario a arquitecturas de base de datos a nivel aplicacin. Un almacn de datos es un entorno de datos separado, que no est directamente integrado con las aplicaciones del da a da, pero que abarca todos los datos utilizados por una empresa. Caractersticas de un almacn de base de datos:

Orientacin por materia: Esto nos lleva a una exclusin de datos que podran ser necesarios para una funcin particular del negocio. Integracin: Sin tener en cuenta la fuente de datos, da consistencia nombrar convenciones, unidades y medidas, estructuras de codificacin y atributos fsicos. Restriccin de tiempo: Para un entorno aplicacin orientado a transaccin, los datos son precisos en el momento del acceso y por un perodo de tiempo pequeo (60 a 90 das) antes del acceso. En un almacn de datos se accede a los datos en un momento especfico de tiempo. No volatilidad: En el almacn de datos, los datos se cargan, pero despus de la primera transferencia, los datos no cambian. Diseo de datos a nivel de componentes. Se centra en la representacin de estructuras de datos a las que se accede directamente a travs de uno o ms componentes del software. Principios para la especificacin de los datos: 1. Los principios del anlisis sistemtico aplicado a la funcin y al comportamiento deberan aplicarse tambin a los datos. 2. Todas las estructuras de datos y las operaciones a llevar a cabo en cada una de ellas deberan estar claramente identificadas. 3. Se debera establecer un diccionario de datos y usarlo para definir el diseo de los datos y del programa 4. Las decisiones de diseo de datos de bajo nivel deberan dejarse para el final del proceso de diseo. 5. La representacin de las estructuras de los datos deberan conocerla solo aquellos mdulos que deban hacer uso directo de los datos contenidos dentro de la estructura. 6. Deberan desarrollarse una biblioteca de estructuras de los datos tiles y de las operaciones que se les pueden aplicar. 7. Un diseo del software y un lenguaje de programacin debera soportar la especificacin y realizacin de los tipos abstractos de datos.

Despus de haber desarrollado y refinado la estructura, se deben completar las siguientes tareas: Se debe desarrollar una descripcin del procesamiento para cada mdulo. Se aporta una descripcin de la interfaz para cada mdulo. Se definen las estructuras de datos generales y locales. Se anotan todas las limitaciones/restricciones del diseo. Se lleva a cabo una revisin del diseo. Se considera un refinamiento (si es necesario y est justificado). El diseo de estructuras de datos puede tener profundo impacto en la arquitectura y en los detalles procedimientos de cada componente de software. Debe fomentarse el refinamiento de la arquitectura del software durante las primeras etapas del diseo. Es importante anotar que la simplicidad estructural es a menudo, reflejo de elegancia y eficiencia. El refinamiento del diseo debera luchar por obtener un pequeo nmero de mdulos consecuentes a la modularidad operativa y la estructura de datos menos compleja que sirva adecuadamente a los requisitos de informacin.

También podría gustarte