Modelos de arquitectura
La arquitectura de software implica la estructura de alto nivel de abstracción del sistema de software, mediante el uso de descomposición y composición, con estilo arquitectónico y atributos de calidad. Un diseño de arquitectura de software debe cumplir con los principales requisitos de funcionalidad y rendimiento del sistema, así como satisfacer los requisitos no funcionales, como confiabilidad, escalabilidad, portabilidad y disponibilidad.
Una arquitectura de software debe describir su grupo de componentes, sus conexiones, las interacciones entre ellos y la configuración de implementación de todos los componentes.
Una arquitectura de software se puede definir de muchas formas:
UML (Unified Modeling Language) - UML es una de las soluciones orientadas a objetos que se utilizan en el modelado y diseño de software.
Architecture View Model (4+1 view model) - El modelo de vista de arquitectura representa los requisitos funcionales y no funcionales de la aplicación de software.
ADL (Architecture Description Language) - ADL define la arquitectura del software de manera formal y semántica.
UML
UML son las siglas de Unified Modeling Language. Es un lenguaje pictórico utilizado para hacer planos de software. UML fue creado por Object Management Group (OMG). El borrador de la especificación UML 1.0 fue propuesto al OMG en enero de 1997. Sirve como estándar para el análisis de requisitos de software y documentos de diseño que son la base para desarrollar un software.
UML se puede describir como un lenguaje de modelado visual de propósito general para visualizar, especificar, construir y documentar un sistema de software. Aunque UML se usa generalmente para modelar el sistema de software, no está limitado dentro de este límite. También se utiliza para modelar sistemas que no son de software, como los flujos de procesos en una unidad de fabricación.
Los elementos son como componentes que pueden asociarse de diferentes formas para hacer una imagen UML completa, que se conoce como diagram. Por lo tanto, es muy importante comprender los diferentes diagramas para implementar el conocimiento en sistemas de la vida real. Tenemos dos categorías amplias de diagramas y se dividen en subcategorías, es decirStructural Diagrams y Behavioral Diagrams.
Diagramas estructurales
Los diagramas estructurales representan los aspectos estáticos de un sistema. Estos aspectos estáticos representan las partes de un diagrama que forman la estructura principal y, por tanto, es estable.
Estas partes estáticas están representadas por clases, interfaces, objetos, componentes y nodos. Los diagramas estructurales se pueden subdividir de la siguiente manera:
- Diagrama de clase
- Diagrama de objetos
- Diagrama de componentes
- Diagrama de implementación
- Diagrama del paquete
- Estructura compuesta
La siguiente tabla proporciona una breve descripción de estos diagramas:
| No Señor. | Diagrama y descripción |
|---|---|
| 1 | Class Representa la orientación a objetos de un sistema. Muestra cómo las clases están relacionadas estáticamente. |
| 2 | Object Representa un conjunto de objetos y sus relaciones en tiempo de ejecución y también representa la vista estática del sistema. |
| 3 | Component Describe todos los componentes, su interrelación, interacciones e interfaz del sistema. |
| 4 | Composite structure Describe la estructura interna del componente, incluidas todas las clases, interfaces del componente, etc. |
| 5 | Package Describe la estructura y organización del paquete. Cubre clases en el paquete y paquetes dentro de otro paquete. |
| 6 | Deployment Los diagramas de implementación son un conjunto de nodos y sus relaciones. Estos nodos son entidades físicas donde se implementan los componentes. |
Diagramas de comportamiento
Los diagramas de comportamiento capturan básicamente el aspecto dinámico de un sistema. Los aspectos dinámicos son básicamente las partes cambiantes / móviles de un sistema. UML tiene los siguientes tipos de diagramas de comportamiento:
- Use el diagrama del caso
- Diagrama de secuencia
- Diagrama de comunicación
- Diagrama de gráfico de estado
- Diagrama de actividad
- Descripción general de la interacción
- Diagrama de secuencia de tiempo
La siguiente tabla proporciona una breve descripción de estos diagramas:
| No Señor. | Diagrama y descripción |
|---|---|
| 1 | Use case Describe las relaciones entre las funcionalidades y sus controladores internos / externos. Estos controladores se conocen como actores. |
| 2 | Activity Describe el flujo de control en un sistema. Consta de actividades y enlaces. El flujo puede ser secuencial, concurrente o ramificado. |
| 3 | State Machine/state chart Representa el cambio de estado de un sistema impulsado por eventos. Básicamente describe el cambio de estado de una clase, interfaz, etc. Se utiliza para visualizar la reacción de un sistema por factores internos / externos. |
| 4 | Sequence Visualiza la secuencia de llamadas en un sistema para realizar una funcionalidad específica. |
| 5 | Interaction Overview Combina diagramas de actividad y secuencia para proporcionar una descripción general del flujo de control del sistema y el proceso empresarial. |
| 6 | Communication Igual que el diagrama de secuencia, excepto que se centra en la función del objeto. Cada comunicación está asociada con un orden de secuencia, número más los mensajes pasados. |
| 7 | Time Sequenced Describe los cambios por mensajes en estado, condición y eventos. |
Modelo de vista de arquitectura
Un modelo es una descripción completa, básica y simplificada de la arquitectura de software que se compone de múltiples vistas desde una perspectiva o punto de vista particular.
Una vista es una representación de un sistema completo desde la perspectiva de un conjunto relacionado de preocupaciones. Se utiliza para describir el sistema desde el punto de vista de diferentes partes interesadas, como usuarios finales, desarrolladores, directores de proyectos y probadores.
Modelo de vista 4 + 1
El modelo de vista 4 + 1 fue diseñado por Philippe Kruchten para describir la arquitectura de un sistema intensivo en software basado en el uso de vistas múltiples y concurrentes. Es unmultiple viewmodelo que aborda diferentes características y preocupaciones del sistema. Estandariza los documentos de diseño del software y hace que el diseño sea fácil de entender por todas las partes interesadas.
Es un método de verificación de la arquitectura para estudiar y documentar el diseño de la arquitectura del software y cubre todos los aspectos de la arquitectura del software para todas las partes interesadas. Proporciona cuatro vistas esenciales:
The logical view or conceptual view - Describe el modelo de objetos del diseño.
The process view - Describe las actividades del sistema, captura los aspectos de concurrencia y sincronización del diseño.
The physical view - Describe el mapeo de software en hardware y refleja su aspecto distribuido.
The development view - Describe la organización o estructura estática del software en su entorno de desarrollo.
Este modelo de vista se puede ampliar agregando una vista más llamada scenario view o use case viewpara usuarios finales o clientes de sistemas de software. Es coherente con otras cuatro vistas y se utiliza para ilustrar la arquitectura que sirve como vista “más uno”, modelo de vista (4 + 1). La siguiente figura describe la arquitectura del software mediante el modelo de cinco vistas simultáneas (4 + 1).
¿Por qué se llama 4 + 1 en lugar de 5?
los use case viewtiene un significado especial, ya que detalla los requisitos de alto nivel de un sistema, mientras que otros visualizan detalles: cómo se cumplen esos requisitos. Cuando se completan las otras cuatro vistas, es efectivamente redundante. Sin embargo, todas las demás vistas no serían posibles sin él. La siguiente imagen y tabla muestra la vista 4 + 1 en detalle:
| Lógico | Proceso | Desarrollo | Físico | Guión | |
|---|---|---|---|---|---|
| Descripción | Muestra el componente (objeto) del sistema, así como su interacción. | Muestra los procesos / reglas de flujo de trabajo del sistema y cómo se comunican esos procesos, se centra en la vista dinámica del sistema | Proporciona vistas de bloques de construcción del sistema y describe la organización estática de los módulos del sistema. | Muestra la instalación, configuración e implementación de la aplicación de software. | Muestra que el diseño está completo al realizar la validación y la ilustración. |
| Visor / titular de estaca | Usuario final, analistas y diseñador | Integradores y desarrolladores | Programadores y gerentes de proyectos de software | Ingeniero de sistemas, operadores, administradores de sistemas e instaladores de sistemas | Todas las opiniones de sus puntos de vista y evaluadores. |
| Considerar | Requerimientos funcionales | Requerimientos no funcionales | Organización del módulo de software (reutilización de la gestión de software, limitación de herramientas) | Requisito no funcional con respecto al hardware subyacente | Consistencia y validez del sistema |
| UML - Diagrama | Clase, Estado, Objeto, secuencia, Diagrama de comunicación | Diagrama de actividad | Componente, diagrama de paquete | Diagrama de implementación | Use el diagrama del caso |
Lenguajes de descripción de arquitectura (ADL)
Una ADL es un lenguaje que proporciona sintaxis y semántica para definir una arquitectura de software. Es una especificación de notación que proporciona características para modelar la arquitectura conceptual de un sistema de software, que se distingue de la implementación del sistema.
Las ADL deben admitir los componentes de la arquitectura, sus conexiones, interfaces y configuraciones, que son el componente básico de la descripción de la arquitectura. Es una forma de expresión para usar en descripciones de arquitectura y proporciona la capacidad de descomponer componentes, combinar los componentes y definir las interfaces de los componentes.
Un lenguaje de descripción de arquitectura es un lenguaje de especificación formal, que describe las características del software como procesos, subprocesos, datos y subprogramas, así como componentes de hardware como procesadores, dispositivos, buses y memoria.
Es difícil clasificar o diferenciar una ADL y un lenguaje de programación o un lenguaje de modelado. Sin embargo, existen los siguientes requisitos para que un idioma se clasifique como ADL:
Debe ser apropiado para comunicar la arquitectura a todas las partes interesadas.
Debe ser adecuado para tareas de creación, perfeccionamiento y validación de arquitectura.
Debe proporcionar una base para una mayor implementación, por lo que debe poder agregar información a la especificación ADL para permitir que la especificación final del sistema se derive de la ADL.
Debe tener la capacidad de representar la mayoría de los estilos arquitectónicos comunes.
Debe admitir capacidades analíticas o proporcionar implementaciones de prototipos de generación rápida.