A. Integration of Sequence Knowledge
1. Model Formulation
Una tarea que consumi´o una parte importante del tiempo dedicado a la imple- mentaci´on de este m´odulo, fue la integraci´on de las distintas versiones existentes. Si bien esta tarea no era imprescindible para que la interfaz de gesti´on cumpliese sus funciones, se consider´o de orden presentar en la soluci´on final una versi´on que incluyera las funcionalidades aportadas por el grupo Multicast mencionado en la secci´on 10.2 de este cap´ıtulo. De esta manera se piensa que se est´a haciendo un aporte importante para que futuros trabajos sobre el mismo software conduzcan a una soluci´on mejor y no varias que ataquen distintos aspectos de esta tem´atica.
Una imagen de la ventana principal del software, luego de las inclusiones men- cionadas previamente en este cap´ıtulo, puede verse en la figura 10.4
El software provee otras funcionalidades que pueden consultarse en [45] y no son descritas en esta secci´on por no ser parte de la soluci´on implementada por este proyecto.
10.4.
Conclusiones
En este cap´ıtulo se present´o el software utilizado para cumplir las funciones de interfaz de gesti´on de la herramienta en l´ınea. Se comentaron las distintas posibili- dades que ´esta brinda, haciendo especial ´enfasis en aquellos aspectos desarrollados por el presente proyecto.
La interfaz de gesti´on con la que cuenta la herramienta permite que el usuario o administrador pueda tener una imagen del estado de la red bajo estudio y pueda configurar o dar de baja LSPs de manera sencilla. Tambi´en permite combinar he- rramientas de c´alculo fuera de l´ınea sobre la red bajo estudio, para simular distintos casos de ampliaci´on o de cambios en el tr´afico sobre la misma.
10.4. Conclusiones 107
Figura 10.4: Interfaz gr´afica del software Net-TE.
El hecho de contar con una implementaci´on ya muy avanzada de la parte gr´afica y con una arquitectura modular con su mecanismo de comunicaci´on definido, hizo que la adaptaci´on del software Net-TE, para integrar la herramienta en l´ınea, fuera posible. Esto permite concluir que la elecci´on de la arquitectura fue exitosa en lo que a versatilidad refiere.
Cap´ıtulo 11
Ingenier´ıa de Software
11.1.
Introducci´on
En este cap´ıtulo se muestran resultados sobre los aspectos de an´alisis y de dise˜no
que se contemplaron durante el desarrollo del software descrito en los cap´ıtulos anteriores.
Se decidi´o implementar como m´odulos de software independientes a los distintos m´odulos de la arquitectura elegida, cuyo detalle se coment´o en el cap´ıtulo 4. Pre-
valeci´o en todo momento como criterio de dise˜no el preservar la independencia de
los m´odulos, por lo que se ver´a que cada m´odulo resuelve lo que le compete y se comunica con el resto de los m´odulos de la manera descrita en el cap´ıtulo 4.
A continuaci´on se describen las componentes de software de cada uno de los m´odulos.
11.2.
An´alisis y dise˜no
11.2.1. M´odulo Topolog´ıa
A. Casos de Uso
Para este m´odulo se identific´o como ´unico caso de uso levantar la topolog´ıa f´ısica de una red. Se identificaron como actores: la red, el administrador de la red y la base de datos. A continuaci´on se describe el caso de uso. El diagrama del mismo se muestra en la figura 11.1.
Caso de uso: Descubrir la topolog´ıa f´ısica de una red El administrador desea que se conozca la topolog´ıa f´ısica de la red bajo estudio. Para ello ejecuta la operaci´on de descubrir la topolog´ıa en el sistema proveyendo los datos requeridos por el mis- mo: community SNMP, direcci´on IP de un nodo de la red y opcionalmente, otros par´ametros del protocolo SNMP (por ejemplo tiempo de expiraci´on, reintentos). El sistema realiza las consultas a la red utilizando el protocolo SNMP, comenzando por
el nodo cuya identidad se conoce e iterativamente completa la informaci´on buscada; los nodos y enlaces presentes en la red, direcciones IP, nombres y velocidades nomi- nales de las interfaces. El sistema persiste la informaci´on recolectada en la base de datos.
No se incluye en esta secci´on una descripci´on en formato completo del caso de uso para permitir una lectura m´as ´agil de la misma. No obstante, los escenarios alternativos se har´an evidentes m´as adelante en esta secci´on.
Figura 11.1: Diagrama de casos de uso. M´odulo Topolog´ıa.
B. Modelo Conceptual
El modelo conceptual de este m´odulo se puede ver en la figura 11.2.
C. Diagrama de secuencia
El diagrama de secuencia de este m´odulo se puede ver en la figura 11.3.
D. Diagrama de paquetes
El proceso de dise˜no llev´o, luego de varias iteraciones, al diagrama de paquetes
que se muestra en la figura 11.4. Se puede advertir que se han omitido detalles en la documentaci´on de las etapas de an´alisis con el fin de simplificar sus gr´aficos.
11.2. An´alisis y dise˜no 111
Figura 11.2: Modelo conceptual. M´odulo Topolog´ıa.
11.2. An´alisis y dise˜no 113
11.2.2. M´odulo Monitorizaci´on
A. Casos de Uso
Para el m´odulo de monitorizaci´on el an´alisis del problema llev´o a la detecci´on de un caso de uso complejo. Este caso de uso se descompuso en otros debido a su complejidad y a la posibilidad de que se quieran ejecutar los casos de uso por separado. Se identificaron como actores: la red, el administrador de la red y la base de datos. A continuaci´on se describen los mismos en formato breve. El diagrama de casos de uso se puede observar en la figura 11.5.
Caso de uso: Monitorizar la red El administrador desea que se tenga disponible infor- maci´on din´amica de la red, esta informaci´on refiere a los LSPs establecidos en la misma y a par´ametros de performance de la red. El administrador ejecuta la opera- ci´on monitorizar red, el sistema consulta a la base de datos la red f´ısica disponible y ´esta se la devuelve. Luego se ejecutan los casos de uso Descubrir topolog´ıa virtual de la red y Recolectar par´ametros de performance de la red. El sistema env´ıa a la base de datos la nueva informaci´on obtenida.
Caso de uso: Descubrir la topolog´ıa virtual de la red El sistema comienza a consultar a cada uno de los nodos de la red, utilizando el protocolo SNMP, informaci´on dis- ponible en la MPLS-TE-MIB. La red devuelve esta informaci´on al sistema, ´este la procesa y almacena la informaci´on de los LSPs descubiertos.
Caso de uso: Obtener par´ametros de performance de la red El sistema consulta a cada nodo de la red, utilizando el protocolo SNMP, par´ametros de performance disponi- bles en la MIB-II y en la MPLS-TE-MIB. Cada nodo que es consultado devuelve esta informaci´on. El sistema retiene internamente esta informaci´on. El sistema procede a obtener par´ametros de performance de extremo a extremo para lo que establece una conexi´on mediante TELNET con cada nodo. Se consulta mediante TELNET el retardo de cada LSP. El sistema almacena internamente esta informaci´on.
B. Modelo conceptual
El modelo conceptual del m´odulo monitorizaci´on puede verse en la figura 11.6.
C. Diagrama de Interacci´on
Para este m´odulo se presenta el diagrama de secuencia separado en tres dia-
gramas ya que la complejidad de su ´unica operaci´on as´ı lo amerita. En la figura
11.7 se muestra la secuencia sin desarrollar. En la figura 11.8 se muestra el detalle
del manejo de los hilos. Por ´ultimo, en la figura 11.9 se muestra el detalle de cada
hilo de ejecuci´on. La secuencia correspondiente a la recolecci´on de par´ametros de performance no se incluye paso por paso para no abrumar al lector.
Figura 11.5: Diagrama de casos de uso. M´odulo Monitorizaci´on.
Figura 11.6: Modelo conceptual. M´odulo Monitorizaci´on.
D. Diagrama de paquetes
11.2. An´alisis y dise˜no 115
Figura 11.7: Diagrama de interacci´on general. M´odulo Monitorizaci´on.
11.2. An´alisis y dise˜no 117
11.2.3. M´odulo TE
A. Casos de Uso
En este m´odulo se detect´o el caso de uso evitar congesti´on, que fue descompuesto en dos casos de uso: detectar congesti´on y correr algoritmo correctivo. Se identifica- ron como actores, el administrador de la red, la red, la base de datos y el m´odulo
se˜nalizaci´on. A continuaci´on se describen los casos de uso.
Caso de uso: Evitar congesti´on El administrador de la red desea evitar situaciones de congesti´on de la red, y en caso de que existan corregirlas. Para ello ejecuta la operaci´on del sistema realizar Ingenier´ıa de Tr´afico. El sistema procede a ejecutar el caso de uso detectar congesti´on.
Caso de uso: Detectar congesti´on El sistema pide a la base de datos informaci´on so- bre la red f´ısica, los LSPs sobre ella establecidos y estad´ısticas sobre los datos de performance asociados a ella. El sistema arma los grupos de LSPSs entre los que se balancea carga, y procede a analizar los par´ametros de retardo en cada uno de los LSPs que componen los grupos. Calcula la diferencia entre la derivada del retardo respecto a la carga, m´axima y m´ınima en cada grupo, y si esto supera un cierto umbral marca al grupo como posible grupo desbalanceado. El sistema pide a la base de datos nuevamente la red, con nuevos par´ametros de performance, y actualiza la
informaci´on de cada grupo. En caso de detectar nuevamente desbalanceo en alg´un
grupo, considera que estos est´an desbalanceados. El sistema ejecuta el caso de uso correr algoritmo correctivo para los grupos desbalanceados, marca los mismos como
en proceso de correcci´on y vuelve a cero el resto de los grupos. El sistema contin´ua
realizando este proceso, consultando si el algoritmo termin´o o no en aquellos casos en que se est´a en fase de correcci´on.
Caso de uso: Correr algoritmo correctivo El sistema ejecuta el algoritmo MATE pa- sando como par´ametros los LSPs desbalanceados. El sistema procede a realizar las iteraciones correspondientes. Al fin de cada iteraci´on indica, utilizando el protocolo
de comunicaci´on GRMAP y el formato XML, al M´odulo Se˜nalizaci´on que haga los
cambios correspondientes en cada LSP. Al comienzo de cada iteraci´on el sistema pide una nueva red a la base de datos hasta constatar que los cambios efectivamente se hayan configurado en la red. Prosiguen estos pasos de pedido de red, iteraci´on,
y se˜nalizaci´on hasta que converge el algoritmo y el sistema considera balanceado el
grupo y no hace m´as nada con ´el.
B. Modelo Conceptual
11.2. An´alisis y dise˜no 119
Figura 11.11: Diagrama de Casos de Uso. M´odulo TE.
Figura 11.12: Modelo conceptual. M´odulo TE.
C. Diagrama de Interacci´on
El diagrama de interacci´on de este m´odulo puede verse en la figura 11.13. En el mismo se hace ´enfasis en el la secuencia de detecci´on. La secuencia de correcci´on no se adjunta en este cap´ıtulo ya que si bien fue una etapa necesaria de la ingenier´ıa de software el procedimiento fue claramente explicado en otros cap´ıtulos.
Figura 11.13: Diagrama de interacci´on. M´odulo TE. Detecci´on de Congesti´on.
D. Diagrama de paquetes
11.2. An´alisis y dise˜no 121
11.2.4. Otros M´odulos
Como se pudo ver en las distintas secciones de este cap´ıtulo hay elementos que son comunes a la gran mayor´ıa de los m´odulos. Es por eso que se decidi´o implementar un m´odulo que lleva el nombre de comunes y contiene todos los elementos de software que son comunes a los distintos m´odulos.
El m´odulo comunes consta de las clases necesarias para implementar: El protocolo de comunicaci´on (GRMAP)
La comunicaci´on con la base de datos
Generar e interpretar las cadenas de caracteres del XML Los elementos que modelan la topolog´ıa de una red
La comunicaci´on mediante SNMP con los nodos de la red real El manejo de los archivos de configuraci´on
Las excepciones de todo el software Funcionalidades de prop´osito general
En la figura 11.2.4 se puede observar algunos de los paquetes contenidos en este m´odulo.
11.3.
Implementaci´on
Para la implementaci´on del software se decidi´o utilizar el lenguaje orientado a objetos JAVA, debido a su gran versatilidad. Este lenguaje presenta numerosas ven- tajas entre las que se destacan que es independiente del fabricante y que, debido a
su popularidad, existen muchas bibliotecas p´ublicas que permiten ahorrar tiempo
en la implementaci´on de las funciones auxiliares. Tambi´en se tuvo en cuenta para su elecci´on que ya se contaba con experiencia en el mismo para el desarrollo de aplica- ciones, lo que permiti´o ahorrar el estudio de un nuevo lenguaje. Se eligi´o utilizar la versi´on 1.5 debido a que algunas de las bibliotecas utilizadas as´ı lo requer´ıan.
Los m´odulos fueron implementados como aplicaciones independientes, lo que permite que corran en distintos equipos. De todas maneras, como se coment´o ante- riormente en este cap´ıtulo, se agruparon todas las funcionalidades comunes en un package que es utilizado por todos los m´odulos. Esto por un lado, permite la reu- tilizaci´on del c´odigo, y por otro facilita su mantenimiento. Por ejemplo, en caso de que se realicen modificaciones en el protocolo GRMAP, s´olo debe modificarse dicho package.
Para los casos en que se quieren ejecutar diversas funciones simult´aneamente en un mismo m´odulo, se utilizaron hilos o threads. Los mismos permiten correr
11.4. Despliegue 123
varios procesos simult´aneamente en la misma m´aquina virtual. Son utilizados, por ejemplo, al realizar el descubrimiento de los LSPs para consultar todos los nodos simult´aneamente y acelerar el proceso.
Se tuvo especial cuidado en la elecci´on de los tipos utilizados para almacenar informaci´on. En particular, se estudi´o en cada caso cu´al era el contenedor m´as apro- piado desde el punto de vista de la velocidad de acceso. El objetivo de esto es lograr la mayor rapidez en el acceso a los datos dado que la herramienta tiene fuertes re- querimientos de tiempos. Algunas de las clases creadas para almacenar informaci´on pueden verse en la figura 11.15(e).
La utilizaci´on de bibliotecas externas hizo que se simplificara sensiblemente el desarrollo de muchas de las funcionalidades del package comunes. En particular, se utilizaron las bibliotecas ADVENTNET SNMP API para el manejo del protocolo SNMP, y JDOM para el manejo del formato XML.
Como conclusi´on general se puede decir que la elecci´on del lenguaje fue acer- tada. Se lograron implementar todas las funcionalidades buscadas y a su vez se logr´o reutilizar una gran cantidad de clases lo que permiti´o ahorrar mucho tiempo de implementaci´on.
11.4.
Despliegue
El objetivo de esta secci´on es mostrar c´omo se deben utilizar los distintos m´odulos y dejar en claro las dependencias reales entre ellos.
En la figura 11.16 se puede ver un diagrama de despliegue. En ´el se indican los nodos locales, nodos intermedios y nodos remotos. Los nodos locales refieren a aquellos equipos que deben encontrarse en la misma red a controlar. Por otro lado, los nodos remotos son equipos que pueden encontrarse en cualquier sitio, teniendo ´
unicamente que cumplir con la restricci´on de tener conectividad con el equipo donde
se encuentre la base de datos. Por ´ultimo, se hace referencia a nodos intermedios
(a) Modelado de la topolog´ıa
(b) Manejo de conexiones SNMP (c) Manejo de XML
(d) Manejo de Conexiones (e) Contenedores y Utilidades
11.4. Despliegue 125
Parte III
Cap´ıtulo 12
Validaci´on
12.1.
Introducci´on
En este cap´ıtulo se repasan los criterios de ´exito del proyecto, se describen las pruebas realizadas para la validaci´on, se analizan los resultados y se presentan las conclusiones correspondientes.
El objetivo principal de las pruebas fue la validaci´on de la herramienta bas´andose en los criterios de ´exito. No obstante, se busc´o tambi´en validar la soluci´on implemen- tada frente a criterios generales, buenas pr´acticas en el desarrollo de herramientas de este tipo y comparaci´on con soluciones similares.