4.5 Prognostic Redesign Approach (ProRed) :
4.5.2 ProRed Algorithm :
El desarrollo de software basado en componentes tiene como objeto producir sistemas escalables de software a través de la reutilización explicita de componentes construidos para tal fin. En este contexto, el desarrollo de software basado en componentes resume sus propósitos bajo ciertos conceptos, principalmente el de componente. Un componente es una unidad reutilizable de despliegue y de composición. Una opinión común es que un componente está estrechamente relacionado con un objeto y que el CBSD es por lo tanto, una extensión del desarrollo orientado a objetos (CRNKOVIC, y otros, 2002).
2.6.2.2 Modelo de la propuesta CBSD
El desarrollo de software basado en componentes forma parte de una sólida propuesta teórica conocida con el nombre de Ingeniería de Componentes. La Ingeniería de Componentes por definición es un enfoque de desarrollo de software basado en reutilización (SAMETINGER, 2010). La reutilización sistemática requiere de una base de componentes de alta calidad con la documentación adecuada. Dichos componentes no pueden ser simplemente extraídos de las aplicaciones existentes; de hecho, la obtención de componentes reutilizables requiere más esfuerzo ya que dichos componentes debieron haber sido diseñados generalmente para necesidades especiales.
Teniendo en cuenta la inclinación marcada hacia la fase de diseño e implementación, el desarrollo de software basado en componentes ha plasmado su filosofía en estándares de la industria. Es por tal razón que hoy por hoy, se hablan de modelos de desarrollo de software basado en componentes a la luz de CORBA (propuesto por OMG), EJB (propuesto por Oracle, antiguamente por Sun Microsystems) y DCOM/COM+ (propuesto por Microsoft), entre otros.
Todos los modelos anteriores se basan en la abstracción general de la propuesta la cual integra los grandes conceptos de componentes, interfaces, contratos, patrones y frameworks.
Esto quiere decir que se requiere una metodología para la construcción de componentes, para su validación, pruebas y control de calidad, y de unos mecanismos de distribución de componentes a través de repositorios de donde dichos elementos puedan ser consumidos. Con esto se evidencia la naturaleza del modelo hacia ambientes de reutilización explicita.
49
2.6.2.3 Activos de la propuesta CBSD
Los activos de la propuesta CBSD son: modelo de requisitos, bibliotecas de componentes, modelo de diseño, modelo de implementación, esquema de datos, sistema integrado y componentes, modelo de despliegue, casos de prueba, documento del entorno de configuración y documentación de soporte y mantenimiento
Teniendo en cuenta que el CBSD profundiza su quehacer en el aspecto de implementación, los activos generados a través de su ciclo son supremamente puntuales en cuanto a nomenclatura. La documentación que generan 4 actores (el diseñador, el arquitecto, el desarrollador y el administrador) son establecidas directamente como activos escritos en UML
2.6.2.4 Proceso de la propuesta CBSD
El desarrollo de software basado en componentes reinterpreta el concepto de ciclo de vida para desarrollar pequeñas iteraciones en cuanto a la secuencialidad de las fases. Como lo muestra Sametinger, los procesos de la propuesta de CBSD van de la mano con los procesos propios de la ingeniería de dominio. Es aquí donde el desarrollo de software basado en componentes se relaciona estrechamente con el análisis de dominio y sus especificaciones:
Figura 5. Ciclo de vida de CBSD integrado con ingeniería de dominio
Fuente: (SAMETINGER, 2010)
A partir de la figura 6, se puede evidenciar que el concepto de componentes reutilizables es generado a través del análisis del dominio. Es aquí donde los activos de software deben ser filtrados a través del escenario de Generalización de Componentes (ajustarlo a lineamientos industriales) a fin de tener éxito en la construcción de aplicación usando componentes específicos.
Finalmente, el desarrollo de software basado en componentes, interactúa con la reutilización en los siguientes niveles de ciclo de vida clásico.
50
Esto indica que el ciclo de vida de desarrollo necesariamente asocia elementos de evaluación para la obtención de componentes existes. Otra evidencia de que la reutilización es un factor natural de la propuesta.
2.6.2.5 Orientación hacia la reutilización y el trabajo con catálogos en la propuesta CBSD
La reutilización debe ser vista como una parte integral del ciclo de vida del software sobre todo bajo una orientación basada en componentes. En el enfoque tradicional de reutilización, es común buscar los componentes necesarios después de que la mayor parte del trabajo de diseño se ha hecho. En lugar de esperar hasta que el diseño se haga (y luego se busca en vano los componentes a integrar), los productos de software deben ser diseñados en torno a los componentes de software disponibles. En este sentido el Desarrollo de Software basado en componentes tiene una alta inclinación hacia las estrategias de reutilización, especialmente en su fase de implementación.
De acuerdo con (SAMETINGER, 2010), las fases del ciclo de vida del desarrollo de software basado en componentes involucra aspectos de reutilización por cada transición. La figura 6 muestra como dichas transiciones re-toman activos prediseñados, en este caso componentes de software.
Figura 6. CBSD con reutilización
Fuente: (SAMETINGER, 2010)
Según lo anterior, el modelo de la propuesta CBSD se enfoca hacia 5 grandes escenarios de acción:
Desarrollo de Componentes: Metodologías asociadas a la fase de diseño e implementación de los componentes como tales.
La Generalización de Componentes: Ajuste a lineamientos de la industria (tales como CORBA, EJB, COM+, entre otros)
51
La Certificación de Componentes: Filtro donde se hace una medición de calidad de los componentes a ser reutilizados. Se siguen pruebas prediseñadas para los componentes construidos.
El uso de Repositorios de Componentes: se establecen lugares donde residen los componentes reutilizables, estos pueden ser: repositorios locales, repositorios de dominio especifico, y repositorios de referencia.
La Clasificación de Componentes: Varios aspectos son considerados en cuanto a clasificación de componentes. Entre ellos están: Clasificación por función, por objeto, por medio, áreas funcionales, configuraciones, etc.
2.6.3 Feature Oriented Domain Analysis (FODA)