Diseo de Software

14deseptiembre

2007
Anlisis Arquitectnico dela herramienta FLABot.

El objetivo del presente trabajo es realizar una descripcin arquitectnica de la herramienta grfica FLABot.

Integrantes
Helling, Alejandro Mercado, Matas
(adhelling@yahoo.com.ar)

(matiasmercado2003@yahoo.com.ar)

Diseo de Software

Especificacin Arquitectnica FLABot

Tabla de Contenidos
1 - Caso de Estudio....................................................................... 5 1.1 - Especificacin Arquitectural ..................................................... 5 1.1.1 - Arquitectura Extensin Point ............................................... 5 1.1.2 - Arquitectura GEF y EMF .................................................... 10 1.1.2.1 Modelo .................................................................... 10 1.1.2.2 Vista ....................................................................... 11 1.1.2.3 Controlador............................................................... 11 1.1.2.4 Comandos en el plug-in GEF ........................................... 12 1.2 - Especificacin Arquitectural: Arquitectura FLABot ......................... 13 1.2.1 El Editor FLABot ............................................................. 14 1.2.2 Vista, Modelo y Controlador del Diagrama de Componentes ......... 16 1.2.2.1 Modelo ..................................................................... 16 1.2.2.2 Controlador ............................................................... 18 1.2.2.3 Vista ........................................................................ 20 1.2.3 - Vista, Modelo y Controlador del Diagrama de Mapa de Caso de Uso 22 1.2.3.1 Modelo ..................................................................... 22 1.2.3.2 Controlador ............................................................... 24 1.2.3.3 Vista ........................................................................ 26 1.2.4 - Trabajando con el nuevo archivo .flabot ................................ 28 1.2.4.1 Agregar componente al Diagrama de Componentes ............... 28 1.2.4.2 El nodo Stub AgregarModeloSemntico .............................. 29 1.2.4.3 El nodo stub AgregarModeloVisual .................................... 30 1.2.4.4 Agregar puerto al Diagrama de Componentes ...................... 31 1.2.4.5 Agregar/Borrar responsabilidad al Diagrama de Componentes .. 32 1.2.4.7 Suscripcin del EditPart al Modelo ................................... 33 1.2.4.8 Generacin de Reportes................................................ 34 2- Estadsticas tomadas ................................................................ 36 2.1 Mtricas.......................................................................... 36 2.2 Tiempos.......................................................................... 38 2.3 - Relacin mtricas-tiempos ................................................... 40 3 Referencias........................................................................... 41

Helling Mercado

Pgina 2 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Tabla de Figuras
Figura I: Arquitectura de los puntos de extensin de Eclipse. ................... 6 Figura II: Extensin de plug-in. ........................................................ 6 Figura III: UCM de la carga de acciones............................................... 7 Figura IV: Flujo de registrar punto de extensin.................................... 8 Figura V: Flujo de creacin de grupo de solapas.................................... 9 Figura VI: Interaccin de los componentes relacionados al GEF................. 10 Figura VII: Relacin entre modelo semntico y modelo visual................... 11 Figura VIII: Linkeo de cada parte del modelo con su representacin visual a travs del editPart asociado........................................................... 12 Figura IX: Ejecucin de comando en el plug-in GEF. .............................. 13 Figura X: Diagrama de Clases de los tipos de Diagramas de FLABot. ........... 14 Figura XI: UCM de la creacin de un nuevo archivo FLABot. .................... 15 Figura XII: Diagrama bsico de clases de FLABot................................... 15 Figura XIII: Vista esttica del modelo del editor diagrama de componentes. . 17 Figura XIV: Vista esttica de los controladores del diagrama de Componentes. ............................................................................................. 19 Figura XV: Diagrama de las vistas del diagrama de componentes............... 21 Figura XVI: Vista esttica del modelo del editor diagrama de Mapa de Caso de Uso......................................................................................... 23 Figura XVII: Vista esttica de los controladores del diagrama de Mapa de Caso de Uso. .................................................................................... 25 Figura XVIII: Diagrama de vistas del diagrama de Mapa de Caso de Uso. ...... 27 Figura XIX: UCM del agregado de un componente al Diagrama de Componentes ............................................................................................. 29 Figura XX: UCM de la insercin del modelo semntico de un elemento al modelo. ................................................................................... 30 Figura XXI: UCM de la insercin del modelo visual de un elemento al modelo. ............................................................................................. 31 Figura XXII: UCM del agregado de un puerto a un componente del Diagrama de Componentes............................................................................. 32

Helling Mercado

Pgina 3 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura XXIII: UCM del agregado/borrado de una responsabilidad al Diagrama de Componentes............................................................................. 33 Figura XXIV: UCM de la suscripcin de un elemento al contenedor de modelos. ............................................................................................. 34 Figura XXV: UCM de la generacin de Reporte. .................................... 35 Figura XXVI: Resumen de las mtricas calculadas. ............................. 38 Figura XXVII: Resumen de los tiempos invertidos en el estudio del proyecto. 39 Figura XXVIII: Relacin mtricas/tiempo. ........................................... 40

Helling Mercado

Pgina 4 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

1 - Caso de Estudio
El presente caso de estudio representa la simulacin del uso de una herramienta para disear vistas de comportamiento de algn sistema. El objetivo del usuario es especificar la arquitectura bsica de un sistema sobre el cual se trabajar, haciendo uso de los elementos provistos por los editores administrados por el plug-in FLABot. Para el usuario hacer uso de los editores anteriormente mencionados, deber seguir los siguientes pasos: i) identificar los componentes y las responsabilidades existentes en el sistema analizado, ii) plasmar estos elementos en el Diagrama de Componentes, iii) asignar responsabilidades a los diferentes componentes, iv) relacionar los componentes existentes a travs de interfaces de conexin que ellos mismos proveen y/o requieren, v) utilizando los componentes definidos en el Diagrama de Componentes, establecer los flujos de ejecucin del sistema analizado, en el Diagrama de Mapa de Caso de Uso.

1.1 - Especificacin Arquitectural

1.1.1 - Arquitectura Extensin Point
Un plug-in es la unidad mnima de funcionalidad de Eclipse que puede ser distribuida de manera separada. Herramientas pequeas se escriben como un nico plug-in, mientras que en las complejas la funcionalidad est en varios plug-ins. Excepto un pequeo ncleo de la plataforma Eclipse, el resto de la funcionalidad de la plataforma Eclipse est implementada como plug-ins. Cada plug-in tiene un fichero denominado de manifest en el cual se declaran sus interconexiones con otros plug-ins. La interconexin sigue un modelo muy simple: un plug-in declara un nmero de los denominados puntos de extensin, y un nmero de extensiones para uno o ms puntos de extensin de otros plug-ins. La interfaz entre dos plug-ins (el que extiende y el extendido) se conoce como punto de extensin (extension point). Bsicamente, un punto de extensin es la entrada a travs de la cual un plug-in puede aportar una nueva funcionalidad.

Helling Mercado

Pgina 5 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Plug-in X
Punto de Extensin P Aporta

Plug-in Y
Extensin

Interfaz I

Implementa

Clase Z

Crea, llama a

El Plug-in X declara el punto de extensin P y la interfaz I asociada a P. El Plug-in Y implementa la interfaz I con su clase Z y por lo tanto aporta a la clase Z el punto de extensin P. El plug-in X se encarga de crear instancias de la clase Z y de llamar a sus mtodos

Figura I: Arquitectura de los puntos de extensin de Eclipse.

La siguiente figura muestra como un plug-in extiende a otro. org.xxx

Editores Vistas Plug-in anfitrin Perspectivas Puntos de extensin

org.yyy
<extensin point = org.eclipse.ui.perspectives <perspectiva /> Plug-in

Figura II: Extensin de plug-in.

Adems de los puntos de extensin, el anfitrin puede definir acciones globales. Estas acciones, que son implementadas por el plug-in que extiende, tienen una semntica nica. Como ejemplos, encontramos el caso de las acciones nuevo, abrir, cerrar y guardar. En ese caso, cada plug-in las implementar con un comportamiento adecuado, pero la semntica de la accin se conserva. A continuacin se muestra la forma en que el plug-in anfitrin crea una accin global: IAction action = new PasteAction ( PasteAction.getId(), "paste" ); La creacin de una accin global requiere un id y una etiqueta. El id le permite a otro plug-in poder identificar la accin global a implementar, segn se muestra a continuacin:

Helling Mercado

Pgina 6 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

getViewSite().getActionBars().setGlobalActionHandler( PasteAction.getId(), newProjectAction ); Donde newProjectAction es una instancia IAction que implementa el mtodo run() con el comportamiento deseado para la accin global. Por otra parte, un plug-in podra no implementar todas las acciones globales definidas en el anfitrin, en cuyo caso, quedaran deshabilitadas. A continuacin se muestra la arquitectura de carga de acciones segn una vista de UCM.

Figura III: UCM de la carga de acciones.

El registro de un punto de extensin se realiza con la informacin obtenida del archivo .xml del plug-in. De este archivo toma los puntos de extensin, las clases que los extienden (implementan) y el path del plug-in. La obtencin de la informacin est a cargo de RegistryStrategyOSGI. Usando como clave el path del plug-in, la clase RegistryObjectManager se encarga de registrar la informacin del punto de extensin, provista por ExtensionRegistry. El siguiente Use Case Map expresa este comportamiento:

Helling Mercado

Pgina 7 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura IV: Flujo de registrar punto de extensin.

A su vez, y a modo de ejemplo, el flujo que nace con el doble clic o de la accin new que se realiza sobre el FlabotCollectionSession, y que crea un grupo de solapas se visualiza a continuacin. Este grfico muestra al final del flujo, al punto de extensin propiamente dicho (y que luego ser extendido por FlabotLauncherTabGroup).

Helling Mercado

Pgina 8 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura V: Flujo de creacin de grupo de solapas

Helling Mercado

Pgina 9 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

1.1.2 - Arquitectura GEF y EMF

GEF pone nfasis en desacoplar las distintas capas de un editor grfico y brinda especial soporte para la implementacin del controlador. En GEF, el controlador es el encargado, entre otras cosas, de hacer de intermediario entre la vista y el modelo. El esquema de trabajo de alto nivel es el siguiente:

Figura VI: Interaccin de los componentes relacionados al GEF.

A continuacin se detalla cada una de las partes:

1.1.2.1 Modelo
El Modelo consta de la informacin de base que interesa almacenar en un editor. La informacin que contenga el Modelo es la que va a ser persistida al momento de guardar o cerrar un editor y con la que se contar al momento de abrirlo. Si bien GEF no pone restricciones en cuanto a las interfaces o clases abstractas que debe extender el Modelo, es necesario que dicho Modelo cuente con un mecanismo para notificar adecuadamente sus cambios a terceras partes. Este mecanismo es necesario para que el Controlador pueda actuar al momento de registrar un cambio en el Modelo. Dado que GEF no suministra ninguna clase base para el armado del modelo, se confeccion un modelo en base a EMF, la cual brinda las caractersticas principales comunes para todos los elementos del modelo. Una de las caractersticas ms importantes, es la posibilidad de registrarse para ser notificado ante el cambio de cualquiera de las propiedades del elemento. Los cambios realizados sobre el modelo por parte del Controlador (generalmente a pedido del usuario) son representados por Comandos. Los comandos, slo deben conocer la existencia del, y deben contener la lgica para efectuar o deshacer los cambios requeridos por el Controlador.

Helling Mercado

Pgina 10 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Cada elemento del modelo (del GEF), mezcla atributos visuales (como fuente y color) y atributos del modelo (como componentes y pre-condiciones). De esta forma todos los atributos estn en cualquier modelo. Para evitar esta mezcla, se divide al modelo en dos partes: modelo visual y modelo semntico, pudiendo tener un modelo semntico varios modelos visuales. Generalmente los modelos visuales se registran como observadores del modelo semntico. Esta organizacin, proporciona una gran flexibilidad para modelar los elementos que componen un diagrama de componentes y un diagrama de UCM. As el modelo semntico soporta el modelamiento de los elementos de los diagramas, mientras que el modelo visual brinda una interfaz general para todos estos elementos. La relacin entre estos dos modelos se refleja en el siguiente grfico:
setearAtributoSemntico

Modelo Semntico

obtenerAtributoSemntico setearAtributoVisual notificarCambio

Modelo Visual

notificarCambio

Vista
obtenerAtributoVisual

Figura VII: Relacin entre modelo semntico y modelo visual.

1.1.2.2 Vista
La Vista compone la capa visual del editor. Dada la gran separacin entre capas que propone GEF, la vista no puede conocer o hacer referencia a ningn objeto del modelo, ni tampoco tener lgica asociada al editor. S debe contener informacin propia de la representacin visual de los elementos que se pretenden graficar. GEF utiliza Draw2D como capa visual base y en ella, el elemento atmico es la figura, representada por la interface IFigure. Draw2D provee una amplia cantidad de figuras elementales prediseadas y la composicin entre ellas permite un amplio rango de posibilidades con un mnimo esfuerzo. Por lo general, un elemento del modelo tiene asociado una figura de la Vista, aunque no es una limitacin del framework.

1.1.2.3 Controlador
El Controlador tiene el papel de mediador entre el usuario, la vista y el modelo. En GEF, el controlador es llamado EditPart. Principalmente, acta de observador del modelo, reflejando los cambios en la vista cuando es necesario. Por lo general existe un EditPart por cada elemento del modelo
Helling Mercado Pgina 11 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

(aunque no es una limitacin), y entre los distintos EditParts se forma una estructura de rbol, siendo el nodo raz el correspondiente al diagrama. Los EditParts tambin son los encargados de administrar los pedidos de cambio del usuario, denominados Requests, y transformarlos en Comandos. Por ejemplo para el tipo de pedido delete (borrar), la poltica de edicin deber identificar el tipo elemento a borrar y crear el comando de borrado, correspondientemente. La administracin tambin consta de aceptar, ignorar o rechazar los Requests, a travs de clases que encapsulan las polticas de edicin.

Modelo

Controlador (EditPats)

Vista

Figura VIII: Linkeo de cada parte del modelo con su representacin visual a travs del editPart asociado.

1.1.2.4 Comandos en el plug-in GEF

El plug-in GEF proporciona soporte para la implementacin de las acciones ejecutar, hacer y deshacer. Esto lo realiza a travs de comandos, que pueden ser sobrecargados por el usuario, de modo de realizar la accin que ste desee. Para llevar a cabo la ejecucin de los comandos, el plug-in cuenta con una pila para ellos, a la cual se le van agregando uno a uno los comandos a ejecutar. Gracias a esta pila existe el soporte para hacer y deshacer. El siguiente UCM muestra el comportamiento de los flujos de lo comentado anteriormente:

Helling Mercado

Pgina 12 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura IX: Ejecucin de comando en el plug-in GEF.

1.2 - Especificacin Arquitectural: Arquitectura FLABot

Los mdulos relevantes para la arquitectura de FLABot son CoreModel y Editor. Bsicamente, CoreModel guarda toda la informacin proveniente de los diagramas de arquitectura existentes en el proyecto, mientras que el Editor encapsula la mecnica para la manipulacin de diagramas. Los mdulos restantes pueden verse como divididos en dos editores especializados: un editor para Diagramas de Componentes y como un editor para UCMs1, respectivamente. Aunque ellos comparten algunas caractersticas, cada uno de estos editores poseen su propia funcionalidad y diagramas. Las clases/interfaces responsables del funcionamiento de estos editores son:

UCM: Mapa de Caso de Uso

Helling Mercado

Pgina 13 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura X: Diagrama de Clases de los tipos de Diagramas de FLABot.

De acuerdo al caso de estudio planteado, identificamos dentro de los requerimientos funcionales, un grupo que se destaca: Crear nuevo proyecto FLABot, Crear nuevo Diagrama de Componentes, Crear nuevo Diagrama de Mapa de Caso de Uso, Agregar, modificar y eliminar elementos2 a los diferentes diagramas, Agregar, modificar y eliminar responsabilidades, Chequear consistencia en el modelo, Exportar como imgenes los diferentes diagramas, Generar reportes HTML sobre la especificacin de los diagramas. Seguidamente se describe como se materializan estos requerimientos funcionales en la arquitectura del FLABot, haciendo uso de vistas estticas (Diagrama de Clases) y/o dinmicas (Use Case Map).

1.2.1 El Editor FLABot

Para poder hacer uso de esta herramienta, primeramente se debe crear un archivo .flabot, el cual es almacenado de acuerdo a los datos ingresados por el usuario. Al momento en que se crea este archivo, tambin se le crea un
2

Como elemento nos referimos a: componente, puerto, interface, nota, conexin y relacin.

Helling Mercado

Pgina 14 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

modelo y un editor de Diagrama de Componentes y un editor de Mapa de Caso de Uso por defecto. Este proceso puede visualizarse en el siguiente Use Case Map.

Figura XI: UCM de la creacin de un nuevo archivo FLABot.

La materializacin de las responsabilidades pertenecientes a las clases presentes en este diagrama se encuentra en el archivo adjunto materializacin.html La vista esttica de las clases/interfaces que materializan el flujo de correspondiente a la accin de agregar un archivo .flabot es presentada a continuacin:

Figura XII: Diagrama bsico de clases de FLABot.

Helling Mercado

Pgina 15 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Como se puede observar en la figura, la interface FlabotFileModel, contiene un Modelo, al igual que la interfaz diagrama. De esta forma el FlabotFileModel contiene al modelo a travs del cual conoce a sus diagramas. A su vez el Diagrama puede dividirse en UCMDiagram o ComponentDiagram.

1.2.2 Vista, Modelo y Controlador del Diagrama de Componentes

En la seccin de la especificacin Arquitectnica del Framework, se explic el estilo MVC conformado tanto por GEF como por EMF. Cabe aclarar que cada uno de los editores grficos pertenecientes a la herramienta, reimplementa cada una de sus partes, es decir que contienen una serie de clases e interfaces que actan de modelos, vistas y controladores.

1.2.2.1 Modelo
El modelo del Diagrama de Componentes, se conforma principalmente por las interfaces: StereotypeElementModel, NameElementModel, PropertyElementModel, NoteElementModel, Property, Note, RelationShip, Stereoype, ComponentModel, PortModel, InterfaceModel, Interfacelink, FeatureModel y CoreModel. El componente contiene una serie de puertos, caractersticas y relaciones, y un estereotipo, que lo describen. Cada puerto contiene dos conjuntos de interfaces (Provistas y Requeridas), que son utilizadas para describir los tipos de servicios que se proveen o se requieren. El CoreModel se conforma de un grupo de componentes, estereotipos, relaciones e interfaces. Esta interface es el ncleo del Diagrama de Componentes ya que su implementacin (CoreModelImpl) es quien administra todos los elementos del diagrama. De esta manera, cualquier modificacin sobre algn elemento se ve reflejada sobre ella.

Helling Mercado

Pgina 16 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura XIII: Vista esttica del modelo del editor diagrama de componentes.

Helling Mercado

Pgina 17 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

1.2.2.2 Controlador
El controlador del Diagrama de Componentes, se conforma principalmente por las interfaces: ContainerEditPart, PortEditPart, InterfaceEditPart, ProvidedInterfaceEditPart, RequiredInterfaceEditPart, ConnectedEditPart, ComponentEditPart, ConnectionEditPart, ConnectionToConenectionEditPart, InterfaceConnectionEditPart, RelationshipConnectionEditPart, ComponentDiagramEditPart. Cada uno de los controladores se encarga de crear su figura (en realidad cada uno delega esto a la clase IFigure de draw2d), de crear sus polticas (es decir que crea sus propios comandos y los apila en la pila de comandos (CommandStack)) y notificar cambios a quien corresponda. ContainerEditPart, ConnectionEditPart y ComponentDiagramEditPart implementan el mtodo HookIntoModel, que agregar al modelo el adapter del elemento que es pasado por parmetro (de esta forma queda suscripto el controlador al modelo). A su vez implementan el mtodo UnhookFromModel que realiza justamente la accin inversa (extrae el adapter del modelo).

Helling Mercado

Pgina 18 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura XIV: Vista esttica de los controladores del diagrama de Componentes.

Helling Mercado

Pgina 19 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

1.2.2.3 Vista
Las principales clases que conforman la vista del Diagrama de Componentes son: ComponentFigure, PortFigure, InterfaceFigure, ProvidedInterfaceFigure, RequiredInterfaceFigure. Todas estas clases heredan directa o indirectamente de Figure (de draw2d). As, se encargan de todo lo referido al aspecto visual de los elementos, tanto de los valores iniciales como de las actualizaciones. Puede verse en la clase ComponentFigure, ejemplos de ambos: un valor inicial es name, y su respectiva actualizacin es updateName(). La figura del puerto (PortFigure), contiene adems una variable que indica de que lado del componente se encuentra (side). Asimismo la figura InterfaceFigure tambin la posee y la hereda a sus hijos (ProvidedInterfaceFigure, RequiredInterfaceFigure).

Helling Mercado

Pgina 20 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura XV: Diagrama de las vistas del diagrama de componentes.

Helling Mercado

Pgina 21 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

1.2.3 - Vista, Modelo y Controlador del Diagrama de Mapa de Caso de Uso

1.2.3.1 Modelo
Las principales interfaces/clases que conforman el modelo del Diagrama de Mapa de Caso de Uso son: Note, NoteElementModel, Property, PropertyElementModel, NameElementModel, StereotypeElementModel, Path, PathNode, SimplePathNode, ResponsabilityRole UseCaseMap, StubNode, ComponentNode, Responsability, ForkNode, JoinNode, CoreModel. El modelo (CoreModel) contiene un conjunto de mapas de casos de uso (UseCaseMap) y un conjunto de nodos de responsabilidades (ResponsabilityNode). A su vez estos nodos contienen una responsabilidad (Responsability), y de ellos heredan tanto el nodo bifurcacin (ForkNode) como el nodo reunin (Join Node), que pueden ser or o and. Por otro lado el mapa de casos de uso contiene un conjunto de paths (Path) y otro de roles de componentes (ComponentRole). Cada uno de estos paths, contiene tres listas de nodos que conforman un path, llamadas Nodes, EndNodes y StartNodes, que hacen referencia a los nodos intermedios, finales e iniciales de algn path en particular. CoreModel vuelve a ser el centro del modelo, al igual que en el modelo del Diagrama de Componentes. Conoce directa o indirectamente a todos los elementos contenidos en el diagrama de mapa de casos de uso.

Helling Mercado

Pgina 22 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura XVI: Vista esttica del modelo del editor diagrama de Mapa de Caso de Uso.

Helling Mercado

Pgina 23 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

1.2.3.2 Controlador
De entre las clases/interfaces que lo conforman, las principales son: ComponentEditPart, ConnectedEditpPart, VisualDiagramJumpEditPart, PathNodeEditPart, ResponsabilityNodeEditPart, StubNodeEditPart, JoinNodeEditPart, ForkNodeEditPart, ConnectionEditPart, ConnectionToConnectionEditPart, UCMDiagramEditPart, PathSegmentEditPart. Cada uno de los controladores se encarga de crear su figura (en realidad cada uno delega esto a la clase IFigure de draw2d), de crear sus polticas (es decir que crea sus propios comandos y los apila en la pila de comandos (CommandStack)) y notificar cambios a quien corresponda. ConnectionEditPart y ResponsabilityNodeEditPart implementan el mtodo HookIntoModel, que agregar al modelo el adapter del elemento que es pasado por parmetro (de esta forma queda suscripto el controlador al modelo). A su vez implementan el mtodo UnhookFromModel que realiza justamente la accin inversa (saca el adapter del modelo).

Helling Mercado

Pgina 24 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura XVII: Vista esttica de los controladores del diagrama de Mapa de Caso de Uso.

Helling Mercado

Pgina 25 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

1.2.3.3 Vista
Las clases/interface principales que materializan la vista del diagrama de mapa de casos de uso son: ThreeConnectionFigure, AndForkFigure, OrForkFigure, AndJoinFigure, OrJoinFigure, VisualDiagramJumpFigure, PathPointFigure, ResponsabilityNodeFigure, StubFigure. Estas clases se encargan de todo lo referido al aspecto visual de los elementos, tanto de los valores iniciales como de las actualizaciones. Puede verse en la clase PathPointFigure, ejemplos de ambos: un valor inicial es name, y su respectiva actualizacin es updateName(). La clase ThreeConnectionFigure, contiene adems una variable que indica la ubicacin del nodo con respecto a la rotacin que puede realizar. Es decir que el nodo pude rotar, y esta variable indica en cual de las cuatro posiciones posibles se est visualizando. De esta clase extienden los nodos de bifurcacin (AndForkNode y OrForkNode) y los nodos de reunin (AndJoinNode y OrJoinNode), quienes implementan los movimientos de rotacin del nodo en cuestin.

Helling Mercado

Pgina 26 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura XVIII: Diagrama de vistas del diagrama de Mapa de Caso de Uso.

Helling Mercado

Pgina 27 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

1.2.4 - Trabajando con el nuevo archivo .flabot

Una vez explorada la composicin de los componentes modelo, controlador y vista del editor y de ambos diagramas (ComponentDiagram y UCMDiagram), profundizaremos sobre el funcionamiento del flabot, mediante diagramas de mapa de casos de uso. Previamente se pudo observar el UCM de la creacin de un archivo .flabot y sus respectivos elementos (figura XI). Dentro de l se pudo apreciar tambin, el flujo para la creacin de un diagrama de mapa de casos de uso (la creacin de un diagrama de componentes, es anloga, salvo por la no creacin e insercin del Use Case Map). Una vez que se cuenta con los correspondientes diagramas, se pueden agregar los elementos a stos. Para visualizar la materializacin de las responsabilidades de las clases contenidas por cada Use Case Map, remitirse al archivo adjunto materializaciones.html.

1.2.4.1 Agregar componente al Diagrama de Componentes

El siguiente Use Case Map representa el flujo para la creacin de un componente en el diagrama de componentes. Tres flujos atraviesan el componente de la figura: AgregarComponente: agregar el componente al diagrama. Rehacer: revierte lo hecho por el flujo Deshacer. Deshacer: deshace la accin de agregar un componente. A partir del nodo de reunin or rehacerComandoComponente, solo uno de los dos flujos (agregarComponente y rehacer) contina. El que contina, se divide en dos flujos: agregarModeloSemntico y AgregarModeloVisual, quienes agregarn al componente en el modelo semntico y en el visual respectivamente. Para visualizar fcilmente esta divisin, se utilizaron nodos stub, que seguidamente sern detallados. La responsabilidad EjecutarAgregadoComponente tiene como precondicin el hecho de que exista un diagrama (en el grfico se indica mediante una T). Por otro lado, F, que figura en la parte inferior del grfico se debe a que el puerto tiene como precondicin el hecho de que exista un componente.

Helling Mercado

Pgina 28 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura XIX: UCM del agregado de un componente al Diagrama de Componentes

1.2.4.2 El nodo Stub AgregarModeloSemntico

Este use case map se generaliz por ser idntico el comportamiento de todos los tipos de elementos en cuanto a estos componentes (CoreModel, CoreModelTreeEditPart, ComponentTreeEditPart). Como se dijo en el caso de Agregar Componente, es idntico el flujo en el Use Case Map, pero internamente el proceso de agregar y borrar cada elemento de estos componentes, es diferente. En el detalle de este nodo se puede ver que hay dos flujos: Agregar elemento Borrar elemento El flujo de agregar un elemento, primeramente atraviesa el CoreModel donde se incorpora el elemento al modelo, luego se le notifica al correspondiente editPart de la insercin, y por ltimo se actualiza el rbol de elementos visuales. El flujo para borrar un elemento sigue el mismo camino, borrando primero el elemento del modelo, luego notificando al editPart del modelo y por ltimo actualizando el rbol de componentes.

Helling Mercado

Pgina 29 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura XX: UCM de la insercin del modelo semntico de un elemento al modelo.

1.2.4.3 El nodo stub AgregarModeloVisual

Como se dijo en la especificacin del modelo de GEF/EMF, el modelo esta dividido en modelo semntico y modelo visual. En esta seccin nos encargaremos de ver como se realiza el agregado del modelo visual a cada editPart.

Helling Mercado

Pgina 30 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura XXI: UCM de la insercin del modelo visual de un elemento al modelo.

1.2.4.4 Agregar puerto al Diagrama de Componentes

De la misma forma en que se agreg un componente al diagrama de componentes, se pueden agregar el resto de los elementos que lo componen. A modo de ejemplo se ver la insercin de un puerto en un componente. Con este Use Case Map, se ver que el agregado del puerto y del componente (en cuanto a flujo) solo vara en la precondicin que necesitan, y tambin se podr observar la dependencia entre dos elementos del mismo diagrama. Vale aclarar que la insercin de dos elementos de diferente tipo, representada por estos Use Case Map se ven casi idnticas, pero en realidad varan sus comandos, figuras, condiciones para la insercin, etc. La dependencia de elementos se da porque el puerto necesita de un componente para existir (en la figura se representa por medio de la T). Al igual que con el agregado del componente, el flujo de agregar el puerto llega a un nodo Join, por donde solo atraviesa ste flujo o el flujo del rehacer. Luego se divide en dos flujos que agregan el puerto al modelo semntico y al visual (al igual que cuando se agreg el componente).

Helling Mercado

Pgina 31 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura XXII: UCM del agregado de un puerto a un componente del Diagrama de Componentes.

Nota: la accin de agregar un componente en un diagrama de componentes, es similar (en lo que a flujo se refiere) a la de agregar un componente en un diagrama de casos de uso. La diferencia radica en que en el segundo caso, el modelo semntico ya existe, y es tomado del correspondiente diagrama de componentes, mientras que el modelo visual es nuevamente creado (por presentar algunas diferencias con respecto al modelo visual del componente en el diagrama de componentes). En general, la insercin de elementos en el diagrama de casos de uso, es muy similar a la insercin en diagrama de componentes.

1.2.4.5 Agregar/Borrar responsabilidad al Diagrama de Componentes

Al igual que en los casos de agregar un puerto y un componente, el flujo de agregar una responsabilidad comienza incluyndola en el modelo semntico del diagrama. Otra posibilidad del que flujo atraviese la responsabilidad agregarModeloSemntico, es el que nace en InicioRehacer. Otro posible flujo que atraviesa el componente es el InicioDeshacer, que deshace el ltimo agregado. Todos los flujos terminan en un nodo Stub, que detalla la incorporacin de la responsabilidad en el modelo semntico.

Helling Mercado

Pgina 32 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Anlogamente, el flujo InicioBorrar lleva a cabo la eliminacin de la responsabilidad. El flujo inicioRehacer e inicioDeshacer cumple la misma funcin que en el caso anterior.

Figura XXIII: UCM del agregado/borrado de una responsabilidad al Diagrama de Componentes.

1.2.4.7 Suscripcin del EditPart al Modelo

Cada editpart redefine su mtodo activate(), para poder suscribirse al modelo. En el nodo bifurcacin que conlleva la responsabilidad activar, se verifica que el editpart del elemento en cuestin no se encuentre ya suscripto al modelo. De ser as se lo suscribe, caso contrario el flujo termina. Este use case map, generaliza esta accin de suscripcin al modelo, puesto que para todos los elementos el flujo es el mismo (pero las implementaciones en cdigo son diferentes).

Helling Mercado

Pgina 33 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura XXIV: UCM de la suscripcin de un elemento al contenedor de modelos.

1.2.4.8 Generacin de Reportes

El editor flabot provee soporte para la generacin de reportes, en el cual se detallan todos los elementos contenidos en los diagramas del archivo .flabot para el cual se est generando el reporte. El archivo de salida tiene formato HTML, lo que permite una fcil navegacin. Para realizar este reporte, se utiliza el plug-in report ubicado en el proyecto. Esto es a travs de un punto de extensin. El flujo comienza por presentar un dilogo donde se selecciona el nombre del archivo y el path de destino. Con estos datos crea una tarea la cual es encolada en el administrador de tareas para su posterior ejecucin. Al momento de crear la tarea a encolar, se determinan (en el mtodo runInWorkspace() de la clase generateReportAction) las acciones a seguir para la contraccin del reporte que sern llevadas a cabo en el momento en que el administrador seleccione esta tarea encolada para su ejecucin. Cuando se ejecuta el mtodo runInWorkspace() se obtiene el modelo del flabotFileModel. Para la generacin del reporte se recorre este modelo y por cada elemento se obtiene las clases y el comportamiento mapeados a l.

Helling Mercado

Pgina 34 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura XXV: UCM de la generacin de Reporte.

Helling Mercado

Pgina 35 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

2- Estadsticas tomadas
En esta seccin del informe, se presentarn diferentes mtricas de los paquetes, subpaquetes y clases/interfaces que componen la parte central del plug-in FLABot. Asimismo se presentar una relacin entre la magnitud de los elementos que componen el cdigo del plug-in, y el tiempo utilizado para su comprensin. Esta ltima relacin denota el esfuerzo invertido en el entendimiento del funcionamiento del proyecto asignado.

2.1 Mtricas
Las mtricas fueron realizadas mediante el plug-in Metrics, y posteriormente filtrada para su mejor apreciacin. En el archivo adjunto mtricas.xls se puede explorar la informacin sin refinamientos, y su respectivo resumen (idntico al presentado a continuacin). El plug-in FLABot se encuentra distribuido en dos paquetes principales (coremodel y edit), y en dos paquetes secundarios (messages y util), los cuales contienen clases de utilidad, como por ejemplo la clase Message que es la encargada de obtener todo lo relacionado al texto que aparece en las diferentes interfaces de usuario. El paquete coremodel esta compuesto por 90 distribuidos a lo largo del cdigo en 21762 lneas. Estas cuentan en conjunto con 1318 mtodos por los cuales argumentos, es decir que cada mtodo recibe un promedio de clases/interfaces clases/interfaces se reciben 952 0.72 parmetros.

El paquete message esta compuesto por 7 clases/interfaces, los cuales suman un total de 369 lneas de cdigo (y comentarios). Estas clases/interfaces cuentan en conjunto con 18 mtodos por los cuales se reciben 31 argumentos, es decir que cada mtodo recibe un promedio de 1.72 parmetros. El paquete util esta compuesto por 32 clases/interfaces, las cuales cuentan 1869 lneas de cdigo. Las clases/interfaces poseen en total 141 mtodos y en promedio se obtiene por cada mtodo 1.13 parmetros. El paquete edit esta dividido en 9 subpaquetes (componenteditor, componentmodel, editor, editormodel, multipage, outline, ucmeditor, ucmmodel y wizards). El subpaquete componenteditor esta constituido de 79 clases/interfaces que a su vez esta compuesto por 485 mtodos que constan en total de 10099 lneas y 271 argumentos, dando un promedio de 0.56 argumentos por mtodo.

Helling Mercado

Pgina 36 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

El subpaquete componentmodel esta compuesto de 7 clases/interfaces, 42 mtodos y 999 lneas. La cantidad total de argumentos es de 27, dando un promedio de 0.64 argumentos por mtodo. El subpaquete editor esta conformado por 82 clases/interfaces divididas en 619 mtodos y 8692 lneas. En total este subpaquete cuenta con 411 parmetros y un promedio de 0.66 parmetros por mtodos. El subpaquete editormodel esta dividido en 30 clases/interfaces y en promedio contiene 19.76 mtodos por clase. A su vez cada mtodo recibe en promedio 0.61 argumentos. El paquete contiene 9442 lneas de cdigo y comentarios. El subpaquete multipage contiene un total de 35 clases/interfaces y 271 mtodos, siendo el nmero de lneas de cdigo de estas clases 5340, el promedio de lneas por mtodo es de 19.7. En total se pasan 210 parmetros. El subpaquete outline tiene 16 clases/interfaces compuestas de 132 mtodos, 1634 lneas y 39 argumentos. En promedio cada clase/interface tiene 102.12 lneas de cdigo y 8.25 mtodos. El subpaquete ucmeditor siendo 123 las clases/interfaces y 877 los mtodos que conforman este subpaquete, el promedio de mtodos por clase/interfaces es de 7.13. El nmero de lneas es de 20966 y el de argumentos es de 740 dando un promedio de 0.84 argumentos por mtodo. El subpaquete ucmmodel esta compuesto de 8 clases/interfaces que contienen 60 mtodos, 1242 lneas y 42 argumentos. El promedio de lneas por mtodo es de 20.7 y por clase/interface es 155.25. El subpaquete wizards contiene 5 clases/interfaces conformadas por 32 mtodos, dando un promedio de 6.4 mtodos por clase/interface. Contiene en total 1036 lneas y 23 argumentos. El promedio de argumentos por mtodos es de 0.72 y el de lneas por mtodos es de 32.37.

Helling Mercado

Pgina 37 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

Figura XXVI:

Resumen de las mtricas calculadas.

En resumen el plug-in est compuesto de 512 clases/interfaces compuestas 4592 mtodos dando un promedio de 8.97 mtodos por clase/interface. El nmero total de lneas del plug-in es de 83520, dando un promedio de 163.12 lneas por clase/interface y 18.19 por mtodo. El total de argumento es de 3267, dando un promedio de 0.71 argumentos por mtodo.

2.2 Tiempos
Los tiempos invertidos en el proyecto, fueron relevados a travs del plug-in Mylyn. Al igual que con las mtricas, estos datos fueron resumidos, y pueden ser explorados (junto con los datos sin refinamientos) en el archivo adjunto tiempos.xls. La siguiente tabla presenta un extracto de los tiempos invertidos en el proyecto, organizados por subpaquetes:

Helling Mercado

Pgina 38 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

paquete

subpaquete nivel 1
--CoreModel

subpaquete nivel 2
------ComponentModel ComponentEditor Editor EditorModel Multipage Outline UCMEditor UCMModel Wizards -------------

tiempo
07:03:55 12:04:22 02:21:11 00:36:20 18:05:55 04:56:14 03:19:36 06:30:41 02:27:53 10:03:32 01:12:54 0:07:12. 00:00:00 00:03:06 02:38:12 00:08:35 00:06:45 01:59:36 73:38:47

Flabot

Edit

icons message util launcher report mapping -------

Total
Figura XXVII: Resumen de los tiempos invertidos en el estudio del proyecto.

De esta tabla se infiere el hecho de que los subpaquetes en los que ms tiempo se invirti, fueron CoreModel, ComponentEditor y UCMEditor, ya que ellos contienen la mayor parte de la lgica del plug-in. El subpaquete message requiri poco tiempo (3 minutos segn el plug-in Mylyn), puesto que fue consultado en ocasiones (y en breves intervalos) para reconocer el texto presente en las GUI. En total, el tiempo invertido en el estudio del proyecto es de aproximadamente 73 horas y 38 minutos.

Helling Mercado

Pgina 39 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

2.3 - Relacin mtricas-tiempos

El esfuerzo invertido en la familiarizacin con el proyecto FLABot se ve expresado en la siguiente tabla:

PACKAGE CoreModel ComponentEditor ComponentModel Editor EditorModel Multipage Outline UCMEditor UCMModel Wizards Messages Util Flabot

#Clases/ #Mtodos #Lneas #Argumentos Tiempos interfaces 90 76 7 82 30 35 16 123 8 5 7 32 1 1318 485 42 619 593 271 132 877 60 32 18 141 4 21762 10099 999 8692 9442 5340 1634 20966 1242 1036 369 1869 70 952 271 27 411 361 210 39 740 42 23 31 160 0
12:04:22 18:05:55 00:36:20 04:56:14 03:19:36 06:30:41 02:27:53 10:03:32 01:12:54 0:07:12. 00:03:06 02:38:12 07:03:55

Figura XXVIII: Relacin mtricas/tiempo.

El subpaquete CoreModel, ComponentEditor y UCMEditor son los que ms tiempo han consumido para su estudio, debido a su gran extensin y complejidad. Puede verse en la tabla relacional, que stos 3 paquetes son los que mayor nmero de lneas contienen. Asimismo, y como es lgico, el subpaquete de nivel 1 que ms tiempo requiri fue el Edit, puesto que contiene una gran cantidad de subpaquetes de gran volumen y contiene la mayor parte del funcionamiento del plug-in (es decir, este paquete contiene los controladores, las interfaces de usuario, las comandos referentes a las acciones del usuario, y las acciones que se llevan a cabo sobre el modelo visual).

Helling Mercado

Pgina 40 de 41

Diseo de Software

Especificacin Arquitectnica FLABot

3 Referencias
http://publib-b.boulder.ibm.com/Redbooks.nsf/redbooks/ http://www.eclipse.org/articles/Article-GEF-EMF/gef-emf.html http://www.eclipse.org/gef/ http://www.eclipse.org/modeling/emf/ http://www.eclipse.org/mylyn/ http://open.ncsu.edu/se/tutorials/metrics/ ArchitecturalDesignFlabot-ISISTAN-DGN-TRP-0001 v1.0 EditorsDesignFlabot-ISISTAN-DGN-TRP-0002 v1.0 FaultLocatorPrototypeDesignFlabot-ISISTAN-DGN-TRP-0003 v1.0 Tesis de grado en ingeniera informtica: un framewrok para la visualizacin de patrones de diseo distribuidos y concurrentes implementados con programacin orientada a aspectos. Espaa. Eclipse Development - IBM - Eclipse Development using the Graphical Editing Framework and the Eclipse Modeling Framework

Helling Mercado

Pgina 41 de 41