Diseño e implementación de un ambiente de desarrollo de software para JCSP
106
0
0
Texto completo
(2) ISC-2003-1-3. ii. DISEÑO E IMPLEMENTACIÓN DE UN AMBIENTE DE DESARROLLO DE SOFTWARE PARA JCSP. FERNANDO ANGARITA SARMIENTO. TESIS DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE SISTEMAS Y COMPUTACIÓN. ASESORES RAFAEL GÓMEZ DÍAZ RUBBY CASALLAS GUTIÉRREZ. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN 2004.
(3) ISC-2003-1-3. iii. DEDICADO. A mis padres, Guillermo y Magdalena, quienes han sido la luz que ha guiado mis pasos y aún continúan enseñándome el camino..
(4) ISC-2003-1-3. iv. AGRADECIMIENTOS. A mis asesores, Rafael Gómez y Rubby Casallas, por la infinita paciencia que me tuvieron durante el desarrollo de este trabajo, así como también por el tiempo y la colaboración que muy amablemente me brindaron.. A mi familia por el apoyo, el ánimo y los incansables días de lucha que conmigo compartieron. Sin ustedes este proyecto nunca hubiera culminado.. A Gabriel, Hector, Natalia, Claudia, Bibiana, Gonzalo, Raul Andrés, y todos los demás que de una u otra forma me dieron ánimo y fuerza para continuar cuando todo parecía perdido.. A todos ustedes muchas gracias..
(5) ISC-2003-1-3. v. CONTENIDO. INTRODUCCIÓN............................................................................................................................................ 11 1. MARCO TEÓRICO....................................................................................................................................15 1.1 AMBIENTES DE DESARROLLO DE SOFTWARE (SDE).....................................................................15 1.2 COMMUNICATING SEQUENTIAL PROCESSES (CSP)........................................................................22 1.3 COMMUNICATING SEQUENTIAL PROCESSES FOR JAVA (JCSP).................................................. 29 2. HERRAMIENTAS UTILIZADAS..............................................................................................................40 2.1 ECLIPSE...................................................................................................................................................... 40 2.1.1 Arquitectura. ............................................................................................................................................. 42 2.1.2 Funcionamiento......................................................................................................................................... 45 2.2 OTRAS TECNOLOGÍAS............................................................................................................................ 47 2.2.1 Eclipse Modeling Framework (EMF)........................................................................................................47 2.2.2 Graphical Editing Framework (GEF)........................................................................................................ 49 2.2.3 Velocity..................................................................................................................................................... 53 3. DESCRIPCIÓN DE LA APLICACIÓN.....................................................................................................56 3.1 DESCRIPCIÓN............................................................................................................................................ 56 3.1.1 Procesos simples........................................................................................................................................57 3.1.2 Procesos conectar y utilizar....................................................................................................................... 58 3.1.3 Procesos Compuestos................................................................................................................................ 58 3.1.4 Canales.......................................................................................................................................................59 3.1.5 Puertos....................................................................................................................................................... 59 3.2 DISEÑO........................................................................................................................................................60.
(6) ISC-2003-1-3. vi. 3.2.1 Decisiones de Diseño.................................................................................................................................62 3.2.2 El modelo de red de procesos....................................................................................................................62 3.3 ARQUITECTURA....................................................................................................................................... 72 3.4 FUNCIONAMIENTO.................................................................................................................................. 84 3.4.1 Prerequisitos.............................................................................................................................................. 84 3.4.2 Ejecución................................................................................................................................................... 85 4. CONCLUSIONES........................................................................................................................................ 90 5. TRABAJO FUTURO................................................................................................................................... 95 BIBLIOGRAFÍA.............................................................................................................................................. 99 ANEXOS..........................................................................................................................................................102.
(7) ISC-2003-1-3. vii. LISTA DE FIGURAS. FIGURA 1. RED DE PROCESOS CON DOS PROCESOS........................................................................ 39 FIGURA 2. ARQUITECTURA DE LA PLATAFORMA ECLIPSE.......................................................... 44 FIGURA 3. ARQUITECTURA MVC GEF................................................................................................... 50 FIGURA 4. ARQUITECTURA EDITPART................................................................................................. 52 FIGURA 5. REPRESENTACIÓN DE UN PROCESO SIMPLE................................................................ 57 FIGURA 6. REPRESENTACIÓN PROCESOS CONECTAR Y UTILIZAR............................................58 FIGURA 7. REPRESENTACIÓN DE UN PROCESO COMPUESTO CON UN PAR DE PROCESOS INTERNOS....................................................................................................................................................... 59 FIGURA 8. REPRESENTACIÓN DE LOS TIPOS DE PUERTOS............................................................60 FIGURA 9. REPRESENTACIÓN DE LOS PUERTOS EXTERNOS........................................................ 60 FIGURA 10. MODELO DE LA RED DE PROCESOS................................................................................63 FIGURA 11. JERARQUÍA DE LOS CONTROLADORES.........................................................................77 FIGURA 12. FLUJO DE INFORMACIÓN ENTRE LOS DISTINTOS COMPONENTES DE LA APLICACIÓN...................................................................................................................................................81 FIGURA 13. ARQUITECTURA DEL AMBIENTE DE DESARROLLO PARA JCSP...........................84.
(8) ISC-2003-1-3. viii. FIGURA 14. DIALOGO PARA INSTANCIAR UN PROCESO.................................................................87.
(9) ISC-2003-1-3. ix. INDICE DE TABLAS. TABLA 1. RESUMEN CLASE PROCESSNETWORKELEMENT..........................................................63 TABLA 2. RESUMEN DE LA CLASE PROCESSNETWORK..................................................................64 TABLA 3. RESUMEN CLASE PROCESSNETNODE................................................................................ 65 TABLA 4. RESUMEN CLASE PROCESS....................................................................................................65 TABLA 5. RESUMEN CLASE PAPPROCESS............................................................................................ 66 TABLA 6. RESUMEN CLASE COMPOUNDPROCESS............................................................................67 TABLA 7. RESUMEN CLASE INITFIELD................................................................................................. 67 TABLA 8. RESUMEN CLASE CHANNEL.................................................................................................. 69 TABLA 9. RESUMEN CLASE OUTPUTPORT...........................................................................................69 TABLA 10. RESUMEN CLASE INPUTPORT.............................................................................................70 TABLA 11. RESUMEN CLASE EXTINPUTPORT.....................................................................................71 TABLA 12. RESUMEN CLASE EXTOUTPUTPORT................................................................................ 72 TABLA 13. RESUMEN DE LA CLASE COMMENT................................................................................. 72.
(10) ISC-2003-1-3. x. LISTA DE ANEXOS. ANEXO A. DIAGRAMA DE COMPONENTES........................................................................................ 102 ANEXO B. DIAGRAMA DE CLASES, LÓGICA DE NEGOCIO........................................................... 103 ANEXO C. DIAGRAMA DE CLASES, MODELO DE VISTA................................................................ 104 ANEXO D. DIAGRAMA DE CLASES, MODELO DE CONTROLADORES........................................105 ANEXO E. DIAGRAMA DE CLASES, EDITOR GRÁFICO...................................................................106.
(11) ISC-2003-1-3. 11. INTRODUCCIÓN. A lo largo de las historia de las ciencias, se ha podido observar cómo antiguas formas de pensar y de ver el mundo son reemplazadas por otras nuevas. Estas revoluciones en cuanto a la forma han dado lugar a descubrimientos sin parangón, además de lograr otorgar eficiencia a procesos mentales y de otras índoles (i.e. productivos, metodológicos, etc.)1.. La historia de las ciencias de la computación no es una excepción, esto es especialmente evidente en el área de la programación. En dicho campo se ha podido observar cómo, a lo largo de su evolución histórica, los modelos y las formas de plantear e implementar las soluciones a los problemas que se han enfrentado han ido cambiando a través del tiempo. Esta evolución en cuanto a la forma se ha dado en parte gracias a una necesidad constante de desarrollar aplicaciones más confiables, más seguras, más robustas y más eficientes, sin decir con esto que estas son las únicas variables determinantes en dicha evolución.. 1. Kuhn, Thomas. La Estructura de las Revoluciones Científicas. Bogotá: Fondo de la cultura económica, 1994..
(12) ISC-2003-1-3. 12. A lo largo del desarrollo de este campo se han podido observar diferentes paradigmas de programación, al igual que distintos lenguajes de programación que encajan en la definición, y que pueden ser representantes de su paradigma particular. Algunos ejemplos de tales paradigmas son: •. Por procedimientos o Imperativa (e.g. FORTRAN).. •. Funcional o Aplicativa (e.g. LISP).. •. Lógico (e.g. PROLOG).. •. Basado en reglas (e.g. OPS5).. •. Lenguajes de consulta a bases de datos (e.g. SQL).. •. Visual (e.g. Visual Basic).. •. Scripts (e.g. PERL). •. Programación por demostración (e.g. LAWE).. •. Orientado a Objetos (e.g. Java)2,3,4.. •. Orientado a Procesos (e.g. Occam).. Tal cantidad de paradigmas de programación se debe en gran parte al hecho de que hasta este momento no existe un paradigma que no padezca de algún tipo de defecto con respecto a la, cada vez mayor, complejidad de los sistemas de software. En la actualidad, el. 2. Furse,. Edmund.. Introduction. to. Programming. Paradigms.. En. línea:. En. línea:. En. línea:. http://www.comp.glam.ac.uk/pages/staff/efurse/Teaching/PP/Introduction.html, 1998. 3. Campbell,. Jonathan.. Programming. Languages. and. Paradigms.. http://www.cs.qub.ac.uk/~J.Campbell/myweb/oop/oophtml/node4.html, 1999. 4. Edwards,. Steve.. Programming. Language. History. and. http://courses.cs.vt.edu/~cs3304/Spring00/notes/Chapter-2/index.htm, 2000.. Evolution..
(13) ISC-2003-1-3. 13. paradigma de programación más utilizado es el orientado a objetos5, dados los beneficios que este paradigma ha otorgado al análisis, diseño, y desarrollo de sistemas complejos, especialmente a nivel comercial.. Sin embargo, el paradigma orientado a objetos tiene una serie de carencias inherentes a su concepción y definición. Precisamente estas deficiencias han dado lugar a desarrollos de nuevos paradigmas que pretenden “refinar o mejorar o energizar a este [al paradigma orientado a objetos]”6. Es precisamente esta situación la que ha motivado el presente trabajo de grado, en el sentido de que se va a desarrollar una herramienta que permita investigar a futuro hasta qué punto el paradigma orientado a procesos, más específicamente CSP7, soluciona algunas de las carencias que presenta el paradigma orientado a objetos.. Para lograr dicho objetivo, en el presente trabajo de grado se va a investigar cuál es la problemática del modelo orientado a objetos y a partir de dicha problemática se piensa ahondar en el modelo de CSP, y de cómo este puede ayudar a solucionar algunos aspectos analizados en la perspectiva de los objetos. Una vez aclarados estos aspectos, se va a describir el funcionamiento de la herramienta construida.. 5. Capretz, Luis Fernando. A Brief History of the Object-Oriented Approach. En: ACM SIGSOFT Software. Engineering Notes. Londres. Vol. 28, No. 2 (mar. – abr. 2003); p. 1 – 10. 6. Hayes, Brian. The Post-OOP Paradigm. En: American Scientist. Vol. 91, No. 2 (mar. – abr. 2003); p.108.. 7. Communicating Sequential Processes. Este paradigma aparece por primera vez en un artículo escrito por. C.A.R. Hoare en 1985..
(14) ISC-2003-1-3. 14. Para tal efecto, este documento comenzará por definir el marco teórico en el que este trabajo de grado se desarrolla. En dicho marco teórico se introducirá el concepto de los SDE8, así como una introducción a CSP, finalmente se dará una descripción de la implementación JCSP, puesto que es con base a esta que el modelo de la aplicación está construido.. En el capítulo 2 se presentará una descripción de las tecnologías usadas en el desarrollo de la aplicación, continuando en el capítulo 3 con la descripción de la aplicación y su forma de uso.. Este trabajo de grado concluirá con un capítulo referente a las conclusiones a las que se llegó a lo largo del desarrollo del presente trabajo, así como un capítulo adicional en el que se propone el trabajo futuro. Finalmente se anexarán los documentos pertinentes a la herramienta.. 8. Ambientes de Desarrollo de Software, SDE por sus siglas en ingles Software Development Environments..
(15) ISC-2003-1-3. 15. 1. MARCO TEÓRICO. Como se mencionó en la introducción a este trabajo de grado, la historia de las ciencias de la computación, especialmente en cuanto a la técnica y la metodología se refiere, ha sufrido muchos cambios.. Estos cambios han dado lugar a una evolución en cuanto a las. herramientas utilizadas para automatizar el proceso de desarrollo de software, así como también en cuanto a las distintas metodologías para lograr este mismo fin.. En el presente capitulo se introducirá y se explicara lo que son los SDE y cuál es su utilidad práctica en el campo del desarrollo de software. De igual manera, se introducirá y se explicará lo que es el lenguaje CSP, su uso y su aplicación en este campo. Por ultimo, se presentará una de las implementaciones del lenguaje CSP, sobre la cual se diseñó la herramienta.. 1.1 AMBIENTES DE DESARROLLO DE SOFTWARE (SDE). A lo largo de la evolución de las ciencias de la computación, los sistemas de software han ido creciendo tanto en tamaño como en el número de desarrolladores involucrados en los.
(16) ISC-2003-1-3. 16. proyectos de construcción de dichos sistemas. Paralelamente a este crecimiento, también ha ido creciendo la demanda por software de calidad a precios razonables, así como también una necesidad por cumplir las metas propuestas en lo relacionado con los tiempos de entrega.. Todo esto ha llevado a que, a medida que la complejidad de los sistemas de software aumenta, se evalúe la eficacia y la eficiencia del proceso de desarrollo de software, lo que ha conducido a buscar un mejoramiento a dicho proceso. Existen personas que ven al proceso de desarrollo de software como uno muy dinámico y por lo tanto muy difícil de automatizar. De otro lado, existen aquellas que ven dicho proceso como uno con un ciclo de vida propio, con fases determinadas (i.e. análisis, diseño, desarrollo, etc.), en donde cada una de esas fases presenta una serie de tareas repetitivas y, por lo tanto, susceptibles de automatización.. Es en este último aspecto en donde aparecen los ambientes de desarrollo de software. Como lo expresa Springl, “Un proceso automatizado se presta a sí mismo para ser usado a través de un conjunto de herramientas cuyas interfaces guían al desarrollador a lo largo de cada actividad, y por lo tanto obliga a que todos los pasos [del proceso] sean tomados y en la secuencia correcta. Esto asegura resultados consistentes y mensurables, lo que a su vez conduce al tan deseado mejoramiento del proceso como tal.”9. 9. Springl, Milan. Rule-based Process Models. En línea: http://sern.ucalgary.ca/~springl/Seng609-01/seng609-. 01-rbde.html, 1998..
(17) ISC-2003-1-3. 17. Para lograr tal automatización es deseable contar con un modelo para, con base en tal modelo, diseñar y desarrollar las herramientas apropiadas para soportar todo el conjunto de actividades requeridas por el proceso. Springl propone que “Una aproximación al modelado del proceso [de desarrollo de software] es un ambiente, en donde la invocación de actividades está guiada por reglas construidas dentro del sistema. Esto asegura una precisa secuencia de eventos sin perder ningún paso, y por lo tanto asegura la consistencia del proceso.”10. Cuando Springl se refiere a “ambiente”, este hace referencia a “… la colección de herramientas de hardware y software que un desarrollador utiliza para construir sistemas de software.”11. Antes de seguir adelante hay que hacer una distinción importante entre lo que es un ambiente de programación y un ambiente de desarrollo de software. Todos los autores coinciden en que un ambiente de programación hace referencia a las herramientas que soportan la fase de codificación, es decir tareas relacionadas con la programación en pequeño (e.g. editar y compilar)12, 13, 14.. 10. 11. Ibíd. Dart,. Susan. et. al.. Overview. of. Software. Development. Environments.. En. línea:. http://www.ida.liu.se/~petfr/princprog/envpaper.pdf, Suecia. 12 Ibíd., p. 1. 13. Dewayne, Perry. Industrial Strength Software Environments. En:. Proceedings of IFIP '89 - 11th World. Computer Congress. Agosto 1989, San Francisco. 14 Para entender mejor los términos “programación en pequeño” y “programación en grande”, se puede consultar a Deremer y Kron, Programming In the Large Versus Programming In the Small, IEEE Transactions On Software Engineering. junio 1976..
(18) ISC-2003-1-3. 18. Por otro lado, un ambiente de desarrollo de software es definido como un “… conjunto altamente integrado de herramientas que soportan el proceso de desarrollo de software completo.”. En esa misma línea, Dart et al. dice “Por ambiente de desarrollo de software nos referimos a un ambiente que aumenta o automatiza las actividades comprendidas en el ciclo de desarrollo de software , incluyendo tareas de la programación en grande tales como administración de configuraciones y tareas de la programación en número tales como administración de proyectos y de equipo. También nos referimos a un ambiente que soporta mantenimiento de software prolongado y de gran escala.”15. Una vez hecha esta distinción, cabe anotar que existe gran cantidad de ambientes de desarrollo de software y que estos no son necesariamente iguales, por tanto es necesario hacer una clasificación.. Dart et al. hacen una clasificación basada en las tendencias que tienen un impacto significativo en dichos ambientes. Teniendo en cuenta esto, Dart et al. definen cuatro categorías que son:. Ambientes centrados en el lenguaje Este tipo de ambientes están construidos alrededor de un lenguaje particular, y, por lo tanto, proveen un conjunto exclusivo de herramientas para dicho lenguaje. Estos ambientes son altamente interactivos y proveen servicios limitados para tareas relacionadas con la programación en grande.. 15. Dart, Op. cit., p. 1..
(19) ISC-2003-1-3. 19. Ambientes orientados a la estructura Estos incorporan técnicas que le permiten al usuario manipular las estructuras directamente. La independencia hacia el lenguaje de las técnicas condujo a la noción de generadores para ambientes.. Ambientes de caja de herramientas Estos proveen una colección de herramientas que incluyen soporte para tareas relacionadas con la programación en grande que son independientes del lenguaje tales como administración de configuraciones y control de versiones. Hay muy poco, si algo, control definido por el ambiente y administración del uso de las herramientas.. Ambientes basados en métodos Estos incorporan el soporte para un amplio rango de actividades en el proceso de desarrollo de software, incluyendo tareas tales como administración de proyectos y de equipos (programación en números). Estos ambientes también incorporan herramientas para métodos particulares de especificación y diseño16.. De otra parte, Perry y Kaiser proponen un modelo general mediante el cual se pueden describir los SDE. Este modelo consiste en tres componentes interrelacionados que son: las políticas, los mecanismos y las estructuras. Las políticas hacen referencia a las reglas, las directrices, y las estrategias impuestas al programador por el ambiente. Los mecanismos se refieren a las herramientas, y los fragmentos de herramientas visibles y subyacentes. Por 16. Ibíd., p. 2..
(20) ISC-2003-1-3. 20. último, las estructuras tienen que ver con los objetos subyacentes y los objetos agregados sobre los cuales los mecanismos operan.17. A partir de la definición de este modelo general, Perry y Kaiser definieron una taxonomía de los ambientes de desarrollo de software basados en la escala. Esta escala hace referencia tanto al número de desarrolladores en un proyecto en particular, como también al tamaño del sistema de software que está siendo desarrollado. Ellos, al igual que Dart et al., también definieron cuatro categorías que son:. Modelo individual Este modelo representa un conjunto de herramientas para ser usadas por el programador individual que está trabajando en aislamiento y concentrado en la construcción de programas.. Modelo de familia Representa aquellas herramientas que adicionalmente facilitan las interacciones de pequeños grupos de programadores trabajando juntos. Estas herramientas suponen que los miembros del proyecto actúan de manera razonable y que solo una mínima parte de coordinación es necesaria entre ellos (usualmente suplida por servicios de administración de versiones).. Modelo de ciudad 17. Dewayne, Perry y Gail, Kaiser. Models of Software Development Environments. En: Proceedings of the. 10th International Conference on Software Engineering. Raffles City, Singapore, Abril 1988. p. 60-68..
(21) ISC-2003-1-3. 21. Representa aquellos ambientes que soportan grupos más grandes en cuanto a tamaño (de 20 o más desarrolladores), en donde los grados de libertad permitidos resultarían en completo caos si se aplicaran al modelo de familia. Es necesario un conjunto mucho más rico de políticas para soportar el grado de cooperación necesario en este tipo de ambientes.. Modelo de estado Este modelo soporta un conjunto, posiblemente heterogéneo, de SDE, consistente de uno o más de los otros modelos, y administra un conjunto uniforme de políticas a lo largo de estos ambientes.18. Hasta aquí se ha mostrado lo que es un ambiente integrado de software y cómo se clasifica. Teniendo en cuenta que los SDE “… son usados para desarrollar y mantener una diversa colección de objetos de software altamente interrelacionados en un contexto distribuido de usuarios múltiples.”19, los requerimientos de un ambiente de desarrollo de software son:. •. Soporte para un usuario individual, para realizar tareas de programación en pequeño.. •. Soporte para múltiples usuarios para tareas relacionadas con la programación en grande.. 18. Ibíd.. 19. Anderson, Kenneth et al. Chimera: Hypermedia for Heterogeneous Software Development Environments.. En: ACM Transactions on Information Systems (TOIS). New York. Vol. 18, No. 3 (jun. - jul. 2000); p. 211245..
(22) ISC-2003-1-3. •. 22. Soporte para la administración del ciclo de desarrollo de software20.. En esencia, el usuario requiere que el ambiente le provea soporte para todo el ciclo de desarrollo de software, desde la especificación pasando por la codificación hasta el mantenimiento del sistema de software.. 1.2 COMMUNICATING SEQUENTIAL PROCESSES (CSP). En esta sección se hará una breve descripción de este lenguaje descrito por primera vez en el año 1978 por C. A. Hoare21. Según este artículo22 acerca de CSP, Hoare propone que adicionalmente a los constructos en los que el estado interno de una maquina, ejecutando un programa, se modifica, como es el caso de la asignación, también deben considerarse los constructos que modifiquen y que tengan en cuenta el estado externo de la misma23.. Para entender mejor el lenguaje desarrollado por Hoare, se hace necesario comprender, como primera medida, el funcionamiento de los sistemas concurrentes. Los sistemas que presentan concurrencia tienen varios procesos haciendo avanzando simultáneamente hacia la terminación . Adicionalmente, estos procesos, o tareas, o hilos de ejecución, pueden estar ejecutándose en paralelo, o en un solo procesador. Los procesos se comunican entre ellos 20. Dart, Op. Cit.. 21. Hoare, C. A. R. Communicating Sequential Processes. En: Communications of the ACM. New York. Vol. 21, No. 8 (ago. - sep. 1978); p. 666-677. 22. Hoare eventualmente escribiría un libro acerca de este tema. Dicho libro fue publicado en 1985 por la. editorial Prentice Hall bajo el titulo “Communicating Sequential Processes”. 23. Hoare. Op. Cit. p. 1.
(23) ISC-2003-1-3. 23. para determinar en qué estado se encuentran en un momento dado, y así sincronizar su ejecución. Esta situación es necesaria dado que cada proceso tiene su propia vida, y, en general, un estado, independiente del de los demás.. Es gracias a la situación anteriormente apuntada que se hizo necesario el desarrollo de un nuevo lenguaje que sirviera para ser una notación y una teoría para describir y analizar sistemas cuyo interés primario se origina de las formas en las que diferentes componentes interactúan al nivel de comunicación24.. Según Hoare, el objetivo principal del desarrollo de este nuevo lenguaje es “ ... encontrar la teoría matemática más simple posible que cumpla con las siguientes propiedades: . Este debe describir un amplio rango de aplicaciones de computación interesantes, desde máquinas de vender, pasando por control de procesos y simulación de eventos discretos, hasta sistemas operativos de recursos compartidos.. . Debe proveer la capacidad de presentar una implementación eficiente en una gran variedad de arquitecturas convencionales y novedosas, desde computadores con tiempo. compartido,. pasando. por. microprocesadores. hasta. redes. de. microprocesadores comunicándose. . Este debe proveer asistencia clara al programador en sus tareas de especificación, diseño, implementación, verificación y validación de complejos sistemas de computador”25.. 24. Ibíd. p. 2. 25. Hoare, C. A. R. The Communicating Sequential Processes. Prentice Hall, 1985. p. 207..
(24) ISC-2003-1-3. 24. De acuerdo con lo planteado por Hoare, dentro de los métodos de estructuración de programas son tres los constructos básicos más usados en la forma como se programa, aún hoy en día. Estos tres constructos básicos son el de iteración (e.g. el ciclo while), el constructo de alternativa (e.g. el condicional if..else), y por último la composición secuencial normal, la cual es comúnmente expresada por medio de un punto y coma (;)26.. Teniendo en cuenta el hecho de que los paradigmas convencionales de programación fueron diseñados principalmente para ejecutar programas secuenciales, los. constructos. anteriormente mencionados son suficientes para desarrollar tal tipo de aplicaciones. No obstante, estos no son suficientes cuando lo que se pretende es desarrollar aplicaciones concurrentes. Debido a esto, Hoare introduce otro tipo de constructos que servirán para comunicar conjuntos de procesos, que en su interior se comportan de forma secuencial, pero que se hacen su procesamiento conjunto de manera concurrente.. Según la teoría de CSP, estos constructos adicionales, necesarios para desarrollar aplicaciones concurrentes, son: lectura (input), escritura (output) y composición paralela. Los constructos de lectura y escritura se operan sobre una estructura denominada canal, la cual es de tipo sincrónica, lo que hace que no se permita memoria intermedia interna. El constructo de composición se opera sobre dos o más procesos de acuerdo a una serie de reglas formales definidas en su trabajo de 1985.. Hasta ahora se ha mencionado el origen y la intención del desarrollo de CSP, sin embargo aún no se ha hecho mención explicita en lo referente a las estructuras necesarias para el 26. Hoare. Op. Cit. p. 1.
(25) ISC-2003-1-3. 25. desarrollo de aplicaciones concurrentes, a las que hace referencia la especificación de este lenguaje.. Las principales estructuras de esta especificación son los procesos y los canales. Un proceso en CSP es un tipo de estructura en la cual se cumple estrictamente la noción de encapsulamiento, esto significa que tanto los atributos como los métodos tienen visibilidad privada, y por lo tanto no pueden ser invocados de forma explícita. Por otro lado, tales procesos solo pueden comunicarse entre ellos leyendo y/o escribiendo en el otro tipo de estructuras de CSP denominadas canales. Por último, tal tipo de procesos carecen de identidad, dentro del lenguaje CSP, lo cual hace imposible referirse a ellos de manera explícita, esto hace que la comunicación entre procesos deba hacerse exclusivamente a través de canales27. En esa misma línea, un proceso tiene una lista de operaciones internas que son ejecutadas secuencialmente, así pues un proceso termina cuando la ejecución alcanza el final de esta lista.. Aun cuando se ha dicho que los procesos contienen una lista de operaciones secuenciales que operan sobre datos internos, de la misma manera que lo hace un programa secuencial, no se debe concluir que esta es la única forma de derivar procesos. De hecho, una de las características más interesantes de CSP es la derivación de estos a través de la composición. Esta composición entre procesos puede ser secuencial («;») o paralela («||»).. 27. Lea, Doug. Programación Concurrente en JAVA™ Principios y Patrones de Diseño. Segunda Edición.. Madrid, Addison Wesley, 2001..
(26) ISC-2003-1-3. 26. Un ejemplo en cuanto a la forma de componer procesos es la siguiente: supóngase que P, Q y R son procesos. Se puede componer procesos así: •. P = (Q ; R). •. P = (Q || R). En el primer caso, el proceso P es equivalente a la composición secuencial entre los procesos Q y R, esto quiere decir que P termina una vez se termine la ejecución del proceso R, antecedido de la ejecución correcta del proceso Q. En el segundo caso, P es equivalente a la composición paralela entre Q y R, es decir que la ejecución de P es la ejecución concurrente de los procesos constitutivos, y por lo tanto P no terminará hasta que ambos, Q y R, no terminen sus respectivas ejecuciones.. El otro tipo de estructura fundamental dentro de esta especificación es conocida como canal. Un canal es una estructura que permite la comunicación entre procesos, esta estructura es síncrónica por definición. Otra característica fundamental de este tipo de estructuras es que solo permite dos tipos de operaciones, la de lectura («?») y la de escritura («!») que lo que hace es aportar valores de datos28. Según Hoare “ ... debemos observar la convención de que los canales son usados para comunicación en solamente una dirección y entre solamente dos procesos.”29, sin embargo en otras implementaciones otro tipo de canales es desarrollado30.. 28. Ibid.. 29. Hoare. Op. Cit. p. 114.. 30. En JCSP se desarrollaron otro tipo de canales tales como uno a muchos, muchos a uno, y muchos a muchos..
(27) ISC-2003-1-3. 27. Estos canales son estructuras pasivas de sincronización, es decir que no asumen ningún rol más que el de transmisión de datos y por lo tanto no tienen memoria. Es por esto que la comunicación entre procesos debe ser sincrónica en el sentido que el proceso escritor debe esperar a que el proceso lector se encuentre listo y viceversa. Los mensajes que se envían usando estos canales, son por regla objetos pasivos sobre los cuales operan los procesos comunicantes.. La notación definida para este tipo de estructuras es como sigue: •. c!x → P. •. c?x → P. En el primer caso, P se activa cuando se ha escrito el valor de la variable x en el canal c, el proceso P. En el segundo caso, el proceso P se activará, cuando el mensaje enviado por el canal c sea leído y almacenado en la variable x. Cabe anotar que en ningún caso se dará la comunicación hasta tanto los dos procesos comunicantes no estén preparados para realizar tal operación.. Por último, retomando uno los conceptos centrales dentro la especificación CSP, el relacionado con la composición paralela entre procesos, podemos observar que este tiene una serie de reglas formales que dictan su comportamiento, y, por lo tanto, dicho comportamiento puede ser estudiado analíticamente. Dado que los procesos son estructuras que ejecutan sus instrucciones sobre datos internos, de forma secuencial y de manera independiente entre sí, los procesos a nivel superior se crean por composición. Esta composición paralela hace que los procesos constitutivos de tal composición sean ejecutados de manera concurrente..
(28) ISC-2003-1-3. 28. Resumiendo lo anteriormente anotado, sea c un canal, P y Q un par de procesos, y x una variable, se tiene que: c!x → P significa que al escribir en c se activa P. c?x → P significa que al leer de c se activa P. P;Q. significa que P va seguido de Q.. P||Q. significa que P y Q se ejecutan en paralelo.. P[]Q. significa que se ejecuta P o Q pero no ambos.31. A propósito de este último operador, lo explica mejor Lea cuando dice: “El operador de elección P [ ] Q requiere que tanto P como Q sean procesos con sus comunicaciones activadas (de la forma d?y → R o bien d!y → R). La selección del proceso que se ejecutará depende de la comunicación que esté lista: no sucede nada mientras no está preparada una de las comunicaciones o bien las dos. Si una está preparada (o pasa a estarlo), entonces se sigue ese camino. Si ambas están preparadas (o pasan a estarlo), entonces se puede efectuar cualquier elección (de forma no determinista).32”. Dada la notación presentada anteriormente y suponiendo que c es un canal sobre el cual el proceso P escribe y desde el cual el proceso Q lee, la regla que gobierna la comunicación entre procesos que están siendo ejecutados bajo la composición paralela es la siguiente:. (c!v → P | | c?x → Q(x)) = c!v → (P | | Q(v)) 31. 32. Lea, Doug. Op. Cit. p. 385. Ibid..
(29) ISC-2003-1-3. 29. Esta regla nos dice que para que dos procesos sean activados, es decir su ejecución pueda continuar normalmente, de manera concurrente, el canal de comunicación tiene que estar sincronizado puesto que, después de la escritura de un valor v sobre el canal, ambos procesos se activan concurrentemente, con el proceso lector ejecutando el remanente de sus instrucciones sobre el valor que fue escrito en dicho canal.. Finalmente, la especificación de CSP nos dice que, de la misma manera en que un proceso termina su ejecución cuando alcanza el final de su lista de comandos, una composición paralela de procesos termina su ejecución cuando todos los procesos constitutivos de tal composición terminan sus respectivas ejecuciones.. 1.3 COMMUNICATING SEQUENTIAL PROCESSES FOR JAVA (JCSP). Como puede observarse en el título, JCSP es una implementación de la especificación CSP para la plataforma java. JCSP está implementado como una librería que puede ser utilizada por cualquier aplicación que desee hacer uso del poder de concurrencia de CSP. Esta sección sigue las pautas del documento de Peter Welch33. Como se indica en el párrafo anterior JCSP es una librería concebida para adicionar al lenguaje java las ventajas de una concurrencia basada en los constructos CSP. Aun cuando. 33. Welch,. Peter.. Process. Oriented. Design. for. http://www.cs.kent.ac.uk/projects/ofa/pdpta-2002/jcsp.pdf. Java:. Concurrency. for. All.. En. línea:.
(30) ISC-2003-1-3. 30. java ya viene con un mecanismo para manejar concurrencia, este mecanismo no es el más adecuado y ha dado lugar a problemas.. En java, la concurrencia se maneja a través del concepto de monitores: estos imponen un candado sobre un objeto a la vez lo que hace la sincronización entre hilos de ejecución bastante compleja. JCSP no pretende reemplazar el paradigma orientado a objetos, sino, más bien, extenderlo para proveerlo de mecanismos de ejecución concurrente más limpios. De hecho, JCSP está construido sobre el modelo de monitores que java ofrece: la diferencia radica en que se ha procurado construir muy cuidadosamente cada una de las primitivas CSP.. En contraste con lo que sucede en java, donde un solo hilo de ejecución puede tocar y activar distintos objetos, con JCSP solo se permite que el hilo que creo al proceso pueda activarlo y manipularlo. Esto reduce la complejidad del sistema por cuanto permite razonar localmente acerca del estado de este tipo de objetos.. Dado que JCSP es una implementación de CSP, el primero comparte las mismas características teóricas del segundo. Así que en esta sección nos centraremos en describir las estructuras primitivas de JCSP.. De la misma manera que CSP, JCSP cuenta con dos estructuras principales: los procesos y los canales, pero, además, vale la pena mencionar otro tipo de estructura que, aunque no se menciono en la sección de CSP, está implementada en esta librería: se trata de las alternativas..
(31) ISC-2003-1-3. 31. Procesos En JCSP los procesos representan clases que implementan la interfaz CSProcess. Esta interfaz contiene la declaración de un único método, el método run(). La ejecución de este método define el comportamiento del proceso. Al igual que en la especificación del lenguaje, JCSP impone estrictamente el encapsulamiento de los procesos.. Esto implica que tanto los atributos como los métodos deben tener visibilidad privada. En JCSP los únicos métodos que pueden ser declarados como públicos son los métodos constructores y el método run. Los atributos de un proceso pueden ser tipos de datos primitivos u objetos pasivos, pero solo se permite la creación y manipulación de tales objetos por el dueño de estos.. Para que los objetos que implementan la interfaz sean activados, JCSP requiere que sean pasados como argumentos a otro objeto que los compone y crea un hilo de ejecución separado para cada uno de estos. Una vez en el argumento de este proceso compositor, los objetos son activados y comienzan a ejecutar el código correspondiente de sus métodos run().. Este proceso compositor puede ser de dos clases: Sequential y Parallel. El proceso secuencial se encuentra en la especificación por razones de completitud, ya que, en realidad, el comportamiento secuencial es manejado por java. El otro tipo de.
(32) ISC-2003-1-3. 32. proceso compositor el es proceso Parallel. Este proceso lanza un número arbitrario de procesos simultáneamente y espera a que todos ellos terminen antes de continuar.. La estructura general de este tipo de procesos es como sigue:. import jcsp.lang.*; ... otros imports class Ejemplo implements CSProcess { ... objetos compartidos de sincronización, privados (canales, etc.) ... información privada de estado ... constructores públicos ... métodos privados de soporte (hacen parte del método run) ... método público run (el proceso comienza aquí) }34. Una vez el proceso comienza su ejecución, su hilo correspondiente nunca puede abandonar el objeto; de igual manera, ningún hilo foráneo puede ingresar. Esto asegura que el único responsable de modificar y mantener los campos privados sea el objeto propietario de los mismos. Otros procesos pueden pedir la modificación del estado del proceso, pero solo a través de canales bien definidos, y en todo caso es decisión del proceso aceptar tales peticiones. En consecuencia, ambos nodos deben estar de acuerdo al momento de intercambiar información, lo que garantiza un estado consistente en todo momento.. Canales 34. Ibid..
(33) ISC-2003-1-3. 33. Los canales son objetos de sincronización pasiva mediante los cuales un par de procesos intercambian información. Los canales pueden ser entendidos como una analogía a los cables en una conexión de hardware. Tanto en JCSP como en una conexión de hardware, estos canales no tienen la capacidad de almacenar información, en tanto medios de transmisión.. Para evitar la perdida de información, la comunicación sobre estos canales debe ser sincronizada. Esto quiere decir que solo cuando los dos procesos estén listos para la comunicación, esta se dará; de lo contrario, uno de los dos procesos se bloqueará hasta que el que no estaba listo, lo esté.. En JCSP se implementaron distintos tipos de canal en función del número de lectores y escritores que pueden usar seguramente el canal. Los tipos de canal son: •. One2OneChannel: Solo se permite un lector y un escritor sobre el canal.. •. One2AnyChannel: Se permite un solo escritor y varios lectores.. •. Any2OneChannel: Permite varios escritores pero un solo lector.. •. Any2AnyChannel: Permite varios escritores y varios lectores.. Para todos los tipos de canal, en un momento dado, solo pueden estar usando el canal un par de procesos. Esto significa que, por ejemplo, el canal Any2AnyChannel solo permite la comunicación entre dos procesos en cualquier momento dado, pero permite a varios escritores y varios lectores compartir el mismo canal..
(34) ISC-2003-1-3. 34. Como se mencionó anteriormente, el canal no guarda información: sin embargo, en la implementación de JCSP, se permite crear un objeto contenedor para que el canal tenga la capacidad de almacenar información. Este objeto puede ser de varios tipos. Buffer,. InfiniteBuffer,. OverFlowingBuffer,. OverWriteOldestBuffer,. OverWritingBuffer, y ZeroBuffer.. Alternativa Aunque JCSP provee el mecanismo de comunicación entre procesos a través de canales, los procesos también necesitan esperar pasivamente a que uno o más eventos ocurran. JCSP provee un mecanismo mediante el cual un proceso puede esperar pasivamente por un suceso y, además, tres mecanismos para elegir cuando más de un evento se produce simultáneamente.. Cada elemento sobre el cual el proceso puede esperar pasivamente recibe el nombre de guarda. Una guarda puede ser un AltingChannelInput, un proceso CSTimer, un proceso Skip. El canal AltingChannelInput es una guarda que se activa tan pronto como existen datos disponibles para ser leídos, la guarda CSTimer se activa cuando el tiempo especificado ha expirado. Por último, la guarda Skip siempre está activa. El constructo Alternative espera hasta que al menos una de las guardas se encuentre activa. Cuando más de una guarda se activa al tiempo, existen tres mecanismos para seleccionar entre estas.. Los mecanismos de selección entre guardas activas son:.
(35) ISC-2003-1-3. •. 35. Arbitraria: Como su nombre lo indica, el sistema escoge una de las guardas aleatoriamente. Este mecanismo existe para cumplir con la especificación de no determinismo definida en CSP.. •. Con prioridad: En este caso el sistema escoge de acuerdo con una prioridad definida por la posición en el orden del conjunto de guardas.. •. Equitativa: En esta situación se tienen en cuenta las decisiones pasadas para escoger de manera justa a cada una de las guardas, asegurando con esto que ninguna guarda acapare el servicio del proceso.. Por último, veremos la composición paralela y cómo esta articula los elementos antes expuestos en la red de procesos.. Una red de procesos está definida como “... simplemente una composición paralela de procesos conectados a través de un conjunto de objetos de sincronización pasiva (e.g. cables) y es en sí misma un proceso.”35 Ya hemos visto lo que son los procesos y los canales, ahora tenemos que investigar la composición.. La composición paralela de procesos se logra por medio de un proceso JCSP llamado Parallel. Este proceso tiene un constructor público, el cual recibe el conjunto de procesos que desea ejecutar en paralelo. Una vez se tiene esta situación, se invoca el método run() del proceso paralelo, el cual invoca simultáneamente el método run respectivo de cada uno de los procesos que le fueron pasados en su construcción. El proceso termina si y solo si todos y cada uno de los procesos de la composición paralela ha terminado. 35. Ibid..
(36) ISC-2003-1-3. 36. Ejemplo Para ilustrar mejor los conceptos anteriormente anotados se presenta un ejemplo muy simple en el que un proceso escritor envía a otro proceso lector una serie de números generados aleatoriamente.. El proceso escritor, al igual que el lector, sigue la estructura anteriormente expuesta. Este proceso genera números aleatorios y los envía por su canal de salida. import jcsp.lang.*; import java.util.Random; public class Escritor implements CSProcess { private ChannelOutput outputPort0; private Random rand; public Escritor (ChannelOutput outputPort0) { this.outputPort0 = outputPort0; } public void run() { rand = new Random(); while(true) { Integer randNumber = new Integer(rand.nextInt()); outputPort0.write(randNumber); } } }.
(37) ISC-2003-1-3. 37. En el caso del proceso lector este lee el objeto proveniente de su canal de entrada y lo imprime en pantalla. import jcsp.lang.*; public class Lector implements CSProcess { private ChannelInput inputPort0; public Lector (ChannelInput inputPort0) { this.inputPort0 = inputPort0; } public void run() { while (true) { System.out.println ((Integer)inputPort0.read()); } } }.
(38) ISC-2003-1-3. 38. Como se puede observar cada uno de estos procesos es independiente del otro; como consecuencia, ninguno tiene referencia implicita ni explicita del otro proceso. Debido a esto se necesita una clase que provea las conexiones entre los procesos, es decir, que defina la topología de la red de procesos. import jcsp.lang.*; public class ProcessNetwork { public static void main (String[] args) { One2OneChannel channel0 = new One2OneChannel(); Escritor escritor = new Escritor(channel0); Lector lector = new Lector(Channel0); CSProcess[] parArray = new CSProcess {escritor, lector}; Parallel par = new Parallel(parArray); par.run(); } }. Como se puede observar, la clase encargada de crear y conectar, mediante canales, los procesos, es la clase principal. Esta clase puede ser, como en este caso, la que contiene el método main, o, por el contrario, una clase que declare otro proceso..
(39) ISC-2003-1-3. 39. Si se sigue el camino posterior, este nuevo proceso puede ser utilizado en una nueva red de procesos, con lo cual se configuraría una red de redes de procesos. En este ejemplo solo se ha configurado una red con un lector y un escritor, sin embargo, de la misma manera en que se presentó, se puede configurar una red con un solo lector y varios escritores, varios lectores y un solo escritor, o varios lectores y varios escritores intercambiando información.. Figura 1. Red de procesos con dos procesos.
(40) ISC-2003-1-3. 40. 2. HERRAMIENTAS UTILIZADAS. En el presente capítulo se analizarán las herramientas utilizadas en el desarrollo de la aplicación. Primero, se desarrollará una descripción de la plataforma sobre la cual se diseñó e implementó la aplicación, y, luego, se detallarán las tecnologías usadas en la implementación de la herramienta.. Estas tecnologías incluyen los plug-in EMF, GEF, y la tecnología de generación de texto basado en plantillas Velocity.. 2.1 ECLIPSE. Como se puede inferir de los conceptos desarrollados en la sección 1.1, existen muchas herramientas que encajan en la definición de lo que es un ambiente de desarrollo de software. En la actualidad, existe un océano de tales herramientas; la mayoría de ellas diseñadas para trabajar con base en un lenguaje claramente definido (i.e. JAVA, C, C++, etc.36). Adicionalmente, muchas de estas herramientas son propietarias, es decir, son comerciales y los derechos sobre el código fuente le pertenecen a la compañía 36. Brown, Richard. March of the IDEs. En: LinuxUser & Developer. Londres. No. 15 (oct. 2001); p. 27-35..
(41) ISC-2003-1-3. 41. desarrolladora de esta. Ejemplos de tales herramientas son JBuilder37 de Borland, Visual Studio .NET38 de Microsoft, etc. Las herramientas restantes tienen un esquema de licenciamiento39,40 distinto que permite no solo utilizar la herramienta de forma gratuita, sino que, a la vez, permite modificar el código fuente y extender la herramienta sin ningún tipo de perjuicio para el proveedor de tales extensiones. Algunas de las herramientas más representativas de esta categoría son Netbeans41 de Sun Microsystems y Eclipse de IBM.. A medida que el número de herramientas de este tipo crece, crece también la necesidad de interoperabilidad entre estas. Esto se debe, principalmente, al incremento en el tamaño de los equipos de desarrollo, así como también a la distribución geográfica de las ubicaciones de tales equipos y de sus integrantes. Teniendo esto en mente, se diseñó una plataforma que cumpliera con tales requerimientos. Esta plataforma recibió el nombre de Eclipse.. 37. En línea: http://www.borland.com/jbuilder/. 38. En línea: http://msdn.microsoft.com/vstudio/. 39. Senoir. Corps.. Tech. Center.. Understanding. Licenses.. http://www.seniortechcenter.org/reference_library/software/understanding_licenses.php 40 Open Source. The Approved Licenses. En línea: http://www.opensource.org/licenses/ 41 En línea: http://www.netbeans.org/. En. línea:.
(42) ISC-2003-1-3. 42. Hasta ahora se ha mencionado dicha herramienta en varias ocasiones, pero aún no se ha dicho qué es esta herramienta. Eclipse, como ya se ha mencionado anteriormente, es un ambiente integrado de desarrollo o IDE por sus siglas en ingles. El consorcio llamado Eclipse Consortium define a Eclipse como “… un IDE para cualquier cosa, y para nada en particular”42. Gallardo la define como “…plataforma de desarrollo extensible, de código abierto, basada en Java”43. Bolour dice al respecto “Eclipse es una plataforma extensible para desarrollar IDE”44. Shah dice “… esta [Eclipse] no es un IDE en sí misma, sino más bien una plataforma para construir IDE a través de una arquitectura de plug-in”45.. Partiendo de las anteriores definiciones, se puede decir que Eclipse es una plataforma extensible para construir ambientes integrados de desarrollo, pero que, a su vez, incluye varios de estos (e.g. JDT, PDE).. 2.1.1 Arquitectura. Eclipse fue diseñada e implementada para cumplir con los siguientes criterios: •. Soportar la construcción de una gran variedad de herramientas para el desarrollo de aplicaciones.. • 42. Object. Soportar una cantidad ilimitada e irrestricta de proveedores de herramientas. Technology. Internacional,. Inc.. Eclipse. Platform. Technical. Overview.. En. línea:. http://www.eclipse.org. Julio 2001, actualizado en febrero de 2003. 43. Gallardo,. David.. Getting. Started. With. The. Eclipse. Platform.. En. línea:. http://www-. 106.ibm.com/developerworks/opensource/library/os-ecov/ 44 Bolour, Azad. Notes on the Eclipse Plug-in Architecture. En línea: http://www.eclipse.org/articles/ArticlePlug-in-architecture/plugin_architecture.html 45 Shah, Rawn. Working the 106.ibm.com/developerworks/library/eclipse/. Eclipse. Platform.. En. línea:. http://www-.
(43) ISC-2003-1-3. 43. •. Soportar herramientas para manipular distintos tipos de contenidos.. •. Facilitar la integración transparente de herramientas a lo largo, y dentro, de diferentes tipos de contenidos y proveedores de herramientas. Soportar ambientes de desarrollo de aplicaciones basados tanto en interfaces. •. gráficas como en interfaces no gráficas. •. Operar en múltiples plataformas (e.g. Windows®, Linux™, etc.).. •. Utilizar el poder y la popularidad de Java, para desarrollar herramientas46.. Para lograr tales objetivos, Eclipse desarrolla un concepto que le permite a esta plataforma observar los criterios anteriormente descritos. Dicha plataforma está construida alrededor del concepto de puntos de extensión. Tales puntos de extensión son puntos bien definidos dentro del sistema que permiten a otras herramientas, llamadas plug-in, contribuir en funcionalidad a la plataforma47.. El plug-in es la unidad más pequeña dentro de la plataforma, y, como se mencionó anteriormente, cada una de estas unidades aporta una funcionalidad nueva, o extiende una existente. De hecho la plataforma en sí misma está compuesta de varios plug-in; sin embargo, una excepción a este modelo es el kernel de la plataforma llamado Platform Runtime, el cual está encargado de administrar los plug-in que se encuentran activos en la plataforma en un momento determinado, pero no es un plug-in per se.. 46. 47. Object Technology International, Inc. Op. Cit. p. 3 Eclipse. Platform Plug-in Develoment Guide. En: Incluida con la herramienta. Sección: Platform. Architecture..
(44) ISC-2003-1-3. 44. Figura 2. Arquitectura de la plataforma Eclipse.. Como se anotó en el párrafo precedente, el plug-in, que es la unidad de desarrollo más pequeña que maneja la plataforma, es un componente que provee un cierto tipo de servicio dentro del contexto del workbench de Eclipse48. Dichos plug-in deben estar escritos en Java para soportar la multiplicidad de plataformas. Típicamente un plug-in consiste de un conjunto de clases y recursos empacados en un archivo JAR. Estos recursos generalmente corresponden a distintos tipos de contenido y son necesarios para el funcionamiento correcto del plug-in.. Cada plug-in tiene, además, un descriptor llamado manifiesto, el cual declara atributos necesarios para el adecuado funcionamiento de este. Estos atributos contienen entre otros, 48. Bolour. Op. Cit. Sección 2.
(45) ISC-2003-1-3. 45. el nombre del plug-in, las dependencias hacia, y las interconexiones con, los demás plug-in. Estas interconexiones están definidas en términos de los puntos de extensión que cada plug-in ha declarado. El modelo de interconexión es relativamente simple “… un plug-in declara un número cualquiera de puntos de extensión nombrados, y cualquier número de extensiones a uno o más puntos de extensión declarados en otros plug-in”.49. 2.1.2 Funcionamiento. Como se mencionó anteriormente, el módulo correspondiente a la ejecución de la plataforma denominado “Platform Runtime” (Ver Figura 1.), es el único componente de la plataforma que no sigue la arquitectura de plug-in. Este módulo es el encargado de activar la plataforma, así como los plug-in correspondientes en el tiempo adecuado.. Cuando se inicializa la plataforma, el módulo de ejecución se encarga de encontrar el conjunto de plug-in disponibles. Esto lo logra analizando las carpetas que se encuentran en el directorio “plugins”, dado que cada plug-in instalado tiene un directorio único dentro de este. Una vez hecho esto, el módulo lee cada uno de los manifiestos de los plug-in encontrados, para crear con esta información un registro. Este registro no es más que una representación en memoria de la información contenida en cada manifiesto. Esta información puede ser, y de hecho es, obtenida en tiempo de ejecución por otros plug-in a través de un API proveído por la plataforma. Debido a este mecanismo de descubrimiento y carga de la información de los plug-in, estos no pueden ser adicionados en tiempo de ejecución sino que requieren reiniciar la plataforma para ser reconocidos por el registro.. 49. Object Technology Internacional, Inc. Op. Cit. p. 4.
(46) ISC-2003-1-3. 46. Dado que el manifiesto de un plug-in está escrito en XML, y adicionando a esto el hecho de que la plataforma no carga los plug-in al iniciarse, se logra que la huella en memoria principal de cada plug-in instalado sea muy baja. Este hecho permite tener un número indefinido de plug-in sin que esto afecte de manera determinante el rendimiento de la plataforma, especialmente en la inicialización.. Un plug-in cualquiera se activa justo en el momento en que el código de este necesita ser ejecutado. Una vez activo este usa el API para acceder al registro de la plataforma, logrando de esta manera descubrir todos los puntos que han sido extendidos para contribuir a su funcionalidad. Cabe anotar que una vez se active un plug-in este permanecerá activo hasta que sea cerrada la plataforma.. Al respecto, en el documento titulado “Eclipse Platform Technical Overview”, la OTI dice: “Al determinar por adelantado el conjunto de plug-in disponibles, y al soportar un intercambio significante de información entre plug-in sin tener que activar a ninguno de ellos, la plataforma puede proveer a cada plug-in con una rica fuente de información acerca del contexto en el que está operando. Este contexto no puede cambiar mientras que la plataforma está corriendo, así que no hay necesidad de complicados eventos del ciclo de vida para informar a los plug-in cuando el contexto cambia. Una larga secuencia de inicialización es evitada, tal que esto es una fuente común de errores que se origina en un orden impredecible de activación de los plug-in”50.. 50. Object Technology Internacional, Inc. Op. Cit. p. 5.
(47) ISC-2003-1-3. 47. 2.2 OTRAS TECNOLOGÍAS. En esta sección se hará una breve descripción de algunas de las tecnologías usadas en el desarrollo de la aplicación. La primera es EMF, que es una plataforma para la generación de código basado en un modelo. Una segunda es GEF la cual es una plataforma para desarrollar editores gráficos51. Por último una tecnología denominada Velocity la cual es un motor de plantillas basado en java52.. 2.2.1 Eclipse Modeling Framework (EMF). EMF es un framework, desarrollado por el consorcio Eclipse, que tiene como función la generación de código java, para construir herramientas y otras aplicaciones tomando como base un modelo estructurado.. Cuando se habla de un modelo estructurado, se está haciendo referencia a una descripción formal del modelo. Esta descripción en diseño orientado a objetos usualmente se hace usando el lenguaje UML. Para que tal descripción se considere completa, se utilizan distintos artefactos de este lenguaje como son los diagramas de clases, de componentes, de interacción, etc.. 51. GEF. En línea: http://www.eclipse.org/gef/. 52. Velocity. Design Page. En línea: http://jakarta.apache.org/velocity/design.html.
(48) ISC-2003-1-3. 48. En el caso de EMF, la descripción de este modelo solo requiere un subconjunto de los artefactos del lenguaje UML. En particular, solo requiere la especificación del diagrama de clases para poder generar código java consistente e integrable a la plataforma Eclipse. EMF utiliza XMI (XML Metadata Interchange) como forma canónica de definición del modelo. Para lograr transformar el modelo a la forma canónica de definición existen varias opciones: •. Crear el documento XMI directamente utilizando un editor de texto o de XML.. •. Exportar el documento XMI desde una herramienta de diseño como Rational Rose.. •. Anotar interfaces java con propiedades del modelo.. Una vez definido el modelo a usar, EMF puede generar código java con las clases correspondientes. Tales clases llevan una implementación por defecto que, entre otras cosas, provee beneficios como mecanismos de notificación de cambios, soporte para la persistencia usando documentos XMI, y un API reflectivo para manipular objetos EMF.. Estas clases generadas pueden ser modificadas a voluntad del desarrollador y sin embargo ser actualizadas sin que esto implique perder los cambios realizados. Esto hace de EMF un framework que acelera el proceso de desarrollo de herramientas y aplicaciones significativamente, al tiempo que proporciona una implementación consistente con la especificación del modelo..
(49) ISC-2003-1-3. 49. 2.2.2 Graphical Editing Framework (GEF). Como se menciono anteriormente GEF es un framework o “plataforma”, la cual está diseñada para facilitar el desarrollo de editores gráficos. Dicha plataforma no debe ser confundida con la que está siendo desarrollada por el grupo Tigris53.. Esta plataforma está compuesta por dos componentes. Uno de estos componentes es denominado draw2d, el cual es un sistema liviano de figuras en dos dimensiones. Este componente está desarrollado sobre SWT54, y tiene la responsabilidad de dibujar los componentes del modelo en la pantalla. Esta responsabilidad incluye la de organizar los componentes a nivel visual, así como también la de proveer un mecanismo para que el proceso de dibujo de tales componentes sea más rápido y eficiente55.. El segundo componente es el denominado GEF. Así como el componente anterior es el encargado de dibujar los componentes del modelo en la pantalla, la función de este componente es proveer los mecanismos MVC para poder construir el editor gráfico.. 53. http://gef.tigris.org/. 54. Standard Widget Toolkit.. 55. Eclipse GEF. GEF Overview. En línea: http://www.eclipse.org/gef/.
(50) ISC-2003-1-3. 50. En la documentación incluida se pone de manifiesto que GEF impone de forma estricta el patrón MVC, asegurando de esta manera consistencia entre distintos editores gráficos desarrollados sobre esta plataforma. A diferencia del modelo MVC que utiliza Swing, GEF no tiene vistas diseñadas específicamente para cierto tipo de objetos en el modelo. Esto permite que prácticamente cualquier vista pueda representar prácticamente cualquier modelo. De hecho, en GEF la correspondencia no tiene que ser, necesariamente, 1 a 156.. Esta separación entre el modelo y la vista, le permiten a esta plataforma proveer los servicios para desarrollar un editor gráfico sin tener absolutamente ninguna restricción en cuanto al modelo. Adicionalmente a lo anterior, la separación entre los componentes de este framework asegura que todos los editores construidos sobre él tengan el mismo “look & feel”57.. Figura 3. Arquitectura MVC GEF Copyright (c) IBM Corp. and others 2000, 2003. All Rights Reserved.. 56. GEF Developer Guide. Model-View-Controller Paradigm. Documentación incluida en el componente.. 57. Eclipse GEF. Op. Cit. p. 1.
(51) ISC-2003-1-3. 51. En el framework GEF el componente draw2d contiene los elementos visuales, es decir que a través de este componente se representarán las vistas correspondientes al modelo. Las figuras de este componente tienen métodos específicos de representación visual, como son la notificación de eventos generados por el usuario, la actualización de la representación gráfica propia y la de sus hijos, etc.. De otra parte, el modelo existe independiente de GEF y es precisamente por esto que cualquier modelo puede ser adaptado a cualquier vista. Pero, para que esto sea posible, se necesita de un tercer componente. Este componente fundamental son los controladores.. En GEF los controladores toman la forma de clases llamadas EditPart. Estas clases controladores son indispensables para ligar el modelo y las vistas asociadas a este. Los controladores tienen la responsabilidad de notificar a la vista cuando el modelo ha cambiado. De la misma manera, estos generan los comandos necesarios para modificar el modelo, dado una serie de eventos provenientes de las vistas. En ningún caso, entre el modelo y la vista debe existir algún tipo de referencia. Es más, solo los EditPart tienen acceso tanto al modelo como a las vistas, así pues ni los primeros ni los segundos tienen acceso a su EditPart respectivo..
(52) ISC-2003-1-3. 52. Figura 4. Arquitectura EditPart Copyright (c) IBM Corp. and others 2000, 2003. All Rights Reserved.. Dado que el EditPart es el elemento más importante de GEF, vale la pena explicarlo con un poco más de detalle. Un EditPart contiene básicamente tres elementos. Los dos primeros, son referencias al modelo y a su vista correspondiente. Este par de elementos son modificables, de hecho es responsabilidad del controlador notificar a uno y generar los comandos de modificación del otro. El tercer componente que este contiene, son unos elementos denominados EditPolicies. Estos elementos están encargados de proveer las capacidades de edición visual que un EditPart tiene.. Un EditPart instala una serie de EditPolicies los cuales entienden los eventos generados por las vistas y actúan en correspondencia. En otras palabras, cuando un EditPart recibe un evento de su vista, este itera sobre sus EditPolicy para poder manejar tales eventos y si alguno de ellos comprende el evento, entonces genera los comandos respectivos..
(53) ISC-2003-1-3. 53. 2.2.3 Velocity. Velocity es un motor de plantillas basado en java, a través del cual se puede generar toda clase de documentos de texto e inclusive código fuente java. Este motor puede ser usado como un cliente pesado (i.e. standalone), para generar distintos tipos de contenido, o en combinación con otros sistemas para proveer servicios de plantillas58.. Según el documento de diseño de este motor, Velocity tiene una amplia variedad de usos como lo es la generación de documentos SQL, XML, o código fuente de java a partir de plantillas, sin embargo al grupo que más espera beneficiar es el correspondiente a “… aquellos desarrolladores buscando una alternativa viable a PHP59 o Java Server Pages (JSP)60 …”.61. Este motor le permite a los desarrolladores de páginas Web, así como también a los desarrolladores de aplicaciones que necesitan generar código fuente, integrar elementos de script dentro de los lugares apropiados para cada necesidad. Tales elementos son bastante sencillos: sin embargo, asociados a un elemento contextual proveen al desarrollador elementos poderosos de generación de contenido. El elemento contextual al cual se hace mención es un objeto en java, más específicamente una tabla de hash, en la que se almacenan las propiedades que serán usadas como elementos de script.. 58 59. Jakarta Velocity. Design Document. En línea: http://jakarta.apache.org/velocity/design.html http://www.php.net/. 60. http://java.sun.com/products/jsp/. 61. Jakarta Velocity. Op. Cit. p. 1.
(54) ISC-2003-1-3. 54. Los elementos de script son obtenidos del objeto contextual a través de métodos get y set. Estos métodos para acceder el objeto contextual retornan cadenas de caracteres que luego serán reemplazadas en los lugares determinados por los elementos de script. Adicionalmente este motor le otorga cierto control al desarrollador en cuanto a ciclos y estructuras condicionales, mediante los constructos #foreach e #if . .#elseif .. #else.. Al igual que GEF, Velocity también utiliza el patrón MVC en su arquitectura, al separar el código java del código de las plantillas. Contrario a lo que sucede con JSP, Velocity no permite la inclusión de código java al interior de las plantillas. Así mismo, tampoco implementa características con otras funciones tal como lo hace PHP62.. Esta separación de preocupaciones brinda una mayor seguridad tanto para los desarrolladores como para los diseñadores, ya que asegura que ninguno de los dos grupos tendrá la necesidad de alterar, o siquiera de conocer, el código del otro grupo. Simplemente tendrán que acordar un contrato en cuanto a los elementos de script que el objeto contextual debe proveer.. Entre los beneficios de tal arquitectura se encuentra la facilidad en el mantenimiento de los documentos generados a partir de las plantillas, ya que, como no tienen necesidad de manipular el código de la aplicación, son menos propensas a introducir errores. Adicionalmente, y dado que para poder trabajar sobre esta arquitectura se necesita una sincronización en cuanto al diseño de los métodos para acceder a los datos de la aplicación,. 62. Jakarta Velocity. Op. Cit. p. 1.
(55) ISC-2003-1-3. 55. una vez definidos estos, el tiempo de desarrollo de aplicaciones para la Web puede reducirse significativamente.. Por último una ventaja adicional sobre JSP y PHP es que Velocity no necesita de un motor pesado para manejar la transformación de las plantillas en el código objetivo. A diferencia de JSP, en el que es necesario un servidor que cumpla con ciertas especificaciones, y que tiene que inicializarse cuando se inicializa el servidor Web, Velocity incluye el motor generador de documentos y viene empacado en un archivo JAR, lo cual lo hace más rápido y más liviano..
(56) ISC-2003-1-3. 56. 3. DESCRIPCIÓN DE LA APLICACIÓN. Como ya se ha mencionado anteriormente, la herramienta desarrollada es un ambiente de desarrollo de software para JCSP. En esta parte del trabajo se va a describir tal aplicación, se presentarán los requerimientos, y se explicarán las decisiones de diseño más relevantes.. 3.1 DESCRIPCIÓN. Como se puede inferir del título de este trabajo de grado, el espacio del problema tiene que ver con JCSP. De acuerdo con lo visto en el marco teórico en la sección correspondiente, JCSP tiene una serie de conceptos que vale la pena repasar para comprender la solución implementada para este espacio.. Esta aplicación implementa la metodología denominada “diseño orientado a procesos”63. En esta metodología el diseño se hace progresivamente en capas de redes de procesos. Estas redes de procesos no son más que una colección de procesos ejecutándose en forma 63. Welch, Peter. JCSP Documentation. En línea: http://www.cs.kent.ac.uk/projects/ofa/jcsp/jcsp-1-0-rc4/jcsp-. docs/.
Documento similar