diseÑo e implementaciÓn de un ambiente de desarrollo de
TRANSCRIPT
ISC-2003-1-3
DISEÑO E IMPLEMENTACIÓN DE UN AMBIENTE DE
DESARROLLO DE SOFTWARE PARA JCSP
FERNANDO ANGARITA SARMIENTO
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
2004
i
ISC-2003-1-3
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
ii
ISC-2003-1-3
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.
iii
ISC-2003-1-3
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.
iv
ISC-2003-1-3
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
v
ISC-2003-1-3
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
vi
ISC-2003-1-3
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
vii
ISC-2003-1-3
FIGURA 14. DIALOGO PARA INSTANCIAR UN PROCESO.................................................................87
viii
ISC-2003-1-3
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
ix
ISC-2003-1-3
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
x
ISC-2003-1-3
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.
11
ISC-2003-1-3
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 :
http://www.comp.glam.ac.uk/pages/staff/efurse/Teaching/PP/Introduction.html, 1998.
3 Campbell, Jonathan. Programming Languages and Paradigms. En l ínea :
http://www.cs.qub.ac.uk/~J.Campbell/myweb/oop/oophtml/node4.html, 1999.
4 Edwards, Steve. Programming Language History and Evolution. En l ínea :
http://courses.cs.vt.edu/~cs3304/Spring00/notes/Chapter-2/index.htm, 2000.
12
ISC-2003-1-3
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.
13
ISC-2003-1-3
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.
14
ISC-2003-1-3
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
15
ISC-2003-1-3
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.
16
ISC-2003-1-3
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 Ibíd.
11 Dart, Susan et al. Overview of Software Development Environments. En línea:
http://www.ida.liu.se/~petfr/princprog/envpaper.pd f , 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.
17
ISC-2003-1-3
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.
18
ISC-2003-1-3
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.
19
ISC-2003-1-3
ú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.
20
ISC-2003-1-3
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. 211-
245.
21
ISC-2003-1-3
• 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 ellos20 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
22
ISC-2003-1-3
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.
23
ISC-2003-1-3
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
24
ISC-2003-1-3
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.
25
ISC-2003-1-3
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.
26
ISC-2003-1-3
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.
27
ISC-2003-1-3
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 Lea, Doug. Op. Cit. p. 385.
32Ibid.
28
ISC-2003-1-3
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 Java: Concurrency for All. En línea:
http:// www.cs.kent.ac.uk/projects/ofa/pdpta-2002/jcsp.pdf
29
ISC-2003-1-3
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.
30
ISC-2003-1-3
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
31
ISC-2003-1-3
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.
32
ISC-2003-1-3
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.
33
ISC-2003-1-3
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:
34
ISC-2003-1-3
• 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.
35
ISC-2003-1-3
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);
}
}
}
36
ISC-2003-1-3
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());
}
}
}
37
ISC-2003-1-3
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.
38
ISC-2003-1-3
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.
39
Figura 1. Red de procesos con dos procesos
ISC-2003-1-3
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.
40
ISC-2003-1-3
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/
39Senoir Corps. Tech Center. Understanding Licenses. En línea :
http://www.seniortechcenter.org/reference_library/software/understanding_licenses.php40 Open Source. The Approved Licenses. En línea : http://www.opensource.org/licenses/41 En línea: http://www. netbeans.org/
41
ISC-2003-1-3
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.
• Soportar una cantidad ilimitada e irrestricta de proveedores de herramientas.
42 Object 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/Article-
Plug-in-architecture/plugin_architecture.html 45 Shah, Rawn. Working the Eclipse Platform. En línea: http://www-
106.ibm.com/developerworks/library/eclipse/
42
ISC-2003-1-3
• 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 Object Technology International, Inc. Op. Cit. p. 3
47 Eclipse. Platform Plug-in Develoment Guide. En: Incluida con la herramienta. Sección: Platform
Architecture.
43
ISC-2003-1-3
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
44
ISC-2003-1-3
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
45
ISC-2003-1-3
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
46
ISC-2003-1-3
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
47
ISC-2003-1-3
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.
48
ISC-2003-1-3
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/
49
ISC-2003-1-3
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.
56 GEF Developer Guide. Model-View-Controller Paradigm. Documentación incluida en el componente.
57 Eclipse GEF. Op. Cit. p. 1
50
Figura 3. Arquitectura MVC GEF
Copyright (c) IBM Corp. and others 2000, 2003. All Rights Reserved.
ISC-2003-1-3
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.
51
ISC-2003-1-3
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.
52
Figura 4. Arquitectura EditPart
Copyright (c) IBM Corp. and others 2000, 2003. All Rights Reserved.
ISC-2003-1-3
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 Jakarta Velocity. Design Document. En línea: http://ja k a rta.apache.org/velocity/design .html 59 http://www.php.net/
60 http://java.sun.com/products/jsp/
61 Jakarta Velocity. Op. Cit. p. 1
53
ISC-2003-1-3
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
54
ISC-2003-1-3
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.
55
ISC-2003-1-3
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/
56
ISC-2003-1-3
paralela, y que están conectados entre ellos mediante una serie de canales. Tales canales son
definidos en JCSP como un objetos de sincronización pasivos. En última instancia, cada red
de procesos es, en sí misma, un proceso.
Para el caso del modelo que utiliza este ambiente de desarrollo, se han definido tres tipos de
procesos: simples, conectar y utilizar, y compuestos.
3.1.1 Procesos simples
Un proceso simple es un proceso “cascaron” en el sentido de que el código generado por la
aplicación solo contiene el constructor público y el encabezado del método run. Para el
caso de este último método, es responsabilidad del desarrollador implementarlo, ya que así
define el comportamiento del proceso.
En JCSP no existe el concepto de puertos, sin embargo, para la identificación correcta de
las conexiones entre procesos se introdujo dicho concepto. Más adelante se ampliará esta
decisión. Aunque en el momento de la creación de un proceso simple, este no contiene
ningún tipo de puerto, estos pueden ser agregados a voluntad por el desarrollador.
Figura 5. Representación de un proceso
simple.
57
ISC-2003-1-3
3.1.2 Procesos conectar y utilizar
Este tipo de procesos reciben su nombre por su contraparte en inglés Plug and Play. Estos
son procesos almacenados en una librería de procesos, y, por lo tanto, su implementación
no puede ser modificada. La idea de este tipo de procesos es servir como bloques primarios
de construcción de procesos más complejos.
Dado que estos procesos no pueden ser modificados, en el momento de creación estos ya
contienen los puertos necesarios para su comunicación con otros procesos. En el caso de
estos procesos, la aplicación no genera código fuente para ser implementado, porque, como
se mencionó anteriormente, estos ya existen dentro de una librería de procesos.
3.1.3 Procesos Compuestos
Este tipo de procesos son una especie de contenedores, dado que en su interior poseen una
red de procesos independiente de la red contenedora del proceso como tal. La
implementación de este tipo de procesos sigue el patrón composite. En esta red interna,
pueden existir los tres tipos de procesos conectados mediante canales.
Figura 6. representación procesos
conectar y utilizar.
58
ISC-2003-1-3
3.1.4 Canales
Estos elementos son utilizados para conectar dos procesos entre sí. En este caso la fuente de
un proceso es dirigida hacia el destino del proceso a conectar. Estos canales solo pueden ser
conectados entre puertos.
3.1.5 Puertos
Los puertos son una serie de elementos visuales usados por los procesos para comunicarse
con sus pares. Estos puertos son de tres tipos: de entrada, de entrada alternativa, y de salida.
En la figura 8 pueden observarse las representaciones para los distintos tipos de puertos. La
primera y la ultima corresponden a los primeros dos tipos, mientras que la del medio
representa el último tipo de puerto.
Los puertos son utilizados como puntos de entrada y salida de los canales, es decir, los
canales conectan, siempre, un par de puertos. Estos puertos, como se indicó anteriormente,
son contenidos por cada proceso.
Figura 7. Representación de un proceso compuesto con un par de procesos
internos.
59
ISC-2003-1-3
Adicionalmente se tiene otro par de puertos que representan la comunicación de la red de
procesos con el ambiente externo. Estos puertos no permiten la conexión de canales
provenientes de redes de procesos externas, simplemente representan un punto, el cual, una
vez encapsulada la red de procesos, servirá para comunicarse con el ambiente. Estos puertos
no son contenidos por un proceso; antes bien, es la red de procesos la que los contiene.
Como consecuencia, estos puertos son elementos flotantes en la red de procesos, tal como
lo es un proceso o un comentario.
3.2 DISEÑO
El ambiente de desarrollo de software para JCSP fue diseñado como un plug-in para la
plataforma Eclipse. Tal herramienta es un editor gráfico el cual usa la vista de propiedades
Figura 8. Representación de los tipos de
puertos.
Figura 9. Representación de los puertos
externos.
60
ISC-2003-1-3
para capturar los datos proveídos por el usuario, y que, además, provee una vista de
delineamiento que le ayuda al desarrollador a navegar más fácilmente por el modelo.
Para el diseño y desarrollo de la aplicación, se tomó como base el articulo de Dean et al.
publicado por IBM, bajo la colección redbooks titulado “Eclipse Development using the
Graphical Editing Framework and the Eclipse Modeling Framework”, en Febrero de 2004.
A partir de este documento, se tomaron varias decisiones en cuanto a diseño, y se
evolucionó hasta lograr la aplicación concerniente a este trabajo.
Este ambiente provee una serie de funcionalidades para ayudar al desarrollador a realizar su
tarea de una manera más fácil y rápida. En el espacio del editor se permite la edición in situ
de los procesos compuestos. Tales procesos se pueden editar mediante el mecanismo
conocido como drag and drop. Por otro lado, se provee un segundo espacio de trabajo para
la edición de los procesos compuestos.
En cuanto a la creación de canales, se provee un mecanismo mediante el cual la herramienta
de conexión reconoce los posibles sitios donde puede ser conectado un canal. En este
sentido se deben tener en cuenta varias restricciones, entre las que se cuenta la incapacidad
de realizar conexiones entre los procesos de una red y los procesos de una subred de esta.
Esto implica que solo se permiten conexiones entre procesos pertenecientes a una misma
red.
Otras funcionalidades incluyen la actualización dinámica de las vistas correspondientes,
cuando de presentan eventos de creación, modificación y eliminación de los distintos
61
ISC-2003-1-3
elementos de la red de procesos. Soporte para arrastrar y soltar elementos desde la paleta de
componentes al espacio de trabajo. Menús contextuales que contienen distintas funciones y
que se activan al oprimir el botón derecho del ratón.
3.2.1 Decisiones de Diseño
A lo largo del diseño y desarrollo de la herramienta, se tomaron un conjunto de decisiones,
entre las cuales se encuentran las siguientes:
• Solo puede existir una red de procesos de primer nivel por cada archivo.
• La red de procesos al interior de un proceso compuesto es, en sí misma, una red
de procesos.
• No se permiten referencias a redes de procesos externas, ni tampoco a subredes.
• Se permite la asociación de más de un canal a un puerto, es decir, un puerto
puede ser la fuente o el destino de más de un canal.
• La generación de código se realiza sobre la instancia guardada del modelo.
• Se tomó la decisión de desarrollar la herramienta para que funcione como un
plug-in de Eclipse para aprovechar la funcionalidad y ventajas que este ofrece.
3.2.2 El modelo de red de procesos
Durante el resto de esta sección se presenta una pequeña descripción de los elementos más
relevantes del modelo de la aplicación, el cual se puede observar en la siguiente figura.
62
ISC-2003-1-3
ProcessNetworkElement
Esta clase es la superclase para todos los elementos gráficos que tiene la herramienta
y, por lo tanto, todas las clases que la extienden tienen su equivalente en el espacio
visual. Esta clase abstracta contiene atributos comunes a todas las clases que
representan un elemento visual. La tabla 1 provee un resumen de la clase.
Tabla 1. Resumen clase ProcessNetworkElement
Pertenece a Super Clase
Figura 10. Modelo de la red de procesos
63
ISC-2003-1-3
Atributos name: Contiene el nombre de la red de procesos
comment: Es una cadena opcional para escribir un comentario.
xLocation: Coordenada para la ubicación visual del elemento.
yLocation: Coordenada para la ubicación visual del elemento.
width: Este atributo indica la anchura del elemento.
height: Este atributo indica la altura del elemento.
id: Contiene una identificación única para un elemento de la redde procesos
Restricciones
ProcessNetwork
Esta clase es la representación de una red de procesos. Una red de procesos puede
tener nodos y canales conectando tales nodos. En el caso de esta representación, la
clase contiene estos elementos, además de comentarios para anotar los procesos que
están siendo creados en un momento dado. La tabla 2 provee un resumen de esta
clase.
Tabla 2. Resumen de la clase ProcessNetwork
Pertenece a Super Clase ProcessNetworkElementAtributos Nodos: Los procesos contenidos por esta red de procesos.
Canales: Los vínculos entre los distintos nodos de la red.
Comentarios: Los comentarios contenidos en la red de procesos.Restricciones
ProcessNetNode
64
ISC-2003-1-3
La clase ProcessNetNode representa un nodo en la red de procesos. Estos nodos
tienen puertos, mediante los cuales pueden ser conectados a otros nodos.
Adicionalmente, estos nodos mantienen una colección de campos de inicialización
que son utilizados para configurar la ejecución de la red de procesos.
Tabla 3. Resumen clase ProcessNetNode
Pertenece a ProcessNetworkSuper Clase ProcessNetworkElementAtributos processNetwork: Contiene una referencia a la red de procesos
que contiene al nodo.
inputs: Los puertos de entrada, incluyendo los alternativos,pertenecientes a este nodo.
outputs: Los puertos de salida que pertenecen a este nodo.
initFields: Los campos con los cuales se inicializa este nodo.Restricciones
Process
La clase Process es la representación de un proceso simple, es decir, sin la
implementación de su método run. Adicionalmente, esta clase representa un proceso
que puede ser editado.
Tabla 4. Resumen clase Process
65
ISC-2003-1-3
Pertenece a Super Clase ProcessNetNodeAtributosRestricciones
PaPProcess
Esta clase representa a los procesos denominados conectar y utilizar64. Este tipo de
procesos ya tiene una implementación definida y se obtiene de una librería de
procesos predeterminada. Por esta razón tal proceso no puede ser editado más allá
de los valores de inicialización.
Tabla 5. Resumen clase PaPProcess
Pertenece a Super Clase ProcessNetNodeAtributos papType: Es una cadena con el nombre calificado del tipo de este
proceso.Restricciones Este proceso no puede ser editado.
En la creación se definen los puertos correspondientes, y no sepueden agregar ni eliminar otros puertos.
Solo se permite la modificación de los valores de los campos deinicialización.
CompoundProcess
La clase CompoundProcess representa a un proceso compuesto. Un proceso
compuesto es una clase de proceso, el cual contiene una subred de procesos. Aun
cuando esta subred de procesos tiene exactamente las mismas características de la
64Por su denominación en ingles Plug and Play.
66
ISC-2003-1-3
red de procesos principal, no se permite la conexión de nodos entre redes distintas.
Todas las redes son independientes entre ellas.
Tabla 6. Resumen clase CompoundProcess
Pertenece a Super Clase ProcessAtributos subProcessNetwork: La red de procesos que define al proceso
compuesto.Restricciones No se permite la conexión de nodos entre la subred y la red
contenedora de este proceso; tampoco se permiten conexionesentre la subred de este proceso y subredes de procesoscompuestos contenidos en esta subred.
InitField
La clase InitField corresponde a los campos de inicialización de los nodos
pertenecientes a la red de procesos. Estos campos de inicialización serán utilizados
en la generación de código para inicializar cada proceso. En la estructura de la clase,
estos campos corresponden a los argumentos de los constructores públicos de los
procesos.
Tabla 7. Resumen clase InitField
Pertenece a ProcessNetNodeSuper ClaseAtributos name: Contiene el nombre del campo.
type: Indica el tipo del valor que este campo puede asumir.
value: Contiene el valor que tiene este campo.
67
ISC-2003-1-3
Restricciones El valor del campo debe ser del mismo tipo que el indicado en elatributo type.
En los procesos conectar y utilizar, solo puede ser modificado elatributo valor, mientras que en los demás tipos de procesos noexisten restricciones.
Channel
La clase Channel representa un vínculo entre dos procesos, o entre un proceso y un
canal externo. Este vínculo se realiza entre un puerto de salida de un nodo y un
puerto de entrada de otro proceso, o entre un puerto de entrada o salida de un
proceso, y un puerto externo de entrada o salida. En el campo visual, los canales son
uno a uno, sin embargo los puertos aceptan más de un canal excepto cuando son
puertos externos, en cuyo caso solo aceptan un canal. A través de esta propiedad la
herramienta soporta los canales uno a muchos y muchos a uno presentes en la
especificación de JCSP.
68
ISC-2003-1-3
Tabla 8. Resumen clase Channel
Pertenece a ProcessNetworkSuper Clase ProcessNetworkElementAtributos processNetwork: La red de procesos que contiene al canal.
source: El puerto de salida desde el cual se origina el canal.
target: El puerto de entrada que es el destino del canal.
extSource: Puerto de salida externo desde el cual se origina elcanal.
extTarget: Puerto de llegada externo al cual se dirige un canal.Restricciones Se permite únicamente una fuente y un destino, aunque estos
pueden ser modificados.
Cuando uno de los extremos es un puerto externo, el otroextremo debe ser un puerto perteneciente a un proceso.
Port
La clase puerto es una clase abstracta que provee los elementos comunes a los
distintos tipos de puertos. Esta clase también hereda de la superclase
ProcessNetworkElement.
OutputPort
La clase OutputPort representa un puerto desde el cual se origina un canal. En el
código generado este puerto está reflejado en la declaración de un canal JCSP de
tipo ChannelOutput.
Tabla 9. Resumen clase OutputPort
Pertenece a ProcessNetNodeSuper Clase Port
69
ISC-2003-1-3
Atributos channels: Los canales que tienen como destino a este puerto.
node: El nodo al cual pertenece este canal.Restricciones
InputPort
La clase InputPort representa un puerto al cual se dirige un canal. Como en el caso
anterior, este puerto representa la declaración de un canal de tipo ChannelInput.
Tabla 10. Resumen clase InputPort
Pertenece a ProcessNetNodeSuper Clase PortAtributos channels: Los canales que tienen como destino a este puerto.
node: El nodo al cual pertenece este canal.Restricciones
AltInputPort
La clase AltInputPort hereda sus atributos y funciones de la clase InputPort y, por lo
tanto, tiene una connotación parecida. El punto que diferencia los dos tipos de
puertos es que este puerto representa canales de tipo AltingChannelInput, cuyas
consecuencias han sido explicadas en la sección acerca de JCSP.
ExtInputPort
La clase ExtInputPort se comporta como la clase OutputPort en el sentido de ser un
puerto fuente para el canal, pero al contrario de este, el puerto externo solo acepta
70
ISC-2003-1-3
un canal. En el mismo sentido, el puerto externo es contenido por una red de
procesos y no por un proceso como en el caso del puerto de tipo OutputPort.
Una vez se encapsule la red de procesos, estos puertos externos se convertirán en los
puertos del proceso encapsulado. En la tabla 11 se puede observar un resumen de la
clase.
Tabla 11. Resumen clase ExtInputPort
Pertenece a ProcessNetworkSuper Clase PortAtributos channel: El canal que comunica este puerto con un puerto de
entrada de un proceso.
processNetwork: La red de procesos a la cual pertenece estecanal.
Restricciones Solo se permite un canal por puerto.
ExtOutputPort
Esta clase es otro tipo de puerto externo, en este caso se trata de un puerto de salida.
Este puerto es el destino de un canal que tiene su origen en un puerto de tipo
OutputPort y que pertenece a un proceso.
Al momento de encapsular la red de procesos, este puerto representará un puerto de
salida en el proceso encapsulado. Para este tipo de puertos, solo se permite un canal
para la comunicación. Este canal debe ser de tipo uno a uno.
71
ISC-2003-1-3
Tabla 12. Resumen clase ExtOutputPort
Pertenece a ProcessNetworkSuper Clase PortAtributos channel: El canal que comunica este puerto con un puerto de
entrada de un proceso.
processNetwork: La red de procesos a la cual pertenece estecanal.
Restricciones Solo se permite un canal por puerto.
Comment
La clase comment representa una clase de comentarios que no están atados a
ninguno de los demás elementos visuales en el espacio de trabajo. La tabla 13
muestra un resumen de la clase.
Tabla 13. Resumen de la clase Comment.
Pertenece a Super Clase ProcessNetworkElementAtributosRestricciones El texto del comentario debe ir en el atributo comment, heredado
de la clase ProcessNetworkElement.
3.3 ARQUITECTURA
En esta sección se describirá la arquitectura de la herramienta, así como algunos detalles de
la implementación. Esta sección es relevante en tanto se desee extender la herramienta o en
último caso modificarla.
72
ISC-2003-1-3
Al momento de diseñar la aplicación se tuvieron en cuenta una serie de requerimientos
según los cuales se implementó la solución deseada. Entre estas restricciones se encuentran
las siguientes:
• El sistema debe interactuar con el framework de Eclipse en su versión 2.1.
• El sistema debe proveer un ambiente gráfico de edición de procesos.
• El sistema debe proveer un ambiente textual de edición de procesos.
• El sistema debe generar el código fuente de los procesos que están siendo
editados en el ambiente gráfico.
• El sistema debe proveer los mecanismos para compilar y ejecutar los procesos
sobre los que está trabajando un proyecto.
Aunque existe un número mayor de requerimientos, los anteriores influenciaron en mayor
proporción las decisiones en cuanto a la arquitectura de la aplicación.
En primera medida, la decisión más importante en cuanto a la interacción con Eclipse fue la
de implementar la herramienta como un conjunto de plug-in. Se decidió integrar tal
conjunto al nivel de “interfaz de usuario”65, para aprovechar las ventajas que provee esta
plataforma. Tales ventajas incluyen un editor para el lenguaje Java, una interfaz gráfica
madura, y su variedad de herramientas.
La aplicación consiste de dos plug-in, cada uno de ellos representa un componente
completamente funcional desde la perspectiva del usuario. El primero de ellos es el que
65 Según la definición de Amsden en su articulo denominado Levels of Integration.
73
ISC-2003-1-3
contiene el modelo de negocio de la herramienta, en el se encuentra el modelo de la red de
procesos, y la lógica de generación del código. El segundo contiene la parte gráfica de la
aplicación, en este se encuentra el soporte para drag and drop, el editor gráfico, y la
integración con la plataforma Eclipse.
Con respecto a la lógica de negocio de la herramienta, en la sección 3.2.2 se presentó un
resumen de las clases de este modelo, sin embargo, vale la pena ampliar la explicación con
respecto a la arquitectura.
El modelo de la lógica de negocio fue diseñado teniendo en cuenta un aspecto muy
importante del diseño orientado a procesos. Este nos indica que una red de procesos es, en
sí misma, un proceso. Como tal, puede estar incluida en la composición de otras redes de
procesos, o, por el contrario, puede ser ejecutada como red principal. Siguiendo esta lógica,
una red de procesos puede tener puertos de entrada y salida además de los elementos
usuales, descritos anteriormente.
Este modelo está organizado en paquetes relativamente funcionales. En un primer paquete
se pueden encontrar las interfaces que definen al modelo de acuerdo con el diagrama de
clases que se encuentra en el anexo A. En un paquete distinto se encuentran las clases que
implementan a este conjunto de interfaces. Por último, en los paquetes restantes,
encontramos las clases utilitarias que sirven como apoyo a ciertas funciones de la
aplicación, entre estas encontramos la generación de código y la exportación de la red de
procesos a la librería de procesos.
74
ISC-2003-1-3
El modelo tiene una serie de particularidades a nivel de implementación, que es
conveniente resaltar. Por una parte, el acceso a las clases del modelo se hace a través de la
clase denominada JcspModelManager. Esta clase no actúa como fachada al modelo,
simplemente provee una serie de métodos para acceder a artefactos de creación, de acceso,
y de persistencia del modelo.
Por otro lado, existe un artefacto, generado automáticamente por el framework EMF, que
provee acceso a meta-objetos que representan cada clase, cada atributo de cada clase, cada
enumeración, y cada tipo de dato. Estos meta-objetos son utilizados por la herramienta en
su esquema de notificación, el cual está diseñado siguiendo el patrón Observer.
Se decidió trabajar con Velocity porque esta herramienta posee una ventaja en cuanto a la
velocidad de generación, así como también en cuanto a la facilidad para modificar las
plantillas usadas para la generación de código. En este respecto, una vez el usuario decide
realizar la generación de código, la clase pertinente en el modelo analiza, como primera
medida, el tipo de archivo que se generará para la red de procesos. Esta decisión se toma
con base en la existencia de puertos externos, bien sea de entrada o de salida. Si tales
puertos existen, la herramienta supone que se desea encapsular la red de procesos y, por lo
tanto, genera el código fuente para un nuevo proceso. Por el contrario, si no los encuentra,
se genera un archivo que permita la ejecución de la red de procesos que está siendo editada.
Así mismo, la herramienta itera sobre los nodos contenidos en la red de procesos en busca
de aquellos que no poseen implementación. Con la información contenida en cada uno de
estos nodos, genera el código fuente del proceso respectivo. Por último, recorre los canales
75
ISC-2003-1-3
que contiene la red y sobre estos canales hace un análisis en cuanto al tipo de conexión que
existe. Si esta conexión es uno a uno no sucede nada. Si, por el contrario, descubre que las
conexiones existentes son asimilables a canales de tipo muchos a uno, o uno a muchos, crea
objetos que representan estos tipos de conexión para que el generador de código haga lo
correspondiente en el archivo de la red de procesos.
De otra parte en la implementación de la lógica de negocio, se utilizó una herramienta,
diseñada por el mismo grupo de desarrolladores que crearon Eclipse, que recibe el nombre
de EMF66. La descripción de esta herramienta se hizo en una sección anterior.
El uso de tal herramienta fue motivado, entre otras cosas, por el mecanismo de notificación
de cambios que este posee. EMF provee soporte para la persistencia de instancias del
modelo vía XML. Es esta característica la que hace que la información del modelo sea
bastante portable. Por último, pero no por ello menos importante, porque EMF tiene un
mecanismo de reflexividad, lo que hace más fácil diseñar soluciones genéricas que se
adapten a cualquier espacio.
Con respecto al componente gráfico de la aplicación, está implementado usando el
framework conocido como GEF. Como se indicó en la sección correspondiente, GEF
impone el modelo MVC para su funcionamiento. Para el caso de esta aplicación, el modelo
está claramente definido en un plug-in independiente. La vista y los controladores se
encuentran integrados en el plug-in gráfico.
66Eclipse Modeling Framework.
76
ISC-2003-1-3
En la aplicación, los controladores son subclases de AbstractEditPart, la cual a su
vez es una implementación de la interface EditPart. Esta interfaz y la clase que la
implementa se pueden encontrar en el plug-in de GEF. Las clases que representan a estos
elementos son fácilmente identificables dado que su nombre termina con la palabra
EditPart. Tales controladores tienen una estructura jerárquica que facilita la manipulación
del modelo dada la estructura del mismo. La figura 11 muestra esta estructura.
Estos controladores son la porción más importante de la aplicación dado que sirven de
puente entre el modelo y su representación gráfica. Son estos elementos con los que el
desarrollador va a interactuar directa o indirectamente.
Como se mencionó en la sección 2.3.2, correspondiente al framework GEF, un controlador
consta de tres componentes que son: el modelo, la vista, y las políticas de edición. Este
establece la correspondencia entre los dos primeros, y con el último se encarga de mantener
actualizados al modelo y a la vista, en respuesta a eventos generados en la interacción con
el usuario.
Figura 11. Jerarquía de los controladores.
77
ISC-2003-1-3
Anteriormente se ha hecho mención con respecto al modelo, posteriormente se presentará la
vista, pero ahora es necesario describir la forma en que el controlador cumple con su
objetivo de editar el modelo, y la vez mantener actualizados los componentes que posee, es
decir la vista y el modelo. Estas funciones las cumple a través del tercer elemento que se
mencionó como parte constitutiva de un controlador, es decir, las políticas de edición.
Si la porción más importante de la aplicación son los controladores, entonces las políticas
de edición son el componente fundamental que le da tal importancia a los controladores.
Esto es debido a que tales políticas son las que le proveen la funcionalidad a estos
controladores. Sin estas, los controladores no podrían hacer nada y el usuario no podría ni
siquiera seleccionar un elemento gráfico dentro del espacio de edición.
La función de tales políticas es la de crear comandos de manipulación del modelo, y/o la
vista, en respuesta a requerimientos generados por acciones o por otros controladores en el
espacio de edición. Esto implica que la tarea de edición no la implementa directamente el
controlador, por el contrario, cada controlador instala una serie de políticas que se encargan
de una porción específica del trabajo de edición.
Una consecuencia de tal aproximación es que permite que distintos controladores
compartan algunos comportamientos de edición y difieran en otros, sin modificar de forma
alguna la manera como estos pueden evolucionar. Esto se logra mediante la utilización del
78
ISC-2003-1-3
patrón Strategy67 en la implementación de tales políticas. En general las políticas están
definidas y organizadas en términos de los requerimientos que estas comprenden.
La forma como el controlador utiliza sus políticas para editar el modelo o la vista, según el
caso, es como sigue: Una acción o un controlador por medio de su vista genera un
requerimiento de edición, este requerimiento puede ser de creación, de eliminación, de
adición, etc. El controlador correspondiente recibe tal requerimiento e itera sobre cada una
de sus políticas instaladas preguntando si esta, la política, comprende el requerimiento
dado. Si la política en cuestión no comprende el requerimiento, no sucede nada y el
controlador continúa con la siguiente. Si, por el contrario, lo comprende, la política genera
el comando correspondiente y lo retorna al controlador, este a su vez lo retorna al objeto
que generó, en primer lugar, el requerimiento. Este último es el encargado de ejecutar el
comando por medio de la ejecución del método Command#execute().
El requerimiento, al igual que el comando, es un objeto en sí mismo. En el caso del
primero, es un objeto utilizado para comunicarse con los controladores. Estos objetos
consisten tan solo de un identificador que denota el tipo de acción requerida, estos
requerimientos están agrupados en tres categorías: de creación, de agrupamiento y de
localización.
Los requerimientos de creación, como su nombre lo indica, piden crear un nuevo objeto.
Los de agrupamiento son requerimientos que agrupan a más de un controlador, como es el
67 Gamma, Erich et al. Design Patterns Elements of Reusable Object-Oriented Software. New York, Addison-
Wesley, 2002. pp. 315 – 323.
79
ISC-2003-1-3
caso en que se necesita alinear una o más figuras en el ambiente de edición gráfica.
Finalmente, se encuentran los de localización que lanzan requerimientos para mantener
actualizados tanto la posición, como el tamaño de las figuras que poseen los controladores.
Por otro lado, se encuentran los comandos, que son los objetos con los que efectivamente se
modifica al modelo. Estos comandos están implementados siguiendo el patrón Command68,
y extienden la clase abstracta org.eclipse.commands.Command que se encuentra en
el framework GEF. En estos comandos se encuentra implementada la lógica de
modificación, así como también aquella necesaria para deshacer los cambios realizados por
los mismos.
La figura 12 ilustra mejor el proceso de intercambio de información entre los distintos
componentes de la aplicación. Así como en el caso de los controladores, los demás
elementos presentados en esta figura son fácilmente identificables porque los nombres de
las clases respectivas terminan en Policy para el caso de las políticas, en Request para el de
los requerimientos, y en Command para el caso de los comandos.
68Ibid., pp. 233 - 242
80
ISC-2003-1-3
Cabe, en este momento, destacar que los controladores no son visibles per se; estos solo se
hacen presentes a través de la vista que contienen, y es por intermedio de esta que el usuario
interactúa con los controladores y, por extensión, con el resto de la aplicación.
En la aplicación aquí presentada, la vista está representada por una serie de objetos
denominados figuras. Estas figuras heredan su funcionalidad de la clase
org.eclipse.draw2d.Figure, la cual define la funcionalidad de todos los
elementos gráficos a ser usados en la herramienta.
Esta funcionalidad permite conocer y modificar el estado de tales elementos gráficos.
Dentro de las funciones a las que se hace mención, se encuentran:
Figura 12. Flujo de información entre los distintos componentes de la aplicación.
81
ISC-2003-1-3
• Registrar y remover escuchas de eventos. Típicamente estos eventos tienen que
ver con acontecimientos del ratón en el interior de la figura.
• Informe de eventos relacionados con cambios estructurales en la jerarquía de
figuras, así como también con cambios en cuanto a la posición y el tamaño.
• Adición y eliminación de figuras hijas.
• Conversión, intersección y pruebas de límites sobre la figura.
• Pintarse y validarse.
• Todas aquellas operaciones relacionadas con la manipulación de figuras gráficas.
Hasta este punto se ha descrito la arquitectura de base sobre la cual se edificó la aplicación;
sin embargo, se hace necesario presentar un último elemento fundamental en la
herramienta. Este elemento tiene que ver con la entrada a la aplicación, o más
concretamente con el editor gráfico.
El editor gráfico, como tal, se encuentra situado en el paquete
edu.eclipse.jcsp.ui.editor. En este paquete se encuentran aquellas clases que
le dan la apariencia gráfica a la aplicación, así como también aquellas clases que le proveen
al editor las herramientas para cumplir con sus objetivos. Entre estas herramientas se
encuentran las de creación de nuevos elementos de la red de procesos.
La clase edu.eclipse.ui.editor.ProcessEditor representa un editor de
múltiples páginas en las que se puede editar la red de procesos principal, o las subredes de
los procesos compuestos. En esta clase se encuentra la lógica necesaria para registrar
82
ISC-2003-1-3
nuevas acciones, salvar el trabajo modificado, crear una nueva red de procesos, mantener la
pila de comandos, cerrar el editor, etc.
Algunas de las funciones encontradas en esta clase son delegadas directamente al modelo.
Esto se debe a que el editor mantiene una referencia con la clase de acceso al modelo, y a
través de ella delega las funciones necesarias al modelo.
Los requerimientos concernientes a la edición textual de procesos, así como también a la
compilación y ejecución del código editado, se obtiene a través de la integración con
Eclipse. Tal integración hace uso de un plug-in llamado JDT. Este viene incorporado en la
plataforma y su función especifica es la de proveer un ambiente de desarrollo para el
lenguaje JAVA. Esta herramienta nos provee con las capacidades para cumplir con estos
dos requerimientos.
En la figura 13 se puede observar una representación gráfica de la estructura de la
aplicación a la que hace referencia este trabajo.
83
ISC-2003-1-3
3.4 FUNCIONAMIENTO
En esta sección se describirá el proceso de instalación de la herramienta, así como también
la manera de acceder a las funciones más relevantes de la aplicación. Esta sección está
presentada a modo de manual por esta razón.
3.4.1 Prerequisitos
Para poder ejecutar correctamente la aplicación existen unos requerimientos mínimos que
se deben cumplir. El primero de estos es que debe estar instalada la plataforma Eclipse en
una versión superior o igual a 2.1.0. Adicionalmente existen otros prerrequisitos, que tienen
que ver con la instalación de los siguientes plug-in:
• Eclipse Modeling Framework (EMF) en su versión 1.1.0
• Graphical Editing Framework (GEF) versión 2.1.0
• Velocity Plug-in versión 1.3.1
• JCSP Plug-in versión 1.0.0
Figura 13. Arquitectura del ambiente de desarrollo para JCSP
84
ISC-2003-1-3
Los primeros dos fueron desarrollados por el grupo Eclipse y pueden ser hallados en la
página de este grupo69. El tercer plug-in fue desarrollado por un grupo independiente bajo el
nombre de “veloedit”, y puede ser hallado en la dirección http://veloedit.sourceforge.net.
Por último, el cuarto plug-in se encuentra junto con la aplicación dado que esta librería
nunca fue empacada como tal.
Se eligió convertir esta librería en un plug-in dado que es más sencillo para Eclipse
descubrir en dónde se encuentran las clases incluidas en esta librería.
Para instalar la herramienta, simplemente se debe desempacar el archivo zip en la carpeta
donde se encuentran los plug-in de la plataforma.
3.4.2 Ejecución
La herramienta define un editor por defecto para archivos con extensión .jcsp. Este tipo
de archivo es el que contiene la red de procesos principal, y sobre el cual se basa el
generador de código para producir el código fuente respectivo.
Para ejecutar la aplicación, primero se debe crear un proyecto java, luego se debe crear el
archivo con la extensión adecuada usando el asistente proveído para tal fin. Los pasos para
crear estos elementos son como sigue.
69http://www.eclipse.org/gef y http://www.eclipse.org/emf
85
ISC-2003-1-3
Para crear el proyecto java:
1. Haga click en File -> New -> Project..., seleccione Java -> Java Project, click Next.
2. Ingrese el nombre del proyecto y haga click en Finish.
Para crear el modelo de la red de procesos con el asistente:
1. Haga click en File -> New -> Other... luego seleccione Jcsp-> Process Network,
haga click en Next.
2. Ingrese el nombre del archivo, respetando la extensión del archivo. Haga click en
Finish.
Una vez se ha seguido este procedimiento, el editor de procesos abre automáticamente una
red de procesos vacía. Estando abierta esta nueva red de procesos, el usuario puede realizar
distintos tipo de operaciones sobre esta red.
A continuación se presenta una lista de operaciones que pueden ser realizadas en este
entorno.
Adición de Procesos
El editor gráfico de procesos permite la adición de procesos a la red, utilizando un
mecanismo denominado drag and drop. El usuario simplemente tiene que hacer
click sobre el tipo de proceso que quiere instanciar, y luego debe hacer click en
cualquier lugar del espacio de trabajo. La herramienta tiene un método visual de
informar al usuario si es permitido el lugar en donde piensa crear el nuevo proceso.
86
ISC-2003-1-3
Para el caso de los procesos plug and play, una vez el usuario ha decidido el lugar
en donde se ubicará su proceso, el editor gráfico le presenta un diálogo (figura 14)
con los tipos de procesos que puede instanciar. El usuario debe escoger una de las
opciones y proveer el nombre de la instancia en la casilla correspondiente.
Adición de puertos
El usuario puede adicionar puertos a los procesos, siempre y cuando estos no
pertenezcan a la clase Plug and Play. Esto se debe a que sobre esta clase pesa una
restricción que indica que, para esta clase de procesos, solo pueden ser modificados
sus valores de inicialización.
La adición de puertos se hace a través de un menú contextual que se activa al hacer
click derecho sobre un proceso. En este menú aparecen las opciones para agregar los
tres tipos de puertos que soporta la aplicación.
Figura 14. Dialogo para
instanciar un proceso.
87
ISC-2003-1-3
Conexión de nodos
Como se mencionó en una sección anterior, la conexión entre nodos se hace a través
de canales. En esta herramienta solo existe un tipo de canal a nivel visual, este tipo
es uno a uno. Aunque visualmente solo existen canales uno a uno, al momento de
generar el código fuente se pueden lograr canales uno a muchos y muchos a uno
debido a que los puertos soportan mas de un canal como fuente o destino.
Para hacer uso de esta capacidad, el usuario debe seleccionar la herramienta de
conexión que se encuentra en la paleta de herramientas, y luego seleccionar el par de
puertos que se desea unir.
Adición de comentarios
Al igual que con los procesos, el usuario puede adicionar comentarios flotantes, es
decir, no dependen de ningún otro elemento gráfico para existir. El texto que
aparece como comentario, debe ser modificado en la vista de propiedades de la
herramienta en el campo comment.
Modificación de Atributos
El usuario puede modificar algunos atributos de los procesos mediante los cuales se
configuran los valores que serán generados en el código. Estos atributos incluyen el
nombre, los comentarios, los valores de inicialización del código generado.
Eliminación de elementos
88
ISC-2003-1-3
De la misma manera en que la aplicación permite agregar elementos a la red de
procesos, también permite la eliminación de estos. Existen dos maneras de realizar
tal operación. Una es mediante la tecla eliminar, la otra es mediante la opción
correspondiente en el menú contextual.
Se debe tener en cuenta que cuando se borra un elemento también se eliminan todos
los hijos de este. Por ejemplo, al borrar un proceso compuesto, son borrados
también los puertos que este contiene así como la subred de procesos con todos los
nodos y conexiones que pueda tener.
De igual manera, existe otra serie de operaciones relacionadas con el ambiente gráfico.
Dentro de estas se incluyen el cambio del tamaño y posición de un elemento dentro de la
red de procesos.
Por último, la generación de código se produce al seleccionar la opción correspondiente en
el menú contextual asociado al archivo que contiene la red de procesos. El código generado
será guardado en la carpeta “src” del proyecto java.
89
ISC-2003-1-3
4. CONCLUSIONES
El objetivo del presente trabajo fue la construcción de una herramienta que permitiera
investigar cómo el modelo propuesto por Hoare en CSP puede llegar a suplir algunas
carencias del paradigma OO. Así mismo, se buscó que tal herramienta facilitara el
desarrollo de aplicaciones concurrentes utilizando un patrón de diseño orientado a procesos.
Para cumplir tales objetivos se presentó un marco teórico que definió el tipo de herramienta
a construir y el modelo que tal herramienta utilizaría. En tal marco se comenzó por una
definición clara del tipo de aplicación a construir. Esta herramienta es definida como un
ambiente de desarrollo de software (SDE por sus siglas en inglés). Se presentaron dos
clasificaciones acerca de los tipos de SDE, y se presentó el tipo de servicios que presta cada
uno según su clasificación.
A continuación se describió el lenguaje propuesto por Hoare presentando los elementos
centrales del mismo, entre los que se incluyen los procesos, los canales, y las reglas de
comunicación que gobiernan tales elementos. Acto seguido se presentó la implementación
que utiliza la herramienta para generar aplicaciones concurrentes orientadas a procesos.
90
ISC-2003-1-3
Esta implementación fue desarrollada por Peter H. Welch en la universidad de Kent en
Canterbury. Esta está implementada para ser utilizada como una librería del lenguaje Java,
y es denominada JCSP que significa CSP para Java.
Dado que JCSP es una implementación de CSP, el primero comparte las mismas
características teóricas del segundo. Así pues, se presentó la forma como tales elementos
fueron implementados en esta librería.
Inmediatamente después se presentaron las herramientas utilizadas para la construcción de
la aplicación a la que hace referencia el presente trabajo. Estas herramientas incluyen el
framework sobre el que se ejecuta la aplicación, así como también el framework de edición
gráfica y el de generación de código. En cada uno de estos se expuso la arquitectura y la
forma de utilizar cada una de tales.
Finalmente se presenta la aplicación que satisface los objetivos propuestos al inicio de este
documento. Como se mencionó anteriormente, tal aplicación puede ser catalogada como un
ambiente de desarrollo de software, con la ventaja de presentar un entorno gráfico en el cual
el desarrollador se puede concentrar en las tareas de diseño. Esta estrategia es conveniente
en tanto que al tiempo que el desarrollador está diseñando su aplicación, también la está
implementando, lo que a su vez ahorra tiempo e incrementa la productividad.
Se inició la presentación describiendo los elementos conceptuales que conforman la
aplicación, es decir, aquellos elementos con los que el usuario se va a ver enfrentado al
momento de utilizar la herramienta. Una vez descritos tales elementos se procedió a
91
ISC-2003-1-3
explicar las consideraciones de diseño, así como las clases que conforman el modelo de la
aplicación.
Después de esto, se ahondó en la arquitectura del sistema presentando los componentes más
relevantes, incluyendo las interconexiones entre estos. En esta sección se pudo observar
como el sistema fue desarrollado en torno al patrón MVC y cómo usando distintos patrones
la aplicación realiza las tareas propuestas. Por último, se presenta un manual de usuario en
el cual se expone la forma de utilizar el ambiente desarrollado.
El presente trabajo de grado tuvo un doble propósito desde el momento de proponerlo. Un
primer objetivo era crear una herramienta que permitiera investigar la o las formas en que el
modelo CSP puede llegar a complementar el paradigma orientado a objetos. De otra parte,
se buscaba crear un ambiente integrado de desarrollo en el cual a través de un ambiente
gráfico de edición, un usuario pudiese desarrollar aplicaciones concurrentes tomando como
base el lenguaje propuesto por Hoare. Como se puede inferir de la proposición de objetivos,
estos son complementarios en la medida en que para satisfacer el primer objetivo es
necesario consumar el desarrollo del segundo.
Este par de objetivos se lograron mediante la utilización de distintas herramientas
integradas bajo un mismo modelo arquitectónico, a saber el de plug-in. Este modelo
permite agregar y extender herramientas agrupadas bajo un mismo framework, en este caso
el de Eclipse. Tal situación permite crear herramientas bastante extensibles, así como una
orientación a la tarea específica. Esto implica que aquel que pretenda crear o extender una
92
ISC-2003-1-3
herramienta solo debe centrarse en proveer la funcionalidad específica, ya que se puede
aprovechar de las demás existentes para lograr sus objetivos.
El desarrollo de tales objetivos es importante, y además necesario, en tanto el paradigma
orientado a objetos ha comenzado a quedarse corto en el manejo de aplicaciones
concurrentes. De la misma manera, este paradigma le presenta al desarrollador novato un
modelo de concurrencia bastante confuso, y muchos casos, difícil de aprender y aplicar.
Esto se debe a que este paradigma fue pensado inicialmente para desarrollar aplicaciones
secuenciales. La concurrencia, en OO, ha tenido distintas implementaciones, todas ellas han
sido añadidas al modelo inicial, lo cual ha introducido nuevas complicaciones.
Por el contrario, CSP fue diseñado pensando en aplicaciones concurrentes. En
consecuencia, su diseño es mucho más “natural” y abstrae mejor la forma en que
aplicaciones concurrentes ejecutan sus instrucciones. Adicionalmente, su diseño permite
razonar localmente acerca de cada proceso, y en niveles estructurados de redes de procesos.
Una consecuencia de este diseño es que es fácilmente asimilable tanto por los
desarrolladores novatos, como por aquellos más experimentados. Así pues, se torna más
sencilla y más eficiente la producción de aplicaciones concurrentes, con los consecuentes
beneficios asociados.
JCSP, que es la implementación para Java de CSP, pretende presentar un modelo de
concurrencia alternativo al basado en monitores que Java utiliza. Esta implementación
tiene como objetivo proveer una tal que “... se [adhiera] al modelo CSP de sistemas
93
ISC-2003-1-3
comunicantes de manera que veinte años de teoría, herramientas y experiencia práctica
pueda ser utilizada para soportar las aplicaciones multi-hilo de Java”70.
La herramienta desarrollada tiene como objetivo facilitar la investigación y puesta a prueba
de tal hipótesis.
70 Welch, Peter. Op. Cit.
94
ISC-2003-1-3
5. TRABAJO FUTURO
El presente trabajo de grado tiene tres frentes de trabajo sobre los cuales se puede trabajar
en el futuro. El primero de ellos, como se mencionó anteriormente, es la investigación de la
hipótesis planteada por la implementación de CSP para java. El segundo es la extensión de
la herramienta aquí presentada para que provea otras funciones y mejore algunos aspectos
de la misma. El último frente de trabajo es la extensión de la implementación JCSP, para
soportar nodos de procesamiento distribuido.
Con respecto al primero de los temas propuestos, el trabajo consiste en desarrollar
aplicaciones, utilizando la herramienta aquí presentada, para evaluar si la implementación
de CSP para Java realmente cumple con los objetivos planteados en la documentación de la
misma. Este objetivo se puede lograr mediante pruebas bien estructuradas en las que los
componentes desarrollados se intercambien entre sí para analizar el comportamiento de los
sistemas concurrentes evaluados. Además vale la pena poner a prueba distintos aspectos de
la especificación CSP, como es la composición de redes de procesos, la utilización de
distintos tipos de canales, el uso de canales alternativos, etc.
95
ISC-2003-1-3
El objetivo es realizar una evaluación consistente y comparada entre el modelo de
concurrencia propuesto en CSP y el de monitores proveído por Java para analizar en qué
forma el primero es mejor que el segundo y cómo puede complementar mejor el modelo
orientado a objetos.
El segundo frente de trabajo es la extensión de la herramienta presentada en este
documento. El objetivo detrás de este trabajo es la de complementar la aplicación para que
soporte funciones que en su primera versión no se alcanzaron a implementar. Dentro de las
funcionalidades que se espera, llegue a proveer la herramienta se encuentran:
• Proveer al usuario un mecanismo de organización de los procesos
implementados. En este momento la herramienta posee una única librería en la
que el usuario almacena todos los procesos implementados, sin embargo, para
una mayor facilidad de uso y organización, se debería permitir que el usuario cree
y organice los procesos desarrollados en librerías independientes. Esta
organización debería estar estructurada en librerías de acuerdo con la voluntad
del desarrollador; esto implica que el usuario tendría la potestad de crear y
eliminar librerías de procesos, así como también la de mover procesos entre
distintas librerías.
• Proveer al usuario de un ambiente independiente de ejecución. Actualmente la
herramienta no posee una clara separación entre el ambiente de edición y el
ambiente de ejecución para la red de procesos en que se esta trabajando. El
objetivo es desarrollar una página de ejecución en la que el usuario pueda correr
la red de procesos que está siendo editada, definiendo procesos que proveen y
reciben datos para evaluar el funcionamiento de dicha red. En este momento, el
96
ISC-2003-1-3
usuario debe generar expresamente el código fuente de la aplicación y luego
ejecutar el código generado; la idea es desarrollar un ambiente de ejecución
independiente en el que esté abstraído este proceso y se le oculte tal al usuario.
• Proveer un analizador de código fuente que permita sobrescribir tan solo
aquellas porciones no modificadas por el usuario. La herramienta sobrescribe
todos los archivos generados cada vez que el usuario le pide generar el código
fuente de una red de procesos, el objetivo detrás de este requerimiento es proveer
un analizador de código que no modifique aquellas partes que el usuario a
modificado, como es el caso del método CSProcess#run.
• Extender el mecanismo de edición textual para soportar las palabras clave
inherentes a la especificación JCSP. La herramienta se basa en el editor de
código fuente proveído por el plug-in JDT para realizar lo propio en la red de
procesos. Sin embargo, JDT está diseñado específicamente para Java y no
contempla las ayudas visuales para JCSP, vale la pena extender el editor textual
del plug-in para que soporte las palabras clave de JCSP.
Además de las anteriormente mencionadas, se deben implementar todas aquellas funciones
que suplan necesidades surgidas en el desarrollo de la investigación propuesta en el primer
frente de trabajo.
Por último, encontramos que un frente de trabajo interesante, que puede contribuir a la
investigación con respecto a las bondades de JCSP como complemento del modelo OO, es
la extensión de JCSP para que soporte nodos de procesamiento distribuido. La
implementación sobre la que trabaja la herramienta ofrece el modelo de concurrencia en un
97
ISC-2003-1-3
solo nodo de procesamiento, que para el caso de JCSP significa una única máquina virtual
de Java, o JVM, por sus siglas en ingles.
Actualmente existe una implementación que cumple con el objetivo de ofrecer nodos de
procesamiento distribuido, pero sobre esta implementación existe una licencia que impide
utilizarla sin pagar un importe por tal derecho. Esta es la razón por la cual se propone
realizar una implementación libre que permita desarrollar la investigación deseada.
Esta funcionalidad fue implementada en una librería denominada JCSP.net71 y la compañía
que posee la licencia de uso de esta se llama Quickstone Technologies72. La idea detrás de
esta implementación es la de poder distribuir los procesos en distintos nodos de
procesamiento de tal manera que se pueda tener una red de procesos distribuida a lo largo
de una red, en contraste a la implementación sobre la que se trabajó, la cual solo permite
trabajar con una red de procesos que se encuentre en una misma máquina. Adicionalmente,
se pretende que esta distribución sea invisible para los procesos que intervienen en la red de
procesos.
71Si se desea consultar una descripción global acerca de la forma como está implementada esta librería se
puede consultar http://www.cs.kent.ac.uk/projects/ofa/jcsp/jcsp-net-slides.ppt.
72http://www.quickstone.com .
98
ISC-2003-1-3
BIBLIOGRAFÍA
[1]. Amsden, Jim. Levels of Integration. En línea: http://www.eclipse.org/articles/Article-
Levels-Of-Integration/Levels%20Of%20Integration.html, Marzo 25, 2001.
[2]. 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. 211-245.
[3]. Bolour, Azad. Notes on the Eclipse Plug-in Architecture. En línea:
http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html
[4]. Brown, Richard. March of the IDEs. En: LinuxUser & Developer. Londres. No. 15 (oct.
2001); p. 27-35.
[5]. Campbell, Jonathan. Programming Languages and Paradigms. En l ínea :
http://www.cs.qub.ac.uk/~J.Campbell/myweb/oop/oophtml/node4.html, 1999.
[6]. 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.
[7]. Dart, Susan et al. Overview of Software Development Environments. En línea:
http://www.ida.liu.se/~petfr/princprog/envpaper.pdf, Suecia.
99
ISC-2003-1-3
[8]. Dean, David et al. Eclipse Development using the Graphical Editing Framework and
the Eclipse Modeling Framework. En: IBM Redbooks, Febrero 2004.
[9]. Dewayne, Perry. Industrial Strength Software Environments. En:. Proceedings of IFIP
'89 - 11th World Computer Congress. Agosto 1989, San Francisco.
[10]. 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.
[11]. Eclipse. Platform Plug-in Develoment Guide. En: Incluida con la herramienta.
Sección: Platform Architecture.
[12]. Edwards, Steve. Programming Language History and Evolution. En l ínea :
http://courses.cs.vt.edu/~cs3304/Spring00/notes/Chapter-2/index.htm, 2000.
[13]. Furse, Edmund. Introduction to Programming Paradigms. En línea :
http://www.comp.glam.ac.uk/pages/staff/efurse/Teaching/PP/Introduction.html, 1998.
[14]. Gallardo, David. Getting Started With The Eclipse Platform. En línea: http://www-
106.ibm.com/developerworks/opensource/library/os-ecov/
[15]. Gamma, Erich et al. Design Patterns Elements of Reusable Object-Oriented Software.
New York, Addison-Wesley, 2002
[16]. GEF Developer Guide. Model-View-Controller Paradigm. Documentación incluida
en el componente.
[17]. Hayes, Brian. The Post-OOP Paradigm. En: American Scientist. Vol. 91, No. 2 (mar.
– abr. 2003); p.108.
[18]. Hoare, C. A. R. Communicating Sequential Processes. En: Communications of the
ACM. New York. Vol. 21, No. 8 (ago. - sep. 1978); p. 666-677.
100
ISC-2003-1-3
[19]. Hoare, C. A. R. The Communicating Sequential Processes. Prentice Hall, 1985. p.
207.
[20]. Jakarta Velocity. Design Document. En línea:
http://jaakrta.apache.org/velocity/design.html
[21]. Kuhn, Thomas. La Estructura de las Revoluciones Científicas. Bogotá: Fondo de la
cultura económica, 1994.
[22]. Lea, Doug. Programación Concurrente en JAVA™ Principios y Patrones de Diseño.
Segunda Edición. Madrid, Addison Wesley, 2001.
[23]. Lohr, Steve. Some IBM Software Tools To Be Put in Public Domain. En: The New
York Times, New York: (05, Nov., 2001); p. 2C, c. 5
[24]. Object Technology Internacional, Inc. Eclipse Platform Technical Overview. En línea:
http://www.eclipse.org. Julio 2001, actualizado en febrero de 2003.
[25]. Open Source. The Approved Licenses. En línea : http://www.opensource.org/licenses/
[26]. Roscoe, A. W. The Theory and Practice of Concurrency. Prentice Hall, 1997.
[27]. Senoir Corps. Tech Center. Understanding Licenses. En línea:
http://www.seniortechcenter.org/reference_library/software/understanding_licenses.php
[28]. Shah, Rawn. Working the Eclipse Platform. En línea: http://www-
106.ibm.com/developerworks/library/eclipse/
[29]. Springl, Milan. Rule-based Process Models. En línea:
http://sern.ucalgary.ca/~springl/Seng609-01/seng609-01-rbde.html, 1998.
[30]. Welch, Peter. JCSP Documentation. En línea:
http://www.cs.kent.ac.uk/projects/ofa/jcsp/jcsp-1-0-rc4/jcsp-docs/
[31]. Welch, Peter. Process Oriented Design for Java: Concurrency for All. University of
Kent at Canterbury.
101
ISC-2003-1-3
ANEXOS
Anexo A. Diagrama de componentes.
ISC-2003-1-3
Anexo B. Diagrama de clases, Lógica de negocio.
103
ISC-2003-1-3
Anexo C. Diagrama de clases, Modelo de vista.
ISC-2003-1-3
Anexo D. Diagrama de clases, Modelo de Controladores.
105
ISC-2003-1-3
Anexo E. Diagrama de clases, Editor Gráfico.