Estado del Arte del Desarrollo de Aplicaciones Basado en
Componentes
Ana Fermoso García
Escuela Universitaria de Informática. Universidad Pontificia de Salamanca. España afermoso@upsa.es
Pablo de la Fuente
Escuela Técnica Superior de Ingeniería Informática. Universidad de Valladolid. España pfuente@infor.uva.es
Resumen
Los cambios que se están produciendo en la filosofía de negocio y la aparición de nuevas tecnologías como la explosión de Internet, originan también cambios en el desarrollo del software y han propiciado la difusión del desarrollo de aplicaciones basado en la utilización de componentes.
Falta todavía mucho camino por recorrer para lograr una metodología más o menos estandarizada en el desarrollo de este tipo de aplicaciones, es más, no hay ni siquiera unanimidad a la hora de dar una definición de lo que es un componente. Este tabajo trata de hacer un recorrido por las diversas tendencias y metodologías de desarrollo con componentes que existen hoy en el mercado y partiendo de ellas, se plantea como trabajo futuro el crear un método que unifique más o menos todas estas tendencias.
Palabras clave: componente, interfaz, UML
1. Introducción
En la gestión actual de un negocio han surgido nuevas necesidades como son el tener que estar continuamente preparados para adaptarse a los cambios que exige la competencia, esta gestión afecta a más gente, pues ahora ya no sólo se van a ver involucrados en ella los empleados de la propia empresa, sino que también van a participar de forma activa otros elementos externos al negocio como clientes, proveedores, bancos, ... Aparecen cambios tecnológicos, toda la automatización de un proceso de negocio implica ahora también la gestión de redes y servicios para reducir costes y facilitar el acceso al cliente. Dentro de estas nuevas tecnologías hay que destacar el gran cambio que ha supuesto Internet, ahora todo tiene que estar preparado para trabajar también con Internet e Intranets. Finalmente se demandan nuevas arquitecturas hardware y software que permitan mantener la información descentralizada, que soporten informaciones de todo tipo y que no nos obliguen a depender de un determinado vendedor de software.
Todo esto ha provocado también una revolución en el mundo del software para adaptarse a estas nuevas necesidades y así aparecen los componentes de software como nueva filosofía de implementación de aplicaciones. El problema que se plantea es que han proliferado el desarrollo de este tipo de aplicaciones pero sin unanimidad en sus criterios, ni siquiera existe una definición normalizada de lo que es un componente y esto puede plantear problemas y acabar precisamente con lo que se pretende, que es la independencia del componente del resto de la aplicación.
Lo más importante es que de entre todas las definiciones que se dan se obtengan unas características de lo que es y no es un componente y en general podemos resumir, dando una definición propia, que un componente es una entidad software que soporta una funcionalidad software que se presenta en forma de servicios del componente y que se implementa a través de interfaces. Una interfaz es cada una de las formas en que podemos usar un componente según
nuestras necesidades. Por otra parte, un componente tiene que ser independiente de la plataforma de desarrollo, del lenguaje de programación con que se haya implementado y de cualquier otra herramienta de aplicación, para poderlo usar donde lo necesitemos por su funcionalidad, que es lo que debe interesarnos.
En la práctica, sin embargo, esta independencia total de la plataforma de desarrollo y adaptación plena a cualquier aplicación en que se necesiten sus servicios, no es tan clara ni tan sencilla y tampoco esta normalizada la sintaxis con la que un componente debe mostrar sus interfaces para que todo el mundo los pueda entender y usar.
En general, a la hora de desarrollar una aplicación y en función de sus necesidades, se establece la funcionalidad de los componentes que necesita y el siguiente paso es buscar si existen componentes ya hechos que podemos reutilizar, o si por el contrario los debemos de hacer nosotros. Este enfoque plantea dos grandes ramas a la hora de la aparición de métodos de desarrollo con componentes:
- Las metodologías que simplemente ven una aplicación como un simple ensamblaje de componentes donde lo que hay que hacer es encontrar los componentes ya hechos que necesitamos y lograr la interacción entre ellos, es decir, solucionar los problemas de ensamblaje.
- Las metodologías que se plantean el como llegar hasta las características que debería tener cada componente que se necesita dentro de un aplicación a la hora de satisfacer sus necesidades, y luego ya nos ocuparemos de encontrar o implementar componentes con esas características.
Vamos a hacer un recorrido por los diversos métodos que aparecen en el mercado en uno y otro sentido, aunque lo que más nos interesa es la segunda opción, el cómo llegar a que componentes y con que características deben desarrollarse, para dar solución a una aplicación particular, pues el problema de la integración de componentes ya ha sido mucho más investigado.
Más en particular vamos a ver, dentro del desarrollo de componentes, a la filosofía de Desarrollo Basado en Componentes (CBD) de Sterling y dentro de ella y como una metodología concreta de CBD, pero influenciada por UML (Unified Modeling Language), el modelo de Catalysis de Desmond D’Souza, y a continuación otros dos métodos de definición de componentes, uno Orientado al Proceso y otro Modelado Dirigido por la Arquitectura. Y viendo la aplicación como un simple ensamblaje de componentes o Componentware primero haremos una introducción general de esta técnica y luego veremos dos casos particulares de ella que son los Patrones de Proceso y la Adaptación a Componentware del modelo alemán V-Modell, aunque este último esta totalmente influenciado por los Patrones de Proceso.
Finalmente veremos un modelado de componentes a medio camino entre los anteriores, que consiste en modelar componentes pensados ya para su reutilización (modelar para reutilizar) y
apoyándose en UML como herramienta de definición.
2. Desarrollo Basado en Componentes (CBD)
CBD [Sterling 1999] aparece, como acabamos de decir, por el cambio en las nuevas aplicaciones orientadas a Internet y bajo el modelo de computación en red, y la construcción de este tipo de aplicaciones se hace con componentes.
CBD es más una filosofia de desarrollo que plantea unos pasos genéricos en dicho proceso de desarrollo, que una metodología en particular.
Las aplicaciones ahora se tienen que ver como un conjunto de componentes que interactúan entre sí para suministrar servicios de negocio a través de redes y sistemas operativos.
Una aplicación ya no es un conjunto de ejecutables y datos, sino un conjunto de servicios requeridos para soportar el ámbito de un problema.
Según esta filosofía, los pasos a seguir dado un problema serían: 1. Diseñar el modelo de procesos de negocio.
2. Buscar posibles componentes reutilizables entre catálogos de componentes y si luego se encuentra otro mejor, que se pueda reemplazar sin afectar al resto.
3. Añadir componentes que enlacen lo ya existente (si lo hay), con los nuevos componentes encontrados en los catálogos.
Para encontrar los componentes adecuados para la aplicación hay que fijarse más en las necesidades de esa aplicación, que en como están construidos internamente esos componentes. Los pasos serían:
1. Registrar y analizar las necesidades del negocio.
2. Asociar esas necesidades con componentes ya construidos, o implementarlos nosotros si no existen.
3. Ensamblar los componentes encontrados con el resto de la aplicación.
4. Si se han construido nuevos componentes, quedarlos disponibles para nuevos proyectos. Existen distintas formas o métodos de aplicar estos pasos, cada forma determina una metodología de CBD, encontramos más información en [Brown 1998]. Uno de los modelos más usados es el de Catalysis que se basa en UML y que pasamos a ver a continuación.
3. Catalysis.
Este modelo se describe detalladamente en [Souza 1999].
Un componente software en este modelo, se define como un paquete de servicios de software reutilizable y desarrollado independientemente.
Un componente tiene tres partes:
1. Una especificación que describe la semántica, lo que hace el componente y como debe
usarlo el cliente.
2. Un diseño de la implementación que describe como se ha construido ese software internamente. Se expresa en términos de código y datos. La implementación puede ser escrita en un lenguaje de programación y plataforma distinta a la que va a tener luego el cliente que usa el componente.
3. Un ejecutable que permite que funcione el componente en una determinada plataforma.
Un componente puede ser sustituido por otro si tienen la misma especificación, da igual su implementación.
La separación entre especificación e implementación lo da la encapsulación.
La especificación es fundamental darla bien para poder usar eficientemente el componente y tiene dos partes:
1. Los servicios que el componente suministra descritos como una lista de operaciones ofrecidas por el componente.
2. Modelo de especificación, que es el vocabulario que describe el comportamiento de cada operación.
Una especificación describe conjuntos de servicios que pueden ser agrupados en cluster, cada uno de esos grupos es una interfaz. Una interfaz define como el cliente debería interactuar con el componente, pero oculta los detalles de implementación.
El modelo de especificación de interfaces no es un diseño de implementación, es independiente de cualquier tecnología. No detalla como se gestionan o almacenan los datos, el cliente sólo debe acceder a las operaciones definidas en la interfaz y no puede hacer nada más.
Acabamos de decir que un componente se utiliza a través de sus interfaces, la cuestión que se plantea es como diseñar estos interfaces y la respuesta se obtiene con las dos tareas siguientes: - Modelado de componentes: es el grupo de actividades que lleva una descripción detallada
de las interfaces y de cómo están relacionados con los componentes que los implementan. Las interfaces tienen que agruparse en catálogos que también deben contener detalles de los componentes con los que se relacionan.
- Modelado del dominio: aproximación orientada a objetos para entender los requerimientos y
trasladarlos a una descripción de interfaces. Aquí es donde interviene la nomenclatura UML, pues se describe con el modelado de casos de uso, diagramas de colaboración,... todo ello nos ayuda a identificar objetos en un dominio, su conducta, las colaboraciones con otros objetos y el protocolo de esa colaboración. De aquí se sacarán las interfaces que luego agruparemos y asociaremos a componentes.
3.1. Modelado de componentes e Interfaces.
Veamos ahora la relación entre el modelado de componentes e interfaces.
Un componente se define también como un conjunto de interfaces, y estos interfaces agrupan los servicios que ofrece el componente.
Una interfaz consiste en un nombre, una lista de operaciones y un modelo de especificación. Cada operación se describe a través de un nombre y una cabecera con los parámetros que se le pasan y los valores que devuelve. En la cabecera se describe que ocurre cuando esa operación es invocada por un objeto.
El modelo de especificación es una descripción del vocabulario o términos usados para explicar los efectos detallados de la operación, explica lo que significa la operación, la semántica de interacción.
Cuando se modela un componente durante el proceso de modelado de componentes, sus especificaciones serán los modelos de especificación de cada uno de las interfaces que soporta dicho componente.
La especificación completa de una interfaz suministra la descripción y restricciones de las operaciones soportadas y el significado de cada uno de ellas utilizando un vocabulario común al problema planteado y siendo lo más precisa posible para evitar cualquier ambigüedad en la definición. Esta es información suficiente para definir correctamente el protocolo de colaboración.
La representación de una interfaz puede hacerse como la de una clase UML añadiendo el supertipo de <<interfaz>>.
Dentro de la interfaz también se pueden poner asociaciones o relaciones con otras interfaces o especificaciones y el estado del objeto a través de los valores de sus atributos. Estas relaciones señalan colaboraciones entre los componentes que implementan esas interfaces.
En el modelo de componentes e interfaces, también puede aparecer el polimorfismo para permitir que distintos componentes respondan al mismo mensaje, aunque internamente se
implementen de distinta forma, y la herencia, para poder reutilizar lo que ya se ha hecho y establecer una jerarquía de tipos.
3.2. Modelado del Dominio.
El segundo modelo de desarrollo fundamental es el modelo de dominio, que describe el contexto del sistema que se quiere desarrollar, más en concreto el modelo de dominio describe los objetos significativos, sus relaciones y las colaboraciones entre objetos en el dominio en el que estamos trabajando.
A partir de este modelo también se deducen las interfaces del sistema, más en concreto, la relación entre interfaces y dominio sería la siguiente:
1. Las interfaces útiles para el sistema se sacan de entender que conducta es requerida por los objetos individuales para participar en las actividades clave del dominio.
2. Los modelos de especificación de interfaces se pueden enlazar con objetos y colaboraciones en el modelo del dominio.
3. Cuando se usa una interfaz en el modelo del dominio se necesita un protocolo adecuado para determinar como interactúa la interfaz con el modelo del dominio.
Un tipo modela una serie de facetas o conducta común a un conjunto de objetos. Los tipos por tanto se caracterizan por operaciones que definen su conducta y modelos de especificación (atributos, especificaciones y reglas).
Durante el modelado del dominio se determinan que objetos son los importantes para el sistema, los tipos, las actividades del dominio y la colaboración entre ellos. En algún momento decidimos implementar esa conducta del tipo en un componente y es cuando aparecen las interfaces. Una interfaz es por tanto, lo mismo que un tipo pero cuando lo implementamos ya en algún componente.
Dentro del modelo del dominio una colaboración es una interacción entre los objetos del sistema. En una colaboración pueden intervenir muchas partes y una secuencia de acciones entre ellas. Durante esta secuencia un mismo participante puede jugar distintos roles o papeles y a veces también distintos participantes pueden jugar el mismo rol. El rol es por tanto, la forma en que el tipo participa en el dominio.
Las interfaces que luego se implementarán se derivarán de los tipos y los roles, es decir, el papel que un tipo juega en la colaboración nos ayuda a seleccionar aquellos aspectos del comportamiento que deben ser soportados por la aplicación.
Durante el diseño de componentes una interfaz representa el papel que un componente juega en el modelo de colaboración de la aplicación.
3.3. Modelado de Componentes dirigido por el comportamiento en Catalysis.
Resumiendo lo visto, y una vez entendido lo que es el Modelo del Dominio y de Componentes e Interfaces, los pasos que Desmond D’Souza [Souza 1999] propone en su metodología Catalysis para obtener los componentes de una aplicación, serían los que se especifican a continuación, y como herramienta para facilitar este modelado usa los diagramas de UML.
1. Modelado del dominio: establecer los objetos importantes del dominio y la interacción entre ellos.
Los objetos anteriores se obtienen de estudiar las colaboraciones entre los objetos y los roles que esos objetos desempeñan en la colaboración.
2. Estudiamos la conducta del sistema a través de las colaboraciones entre los objetos, y a su vez, agrupamos estas colaboraciones a través de un contexto.
Podemos especificar un contexto como dependiente de la conducta compartida por muchos objetos como un tipo, un tipo representa un rol.
Cuando se decide la conducta que se debe implementar, los tipos se redefinen y publican como interfaces.
3. Las interfaces se asocian a componentes y si existen componentes que ya implementan esas interfaces, se reutilizan.
Para ayudar a definir las colaboraciones, las podemos definir por medio de roles y protocolos usando escenarios. Los escenarios representan un posible ejemplo de la colaboración (las conductas más o menos usuales).
Para el análisis de escenarios se pueden usar los diagramas de colaboración de UML.
Las colaboraciones también se pueden definir mediante casos de uso, especialmente cuando describen eventos y acciones clave en el nivel más alto del proceso de negocio.
4. Definición de Componentes con un Método Orientado al Proceso.
Según esta metodología [Mattes et al. 1999], un componente es un sistema de información que puede ser visto desde tres puntos de vista o niveles: nivel de acceso a datos, interacción con otros objetos y acoplamiento de procesos.
En todos los niveles las interfaces entre los componentes deberían ser declarados de forma abstracta e independiente de la sintaxis o implementación que luego se utilice, así se logra no depender del vendedor.
En la clásica filosofía orientada a datos, un componente se define usando conceptos como entidades, relaciones y modelos conceptúales de datos y en la filosofía de orientación a objetos se utilizan conceptos como clases, herencia, interfaces, eventos, mensajes, ...
Es mejor la orientación a objetos que la de datos porque los métodos de los objetos suministran un protocolo más eficiente para la interacción entre el componente cliente y el servidor, que una secuencia lineal de sentencias en SQL sobre un sistema de tablas en una base de datos. Pero el modelo de objetos también tiene algunas deficiencias que trata de solucionar el orientado a procesos, cómo es la dependencia del lenguaje, que la interfaz de un componente no suele estar formada por un único objeto sino por la combinación de varios, son más difíciles de implementar las restricciones de ejecución en objetos, ...
Las definiciones de interfaz orientadas a procesos solucionan estos problemas y para realizarlas seguimos los siguientes pasos:
1. Identificar los actores del sistema de información del negocio. Un actor puede ser humano o
un proceso activo.
2. Especificaciones de conversación: describen las interacciones entre los actores y dentro de la misma se asignan roles a dichos actores. El actor que inicia la conversación es el cliente y el que la acepta el proveedor.
Un actor puede participar en varias conversaciones (incluso de forma concurrente) con distintos roles.
3. Especificaciones de diálogo: describen los pasos del proceso dentro de cada conversación especificada en la fase anterior.
Un diálogo consiste en una especificación de contenido jerárquicamente estructurada, más una serie de especificaciones de peticiones válidas o restricciones que hay que tener en cuenta en ese paso del proceso en particular.
Para cada especificación de petición dentro de la especificación de un diálogo, es decir, cada petición que se hace al usuario, hay que especificar los valores admisibles.
La especificación de diálogo tiene que abstraerse de los detalles o modalidad concreta en que luego se tienen que implementar esos diálogos en tiempo de ejecución (por ejemplo si luego las peticiones se tienen que hacer por e-mail, vía interfaz GUI, ...)
En la orientación a objetos tradicional todas las interacciones entre objetos se hacen mediante el paso de mensajes y ahora el estilo de interacción, es decir, lo que describe la especificación de diálogo, se basa en “formularios” y “documentos”, con lo que se parece más a la interacción real (de una forma semi-formal) entre humanos.
La ventaja de las especificaciones de conversación es que nos ayudan a definir los componentes al identificar los datos y dependencias de control, y facilitar además la asignación de estos datos, conductas y también procesos, en forma de responsabilidades, a los actores del sistema. En definitiva, la mejora que aporta esta nueva orientación es que se describe el sistema a implementar de una forma más similar a como luego va a interactuar realmente con el ser humano y de una forma más similar también, al modelo de implementación real que luego se va a usar (formularios y documentos). Para conseguir esto sus dos herramientas o innovaciones fundamentales son las especificaciones o descripciones de conversación y diálogo entre los actores que participan en el sistema, junto con los roles que estos actores representan en cada una de estas conversaciones y diálogos.
5. Modelado de Componentes por el método “T”dirigido por la Arquitectura.
El modelo “T” [Ambler 1998] es un método más de modelado de componentes que, como en muchas otras técnicas, trata de dividir el problema en partes para solucionarlo y es apropiado cuando se trabaja con grandes proyectos que tienen que coexistir con otros subsistemas por un largo periodo de tiempo.
El modelo “T” se basa en un proceso de modelado en dos partes, primero se da el modelo de arquitectura que describe la organización y su entorno externo, los subdominios del sistema y como se relacionan entre si, así como los componentes hardware y software usados para soportar el negocio. En segundo lugar se desarrolla ya el modelo en detalle que describe como debería ser construido cada dominio sobre la base de los límites establecidos por la arquitectura dada.
El modelo de arquitectura es una base de partida para el modelo detallado y el modelo detallado conduce los cambios sobre el modelo de arquitectura y al mismo tiempo este modelo de arquitectura evoluciona con los modelos detallados.
5.1. Modelo de Arquitectura
Esta formado a su vez por tres elementos o partes que pasamos a detallar:
. Modelo de la empresa: describe la organización y su entorno externo y su información se capta y representa, de nuevo, por medio de los diagramas de casos de uso, que contienen casos de uso y actores. Para su implementación intervienen los analistas y los usuarios.
. Modelo de la arquitectura del dominio: determina, a partir del modelo de empresa, los elementos a desarrollar a alto nivel en el sistema. Como herramienta utiliza los diagramas de secuencias de UML, obtenidos a partir de los casos de uso, y sobre todo el diagrama de
componentes a alto nivel, que mostrará las aplicaciones o subsistemas que soporta la organización. En todo este proceso intervienen analistas, usuarios y diseñadores.
. Modelo de la arquitectura técnica: se centra en la tecnología y como debe ser esta para soportar nuestra organización. Se tiene en cuenta tanto las necesidades técnicas como las restricciones impuestas por el entorno, así como las posibles necesidades futuras. El principal producto obtenido en esta fase es el diagrama de desarrollo que incluirá el hardware, sistema operativo, middleware y la configuración software. Para llegar hasta este diagrama la herramienta que nos va a ayudar es el prototipado técnico que nos permitirá ir probando las diferentes posibilidades tecnológicas para evaluar la que más nos conviene. En esta fase participan los analistas, diseñadores y programadores.
5.2. Modelo Detallado.
También se denomina Modelado de Componentes de Aplicaciones o Subsistemas.
El modelo de arquitectura define los componentes que se necesitan y el detallado describe como trabaja internamente cada componente y lo hace en dos fases:
. Análisis detallado: establece que componentes necesitan ser construidos y es conducido por la arquitectura del dominio.
. Diseño detallado: es conducido por el análisis detallado y la arquitectura técnica, teniendo ya también en cuenta aspectos como tamaño, volumen de transacciones y utilización de recursos. Para detallar cada componente se diseñan sus interfaces, describiendo para cada método de los mismos, sus parámetros de entrada, valores de salida y pre y post condiciones antes de ser ejecutado.
6. Componentware.
El objetivo de Componentware [Bergner et al. 1998a] y [Bergner et al. 1998c], es construir sistemas software mediante el ensamblaje de componentes prefabricados. Esto supone una nueva filosofía de desarrollo y esta nueva filosofía se basa en los siguientes puntos:
1. Concepto de componente bien definido.
2. Técnicas de descripción para componentes. Son necesarias para la comunicación con los clientes y entre los desarrolladores y por ejemplo se puede usar UML, C++ o JAVA.
3. El desarrollo debe estar organizado de acuerdo a un proceso. El proceso consiste fundamentalmente en la asignación de tareas a distintos roles (cliente, desarrollador de componentes, ensamblador de componentes, coordinador de proyecto, arquitecto de sistemas,...)
4. Las técnicas de descripción y los procesos, es decir, el método de desarrollo, tienen que ser soportados por herramientas.
6.1. Características y conceptos.
Componentware es el arte de construir sistemas a partir de componentes, por tanto los conceptos más importantes son el de componente e interfaz.
Las interfaces son fundamentales para el uso de los componentes por sus usuarios. Permiten al cliente encontrar el componente adecuado a través de su propósito, funcionalidad, uso y restricciones.
Un componente puede implementar (o exportar) uno o más interfaces y puede usar también (importar) interfaces de otros componentes. Las interfaces exportadas corresponden a los
servicios que el componente suministra al entorno y los importados corresponden a los servicios que el componente necesita del entorno para implementar los servicios exportados. Las interfaces exportadas e importadas restringen las conexiones entre componentes.
6.2. Técnicas de descripción para componentes.
Describir las interfaces de un componente significa describir su vista de “caja negra”.
Un tipo de descripción es el de los Diagramas de Interfaces de Componente (CID’s) que son una adaptación de los diagramas de clases de UML donde cada caja representa una interfaz de exportación o importación, de un componente.
La parte de la conducta del componente se puede describir con máquinas de estado o diagramas de secuencia.
Para describir la implementación del componente, también llamado vista de “caja blanca o cristal”, se pueden usar diagramas de casos de uso, máquinas de estado y diagramas de secuencia. Una vez más, por tanto, se siguen usando los diagramas UML.
6.3. Método Componentware.
Por encima de las técnicas de descripción dentro del desarrollo de componentes, esta el “método” de desarrollo.
En el método de desarrollo de componentes las principales tareas son semejantes al modelo tradicional en cascada: análisis, diseño de la arquitectura, diseño de componentes e implementación, pero ahora estas tareas no tienen porque realizarse secuencialmente, sino que se pueden hacer en paralelo o pasar de una a otra. Entre ellas además se requerirán buenas interfaces: documentos, especificación e implementación de componentes e interfaces.
Cada tarea consistirá en una serie de subtareas y no hay un orden temporal entre el desarrollo de dichas tareas para aumentar la flexibilidad del proceso, depende del estado actual del proyecto. Aparecen algunas nuevas como la interacción con los vendedores o la búsqueda de los componentes adecuados.
Las tareas fundamentales del modelo componentware son, por tanto, las de cualquier modelo de procesos, salvo que el diseño se divide en Técnico y de Negocio. La descripción de cada tarea con sus subtareas es la siguiente:
. Análisis: el principal resultado de esta tarea es obtener la especificación de los requerimientos
del cliente y dentro de esta parte tenemos:
- Análisis de Interacción: se refiere a la interacción entre el sistema y el entorno, delimita los límites del sistema, sus principales actores (humanos y sistemas técnicos) y su papel en el sistema a desarrollar. Puede tener que ir acompañado de representaciones como casos de uso, modelo de procesos de negocio, especificaciones de interacción con casos de prueba del sistema e incluso algún prototipo GUI.
- Análisis de Responsabilidad: especifica la funcionalidad esperada del sistema con respecto a los requerimientos funcionales y no funcionales. Incluye partes o representaciones como la especificación de servicios, diagramas de clases y diccionario de datos.
- Análisis de Riesgos: identifica los beneficios y riesgos asociados al desarrollo del sistema. Para poder llevar a cabo esta subtarea se requiere un estudio de mercado con información acerca de las soluciones y componentes que podemos encontrar orientados al negocio. El análisis cubre aspectos funcionales y no funcionales, luego el Diseño de Negocio se ocupará de los funcionales y el Técnico de los no funcionales. Por otra parte, los casos de prueba obtenidos del análisis de interacción los tendrá que pasar luego la implementación.
. Diseño de Negocio: define toda la arquitectura del negocio, especifica los componentes de
negocio e incluye lo siguiente:
- Diseño de Arquitectura y Componentes: sacan, respectivamente, los requisitos y la funcionalidad de los componentes de negocio (equivalen al análisis de Interacción y responsabilidad en el análisis) pero no tocan aspectos técnicos, detallan o especifican aspectos relevantes del negocio, interacciones, algoritmos y responsabilidad del sistema y sus componentes.
- Búsqueda de componentes: corresponde a la preselección de componentes de negocio y la elección del estándar de la arquitectura de negocio para la especificación posterior.
- Evaluación: compara los componentes encontrados con los especificados en el diseño de arquitectura y componentes.
. Diseño Técnico: comprende la especificación de componentes técnicos como son los
componentes de base de datos y toda la conexión de la arquitectura según los requerimientos no funcionales del cliente. Afecta a aspectos como persistencia, distribución y esquemas de comunicación.
Las subtareas son semejantes a las de Diseño de Negocio pero ahora en la parte técnica. - Especificación: mezcla las dos vistas de diseño anteriores resultando una especificación de
arquitectura y componentes consistente.
- Pruebas de componentes: prueban a los componentes diseñados anteriormente respecto a los requerimientos de usuario y la arquitectura elegida. Algunos componentes simplemente tienen que ser ensamblados y otros desarrollados.
- Asignación de componentes: especifica que componentes deben ser desarrollados en el proyecto y que componentes son externos, es decir, están ya hechos.
. Implementación: el principal resultado es el código. El código abarca tanto al código fuente como el binario, para los componentes ya hechos.
Con las siguientes metodos, “Componentware Basado en Patrones de Proceso” y “Adaptación del V-Modell Process a Componentware”, veremos algunos ejemplos para llevar a cabo este desarrollo Componentware.
6.4. Nuevos roles en el proceso de desarrollo.
En el proceso de desarrollo software aparecen nuevas figuras como las siguientes:
. Desarrollador de componentes: su responsabilidad es reconocer los requerimientos comunes a muchos clientes y usuarios y construir componentes reutilizables de acuerdo a ellos. Si un cliente necesita un componente, el desarrollador es el encargado de ofrecerle y venderle ese componente.
. Ensamblador de componentes: adapta a las necesidades específicas del sistema a desarrollar, el componente preconstruido y además lo integra en el sistema bajo desarrollo.
. Analista de sistemas: en otras metodologías su labor era sólo recoger los requerimientos del cliente, ahora además también tiene que explorar las características de los sistemas existentes y los componentes de negocio relevantes.
. Arquitecto de sistemas: desarrolla un plan de construcción y selecciona los componentes adecuados junto con los desarrolladores y ensambladores de componentes. Durante el desarrollo el arquitecto supervisa y revisa los aspectos técnicos y la consistencia y calidad de los resultados.
. Coordinador de proyecto: supervisa todo el proceso de desarrollo software, especialmente en
cuanto a agenda y costes. Se encarga junto con el cliente de establecer estos límites.
7. Componentware basado en Patrones de Proceso.
Según [Bergner
et al.
1998b], un patrón es una solución genérica a un conjunto de problemas o sistemas con características más o menos similares.Desde el punto de vista de los componentes, los patrones de proceso pueden ser considerados desde la perspectiva del proveedor y productor del componente, que intentará que su solución se aplique en la mayor parte de casos posibles para vender más, y desde la perspectiva del cliente, que seleccionará el componente mejor de entre todos los que le pueden servir en cada momento. Las tres partes fundamentales de un patrón de proceso son:
. Contexto: definido por el estado interno del desarrollo del proyecto, definiendo este estado interno respecto a los clientes, competidores y situación del mercado. El contexto se refiere a la “aplicabilidad” (descripción del contexto en el que el patrón puede ser usado) y “estructura” (representación visual de la estructura del patrón) del patrón propuesto.
. Problema: describe el problema concreto que típicamente se presenta en el contexto de desarrollo dado. Normalmente menciona las influencias de los desarrolladores, clientes, competidores, vendedores de componentes, restricciones de tiempo y dinero, requerimientos y propiedades deseables que la solución debería tener,...
. Solución: comprende a los roles y partes de la estructura resultado y suministra recomendaciones concretas sobre la secuencia y prioridad de las acciones a desarrollar. El proceso de aplicación de patrones consistiría en que, partiendo de la situación actual del proyecto representado por el estado y consistencia de la estructura de resultado, el coordinador de proyecto identifica los problemas del desarrollo actual. Esta información provoca la selección de uno o más patrones de proceso que pueden ser aplicados porque su contexto y descripción del problema están relacionados con la situación actual.
Podemos definir un patrón como un método o modelo que marca los pasos a dar para el desarrollo basado en componentes de un sistema. Habrá distintos patrones que se pueden aplicar para usar en cada momento y elegiremos el que más nos interese según la situación actual y tipo del proyecto a implementar, así logramos mucha más flexibilidad.
Algunos de los tipos de patrones más usados son los siguientes:
- Patrones de proyecto: diseño top-down, de ida y vuelta, conducido por la arquitectura, ...
- Patrones de resultados internos e intermedios: Tune Performance, reingeniería, innovación,
actualización o valoración de componentes, ...
- Patrones de resultados principales: análisis conducido por el cliente o por el mercado,
evaluación conducida por el diseño o por el componente, ...
8. Adaptación del V-Modell Process a Componentware.
La metodología V-Modell [Ansorge et al. 1999] es el modelo de procesos del gobierno alemán, para el desarrollo de sistemas de información y lo que vamos a ver es como se puede adaptar para que también sirva para desarrollos Componentware, apareciendo así como una metodología más para desarrollos basados en componentes, aunque en la práctica lo que hace es introducir las características del modelo de patrones, que va a ser su principal influencia. El modelo V-Modell tradicional tiene cuatro submodelos o partes fundamentales que son:
- Ingeniería de sistemas - Gestión de proyectos - Gestión de configuraciones - Modelo de Producto
Lo que se trata de ver es cómo afectan a estas tareas las nuevas necesidades de Componentware, teniendo en cuenta que ahora hay que afrontar dos nuevas cuestiones que son la reutilización de componentes ya hechos y que el proyecto tiene que desarrollarse para poder ser reutilizado, para que se pueda reutilizar lo que se ha hecho.
Veamos ahora como se ven afectadas, por la aparición de los componentes, cada una de las tareas principales del V-Modell.
• Ingeniería de Sistemas.
Abarca todas las actividades relacionadas con el desarrollo hardware y software y la creación de los correspondientes documentos.
Se añaden ahora actividades relacionadas con la reutilización como son la búsqueda de componentes ya existentes y su evaluación detallada para determinar su valía.
También dentro de esta actividad esta el análisis de reemplazamiento de un componente por otro, su coste y los cambios que supone.
Las actividades de diseño e implementación ahora son principalmente actividades de composición, instanciación y adaptación de los componentes ya existentes.
• Gestión de Proyecto.
Tiene tres actividades fundamentales: inicialización, planificación y ejecución.
En general afecta a un planteamiento de objetivos generales, planificación de recursos, agenda, estimación de costes, análisis de riesgos. Además ahora aparecen nuevas actividades que son:
- Definir un proceso flexible para adaptarse a los cambios del mercado
- Negociación entre desarrollador, cliente y productor a la hora de construir un componente.
- Análisis de mercado y marketing para comprobar que es lo que existe en el mercado y cuales son las nuevas necesidades.
- Gestión de proveedores de componentes, de contratos de esos componentes y de variantes o posibles versiones que salgan al mercado de los mismos.
• Gestión de Configuraciones..
La gestión de configuraciones esta relacionada con los cambios y gestión de copias y con la creación, eliminación y cambios del producto en sí mismo.
Las principales tareas añadidas serían la integración de descripciones, librerías y variantes de componentes.
• Valoración de Calidad..
Para valorar la calidad hay que valorar los componentes.
Las técnicas de prueba para componentes son distintas de las del software tradicional, por ejemplo porque ahora ni siquiera tendremos el código fuente para probarlo. El proveedor
del componente debe dar alguna información adicional sobre la calidad de sus componentes.
Las pruebas de componentes externos no se pueden retrasar hasta la integración del sistema, hay que probarlos durante la elaboración de la arquitectura y las interfaces para detectar defectos ocultos que puedan luego afectar a todo el proyecto.
9. Modelado de componentes con UML para ser reutilizados.
Lo que plantea este método [Lewis
et al.
1999] es otra forma de diseñar componentes, pero ya pensando en facilitar al máximo su reutilización, que normalmente no es tan fácil en la práctica, como se plantea en la teoría.Lo que un componente muestra al exterior para determinar como reutilizarlo es lo que en este método se denomina “fachada”.
Lo que se da habitualmente, como lo que aquí denominamos fachada del componente, es sólo el código necesario para usar el componente a través de sus interfaces. Lo que este método plantea como mejora es que esta fachada no consista únicamente en la parte de implementación, sino que también vaya acompañada de los modelos de análisis y diseño asociados a ese componente, descritos con diagramas UML, y teniendo en cuenta que ese componente se ha de desarrollar con independencia de cualquier plataforma o marco de desarrollo para que no se vea limitado su uso.
Más en particular, cada componente debe ir acompañado de:
- Un modelo de casos de uso que determina los requerimientos del sistema que va a solucionar y que además sirve de base para las futuras pruebas y posterior análisis.
- Un modelo de análisis con el diagrama de clases y los diagramas de colaboración y secuencias asociados a dicho componente
- Un modelo de diseño, que junto con el de implementación, es lo único que traía normalmente cualquier componente.
Con toda esta información de cada componente posible para reutilizar, ya es mucho más fácil esa reutilización e integración con el resto de la aplicación, pues su análisis y diseño, representados en UML, se pueden compenetrar más fácilmente con el análisis y diseño del resto del sistema.
10. Conclusiones y líneas futuras.
El objetivo de todas las metodologías vistas es el mismo, implementar la aplicación que resuelve el problema del sistema a implementar utilizando componentes, pero para conseguirlo cada uno da una solución:
- Catalysis integra un modelo de dominio, que determina para cada aplicación en particular cuales son sus necesidades, con un modelo de componentes, que especifica las características de los mismos.
- El Método Orientado al Proceso se basa en describir el sistema como un conjunto de especificaciones de conversaciones y diálogo en forma de documentos y formularios, desde los que se obtienen las características de los componentes que se necesitan.
- El Método “T” dirigido por la arquitectura, define el proceso en dos fases, primero se modela la arquitectura con las necesidades del sistema y limitaciones técnicas y luego se detalla, asociando ya componentes a esas necesidades y limitaciones.
- Los Patrones de Proceso dan soluciones genéricas a problemas similares lo que supone plantearse el desarrollo de componentes por parte de los proveedores, como una solución que satisfaga al mayor número de potenciales clientes posibles, y por parte de los clientes, como una búsqueda del mejor componente en cada caso, dentro de todo lo que ofrece el mercado.
- El modelo V- Modell adapta el clásico modelo de desarrollo alemán a componentware, añadiendo la problemática de la reutilización en sus diferentes etapas.
- El método de Modelado para la Reutilización con UML plantea el que, a la hora de exponer las características de un componente para poder ser utilizado, lo que se denomina la fachada del componente, se muestre también su modelo de análisis y diseño, que habrá sido realizado con UML, y así se facilitará su integración con el resto del sistema.
Cada solución es un enfoque distinto y de lo que se trata es de intentar unificar y obtener así un modelo más o menos normalizado de desarrollo con componentes, analizando por ejemplo, lo que se puede sacar de común de estos métodos.
Parece lógico que el proceso de desarrollo planteado se apoyara o usara directa o indirectamente diagramas de UML, pues esto aparece en varios de los métodos, más información también sobre el uso de UML aparece en [Muller 1997] y [Kruchten 1998]. También parece lógico el diferenciar dos grandes etapas dentro del desarrollo:
- Una primera que consistiría en el análisis de las necesidades del problema que se plantea, y en función de ellas obtener las características o servicios que deberían ofrecer los componentes que se deben utilizar.
- Una segunda de búsqueda y ensamblaje de esos componentes o creación de los mismos sino existen. Esta segunda fase correspondería a lo que hemos denominado aquí Componentware y es quizás la parte que esta ya más avanzada. El problema es que Componentware ya parte de que la aplicación se tiene que hacer con componentes ya existentes, y desde el comienzo trata de buscar un equilibrio entre lo que hay y lo que se quiere obtener.
Lo que más nos interesa, y esto es lo que se plantea como línea de trabajo futuro, es unificar criterios y para ello vamos a dar el esbozo de lo que se podría plantear como una solución propia.
El proceso de Ingeniería del Software Basada en Componentes (CBSE) va a consistir en un desarrollo de componentes y una integración de componentes. Ambos procesos pueden ser hechos por separado y de forma concurrente, tal que por una parte, se trata de ver las características de los componentes que nosotros necesitamos, y por otro, investigar lo que ya hay hecho.
Al hacer el diseño del componente es cuando ambos procesos se podrían entrelazar pues tratarían de adaptar lo que necesitamos a lo que tenemos, y sino disponemos de ello, es cuando intentamos hacerlo nosotros. Esta etapa desembocaría en la integración o ensamblaje de los componentes seleccionados.
Con todo lo anterior ya tendríamos la implementación de la aplicación que queremos solucionar. Sobre esta aplicación luego haremos las pruebas, primero de integración entre componentes, y luego ya de todo el sistema.
Figura 1 – Proceso de CBSE
Esta nueva filosofía de procesamiento también dará lugar a nuevos roles, como ya se menciona en Componentware, como son las figuras del desarrollador de componentes (en la fase de análisis), del vendedor de componentes (en la adquisición de componentes) y el ensamblador de componentes, que selecciona los componentes que debemos adquirir en función de los diseñados por el desarrollador, y los ofrecidos por el vendedor, y luego los ensambla.
De la fase de ensamblaje o integración ya se ha investigado mucho más. Es en la fases previas de análisis y diseño de componentes, donde hay menos unanimidad y por eso precisamente, es en lo que nos vamos a centrar.
Como conclusión y solución propia, y aprovechando lo mejor de cada uno de los métodos vistos, podemos dividir el proceso de desarrollo en las siguientes fases:
1. Modelo del Proceso de Negocio.
Se trata de describir el contexto del sistema, par lo cual hay que describir los actores y objetos importantes, así como las relaciones y colaboraciones entre ellos.
Para lograrlo podemos usar, por una parte, los diagramas de secuencia y colaboración de UML, y como complemento, lo mismo pero expresado en forma de especificaciones de conversación y diálogo, como propone el método Orientado al Proceso.
Por otra parte, en esta primera fase también introduciremos las restricciones técnicas del sistema, lo que es el modelo de arquitectura técnica, del Modelo T.
Comparado con los métodos vistos, esta fase sería la combinación, o se correspondería con las siguientes fases de los métodos vistos.
- Modelo del Dominio (Catalysis).
- Especificación de conversaciones y diálogo (Método Orientado al Proceso) - Modelo de arquitectura (Modelo T)
- Modelo de casos de uso en la fachada del componente (Reutilización con UML)
2. Modelo de componentes.
Se trata de asociar las características anteriores, que serían los servicios del sistema, a componentes software, y a su vez agrupar estos servicios de cada componente en Interfaces.
Diseño Orientado a Componentes Adquisición de Componentes Análisis Pruebas de Integración Integración de Componentes Pruebas del Sistema
Aquí también convendría tener en cuenta lo ya existente, es decir, a la hora de diseñar los componentes tener en cuenta lo que se nos ofrece en el mercado, o incluso organizar los servicios, asociar servicios a interfaces, de forma que se satisfagan las necesidades de la aplicación, pero que también se pueda reutilizar lo que ya esta hecho.
En la práctica aquí usaríamos los diagramas de clases y estados de UML, y como resultado se obtendrían por ejemplo, los diagramas de despliegue y desarrollo, también de UML. Al diseñar estos componentes también tendremos en cuenta las técnicas del modelo detallado del Modelo T.
Esta fase equivaldría en los distintos métodos, a lo siguiente: - Modelado de componentes e interfaces (Catalysis).
- Asociación de componentes a las especificaciones de conversación y diálogo (Método Orientado al Proceso)
- Modelo detallado (Modelo T)
- Modelo de análisis de la fachada (Reutilización con UML)
3. Búsqueda e Integración de componentes.
Buscamos, usando las técnicas de Componentware, (ayudados por el nuevo rol del vendedor de componentes) lo que ya hay, y lo que no existe, lo hacemos.
Luego se trata de ensamblar todos los componentes (labor que realiza el ensamblador de componentes).
Para sintetizar todo lo visto primero mostraremos una tabla en la que comparamos el desarrollo tradicional de aplicaciones, con el desarrollo basado en componentes.
Desarrollo TRADICIONAL CBSE
Arquitectura Monolítica Modular
Componentes Implementación Interfaces
Proceso En Cascada Evolutivo y Concurrente
Metodología Se parte de la nada Composición o Ensamblaje
Organización Monolítica Especializada: desarrollador, vendedor y
ensamblador de componentes Tabla 1- Comparación del modelo de Desarrollo Tradicional con el Desarrollo Basado en
Componentes
Una vez vistas en la Tabla 1 las características comunes a cualquier desarrollo basado en componentes, vamos a comparar con otra tabla, los distintos métodos basados en componentes estudiados en este artículo, con la solución propia que nosotros hemos propuesto, quedando como tarea pendiente el refinar aún más esta solución.
Solución Propuesta Catalysis Modelo Orientado al Proceso Modelo T Reutilización con UML Componentware Modelo Proceso de Negocio Modelo de Dominio Especificaciones de Conversación y Diálogo Modelo de Arquitectura Casos de uso de la Fachada Modelo de Componentes Modelo de Componentes e Interfaces Asignación de Componentes a Especificaciones Modelo Detallado Diagrama de Clases e Implementación de la Fachada Búsqueda e Integración Integración de Componentes Tabla 2 – Comparación entre las Fases de Modelado en la solución propuesta y en los métodos
analizados.
Se trata en definitiva, de aprovechar lo mejor de cada modelo, Catalysis ofrece una buena organización, el Modelo T añade el tener en cuenta la parte técnica, el Modelo Orientado a Proceso facilita el entender las colaboraciones en el sistema y la “fachada” del método de Reutilización con UML, muestra en UML , todo lo anterior.
La aportación de este trabajo, es por tanto, el hacer un recorrido por algunos de los métodos de análisis y diseño con componentes existentes hoy en día. El problema es que hay mucho sobre implementación con componentes, pero muy poco, sobre las dos fases previas de análisis y diseño. El objetivo es pues tratar de dar procedimientos para estas fases y esto es lo que se pretende con la solución propia que se propone.
Esta solución o fases fundamentales del desarrollo que se proponen, pueden servir como punto de partida para una solución unificada, pero por supuesto, esta abierta a nuevas ideas y propuestas y habría que refinarla aún más, quedando esto como línea de investigación futura.
11. Referencias.
Ambler, Scott W. The Object-Oriented Modeling Process: Process Patterns for an
Architecture-Driven Approach. AmbySoft Inc., Junio 1998.
D.Ansorge, K. Bergner, B. Deiger, N.HawLitzky, C.Maier, B. Paech, A.Rausch, M.Shiling, V. Thurner, S. Vogel. Managing Componentware Development- Software Reuse and the
V-Modell Process. Fraunchofer Institute for Experimental Software Engineering of Germany,
1999
Len Bass, Paul Clements, Rick Kasman. Software Architecture in Practice. Addison Wesley, 1998
Devis Botella. RPP, Modelo de Roles. El método OOram, 17. Devis Botella. RPP, Especificación de requerimientos, 16.
Klaus Bergner, Andreas Rausch, Marc Sihling. Componentware- The Big Picture. International on Component-Based Software Engineering, 1998.
Klaus Bergner, Andreas Rausch, Marc Sihling. A Componentware methodology based on
Process Patterns. International on Component-Based Software Engineering, 1998
Klaus Bergner, Andreas Rausch, Marc Sihling. Putting the Parts Together- Concepts,
Descriptions Techniques and Development Process for Componentware. International on
Alan W. Brown. From Component Infrastructure to Component- Based Development. International on Component-Based Software Engineering, 1998.
Alan W. Brown, Kurt C. Wallnau. An Examination of the Current State of CBSE: A Report on
the ICSE Workshop on Component-Based Software Engineering. International on
Component-Based Software Engineering, 1998.
Philippe Kruchten. Modeling Component Systems with the Unified Modelling Language. International on Component-Based Software Engineering, 1998.
Dave Lewis, Chris Malbon, Alina DaCruz. Modelling Management Components for Reuse
Using. Department pf Computer Science, University College London, 1999
Pierre-Alain Muller. Modelado de objetos con UML. Gestión 2000, 1997.
Florian Mattes, Holm Wegner, Patrick Hupe. A Process- Oriented Approach to Software
Component Definition, Software Systems Institute (STS), 1999
Jim Q. Ning. CBSE Research at Andersen Consulting. International on Component-Based Software Engineering, 1998.
Robert Orfali, Dan Harkey, Jeri Edwrads. The Essential Distributed Objects Survival Guide. Jon Wiley & Sons, Inc., 1996
Robert Orfali, Dan Harkey, Jeri Edwrads. The Essential Client-Server Survival Guide, 2ª Edition. Jon Wiley & Sons, Inc., 1996
“ROSE Architect”, 1, 2 (1999) “ROSE Architect”, 2, 3 (2000)
Rumbaugh. Modelado y Diseño Orientado a Objetos. Prentice Hall, 1995.
R. Schmidt, U. Assmann. Concepts for Developing Component-Based Systems. International on Component-Based Software Engineering, 1998.
Douglas C. Schmidt. “Communications of the ACM”, Evaluating Architectures for
Multithreaded Object Request Brokers, 41, 10 (1998)
Siegel. CORBA: Fundamentals and programming. Jon Wiley & Sons, 1996.
Desmond D’Souza. Objects, Components and Frameworks with UML. The Catalysis Approach. Addison Wesley, 1999
Sterling. Component Based Development and Object Modeling. Sterling Software, 1999
Stefan Tai. A Connector Model for Object- Oriented Component Integration. International on Component-Based Software Engineering, 1998.
Antonio Vallecillo Moreno. Un Modelo de Componentes par el Desarrollo de Aplicaciones
Distribuidas. Tesis Doctoral. Málaga, 1999.
Steve Vinoski. “Communications of the ACM”, New Features for CORBA 3.0. 41, 10 (1998)
• Más información sobre CBSE en general y algunos de los métodos vistos, en particular, puede encontrarse en las siguientes direcciones web:
. http://www.cetus-links.org//oo_distributed_objects
. http://www.cool.sterling.com/cbd
. http://www.cs.ucl.ac.uk/research/flowthru/content/liaison.html
. http://www.iconcomp.com
. http://www.rational.com
. http://www.sei.cmu.edu/
