Resumen: Para separar las preocupaciones centrales y las preocupaciones transversales en el sistema de software, se diseña un modelo de desarrollo de software orientado a aspectos introduciendo la idea de Se analiza en detalle el desarrollo de software orientado a aspectos del modelo de arquitectura de software y los tres componentes básicos del modelo, a saber, componentes, conectores y componentes de aspectos. Finalmente, el ejemplo del pago en línea demuestra que el modelo tiene cierta importancia teórica y valor práctico.
Palabras clave: arquitectura de software orientada a aspectos; problemas cruzados; conectores; componentes de aspectos
La crisis del software en la década de 1960 hizo que la gente prestara atención a la investigación de la ingeniería de software. Inicialmente, la gente se centraba en la selección de estructuras de datos y algoritmos en el diseño de software. Sin embargo, a medida que la escala de los sistemas de software continúa expandiéndose, el diseño y la especificación de la estructura general del sistema se han vuelto extremadamente importantes. A medida que se intensifica la crisis del software, surge el concepto de arquitectura de software. La arquitectura de software se centra en la forma organizativa general del sistema de software, capta las conexiones internas entre varias partes del sistema en un nivel superior y cambia el enfoque del desarrollo de software de cientos de códigos a elementos arquitectónicos más detallados y sus interacciones en el mismo. diseño. En comparación con la tecnología de software tradicional, la teoría de la arquitectura del software no solo ayuda a resolver el problema de la creciente escala y complejidad de los sistemas de software, sino que también ayuda a reutilizar componentes y mejorar la productividad del software. El desarrollo de software orientado a aspectos (AOSD) cree que un sistema está entrelazado orgánicamente con preocupaciones centrales y transversales. Las preocupaciones centrales son las principales funciones y objetivos que debe lograr el software, y las preocupaciones transversales son aquellas que tienen un efecto transversal con las preocupaciones centrales, como los registros del sistema, el procesamiento de transacciones y la verificación de permisos. AOSD facilita el diseño y mantenimiento de sistemas al separar las preocupaciones transversales y las preocupaciones centrales del sistema.
En 2002, Navasa et al. [1] de la Universidad de Extremadura propusieron introducir en el diseño de arquitectura de software una tecnología de desarrollo de software orientada a aspectos, denominada AO-SA, que puede combinar las dos. ventajas de otros aspectos, pero no proporciona un método detallado para construir una arquitectura de software orientada a aspectos.
Aunque el concepto de arquitectura de software orientada a aspectos aún no ha formado una comprensión unificada, generalmente se cree que los componentes de aspectos se agregan a la arquitectura de software tradicional para encapsular las preocupaciones transversales del sistema. En la actualidad, hay relativamente poca investigación sobre modelos de arquitectura de software orientados a aspectos en el país y en el extranjero, y aún menos investigación sobre sus modelos de unidades componentes, que generalmente solo se centran en las unidades componentes de los componentes de aspectos. Los componentes de aspecto fueron propuestos por primera vez por Lieberherr et al. Se basa en el componente adaptable Plug and Play (APPC) y se forma mediante la introducción de AOP para ampliar la interfaz modificable. Sin embargo, su definición de interfaz de solicitud e interfaz de servicio es relativamente vaga y no puede proporcionar un modelo de componente de aspecto claro. Pawlak et al. [3] propusieron un marco orientado a aspectos, que incluye principalmente un modelo de componentes de aspectos: Java Aspect Component (JAC), pero este modelo de componentes de aspectos solo incluye puntos de entrada e integra sugerencias en AOP en la expresión de puntos de entrada. , se elabora principalmente desde la perspectiva de la implementación y no se proporciona ningún modelo de componente de aspecto detallado. Este artículo no solo se centra en el modelo de componentes de la arquitectura de software orientada a aspectos, sino que también analiza en detalle sus otros dos componentes, componentes y conectores, ya que todas las partes de la arquitectura de software orientada a aspectos están interrelacionadas.
1 Conceptos relacionados de la arquitectura de software orientada a aspectos
La arquitectura de software orientada a aspectos implica muchos conceptos, que se presentarán por separado a continuación. La arquitectura de software tiene una gran influencia en el campo de la ingeniería de software, pero aún no se ha formado una definición unificada y estándar. En la actualidad, se cree generalmente, tanto en el país como en el extranjero, que la arquitectura de software incluye componentes, conectores y restricciones [4]. Las restricciones describen los requisitos para la configuración y la topología de la arquitectura y determinan las conexiones entre los componentes y conectores de la arquitectura. Por lo tanto, la arquitectura del software se puede escribir como
Arquitectura de software)=componente)+
Conector)+restricciones
El componente es uno de los elementos básicos del software. arquitectura. En términos generales, un componente se refiere a una unidad de software que tiene ciertas funciones, puede identificarse claramente, tiene una semántica completa, una sintaxis correcta y un valor reutilizable. Sin embargo, actualmente no existe un estándar unificado para la estructura y composición específicas de los componentes, y algunas tecnologías de componentes importantes no utilizan los mismos tipos de componentes. Además, las definiciones de componentes actualmente ampliamente aceptadas no contienen un modelo de componente de software específico.
Por ejemplo, Szyperski et al. [6] dieron una definición bien conocida de componentes de software: un componente de software es una unidad estructural que tiene sólo una interfaz de contrato específica y dependencias de contexto explícitas, se puede implementar de forma independiente y se integra fácilmente mediante un tercero. Sin embargo, existe una opinión generalmente aceptada sobre el modelo de componentes de software de que los componentes de software son unidades de software con funciones de prestación y solicitud de servicios [7].
Los conectores son otro componente fundamental de la arquitectura de software, son los bloques de construcción utilizados para establecer interacciones entre componentes y gestionar las reglas para estas interacciones. El conector fue propuesto por primera vez por Shaw [8], quien sugirió que se utilizara el conector como el primer tipo de entidad en la arquitectura de software para representar la interacción entre componentes públicos. Actualmente no existe una comprensión unificada de los conectores. Aunque se ha enfatizado la necesidad de los conectores en la arquitectura de software, ha habido poca investigación sobre los modelos de conectores y las aplicaciones prácticas de los conectores también están inmaduras.
La arquitectura de software orientada a aspectos añade unidades de componentes de aspectos a la arquitectura de software tradicional. En términos generales, un componente de aspecto es un tipo especial de componente que encapsula las preocupaciones transversales del sistema. En la actualidad, la investigación sobre modelos de componentes de aspectos está todavía en sus primeras etapas.
2 Modelo de arquitectura de software orientado a aspectos
Debido a que el modelo de arquitectura de software tradicional incluye componentes, conectores y restricciones, la arquitectura de software orientada a aspectos se basa en la arquitectura de software tradicional. En cuanto a los componentes de aspecto, la estructura del modelo de arquitectura de software orientada a aspectos incluye componentes, conectores, componentes de aspecto y restricciones. Entre ellas, las restricciones describen los requisitos de configuración y topología de la arquitectura orientada a aspectos y determinan las relaciones de conexión entre los componentes, conectores y componentes de aspecto de la arquitectura. Los componentes, conectores y componentes de aspecto son sus tres componentes básicos. Los modelos de estas unidades de tres componentes se diseñan en detalle a continuación.
2.1 Modelo de Componentes
El modelo de componentes consta de los siguientes elementos (Figura 1):
Puerto.
Las funciones de solicitud y prestación de servicios de los componentes se implementan a través de puertos. Un puerto es el único canal a través del cual un componente interactúa con el entorno externo. Los modelos de componentes comunes suelen emplear dos tipos de puertos, puertos bidireccionales y puertos unidireccionales. En un modelo de componentes que utiliza puertos bidireccionales, las funciones de solicitud de servicio y provisión de servicio se pueden implementar en el mismo puerto. El modelo de componentes de este artículo utiliza puertos unidireccionales, que se dividen en dos tipos: puertos de solicitud y puertos de servicio.
(a) Puerto de servicio. Los componentes proporcionan servicios a otros componentes a través de puertos de servicio. El componente responde a los mensajes de solicitud de otros componentes a través del puerto de servicio y devuelve el mensaje de respuesta. Cada puerto de servicio corresponde a una interfaz.
(b) Solicitar puerto. Un componente solicita servicios de otros componentes a través de puertos de solicitud. Para implementar sus propias funciones comerciales, los componentes deben enviar mensajes de solicitud a otros componentes a través del puerto de solicitud. Cada puerto de servicio también corresponde a una interfaz.
(b)Interfaz.
Define una o más funciones empresariales. Estas funciones comerciales las proporcionan los puertos de servicio y las utilizan los puertos de solicitud. Una interfaz define las funciones interactivas que puede realizar un puerto específico. Una interfaz es un contrato para la interacción entre componentes. Los tipos de interfaz comunes incluyen: interfaz Java, tipos de puerto WSDL1.1 e interfaz WSDL2.0, etc. También puede personalizar el tipo de interfaz.
Propiedades.
Al igual que las clases u objetos, los componentes también tienen propiedades. Las propiedades se pueden configurar antes de utilizar el componente y pueden reflejar los cambios de estado del componente durante el proceso de interacción.
2.2 Modelos de conectores
Los conectores son bloques de construcción arquitectónicos que se utilizan para establecer interacciones entre componentes y gestionar las reglas para estas interacciones. Los conectores proporcionan servicios de transporte y enrutamiento para el intercambio de información entre componentes. En el caso más simple, los componentes pueden interactuar directamente y luego los conectores de la arquitectura degeneran en conexiones directas. En casos más complejos, se requieren conectores para manejar y mantener las interacciones entre componentes. En lo que respecta a los componentes, los conectores son el pegamento de los componentes y la realización de la interacción de los mismos. También pueden considerarse componentes especiales [8]. Al igual que los componentes, los conectores también tienen puertos. Los puertos de conector se pueden dividir en dos tipos, puertos de origen y puertos de destino. El puerto de origen se utiliza para recibir mensajes desde el puerto de solicitud del componente y el puerto de destino se utiliza para ingresar mensajes al puerto de servicio del componente. Los conectores normalmente requieren el uso de mecanismos de unión adecuados. El puerto de solicitud del componente utiliza este mecanismo de enlace para describir el método de atender la solicitud, y el puerto de servicio del componente también utiliza este mecanismo para describir la forma en que el componente realiza la solicitud.
Los mecanismos de enlace comúnmente utilizados incluyen el enlace de WebService y el enlace JMS. También puede personalizar el mecanismo de encuadernación. Al igual que los componentes, los conectores también tienen propiedades para representar cambios de estado en las interacciones entre componentes, como se muestra en la Figura 2.
2.3 Modelo de componentes compuestos
Los componentes se pueden dividir en dos tipos, a saber, componentes atómicos y componentes compuestos. El primero es un componente integral. Este último es un subcomponente que encapsula varios subcomponentes. Los subcomponentes se conectan a través de conectores. Los puertos de los subcomponentes también pueden exponerse como puertos de componentes compuestos, y los subcomponentes también pueden ser componentes compuestos. Como se muestra en la Figura 3, el componente compuesto A incluye dos subcomponentes B y D, que están conectados a través del conector c. El puerto de servicio E del componente B está expuesto como el puerto de servicio F del componente compuesto A, y su puerto de solicitud G está expuesto como el puerto de solicitud H del componente A.
2.4 Modelo de componente de aspecto
Componentes de aspecto son los componentes centrales de la arquitectura de software orientada a aspectos, que encapsulan preocupaciones transversales, que es la mayor diferencia con la arquitectura de software tradicional. La Figura 4 muestra el modelo de componente de aspecto. Al igual que los componentes ordinarios, los componentes de aspecto tienen puertos de servicio, puertos de solicitud y propiedades, pero también tienen puertos de aspecto que los componentes ordinarios no tienen. Cuando un componente tiene un puerto de aspecto, puede considerarse un componente de aspecto. Un puerto de aspecto contiene varios aspectos, lo cual es diferente del concepto de aspecto en la tecnología general de programación orientada a aspectos (AOP). La programación orientada a aspectos tiene los siguientes cuatro conceptos básicos: aspectos, puntos de conexión, sugerencias y puntos de entrada. Un punto de unión es una ubicación bien definida en la ejecución de una aplicación. Por ejemplo, una llamada a un método es un punto de unión típico. Un punto tangente es una colección de una serie de puntos de conexión y es el punto de acción de un aspecto. Una notificación representa una acción que se realizará en el punto de unión seleccionado por el punto de corte. Los tipos de notificación comunes son antes, alrededor y después, y la subtabla representa la ejecución del código de notificación correspondiente antes, cerca y después del punto de conexión. Aspecto es la unidad básica utilizada para describir e implementar inquietudes transversales, que consta de puntos de referencia y notificaciones. El aspecto transversal en el puerto de aspecto se centra en los componentes, que es diferente de los objetos en los que se centra el AOP general (como AspectJ). Debido a que los componentes pueden expresar la capacidad de solicitar servicios que no pueden expresarse mediante objetos [9], el modelo de punto de conexión adoptado por los puertos de aspecto es muy diferente al de los lenguajes tangentes.
2.4.1 Modelo de punto de conexión
El modelo de punto de conexión incluye dos tipos diferentes de puntos de conexión, a saber, la operación de provisión de servicio en el puerto de servicio del componente y la operación de solicitud de servicio en la solicitud. puerto. Debido a que la estructura interna de un componente a menudo se trata como una caja negra, el modelo de punto de conexión solo debe considerar elementos visibles fuera del componente, como operaciones de servicio en los puertos de solicitud de componentes y puertos de servicio. Si el modelo de punto de conexión contiene propiedades del componente, se interrumpirá el reempaquetado del componente.
Lenguaje tangente
El lenguaje tangente para seleccionar puntos de unión se basa en expresiones tangentes. La Tabla 1 muestra los cinco componentes del punto de corte, a saber, componente, jp_type, puerto, interfaz y servicio, y luego los explica respectivamente. Donde jp_type representa el tipo de punto de conexión seleccionado, que puede ser un servicio en el puerto de solicitud, un servicio en el puerto de servicio o un servicio en todos los puertos. Consulte la Tabla 1 para obtener más detalles. La Tabla 2 ofrece algunos ejemplos de lenguajes tangentes, donde las expresiones regulares se basan en el paquete java.util.regexp.
2.5 Modelo de arquitectura de software orientada a aspectos
La arquitectura de software orientada a aspectos consta de componentes, conectores y componentes de aspectos. Consulte la Figura 6 para obtener más detalles.
Ejemplo de pago en línea basado en un modelo de arquitectura de software orientado a aspectos
En los últimos años, las compras en línea se han desarrollado rápidamente y el pago en línea es uno de los principales métodos de pago para los consumidores. La Figura 7 muestra un modelo de pago en línea basado en una arquitectura de software orientada a aspectos, que consta de cuatro componentes atómicos, a saber, un componente compuesto, dos componentes de aspectos y tres conectores. WebClientComponent representa el componente del cliente, que puede solicitar el servicio AccountService() del componente de banca en línea WebBankComponent. Este servicio tiene tres parámetros: nombre de usuario, contraseña y tarifa, que corresponden respectivamente al nombre de la cuenta bancaria en línea del usuario, la contraseña y el monto de los bienes adquiridos.
Nombre del componente = " WebClientComponent requerido.
nombre de puerto = " WebClientRequest requerida
←Java . interfaz interfaz = " AccountServiceInterface "←nombre de servicio = " AccountService()"←
〈param nombre = " nombre de usuario " tipo = " cadena "/〉
〈param nombre = " contraseña " tipo = " cadena "/〉
〈param nombre = " costo " tipo = " flotante "/〉
﹨/service﹨﹨/Java . interface﹨
// puerto requerido \
ﺸ/Componentﺸ
Connector AccountServiceConnector se utiliza para conectar el componente del Cliente. y componente de banca en línea, utiliza el mecanismo de enlace de WebServiceBinding
Nombre del conector = " AccountServiceConnector " enlace = " enlace de servicio web " /
←nombre de la fuente = " S ". /←nombre de destino = " T "←
﹔/Conector﹔
"conectar . fuente de = " WebClientRequest"to="S"/ 》
←connect target from = " T " to = " componente del banco web.Respuesta del banco"/"Respuesta del banco
El componente de la banca en línea es un componente compuesto compuesto por el componente de servicio de cuenta y el conector de base de datos de cuentas AccountDBConnector. y el componente de base de datos de la cuenta AccountDBComponent. El puerto de servicio del componente compuesto también utiliza la interfaz AccountServiceInterface, que debe ser compatible con la interfaz utilizada por el puerto de solicitud del componente del cliente
AuthenticationComponent. accede al componente de base de datos de información del usuario UserInfoDBComponent a través del conector UserInfoConnector
pointcut = "Respuesta del fondo WebBankComponent; AccountServiceInterfaceAccountService()"
es una expresión, que está en Use pointcuts en el aspecto. puerto de este componente de aspecto.
Para garantizar la seguridad de los componentes de la base de datos UserInfoDBComponent y AccountDB-Component, el componente de aspecto SecurityComponent utiliza la seguridad del puerto de aspecto para monitorear los puertos de servicio de estos dos componentes, de modo que los registros se agreguen antes de las llamadas al servicio. de estos dos componentes y las funciones de transacción, estos dos componentes a menudo aparecen como preocupaciones transversales en el sistema. La arquitectura de software orientada a aspectos puede encapsularlos bien y facilitar el diseño y el mantenimiento.
‐aspect nombre del componente = " Componente de seguridad "‐aspect nombre del puerto = " Seguridad "‐aspect‐pointcut = " UserInfoDBComponent; UserInfoResponse*;* | Ac-countDBComponent; accountdbsresponse; *;* "/ ‐consejo = "antes" acción = "Registro()"/‐consejo .acción = "antes" = "Transacción()"/aspecto puerto \8208; "/-aspect . componente \8208; aspecto
4Conclusión
Este artículo proporciona un modelo de arquitectura de software orientado a aspectos y diseña en detalle sus tres modelos de unidades básicas, a saber, componentes, conectores y componentes del aspecto. Finalmente, la efectividad y viabilidad del modelo se verifican a través de un ejemplo de pago en línea, que sienta una cierta base para la aplicación práctica de la arquitectura de software orientada a aspectos. El autor continuará mejorando la teoría de este modelo y estudiando los métodos de aplicación de ingeniería de la arquitectura de software orientada a aspectos.
Materiales de referencia:
[10] Wang Xiaoming, Wang Xiaoming. Desarrollo y aplicación de software orientado a componentes [J]. Sistema y estructura Acta Sinica Sinica, 2008, 34(2-3):130-149.
[2]LIEBERHERR K, LORENZ D, MEZINI M. Programación utilizando componentes de aspecto, T R NU-CSS-99-01[R].[s.l.]: Universidad de Noutheastam, 1999.
[3]PAWLAK R, SERNTURIER L, DUCHIEN L D, et al. JAC: Un marco dinámico distribuido basado en aspectos [J]. Práctica y experiencia de software, 2004, 34(12):1119-1148. .
[4]Li·. Diseño de arquitectura de software[M]. Beijing: Prensa de la Universidad de Tsinghua, 2008.
Sun Chunyan y Ma Liang. Cambios en el concepto de componentes de software[J]. Informática, 2002, 29 (4): 28-30.
[6] SZYPERSKI C, GRUNTZ D, MURER S. Software de componentes: más allá de la programación orientada a objetos [M]. 2.ª edición [S.l.]: Addison-Wesley, 2002.
[7]K K, Wang Z. Modelo de componentes de software[J]. Instituto de Ingenieros Eléctricos y Electrónicos Transsoft Engineering, 2007, 33(10):709-724.
[8]SHAW M. La llamada a procedimiento es el lenguaje ensamblador de la interconexión de software: el conector merece un estatus de primera clase[C]//Software Design Research ini CSE Workshop on Studies of Software design 1993:17-. 32.
[9]Nawasha A, P? Zhang Zhiyong, et al. Investigación sobre arquitectura de software orientada a aspectos[C]//Actas del Simposio de aspectos iniciales 2002
.