Adopción de un esquema de líneas de productos de Software en HBT. Carlos Andrés Parra Leonardo Giral. Heinsohn Business Technology

Transcripción

1 Agenda Adopción de un esquema de líneas de productos de Software en HBT Carlos Andrés Parra Leonardo Giral Heinsohn Business Technology Cámara de Comercio de Bogotá Centro Empresarial Chapinero

2 AGENDA 1. Contexto HBT Proyecto de Investigación 2. Líneas de Productos de Software Conceptos generales 3. SPL para Heinsohn 1. Ingeniería de Dominio 2. Ingeniería de Aplicación 4. Conclusiones y Perspectivas

4

5 Ventajas Competitivas Bajos Costos de Desarrollo Mayor productividad Reutilización de componentes Menores costos de mantenimiento Mayor Calidad Alta estandarización (la arquitectura se deriva del Framework) Uso de componentes probados Cultura de la Calidad Institucionalizada Talento Humano Más de 700 profesionales garantizan confianza y respaldo 80% del equipo humano dedicado a investigación y desarrollo 280 certificaciones El beneficio implícito de esta filosofía, se ve reflejado frente a nuestros clientes en entendimiento, cumplimiento y atención de cada una de sus necesidades

6 Ventajas Competitivas 80% 02/27/ Slide 3

7 Ventajas Competitivas Menor tiempo de salida al mercado Desarrollo de software con los últimos estándares de tecnología de la industria. Desarrollo de software con herramientas de código abierto. Amplia experiencia en proyectos SOA, Java y.net Experiencia en todos los sectores de la industria: Financiero, Industria y Comercio, Salud y Gobierno. Contamos con fuertes alianzas con algunas de las mejores universidades del país: - Programas de intercambio de estudiantes. - Proyectos conjuntos de investigación. - Comités para investigación de nuevas tecnologías

8 Partners de Negocios

9 Tecnología Custom Software Development Cloud Computing SOA / BPM Solutions Component Development Java CAPS

10 Clientes Principales Technología Financiero Ventas y Manofactura Gobierno

12 SPL para HBT Proyecto de investigación aplicada 3 años (actualmente, en el segundo año) Financiación gubernamental (Colciencias) Abarca tres frentes de trabajo Frente Tecnológico Diseño e implementación Frente Metodológico Adaptación a los procesos de desarrollo Frente Científico Divulgación de resultados

14 SPL - Historia Mass Production... Henry Ford y el modelo T,

15 SPL - Historia Producción en masa Construcción de productos a partir del ensamblaje de piezas fabricadas a mayor velocidad Menor tiempo de construcción Optimización de los recursos Menor costo You can have it any color you want, so long as it s black

16 SPL - Historia Create your own personalized Starbucks drink. With over 87,000 combinations, the possibilities are endless Personalización en masa 16

17 Líneas de Productos de Software Personalización en Masa Mantener la eficiencia de la producción en serie Obtener productos diferentes a partir de: Muchos elementos comunes Ciertos elementos diferentes Cada cliente configura el producto que mejor se adapte a sus necesidades Activos base, y activos de personalización Diseño modular Variabilidad!

18 Líneas de Producto de Software (SPL) Variabilidad - Modelos de Features Feature Diagram (Model) Presentado por Kang et. al. en 1990 como parte FODA (Feature Oriented Domain Analysis) Es una forma de representar la variabilidad utilizando un árbol de características con relaciones and/or y restricciones Cada Feature representa una funcionalidad o elemento del sistema que se quiere modelar de manera independiente. Existe una jerarquía descendente en la que a partir de una raíz, se definen múltiples características hasta llegar a las hojas del árbol (último nivel)

19 Líneas de Producto de Software (SPL) Variabilidad - Modelos de Features Notación inicial propuesta por Kang et. al. en 1990

20 Líneas de Producto de Software (SPL) Variabilidad - Modelos de Features Notación estándar

21 Líneas de Producto de Software (SPL) Semántica de un FM (2) (2^1) Cuántos productos hay? (2) * (2^1)* (2^2-1) = 12 (2^2-1) {MP, Print, Laser, Scan, Connection, USB}, {MP, Print, Inkjet, Scan, Fax, Connection, USB, Ethernet}, {MP, Print, Inkjet, Scan, Connection, USB}, {MP, Print, Laser, Scan, Fax, Connection, USB, Ethernet}, {MP, Print, Inkjet, Scan, Connection, Ethernet}, {MP, Print, Laser, Scan, Fax, Connection, Ethernet}, {MP, Print, Laser, Scan, Connection, Ethernet}, {MP, Print, Inkjet, Scan, Fax, Connection, Ethernet}, {MP, Print, Inkjet, Scan, Fax, Connection, USB}, {MP, Print, Inkjet, Scan, Connection, USB, Ethernet}, {MP, Print, Laser, Scan, Fax, Connection, USB}, {MP, Print, Laser, Scan, Connection, USB, Ethernet}

22 Líneas de Producto de Software (SPL) Semántica de un FM Un producto legal (respeta todas las restricciones): {MP, Print, Laser, Scan, Connection, USB}

23 Líneas de Producto de Software (SPL) Semántica de un FM Un producto ilegal: {MP, Print, Laser, Fax, Connection}

24 Líneas de Productos Activos Configuración Familia de productos

25 Líneas de Productos de Software Evitar gastar tiempo y dinero solucionando el mismo problema n veces Abaratar los costos de desarrollo Minimizar el tiempo de desarrollo Mejorar la calidad del software Reutilizar componentes a través de diferentes productos

26 Lineas de Productos de Software (SPL) Beneficios esperados

27 Líneas de productos de Software Procesos Ingeniería de Dominio Análisis de variabilidad Alcance de la línea (familia de productos) Desarrollo de activos Ingeniería de Aplicación Configuración de productos Derivación de productos

28 Líneas de productos de Software Estrategias de Adopción [Kreuger 2001] Extractiva La organización usa los artefactos de software existentes, identificando elementos en común y variables para construir la familia de productos Reactiva Crecimiento incremental hacia la personalización en masa. Se utilizan los activos actuales, pero a la vez, se desarrollan nuevos activos para su integración y reutilización en diferentes productos. Proactiva Análisis, diseño e implementación de los activos de la línea, para personalización en masa de todos los productos de software previstos para el futuro

29 Líneas de productos de Software Estrategias de Adopción [Kreuger 2001]

31 Por qué una SPL en HBT? Conocimiento de los activos actuales Separación de funcionalidades comunes a varios proyectos para su reutilización Facilidad en el diseño y desarrollo de nuevos productos Arquitectura de integración para incorporar nuevos activos (internos o externos) Desarrollo de productos en los cuales HBT es experto, a partir de activos ya desarrollados Liderazgo en Colombia en el desarrollo de software con SPL Transferencia de conocimientos (Investigación Aplicada) Uso de tecnologías de punta con poca aplicación en Latinoamérica

32 Estrategia inicial extractiva para HBT Estrategia inicial extractiva para HBT Componentes de Negocio Análisis de Variabilidad Familia HBT

33 Esquema General HBT SPL 33

34 Variabilidad en HBT Tres niveles de variabilidad Nivel de negocio Elementos propios de cada vertical de negocio Nivel de Framework Funcionalidades comunes a diferentes negocios Nivel de plataforma Requerimientos a nivel de plataforma Servidores de aplicación Bases de datos Frameworks y librerías Sistema operativo

35 Variabilidad Negocio

36 Variabilidad Framework de Lion

37 Variabilidad Plataforma

38 Variabilidad Resultados Analysis Result Valid Configurations YES e11 Core features 19 Variant features 61 ECR

40 Esquema General Ingeniería de Dominio HBTSPL Business Framework Platform Refinamiento de Variabilidad Ingeniería Inversa Activos configuración Derivación de productos Ingeniería de Aplicación Software Artefactos Artifacts Framework Framework Lion Products Productos 40

41 Ingeniería de Dominio Refinamiento de variabilidad para HBT Creación de características para los artefactos actuales Creación de restricciones entre las características de los niveles existentes y el nuevo nivel de plataforma Mantener actualizada la información referente a las implementaciones actuales de cada artefacto Proveer una conexión directa con los activos de software identificados en el modelo de arquitectura

42 Ingeniería Inversa Definición de esquema xml para los modelos de FeatureIDE Generación del sub-árbol a partir de las anotaciones 42

43 Ingeniería Inversa Construir activos para la línea de productos Utilizar los componentes actuales (estrategia extractiva) Respetar una arquitectura que permita la combinación de múltiples características del árbol de variabilidad Un activo es un componente definido en la arquitectura Identificación clara de los servicios ofrecidos Identificación clara de las referencias requeridas Comunicación y ensamblaje a través de contratos Incluir la idea de actividad o proceso Evitar las modificaciones al código actual 43

44 Ingeniería de Dominio Metamodelo de Arquitectura 44

45 Ingeniería de Dominio Esquema de Transformaciones Generación del modelo genérico hbtarch conforme al metamodelo aspect.xmi en el que se describen los servicios y sus dependencias. 45

46 Ingeniería de Dominio Anotaciones Anota las interfaces que exponen los servicios de cada componente package annotation; Feature { String featurename(); String implementation() default ""; //WS, REST, EJB } 46

47 Ingeniería de Dominio Anotaciones Interfaz = "TaskManager_LF ) public interface TaskManager { = "TaskManager_LF ) public void createtask(long idtasktemplate, Long iduser, Long identityenterprise, Map<String, String> params) throws TadkManagerException; //.. } 47

48 Ingeniería de Dominio Anotaciones Anota los métodos que hagan invocaciones a otros componentes package annotation; Requires { String providedfeaturename(); String requiredfeaturename(); String interfacename() default ""; } 48

49 Ingeniería de Dominio Refinamiento de Variabilidad Método anotado public class TaskManagerImpl{ protected InjectedClass requiredfeaturename="notification_lf", providedfeaturename= TaskManager_LF interfacename="injectedclass ) public void mymethodone(string myparameter) { // attr3.methodtwo(); // } 49

50 Ingeniería Inversa Spoon Diagrama tomado de: Spoon program analysis and transformation in java, Renaud Pawlak, Carlos Noguera, Nicolas Petitprez

51 Ingeniería Inversa Spoon Spoon permite efectuar cambios sobre los elementos analizados por medio de la clase Factory. Tomado de: Spoon program analysis and transformation in java, Renaud Pawlak, Carlos Noguera, Nicolas Petitprez

53 Ingeniería de Aplicación XXXIII Salón de Informática ACIS Esquema General HBT SPL HBTSPL Business Framework Platform Ingeniería de Dominio Refinamiento de Variabilidad Ingeniería Inversa Activos Configuración Derivación de productos Software Artefactos Artifacts Framework Framework Lion Products Productos 53

54 Ingeniería de Aplicación Generación de Wrappers Objetivos Utilizar la información del árbol de variabilidad (Plataforma) para personalizar los componentes Automatizar la instalación del producto Utilizar el manejo de archivos fuente y versiones basado en Maven 54

55 Ingeniería de Aplicación Generación de Wrappers 55

56 Ingeniería de Aplicación Generación de Wrappers En base al modelo genérico hbtarch se construyen los wrappers. Modelo de Variabilidad Configuración Componente 1 Componente 2 Componente 3... Creación de modelos Basada en Derivación Modelo de Arquitectura Conforme a Modelo de Producto Generación de Wrappers Servidor (WS, REST, EJB) Generación de Código Generación de Contratos (WSDL, JAXB) Generación de Wrappers Cliente (WS, REST, EJB) Modificación de Código original y despliegue 56

58 Conclusiones 1. Análisis variabilidad con base en artefactos reutilizables disponibles 2. Implementación de una SPL a través de una estrategia extractiva reactiva 3. Definición de modelo de arquitectura para un activo HBT. 4. Dos procesos para la implementación 1. Ingeniería de Dominio: ingeniería inversa para la construcción de activos 2. Ingeniería de Aplicación: derivación de productos basada en generación de wrappers y ensamblaje en WS, REST, y EJB 58

59 Perspectivas de Negocio 1. Estudiar el diseño de procesos de negocio a partir de combinaciones de características 2. Construir sub-familias para sectores de negocio específicos 3. Repetir análisis de variabilidad incluyendo componentes no implementados para dar prioridad a los componentes más importantes 4. Incluir nuevas características de negocio 59

60 Gracias! 60

61 Bibliografía SPL-HBT Carlos Parra, Leonardo Giral, Alvaro Infante, Camilo Cortés. Extractive SPL adoption using multi-level variability modeling. MAPLE workshop, in Proceedings of the 16th International Software Product Line Conference, Volume 2 (SPLC 12). Salvador, Brazil, September Carlos Parra, Alvaro Infante, Diego Joya, Leonardo Giral. Reverse engineering of enterprise applications for SPL adoption, an industrial experience. Under submission for the ACM Symposium on Applied Computing. VARIABILITY - ANALYSIS Automated analysis of feature models 20 years later: A literature review. D. Benavides, S. Segura, and A. Ruiz- Cortés. Inf. Syst., 35(6): , Sept Feature-oriented domain analysis (foda) feasibility study. K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson. Technical report, Carnegie-Mellon University Software Engineering Institute, November ADOPTION Easing the transition to software mass customization. C. W. Krueger. In Revised Papers from the 4th International Workshop on Software Product-Family Engineering, PFE 01, pages , London, UK, UK, Springer-Verlag. TOOLS A tool framework for feature-oriented software development. C. Kastner, T. Thum, G. Saake, J. Feigenspan,T. Leich, F. Wielgorz, and S. Apel. Featureide: In Proceedings of the 31st International Conference on Software Engineering, ICSE 09, pages ,