DISEÑO DE LA ARQUITECTURA DEL SOTFWARE
¿Qué es arquitectura?
Es la representación que capacita al ingeniero del software para:
• Analizar la efectividad del diseño para la consecución de los requisitos fijados.
• Considerar las alternativas arquitectónicas en una etapa en la cual hacer cambios en el diseño es relativamente fácil.
• Reducir los riesgos asociados a la construcción del software.
En el diseño arquitectónico, un componente del software puede ser tan simple como un módulo de programa, pero también puede ser algo complicado como incluir base de datos y software intermedio (middleware) que permiten la configuración de una red de clientes y servidores.
El diseño de la arquitectura del software tiene en cuenta 2 niveles de la pirámide, el diseño de datos y el diseño arquitectónico. El diseño de datos nos facilita la representación de los componentes de datos de la arquitectura. El diseño arquitectónico se centra en la representación de la estructura de los componentes del software, sus propiedades e interacciones.
¿Por qué es importante la arquitectura?
• Facilitan la comunicación entre todas las partes interesadas en el desarrollo de un sistema basado en computadora.
• Destaca decisiones tempranas de diseño que tendrán un profundo impacto en todo el trabajo de ingeniería del software.
• Constituye un modelo relativamente pequeño e intelectualmente comprensible de cómo está estructurado el sistema y de cómo trabajan juntos sus componentes.
DISEÑO DE DATOS
El diseño de datos también llamado arquitectura de datos, crea un modelo de datos y/o información que se representa con un nivel de abstracción (visión de datos cliente/usuario). Este modelo de datos, es refinado en progresivas representaciones específicas de la implementación, que pueden ser procesadas por un sistema basado en computadora.
Al nivel de los componentes del programa, el diseño de las estructuras de datos y de los algoritmos asociados requeridos para su manipulación, son la parte esencial en la creación de aplicaciones de alta calidad. Al nivel de aplicación, la traducción 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 información almacenada en las diferentes bases de datos y reorganiza en el almacén de datos facilita la minería de datos o el descubrimiento de conocimiento que puede influir en el próximo éxito del negocio.
Modelado de datos, estructura de datos, base de datos y almacén de datos.
Los objetos de datos son modelados utilizando diagramas de entidad-relación y el diccionario de datos. La actividad de diseño 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 aplicación.
Un almacén de datos es un entorno de datos separado, que no está directamente integrado con las aplicaciones del día a día, pero que abarca todos los datos utilizados por una empresa.
Características de un almacén de base de datos:
Orientación por materia: Esto nos lleva a una exclusión de datos que podrían ser necesarios para una función particular del negocio.
Integración: Sin tener en cuenta la fuente de datos, da consistencia nombrar convenciones, unidades y medidas, estructuras de codificación y atributos físicos.
Restricción de tiempo: Para un entorno aplicación orientado a transacción, los datos son precisos en el momento del acceso y por un período de tiempo pequeño (60 a 90 días) antes del acceso. En un almacén de datos se accede a los datos en un momento específico de tiempo.
No volatilidad: En el almacén de datos, los datos se cargan, pero después de la primera transferencia, los datos no cambian.
Diseño de datos a nivel de componentes.
Se centra en la representación de estructuras de datos a las que se accede directamente a través de uno o más componentes del software.
Principios para la especificación de los datos:
1. Los principios del análisis sistemático aplicado a la función y al comportamiento deberían aplicarse también a los datos.
2. Todas las estructuras de datos y las operaciones a llevar a cabo en cada una de ellas deberían estar claramente identificadas.
3. Se debería establecer un diccionario de datos y usarlo para definir el diseño de los datos y del programa
4. Las decisiones de diseño de datos de bajo nivel deberían dejarse para el final del proceso de diseño.
5. La representación de las estructuras de los datos deberían conocerla solo aquellos módulos que deban hacer uso directo de los datos contenidos dentro de la estructura.
6. Deberían desarrollarse una biblioteca de estructuras de los datos útiles y de las operaciones que se les pueden aplicar.
7. Un diseño del software y un lenguaje de programación debería soportar la especificación y realización de los tipos abstractos de datos.
ESTILOS ARQUITECTONICOS
Cada estilo describe una categoría del sistema que contiene: un conjunto de componentes, que realiza una función requerida por el sistema, un conjunto de conectores que posibilitan la comunicación, la coordinación y la cooperación entre los componentes; restricciones que definen como se puede integrar los componentes que forman el sistema; y modelos semánticos que permiten al diseñador entender las propiedades globales de un sistema para analizar las propiedades conocidas de sus partes constituyentes.
Arquitecturas centradas a datos
En el centro de esta arquitectura se encuentra un almacén al que otros componentes acceden con frecuencia para actualizar, añadir, borrar o modificar los datos del almacén. El software del cliente accede a l almacén central, es decir accede a lo datos independientes de cualquier cambio en los datos o de las acciones de de cliente.
Arquitecturas de flujo de datos
Se aplica cuando los datos de entrada son transformados a través de una serie de componentes computacionales o manipulativos en los datos de salida. Un patrón tubería y filtro tiene un grupo de componentes llamados filtros, conectados por tuberías que transmiten datos de un componente al siguiente. El filtro está diseñado para recibir entrada de datos de una forma y producir la salida de datos de una forma específica. Si el flujo de datos degenera en una simple línea de transformadores se le llama Secuencial por Lotes.
Arquitecturas de llamada y retorno
Permite al diseñador del software construir una estructura de programa relativamente fácil de modificar y ajustar a escala. Existen 2 subestilos:
• Arquitectura de programa principal: Clasifica de programación descompone las funciones en una jerarquía de control donde un programa principal llama a un número de componentes del programa, los cuales pueden también llamar a otros componentes.
• Arquitectura de llamada de procedimiento remoto: Los componentes de una arquitectura de programa principal/subprograma, están distribuidos entre varias computadoras en una red.
Arquitecturas orientadas a objetos
Los componentes de un sistema encapsulan los datos y las operaciones que se deben realizar para manipular los datos. La comunicación y la coordinación entre componentes se consiguen a través del paso de mensaje.
Arquitecturas Estratificadas
Se crean diferentes capas y cada una realiza operaciones que progresivamente se aproximan mas al cuadro de instrucciones de la maquina. En la capa externa, los componentes sirven a las operaciones de interfaz de usuario. En la capa interna, los componentes realizan operaciones de interfaz del sistema. Las capas intermedias proporcionan servicios de utilidad y funciones de software de aplicaciones.
Complejidad arquitectónica
Para evaluar la complejidad total de una arquitectura dada una técnica consiste en consideran las relaciones de dependencias entre los componentes de la arquitectura. Existen tres tipos de dependencias:
Dependencias de compartimiento: Representan las relaciones de dependencia entre los consumidores que utilizan los mismos recursos o los productores que producen para los mismos consumidores.
Dependencias de flujo: Representan las relaciones de dependencias entre los productores y los consumidores de recursos.
Dependencias restrictivas: Representan las restricciones de un relativo flujo de control entre un cuadro de actividades.
FLUJO DE TRANSFORMACION
La información debe introducirse y obtenerse del software en forma de mundo exterior, la información entra en el sistema a lo largo de caminos que transforman los datos externos a un formato interno. Estos caminos se identifican como flujo de entrada. La información entrante se pasa a través de un centro de transformación y empieza a moverse a lo largo de caminos que ahora conducen hacia fuera del software. Los datos que se mueven a lo largo de este camino se denominan flujo de salida.
FLUJO DE TRANSACCION
El flujo de transacción se caracteriza por datos que se mueven a lo largo de un camino de entrada que convierte la información del mundo exterior en una transacción. La transacción se evalúa y, basándose en ese valor, se inicia el flujo a lo largo de uno de muchos caminos de acción. El centro de flujo de información del que parten muchos de los caminos de acción se denomina centro de transacción.
ANALISIS DE TRANSFORMACIONES
El análisis de las transformaciones es un conjunto de pasos de diseño que permite convertir un DFD, con características de flujo de transformación, en un estilo arquitectónico especifico.
A continuación se presentara un ejemplo de un sistema de seguridad “Hohar Seguro?”, el cual es representativo de muchos productos y sistemas basados en computadora, este sistema interactúa con el usuario a través de una serie de entradas por teclado y visualizaciones alfanuméricas. En la siguiente figura se aprecia el nivel 0 del DFD de Hogar Seguro?.
PASOS DEL DISEÑO DE TRANSFORMACION
Basándonos en el ejemplo anterior se ilustrara cada paso en el análisis de las transformaciones. Los pasos empiezan con una reevaluación del trabajo hecho durante el análisis de requisitos y después evoluciona hacia el diseño de la arquitectura del software.
Paso 1. Revisar el modelo fundamental del sistema. El modelo fundamental del sistema comprende el DFD de nivel 0 y la información que lo soporta.
Paso 2. Revisar y refinar los diagramas de flujo de datos del software. La información obtenida de los modelos de análisis contenidos en la Especificación de Requisitos del Software se refina para obtener mayor detalle.
Paso 3. Determinar si el diagrama de flujo tiene características de flujo de transformación o de transición. En este paso, el diseñador selecciona la característica general del flujo (de la amplitud del software) basándose en la propia naturaleza del DFD. Además, se aíslan regiones locales de flujo de transformación o de transacción. Estos subflujos pueden usarse para refinar la estructura del programa obtenida por la característica general que prevalece.
Paso 4. Aislar el centro de transformación especificado los límites de los flujos de entrada y salida. Los diseñadores pueden elegir puntos ligeramente diferentes como límites de flujo.
Paso 5. Realizar una descomposición de primer nivel. La descomposición en partes provoca una estructura de programa en la que los módulos del nivel superior realizan la toma de decisiones y los módulos del nivel inferior realizan la mayoría de trabajo de entrada, cálculos y salida y los módulos de nivel intermedio realizan algún control y cantidades moderadas de trabajo
Paso 6. Realizar descomposición de segundo nivel. La descomposición de segundo nivel se realiza mediante la conversión de las transformaciones individuales de un DFD en los módulos correspondientes dentro de la arquitectura. El siguiente diagrama nos ilustra la descomposición del flujo de datos del segundo nivel.
Ejemplo de un controlador principal denominado Gestor de monitorización de sensores que sirve para coordinar una serie de funciones de control subordinadas.
Paso 7. Refinar la estructura inicial de la arquitectura usando heurística para mejorar la calidad. Una primera e3structura de arquitectura siempre puede refinarse aplicando los conceptos de independencia de módulos. Los módulos se incrementan o reducen para producir una descomposición razonable, buena cohesión, acoplamiento mínimo y lo más importante, una estructura que se pueda implementar sin dificultad, probarse sin confusión y mantenerse sin problemas
El objetivo de los siete puntos anteriores es desarrollar una representación general de software. Es decir, una vez que se ha definido la estructura, podemos evaluar y refinar la arquitectura del software viéndola en su conjunto. REFINAMIENTO DEL DISEÑO ARQUITECTONICO
Después de haber desarrollado y refinado la estructura, se deben completar las siguientes tareas:
• Se debe desarrollar una descripción del procesamiento para cada módulo.
• Se aporta una descripción de la interfaz para cada módulo.
• Se definen las estructuras de datos generales y locales.
• Se anotan todas las limitaciones/restricciones del diseño.
• Se lleva a cabo una revisión del diseño.
• Se considera un refinamiento (si es necesario y está justificado).
El diseño 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 diseño. Es importante anotar que la simplicidad estructural es a menudo, reflejo de elegancia y eficiencia. El refinamiento del diseño debería luchar por obtener un pequeño número de módulos consecuentes a la modularidad operativa y la estructura de datos menos compleja que sirva adecuadamente a los requisitos de información.
