El diseño de la arquitectura del software, es el enlace crítico entre los requerimientos y el diseño. Este se preocupa de cómo un sistema de software debería ser organizado y diseñado en su estructura general; identifica los componentes estructurales principales en un sistema y los relaciona entre ellos. La salida del proceso de diseño de la arquitectura es un modelo arquitectónico que describe cómo el sistema es organizado como un conjunto de componentes comunicados.
La arquitectura del software es importante porque este afecta el performance, robustez, distributividad y mantenibilidad de un sistema. Los componentes individuales implementan los requerimientos funcionales y los requerimientos no funcionales tiene el efecto más significativo en la arquitectura del sistema.
Las arquitecturas de sistema son a veces modeladas informalmente usando simples diagramas de bloques. Cada caja en el diagrama representa un componente. Las cajas con cajas indican que los componentes han sido descompuestos a subcomponentes. Las flechas significan que la información y/o señales de control son pasadas desde componente a componente en la dirección de las flechas.
El diseño de la arquitectura es considerado a partir de una serie de decisiones que se muestran en la figura 1.0; aunque cada sistema de software es único, los sistemas en el mismo dominio de la aplicación a veces tienen arquitecturas similares que reflejan los conceptos fundamentales del dominio.
Figura 1.0: decisiones para el diseño de la arquitectura
La arquitectura de un sistema de software quizá esté basado en un patrón de arquitectura, este es una descripción de la organización del sistema. Estos patrones captan la esencia de una arquitectura que ha sido usada en diferentes sistemas de software. Cuando se toman las decisiones para el diseño de la arquitectura, se debe tener conocimiento de los patrones comunes, así como sus fortalezas y debilidades de estos.
Para descomponer las unidades del sistema estructural, se decide una estrategia para descomponer los componentes en subcomponentes. Finalmente en el proceso de modelado de control, se desarrolla un modelo general de las relaciones de control, relacionadas entre las diferentes partes del sistema y hacer las decisiones sobre cómo la ejecución de los componentes es controlada.
Debido a la relación cercana entre características no-funcionales y la arquitectura del sistema; el patrón de diseño y la arquitectura deberían depender de los requerimientos no- funcionales del sistema:
- Rendimiento (performance): Si el rendimiento es un requerimiento crítico, la arquitectura debería ser diseñada para localizar las operaciones críticas con un número pequeño de componentes, con los componentes desarrollados en la misma computadora más que distribuido en la red.
- Seguridad (security): Si la seguridad es un requerimiento crítico, una estructura en capas para la arquitectura debería ser usado donde los activos (assets) más críticos van en las capas internas protegidos por las capas de alto nivel.
- Disponibilidad (availability): Si la disponibilidad es un requerimiento crítico, la arquitectura debería ser diseñada para incluir componentes redundantes así que es posible reemplazar y actualizar componentes sin parar el sistema.
- Mantenibilidad (maintainability): si la mantenibilidad es un requerimiento crítico, la arquitectura del sistema debería ser diseñado usando grano-fino (fine-grain), usando componentes autocontenidos que quizá sea fácilmente cambiados.
Evaluar un diseño de la arquitectura es difícil porque la verdadera prueba de una arquitectura es, qué tan bien el sistema conoce sus requerimientos funcionales y no-funcionales cuando está en uso. Sin embargo, se puede hacer una evaluación comparando el diseño contra arquitecturas referenciadas o patrones de arquitectura genéricos.
Usualmente se necesita representar múltiples vistas de la arquitectura del software en un diagrama (modelo) para representar toda la información relevante sobre la arquitectura del software del sistema. Krutchen (1995) sugiere que debería haber cuatro vistas fundamentales de la arquitectura del software.
- Vista lógica: Muestra las abstracciones clave en el sistema como objetos o clases de objetos.
- Vista de proceso: Muestra cómo (en tiempo de ejecución) el sistema es compuesto de procesos interactuando.
- Vista de desarrollo: Muestra cómo, en tiempo de ejecución, el sistema está compuesto; se muestra el desglose del software en componentes que son implementados por un único desarrollador o equipo de desarrollo.
- Vista física: Muestra el hardware del sistema y cómo los componentes del software son distribuidos a través de los procesadores delen el sistema.
Durante la práctica, las vistas conceptuales de una arquitectura del sistema son casi siempre desarrolladas durante la fase de diseño. Estas son usadas para explicar la arquitectura del sistema a los interesados. Durante la fase de diseño, algunas otras vistas quizás también sean desarrolladas cuando diferentes aspectos del sistema son discutidas, pero es raramente necesario desarrollar una descripción de todas las perspectivas.
Sommerville (2016) menciona que los usuarios de métodologías ágiles afirman que la documentación detallada del diseño no se utiliza en su mayoría. Por lo tanto, es una pérdida de tiempo y dinero desarrollar estos documentos; entonces se debe desarrollar las vistas que son útiles para la comunicación y no se debe preocupar sobre si está o no la documentación completa.
Un patrón de arquitectura describe una organización del sistema que ha sido exitoso en sistemas previos. Este incluye información sobre cuándo es y cuando no es adecuado usarlo, y detalles en las fortalezas y debilidades del patrón arquitectónico.
Las descripciones de los patrones de arquitectura incluyen el nombre del patrón, una descripción breve, un modelo gráfico y un ejemplo del tipo de sistema donde el patrón es usado. Además se debería incluir información sobre cuando el patrón debería ser usado y sus ventajas y desventajas.
Bibliografía
Sommerville, Ian, Software Engineering, (10th edition). Addison Wesley, 2016.
Comentarios
Publicar un comentario