¿QUÉ ES ARQUITECTURA?
Bass, Clements y Kazman definen este término como “la estructura o estructuras del sistema, que comprende a los componentes del software, sus propiedades externas visibles y las relaciones entre ellos”.
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.
Hay una diferencia entre los términos arquitectura y diseño. Un diseño es una instancia de una arquitectura, similar a un objeto que es una instancia de una clase. Por ejemplo, considere la arquitectura cliente/servidor. Con esta arquitectura es posible diseñar de muchos modos un sistema de software basado en red, con el uso de una plataforma java (Java EE) o Microsoft (estructura .NET). Entonces hay una arquitectura, pero con base en ella pueden crearse muchos diseños. Por lo tanto no es válido mezclar los términos diseño y arquitectura.
4.1.- ¿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.
En un sentido amplio podríamos estar de acuerdo en que la Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema, programa o aplicación y tiene la responsabilidad de:
- Definir los módulos principales
- Definir las responsabilidades que tendrá cada uno de estos módulos
- Definir la interacción que existirá entre dichos módulos:
- Control y flujo de datos
- Secuenciación de la información
- Protocolos de interacción y comunicación
- Ubicación en el hardware
4.2.- FLUJO DE TRANSACCIÓN:
El flujo de transacción se caracteriza por el movimiento de datos a través de un camino de llegada que convierte la información del mundo exterior en una transacción. Se evalúa la transacción y de acuerdo con su valor, el flujo sigue por uno de los muchos caminos de acción.
El centro del flujo de información desde el que emanan los caminos de acción se denomina Centro de Transacción. Dentro de un flujo de transacción, el flujo de información a través de un camino de acción puede tener características de flujo de transformación
4.2.1.- FLUJO DE TRANSFORMACIÓN:
En un sistema, la información entra y sale en una forma del mundo exterior (entradas de teclado, tonos telefónicos, imágenes de visualización,...). Esos datos externos, deben ser convertidos auna forma adecuada para el procesamiento.
La información entra al sistema mediante caminos que transforman los datos externos a una forma interna y se identifica como Flujo Entrante.
En el interior del software se produce una transición, los datos entrantes pasan a través de un centro de transformación, moviéndose ahora hacia la salida del software. Estos datos forman el Flujo Saliente.
El flujo de datos global ocurre de forma secuencial y sigue uno o pocos caminos directos. Cuando una parte del DFD tiene estas características decimos que es un Flujo de Transformación.
El Análisis de Transformación es una estrategia, no un algoritmo. Si se siguen los pasos de un algoritmo los resultados están asegurados y son correctos, una estrategia consigue resultados buenos, pero no perfectos en una primera aproximación.
El análisis de transformación es un conjunto de pasos que permiten obtener, a partir de un DFD con características de transformación, la estructura del sistema.
El DFD con características de transformación es aquél en el que se pueden distinguir tres zonas:
- Flujo de llegada o entrada.
- Flujo de transformación o centro de transformación.
- Flujo de salida.
4.2.3.- PASOS DEL ANALISIS DE TRANSFORMACION
- Aislar el centro de transformación.
- Realizar el primer nivel de factorización del Diagrama de Estructura de Cuadros.
- Elaborar el segundo nivel de factorización
- Refinar la estructura del sistema utilizando medidas y guías de diseño.
4.3.- PASOS DEL DISEÑO DE TRANSFORMACIÓN:
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. La transición del DFD a una estructura de programa se hace en 7 pasos:
- Revisar el modelo fundamental del sistema: revisar el DFD nivel 0 y la información complementaria.
- Revisar y refinar los DFD del software: se examinan los DFD nivel 1, 2 y 3 hasta el nivel enque cada transformación tiene una cohesión alta (es decir, cada transformación ejecuta una función sencilla y diferenciada) pudiéndose implementar como un módulo. En este paso se llega al nivel que contiene suficiente detalle como para establecer un diseño inicial para la estructura del programa.
- Determinar si el DFD tiene características de transformación o de transacción: en general, el flujo de información de un sistema podrá representarse siempre como una transformación. Si tiene una característica obvia de transacción es conveniente tratarla como tal. El diseñador selecciona la característica general del flujo basándose en la naturaleza prevaleciente del DFD. Se aíslan las regiones locales de flujo de transformación o de transacción, lo que nos permitirá refinar la estructura del programa posteriormente.
- Aislar el centro de transformación especificando los límites de los flujos entrante y saliente: La interpretación de los límites es algo subjetivo dependiente del diseñador, así es posible obtener distintas soluciones alternativas variando los límites del flujo. El diseñador debe establecer unos límites razonables.
5. Realizar una descomposición de primer nivel: la estructura del programa representa una distribución descendente del control. La descomposición da como resultado una estructura de programa en la que los módulos de nivel superior toman las decisiones de ejecución y los módulos de nivel inferior ejecutan la mayoría del trabajo de entrada, de procesamiento y de salida. Los módulos de nivel intermedio ejecutan algún control y realizan moderadas cantidades de trabajo.
En la parte superior de la estructura del programa se encuentra un módulo de control, que sirve para coordinar las funciones de control subordinadas, que son:
- Controlador del procesamiento de la información entrante, que coordina la recepción de todos los datos que llegan.
- Controlador del centro de transformación, que supervisa todas las operaciones sobre los datos en su forma interna.
- Controlador del procesamiento de la información saliente, que coordina la producción de la información que sale.
Cada módulo de control tiene un nombre que indica la función de los módulos subordinados que controla.
6. Realizar descomposición de segundo nivel: se realiza mediante la conversión de las transformaciones individuales (burbujas) de un DFD, en los módulos correspondientes a la estructura del programa. Comenzando dentro de los límites del centro de transformación y moviéndose hacia fuera a través de los caminos de entrada y luego de salida, las transformaciones se convierten en niveles subordinados de la estructura de control.
Así obtenemos una estructura de programa inicial, también llamada Diagrama de Estructura.
Aunque hemos hecho una correspondencia uno a uno entre las burbujas del DFD y los módulos del software, también se pueden combinar 2 ó 3 burbujas, representándolas como un solo módulo, o también puede dividirse una burbuja en dos o más módulos.
Aunque los módulos que forman la estructura de programa tienen un nombre que indica la función que realiza, se debe escribir para cada uno de ellos un breve texto que explique su procesamiento.
La información que contendrá es:
- La información que entra y la que sale del módulo.
- La información que es retenida en el módulo (ejemplo: en almacenamientos de datos).
- Explicación del procedimiento, indicando los principales puntos de decisión y las tareas.
- Tratamiento de las restricciones y características especiales, si las hay.
7. Refinar la estructura inicial del programa usando heurísticas para mejorar la calidad del software. La estructura inicial del programa siempre puede refinarse aplicando los fundamentos de diseño, por ello, se puede aumentar o reducir el número de módulos para obtener una descomposición con una buena cohesión, un mínimo acoplamiento, una estructura de fácil implementación, prueba y mantenimiento.
Los refinamientos se rigen por consideraciones prácticas y de sentido común.
Hay ocasiones en las que el controlador de flujo de datos entrante/saliente es innecesario, o se requiere un procesamiento de la entrada en un módulo subordinado al controlador de transformaciones, o no se puede conseguir un bajo acoplamiento por la necesidad de trabajar con datos globales.
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.
4.4.- ANALISIS DE TRANSACCION
El análisis de transacción se aplica cuando un DFD toma una forma, en la que un dato determina la elección de uno o más flujos de información.
La transacción es evaluada y, basándose en su valor, el flujo se inicia por uno de los muchos caminos de acción.
El centro de flujo de información desde el que emanan varios caminos de acción se llama centro de transacción.
4.4.1.- PASOS DEL ANÁLISIS DE TRANSACCIÓN:
Pasos a seguir:
- Revisar el modelo fundamental del sistema.
- Revisar y refinar los DFD.
- Determinar si el DFD tiene características de transformación o de transacción.
- Identificar el centro de transacción y las características del flujo de cada camino de acción.
- El centro de acción se localiza fácilmente en el DFD, es el origen de varios caminos de información que fluyen radialmente de él. También deben aislarse el camino entrante y todos los caminos de acción.
- Transformar el DFD en una estructura de software adecuada al procesamiento de transacciones.
El flujo de transacción se convierte en una estructura de programa que contiene una rama entrante y una rama de distribución.
- La rama entrante se obtiene igual que el análisis de transformación, desde el centro de transacción hacia fuera, se convierten las burbujas en módulos.
- La rama de distribución tiene un módulo distribuidor que controla todos los módulos de acción subordinados.
El flujo de cada camino de acción del DFD se convertirá en una estructura que se corresponda
con las características del flujo (de transformación o de transacción).
- Descomponer y refinar la estructura de transacción y la estructura de cada camino de acción. Cada camino de acción del DFD tiene sus propias características de flujo de información no de transacción. La subestructura de cada camino de acción se obtiene siguiendo los pasos del análisis correspondiente.
- Refinar la estructura inicial del software usando heurísticas de diseño para mejorar la calidad. Igual al anterior.
Shaw y Garlan [1994] describen un conjunto de propiedades que deben especificarse como parte del diseño de la arquitectura:
Propiedades estructurales. Este aspecto de la representación del diseño arquitectónico define los componentes de un sistema (módulos, objetos, filtros, etc.) y la manera en la que están agrupados e interactúan unos con otros. Por ejemplo, los objetos se agrupan para que encapsulen tanto datos como el procedimiento que los manipula e interactúen invocando métodos.
Propiedades extra funcionales. La descripción del diseño arquitectónico debe abordar la forma en la que la arquitectura del diseño satisface los requerimientos de desempeño, capacidad, confiabilidad, seguridad y adaptabilidad, así como otras características del sistema.
Familias de sistemas relacionados. El diseño arquitectónico debe basarse en patrones repetibles que es común encontrar en el diseño de familias de sistemas similares. En esencia, el diseño debe tener la capacidad de reutilizar bloques de construcción arquitectónica.
Dada la especificación de estas propiedades, el diseño arquitectónico se representa con el uso de uno o más de varios modelos diferentes. Los modelos estructurales representan la arquitectura como un conjunto organizado de componentes del programa. Los modelos de marco aumentan el nivel de abstracción del diseño, al tratar de identificar patrones de diseño arquitectónico repetibles que se encuentran en tipos similares de aplicaciones. Los modelos dinámicos abordan los aspectos estructurales de la arquitectura del programa e indican cómo cambia la estructura o la configuración del sistema en función de eventos externos. Los modelos del proceso se centran en el diseño del negocio o proceso técnico al que debe dar acomodo el sistema. Por último, los modelos funcionales se usan para representar la jerarquía funcional de un sistema.
VIDEO COMPLEMENTARIO:
No hay comentarios:
Publicar un comentario