RECUPERACIN ARQUITECTURA DE ARGOUML

EDWAR ALEJANDRO GIRALDO MUOZ

YULI ANDREA ORDOEZ GUZMAN

UNIVERIDAD DEL CAUCA

FACULTAD DE INGENIERIA ELECTRONICA Y TELECOMUNICACIONES
INGENIERIA INVERSA
POPAYN
2015

RECUPERACIN ARQUITECTURA DE ARGOUML

EDWAR ALEJANDRO GIRALDO MUOZ

YULI ANDREA ORDOEZ GUZMAN

TRABAJO FINAL

JOSE LUIS ARCINIEGAS HERRERA, PhD

MARTN MONROY ROS, MSC, PhD (c)
RODRIGO CERN, MSC, PhD (c).

UNIVERIDAD DEL CAUCA

FACULTAD DE INGENIERIA ELECTRONICA Y TELECOMUNICACIONES
INGENIERIA INVERSA
POPAYN
2015
2

CONTENIDO

Pg.
INTRODUCCIN ............................................................................................................... 6
1.

OBJETIVOS ............................................................................................................... 7
1.1 OBJETIVO GENERAL.............................................................................................. 8

2.

ARGOUML ................................................................................................................. 9
2.2 DATOS TECNICOS ............................................................................................... 10
2.3 PRINCIPALES FUNCIONALIDADES ..................................................................... 10

3.

HERRAMIENTAS DE INGENIERIA INVERSA ......................................................... 11

3.1 IPLASMA................................................................................................................ 11
3.2

MOOSE ............................................................................................................. 13

3.3 SOFTWARENAUT ................................................................................................. 17

4.

RESULTADOS ......................................................................................................... 18

5.

ANALISIS DE RESULTADOS................................................................................... 28

CONCLUSIONES ............................................................................................................ 30
BIBLIOGRAFA ................................................................................................................ 31

LISTA DE TABLAS

Pg
Tabla 1. Mtricas de la pirmide ..................................................................................... 13
Tabla 2. Rango de mtricas ............................................................................................ 13
Tabla 3. Relacin Resultados con Vistas ......................................................................... 29

LISTA DE FIGURAS
Pg
Figura 1. Arquitectura de iPlasma .................................................................................... 11
Figura 2. Metamodelo MEMORIA .................................................................................... 12
Figura 3. Pirmide de visin general ................................................................................ 12
Figura 4. Flujo de trabajo general de Moose .................................................................... 14
Figura 5. Familia de meta-modelos FAMIX ...................................................................... 15
Figura 6. Vista de dependencias de espacio de nombres y paquetes ............................. 16
Figura 7. Vista principal de Softwarenaut ......................................................................... 17
Figura 8. Proceso de Recuperacin Unificado ................................................................ 18
Figura 9. Resumen de la complejidad del sistema ........................................................... 19
Figura 10. Representacin mtrica .................................................................................. 20
Figura 11. Vista parcial complejidad sistema en Moose ................................................... 20
Figura 12. Vista de mdulos en Softwarenaut .................................................................. 21
Figura 13.Paquetes de ArgoUml ...................................................................................... 22
Figura 14. Complejidad del paquete uml .......................................................................... 23
Figura 15. Class BluePrint FigNodeModelElement .......................................................... 24
Figura 16. Representacin de paquetes de uml ............................................................... 24
Figura 17. Clase FigNodeModelElement en Softwarenaut ............................................... 25
Figura 18. Complejidad del paquete uml en Softwarenaut ............................................... 26
Figura 19.Class BluePrint de FigNodeModelElement en Moose ...................................... 26
Figura 20. Dependencias de paquetes en Moose ............................................................ 27
Figura 21. Que vistas son tiles para los interesados ...................................................... 29

INTRODUCCIN

Este proyecto tiene como objetivo el hacer la recuperacin de la arquitectura de un

sistema software que ha sido desarrollado desde la comunidad open source y
proponer un prototipo de mecanismo para la comunicacin de la arquitectura de
un sistema software, teniendo en cuenta que la comunidad open source no cuenta
con un lugar de reunin sino que por lo general es un grupo de personas que
estn distribuidas por todo el mundo. Durante el desarrollo del proyecto se hace
uso de herramientas de ingeniera inversa para la recuperacin de la arquitectura
de un sistema, las cuales nos proveen de vistas arquitectnicas del sistema donde
se puede observar este desde un nivel general hasta llegar a un nivel de detalle
donde podemos ver una clase y ver como es el comportamiento de esta.
Este documento est organizado de la siguiente forma. La seccin 1 presenta la
motivacin para realizar este proyecto, en la seccin 2 se presenta el sistema
software al cual se va realizar la recuperacin de su arquitectura, en la seccin 3
se presentan las herramientas de ingeniera inversa que se usaron para la
recuperacin de la arquitectura del sistema software, en la seccin 4 se presentan
los resultados ms relevantes de la recuperacin de la arquitectura de software,
en la seccin 5 se presenta el anlisis de los resultados, en la seccin 6 se
presenta el prototipo de comunicacin de una arquitectura y por ltimo se
presenta las conclusiones.

1. OBJETIVOS

Inicialmente el diseo de software fue entendido como la implementacin de la

funcionalidad del sistema, definida como la capacidad del sistema para hacer el
trabajo para el que fue construido1 1, dejando por fuera cualidades tales como la
interoperabilidad, modificabilidad y la portabilidad que tambin son propiedades a
cubrir a travs del desarrollo de un sistema software. Estas propiedades son
conocidas como atributos de calidad, los cuales son principalmente determinadas
por la arquitectura del sistema. Mientras que muchas estructuras pueden
satisfacer la funcionalidad, pocas estructuras pueden satisfacer la funcionalidad y
los atributos de calidad necesarios en el sistema. Las arquitecturas de software
surgen como un medio para satisfacer tanto las necesidades funcionales, como
los atributos calidad de un sistema 2.
El conocimiento sobre la arquitectura de un sistema ayuda a los desarrolladores a
identificar y localizar las partes del sistema que deben ser modificadas durante un
ciclo de evolucin o un requerimiento de mantencin, as como las dems partes
del sistema que se vern afectadas por dichos cambios 3. A medida que un
sistema software evoluciona, su arquitectura puede requerir ajustes, de manera
que sta erosiona sino se considera su documentacin, su coherencia con su
implementacin y en especial su rationale1 4 hacindose propensa a errores para
las labores de incremento en las funcionalidades y en las actividades de
mantenimiento, lo cual contribuye al rpido envejecimiento del software 5. Por lo
anterior, se considera que la arquitectura software es parte fundamental en la
evolucin de los sistemas software 6, por lo que su recuperacin es una la
necesidad de gran importancia cuando esta no se encuentra definida en forma
explcita 7 o hay divergencia entre la arquitectura prescriptiva2 y la arquitectura
descriptiva3. Se entiende la recuperacin de la arquitectura de software como el
proceso de ingeniera inversa en el que se obtiene la arquitectura explcitamente
documentada a partir de la arquitectura implcita o prescriptiva presente en un
sistema implementado y para el cual se requiere del conocimiento arquitectnico.
En particular la pequea industria de software, puede verse beneficiada por este
tipo de soluciones bien sea para evolucionar sus sistemas ya implementados o
para fortalecer su proceso de desarrollo al reutilizar soluciones desde el universo
de las soluciones del mercado 8, dentro de su misma organizacin o las
disponibles a nivel open source para generar valor rpidamente a sus clientes. Sin
embargo, la comprensin de los sistemas, son las mayores barreras para su
extensin y reutilizacin 9.
1

Rationale- la inclusin explcita de las decisiones tomadas durante el proceso de diseo y las
razones por las cuales esas decisiones fueron tomadas.
2
Decisiones tomadas respecto a la arquitectura
3
Decisiones explcitamente descritas en el documento de la arquitectura

La descripcin de la arquitectura es el instrumento del arquitecto el cual tiene dos

propsitos: capta las decisiones sobre la estructura, el comportamiento y la calidad
del sistema, a fin de orientar la construccin, mantenimiento y evolucin del
sistema, y para comunicar dichas decisiones a todos los interesados en el
sistema. Estas dos fuerzas no siempre son fciles de alinear 10. El problema de la
falta de arquitectura acorde a los sistemas desarrollados, se acrecienta en casos
donde por el mismo negocio del software, inician sin un plan arquitectnico en
mente, as como los desarrollos de software libre, donde adems de ser
realizados por un grupo numeroso de desarrolladores, no necesariamente posee
un grupo completamente destinado al ejercicio de la arquitectura, llevando a que
no siempre se cuente con toda la informacin acerca de la arquitectura del sistema
o definitivamente no se cuente con una arquitectura explcita 11.
1.1 OBJETIVO GENERAL
Documentar la arquitectura de ArgoUml a un nivel de diseo.

2. ARGOUML
2.1 DESCRIPCION

ArgoUML fue concebida como una herramienta y medio para uso en el anlisis y
diseo de sistemas de software orientado a objetos. Es similar a muchas de las
herramientas CASE comerciales que se venden como herramientas para el
modelado de sistemas de software12.
ArgoUML es potente y fcil de usar, soporta el diseo, desarrollo y documentacin
de las aplicaciones de software orientadas a objetos. ArgoUML pertenece a la
familia de aplicaciones de software llamado Computer Aided Software Engineering
(CASE).
Los usuarios de ArgoUML son diseadores de software, arquitectos,
desarrolladores de software, analistas de negocios, analistas de sistemas y otros
profesionales involucrados en el anlisis, diseo y desarrollo de aplicaciones de
software12.
ArgoUML fue concebido como un entorno y herramienta para usar en el anlisis y
diseo de sistemas de software orientados a objeto. Es similar a muchos de las
herramientas CASE comerciales que son vendidas como herramientas para
modelar sistemas software. ArgoUML tiene las siguientes caractersticas 13:

Es gratis.
ArgoUML se enfoca en investigacin en psicologa cognitiva para
proporcionar nuevas caractersticas que incrementen la productividad
soportando las necesidades cognitivas de diseadores y arquitectos de
software orientado a objeto.
ArgoUML soporta estndares abiertos extensivamenteUML, XMI, SVG,
OCL y otros.
ArgoUML es una aplicacin Java pura 100%. Esto permite a ArgoUML
funcionar en todas las plataformas que soporte java.
ArgoUML es un proyecto de cdigo abierto. La disponibilidad del cdigo
fuente asegura que una nueva generacin de diseadores de software e
investigadores ahora tienen un entorno de trabajo probado desde el que
pueden conducir el desarrollo y evolucin de tecnologas de herramientas
CASE.

2.2 DATOS TECNICOS

Nombre: ArgoUML
Productores: Jason Robbins
Tipo de Licencia: Eclipse Public License (EPL) 1.0.
Primera Version: Release 0.10.1 (Octubre 9, 2002)
ltima Versin: Release 0.34 (Diciembre 15, 2011)
Paradigma de Programacin: Programacin Orientada a Objetos
Lenguaje de Programacin: Java
Tamao: 184600 LOC

2.3 PRINCIPALES FUNCIONALIDADES

Estndares abiertos: XMI, SVG y PGML - ArgoUML soporta estndares abiertos UML, XMI, SVG, OCL y otros.
XML Metadata Interchange (XMI) es el estndar para guardar los meta-datos que
conforman un modelo UML particular. En principio, esto le permitir tomar el
modelo que ha creado en ArgoUML e importarlo en otra herramienta.
Diseo UML - ArgoUML utiliza GEF, UCI Graph Editing Framework para editar
diagramas UML. Se admiten los siguientes tipos de diagramas 13:

Diagramas de clases
Diagramas de mquina de estados
Diagramas de actividades
Diagramas de casos de uso
Diagramas de colaboracin
Diagramas de implementacin
Diagramas de secuencia

10

3. HERRAMIENTAS DE INGENIERIA INVERSA

3.1 IPLASMA
Es un entorno integrado para el anlisis de calidad de los sistemas de software
orientado a objetos que incluye soporte para todas las fases de anlisis
necesarios: desde la extraccin de modelos (incluyendo anlisis escalable para C
++ y Java) hasta el anlisis basado en mtricas de alto nivel, o la deteccin de la
duplicacin de cdigo. iPlasma tiene tres grandes ventajas: la extensibilidad de
anlisis soportado, la integracin con otras herramientas de anlisis y capacidad
de ampliacin.
En la Figura 1 se puede observar la arquitectura de iPlasma la cual cuenta con
unos extractores de modelos, estos son los encargados de tomar el cdigo fuente
y construir el modelo MEMORIA de dicho cdigo, para que en la capa de anlisis
que es donde se encuentran las herramientas encargadas de tomar el modelo y
realizar el respectivo anlisis para que en la capa de presentacin se muestren los
resultados de los anlisis.

Figura 1. Arquitectura de iPlasma14

11

Para que iPlasma pueda hacer el anlisis de un sistema software y pueda

presentar resultados que sean relevantes para un grupo de interesados, este
requiere que el cdigo fuente pase por unos extractores, estos tienen como
finalidad extraer del cdigo fuente los datos de diseo ms relevantes y traducirlos
a un modelo llamado MEMORIA, ver figura 2, este es un meta-modelo que puede
representar sistemas Java y C ++ de una manera uniforme, mediante la captura
de la informacin de diseo (por ejemplo, clases, mtodos). Una de las funciones
clave de MEMORIA es proporcionar un modelo consistente, incluso en presencia
de cdigo incompleto o bibliotecas que faltan, para permitir el anlisis de grandes
sistemas y facilitar la navegacin dentro de un sistema15.

Figura 2. Metamodelo MEMORIA

Dentro de los resultados que produce iPlasma est la pirmide de visin general,
ver figura 3, esta pirmide se utiliza para visualizar un sistema de software
completo de una manera muy compacta. Para ello se recoge un conjunto de
mtricas de las categoras de herencia, de acoplamiento y Tamao y complejidad,
y las pone en relacin 16.

Figura 3. Pirmide de visin general

Esta pirmide muestra un grupo de mtricas, ver tabla 1, las cuales estn
compuestas por su valor y un color, el valor indica el valor de esta mtrica y el
12

color corresponde a un indicador de que tanto encaja esta mtrica con respecto a
la industria, en la tabla 2 se muestran los rangos usados por la herramienta.

Sigla
NDD
HIT
NOP
NOC
NOM
LOC
CYCLO
CALL

Descripcin
Numero de descendientes directos
Altura rbol de herencia
Numero de paquetes
Numero de clases
Numero de mtodos
Lneas de cdigo
Complejidad ciclomatica
Llamados por mtodo
Tabla 1. Mtricas de la pirmide 16

Mtrica
CYCLO/LOC
LOC/NOM
NOM/NOC
NOC/NOP
CALLS/NOM
FANOUT/CALLS
ANDC
AHH

Bajo
0.16
7
4
6
2.01
0.56
0.25
0.09

Medio
0.20
10
7
17
2.62
0.62
0.41
0.21

Alto
0.24
13
10
26
3.2
0.68
0.57
0.32

Tabla 2. Rango de mtricas 16

3.2 MOOSE
Moose es una plataforma de cdigo abierto para la expresin de los anlisis de los
sistemas de software y de los datos en general, su objetivo principal es ayudar a
los ingenieros a comprender grandes cantidades de datos, y los sistemas de
software en particular. Desde un punto de vista conceptual, Moose se organiza de
la siguiente manera, ver figura 4.

13

Figura 4. Flujo de trabajo general de Moose17

Moose se dirige a varias categoras de personas:

Investigadores en el rea de ingeniera de anlisis de software, minera de
datos e ingeniera inversa.
Ingenieros y arquitectos que quieren entender los sistemas y datos.
Constructores/Desarrolladores de herramientas.
El insumo o entrada para el motor de Moose son datos. Por datos se entiende que
son todo los tipos de estructuras que contienen objetos, propiedades y relaciones.
Por ejemplo, un sistema de software escrito en Java, o bien, un conjunto de
archivos de configuracin escritos en XML, entre otros. Estos datos se cargan en
Moose travs de importadores. En Moose, se puede importar datos de diversas
fuentes y en diferentes formatos. Por ejemplo, Moose puede manejar la
importacin de la estructura de los sistemas de software escritos en varios
lenguajes de programacin ya sea a travs de importadores internos (por ejemplo,
Smalltalk14, XML, MSE), o a travs de las externas (por ejemplo, Java, JEE, C++).
Una vez importado, los datos se almacenan en los modelos con los cuales se
pueden comenzar a realizar distintos tipos de anlisis por parte de los ingenieros.
Moose permite manipular grandes cantidades de datos, pero presenta un
problema al momento de comprender y evaluar su estado, ya que los datos no
tienen una forma fsica o visual entendible. La falta de forma grfica de los datos
hace intil la habilidad humana para interpretar los modelos por medio de
estmulos visuales. Mondrian, es un motor de scripting basado en Smalltalk que
permite disear visualizaciones personalizadas de datos en una manera rpida
dentro de la plataforma Moose 17.
Para realizar el anlisis en este proyecto se hace uso de la familia de metamodelos FAMIX, la cual familia de meta-modelos que sirve para la representacin
de modelos relacionados con las diversas facetas de los sistemas de software.

14

Estos meta modelo permiten el anlisis y proporcionan una API rica que se puede
utilizar para consulta y navegacin, ver figura 5.

Figura 5. Familia de meta-modelos FAMIX18

Una vez se ha hecho la extraccin del cdigo fuente, Moose provee una serie de
funcionalidades, dentro de las cuales estn 19:

Vista de Dependencia de espacio de nombres y paquetes

Es una vista polimtrica en el que cada nodo es un espacio de nombres o paquete

y cada arco representa una dependencia. La grfica se presenta en capas de tal
manera que cada nodo se coloca debajo del nodo cliente, ver figura 6. Por lo
tanto, los espacios de nombres o paquetes de la parte inferior es el que se utiliza
por muchos clientes, pero no es usa por ninguno, y los de la parte superior son
utilizados por ningn otro espacio de nombres o paquete.
Los nodos tambin presentan las siguientes mtricas:
o La anchura viene dada por el nmero de clases (NOC) en el espacio de
nombres o paquete
o La altura es proporcionado por el nmero de mtodos (NOM) en el
espacio de nombres o paquete.

15

Figura 6. Vista de dependencias de espacio de nombres y paquetes 19

Complejidad del sistema

Es una vista que muestra un grfico en el cual los nodos representan las clases y
los nodos representan relaciones de herencia entre clases. Los nodos se
enriquecen visualmente con tres mtricas:
o El nmero de mtodos (NOM) se asigna en la altura.
o El nmero de atributos (NOA) se asigna de la anchura.
o El nmero de lneas de cdigo (LOC) se asigna en el color.
Moose ofrece una versin ligeramente mejorada. En primer lugar, para maximizar
el espacio en pantalla, en lugar de mostrar todas las jerarquas junto a la otra
horizontal, que se muestran en varias filas. En segundo lugar, las clases que no
heredan de cualquier otra clase se colocan en un "clases Solitarios" grupo de la
derecha.

16

3.3 SOFTWARENAUT
Es una herramienta que provee recuperacin de arquitectura a travs de
exploracin interactiva y visualizacin, tiene una arquitectura general de
recuperacin de arquitectura de software donde se tienen tres pasos: como la
extraccin de datos luego la abstraccin de la informacin, esta herramienta tiene
muy en cuenta la descomposicin jerrquica de un sistemas, cuando hay muchas
versiones sta herramienta crea una historia modelando cada versin y permite
visualizar la arquitectura.
La figura 7 muestra una vista de Softwarenaut, esta vista ofrece una visin de alto
nivel de los mdulos del sistema y las relaciones fundamentales entre ellos. Los
mdulos se representan como diagramas de rbol, y el tamao de cada mdulo es
proporcional a su tamao real en lneas de cdigo; la anchura de cada relacin es
proporcional al nmero de invocaciones entre los mdulos correspondientes. Las
vistas producidas son interactivas, lo que permite inspeccionar los detalles o hacer
zoom en los mdulos y las relaciones individuales. Las visitas tambin pueden ser
guardadas y compartidas 20.

Figura 7. Vista principal de Softwarenaut

17

4. RESULTADOS

Panas et. al. 21 definen el proceso unificado para ingeniera inversa, incluyendo
anlisis de los programas, el filtrado, la compresin de informacin sobre el
programa y la visualizacin del programa, ver figura 8. La Ingeniera inversa
consta de tres partes: el anlisis, el enfoque y la visualizacin de un sistema.
Existen numerosas tcnicas de anlisis que permiten recuperar informacin sobre
el programa desde el cdigo fuente fiable y establecer modelos apropiados para la
comprensin y modificacin. Para evitar que en el anlisis el programa de
resultados incomprensibles, la informacin se filtra y el programa de visualizacin
es responsable de representar la informacin sobre el sistema. Adems, se hace
una mejor comprensin mediante visualizacin interactiva. La tarea principal en
arquitectura de software es la comprensin, la identificacin de los componentes
de un paquete grfico.

Figura 8. Proceso de Recuperacin Unificado 21

Siguiendo el proceso que plantea Panas et. al. 21, presentamos los resultados
ms relevantes de cada una de las herramientas que se utilizaron para este
proyecto. En el proceso se plantea una representacin a nivel de clase esta se
puede obtener de la herramienta iPlasma y de la plataforma Moose.
iPlasma no muestra como primer resultado una pirmide de resumen del sistema,
ver figura 9, esta nos muestra una recopilacin de mtricas acerca del sistema en
general, donde se muestran indicadores para observar si estas estn o no en el
rango de la industria.

18

Figura 9. Pirmide de Resumen

Tambin nos muestra una vista llamada Resumen de la complejidad del

sistema, ver figura 10, esta vista nos permite ver la totalidad de las clases del
sistema junto con sus relaciones de herencia, adems de incluir en la
representacin de cada clase tres mtricas que representan el nmero de
atributos, nmero de mtodos y nmero de lneas de cdigo.

Figura 10. Resumen de la complejidad del sistema

19

La figura 11 muestra cmo se representan las mtricas nmero de atributos,

nmero de mtodos y nmero de lneas de cdigo.

Figura 11. Representacin mtrica

Moose tambin nos entrega un resultado con la mismas caractersticas del

obtenido por iPlasma, solo que este no representa la mtrica nmero de lneas de
cdigo, en la figura 12 se muestra una vista parcial de la vista de complejidad del
sistema donde se refleja que no se representa la mtrica nmero de lneas de
cdigo.

Figura 12. Vista parcial complejidad sistema en Moose

Cuando ya hemos obtenido la representacin a nivel de clases del sistema

procedemos realizar la representacin a nivel de arquitectura, esta se puede
obtener a partir de la herramienta Softwarenaut y la plataforma Moose.
Softwarenaut nos provee de una vista general del sistema donde se representan
los mdulos del sistema y las relaciones que hay entre estos, adems inserta unas
mtricas donde el tamao de cada mdulo es proporcional a su tamao real en
lneas de cdigo y la anchura de cada relacin es proporcional al nmero de
20

invocaciones entre los mdulos correspondientes, adems de representar los

mdulos que contiene un mdulo, ver figura 13.

Figura 13. Vista de mdulos en Softwarenaut

Moose nos permite ver los paquetes del sistema como un rbol, el cual nos
proporciona una vista muy general del sistema, esta vista es de mucha utilidad ya
que nos permite ubicarnos cuando los sistemas son tan grandes, en la figura 14 se
puede
el
rbol
correspondiente
al
sistema
ArgoUml.

21

Figura 14.Paquetes de ArgoUml

El proceso que estamos siguiendo hace referencia que se debe hacer un anlisis
de la arquitectura y se debe mostrar en un nivel de detalle ms alto de los
componentes del sistema. IPlasma nos permite ver los componentes del sistema
partiendo desde una vista de la complejidad de cada uno de los paquetes del
sistema hasta una representacin de cada clase donde podemos ver cules son
los mtodos, funciones y atributos que esta tiene.
En la figura 15 podemos ver la vista de complejidad del paquete uml del sistema,
esta vita tiene la misma representacin que la vista de resumen de la complejidad
del sistema completo, pero solo nos concentramos en cada uno de los paquete.

Figura 15. Complejidad del paquete uml

Mirando el resultado arrojado podemos ver que una de las clases que contiene
este paquete presenta un alto grado de complejidad, en la herramienta se
identifica que es la clase FigNodeModelElement, es bueno hacer representacin
ms detallada de las clases que presentan este comportamiento, en la figura 16 se
puede ver la representacin de esta clase .

Figura 16. Class BluePrint FigNodeModelElement

Softwarenaut tambin nos ayuda hacer una representacin de paquetes por los
cuales podemos navegar por ellos, en la figura 17 podemos observar la
visualizacin del paquete uml. Esta herramienta nos permite tener una
visualizacin a nivel clase pero si nos ayuda en el anlisis de estas dndonos una
serie de datos correspondientes a las clases como se pude ver en la figura 18,
donde vemos los datos que pertenecen a la clase FigNodeModelElement.

Figura 17. Representacin de paquetes de uml

24

Figura 18. Clase FigNodeModelElement en Softwarenaut

25

Moose nos posibilita hacer visualizaciones a nivel de paquetes, donde podemos

observar todas las clases que contiene este paquete y sus subpaquetes y la
relaciones que entre ellas, en la figura 19 se puede observar una vista parcial del
resultado arrojado por la plataforma.

Figura 19. Complejidad del paquete uml en Softwarenaut

A nivel de clase Moose posibilita la visualizacin de estas. En la figura 20 se

observa el ClassBlueprint de la clase FigNodeModelElement. Adems permite la
visualizacin de las clases individualmente en un diagrama UML aunque no
permite exportar este.

Figura 20.Class BluePrint de FigNodeModelElement en Moose

Por ultimo Moose tiene una opcin la cual permite generar una vista la cual nos
muestra las dependencias de los paquetes del sistema y los organiza por capas
de tal manera que los paquetes cliente de un paquete se ubican en una capa
inferior, en la figura 21 se puede ver esta vista para el sistema que estamos
evaluando.

26

Figura 21. Dependencias de paquetes en Moose

5. ANALISIS DE RESULTADOS

El proceso que se sigue en este trabajo indica que se debe hacer anlisis de los
programas, el filtrado y la visualizacin del programa, con los resultados
presentados en la seccin anterior podemos verificar que se cumple en su
mayora con lo propuesto en el proceso de recuperacin de arquitecturas
propuesto por Pana et. al. 21, donde apoyndonos de las herramientas que se
usaron en el trabajo se puede realizar un anlisis del sistema, aunque es a un bajo
nivel ya que solo se pueden sacar mtricas correspondientes a las caractersticas
de los componentes de sistema y no se realiza ninguna recomendacin sobre
como corregir las mtricas que presentan valores crticos. Las herramientas y la
plataforma que usamos nos permiten hacer una exploracin del sistema donde no
podemos concentrar en cada una de las partes del sistema con el que estamos
trabajando y por ltimo se realiza la visualizacin del sistema donde se generan
vistas que son que muestran comportamientos del sistema y sus componentes
adems de sacar la informacin correspondiente a sus mtricas.
Podemos decir que el proceso de recuperacin de arquitecturas se ha logrado
realizar con cierto grado de cumplimiento, pero ahora debemos ver si los
resultados obtenidos de este proceso pueden ser de utilidad para realizar la
documentacin de un sistema software, para esto Clements et. al. Presentan un
mtodo practico para la documentacin de la arquitectura, donde debemos
identificar a quien o quienes va dirigida la documentacin de la arquitectura y que
deseamos documentar de la arquitectura del sistema y luego relacionar esta
decisiones con una tabla que presentan, ver figura 22 para poder identificar que
estilos de vistas son las ms apropiadas para poder cumplir con el objetivo de la
documentacin.
Esta documentacin se realiza con el objetivo de apoyar actividades de evolucin
y mantenimiento de un sistema, por lo que est dirigida para arquitectos y equipos
de mantencin, y lo que se pretende documentar es la estructura del sistema a
nivel de mdulos, entonces si relacionamos estas decisiones que se toman con la
figura 21 podemos decir que las vistas que ms apoyan a estos son: la vista de
descomposicin, la vista de generalizacin, la vista de uso y la vista de capas.

Figura 22. Que vistas son tiles para los interesados 22

En la tabla 3 podemos relacionar los resultado obtenidos por las herramientas y la

plataforma con las vistas de descomposicin, generalizacin y uso.

Dependencia de
paquetes

Paquetes

Moose
complejidad
sistema

Vista de Clase

Vista de mdulos

Piramide de
Resumen

Softwarenaut

ClassBlueprint

Descomposicin
Generalizacin
Uso

ClassBlueprint

Resumen de la
complejidad del
sistema

iPlasma

x
x

x
Tabla 3. Relacin Resultados con Vistas

La pirmide de Resumen y la Vista de Clase no se relacionan con ninguna de las

vistas que queremos observar, pero se mantienen dentro de la documentacin del
sistema ya que se consideran que ofrecen informacin importante del sistema
para su anlisis.

29

CONCLUSIONES
La actividad de recuperacin de la arquitectura de un sistema software es
compleja y lleva mucho tiempo, por esto es necesario apoyarse de las
herramientas para que esta no consuma mucho tiempo, adems de hacer la
recuperacin de la arquitectura es necesario que la arquitectura se comprensible
para muchos interesados, los cuales tienen diferentes intereses, por los que esta
actividad debe ser tambin planificada para que los resultados que se obtengan
sean realmente relevantes.
El anlisis esttico de sistema provee de informacin que es importante y puede
que puede ser usada para actividades de mantenibilidad, evolucin y reutilizacin
del software, pero tambin es necesario que se haga un anlisis dinmico del
sistema y combinar los do resultados para que haya un aporte mucho mejor en
estas actividades.
Las herramientas de ingeniera inversa ayudan en la recuperacin de los sistemas
software, pero se debe hacer un anlisis de estas para que realmente apoyen a la
actividad de recuperar la arquitectura de un sistema, y no aumenten el tiempo de
trabajo del arquitecto.
La recuperacin de la arquitectura de un sistema no est hecha con la finalidad de
generar un documento esttico donde todos lo interesado puedan ver lo que para
ellos es importante, el resultado de esta actividad debe ser un mecanismo de
comunicacin que realmente aporte a las personas interesadas en el sistema,
donde sea posible navegar por la arquitectura del sistema.
El mecanismo de navegacin por la arquitectura de un sistema permite al usuario
concentrarse en las partes realmente importantes del sistema, ya que ver la
arquitectura a un nivel muy general puede producir mucho ruido en el anlisis del
sistema.

30

BIBLIOGRAFA
1. L. Bass, P. Clements, R. Kazman, "Software Architecture in Practice",
Second Edition, ISBN: 0-321-15495-9, Addison-Wesley, 2003
2. Bengtsson, P.O.; Bosch, J., "Scenario-based software architecture
reengineering," Software Reuse, 1998. Proceedings. Fifth International
Conference on , vol., no., pp.308,317, 2-5 Jun 1998
3. I. Hogganvik, E. Molstad, and S. Fordypningsemne, "INCO- open source
architecture recovery," 2002.
4. M. Lungu, M. Lanza, and O. Nierstrasz, "Evolutionary and collaborative
software architecture recovery with Softwarenaut," Science of Computer
Programming, vol. 79, pp. 204-223, 2014.
5. Tran, J.B.; Godfrey, M.W.; Lee, E.H.S.; Holt, R.C., "Architectural repair of
open source software," Program Comprehension, 2000. Proceedings. IWPC
2000. 8th International Workshop on , vol., no., pp.48,59, 2000.
6. Maqbool, O.; Babri, H.A., "Hierarchical Clustering for Software Architecture
Recovery," Software Engineering, IEEE Transactions on , vol.33, no.11,
pp.759,780, Nov. 2007
7. C.-h. Lung, "Software architecture recovery and restructuring through
clustering techniques," in In Proceedings of the Third International
Workshop on Software Architecture, 1998, pp. 101-104.
8. Camacho, M.C.; Alegria, J.A.H., "Analizing the viability for adopting the
software process line approach in small entities," Computing Congress
(CCC), 2012 7th Colombian , vol., no., pp.1,6, 1-5 Oct. 2012
9. C. Schmidt. Why software reuse has failed and how to make it work for you.
C++ Report, Enero 1999.
10. Perovich, D.; Bastarrica, M.C., "Model-Based Formalization of Software
Architecture Knowledge," Software Architecture (WICSA), 2014 IEEE/IFIP
Conference on , vol., no., pp.235,238, 7-11 April 2014

31

11. Tran, J.B.; Godfrey, M.W.; Lee, E.H.S.; Holt, R.C., "Architectural repair of
open source software," Program Comprehension, 2000. Proceedings. IWPC
2000. 8th International Workshop on , vol., no., pp.48,59, 2000.
12. Ramirez,
A
et.
al.,
"ArgoUML:
Manual
de
Usuario",
http://www.di.ubi.pt/~cbarrico/Disciplinas/EngenhariaSoftware/Downloads/Ar
goUML_Manual.pdf
13. http://argouml.tigris.org/
14. Marinescu, C.; Marinescu, R.; Mihancea, P.; Ratiu, D.; Wettel, R.; "iPlasma:
An Integrated Platform for Quality Assessment of Object-Oriented Design".
In Proceedings of the 21st IEEE International Conference on Software
Maintenance (ICSM 2005), p. 77-80, 2005.
15. Ratiu, D.: Memoria: A Unified Meta-Model for Java and C++ (2004)
16. M. Lanza, R. Marinescu, and S. Ducasse, Object-Oriented Metrics in
Practice. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2005.
17. M. Lanza and S. Ducasse, "Polymetric views-a lightweight visual approach
to reverse engineering," Software Engineering, IEEE Transactions on, vol.
29, pp. 782-795, 2003.
18. S. Tichelaar, "Modeling object-oriented software for reverse engineering and
refactoring," PhD thesis, University of Berne, 2001.
19. http://www.moosetechnology.org/
20. M. Lungu, M. Lanza, and O. Nierstrasz, "Evolutionary and collaborative
software architecture recovery with Softwarenaut," Science of Computer
Programming, vol. 79, pp. 204-223, 2014.
21. Panas, Lwe, Asmann. Towards the unified recovery architecture for
reverse engineering. Proc. of the Intern. Conf. on Software Engineering and
Practice SERP03, volume 1, pages 854860, Las Vegas, NV, June 2003.
CSREA Press.

32

22. P. C. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R.

Nord, and J. Stafford, A practical method for documenting software
architectures, 2002.

33