Desarrollo del módulo PSM CODIGO versión 3 0 de la herramienta JMDA

Texto completo

(1)UNIVERSIDAD CENTRAL “MARTA ABREU” DE LAS VILLAS FACULTAD MATEMÁTICA FÍSICA Y COMPUTACIÓN Licenciatura en Ciencia de la Computación. TRABAJO DE DIPLOMA Desarrollo del módulo PSM-CODIGO versión 3.0 de la herramienta JMDA. AUTOR: ELVIS HERNÁNDEZ HERNÁNDEZ TUTOR: DR. ROSENDO MORENO RODRÍGUEZ. SANTA CLARA 2017.

(2) El que suscribe _Elvis Hernández Hernández_, hago constar que el trabajo titulado “Desarrollo del módulo PSM-CODIGO versión 3.0 de la herramienta JMDA” fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de los estudios de la especialidad de __Ciencias de la Computación_, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.. ______________________ Firma del Autor. Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. ____________________________ Firma del Tutor: Dr. Rosendo Moreno Rodríguez.

(3) Dedicatoria Dedicatoria. A mis padres y abuelos, en especial a mi abuelo Raúl por ser lo más que quiero, por su ayuda y apoyo incondicional, por su esfuerzo durante todos estos años para que pudiera estudiar y graduarme. A mis compañeros de universidad y a toda mi familia por hacer posible la realización de este sueño.. I.

(4) Agradecimientos Agradecimientos. Quisiera agradecer a todos los que de una forma u otra han hecho posible la realización de este trabajo. A mis padres y abuelos y hermanos por la guía y el tesón. A mi tutor Rosendo, por su orientación y ayuda brindada. A mis amigos, con los cuales he pasado estos largos 5 años, por pasar momentos difíciles y gratos, por aguantarme. A los viejos amigos, que siempre han estado junto a mí.. II.

(5) Resumen Resumen La Industria Nacional del Software necesita de herramientas que permitan incrementar la productividad, portabilidad, mantenibilidad y calidad en la producción de este esencial producto en el mundo actual. Muchas de estas herramientas se conocen como Ingeniería del Software Asistida por Computadoras y existen tanto propietarias como de código abierto. Pero lo cierto es que lo mejor fuese tenerlas propias, para que incidan en el desarrollo de Cuba. En los últimos años el Grupo de Dirección de la Orientación a Objetos estandarizó el marco de trabajo Arquitectura Dirigida por Modelos que fundamenta la existencia de cuatro etapas en el desarrollo del software basadas en el modelado del análisis y diseño fundamentalmente con Lenguaje Unificado de Modelado, así como las transformaciones automáticas entre cada una y la que le sigue. Las herramientas consideradas de este tipo tampoco son soberanas, y ni siquiera completas. En el Centro de Estudios de Informática de la UCLV se fundamentó un Proyecto de Investigación que tenía como tarea esencial crear una herramienta propia que implementara dicha arquitectura (JMDA) dividida en las 3 transformaciones esenciales. El presente trabajo se corresponde a la tercera versión de la transformación del Modelo Específico de Plataforma a código fuente Java. En esta versión se hizo énfasis en tener un ambiente gráfico adecuado para la modelación e importación de los modelos específicos de la plataforma, ya sea generados automáticamente como resultado de otro trabajo de diploma que abarca la transformación PIM-PSM de la propia herramienta JMDA o por esta versión, y establecer principios adecuados de generación del código fuente.. III.

(6) Abstract Abstract The National Software Industry needs tools to increase productivity, portability, maintainability and quality in the production of this essential product in today's world. Many of these tools are known as Computer Assisted Software Engineering and exist both proprietary and open source. But the truth is that it is best to have their own, so that they influence the development of Cuba. In recent years, the Object Orientation Steering Group has standardized the Model-Driven Architecture framework that supports the existence of four stages in software development based on modeling analysis and design primarily with Unified Modeling Language Like the automatic transformations between each one and the one that follows. The tools considered of this type are also not sovereign, nor even complete. In the Center of Studies of Computer science of the UCLV was based a Research Project that had as essential task to create a own tool that would implement said architecture (JMDA) divided in the 3 essential transformations. The present work corresponds to the third version of the transformation of the Specific Model of Platform to Java source code. In this version, emphasis was placed on having a suitable graphical environment for the modeling and import of the platform-specific models, either automatically generated as a result of another diploma work involving the PIM-PSM transformation of the JMDA tool itself or This version, and establish proper principles of source code generation.. IV.

(7) Tabla de Contenidos Contenido Introducción .................................................................................................................................. 1 Capítulo 1. Antecedentes y Fundamentación Teórica ................................................................... 5 1.1 Antecedentes ....................................................................................................................... 5 1.2 UML y Procesos de Desarrollo de Software ...................................................................... 6 1.3 Arquitectura Dirigida por Modelos ................................................................................... 6 1.3.1 ¿Qué es MDA? ............................................................................................................. 7 1.3.2 Modelos en MDA ......................................................................................................... 7 1.3.3 Transformaciones de Modelos..................................................................................... 9 1.3.4 Ventajas del MDA...................................................................................................... 15 1.3.5 Desventajas del MDA ................................................................................................ 16 1.4 Herramientas Case ........................................................................................................... 16 1.4.1 Caracterización de herramientas CASE más utilizadas ........................................... 17 1.4.2 Herramientas CASE que implementan la aproximación MDA ............................... 17 1.5 ¿Por qué una herramienta propia?.................................................................................. 19 1.6 Análisis de lenguajes de programación más usados actualmente ................................... 22 1.6.1 Java ............................................................................................................................. 23 1.6.2 Python ......................................................................................................................... 27 1.7 Análisis crítico de la Herramienta JMDA v2.0 PSM-Código.......................................... 28 1.7.1 Funcionalidades que deben incorporarse a la nueva versión de la herramienta JMDA v3.0 PSM-Código .................................................................................................................. 29 1.8 Conclusiones del capítulo ................................................................................................. 29 Capítulo 2. Aspectos del análisis, diseño e implementación........................................................ 30 2.1 Herramientas utilizadas para la implementación de la versión 3.0 de JMDA PSMCódigo..................................................................................................................................... 30 2.1.1 Entorno de desarrollo empleado ............................................................................... 30 2.1.2 Lenguaje de implementación ..................................................................................... 30 2.1.3 Bibliotecas utilizadas ................................................................................................. 31 2.2 Casos de Uso y Actores de la Herramienta JMDA versión 3.0 ....................................... 33 2.3 Diagrama de clases del diseño .......................................................................................... 35 2.4 Diagrama de Actividades ................................................................................................. 36 2.5 Estructura de la Plantilla para la generación de código java utilizando StringTemplate ................................................................................................................................................ 38 2.5.1 Definición de plantillas .............................................................................................. 38 V.

(8) Tabla de Contenidos 2.5.2 Plantillas definidas para la generación de código java ............................................. 39 2.6 Algoritmo de transformación. Definición y reglas ....................................................... 40 2.6.1 Algoritmo de transformación utilizado ..................................................................... 42 2.7 Conclusiones del capítulo ................................................................................................. 43 Capítulo 3. Descripción de la solución propuesta ........................................................................ 44 3.1 Descripción de la herramienta ......................................................................................... 44 3.1.1 Barra de Menú ........................................................................................................... 44 3.1.2 Botones Adicionales ................................................................................................... 48 3.1.3 Panel de Diagramas ................................................................................................... 49 3.1.4 Panel Componentes ................................................................................................... 50 3.2 Ejemplo de uso de la herramienta ................................................................................... 50 3.2.1.. Problemática ....................................................................................................... 50. 3.2.2.. Diagrama de Casos de Usos de la Empresa ........................................................ 51. 3.2.3.. Diagrama de Actividades para el caso de Uso Renovar Contrato ..................... 51. 3.2.4.. Diagrama de Actividades para el caso de Uso Crear Contrato ......................... 52. 3.2.5.. Diagrama de Actividades para el caso de Uso Cerrar Contrato ........................ 52. 3.2.6.. Diagrama de Actividades para la operación Pedir Baja .................................... 53. 3.2.7.. Diagrama de Clases de la problemática planteada ............................................ 53. 3.2.8.. Comparación de Código...................................................................................... 53. 3.3 Conclusiones del capítulo ................................................................................................. 55 Conclusiones ............................................................................................................................... 56 Recomendaciones ....................................................................................................................... 57 Referencias bibliográficas............................................................................................................ 58.

(9) Lista de Figuras. Lista de Figuras Figura 1 La transformación en el proceso MDA ........................................................................... 10 Figura 2 Proceso de transformación en MDA............................................................................... 14 Figura 3 Diagrama de Casos de Usos y Actores ............................................................................. 34 Figura 4 Diagrama de Clases del diseño ........................................................................................ 35 Figura 5 Diagrama de Actividades para el caso de uso exportar diagramas ................................... 36 Figura 6 Diagrama de Actividades para el caso de uso guardar código .......................................... 37 Figura 7 Diagrama de Actividades para el caso de uso crear diagrama .......................................... 37 Figura 8 Diagrama de Actividades para el caso de uso cargar diagrama ........................................ 38 Figura 9 Algoritmo de transformación PSM-Código ...................................................................... 42 Figura 10 Opción cargar diagrama del menú Archivo.................................................................... 45 Figura 11 Opción exportar diagrama del menú Archivo ................................................................ 46 Figura 12 Opción nuevo diagrama del menú Archivo .................................................................... 46 Figura 13 Menú Editar.................................................................................................................. 47 Figura 14 Menú Ver ..................................................................................................................... 47 Figura 15 Menú Formatos ............................................................................................................ 48 Figura 16 Menú Formas ............................................................................................................... 48 Figura 17 Botones adicionales ...................................................................................................... 49 Figura 18 Panel de diagramas....................................................................................................... 49 Figura 19 Panel de componentes ................................................................................................. 50 Figura 20 Diagrama de Casos de Usos y Actores de la problemática ............................................. 51 Figura 21 Diagrama de Actividades para el caso de uso renovar contrato ..................................... 51 Figura 22 Diagrama de Actividades para el caso de uso crear contrato ......................................... 52 Figura 23 Diagrama de Actividades para el caso de uso cerrar contrato........................................ 52 Figura 24 Diagrama de Actividades para la operación pedir baja .................................................. 53 Figura 25 Diagrama de Clases de la problemática ......................................................................... 53. VII.

(10) Introducción INTRODUCCIÓN La Informática no es más que la ciencia aplicada que abarca el estudio y aplicación del tratamiento automático de la información (Peña, 2011), la general utilización por parte de la humanidad de estos avances ha propiciado la disposición de una gran cantidad de recursos humanos y materiales al desarrollo de la industria de la informatización, contribuyendo a la rápida adquisición de conocimientos y de nuevos valores, desatando a un ritmo continuo e impredecible significativas transformaciones económicas, sociales, culturales e incluso dominando en gran medida nuestra forma de vida. Por lo que la evolución acelerada y la afirmación de la industria software como una forma de economía bastante soluble, no constituyen una sorpresa. Consecuentemente con la necesidad de encontrar soluciones para obtener productos de calidad de modo rentable y fiable surgen métodos y técnicas para desarrollar y mantener aplicaciones, este conjunto de enfoques se conoce como Ingeniería de Software (Sommerville, 2005). Brindando soporte a la utilización de dichos principios aparecen las Herramientas CASE (acrónimo en inglés de “Computer Aided Software Engineering”, Ingeniería de Software Asistida por Computadora), apoyando en tareas como el diseño del proyecto, implementación de parte del código y la documentación asociada a la implementación. El modelado es una parte central de todas las actividades que conducen a la producción de buen software, ya que a través del modelado se consigue visualizar, especificar (estructura y comportamiento de un artefacto), proporcionar plantillas que sean una guía en la construcción del sistema y documentación de las decisiones adoptadas por los desarrolladores. El UML (“Unified Modeling Language”, Lenguaje Unificado de Modelado) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad (Cueva, 1999); está respaldado por el OMG (“Object Management Group”). Los modelos proveen abstracciones de un sistema físico que permiten a los ingenieros analizar el sistema ignorando detalles complejos mientras se enfocan en las partes más relevantes, como puede ser la lógica del negocio. MDA (acrónimo en inglés de “Model Driven Architecture”, Arquitectura Dirigida por Modelos), es una arquitectura que. 1.

(11) Introducción proporciona un conjunto de guías para estructurar especificaciones expresadas como modelos. Conduce al desarrollador a la construcción progresiva de las transformaciones de modelos, separando el diseño de la arquitectura brindando un alto nivel de abstracción, permitiendo que el diseño y la arquitectura sean modificados independientemente. La evolución consecuente de los modelos a distintos niveles de abstracción nos conduce hasta un modelo con detalles específicos de la plataforma, PSM (“Plataform Specific Model”, Modelo Específico de la Plataforma), el cual es cercano a la solución del problema, por tal modelo siguiendo la lógica de transformación se podrá producir el código fuente (Kleppe, 2005). Las aplicaciones construidas en la actualidad deben de diseñarse para soportar distintas situaciones independientes de los aspectos funcionales, permitiendo además la reutilización, modificación y la documentación de las mismas. Ya han sido muchas las plataformas diferentes y demasiadas las necesidades contradictorias, y se hace muy difícil para los desarrolladores acceder a una solución común. Por tanto, un guion más realista es habilitar la coexistencia de los sistemas presentes representándolos por los modelos y transformando estos modelos en otros. MDA en realidad intenta proporcionar una solución al problema de tal integración. Aunque el marco arquitectónico de OMG está en constante cambio, la idea fundamental es lograr en ambas interoperabilidad y portabilidad. Continuamente con la evolución de plataformas de desarrollo y la creación de nuevos estándares, la diversificación de herramientas CASE ha tomado lugar, surgiendo al mercado disimiles herramientas como: Rational Rose, Visual Paradigm, herramientas tradicionales propietarias y otras que se adhieren al paradigma MDA como son OptimalJ, AndroMDA e IBM RSA. La UCLV (Universidad Central “Marta Abreu” de las Villas) es una institución que está estrechamente vinculada con el desarrollo de software soberano o nacional, y en dicha entidad como en muchas otras de nuestro país, es necesaria la utilización de programas que permitan visualizar los diferentes diagramas y generar el código fuente, con el objetivo de ganar productividad y calidad en el desarrollo de software. Para aplicar a un marco de trabajo que garantice la especificación completa de un sistema en base a modelos independientes y. 2.

(12) Introducción específicos de una plataforma y tecnología que permitan desarrollar en un ámbito tan cambiante y complejo productos con la calidad y la productividad requeridas. Planteamiento del Problema: El desarrollo de la industria del software en nuestro país pasa por la existencia de herramientas CASE soberanas en base a la Arquitectura Dirigida por Modelos. El principio de desarrollo de software utilizando dicha arquitectura facilitaría la productividad, agilizando el análisis y diseño de los mismos, así como su implementación. El Software resultante podría ser copiado, mejorado y distribuido libremente por las instituciones cubanas de desarrollo de software. Este fue el planteamiento general del proyecto de investigación asociado, recientemente cerrado pero que solo logró anteriormente a partir de una tesis de grado una versión prototípica que todavía carece de varias funcionalidades. Este trabajo pretende solventar esas deficiencias brindando una herramienta CASE más sólida. Problema tecnológico: La Industria Cubana de software tiene necesidad de contar con una herramienta soberana bajo la base de la Arquitectura Dirigida por Modelos que cumpla con los paradigmas de desarrollo actual. Objetivo General: Implementar la versión 3.0 del módulo PSM-Código de la herramienta JMDA, que supere los errores que presenta la versión anterior, con una nueva interfaz de modelado PSM, con prestaciones gráficas adecuadas, así como la lógica de la transformación a código fuente en lenguaje Java. Objetivos específicos: 1. Realizar un análisis crítico de la versión anterior a la par del estado del arte correspondiente. 2. Crear el módulo gráfico de la herramienta para la edición directa o a través de la importación a un ambiente PSM, de los diagramas UML esenciales para la generación automática de código fuente, con las funcionalidades adecuadas y. 3.

(13) Introducción normales en este tipo de herramientas, incluyendo la entrada y salida (grabación) en los formatos PNG, JPG, MXE. 3. Implementar el módulo que permita la transformación de forma automática de los diagramas creados o mejorados en modelo específico de plataforma (PSM) a código fuente en lenguaje Java, teniendo en cuenta una lógica estándar adecuada. Preguntas de Investigación: 1. ¿Por qué es realmente importante para la Industria Nacional de Software contar con una herramienta que permita aplicar la ingeniería directa generando programas a partir de modelos UML? 2. ¿Cómo desarrollar una herramienta CASE que tenga el ambiente adecuado para captar o crear modelos PSM y ayude a su completamiento y luego la generación automática de programas Java? 3. ¿Cuáles bibliotecas y manipuladores ya desarrollados apoyan este trabajo? El presente trabajo se encuentra estructurado en los siguientes tres capítulos: Capítulo 1: Este Capítulo aborda el estado teórico en que se encuentra en la actualidad el marco de trabajo MDA, se plasman las principales características de algunas de las herramientas que utilicen dicha tecnología, haciendo hincapié en la generación de código fuente. Se hace una exposición de las principales características de los lenguajes de programación Java y Python; además, se argumenta la necesidad de implementar una herramienta propia. Capítulo 2: El capítulo 2 afronta los detalles acerca de la implementación del módulo PSMCódigo de la herramienta jMDA referentes a la generación de código. El proceso propuesto como solución a la problemática planteada en la introducción de esta tesis se expondrá mediante el uso del Lenguaje Unificado de Modelado para mostrar los aspectos funcionales, estructurales y de comportamiento. Capítulo 3: En este capítulo se desarrolla la descripción de la solución propuesta donde se resaltan las soluciones algorítmicas y computacionales de la presente versión de la herramienta.. 4.

(14) Capitulo1 CAPÍTULO 1. ANTECEDENTES Y FUNDAMENTACIÓN TEÓRICA Este Capítulo aborda el estado teórico en que se encuentra en la actualidad el marco de trabajo MDA, se plasman las principales características de algunas de las herramientas que utilicen dicha tecnología, haciendo hincapié en la generación de código fuente, ya que el mismo es el módulo a implementar en el presente trabajo. Se hace una exposición de las principales características de los lenguajes de programación Java y Python con el objetivo de incrementar y profundizar el conocimiento a la hora de la generación del código fuente; además, se argumenta la necesidad de implementar una herramienta propia.. 1.1 Antecedentes El presente trabajo tiene como antecedente la versión 2.0 del software jMDA en el año 2011, diseñado para la obtención automática de código a partir del modelado UML en una etapa PSM sobre la Arquitectura Dirigida por Modelos, siendo este una versión mejorada del mismo. En el trabajo de diploma desarrollado en el 2011 se intentó lograr que la herramienta CASE desarrollada fuera capaz de importar un modelado desde el Modelo Específico de la Plataforma con las características de la plataforma Java ya realizada por otra herramienta y transformarlo a código fuente del lenguaje especificado, cumpliendo las fases dos y tres del desarrollo de software con MDA, con la posibilidad de edición del modelado del diagrama UML importado. En ese año solo se logró que dicha herramienta modelara los diagramas de clase, estados, actividades, casos de uso para el diseño del software, sin importar realmente los obtenidos por la otra herramienta y se simuló la generación de código de manera arbitraria, sin un resultado real lo que se resume en: . La misma presenta errores al crear y diseñar los diagramas por falta de un ambiente gráfico adecuado.. . No genera el código a partir de cada diagrama del PSM confeccionado, y lo que genera es totalmente inoperable.. 5.

(15) Capítulo 1 1.2 UML y Procesos de Desarrollo de Software Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados (Cueva, 1999). Según (Pilone and Pitman, 2005), el mismo en su versión 2.0 y superior estandariza 13 tipos de diagramas para representar gráficamente un sistema desde distintos puntos de vistas: . Estructurales: diagrama de Clases, diagrama de Objetos, diagrama de Componentes, diagrama de Estructuras Compuestas, diagrama de Artefactos, y diagrama de Despliegue. . Comportamiento: diagrama de Casos de Uso, diagrama de Actividades, diagrama de Estado, y diagramas de Interacción (Secuencia, Comunicación, Tiempo, y General de Interacción). No todos los softwares requieren para su construcción de todos estos diagramas, y puede suceder que en sistemas específicos se necesiten otros y por ello UML permite (al ser un lenguaje abierto) la creación de perfiles del mismo.. 1.3 Arquitectura Dirigida por Modelos OMG (acrónimo en inglés de “Object Management Group”), es un consorcio dedicado al establecimiento de estándares de tecnologías orientadas a objetos, integrado por diversas compañías de reconocido nivel y prestigio como: IBM, Apple Computer, Microsoft, Eclipse Foundation, etc. Los estándares de modelado de OMG facilitan un diseño visual, un desarrollo y un mantenimiento de software potentes, son algunos de estos como UML, XMI, CORBA (OMG, 2017). La arquitectura dirigida por modelos (Miller, J. and Mukerji, 2001) es un acercamiento al diseño de software, propuesto y patrocinado por el OMG, concebida para dar soporte a la. 6.

(16) Capítulo 1 ingeniería dirigida a modelos de los sistemas de software. Esta proporciona un conjunto de guías para estructurar especificaciones expresadas como modelos. Según el OMG, MDA proporciona una solución para los cambios de negocio y de tecnologías, permitiendo construir aplicaciones independientes de la plataforma e implementarlas en distintas plataformas.. 1.3.1 ¿Qué es MDA? Según (Omg, 2007), MDA se trata de un marco de trabajo de desarrollo de software que define una nueva forma de construir software en la que se usan modelos del sistema, a distintos niveles de abstracción, para guiar todo el proceso de desarrollo, desde el análisis y diseño hasta el mantenimiento del sistema y su integración con futuros sistemas. Esta se basa en estándares como UML (Unified Modeling Language), XMI (XML Metadata Interchange), MOF (Meta Object Facility) y CWM (Common Warehouse Metamodel). La idea clave de MDA es que si el desarrollo este guiado por modelos de software, se obtienen importantes beneficios en aspectos fundamentales como (Rodríguez Vicente and García Molina, 2004): . Productividad. A través de los modelos independientes de cómputo (CIM por sus siglas en inglés), independiente de plataforma (PIM) y de plataforma específica (PSM), se logran las transformaciones automáticamente, al menos en gran parte, al igual que la generación de código, permitiendo que el trabajo lo realice la herramienta y no el desarrollador.. . Portabilidad. Debido a que cuenta con un modelo PIM, todo lo definido en este modelo es portable hacia cualquier plataforma.. . Interoperabilidad. Normalmente los modelos PSM no pueden comunicarse directamente entre ellos, ya que pueden pertenecer a distintas tecnologías. Este problema lo resuelve generando los puentes entre ellos.. . Mantenimiento y documentación. Básicamente el modelo PIM desempeña el papel de la documentación de alto nivel que se necesita para cualquier sistema de software.. 1.3.2 Modelos en MDA De acuerdo con (Rodríguez Vicente and García Molina, 2004), los modelos juegan un rol trascendental en MDA, ya que al implementar el marco de trabajo MDA, estos dejan de ser. 7.

(17) Capítulo 1 utilizados únicamente para la documentación o como guía para la implementación, convirtiéndose en el artefacto principal del proceso de desarrollo, ya que de ellos depende en gran parte el éxito del proyecto. Constituyen una estrategia clave para entender y especificar una solución de software, mediante la evolución consecuente de los mismos, guían el proceso para obtener una solución final. Cada modelo produce artefactos que establecen el punto de partida para cada etapa de desarrollo. Según la definición de (Kleppe, 2005) “Un modelo es la descripción de todo o parte de un sistema escrito en un lenguaje bien definido”. Por lo que es de gran importancia para MDA la escritura de los modelos en lenguajes bien definidos, ya que se supone que este tiene asociadas una sintaxis y una semántica bien definidas. Esto permite la interpretación automática por parte de compiladores de modelos, los que son fundamentales en MDA. UML es un lenguaje de modelado bien definido que se ha adoptado como el principal lenguaje de modelado en MDA, aunque MDA no está restringido a UML, pues puede usar cualquier lenguaje bien definido. No obstante, la realidad muestra que UML se ha convertido en el lenguaje de modelado oficial de MDA, así que de aquí en adelante se asume que todos los modelos se construyen usando dicho lenguaje. MDA especifica varios modelos básicos de un sistema. Estos modelos pueden verse como niveles de abstracción donde en cada nivel pueden construirse varios modelos (Fernández Sáez, 2009). 1.3.2.1 Modelo Independiente de Computación El modelo CIM (acrónimo en inglés de “Computationally Independent Model”) es un modelo que caracteriza el dominio del problema, no muestra detalles de la estructura del sistema y a veces es llamado modelo del dominio del negocio o modelo de la concepción. Se centra en el entorno del sistema, surge en el proceso de modelado del negocio. Los detalles de la estructura y procesamiento del sistema no se muestran, o aún no están especificados. Idealmente se concibe antes del levantamiento de requisitos. 1.3.2.2 Modelo Independiente de la Plataforma El modelo PIM (acrónimo en inglés de “Platform Independent Model”): es un modelo del sistema de alto nivel que representa la estructura, funcionalidad y restricciones del sistema sin relacionarse con una plataforma determinada. Este modelo sirve de base para todo el. 8.

(18) Capítulo 1 proceso de desarrollo, y es el único que debe ser creado íntegramente por el desarrollador, si no existiese una herramienta capaz de transformar de CIM a PIM. Al no incluir detalles específicos de una plataforma o tecnología determinada, este modelo es útil en dos aspectos: . Es fácilmente comprensible por los usuarios del sistema, y, por lo tanto, les resulta más sencillo validar la corrección del sistema.. . Facilita la creación de diferentes implementaciones del sistema en diferentes plataformas, dejando intacta su estructura y su funcionalidad básica.. 1.3.2.3 Modelo Específico de la Plataforma El modelo PSM (acrónimo en inglés de “Platform Specific Model”): es el modelo derivado de la categoría anterior (PIM), especifican el sistema en términos de las construcciones que se van a implementar a la hora de desarrollar, conteniendo detalles de la plataforma en que será implementado. Es un modelo de sistema de más bajo nivel y mucho más cercano a la vista del código. Finaliza la especificación de un sistema de computadoras. Un modelo PIM puede generar distintos modelos PSM, en función de las tecnologías utilizadas. 1.3.2.4 Modelo de código El modelo de código representa el código desplegable, normalmente en un lenguaje de programación de alto nivel, como Java, C#, C++, VB, JSP, etc. Idealmente, el modelo de código está listo para compilar y no debe requerir la intervención humana; el despliegue de la aplicación puede ser automatizado. Según los puristas y algunos fanáticos de MDA, en un ambiente MDA maduro no se debe pensar en el código más que como simples archivos, o como un mero objeto intermedio para generar el ejecutable final. Pero debido a que MDA no está maduro, y difícilmente se llegue alguna vez a la utopía de no tener que tocar ningún código, los desarrolladores seguirán necesitando conocer la tecnología para complementar la generación de código, poner a punto la aplicación y, sobre todo, lidiar con muchos y variados errores inesperados, extraños y divertidos.. 1.3.3 Transformaciones de Modelos La transformación de modelos constituye el proceso central en el cual se basa la estrategia MDA y con el propósito de crear un estándar de transformación, OMG propone un proceso de estandarización que favorece la representación de propuestas.. 9.

(19) Capítulo 1 La Figura 1 La transformación en el proceso MDA ilustra la forma como MDA propone expresar la solución del problema mediante la evolución consecuente de los modelos, pasando de un nivel de abstracción a otro. La transformación de modelos se sustenta en la definición de las reglas para convertir un modelo de un nivel de abstracción a otro basándose en lenguajes y mecanismos estándares, ver ¡Error! No se encuentra el origen de la referencia... FIGURA 1 LA TRANSFORMACIÓN EN EL PROCESO MDA. 1. En (Roxana and Giandini, 2007) se define una transformación como “la generación automática de un modelo destino desde un modelo fuente, de acuerdo a una definición de transformación”. Donde se refiere a una definición de transformación como “un conjunto de reglas de transformación que juntas describen cómo un modelo en el lenguaje fuente puede ser transformado en un modelo en el lenguaje destino”. Y continua expresando que “una regla de transformación es una descripción de cómo una o más construcciones en el lenguaje fuente pueden ser transformadas en una o más construcciones en el lenguaje destino”.. 1. Tomado de: (Peña, 2011). 10.

(20) Capítulo 1 1.3.3.1 Características deseables de las transformaciones Para poder llevar a cabo el enfoque propuesto por MDA, conviene que el proceso de transformación disponga de una serie de propiedades o características (Rodríguez Vicente and García Molina, 2004): 1. Ajustar las transformaciones: Según MDA es necesario que el programador tenga cierto control sobre la evolución de las transformaciones. Esto se puede obtener mediante: . Control manual: Control directo del programador sobre la transformación. El usuario puede definir manualmente qué elementos del modelo van a ser transformados por qué reglas de transformación. Esta es la solución más flexible, pero es propensa a errores y complica la tarea del desarrollador, por lo que es el método menos utilizado.. . Condiciones en las transformaciones: el desarrollador asigna una condición a cada regla de transformación, la cual describe cuando debe aplicarse la regla. Este enfoque puede combinarse con el control manual. Por ejemplo, todas las clases con el estereotipo “persistent” se transforman en “table”.. . Parámetros de transformación: las definiciones de transformaciones pueden parametrizarse para permitir al desarrollador cambiar el “estilo” de las transformaciones. Por ejemplo, cuando se transforma un atributo público en uno privado con métodos get y set, los prefijos exactos pueden definirse como parámetros de la transformación. Otro parámetro típico de la transformación puede ser la longitud de tipos de datos de tamaño indefinido. Por ejemplo, en lugar de transformar un string en el PIM en un VARCHAR (40) en un PSM relacional, se puede definir la longitud del dato como un parámetro de transformación. Los parámetros de transformación suponen el principal método de control sobre el proceso de transformación. Las marcas vistas en el apartado anterior pueden verse como parámetros de transformación para instancias del modelo.. 2. Trazabilidad: Esta implica que pueda conocerse el elemento origen a partir del cual se ha generado cualquier elemento del modelo destino. Dentro del marco de MDA, la trazabilidad es una característica muy útil en muchas situaciones. Supóngase que se cambia el nombre de la una operación en el PSM que ha sido generada directamente a partir del PIM. Es deseable que ese cambio se reflejase también en. 11.

(21) Capítulo 1 el PIM. Esto no es posible si la herramienta no dispone de un mecanismo para conocer el origen en el PIM de la operación modificada. La trazabilidad también es útil en la búsqueda y corrección de errores. Las partes de código erróneas pueden encontrarse buscando los elementos del PIM, que presentan la funcionalidad defectuosa y siguiendo su traza hasta el código. 3. Consistencia Incremental: Normalmente cuando se genera un modelo destino, éste necesita algún trabajo extra, como rellenar el código de una operación o refinar la interfaz de usuario. Si se regenera de nuevo el modelo destino, debido a cambios en el modelo origen, se quiere que ese trabajo extra se conserve. Esto es consistencia incremental. Cuando se produce un cambio en el modelo origen, el proceso de transformación sabe qué elementos en el modelo destino necesitan cambiarse también. Un proceso de transformación incremental puede reemplazar los elementos viejos con los nuevos, mientras mantiene la información extra del modelo destino en su sitio. Esto significa que cambios en el modelo origen tienen el mínimo impacto en el modelo destino. 4. Bidireccionalidad: Implica que las transformaciones pueden operar en ambas direcciones. Esta propiedad, aunque interesante, tiene menor prioridad que las anteriores. Las transformaciones bidireccionales pueden lograrse de dos formas: . Ambas transformaciones se ejecutan de acuerdo con una única definición de transformación.. . Una transformación y su inversa se especifican mediante dos definiciones de transformación diferentes.. Es muy complicado definir transformaciones bidireccionales, principalmente porque es muy difícil asegurar que una definición de transformación es la inversa de otra. De hecho, en muchas ocasiones la bidireccionalidad es imposible de conseguir. Por ejemplo, cuando se transforma un modelo de negocio en un modelo relacional, solo se transforma la información estructural del modelo origen, ignorando toda la información dinámica. Esto hace imposible regenerar el modelo de negocio completo a partir del modelo relacional. Según lo expuesto en (Peña, 2011) las transformaciones que pueden efectuarse son:. 12.

(22) Capítulo 1 •. PIM a PIM. Esta transformación es utilizada cuando los modelos son mejorados, filtrados o especializados durante el ciclo de vida de desarrollo sin necesitar ninguna información dependiente de la plataforma. Una de las formas de mapeo más obvias es entre los modelos de análisis y el diseño.. •. PIM a PSM. Esta transformación es utilizada cuando el PIM está lo suficientemente refinado para ser proyectado a una infraestructura de ejecución. La proyección está basada en las características de la plataforma utilizada.. •. PSM a PSM. Esta transformación puede requerirse en la implementación y realización de componentes. Por ejemplo, el empaquetado de un componente se realiza seleccionando servicios y configuración. Una vez empaquetado, la entrega del componente puede ser realizada especificando los datos de inicialización, servidores de instalación, generación y configuración del contenedor, etc. Esta transformación está ligada al refinamiento de un modelo PSM a un PSM mejorado y más completo.. •. PSM a PIM. Esta transformación puede ser requerida para abstraer modelos de implementaciones existentes en una tecnología específica a una independiente de la plataforma. Este procedimiento es sin duda uno de los más complicados y difícilmente puede ser automatizado.. •. PSM a Código. Esta transformación es la última de la cadena y permite generar el código específico para una plataforma en particular utilizando PSM. Una vez mejorados los PSM o actualizados debido al surgimiento de nuevos requerimientos una transformación de este tipo es necesaria para regenerar el sistema.. 1.3.3.2 Reglas de transformación en el proceso de generación automática de código De acuerdo con lo plasmado en (Muñetón, Zapata and Arango, 2007) se puede deducir que una regla de transformación es una descripción de cómo una o más construcciones del lenguaje fuente pueden ser transformadas en una o más construcciones del lenguaje objetivo. Según (Tuñón, 2014), los modelos del sistema producto de las fases de definición y análisis, en particular, deben ser refinados, es decir aplicarles una serie de reglas de transformación para incorporarles los elementos propios de la plataforma tecnológica de implantación durante la fase de diseño.. 13.

(23) Capítulo 1 El proceso de generación del código puede llegar a aplicar una serie de estas reglas, los cuales generalmente le permiten al desarrollador la elección entre los distintos patrones que pueden ser aplicados a los modelos para transformarlos en modelos más complejos o código. Estas se especifican a nivel de metamodelo, con el objetivo de hacerlas más genéricas (Muñetón, Zapata and Arango, 2007). La propuesta de refinamiento de OMG es MDA, que plantea tres aspectos fundamentales: . Separación de la especificación de los requisitos de un sistema de los aspectos técnicos asociados con su implementación en una plataforma particular. En otras palabras, se pasa de uno o varios modelos del sistema independientes de la plataforma de implementación, obtenidos en la fase de análisis, a un modelo dependiente de la plataforma de implementación elegida, como producto de la fase de diseño.. . Uso de UML como lenguaje único de modelado a través de todo el proceso de refinamiento de modelos. Así, tanto los modelos independientes de la plataforma como los dependientes quedan especificados en este lenguaje.. . Formalización de las reglas de transformación de un modelo a otro.. FIGURA 2 PROCESO DE TRANSFORMACIÓN EN MDA. Tomando como referente lo expuesto en (Tuñón, 2014), la metodología a seguir para la transformación de modelos definiendo las reglas a nivel de metamodelo es la siguiente: 1. Recolección en lenguaje natural de las reglas de transformación del Modelo de Clases UML al Modelo Código, a partir de diferentes fuentes. 2. Estudio y simplificación del Metamodelo Fuente: Metamodelo del Modelo de Clases de UML, extrayendo sus características más recurrentes en los diagramas construidos por los analistas de software como los atributos derivados y las relaciones de asociación, composición y generalización entre Clases.. 14.

(24) Capítulo 1 3. Selección de un conjunto básico de reglas verbales para transformar el Modelo de Clases UML al Modelo Código, en las que se contemplan aspectos del Modelo de Clases como atributos derivados y relaciones de asociación y generalización para adaptarlas a nivel del Metamodelo. 4. Formalización y aplicación de las reglas seleccionadas al caso práctico de estudio. Las reglas a seleccionar se deben orientar a la transformación de cinco elementos básicos del Modelo de Clases de UML: Clases, Invariantes, Atributos Derivados, Asociaciones, incluyendo la relación de composición, y Generalización. A continuación, se muestra de forma resumida las ventajas y desventajas del paradigma MDA (OMG, 2009; Córdova, 2011).. 1.3.4 Ventajas del MDA MDA representa para los desarrolladores, una nueva manera de organizar y administrar arquitecturas empresariales, basada en la utilización de herramientas de automatización de etapas en el ciclo de desarrollo. De esta forma, permite definir los modelos y facilitar trasformaciones paulatinas entre diferentes modelos. Es decir que, a partir de uno de ellos, podemos generar otro de menor abstracción (OMG, 2009; Córdova, 2011). La ventaja principal de MDA radica en la clara y estricta separación de responsabilidades. Por un lado, modelar los PIM, que representan los modelos del negocio, y, por otro lado, los PSM con las preocupaciones tecnológicas. Esto permite que ambos modelos puedan evolucionar por separado. De esta manera, si se quisiera, por ejemplo, modificar un aspecto técnico, bastará con modificar el PSM sin que estos tengan impacto en la lógica de negocios. Esta idea viene de un concepto que, en Ingeniería de Software, se llama “Guías de Diseño”. Particularmente, una de esas guías dice que el modelado de la solución debe ser dirigido por el negocio. Esta guía se basa en la afirmación de que un cambio en el negocio seguramente produzca un cambio en el código, pero no lo inverso: los cambios en el código no deberían impactar en el negocio. MDA también permite: lidiar con la complejidad del negocio, modelando a éste por separado y permitiendo su análisis y mejora; disminuir costos, si se cuenta con una herramienta MDA adecuada a nuestras necesidades; mejorar la calidad de nuestros modelos y procesos, mediante su análisis y la separación de responsabilidades. (Anacleto, 2006). 15.

(25) Capítulo 1 Por otra parte, MDA mejora la productividad desde el punto en que los desarrolladores de PIM hacen menos trabajo porque pueden trabajar independientemente de los detalles de la plataforma que se vaya a utilizar. Este incremento de productividad se consigue mediante el uso de herramientas que automaticen el paso de un PIM a un PSM y de este a Código. La portabilidad se centra en el desarrollo de los PIM que son plataformas independientes. El mismo PIM se puede transformar automáticamente en múltiples PSM para diferentes plataformas, por tanto, todo lo que se especifique a nivel de PIM es portable. Mejora la interoperabilidad puesto que múltiples PSM generados a partir de un mismo PIM pueden tener relaciones entre sí, que en MDA se llaman puentes. Cuando los PSM están orientados a distintas plataformas no se pueden comunicar directamente. Es necesario transformar conceptos de una plataforma en los conceptos de la otra. En MDA no sólo se generan PSM, sino que también los puentes necesarios entre ellos. El mantenimiento y la documentación presenta una notable mejora ya que hay que centrarse en el PIM, dado que el PIM se usará para transformarse en PSM que a su vez se transformará en código. Además, el PIM no es abandonado una vez escrito, los cambios que se quieran hacer al sistema se harán en el PIM, que actualizará el PSM que a su vez actualizará el código. Y como consecuencia la documentación de alto nivel será consecuente con el código actual.(Alarcos, 2006). 1.3.5 Desventajas del MDA . Presenta carencias en transformación de modelos por falta de estándares OMG y por no tener soporte total de herramientas.. . No proporciona suficientes guías metodológicas, sólo se define la estrategia general para la transformación PIM-PSM.. . No garantiza la separación de conceptos.. 1.4 Herramientas Case Según (Jaramillo, Mojica and Ceballos, 2010), las herramientas CASE (acrónimo en inglés de “Computer Aided Software Engineering”) son diversas aplicaciones informáticas o programas informáticos destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Dichas herramientas suministran soporte automático o semiautomático para los diversos aspectos del ciclo de vida. 16.

(26) Capítulo 1 del desarrollo de software, tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.. 1.4.1 Caracterización de herramientas CASE más utilizadas PLATINUM ERwin: es una herramienta de diseño de base de datos. Brinda productividad en diseño, generación, y mantenimiento de aplicaciones. Desde un modelo lógico de los requerimientos de información, hasta el modelo físico perfeccionado para las características específicas de la base de datos diseñada, ERwin permite visualizar la estructura, los elementos importantes, y optimizar el diseño de la base de datos. Genera automáticamente las tablas y miles de líneas de procedimientos almacenados y disparadores para los principales tipos de base de datos. (Technologies, 2011) Rational Rose: es una herramienta de producción y comercialización, avalada por décadas de éxito en el mercado, perteneciente a la familia de software de IBM Rational Software. Permite el modelado visual de arquitecturas y componentes utilizando UML. Este producto está centrado en la metodología del RUP, y posee la capacidad de: Crear, Ver, Modificar y Manipular los componentes de un modelo. Implementa automáticamente el marco de trabajo del código en Java, C++, Ada, Microsoft Visual Basic, Bases de Datos Oracle y SQL Server y además permite crear un nuevo Marco de Trabajo. Chequeo de la sintaxis UML y generación automática de documentación (Software, 2003). Visual Paradigm: es una herramienta UML profesional que soporta el ciclo de vida completo del desarrollo de software: análisis y diseño orientados a objetos, construcción, pruebas y despliegue. Ofrece un entorno para la creación de diagramas UML, diseño centrado en casos de uso y enfocado al negocio. Brinda capacidades de ingeniería directa e inversa. Generación de código y despliegue de EJB. Importación y exportación de ficheros XMI. Integración con Microsoft Visio (Paradigm, 2017).. 1.4.2 Herramientas CASE que implementan la aproximación MDA A pesar de que el marco de trabajo MDA está todavía en pleno desarrollo, este aporta grandes beneficios al desarrollo de software, por lo que no es sorpresa la aparición de un buen número de herramientas que utilicen dicha arquitectura. Para este estudio se realizó una selección de las herramientas que se considera que en mayor medida implementan esta metodología, 17.

(27) Capítulo 1 además con el fin de servir como soporte a la investigación se recurre a estudios antes realizados, tomando las características y principales carencias que se considera más importantes de dichas herramientas. AndroMDA: es una herramienta de generación de código que sigue el paradigma de la arquitectura MDA. Recibe un modelo UML de una herramienta CASE y genera las clases y los componentes (J2EE u otros), específicos para la arquitectura de la aplicación. Su generador de código soporta plataformas actuales, es una herramienta Open Source. Emplea una serie de plugins para generar código fuente en disímiles lenguajes de programación. Incluye además un juego para desarrollar plugins propios (Meta), el cual puede ser personalizado, para construir un generador de código propio. Brinda soporte para UML 2.0 y herramientas basadas en Eclipse EMF, MagicDraw 11.6, RSM). Es capaz de generar código en diferentes lenguajes de programación como JAVA, PHP, .NET, HTML. Dadas sus características se puede considerar un marco de trabajo para el desarrollo con MDA más que una herramienta en sí misma.(Luis, 2009) OptimalJ: es una herramienta para dar soporte a MDA. Se trata de un entorno de desarrollo de software empresariales que permite generar con rapidez aplicaciones J2EE completas directamente a partir de un modelo de alto nivel (PIM), utilizando patrones para codificar adecuadamente las especificaciones de J2EE y haciendo uso de los estándares del MDA. OptimalJ implementa el marco de trabajo MDA haciendo uso de tecnologías estándar como MOF, UML, XMI, XML, WSDL y J2EE. Actualmente se encuentra en la versión 4.0 (Rodríguez Vicente and García Molina, 2004). Enterprise Architect: combina el poder de la última especificación UML 2.1 con alto rendimiento, interfaz intuitiva, para traer modelado avanzado al escritorio, y para el equipo completo de desarrollo e implementación. Brinda soporte para las transformaciones MDA y para los 13 diagramas de UML 2. Contiene plug-in para vincularse a Visual Studio.Net o Eclipse, dando la posibilidad de localizar el código fuente para las clases, atributos y operaciones en su IDE (Sparx, 2016).. 18.

(28) Capítulo 1 TABLA 1 COMPARACIÓN DE HERRAMIENTAS MDA. AndroMDA. OptimalJ. Patrones en los modelos MDA.  PIM y PSM  No ofrece soporte para CIM.  PIM y PSM  No ofrece soporte para CIM. Transformación de Modelos. Automáticas:. Automáticas:.  . PIM a PSM. PIM a código..  . PIM a PSM PIM a código.. Enterprise Architect  PIM y PSM  No ofrece soporte para CIM Automáticas:   . PIM a uno o varios PSM PIM a Código PSM a Código. Ingeniería Inversa. No. No. Sí. Estándares. XMI. MOF, UML, XMI, XML, WSDL, y J2EE. Perfiles UML. UML, BPMN y SysML. XMI como lenguaje de entrada y almacenamiento. MOF OCL y UML 1.4 Interoperabilidad. XMI como lenguaje de entrada y almacenamiento. XMI como lenguaje de entrada y almacenamiento. Extensibilidad. Apache’s Maven,. API EJB permite la Plug-ins para vincular comunicación remota EA a Visual Studio.NET utilizando CORBA o Eclipse. NetBeans, ArgoUML, MagicDraw, Generación de Código. Por medio de cartridge. En el lenguaje seleccionado. J2EE. C, C++, C#, Delphi, Java, PHP, Python, ActionScript, Visual Basic and VB.NET. 1.5 ¿Por qué una herramienta propia? En Cuba predomina la percepción, de que no puede apostarse por los sistemas operativos privativos como un camino viable para el desarrollo tecnológico, y que a la vez conduzca a la independencia en este mismo ámbito. Factores económicos, de obtención de licencias, de adquisición de software propietario a través de Internet y la posibilidad latente de reclamaciones por parte de algunos fabricantes, entre muchas otras complejidades, conduce a optar por otra modalidad de software, menos atado a restricciones legales y más accesible desde el punto de vista económico. Esto básicamente es una consecuencia del bloqueo económico de EEUU a Cuba.. 19.

(29) Capítulo 1 Aun así, en Cuba, que contaba al cierre del 2013 con más de 1014000 computadoras, según la Oficina Nacional de Estadística e Información (ONEI), la mayoría de las máquinas emplean Windows, y un gran número de usuarios utiliza Word, PowerPoint, Photoshop, etc., programas empleados sin el autorizo de las empresas que los diseñan. De acuerdo con diferentes sitios web, el precio de un sistema operativo de Windows se encuentra entre los 119 y 219 USD y el paquete de Office (Word, PowerPoint, Excel, Access, Outlook…), entre los 240 y 680 USD (ONEI, 2014). Entonces ¿Qué ocurrirá si desaparecieran, a instancias del proceso de normalización de las relaciones Cuba-Estados Unidos, las circunstancias que hoy no nos obligan a pagar el uso de estos programas y sistemas, ¿podríamos pagar precios como esos? La posible eliminación de las disposiciones que hoy impiden estas transacciones podría traer el consecuente cobro de las licencias de esos sistemas que están desplegados en Cuba, y por tanto la erogación de fuertes sumas de dinero, si se tiene en cuenta el precio de un sistema operativo Windows. Cuando hablamos de software propietario, sintéticamente, nos referimos a cualquier programa informático o aplicación en la cual el usuario no puede acceder al código fuente o tiene un acceso restringido limitándose en sus posibilidades de uso, modificación y redistribución. Sin embargo, es bueno aclarar que mantienen un gran punto a favor: el soporte. Cuando aludimos a software libre, partimos de aquel que tiene abierto su código fuente y puede ser distribuido, modificado, copiado y usado. Como país subdesarrollado, la migración a software libre parece imponerse en el camino hacia el alcance de la independencia tecnológica. Para ello, hay que cimentar las bases con software que no dependan de ningún monopolio extranjero, y que principalmente sea posible analizar y modificar por nuestros profesionales. El gobierno cubano está exhortando a dejar de utilizar software de patente y seguir el ejemplo del servicio de aduanas, el cual ha cambiado a GNU/Linux gran parte de sus sistemas. El software libre ofrece cuatro libertades fundamentales: libertad para ejecutar el programa sea cual sea nuestro propósito, para estudiar su funcionamiento y adaptarlo a nuestras necesidades, para redistribuirlo a toda la comunidad de usuarios, y modificarlo, mejorarlo y 20.

(30) Capítulo 1 publicarlo. Muchas veces estas libertades son irrelevantes para los usuarios, pues no les interesa leer el código fuente, sino simplemente emplearlo, pero las mismas son necesarias para lograr la independencia tecnológica. Entre las múltiples ventajas que ofrece el software libre están los beneficios desde el punto de vista económico, pues al contar con el código fuente se pueden desarrollar aplicaciones evitando la compra de software en el exterior; así como que por lo general es libre de costo o posee uno muy bajo, de modo que se torna accesible y tecnológicamente inclusivo. El hecho de poder adaptar el software a tus propias condiciones, otro de los atributos mencionados, aumenta la capacidad decisional sobre las tecnologías y permite resolver qué usar, cómo hacerlo y cómo modificarlo de acuerdo con tu propio contexto. Este tipo de software, además, es diseñado de forma colectiva y cooperativa tanto en su creación como en su desarrollo. Esto conlleva, a que todas las mejoras que se realicen carezcan de restricciones, que los procesos de corrección de errores sean más rápidos, que las actualizaciones se distribuyan de modo casi inmediato a través de las redes de alcance global. Además, no se tiene que esperar, por ejemplo, a que una empresa privada libere la nueva actualización que solucione el problema, la distribuya, para que solo luego, puedas comprarla. Pero cuidado, esto implica perdida del soporte tecnológico, ya que muchos contribuyen, pero ninguno es el verdadero responsable de dar solución a los problemas que se presenten. Además, las diferentes licencias de uso del llamado software libre no permiten que las aplicaciones desarrolladas a partir de ellos, puedan ser vendidas libremente a otros usuarios y esto implica la pérdida de la posibilidad de apoyar al desarrollo económico del país con la industria del software. El tema de la privacidad y seguridad es otro que adquiere particular relevancia en el empleo de un tipo de software u otro pues al tener un código abierto sabes lo que están utilizando, mientras que con el código cerrado desconoces si detrás prevalece alguna orden oculta. Cuando como usuarios empleamos software privativo, desconocemos o aminoramos la importancia de que, por ejemplificar, Windows envíe información a sus creadores o a empresas de marketing sobre las características de la plataforma donde está instalado, aplicaciones empleadas, sitios de Internet visitados, entre otros.. 21.

(31) Capítulo 1 ¿Entonces que es mejor? Desde nuestro punto de vista la verdadera solución sería contar con software “soberano”, lo cual implicaría tener una verdadera industria del software encargada de desarrollarlo –empezando por crear una plataforma completa, con un Sistema Operativo, algún lenguaje de programación, un gestor de datos, aplicaciones ofimáticas, etc. – y de ser el responsable de su soporte y mantenimiento, lo cual permitiría que las entidades nacionales lo usaran para la implementación y explotación de diferentes y variadas aplicaciones que a su vez podrían ser vendidas a terceros, revirtiendo con esas ganancias, los gastos en que se incurre actualmente informatizando al país. Dentro de esa idea está el desarrollo de herramientas CASE y MDA propias para que esa naciente industria cuente con software que permitan aumentar la productividad, garantizando independencia tecnológica pero también el soporte adecuado.. 1.6 Análisis de lenguajes de programación más usados actualmente Un lenguaje de programación es un lenguaje diseñado para describir el conjunto de acciones consecutivas que un equipo debe ejecutar. Por lo tanto, un lenguaje de programación es un modo práctico para que los seres humanos puedan dar instrucciones a un equipo, siendo estos de gran importancia para el desarrollo tecnológico, ya que mediante los mismos se hace posible el desarrollo de aplicaciones, software y soluciones informáticas más específicas y nutridas debido a sus capacidades y posibilidad de interacción entre unos y otros. En los últimos años se caracterizaron por lanzar una amplia gama de lenguajes de programación, algunos de estos lenguajes tuvieron más popularidad y otros sólo se mantuvieron dentro de los números bajos o el anonimato (Lutz, 2010). La empresa RedMonk se encargó de publicar los datos de popularidad y crecimiento o decrecimiento del empleo de cada lenguaje basándose en los datos de GitHub. El fin de éste análisis que se comenzó a realizar en 2010, apunta a comparar los lenguajes de los que se habla con los que se usan, para así obtener como resultado la tendencia de la continuidad y uso que se dará a los lenguajes de programación en un futuro.. 22.

(32) Capítulo 1 El resultado que arrojó el análisis de los primeros meses de 2016 es el siguiente (O’Grady, 2016): 1. JavaScript 2. Java 3. PHP 4. Python 5. C# 6. C++ 7. Ruby 8. CSS 9. C 10. Objective-C En la presente investigación solo se profundizarán en los lenguajes Java y Python, ya que ambos son los de interés para la investigación, además una vez analizado los resultados de popularidad y crecimiento o decrecimiento del empleo de cada lenguaje se pudo observar que ambos están dentro los primeros cinco más usados.. 1.6.1 Java Java es un lenguaje de programación que es distribuido actualmente como software libre bajo una licencia GNU GPL (General Public License), lo cual lo hace un gran candidato para el uso en el desarrollo de aplicaciones en países del tercer mundo. El lenguaje Java fue creado para trabajar con objetos y de manera independiente a la plataforma. Esto es posible debido a la JVM (Java Virtual Machine) la cual es una máquina genérica, que ejecuta un código creado al compilar un programa, que corre indistintamente en cualquier ordenador que tenga instalada dicha máquina virtual. Java es un lenguaje robusto justamente por la forma en que está diseñado, no permite el manejo directo del hardware ni de la memoria. Implementa además mecanismos de seguridad que limitan el acceso a recursos de las máquinas donde se ejecuta. La Plataforma Java se compone de un amplio abanico de tecnologías, cada una de las cuales ofrece una parte del complejo de desarrollo o del entorno de ejecución en tiempo real. Por ejemplo, los usuarios finales suelen interactuar con la máquina virtual de Java y el conjunto. 23.

(33) Capítulo 1 estándar de bibliotecas. Para el desarrollo de aplicaciones, se utiliza un conjunto de herramientas conocidas como JDK (Java Development Kit) o herramientas de desarrollo para Java. Principales características de Java (Schildt, 2001): . Universalidad: Aunque es un programa interpretado no es en principio tan rápido como un programa equivalente compilado, las prestaciones de Java son sin embargo mejores que las de cualquier lenguaje interpretado. Este hecho, junto con la sencillez de programación en Java ha propiciado que se hayan escrito intérpretes de pequeño tamaño adaptados a prácticamente cualquier plataforma, desde mainframes y ordenadores personales (con cualquier sistema operativo: Windows, Macintosh OS, Unix...) hasta dispositivos electrónicos de bajo coste. También se suele hacer referencia a la universalidad de Java con términos equivalentes como transportabilidad, o independencia de plataforma, pues para ejecutar un programa basta compilarlo una sola vez, a partir de entonces, se puede hacer correr en cualquier máquina que tenga implementado un intérprete de Java.. . Sencillez: Java es un lenguaje de gran facilidad de aprendizaje, pues en su concepción se eliminaron todos aquellos elementos que no se consideraron absolutamente necesarios. Por otro lado, Java dispone de un mecanismo conocido como "recogida de basura", el cual usando la capacidad multitarea de Java hace que, durante la ejecución de un programa, los objetos que ya no se utilizan se eliminen automáticamente de la memoria. Dicho mecanismo facilita enormemente el diseño de un programa y optimiza los recursos de la máquina que se esté usando para la ejecución del mismo (con los lenguajes tradicionales, la eliminación de objetos y la consiguiente optimización de recursos debe planificarse cuidadosamente al idear el programa).. . Orientación a objetos: Un objeto es un elemento de programación, autocontenido y reutilizable, y que podríamos definir como la representación en un programa de un concepto, representación que está formada por un conjunto de variables (los datos) y un conjunto de métodos (o instrucciones para manejar los datos).. 24.

(34) Capítulo 1 . Seguridad: En general, se considera que un lenguaje es tanto más seguro cuanto menor es la posibilidad de que errores en la programación, o diseños malintencionados de programas (virus), causen daños en el sistema.. . Disponibilidad de un amplio conjunto de bibliotecas: Como ya se mencionó anteriormente, Java es algo más que un lenguaje. La programación de aplicaciones con Java se basa no solo en el empleo del juego de instrucciones que componen el lenguaje, sino, fundamentalmente, en la posibilidad de utilizar el amplísimo conjunto de clases que se pone a disposición del programador y con las cuales es posible realizar prácticamente cualquier tipo de aplicación.. . Distribuido: Java proporciona una colección de clases para su uso en aplicaciones de red, que permiten abrir sockets y establecer y aceptar conexiones con servidores o clientes remotos, facilitando así la creación de aplicaciones distribuidas.. . Interpretado y compilado a la vez: Java es compilado, en la medida en que su código fuente se transforma en una especie de código máquina, los bytecodes, semejantes a las instrucciones de ensamblador. Por otra parte, es interpretado, ya que los bytecodes se pueden ejecutar directamente sobre cualquier máquina a la cual se hayan portado el intérprete y el sistema de ejecución en tiempo real (run-time).. . Robusto: Java fue diseñado para crear software altamente fiable. Para ello proporciona numerosas comprobaciones en compilación y en tiempo de ejecución. Sus características de memoria liberan a los programadores de una familia entera de errores (la aritmética de punteros), ya que se ha prescindido por completo de los punteros, y la recolección de basura elimina la necesidad de liberación explícita de memoria.. . Seguro: Dada la naturaleza distribuida de Java, donde las applets se bajan desde cualquier punto de la Red, la seguridad se impuso como una necesidad de vital importancia. A nadie le gustaría ejecutar en su ordenador programas con acceso total a su sistema, procedentes de fuentes desconocidas. Así que se implementaron barreras de seguridad en el lenguaje y en el sistema de ejecución en tiempo real.. 25.