Habilidades avanzadas en diseño de arquitectura de sistemas · Teoría y práctica del diseño de arquitectura jerárquica

现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.

Haga clic para ingresar al directorio de series de artículos.

1. Descripción general de la arquitectura jerárquica

1.1 Definición

La arquitectura de software se puede definir como: La arquitectura de software proporciona una abstracción de alto nivel de la estructura, el comportamiento y las propiedades de un sistema de software y consiste en una descripción de los elementos que componen el sistema, las interacciones de estos elementos, los patrones que guiar la integración de los elementos y las limitaciones de estos patrones. La arquitectura del software no solo especifica la estructura organizacional y la topología del sistema, sino que también muestra la correspondencia entre los requisitos del sistema y los elementos que lo componen, proporciona algunos principios básicos para las decisiones de diseño y es un complejo a nivel de sistema construido sobre el software. sistema.uso.

La arquitectura en capas es el método de diseño de arquitectura más común, que puede simplificar efectivamente el diseño, aclarar la estructura del sistema diseñado y facilitar la mejora de la reutilización y las capacidades de mantenimiento del producto. El diseño de la arquitectura jerárquica consiste en organizar el sistema en una estructura jerárquica, en la que cada capa sirve a la capa superior y actúa como un cliente de la capa inferior. En algunos sistemas jerárquicos, excepto por algunas funciones de salida cuidadosamente seleccionadas, las interfaces de las capas internas solo son visibles para las capas adyacentes. Los conectores se definen mediante protocolos que determinan cómo interactúan las capas, y las restricciones topológicas incluyen restricciones sobre las interacciones entre capas adyacentes. Dado que cada capa solo afecta a dos capas como máximo, y siempre que se proporcione la misma interfaz a las capas adyacentes, cada capa puede implementarse con diferentes métodos, lo que también proporciona un potente
soporte para la reutilización del software.

1.2 Composición de aplicaciones jerárquicas

1.3 Características y precauciones

2. Diseño del marco de la capa de presentación.

2.1 Patrón MVC (Modelo-Vista-Controlador)

MVC是一种软件设计模式。MVC把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离，形成了控制器、模型、视图3个核心模块，其中：
（1）控制器（Controller）：接受用户的输入，并调用模型和视图去完成用户的需求。
（2）模型（Model）：应用程序的主体部分，表示业务数据和业务逻辑。
（3）视图（View）：用户看到并与之交流的界面。

如图，三者协作关系：

使用MVC模式来设计表现层，可以有以下优点：
（1）允许多种用户界面的扩展。
（2）易于维护。
（3）易于构件功能强大的用户界面。
（4）增加应用的可拓展性、强壮性、灵活性。

2.2 MVP（Model-View-Presenter）模式

在MVP模式中Model提供数据，View负责显示，Controller/Presenter负责逻辑处理。MVP不仅仅避免了View和Model之间的耦合，还进一步降低了Presenter对View的依赖。

如图，MVP设计模式：

使用MVP模式来设计表现层，可以有以下的优点：
（1）模型与视图完全分离，可以修改视图而不影响模型。
（2）所有的交互都发生在一个地方 - Presenter内部，因此可以更高效地使用模型。
（3）可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。因为视图的变化总是比模型的变化频繁。
（4）如果把逻辑放在Presenter中，就可以脱离用户接口来测试这些逻辑（单元测试）。

2.3 MVVM（Model-View-ViewModel ）模式

MVVM es similar a MVC y MVP y su objetivo principal es lograr la separación de vistas y modelos. La diferencia es que en MVVM, la interacción entre Vista y Modelo se realiza a través de ViewModel, es decir, Vista y Modelo no pueden comunicarse directamente, y la comunicación entre los dos solo se puede realizar a través de ViewModel. ViewModel es el núcleo de MVVM y realiza un enlace bidireccional entre Vista y Modelo a través de DataBinding, que incluye procesamiento de estado de datos, enlace de datos y conversión de datos.
Como se muestra en la figura, patrón de diseño MVVM:

3. Diseño de marco de capa intermedia

3.1 Diseño de componentes de la capa de lógica empresarial

Los componentes de la capa de lógica empresarial se dividen en dos partes: interfaz y clase de implementación. Las interfaces se utilizan para definir los componentes de la lógica de negocios. Definir los métodos que deben implementar los componentes de la lógica de negocios es el núcleo de toda la operación del sistema. Los componentes de lógica de negocios generalmente se diseñan de acuerdo con módulos: cada módulo está diseñado con un componente de lógica de negocios y cada componente de lógica de negocios utiliza múltiples componentes de objetos de acceso a datos (DAO) como base para proporcionar los servicios de lógica de negocios del sistema al mundo exterior.

3.2 Diseño de flujo de trabajo de la capa de lógica empresarial

La Workflow Management Coalition (WFMC) define el flujo de trabajo como: la automatización total o parcial de los procesos de negocio. En este proceso, los documentos, la información o las tareas fluyen de acuerdo con ciertas reglas de proceso para lograr la coordinación entre los miembros de la organización y lograr los objetivos generales del negocio.

Como se muestra en la figura, el modelo de referencia del flujo de trabajo:

3.3 Diseño de entidades de la capa de lógica empresarial

Las entidades de capa lógica brindan acceso programático con estado a datos comerciales y funciones relacionadas (en algunos diseños). Las entidades de la capa de lógica empresarial se pueden crear utilizando datos con esquemas complejos, que a menudo provienen de varias tablas relacionadas en una base de datos. Los datos de la entidad de la capa de lógica empresarial se pueden pasar como parte de los parámetros de E/S del proceso empresarial. Las entidades de la capa de lógica empresarial son serializables para mantener su estado actual.

3.4 Marco de la capa de lógica empresarial

El marco de lógica de negocios está ubicado en la capa intermedia de la arquitectura del sistema y es el componente central para realizar las funciones del sistema. Adopta la forma de contenedor para facilitar el desarrollo, la reutilización de código y la gestión de funciones del sistema. En el contenedor empresarial, la lógica empresarial se implementa de acuerdo con la idea de control de modelo de servicio y dominio. Entre ellos:
(1) El modelo de dominio es un objeto comercial de capa de dominio que solo contiene atributos relacionados con el negocio.
(2) El servicio es una parte integral de la implementación del proceso de negocio y es una unidad funcional diferente del programa de aplicación, que está conectada a través de interfaces y contratos bien definidos entre estos servicios.
(3) El controlador del servicio de control es el vínculo entre los servicios y a través de él se logra la conmutación entre diferentes servicios.

4. Diseño del marco de la capa de acceso a datos.

4.1 Modo de acceso a datos

(1) Acceso en línea
(2) Objeto de acceso a datos
(3) Objeto de transferencia de datos
(4) Modo de datos fuera de línea
(5) Mapeo de objeto/relación

4.2 Aplicación del patrón de fábrica en la capa de acceso a datos

Esto requiere encapsular nuevamente estas clases de acceso a la base de datos durante el proceso de desarrollo real. Después de dicha encapsulación, no solo se pueden lograr los objetivos anteriores, sino que también se pueden reducir los pasos para operar la base de datos y la cantidad de escritura de código. El patrón de diseño de fábrica es el método principal utilizado.

El patrón de fábrica define una interfaz para crear objetos y permite que las subclases decidan qué clase crear una instancia. Los métodos de fábrica permiten diferir la creación de instancias de una clase a sus subclases. Aquí se pueden manejar operaciones en múltiples bases de datos, por lo que primero debe definir una interfaz para manipular la base de datos y luego la fábrica de clases decide qué clase crear una instancia en función de la base de datos.

4.3 Ideas de diseño ORM, Hibernate y CMP2.0

ORM (Object-Relation Mapping) realiza un mapeo entre una base de datos relacional y un objeto. De esta manera, al manipular específicamente la base de datos, ya no necesita lidiar con declaraciones SQL complejas, y solo necesita operar como lo hace normalmente con objetos. Al desarrollar una aplicación (sin utilizar OR Mapping), puede implicar una gran cantidad de código en la capa de acceso a datos, que se utiliza para guardar, eliminar y leer información de objetos de la base de datos, etc. Sin embargo, estos códigos siempre se repiten cuando se escriben. . Una mejor manera es introducir OR Mapping. Básicamente, un mapeo OR genera DAL. En lugar de escribir el código DAL usted mismo, es mejor utilizar OR Mapping, los desarrolladores solo deben preocuparse por los objetos.

4.4 Esquema XML

El esquema XML se utiliza para describir la estructura legal, el contenido y las restricciones de los documentos XML. XML Schema se autodescribe mediante XML 1.0 y utiliza espacios de nombres. Tiene ricos tipos de datos integrados y potentes funciones de definición de estructuras de datos, transformando completamente y ampliando en gran medida el mecanismo DTD (descripción tradicional de la estructura de documentos XML y restricciones de contenido). DTD y se convertirá en el lenguaje de tipos formal en el sistema XML. Junto con la especificación XML y la especificación del espacio de nombres, se convertirá en la base sólida del sistema XML.

4.5 Diseño de procesamiento de transacciones

La transacción es uno de los conceptos centrales de la teoría moderna de bases de datos. Si un conjunto de pasos de procesamiento ocurren todos o no se ejecuta ninguno, llamamos transacción al conjunto de pasos de procesamiento. Cuando todos los pasos se ejecutan completamente como una sola operación, decimos que la transacción está confirmada. Debido a que uno o más pasos fallan y no se confirma ningún paso, la transacción debe revertirse (volver al estado original del sistema). Las transacciones deben cumplir con los principios ACID establecidos por ISO/IEC. ACID es la abreviatura de Atomicidad, Consistencia, Aislamiento y Durabilidad. La atomicidad de una transacción significa que cualquier falla durante la ejecución de la transacción hará que cualquier modificación realizada por la transacción deje de ser válida. Coherencia significa que cuando una transacción falla, todos los datos afectados por la transacción deben restaurarse al estado anterior a la ejecución de la transacción. El aislamiento significa que las modificaciones de los datos durante la ejecución de la transacción no son visibles para otras transacciones antes de que se confirme la transacción. La persistencia significa que el estado de los datos enviados debe ser correcto cuando falla la ejecución de la transacción.

4.6 Diseño de gestión de objetos de conexión

Para los recursos compartidos, existe un patrón de diseño muy famoso: el grupo de recursos. Este modelo está diseñado para resolver los problemas causados ​​por la asignación y liberación frecuente de recursos. Aplicar este modelo al campo de la gestión de conexiones de bases de datos consiste en establecer un grupo de conexiones de bases de datos y proporcionar un conjunto de estrategias de uso y asignación de conexiones eficientes. El primer paso para establecer un grupo de conexiones es establecer un grupo de conexiones estáticas. El llamado estático significa que las conexiones en el grupo se asignan durante la inicialización del sistema y no se pueden cerrar a voluntad. Con este grupo de conexiones, a continuación se puede proporcionar un conjunto de estrategias personalizadas de asignación y liberación. Cuando un cliente solicita una conexión a una base de datos, primero verifica si hay conexiones no asignadas en el grupo de conexiones. Si hay una conexión inactiva, la conexión se asigna al cliente y se procesa en consecuencia.

5. Planificación y diseño de la arquitectura de datos.

5.1 Integración de base de datos y diseño de clases.

La correcta identificación de clases y relaciones entre clases es la clave de los modelos de datos. Esta sección analiza cómo descubrir, identificar y describir clases. Es imposible reducir el proceso de modelado a un proceso simple, paso a paso. En esencia, el modelaje es un arte. No existe un único modelo de datos correcto para una situación compleja determinada, pero existen buenos modelos de datos. Un modelo de datos para una empresa o institución puede ser mejor que otro, pero no existe una solución única sobre cómo modelar un modelo de datos para un sistema en particular.

El objetivo de un buen modelo es minimizar el coste a lo largo de toda la vida del proyecto, teniendo en cuenta también los posibles cambios en el sistema a lo largo del tiempo, por lo que el diseño también debe considerar adaptarse a estos cambios. Por tanto, es un error centrarse en minimizar los gastos de desarrollo.

5.2 Integración del diseño de bases de datos y diseño XML.

Los documentos XML se dividen en dos categorías: una son los documentos centrados en datos, que tienen una estructura regular, un contenido isomórfico, menos contenido mixto y niveles anidados, y a las personas solo les importa el documento. Los datos del documento no se preocupan por el Orden de almacenamiento de los elementos de datos. Este tipo de documento, abreviado como documento de datos, se utiliza a menudo para almacenar y transmitir datos web. El otro tipo son los documentos centrados en documentos. Este tipo de documento tiene una estructura irregular, contenido disperso, contenido más mixto y el orden entre los elementos está relacionado. Este tipo de documento se utiliza a menudo para publicar descripciones en páginas web. Información sexual, Introducción al rendimiento del producto e información por correo electrónico, etc.

Hay dos formas de almacenar documentos XML: almacenamiento basado en archivos y almacenamiento en bases de datos.

6. Diseño de arquitectura jerárquica del Internet de las cosas.

• (1) Capa de percepción:
  la capa de percepción se utiliza para identificar objetos y recopilar información. La capa de percepción incluye etiquetas y lectores de códigos QR, etiquetas y lectores RFID, cámaras, GPS, sensores, terminales M2M, puertas de enlace de sensores, etc. Su función principal es identificar objetos, recopilar información y el papel de la piel y los rasgos faciales en la estructura del cuerpo humano similar.

• (2) Capa de red:
  la capa de red se utiliza para transmitir información y procesar información. La capa de red incluye la red integrada de red de comunicación e Internet, centro de gestión de red, centro de información y centro de procesamiento inteligente. La capa de red transmite y procesa la información obtenida por la capa de percepción, similar a la estructura del centro nervioso y el cerebro en el cuerpo humano.

• (3) Capa de aplicación:
  la capa de aplicación implementa una inteligencia extensa. La capa de aplicación es la integración profunda de Internet de las cosas y la experiencia de la industria, y combina las necesidades de la industria para lograr inteligencia industrial, que es similar a la división social del trabajo de las personas.

Haga clic para ingresar al directorio de series de artículos.