Desarrollo De Un Algoritmo Para La Configuración De Dos Tecnologías De Routers Utilizando Mda

Texto completo

(1)DESARROLLO DE UN ALGORITMO PARA LA CONFIGURACIÓN DE DOS TECNOLOGÍAS DE ROUTERS UTILIZANDO MDA. CARLOS JOHANY SIERRA GUZMÁN DAVID RICARDO RAMÍREZ BUITRAGO. UNIVERSIDAD FRANCISCO JÓSE DE CALDAS FACULTAD TECNOLÓGICA INGENIERIA EN TELECOMUNICACIONES BOGOTA 2016.

(2) DESARROLLO DE UN ALGORITMO PARA LA CONFIGURACIÓN DE DOS TECNOLOGÍAS DE ROUTERS UTILIZANDO MDA. CARLOS JOHANY SIERRA GUZMÁN DAVID RICARDO RAMÍREZ BUITRAGO. Trabajo de tesis para optar por el título de Ingeniero en Telecomunicaciones. GUSTAVO ADOLFO HIGUERA CASTRO INGENIERO EN TELECOMUNICACIONES DIRECTOR DE TESIS. UNIVERSIDAD FRANCISCO JÓSE DE CALDAS FACULTAD TECNOLÓGICA INGENIERIA EN TELECOMUNICACIONES BOGOTA 2016.

(3) Nota de Aceptación. Director de Tesis: Ing. Gustavo Adolfo Higuera Castro. Jurado: Ing. Edward Jacinto Gómez. Bogotá DC, 05 de Mayo de 2016. 3.

(4) Dedicatoria A Dios, a nuestras familias y a nuestro director de tesis.. AGRADECIMIENTOS. Agradecemos a nuestro director del trabajo de grado el Ingeniero Gustavo Adolfo Higuera Castro por brindarnos su conocimiento y ayuda para el desarrollo de este proyecto además de su esfuerzo y dedicación en las correcciones del mismo. A nuestras familias por proporcionarnos la mejor educación posible y lecciones de vida, en especial a nuestros padres que nos brindaron todas las herramientas y valores para abordar la vida Al cuerpo docente que nos brindaron el conocimiento que nos permitió mirar de diferentes maneras el mundo y a nuestros compañeros de academia por compartir grandes momentos y estar presentes en todos los momentos de esta etapa.. 4.

(5) CONTENIDO. Pág 1. INTRODUCCIÓN ............................................................................................... 14 2. OBJETIVOS ....................................................................................................... 15 2.1 OBJETIVO GENERAL ..................................................................................... 15 2.1.2 OBJETIVOS ESPECÍFICOS ......................................................................... 15 3. PLANTEAMIENTO DEL PROBLEMA ................................................................ 16 3.1 DEFINICIÓN DEL PROBLEMA ...................................................................... 16 3.2 JUSTIFICACIÓN .............................................................................................. 16 4. MARCO TEÓRICO ............................................................................................ 17 4.1 MODELO ........................................................................................................ 17 4.1.1 INGENIERÍA DIRIGIDA POR MODELOS ..................................................... 17 4.1.2 ARQUITECTURA DIRIGIDA POR MODELOS ............................................. 19 4.1.3 TRANSFORMACION DE MODELOS ........................................................... 24 4.1.4 TRANSFORMACIÓN DE MODELO A MODELO .......................................... 24 4.1.5 TRANSFORMACIÓN DE MODELO A TEXTO ............................................. 24 4.1.6 DIAGRAMA DE USOS .................................................................................. 25 4.1.7 DIAGRAMA DE SECUENCIA ....................................................................... 26 4.1.8 DIAGRAMA DE CLASES .............................................................................. 27 4.2 PROTOCOLOS................................................................................................ 28 4.2.1 Configuración de Host Dinámico (DINAMIC HOST CONFIGURE PROTOCOL DHCP) .............................................................................................. 29 4.3 ROUTER .......................................................................................................... 33 4.3.1 ROUTER CISCO E-SERIES ......................................................................... 35 4.3.2 ROUTER CISCO 1941.................................................................................. 36 4.3.3 MIKROTIK ROUTERBOARD 750GL ............................................................ 36 5. METODOLOGÍA ................................................................................................ 37. 5.

(6) 6. DESARROLLO DEL PROYECTO ..................................................................... 38 6.1 EVALUACIÓN DE TECNOLOGÍAS: ................................................................ 38 6.2 DESARROLLO DEL ALGORITMO PARA LA CONFIGURACIÓN DE DOS ROUTERS DE DIFERENTES TECNOLOGÍAS ..................................................... 40 6.3 DESARROLLO DE UN MODELO UML PARA EL ALGORITMO PARA LA CONFIGURACIÓN DE DOS DIFERENTES ROUTERS. ....................................... 43 6.3.1 DIAGRAMA DE CASOS DE USOS Y VISUALIZACIÓN DE LA INTERFAZ DE USUARIO......................................................................................................... 43 6.3.2 DIAGRAMA DE CLASES .............................................................................. 47 6.3.3 DIAGRAMA DE SECUENCIA ....................................................................... 49 6.3.4 SELECCIÓN DE LENGUAJES DE PROGRAMACIÓN ................................ 54 6.4 DISEÑO DE LA TOPOLOGÍA DE RED IMPLEMENTADA PARA LA REALIZACIÓN DE PRUEBAS ............................................................................... 56 6.5 USO Y CONSIDERACIONES PREVIAS PARA IMPLEMENTACIÓN DEL APLICATIVO DESARROLLADO ........................................................................... 59 6.6 PRUEBAS DE IMPLEMETACION DEL MODELO ........................................... 60 7 CONCLUSIONES ............................................................................................... 66 8 BIBLIOGRAFÍA ................................................................................................... 66. 6.

(7) LISTA DE TABLAS Pág. Tabla 1: Resultados de la encuesta con relación a la forma estándar de programar ............................................................................................................................... 64 Tabla 2: Comparación entre diferentes sistemas operativos de los Routers ......... 65. 7.

(8) LISTA DE FIGURAS Pág Figura 1: Cambios en los lenguajes de programación a través del tiempo ............ 18 Figura 2: Esquema de MDA. .................................................................................. 19 Figura 3: Método Tradicional del desarrollo de software ....................................... 21 Figura 4: Desarrollo de software por MDA. ............................................................ 22 Figura 5: Representación de IBM para MDA ......................................................... 23 Figura 6: Componentes de un Lenguaje de modelado .......................................... 25 Figura 7: Formato de mensaje de DHCPV4 .......................................................... 31 Figura 8: Imagen de metodología a desarrollar ..................................................... 37 Figura 9: Imagen de Router Cisco 1941 ................................................................ 39 Figura 10: Imagen de Router Linksys e900 ........................................................... 39 Figura 11. RouterBoard 750GL .............................................................................. 40 Figura 12, Algoritmo para configuración de router ................................................. 42 Figura 13. Diagrama de Casos de uso .................................................................. 44 Figura 14. Diseño de interfaz de usuario 1. ........................................................... 45 Figura 15. Diseño de interfaz de usuario 2 ............................................................ 45 Figura 16. Caso de uso finalizado.......................................................................... 46 Figura 17. Diagrama de Clases ............................................................................. 48 Figura 18. Diagrama de secuencia, Inicio de Aplicación ........................................ 50 Figura 19. Diagrama de secuencia, Conexión con el Router ................................. 51 Figura 20. Diagrama de secuencia, Cargando Configuración del Router .............. 52 Figura 21. Diagrama de secuencia, Barrado de Configuración del Router ............ 53 Figura 22. Interfaz gráfica desarrollada en Java .................................................... 55 Figura 23. Interfaz gráfica desarrollada en Python ................................................ 55 Figura 24: Esquema de la topología. ..................................................................... 57 Figura 24: Algoritmo de configuración de Router ................................................... 58 Figura 25, Archivos para configurar computadora. ................................................ 59 Figura 26, Configuración de dirección estática ...................................................... 60. 8.

(9) Figura 27, Configuración de DHCP........................................................................ 60 LISTA DE GRÁFICOS Pág Gráfico 1: Resultados de la pregunta número 1..................................................... 61 Gráfico 2: Resultados de la pregunta número 2..................................................... 62 Gráfico 3: Resultados de la pregunta número 3..................................................... 62 Gráfico 4: Resultados de la pregunta número 4..................................................... 63 Gráfico 5: Resultados de la pregunta número 5..................................................... 63. 9.

(10) LISTA DE ANEXOS. Pág ANEXO A, Código Fuente en Java ........................................................................ 68 ANEXO B, Código fuente en Python...................................................................... 80 ANEXO C, Código Fuente Consola Windows ........................................................ 92. 10.

(11) GLOSARIO. CIM: Descripción de la lógica del negocio, perspectiva independiente de la programación. DHCP: Dynamic Host Configuration Protocol, es un protocolo para asignar IP de forma dinámica dentro de un rango de direcciones. DNS: Domain Name Server, ofrece acceso a sitios web para usuarios que usan nombres de domino. ENRUTAMIENTO: Es el proceso de envío de paquetes entre diferentes redes buscando la ruta más óptima. ISM: Descripción a nivel de código en un lenguaje específico. M2M: Trasformación de modelo a modelo. M2T: Transformación de modelo a texto. MD5: Es un algoritmo de reducción criptográfica de 128 bits. MDA: Arquitectura dirigida por modelos. MDE: Ingeniería dirigida por modelos. MOF: Meta Object Facility y es un estándar de OMG. NTP: Network Time Protocol el cual obtiene la hora por medio de un servidor ubicado en la red. OCL: Object Constraint Language, es un lenguaje para la descripción formal de expresiones en los modelos UML. OMG: Object Management Group. PIM: Descripción de la funcionalidad del sistema en forma independiente de las características de plataformas de implementación específica. PSM: Es el modelo especifico de la plataforma en UML. QVT: Transformación de vistas por preguntas. SMTP: Simple Mail Transfer Protocol para transportar un email en una red. SSH: Protocolo de transporte de datos con encriptación MD5.. 11.

(12) TFTP: Protocolo de transferencia de archivos de cliente y servidor que usa la capa de transporte. UML: Lenguaje unificado de modelado el cual es un estándar a nivel internacional. XML: Intercambio de metadatos del lenguaje permitiendo que diversas herramientas se integren al serializar modelos.. 12.

(13) RESUMEN. En este trabajo de grado se desarrolló un algoritmo para llevar a cabo la configuración de un dispositivo de red como lo es un Router. Para la implementación del algoritmo diseñado se utilizaron dos lenguajes de programación específicos, Java y Python. El principal objetivo del algoritmo tratado en esta tesis es reducir el tiempo que toma un usuario sin conocimientos avanzados en redes, en configurar unos parámetros específicos a un router. Este algoritmo permite al usuario configurar dos tecnologías de Router, la Tecnología de Cisco Systems y Mikrotīkls Ltd (comúnmente llamada Mikrotik), donde la comunicación entre los routers y los equipos terminales se realiza por un protocolo de acceso remoto, llamado Secure Shell Versión 2 (SSH V2), para encriptar los datos en formato MD5 y dar mayor seguridad con respecto a otros protocolos de red como Telnet. En la creación del algoritmo se tuvo en cuenta la arquitectura dirigida por Modelos MDA, arrojando los diferentes diagramas de caso de uso, diagrama de clase y diagramas de secuencias. Finalmente se realizan pruebas del algoritmo con una muestra de usuarios que evaluaron su uso.. Palabras Claves: Algoritmo, DHCP, Enrutamiento estático, Lenguajes de Programación, MDA, Router.. 13.

(14) 1. INTRODUCCIÓN Cada proveedor de tecnologías de routers busca brindar al usuario la facilidad de programar sus dispositivos con diferentes tipos de parámetros, para poder conformar una topología dentro de una red especifica por medio de una plataforma única para cada tipo marca. Este proyecto busca por medio de un modelo MDA crear una única interfaz para programar dos tecnologías de routers con algunos parámetros para su correcto funcionamiento dentro de la topología de red. Esto debido al reciente crecimiento en las redes a nivel mundial y a la interacción entre diversos entornos de programación con sus respectivos lenguajes de programación por medio de Modelos y diagramas que ayuden solución de errores e implementaciones de parámetros posteriores. Se utilizará el modelo estándar de OMG llamado MDA el cual permita generar portabilidad al código e integrarlo con diferentes plataformas de programación y diversos lenguajes de programación. Para la construcción de este modelo se usaran una plataforma de programación y dos lenguajes de programación Python y Java, además por medio del código escrito generar el diagrama de clase para posteriormente crear el modelo UML y finalmente generar el modelo MDA.. 14.

(15) 2. OBJETIVOS. 2.1 OBJETIVO GENERAL Crear un algoritmo a partir de un lenguaje de programación específico para configurar tecnologías de diferentes proveedores de routers, basándose en arquitectura dirigida por modelos (MDA). 2.1.2 OBJETIVOS ESPECÍFICOS 1. Generar un algoritmo de configuración de un router que permita gestionar algunos parámetros como mínimo en dos routers de diferentes tecnologías. 2. Desarrollar el modelo UML para el algoritmo de configuración de los diferentes dispositivos de red. 3. Realizar las pruebas de implementación del modelo con una muestra de personas para observar su estandarización.. 15.

(16) 3. PLANTEAMIENTO DEL PROBLEMA. 3.1 DEFINICIÓN DEL PROBLEMA En la actualidad se conocen diferentes tecnologías de routers para crear aplicaciones de redes de datos, donde es necesario conocer a profundidad los dispositivos de red que se requieren para solucionar una necesidad, estos métodos con los que se configura un router pueden demandar horas en el reconocimiento del dispositivo y realizando pruebas de funcionamiento. Los costos que demanda la configuración de un router pueden variar dependiendo de hacer un curso de o certificación para adquirir los conocimientos o contratar a un experto para ejecutar las instrucciones correctas. Buscando una solución alternativa que permita optimizar tiempo y la reducción de costos se elaboró este proyecto, que facilita a un usuario reducir procedimientos para la configuración de un router, a través de un algoritmo que actualmente permite una configuración predeterminada en dos tecnologías de routers. Con esto último se pretende buscar la generalización de los comandos de configuración de routers para mejorar el aprendizaje y uso de las diferentes tecnologías implementadas por los actuales dispositivos de red, para llevar a cabo esta solución se propone un aplicativo estándar de fácil uso para el usuario final. 3.2 JUSTIFICACIÓN El desarrollo de software se ha incrementado en los últimos años, lo cual ha hecho que el profesional actual tenga que aprender múltiples entornos de desarrollo desaprovechando tiempo y recursos. Cada dispositivo configurable para el diseño de redes tiene comandos diferentes para su uso influenciando a que un usuario se enfoque en una marca ante la imposibilidad de desarrollar en diversos dispositivos. Al consultar en la web y en otros recursos se observa que no hay un entorno que facilite al usuario hacer una configuración predeterminada de dos marcas diferentes con un mismo aplicativo. La configuración de una topología puede ser una tarea ardua si se quiere implementar diferentes tecnologías de routers, ya que implicaría tiempo en conocer ambas tecnologías y limita al usuario a solo acceder a una marca. 16.

(17) que puede ser costosa y elevar el precio de una aplicación. Al continuar con la consulta no se encontró un modelo de software que facilite a un desarrollador asociar rápidamente lenguajes específicos con la configuración de un router, esto limita algunas aplicaciones posibles y desarrollos en las redes de datos. 4. MARCO TEÓRICO Se necesitó de diferentes conceptos teóricos que posibilitaron el desarrollo dentro de ciertos parámetros estos conceptos teóricos se observan a continuación. 4.1 MODELO Se define modelo como la representación de un objeto existente en pequeñas dimensiones en donde se genera un esquema teórico para después ser representado mediante un objeto real, en los modelos para el desarrollo de software se busca automatizar la etapa de desarrollo, este proceso es llamado como Ingeniería Dirigida por Modelos MDE(1). 4.1.1 INGENIERÍA DIRIGIDA POR MODELOS Ingeniería dirigida por modelos (MDE) es la forma de optimizar el proceso de desarrollo que se genera a partir de un modelo. En el desarrollo de software existen modelos en donde se pueden automatizar algunos procesos(2). El objetivo principal del MDE en la creación de software es automatizar la mayor parte del desarrollo del modelo, dado que el software se vuelve cada vez más complejo y la industria necesita industrializar el desarrollo del software. Anteriormente no se hablaba de crisis del software, referido a que en el tiempo que no existían las computadoras la programación no era ningún problema, pero a lo largo de la historia y con la creación de las computadoras la programación fue de problema leve a volverse un problema gigantesco(1). Durante las últimas dos décadas los lenguajes y plataformas han aumentado el nivel de abstracción creciendo rápidamente, dando paso a nuevas (3). Para tratar el tema del crecimiento del software la orientación a objetos no es suficiente y la reutilización de objetos en la industria de software no ha tenido tanto éxito, por esta razón ha aparecido una propuesta basada en modelos en donde se. 17.

(18) conserve el marco conceptual del negocio independiente de la plataforma y el lenguaje con el que se implemente(3).. Figura 1: Cambios en los lenguajes de programación a través del tiempo. En la figura 1 se observa la evolución en los lenguajes de programación, primero se creó el binario en el cual existían mayor número de errores en el desarrollo y a medida que avanza el tiempo el nivel de abstracción de los lenguajes ha aumentado(1). Esto se ha dado a partir de la necesidad de reducir la complejidad de las plataformas actuales, de expresar los conceptos de los diferentes dominios de forma más apropiada, de hacer una abstracción de los sistemas de la implementación de la plataforma, de mejorar la portabilidad reusabilidad e interoperabilidad y de optimizar la productividad(1). La ingeniería dirigida por modelos MDE incluye dos conceptos fundamentales, lenguajes de dominio específico los cuales definen la estructura de la aplicación y los requisitos de un dominio en particular y los motores de transformación que son los que se encargan de analizar el código y crear el código fuente entradas de simulaciones o representaciones de dicho modelo(3). Finalmente se define que MDE sirve para crear modelos de software en donde los conceptos de un dominio predeterminado definen un modelo, y las tecnologías existentes permiten trabajar con MDE como si fueran lenguajes de programación de alto nivel pero estos tienen la particularidad que son lenguajes de dominio especifico, esto tiene muchas aplicaciones en muchos sectores como en Telefonía IP, Gestor de para Android, aplicaciones móviles, relojes digitales, automatización del hogar entre muchas otras(1).. 18.

(19) 4.1.2 ARQUITECTURA DIRIGIDA POR MODELOS Dentro del MDE se define un estándar el cual es Arquitecturas dirigidas por modelos, definido por la Grupo de manejo de Objetos OMG en donde se aproxima como el diseño de los sistemas se orienta a objetos y está organizada en el concepto de modelo independiente de la plataforma (PIM), PIM se define como la especificación de un sistema en términos de conceptos del dominio y con independencia de las plataformas tecnológicas y este puede transformarse automáticamente en un modelo de plataforma o PSM, MDA tiene como objetivo acelerar el desarrollo de aplicaciones simplificar la integración entre distintas tecnologías y reducir el costo de la migración de aplicaciones a nuevas plataformas, en donde la importancia son los modelos en el proceso de desarrollo de software, MDA propone la el uso de modelos para guiar el proceso de desarrollo, y de esta forma generar de forma automática partiendo de los modelos definidos y las reglas de transformación de dichos modelos (1)(4)(5). El éxito en la línea de productos de software es importante la parte de licitación representación y gestión de la variabilidad y para este fin se recurre a MDA como una herramienta de construcción de herramientas de dominio y su transformación a través de modelos de arquitectura (4). Dentro de MDA se tiene un esquema como el que se observa en la figura 2.. Figura 2: Esquema de MDA.. En donde CIM se define como modelo independiente de la computación (modelo de dominio), PIM es Modelo independiente de la plataforma en donde se describe la funcionalidad de un sistema, PSM Modelo especifico de plataforma, ISM. 19.

(20) Implementación del modelo especifico en donde se describe con que lenguaje se va a trabajar(1). Dentro de MDA el grupo OMG definió varios estándares como Lenguaje de modelo unificado UML, Facilidad de meta modelar Objetos MOF, intercambio de meta datos por XML XMI, Lenguaje de restricción de objetos OCL, Transformación de vistas por preguntas QVT(1). En donde MOF es el lenguaje para crear meta modelos propuesto por OMG para MDA en donde es independiente de la plataforma y es el medio universal para definir lenguajes de modelado en donde las herramientas de MOF son interoperables entre sí(1). UML toma elementos de MOF en donde es un estándar para visualizar documentar y más, en donde es independiente del lenguaje y es el principal modelo utilizado en el modelado de MDA; UML es una familia de lenguajes en donde un perfil define una extensión UML en donde se define una forma específica para el uso de UML para un dominio especifico y estos a su vez son usados como PSM(1). Los perfiles se definen mediante un modelo formal en donde se crean estereotipos, valores etiquetados y restricciones. XML permite que las herramientas se integren al serializar modelos y meta modelos MOF en XML y es independiente de la plataforma en donde va más orientado a los modelos en general. OCL se utiliza para definir restricciones y consultas este estándar es parte de UML, y resuelve varias problemáticas y limitaciones en los diagramas UML agrega precisión y genera un diagrama más completo. QVT es un lenguaje de transformación de modelos es dependiente de las especificaciones de MOF y OCL en donde Query hace un filtrado y selecciona elementos del modelo MOF, View es una modelo que se deriva de otro modelo y transformación existen reglas para aplicar transformaciones al modelo(1). Por otro lado MDA separa las especificaciones de un sistema y los detalles de la plataforma en la que se ejecuta para proporcionar bases de:  Definir un sistema independiente de la plataforma.. 20.

(21)  Definir plataformas sobre la cual construir los sistemas.  Elegir una plataforma específica para el sistema.  Transformar la especificación inicial del sistema a la plataforma elegida.. En el desarrollo de software tradicional se siguen las siguientes fases:  Identificación de requisitos  Análisis  Diseño  Codificación  Prueba  Despliegue. Figura 3: Método Tradicional del desarrollo de software La figura 3 muestra el método tradicional de desarrollo de software lo cual baja la productividad al hacer el modelo susceptible a errores en cualquier parte del proceso y al tener que documentar y hacer diagramas demasiado extensos, además si varia con el tiempo variara la documentación(6). En la parte de portabilidad si se necesita migrar el sistema en una industria a otra plataforma hay que hacer un desembolso importante y hacer varias modificaciones. 21.

(22) al modelo (6). Otro aspecto importante es la interoperabilidad, se necesita que la comunicación entre sistemas existentes y sistemas nuevos de manera sencilla y simple(6). Finalmente se obtiene que en la parte de documentación y mantenimiento es un proceso tedioso al tener que realizarse a mano y a los desarrolladores no les interesa mucho documentar el código y esto hace que se pierda calidad, los anteriores ítems se solucionan con MDA en donde en la parte de análisis diseño y codificación cambian al ser reemplazadas por PIM y PSM como se muestra en la figura 4 (6).. Figura 4: Desarrollo de software por MDA. Según IBM MDA es el resumen de tres ideas complementarias las cuales son: 1) Representación directa: Se hace enfoque en las ideas y conceptos del dominio del problema en vez de la tecnología usada y del desarrollo del software, logrando diseños más acertados e incrementando la productividad(6). 2) Automatización: MDA incrementa la velocidad en el desarrollo y reduce errores usando herramientas para transformar modelos específicos en códigos de implementación(6). 3) Estándares Abiertos: Los estándares ayudan al progreso de las tecnologías eliminando la diversidad gratuita ayudando tanto como al vendedor a producir. 22.

(23) herramientas de propósito general y especializado como al usuario de manejarlas(6).. Figura 5: Representación de IBM para MDA En la figura 5 se muestra la representación según los desarrolladores de IBM para MDA. Lo importante en esta descripción de MDA son las transformaciones que se realizan de PIM a PSM y se definen dos tipos principales de transformaciones: 1) Transformaciones de tipos: Según la definición “ Un mapping de tipos especifica un mapping para transformar cualquier modelo construido con tipos PIM a otro modelo expresado con tipos PSM” esto quiere decir que a un PIM se le aplica una regla o norma para transformarlo en uno o varios PSM, puede ser a través del estándar UML. 2) Transformaciones de Instancia: Identifica elementos específicos de un PIM para ser transformados a una plataforma en particular esto se logra a través de marcas, En donde una marca representa un concepto del PSM y se le aplica a un elemento PIM para dirigir una la transformación a una plataforma determinada(7). Existen varias herramientas para lograr estas transformaciones en MDA, como Optimaj, CASE, ArcStyler de código abierto para. Optimaj se usa específicamente para la transformación de PIM a PSM, las herramientas CASE se usan para transformar de PSM a código, y ArcStyler e usa para transformar de PIM a código usando marcas. En todo esto se necesita un IDE de desarrollo o una plataforma para lo cual recurrimos a usar Eclipse que ofrece la posibilidad de usar estas herramientas para MDA(6).. 23.

(24) 4.1.3 TRANSFORMACION DE MODELOS Los modelos pueden relacionarse a través de transformaciones, estas se definen a nivel de meta-modelo y se aplican a nivel del modelo de modo que se ajuste a dicho meta modelo. Los modelos necesitan se migrados tradu8cidos y representados a otros lenguajes o representaciones esto es posible por medio de las transformaciones de modelos, existen dos tipos fundamentales de transformaciones de modelo a modelo y de modelo a texto.. 4.1.4 TRANSFORMACIÓN DE MODELO A MODELO Una Transformación de Modelo a Modelo (M2M) es un programa que recibe uno o más programas como entrada y devuelve uno o más programas como salidas dando como resultando transformaciones uno a uno, uno a muchos, muchos a uno, muchos a muchos, y se definen como exógenas cuando los modelos están definidos en distintos lenguajes o endógenos cuando están definidos en el mismo lenguaje(8).. 4.1.5 TRANSFORMACIÓN DE MODELO A TEXTO Una Transformación de Modelo a Texto M2T es un programa que recibe uno o más modelos para generar automáticamente un modelo representado a texto, estas son las más comunes dentro de la ingeniería de software para la generación de documentación, lista de tares y el código fuente, para representar un modelo es necesario expresarlos de alguna manera, los lenguajes de modelado definir la información de un sistema por un conjunto de reglas definidas, estas reglas son usadas para interpretar el significado de los componentes de esta estructura(8).. 24.

(25) Figura 6: Componentes de un Lenguaje de modelado 4.1.6 DIAGRAMA DE USOS Representa la forma de como un usuario opera con el sistema, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes elementos: Actor: Una definición previa, es que un Actor es un usuario del sistema. Es un rol donde el actor realiza una labor frente al sistema. Como ejemplo el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local. Caso de Uso: Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso. Hay diferentes tipos de relaciones en los casos de uso: Asociación: Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple. Dependencia o Instanciación: Es una forma muy particular de relación entre clases, en la cual una clase depende de otra. Dicha relación se denota con una flecha punteada.. 25.

(26) Generalización: Cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este tipo de relación está orientado exclusivamente para casos de uso (y no para actores). Tenemos entonces: . extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).. . uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica. (26). 4.1.7 DIAGRAMA DE SECUENCIA Es una forma de diagrama de interacción que muestra los objetos como líneas de vida a lo largo de la página y con sus interacciones en el tiempo representadas como mensajes dibujados como flechas desde la línea de vida origen hasta la línea de vida destino. Los diagramas de secuencia son buenos para mostrar qué objetos se comunican con qué otros objetos y qué mensajes se envían en esas comunicaciones. Los diagramas de secuencia no están pensados para mostrar lógicas de procedimientos complejos, y se componen de los siguientes elementos: Línea de Vida: Una línea de vida representa un participante individual en un diagrama de secuencia. Una línea de vida usualmente tiene un rectángulo que contiene el nombre del objeto. Algunas veces un diagrama de secuencia tendrá una línea de vida con un símbolo del elemento actor en la parte superior. Este usualmente sería el caso si un diagrama de secuencia es contenido por un caso de uso. Los elementos entidad, control y límite de los diagramas de robustez también pueden contener líneas de vida. Mensajes: Los mensajes se muestran como flechas. Los mensajes pueden ser completos, perdidos o encontrados; síncronos o asíncronos: llamadas o señales. En el siguiente diagrama, el primer mensaje es un mensaje síncrono (denotado por una punta de flecha oscura), completo con un mensaje de retorno implícito; el segundo mensaje es asíncrono (denotado por una punta de flecha en línea) y el tercero es un mensaje de retorno asíncrono (denotado por una línea punteada). 26.

(27) Ocurrencia de ejecución: Un rectángulo fino a lo largo de la línea de vida denota la ocurrencia de ejecución o activación de un foco de control. En el diagrama anterior hay tres ocurrencias de ejecución. El primero es el objeto origen que envía dos mensajes y recibe dos respuestas, el segundo es el objeto destino que recibe un mensaje asíncrono y retorna una respuesta, y el tercero es el objeto destino que recibe un mensaje asíncrono y retorna una respuesta. Mensaje Self: puede representar una llamada recursiva de una operación, o un método llamando a otro método perteneciente al mismo objeto. Este se muestra como cuando crea un foco de control anidado en la ocurrencia de ejecución de la línea de vida. Inicio y final de línea de vida: Una línea de vida se puede crear o destruir durante la escala de tiempo representada por un diagrama de secuencia. En el último caso, la línea de vida se termina por un símbolo de detención, representado como una cruz. En el primer caso, el símbolo al inicio de la línea de vida se muestra en un nivel más bajo de la página que el símbolo del objeto que causó la creación (27).. 4.1.8 DIAGRAMA DE CLASES Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia y de uso. Un diagrama de clases está compuesto por los siguientes elementos:   . Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso. Elementos. Clase: Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella se puede modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). En UML, una clase es representada por un rectángulo que posee tres divisiones: . Superior: Contiene el nombre de la Clase. . Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public).. 27.

(28) . Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).. Atributos: Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son: . public (+,): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.. . private (-,): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).. . protected (#,): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).. Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características: . public (+,): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.. . private (-,): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar).. . protected (#,): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia). (28). 4.2 PROTOCOLOS Es un sistema o conjunto de reglas estandarizadas ante algún organismo internacional para permitir la comunicación a través de cualquier medio físico, y se puede implementar por software o hardware, un protocolo de comunicación son llamados protocolos de red, en la cual se definen como o se deben trasmitir los distintos tipos de mensaje y en que capa del modelo OSI serán enviadas para circular en una red de computo.. 28.

(29) 4.2.1 Configuración de Host Dinámico (DINAMIC HOST CONFIGURE PROTOCOL DHCP) Todo dispositivo que se conecte a un red necesita una dirección IP única, por lo cual se necesita que para equipos que no cambien de ubicación dentro de la red como servidores e impresoras se les asigne estas direcciones de forma estática, para los demás equipos como los host cambian de ubicación física y lógica por lo cual es necesario un protocolo el cual asigne direcciones IP y otra configuración ante estos cambios. El protocolo de configuración de host dinámico DHCP, permite a un equipo conectado en red obtener su configuración de forma dinámica y solo se le deba suministrar al equipo mediante DHCP que encuentre una dirección IP de forma independiente, utiliza los puertos 68 y 69 de la capa de transporte. El protocolo DHCP distribuye las direcciones IP en una red haciendo su administración más sencilla este protocolo es orientado sin conexión por lo que opera. Para el funcionamiento del protocolo DHCP se necesita un servidor DHCP que distribuya las direcciones IP el servidor será el único que tendrá una dirección IP estática. El sistema de comunicación es BOOTP enviando tramas UDP, así cuando un equipo se inicia transmite un paquete 255.255.255.255 con información adicional como el tipo de solicitud, los puertos de conexión y más través de una red local de esta forma cuando el servidor recibe el paquete responde con otro paquete de transmisión que contiene la información solicitada por el cliente. Existen varios tipos de paquetes que pueden enviarse tanto del cliente al servidor como del servidor al cliente los cuales son:  DHCPDISCOVER: Ubica un servidor DHCP desde el cliente, el cliente envía un broadcast en IPV4 para hacer este procedimiento.  DHCPOFFER: Respuesta que se le da a un DHCPDISCOVER con los parámetros iniciales desde el servidor DHCP de modo Unicast.. 29.

(30)  DHCPREQUEST: Solicitudes de los clientes de broadcast para aceptar la configuración enviada desde el servidor y para que otros host y servidores DHCP no asignen esa dirección IP.  DHCPACK: Respuesta del servidor para indicarle que tiene la dirección IP y demás parámetros del cliente  DHCPDECLINE: El cliente indica que la dirección ya está en uso.  DHCPRELEASE: El cliente termina la conexión.  DHCPINFORM: El cliente solicita parámetros locales pero ya tiene la dirección IP. El cliente envía un paquete DHCPDISCOVER con la dirección de difusión de capa 2 y capa 3, el servidor contesta con un DHCPOFFER en unidifusión o solo se comunica con el cliente que solicita el servicio DHCP para enviarle una dirección IP al cliente, el cliente realiza su configuración y luego hace un DHCPREQUEST para validar su dirección IP en modo difusión para que todos los demás equipos de la red se enteren que ese cliente tiene una dirección IP asignada, el servidor responde con DHCPACK con la dirección IP para confirmar la asignación y este es el procedimiento para que un cliente se conecte a un servidor DHCP. Este protocolo tiene concesiones para optimizar los recursos de red, de esta forma las direcciones IP se asignan con una fecha de inicio y de vencimiento para su validez, este proceso se le llama concesión, así un cliente detecta que su concesión está a punto de vencer y puede solicitar al servidor un DHCPREQUEST, y también cuando el servidor detecta que la solicitud va a vencer enviar un DHCPACK, para consultarle al cliente si quiere extenderla, y si el servidor no recibe respuesta pone la dirección IP como disponible y cierra la conexión, también se puede optimizar las concesiones planeando la duración de las concesiones(9–11). El protocolo DHCP tiene 3 métodos de asignación de una dirección IP:  Asignación manual o estática: Se asigna una dirección a una maquina determinada y se usa cuando se quiere controlar la asignación IP a cada cliente y que clientes no identificados accedan a la red.  Asignación automática: Asigna una dirección IP de forma permanente a una maquina la primera vez que el cliente hace la solicitud al servidor hasta que el cliente la libera.. 30.

(31)  Asignación dinámica: El administrador determina un rango de direcciones IP, y se configura cada dispositivo para que al inicializar su tarjeta de red solicite su dirección IP esto facilita la conexión de nuevas máquinas clientes en la red además es el único método de reasignación dinámica de las direcciones IP. Los parámetros configurables según la RFC 2132:  Dirección del servidor DNS.  Nombre DNS.  Puerta de enlace de la dirección IP.  Dirección de broadcast.  Mascara de subred.  Tiempo máximo de espera del ARP.  MTU  Servidores NIS.  Servidores NTP  Servidor SMTP  Servidor TFTP  Nombre del servidor WINS.. Figura 7: Formato de mensaje de DHCPV4. 31.

(32) En la ilustración se muestra los diferentes campos que componen un mensaje DHCP en IPV4 y se describen a continuación. Código de Operación: Especifica el código del mensaje en donde un uno asigna un mensaje de solicitud y un dos asigna un mensaje de respuesta. Tipo de Hardware: Identifica que tipo de hardware se está utilizando en la red si es 1 es Ethernet, 15 Indica que es Frame Relay y 20 indica línea serial. Longitud de dirección del hardware: Especifica la longitud de la dirección. Saltos: Este controla la cantidad de retransmisiones en una solicitud. Identificador de transacción: Los utiliza el cliente para hacer coincidir la solicitud con las respuestas recibidas por los servidores DHCP. Segundos: Indica la cantidad de segundos desde que el cliente comenzó a adquirir o renovar el arrendamiento de la dirección IP, y este número es usado por los servidores para dar prioridad a las solicitudes de los clientes. Indicadores: Este se utiliza cuando un cliente no conoce su dirección IP y envía una solicitud de difusión y este utiliza solo uno de los 16 bits de este campo. Dirección IP del Cliente: Lo utiliza el cliente solo cuando va a renovar la dirección provista por el servidor y solo se usa en el caso de que el cliente tenga anteriormente una dirección IP asignada de lo contrario este valor se establece en 0. Su dirección IP: La utiliza el servidor para asignar una dirección IP al cliente. Dirección IP del servidor: La utiliza el servidor para identificar la dirección del servidor que asigna el servicio DHCPV4. Dirección IP de Gateway Enruta los mensajes DHCPV4 esta dirección facilita las comunicación cuando las respuestas vienen de servidores ubicados en diferentes redes o subredes. Dirección de hardware del cliente: Especifica que tipi de medio físico usa el cliente en la conexión. Nombre del Servidor: Lo usa el servidor que cuando envía los mensajes de DHCPOFFER o DHCPACK, el servidor puede colocar de forma opcional su nombre en este campo. Nombre de archivo de arranque: En el proceso en que el cliente solicita un DHCPDISCOVER lo utiliza para solicitar determinado tipo de archivo de arranque o lo utiliza el servidor en el proceso de DHCPOFFER para especificar completamente los archivos de arranque que necesita el cliente.. 32.

(33) Opciones de DHCP: Contiene las opciones de DHCP, incluidos parámetros requeridos para el funcionamiento básico de DHCP, este campo es de longitud variable y el cliente como el servidor pueden utilizarlos. 4.3 ROUTER Un router es un dispositivo que permite la interconexión de una red LAN a la red Internet, además también guía los paquetes a través de una red correcta e ir determinando que recorrido hacen los mismo para llegar a su destino, estos usan tecnología ADSL la cual el manejo de internet de banda ancha y ser distribuido a través de medios guiados(14). El router tiene varios componentes los cuales son: . CPU: Es el sistema central de procesamiento del router y ejecuta las instrucciones del sistema operativo las cuales incluyen la inicialización del sistema funciones de enrutamiento y de interfaz gráfica.. . RAM: Es la memoria de acceso aleatorio y se usa para guardar la las tablas de enrutamiento.. . Memoria Flash: La memoria flash se usa para almacenar una imagen del sistema operativo.. . NVRAM: La memoria de acceso aleatorio no volátil se usa por lo general para guardar la configuración de inicio.. . Buses: Los buses se usan en la comunicación entre la CPU y las interfaces y ranuras de expansión.. . ROM: Memoria de solo lectura se usa para almacenar de forma permanente el código de diagnóstico de inicio.. . Fuente de alimentación: Brinda alimentación de energía a los componentes internos.. . Interfaces: Son conexiones de los routers hacia el exterior y pueden ser de tres tipos LAN, WAN y de Consola AUX.. En un router se tienen versiones del sistema operativo que pueden o no ser restrictivos y limitar funcionalidades por lo cual a continuación se mencionan las diferentes alternativas para superar estas limitantes.. 33.

(34) . Tomato: Es un firmware de reemplazo del Router Linksys WRT54G/GL/GS y otros Router basados en el chip Broadcom, con funcionalidades sencillas simples y fácil de aprender. Entre estas esta una interfaz gráfica de acceso Web, con un monitor de ancho de banda, incluye una mejora con respecto al QoS y restricciones de acceso, habilita una nueva característica inalámbrica como WDS y nuevos modos de acceso inalámbrico para los clientes, y aumenta el número máximo de conexiones P2P, además permite ejecutar script por medio de SSH/Telnet y hacer más cosas como observar por medio de la interfaz gráfica el nivel de conexión inalámbrica de los vecinos cercanos de la red (15).. . DDWRT: Es un firmware OpenSource basado en Linux adecuado para gran cantidad de Router con WLAN y sistemas embebidos, en donde el principal énfasis radica en proporcionar un fácil manejo mientras soporta un gran número de funcionalidades sin la necesidad de usar el sistema operativo original. La interfaz gráfica tiene una estructura lógica y se maneja a través de buscadores Web, así personas no expertas pueden hacer sus configuraciones en unos pocos pasos. El manejo simple velocidad y estabilidad son ejes fundamentales de este firmware, si se compara el software preinstalados en la mayoría de Router WLAN, DDWRT permite una operación confiable con una gran funcionalidad. DDWRT tiene un gran soporte por usuarios que utilizan este mismo sistema operativo debido a esto permite respuestas rápidas, los usuarios también pueden encontrar respuestas a preguntas de otros usuarios por medio del foro y la Wiki contiene información futura y guías para mantener a la comunidad DDWRT actualizada. Para dispositivos usados con fines personales DDWRT está disponible gratuitamente, para plataformas usadas comercialmente requiere una licencia de pago. La versión de pago permite modificar parámetros de WLAN para dar confiabilidad a la conexión de redes (16).. . OpenWrt: Es una versión GNU-LINUX para sistemas embebidos en general Router inalámbricos, a diferencia de otros OpenWrt es construido para dar 34.

(35) unas características máximas, con una fácil modificación del sistema operativo lo cual significa que se pueden obtener muchas características personalizadas basadas en Linux. Open Wrt es un firmware estático el cual permite sobrescribir archivos del sistema operativo con manejo opcional de paquetes, y es libre de restricciones en la configuración de esta forma permite usar paquetes propios y sistemas embebidos para la aplicación. Para los desarrolladores OpeWrt permite crear una aplicación sin tener que crear una imagen completa del firmware, esto le da libertad al usuario de crear aplicaciones que requiera sin ningún tipo de licencias. Esto quiere decir que es Open Source totalmente con una licencia GPL, e intenta siempre ser accesible desde un sitio Web con una fuente completa de código disponible y fácil de modificar. OpenWrt ofrece un acceso fácil y gratuito lo que quiere decir que está abierto para nuevas contribuciones que se quieran realizar, también tiene una comunidad interesada en un proyecto en común (17). . RouterOS: es un sistema operativo para los Mikrotik RouterBOARD basado en el kernel de Linux (V2.6). Se caracteriza por ser un S.O de fácil configuración. Una de las características que hace diferente a RouterOS es que puede ser instalado en un computador, emulando un router con todas las características necesarias de red, (firewall, routing, punto de acceso wireless, administración de ancho de banda, servidor VPN, etc…) (18) Hay diferentes métodos de configuración como: Acceso local vía teclado y monitor, Consola serial con una terminal, Acceso vía Telnet y SSH vía una red, WinBox interfaz gráfica, etc…. 4.3.1 ROUTER CISCO E-SERIES Usa el protocolo de comunicación inalámbrica 802.11n con seguridad WPA2 para la encriptación de datos y un firewall SPI para ayudar a proteger la red de posibles intrusiones incluye 4 puertos Ethernet (10/100) para la comunicación por red de los computadores conectados a la misma.. 35.

(36) Incluye un puerto WAN conectar por medio del cable Ethernet a un modem y de esta forma realizar la primera configuración, trae un botón de Wifi Secure Setup para configurar de forma fácil la red inalámbrica de seguridad, indicador de encendido y Jack de conexión AC, Indicador de Actividad de color verde para indicar cual puerto de Ethernet se está usando(19). Este Router no incluye funciones de acceso por entornos remotos como SSH y telnet originalmente, únicamente el acceso es vía HTTP/HTTPS puerto 80 o 443 para su configuración. Es un tipo de Router tipo SOHO el cual sirve para entornos caseros y conectividad limitada y velocidad FastEthernet a 100Mb.. 4.3.2 ROUTER CISCO 1941 Este Router es de la familia 1900 de Cisco el cual tiene cuatro puertos de acceso FastEthernet con velocidad de transmisión a 100Mb por defecto, además tiene dos puertos físicos tipo Giga Ethernet que soportan una velocidad de trasmisión de 10/100/1000 Mb/s. Cuenta con un puerto auxiliar para conectarse por medio telefónico dial-up y un de Consola para acceder a la configuración de los parámetros iniciales. Este Router tiene acceso de forma remota por los telnet y SSH que manejan los puertos 23 y 22 respectivamente además del acceso por via web por protocolo HTTP/HTTPS. Este cuenta con posibilidad de agregar puertos físicos WAN de alta velocidad de hasta 25Mb/s y dos puerto WAN con velocidad de 1.512 Mb. Este Router se usa en ambientes industriales para medianas empresas debido a sus prestaciones además permite interactuar con el sistema operativo de Cisco y utilizar los requerimientos que permite la licencia LAN-BASE (20) 4.3.3 MIKROTIK ROUTERBOARD 750GL Es un router sencillo de bajo costo, un router SOHO. Cuenta con cinco puertos Gigabit Ethernet independientes y la funcionalidad opcional de chip de conmutación Gigabit. La velocidad de la CPU es de unos 400MHz con una memoria RAM de 64MB. Sistema operativo RouterOS. Para las pruebas y resultados deseados es suficiente. Además es un modelo apto para el ámbito educativo y también utilizado en el entorno empresarial (21). 36.

(37) 5. METODOLOGÍA. Seleccionar tecnologías de router a usar. Conexión entre router y PC. Escoger Protocolo de comunicación entre Router y PC. Generar modelo MDA. Generar modelo UML. Crear diagrama de clase, estado y casos de uso.. Seleccionar lenguajes de programación para programar parámetros del Router.. Enviar los comandos para programar enrutamiento estatico.. Enviar comandos para programar DHCP.. Realizar las pruebas del Modelo MDA en la comunicación. Figura 8: Imagen de metodología a desarrollar El proyecto inicia seleccionando el tipo de tecnologías de routers con sus respectivos detalles operativos de conectividad entre los cuales se escogen las plataformas Cisco y Mikrotik. Se realiza la conexión con el PC por medio de cable cruzado, y en el tipo de protocolo que se escoge en el modo de conexión es el más seguro para interactuar con el Router entre las opciones de Telnet/SSH o Puerto de Consola y se elige SSH Versión 2 por tener encriptación en los datos a transmitir. Luego se crean diagramas de clases, casos de uso y diagramas de secuencia para generar el modelo UML guiado por MDA. Para tener el modelo de lo que se quiere implementar en el lenguaje de programación especifico, dentro de este se emiten comandos de configuración al router como servidor DHCP para obtener dentro de un rango direcciones una dirección IP en el PC.. 37.

(38) Adicionalmente cada interfaz del Router es una red diferente por lo cual se necesita interconectar las redes de los dos Router configurados en esta topología, por lo cual se escoge un modo de enrutamiento estático al ser una red pequeña y fácilmente administrable. Se eligen dos lenguajes de programación específicos los cuales serán Java y Python para desarrollar el aplicativo, además se escogen las respectivas librerías que permitan la interconexión entre el Router y el PC a través de cada plataforma por medio de SSH y de esta forma enviarle parámetros directamente desde el aplicativo en Java o Python. Por último se harán las pruebas finales por usuarios, estudiantes de la Universidad Distrital Facultad Tecnológica, verificando el funcionamiento del aplicativo y a su vez del algoritmo, esto permite consolidar que el modelo es portable a diferentes entornos de programación sin necesidad de utilizar un entorno específico para programar un Router y brindar al usuario una plataforma que soporte dos tecnologías de Routers escalables a un futuro.. 6. DESARROLLO DEL PROYECTO 6.1 EVALUACIÓN DE TECNOLOGÍAS: En este trabajo de grado se usaron dos tipos de tecnologías las cuales fueron Cisco y MikroTik, que tienen sistemas operativos propios del fabricante y tienen conexiones necesarias para el desarrollo del proyecto. Se buscaron dos proveedores de tecnologías que facilitaran su configuración a través de consola. También que ofrecieran características comerciales costo/beneficio. Como se sabe Cisco Systems es un proveedor bastante reconocido a nivel mundial ofreciendo una amplia gama de dispositivos para diferentes aplicaciones de red, este fabricante llamó bastante la atención de este proyecto para ser incluido en las tecnologías a utilizar. Entonces se revisaron dos referencias de routers marca Cisco y se evaluaron parámetros esenciales para la ejecución del proyecto. Cisco 1941: Con el IOS Original de Cisco y licencia LAN-BASE V15.1 permite acceso remoto por Telnet puerto 23, SSH puerto 22 además también tiene acceso por vía web protocolos HTTP/HTTPS, permite un enlace serial por medio del puerto de consola y un puerto AUX para comunicación por vía Telefónica o Dial-UP, 38.

(39) adicionalmente permite poner el router como servidor de DHCP y cuenta con protocolos de enrutamiento tanto dinámico como estático.. Figura 9: Imagen de Router Cisco 1941.. Se evaluó también el router SOHO Cisco E900 Linksys con el IOS original de cisco y este solo tiene acceso por medio de HTTP/HTTPSPS puerto 80 o 443 a su configuración por lo que se requiere tener de una conexión a Internet Disponible.. Figura 10: Imagen de Router Linksys e900 Debido a las pocas prestaciones que tiene el Router Cisco E900 con su Sistema operativo original, se debería cambiar a un sistema operativo como OpenWrt. Así que se procede a utilizar el router Cisco 1941 Respecto a lo anterior se eligió el Router Cisco 1941, dejando el sistema operativo provisto por el fabricante Para la elección de la segunda tecnología se realizó una búsqueda en los routers tipo SOHO (Small office/home office) ya que la primera tecnología a tratar (el router Cisco 1941) es una tecnología orientada a entornos empresariales más exigentes y robustos.. 39.

(40) En los routers tipo SOHO un proveedor de tecnología como Mikrotik se prefirió por su sistema operativo que está basado en software libre, por ser un router de bajo costo, con una amplia documentación y porque su sistema operativo puede ser instalado en un computador de escritorio emulando un Router. Por ello la referencia adquirida es la Mikrotik RB750GL (21). Figura 11. RouterBoard 750GL 6.2 DESARROLLO DEL ALGORITMO PARA LA CONFIGURACIÓN DE DOS ROUTERS DE DIFERENTES TECNOLOGÍAS El desarrollo de software depende generalmente de tres etapas: desarrollo del algoritmo, programación y pruebas. Anteriormente se dedicaba un 40% del tiempo dedicado a desarrollar el algoritmo y aplicar las pruebas de funcionamiento, y el tiempo restante a la programación en un lenguaje determinado. Ahora con MDE y MDA se busca implementar un 60% del tiempo en el desarrollo del algoritmo, y el otro 40% del tiempo se destina a la programación y a las pruebas, esto da un gran peso a las acciones previas a la programación, por lo tanto es de gran importancia contar con buenas especificaciones del proyecto a realizar. Como especificaciones del lado del usuario se consideró las direcciones IP del router y de la computadora, el usuario predeterminado del router, la contraseña predeterminada del router y los parámetros a configurar en el router. Las especificaciones que requiere considerar el algoritmo desde la parte operativa son la conexión con el router, las banderas de errores, los elementos de la interfaz de usuario, identificar que tecnología de router se conectó, seleccionar los comandos a enviar dependiendo de la tecnología y publicar la configuración aplicada. Al revisar estas especificaciones se realizó un algoritmo descrito en las siguientes etapas: 1. Cargar elementos de la interfaz de usuario del aplicativo. 40.

(41) 2. Definir las variables (usuario, contraseña, dirección IP, puerto), valores constantes (puerto 22 SSH) y operaciones (verificación de conexión, identificador, enviar comandos, publicar en pantalla) 3. Establecer comunicación con el router 4. Reconocer que router se conectó al aplicativo 5. Revisión de errores 6. Envío de comandos al router, configuración de red requerida por el usuario 7. Recepción información proveniente del router, verificación de la configuración 8. Cierre de la aplicación. Estas etapas se visualizan mejor en el diagrama de flujo de la figura 12. El algoritmo fue sometido a diferentes modificaciones para poder ser plasmado en la figura 12. Como se mencionó anteriormente el trabajo dedicado antes de la programación debe ser extenso, someter el algoritmo a revisiones más rigurosas, para evitar el gasto de recursos al momento de realizar la programación. Para comprobar la validez de este algoritmo se implementó por medio de dos lenguajes específicos dando paso a dos aplicativos, uno desarrollado en Java y otro en Python, estos resultados se mostraran posteriormente en este documento. De acuerdo al estándar MDA, se recomienda desarrollar previamente a la programación los siguientes modelos. 1. CIM: Descripción de la lógica del negocio, perspectiva independiente de la programación. 2. PIM: Descripción de la funcionalidad del sistema en forma independiente de las características de plataformas de implementación específica. 3. ISM: Descripción a nivel de código en un lenguaje específico (Java, Python) Estos modelos serán representados mediante una serie de diagramas de clases que se mostraran mediante la herramienta Enterprice Architect versión 8.0 (usando la licencia de prueba). 41.

(42) Figura 12, Algoritmo para configuración de router. 42.

(43) 6.3 DESARROLLO DE UN MODELO UML PARA EL ALGORITMO PARA LA CONFIGURACIÓN DE DOS DIFERENTES ROUTERS. 6.3.1 DIAGRAMA DE CASOS DE USOS Y VISUALIZACIÓN DE LA INTERFAZ DE USUARIO De acuerdo a los modelos recomendados por el estándar MDA se procede a desarrollar la lógica del negocio mediante un diagrama de casos de uso que interpreta la relación del usuario con el aplicativo. Como actor definimos al usuario que desea configurar un router: 1. 2. 3. 4.. El actor iniciará la aplicación ejecutando la aplicación El actor pulsará el botón que reconoce el router conectado El actor ingresará el usuario predeterminado en el router El actor ingresará la clave predeterminada por en el router. La asociación que se define entre el actor y los casos de uso estará definida como flujo de información para el caso de uso de ingresar usuario y contraseña. Para los demás casos se asociara como un uso. Se observarán las siguientes imágenes del caso de uso desarrollado (13). 43.

(44) uc Casos de uso principales Aplicación SSH2 Java. Inicio de Aplicación. «extend». «extend» Ingreso de usuario «flow» Usuario. «flow» Ingreso de Clav e. Cargando Configuración Auto. Figura 13. Diagrama de Casos de uso Al implementar el diagrama casos de uso anteriormente descrito se plantea el primer diseño de interfaz de usuario. Esta interfaz se modificó durante el desarrollo del proyecto como muestra la figura 14 y 15.. 44.

(45) Figura 14. Diseño de interfaz de usuario 1. Al realizar las debidas revisiones de las especificaciones se modifica la interfaz de la figura 14 y el caso de usos anteriormente mostrado por las figuras mostradas a continuación.. Figura 15. Diseño de interfaz de usuario 2. 45.

(46) uc Casos de uso principales Aplicación SSH2 Java. Inicio de Aplicación. «extend». Conexión con Router. Usuario Cargando Configuración Auto. Borra la configuración. Figura 16. Caso de uso finalizado Como se puede observar en el diseño de la interfaz y en el caso de usos, el usuario está obligado a conocer los datos de fábrica del router, es decir, la dirección IP, usuario y contraseña del router a configurar. Además el usuario debe configurar en la computadora la dirección IP, mascara de red y puerta de enlace, esta última debe ser la dirección IP que viene predeterminada en el router a configurar. Más adelante en este documento se explica una alternativa para facilitar al usuario la configuración de sus direcciones IP. Finalmente para el caso de usos se estableció los casos siguientes: 1. El actor inicia la aplicación 2. El actor pulsará el botón conectar para inicio de sesión y reconocer el router conectado, para esto se requiere ingresar los datos del router (dirección IP, usuario y clave) 3. El actor pulsará el botón que configura el router conectado 4. Opcionalmente, el actor puede borrar la configuración del router. 46.

(47) 6.3.2 DIAGRAMA DE CLASES El diagrama de clases para este proyecto se pensó de manera que permitiera la ejecución del algoritmo en tres clases que están en constante interacción. Las clases que se relacionaron en este diagrama son la clase principal, que llama y define los elementos de interfaz de usuario, capta los datos ingresados por el usuario y permite saber la interacción del usuario con el aplicativo, como conectar el router con el aplicativo, cargar la configuración al router, borrar la configuración en el router y cerrar la aplicación. En esta clase hay definidos cinco atributos para almacenar los datos del router (tipo String, atributos de tipo públicos), e interactuar con el usuario (variables para botones de tipo privados). Respecto a las operaciones que se definieron en esta clase están: Operación Principal (main) para que el ordenado puntualice en que clase iniciará el aplicativo, operación de tipo público. Otras dos operaciones de tipo públicas detalladas en esta clase son la operación para conectar y enviar comandos al router. Estas dos operaciones se relacionaran con la segunda clase del diagrama. Las operaciones privadas serán las fijadas por los “botones” de la interfaz de usuario. La segunda clase que en orden jerárquico sigue es la clase de Conexión y Envío de comandos. En esta clase se abre una sesión que permite reconocer el router conectado, enviar los comandos requeridos para la comunicación y recibir la respuesta del router a configurar. También genera banderas de errores si no hay conexión con el dispositivo de red o si el router fue desconectado al ser configurado, con lo cual se evita que el aplicativo “colapse” y se bloquee (mediante uso de excepciones). Además en esta misma clase se especifica el protocolo de comunicación para establecer una sesión no interactiva o interactiva con el router, dicho protocolo como se mencionó en la metodología del proyecto será SSH versión 2. Los atributos de esta clase están determinados por las variables de recepción y envió de comandos que deben ser tipo String. Adicionalmente dentro de la planeación posterior a la programación se consultó que para establecer una conexión por SSHv2 se debe aprovechar ciertas librerías al momento de programar, por ello se generan dos atributos para el uso de la librería. Estos atributos son públicos y el tipo de la variable dependerá de la librería utilizada. Las operaciones en esta clase son operaciones públicas, y están relacionadas con la descripción realizada al inicio de este párrafo, (conectar el router, envío de comandos, revisar errores, recibir mensaje) La última clase consta de un solo atributo y de dos operaciones. Esta es la clase de Autenticación, que posibilita la verificación de la clave que pueda tener el router a. 47.

(48) configurar. En esta clase también se tiene en cuenta el uso de la librería para SSHv2. El atributo es privado y de tipo String. Las operaciones dedicadas para verificar la clave llevan el String con la clave al router y retornan un valor verdadero o falso. Estos métodos u operaciones son públicas. El diagrama de clases entonces será el siguiente (Figura 17): class Modelo de clases UserInfo AutenticacionDeClav e -. password: String. + +. AutenticacionDeClave(password :String) promptYesNo(arg0 :String) : boolean. Generalización. ConexionRouterEnv ioComandos ~ ~ ~ ~. comand_enviar: ChannelExec conect: Session pssh: JSch = new JSch() recepcion: String = "". + + + + +. AutenticacionDeClave(password :String) enviar_comando(comando :String) : void error_conexion() : String metodo_recepcion() : String subconectar(admin_ip_contraseña :String, puerto :int) : void. Asociación. javax.swing.JFrame InterfazDeUsuario ~ ~ ~ -. admin: String = "admin" boton_configuracion_auto: javax.swing.JTextField ip_gateway: String = "192.168.88.1" port_router: int = 22 terminalSalida: javax.swing.JTextArea. + + +. boton_conectar(evt :ActionEvent) : void boton_desconect(evt :ActionEvent) : void boton_identificador(evt :ActionEvent) : void comando_config_automatica()(ComandoRouter :int) : void main(args :String[]) : void publicar_consola() : void. Figura 17. Diagrama de Clases Como se puede apreciar en la figura 17, las clases están relacionadas entre sí. Estas relaciones son singularizadas como asociación y generalización, donde la clase principal de interfaz de usuario se relaciona por medio de una asociación con la clase de Conexión y Envío de comandos, esto debido a que la clase de conexión. 48.

(49) colabora con la clase interfaz, pero no condiciona la existencia de los objetos en las clases. La relación establecida entre la clase de Conexión y la clase de Autenticación está calificada como una Herencia de tipo Generalización donde el método para autenticar la clave es heredado de la clase Conexión a la clase de Autenticación. 6.3.3 DIAGRAMA DE SECUENCIA Los diagramas de secuencia, son la descripción más detallada dentro del estándar MDA, en esta etapa se describen los mensajes entre las clases y el debido “camino” que debe seguir el programa. Se relacionan los atributos y operaciones de cada clase y se revisa el valor de retorno (tipos de variables texto, enteros, caracteres, etc…), también se precisa bloques de condiciones tipo IF o CASE. Es importante saber que el diagrama de secuencia parte del diagrama de casos de usos, porque por cada caso de uso se realiza un diagrama de secuencia. La figura 16 permite ver los de casos que se listaran a continuación: 1. Inicio de aplicación 2. Conexión con el router para inicio de sesión pulsando el botón conectar, para esto se requiere ingresar los datos del router (dirección IP, usuario y clave) 3. Configuración del router conectado 4. Opción de borrado de la configuración del router El diagrama de secuencias relacionará los casos de uso y las clases mencionadas en el diagrama anterior, se tendrá en cuenta los atributos y operaciones especificados. Las siguientes figuras muestran los diagramas de secuencias partiendo de los casos de usos.. 49.

(50) Figura 18. Diagrama de secuencia, Inicio de Aplicación 50.

(51) sd Sec Conexión «button». «text». «text». «text». :Conectar. :Caj a di recci ón IP. :Caj a Usuari o. :Cl ave Router. Cl ase :Conexi onT XRX. Cl ase :Autenti caci onDeCl ave. Usuari o. Acci onar() Obtener T exto(Stri ng). Obtener T exto(Stri ng). Obtener T exto(Stri ng). Al macenaDatosT emporal es(Stri ng, i nt) subconectar(Stri ng admi n, Stri ng i p, Stri ng cl ave, i nt puerto) EntregaVal oresVari abl es((Stri ng, Int)). Autenti caci onDeCl ave(Stri ng). Bandera() :bool eano. val orBool eano(). alt Rev isaConexión [i f(di sposi ti vo=conectado)] envi ar_comando(Stri ng). metodo_recepci on() :Stri ng i denti dadRouter() :Stri ng. GuardarNombreRouter(Stri ng). publ i car_Router() :Stri ng. [el se] error_conexi on() :Stri ng. Figura 19. Diagrama de secuencia, Conexión con el Router 51.

(52) sd Sec Cargar Confg «button». :InterfazDeUsuario. :ConexionT XRX. :Configurar Router Usuario. Accionar() Configurar(int). GuardarNombreRouter(String). alt IndentificadorRouter [if(router=Mikrotik)] bandera(int). [if(router=Cisco)] bandera(int). comando_config_automatica(bandera). alt ComandoRouter [if(comando=1)]. enviar_comando(String). metodo_recepcion() :String. [if(comando=2)] enviar_comando(String). metodo_recepcion() :String. publicar_consola(). Figura 20. Diagrama de secuencia, Cargando Configuración del Router 52.