Una Metodología para Especificación de Componentes de Negocio (position statement) Raquel Anaya



Descargar 24,53 Kb.
Fecha de conversión06.01.2017
Tamaño24,53 Kb.
Una Metodología para

Especificación de Componentes de Negocio

(position statement)

Raquel Anaya

Universidad EAFIT. Medellín, Colombia

ranaya@eafit.edu.co
Isidro Ramos

Universidad Politécnica de Valencia, España



iramos@dsic.upv.co
Justificación

Con la introducción del enfoque de desarrollo basado en componentes, la ingeniería de software se percibe como un proceso de búsqueda, selección, adaptación y composición de componentes almacenados en una biblioteca. Cuando se trata de componentes que representan una funcionalidad relevante en el espacio del problema, los aspectos de especificación, adaptación y composición se tornan tan complejos que deben ser enfrentados desde el punto de vista metodológico y de manera independiente de la tecnología de componentes en que éstos van a ser implementados. En este sentido se estudian modelos y métodos, lenguajes de especificación de arquitecturas y lenguajes visuales que facilitan la representación, construcción, especificación e integración de componentes a un alto nivel de abstracción.


En la primera etapa de este proyecto se definió la arquitectura del componente a alto nivel de abstracción que hemos denominado componente de negocio y la aproximación metodología que guía su proceso de construcción a través de diferentes niveles de abstracción. La especificación del componente está soportada formalmente en una variante de la versión 3.0 del lenguaje OASIS [LRS+98] [AR99] y se integra en un entorno de desarrollo denominado AR2CA [AR2000].
Actualmente se están realizando actividades que permiten la divulgación de esta propuesta y la aplicación de la metodología y del entorno de desarrollo en problemas reales suministrados por la industria. La siguiente etapa del proyecto tiene por objetivo definir el proceso de generación del componente a las plataforma J2EE, considerando los aspectos de interfaz, lógica, distribución y persistencia.

2. Arquitectura del Componente de Negocio

El componente de negocio describe una arquitectura de dos niveles de abstracción: abstracto y concreto y cuatro vistas de modelado: dinámica, deóntica, estructural y funcional (figura 1).


Los niveles de abstracción determinan los pasos de refinamiento por los que el componente ha evolucionado en su proceso de especificación: el nivel abstracto permite obtener una especificación del componente cercana al espacio del problema: el análisis y el nivel concreto representa la especificación del componente cercana al espacio de la solución: el diseño.
Las vistas permiten diferenciar, en un mismo nivel de abstracción, diversos aspectos semánticos de modelado del componente. La vista dinámica describe el compromiso o colaboraciones que se establecen en la sociedad de objetos participantes; la vista deóntica se ocupa de las obligaciones, permisos y prohibiciones (reglas del negocio) que el componente debe implementar y que forman parte de sus propiedades variables; la vista estructural representa la estructura de los objetos participantes y sus relaciones de especialización, agregación o asociación; la vista funcional describe el efecto de las operaciones sobre el estado de las instancias participantes.

Modelo de Colaboraciones

Modelo de

Roles

Dinámica
Deóntica



Funcional

Dinámica
Deóntica

Estructural

Funcional


Estructural
Funcional


Nivel

Abstracto




Nivel

Concreto

Figura no.1 Arquitectura de un componente del negocio

La arquitectura del componente garantiza las relaciones de trazabilidad, tanto de tipo internivel como de tipo intranivel, entre los diversos elementos del componente, facilitando su evolución y versionado.

2. Metodología de Especificación del Componente de Negocio

El proceso de especificación de un componente de negocio sigue una aproximación orientada al comportamiento en donde el centro del análisis son las colaboraciones que se suceden entre los objetos participantes. La especificación del componente en sus diferentes niveles de abstracción se apoya en la propuesta de reificación [Den96]: a partir de una definición inicial se construye una secuencia de especificaciones que van reemplazando conceptos abstractos de la especificación (dominio del problema) por conceptos concretos (dominio de la solución). Para especificar el componente de negocio se utilizan algunos formalismos gráficos cercanos a la notación UML: el modelo ontológico, el modelo de roles y el modelo de colaboraciones


2.1 El modelo ontológico
Sirve para describir el conjunto de términos relevantes que caracterizan el componente en el espacio del problema. Se ha utilizado una notación extendida de los casos de uso. La aproximación por medio de caso de uso permite particionar el espacio del problema en unidades funcionales significativas en un dominio; cada caso de uso representa entonces un componente de granularidad gruesa que describe una acción abstracta compartida a partir de la cual se inicia el proceso de refinamiento del componente.
2.2 El modelo de colaboraciones
Este modelo permite describir los aspectos dinámico y deóntico del componente. Por medio de los diagramas de secuencia se establece, en primer lugar, el protocolo de interacción entre el componente y el entorno, para luego identificar los componentes participantes y establecer sus responsabilidades de cara a la colaboración que representa el componente.
2.3 El modelo de roles
Este modelo permite describir los aspectos estructurales y funcionales del componente. Los objetos participantes representan especificaciones parciales de los objetos del negocio que reciben el nombre de roles. Un modelo de roles está representado por un diagrama de clases y sirve para definir los atributos y métodos de los componentes que participan en el comportamiento y sus relaciones de especialización, agregación y asociación. Este modelo permite además especificar el comportamiento de los objetos participantes con toda la riqueza semántica que provee el lenguaje Oasis (precondiciones, valuaciones, disparos, reglas de integridad, etc.).
2.4 Refinamiento del componente
El proceso de refinamiento del componente del negocio se realiza sobre los modelos abstractos, a los cuales se les aplican unas primitivas de refinamiento para derivar los respectivos modelos concretos. Existen dos tipos de refinamiento:
El refinamiento estructural se realiza sobre el modelo abstracto de roles cualificado con unas relaciones de transformación que permiten obtener el modelo concreto de roles. Se utilizan primitivas de refinamiento como agregación, especialización, relación, que determinan el tipo de transformación que se aplica sobre los objetos de negocio, para derivar los objetos de diseño.
El refinamiento del comportamiento se realiza sobre el modelo abstracto de colaboraciones con el propósito de transformar los servicios definidos sobre los objetos de negocio. Un servicio que en un objeto de negocio es visto como un evento de ocurrencia instantánea, se transforma en un conjunto de eventos sobre los objetos de diseño, que en Oasis recibe el nombre de proceso.
Conclusiones
El enfoque de Ingeniería de Software Basada en Componentes debe considerar aspectos tanto tecnológicos como metodológicos. Desde el punto de vista metodológico, el desarrollo de componentes software con alto nivel de abstracción, retoma los principios de modelado de orientación por objetos siguiendo una aproximación funcional (behavior driven) antes que estructural (data driven). Para la especificación, evolución y adaptación del componente de negocio, se utiliza una notación cercana a UML con una semántica extendida y soportada por un lenguaje formal de especificación. El conjunto de componentes que, en una plataforma tecnológica específica, representan la implementación del componente de negocio, son generados de manera automática a partir de su modelo conceptual.
Referencias
[Ana99] Anaya, Raquel. Desarrollo y Gestión de Componentes Reutilizables en el Marco de OASIS. Tesis Doctoral. Universidad Politécnica de Valencia, España. Departamento de Sistemas Informáticos y Computación, 1.999
[AR99] Anaya, R.; Ramos, I. Un Lenguaje Formal para Especificación y Refinamiento de Objetos del Negocio. Memorias XXV Conferencia Lationamericana de Informática - CLEI99. 1.999
[AR2000] Anaya, R.; Ramos, I. AR2CA:Un Herramienta para la Construcción de Componentes Reutilizables a Través de Niveles de Refinamiento. Memorias 3er Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes Software. Cancúm, México. 2000
[LRS+98] Letelier, P.; Ramos, I; Sánchez, P.; Pastor, O.. OASIS version 3.0. Un Enfoque Formal para el Modelado Conceptual Orientado a Objeto. Universidad Politécnica de Valencia, España. Colección : LIBRO DOCENTE, 1.998


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal