ANÁLISIS Y DESARROLLO DE UNA APLICACIÓN WEB PARA LA GESTIÓN DE PROTOCOLOS DE PRUEBAS PARA
TRANSFORMADORES SERIE 15K IMPLEMENTANDO EL MODELO SE SERVICIO SaaS DE LA PLATAFORMA DE COMPUTACIÓN EN LA
NUBE
WILLIAM ANDRÉS CUADROS CASTRO JAIME ALEJANDRO AGUILAR GARCÍA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS BOGOTÁ D C
ANÁLISIS Y DESARROLLO DE UNA APLICACIÓN WEB PARA LA GESTIÓN DE PROTOCOLOS DE PRUEBAS PARA
TRANSFORMADORES SERIE 15K IMPLEMENTANDO EL MODELO SE SERVICIO SaaS DE LA PLATAFORMA DE COMPUTACIÓN EN LA
NUBE
WILLIAM ANDRÉS CUADROS CASTRO JAIME ALEJANDRO AGUILAR GARCÍA
Tesis
Director
Ing. Fernando Martínez
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS BOGOTÁ D C
Nota de aceptación:
Firma del presidente del jurado
Firma del Jurado
Esta tesis esta dedicada a las siguientes personas:
William:
A mi familia, en 5 grado de consanguinidad, por su apoyo y su ejemplo de trabajo continuo, siempre mirando hacia adelante.
- Calvin: A new year... a fresh, clean start!
- Hoobes: It’s like having a big white sheet of paper to draw on! - Calvin: A day full of possibilities!
- Calvin: It’s a magical world, Hobbes, ol’ buddy...Let´s go exploring!
Jaime:
A mis padres, por su apoyo incondicional y enseñarme a no darme por vencido frente a los obstáculos que se nos presenten.
Agradecimientos
William:
Sin duda a Fanny y Alberto (el cucho), personas a quien admiro profundamente por su amor sincero y su actitud incansable frente a la vida, lógico, también al cansón de mi hermano Jimmy. En especial a Danny, quien me llenó de fuerza y confianza para lograr esta meta. A Dieginho, Alex, Carlitos por su buen humor siempre. A Jaime mi compañero de tesis por su paciencia. Al profesor Fernando, por mantener el compromiso con nosotros. Gracias totales.
Jaime:
Índice general
4.2.7. Lenguaje de Modelado UML - Unied Modeling Languages[13] . . . 30
4.2.7.1. Componentes UML . . . 30
4.2.8. Transformadores Serie 15Kv . . . 32
4.2.8.1. Transformador de Voltaje: . . . 32
4.2.8.2. Clasicación . . . 33
Índice general 2
4.2.9.1. El proceso de fabricación de un transformador serie 15Kv . . . 34
4.2.9.2. Proceso de reparación de transformador serie 15Kv: . . . 34
4.2.9.3. Proceso de mantenimiento de transformador serie 15Kv: . . . . 34
4.2.10. Protocolo de prueba para transformadores . . . 35
4.2.10.1. Informativa: Incluye los datos descriptivos del transformador iniciales, así como los datos del fabricante y del cliente. . . 36
4.2.10.2. Pruebas de Régimen Nominal: en el cuadro 4.5 se enlistan las pruebas que se deben realizar al transformador serie 15Kv cu-yos resultados se registran en el protocolo de pruebas para transformador serie 15Kv. Estas pruebas se denomina ensayos de rutina según la norma NTC 380: Transformadores eléctricos. Ensayos eléctricos. Generalidades [6]. . . 36
4.2.10.3. Características físicas del transformador: . . . 36
Índice general 3
6.3.3.1. Diagrama de despliegue en la plataforma de computación en la nube. . . 60
6.3.4. Código fuente. . . 61
6.4. RUP - TRANSICIÓN . . . 61
6.4.1. Documento de casos de uso: Vista de casos de uso completo. . . 61
6.4.2. Documento de arquitectura: Arquitectura especicada y corregida. . . . 61
6.4.3. Documento de datos. . . 61
6.4.4. Línea base del producto completada . . . 61
Índice general 4
8.. RECOMENDACIONES . . . 65
Índice de cuadros
4.1. Modelos de servicio de la computación en la nube . . . 24
4.2. Clasicación de transformadores por tamaño . . . 33
4.3. Clasicación de transformadores por aislamiento . . . 33
4.4. Clasicación de transformadores por tensión de alimentación . . . 33
4.5. Ensayos de rutina . . . 36
4.6. Ensayos adicionales para transformador serie 15Kv . . . 36
4.7. Principios para modelamiento de objetos . . . 39
4.8. Relaciones entre objetos . . . 40
Índice de guras
4.1. Arquitectura de computación en nube . . . 22
4.2. Fases de la metodología RUP . . . 25
4.3. Ciclo de vida del software en RUP . . . 26
4.4. Diagrama de Red Eléctrica . . . 32
4.5. Proceso general transformador serie 15kV . . . 34
4.6. Proceso de fabricación de transformador serie 15Kv . . . 34
4.7. Proceso de reparación de transformador serie 15Kv . . . 35
4.8. Proceso de mantenimiento de transformador serie 15Kv. . . 35
4.9. Proceso de diligenciamiento de protocolo de pruebas para transformador serie 15kV . . . 37
4.10. Arquitectura Tradicional N-Layer (Lógica) . . . 40
6.1. Módulos del sistema . . . 51
6.2. Actores . . . 52
6.3. Diagrama de casos de uso . . . 57
6.4. Diagrama de paquetes . . . 57
6.5. Diagrama de clases . . . 58
6.6. Diagrama de secuencia . . . 59
6.7. Modelo de datos . . . 59
6.8. Diagrama de componentes . . . 60
Nomenclatura
Aceite mineral: Líquido que por sus características químicas y físicas no es buen conductor de la electricidad.
Bobina eléctrica : También llamado inductor, la bobina es un componente pa-sivo de un circuito eléctrico que, debido al fenómeno de la autoinducción, almacena energía en forma de campo magné-tico.
Cloud Security Alliance: Organización sin nes de lucro con la misión de pro-mover el uso de las mejores prácticas para ofrecer garantías de seguridad en Cloud Computing , y proporcionar educa-ción sobre los usos de la computaeduca-ción en nube para ayu-dar a asegurar todas las demás formas de la informática. [https://cloudsecurityalliance.org/]
Energizado: Estado del transformador cuand es instalado y puesto en fun-cionamiento conectandolo a la red de distribución.
Infraestructura como Servicio: Modelo de servicio de la computación en la nube. Básicamente el proveedor ofrece recursos como: máqinas virtuales, memo-ria, almacenamiento, rewall, balanceadores de carga y red. El cliente puede implementar la plataforma que él requiera. Núcleo ferromagnético : Material ferromagnético, que permite ordenar la dirección de
la corriente eléctrica del transformador.
Plataforma como Servicio Modelo de servicio de la computación en la nube. Básicamente el proveedor ofrece su plataforma denida por: sistema ope-rativo, un lenguaje de programación y un servidor web. El cliente puede implementar las aplicaciones que desarrolle. Programación Orientada a Objetos : Concepción de la realidad modelada
como componentes (objetos), utilizando herramientas como: abstracción, encapsulación, modularidad, jerarquía y polimor-smo.
Índice de guras 8
Software como servicio: Modelo de servicio de la computación en la nube. El proveedor ofrece un producto de software como un servicio. El cliente accede al producto, hace uso de lo que necesita, cuando lo necesita, donde lo necesita.
Tanque: Coe metálico, hermético, diseñado para contener la parte activa de un transformador y el aceite dielectrico.
Resumen
La aplicación desarrollada para la presente tesis permite la gestión de las pruebas para transformadores serie 15Kv durante los procesos de fabricación, reparación y mantenimiento. Esta aplicación utiliza el modelo de servicio SaaS (Software como Servicio) [22] para el manejo de la información de las empresas que suministran y ofrecen servicios a transformadores. Este desarrollo está soportado por la plataforma PaaS (Plataforma como Servicio) [22]de servicios en la nube de Microsoft.
El desarrollo de software bajo el modelo de servicio en la nube SaaS, ofrece como servicio el producto de software; y para su implementación, el uso como plataforma objetivo de los recursos de almacenamiento, procesamiento, memoria, ancho de banda y administración de los recursos de un proveedor de computación en nube.
La metodología de desarrollo utilizada en el proyecto es RUP (Rational Unied Process), y está enmarcada en el paradigma de programación orientada a objetos 1. El lenguaje de modelado utilizado es UML (Unied Modeling Language) como herramienta para modelar el sistema[23]. La plataforma en la nube que se utilizará será: Windows Azure 2 para el almacenamiento de datos no estructurado y SQL Azure 3 para el almacenamiento en Base de Datos. Como marco de referencia se utilizó la norma NTC 1358 (Protocolo de Pruebas para Transformadores)[5] donde se describe la estructura del documento de protocolo de pruebas serie 15Kv.
1Concepción de la realidad modelada como componentes (objetos), utilizando herramientas como:
abstrac-ción, encapsulamiento, modularidad, jerarquía y polimorsmo.
2Windows Azure es la plataforma de servicios en la nube de Microsoft. La plataforma cuenta con tres
servicios principales: servicio de cómputo donde se permite la ejecución de aplicaciones, un servicio de Al-macenamiento donde se almacena los datos de la aplicación, y una Fábrica donde se soporta los servicios de cómputo y almacenamiento.
INTRODUCCIÓN
En la actualidad hay dos factores que están marcando la pauta en el desarrollo de la tecnolo-gía a nivel mundial: la portabilidad y movilidad [15]. El primer factor caracteriza aquel sistema que puede ser ejecutado en diferentes plataformas (servidores, computadores de escritorio, te-léfonos inteligentes, tabletas ) y el segundo es la posibilidad de conectarse permanentemente a un recurso (red celular, wi, wimax).
En este contexto se presenta una oportunidad para incentivar en la innovación y el desa-rrollo de nuevas soluciones. En la actualidad una nueva tendencia tecnológica aprovecha estas condiciones, se denomina Computación en Nube (Cloud Computing).
Este proyecto de ingeniería de software tiene como objetivo principal, el diseño e imple-mentación de una aplicación web para diligenciar y generar un protocolo de pruebas para transformadores serie 15Kv, siguiendo la norma NTC 1358.
Se ha desarrollado una aplicación web para la gestión de la información del transformador serie 15Kv durante los procesos de fabricación, reparación, mantenimiento y pruebas. Esta aplicación utiliza el modelo de servicio SaaS (Software como Servicio) [22], dado que se ofrece el acceso vía web a la aplicación, y en el aplicativo el usuario encontrará diferentes recursos que le dan valor a su gestión. La aplicación esta soportada por la plataforma de un proveedor de servicios en la nube, bajo el modelo de servicio PaaS (Plataforma como Servicio) [22], donde se puede administrar los recursos de la plataforma como almacenamiento, procesamiento, memoria, ancho de banda, etc.
Otro punto importante que se pretende con el proyecto es la aplicación de las características de la computación en nube: demanda, accesibilidad, multi-localización, elasticidad y control ofreciendo un marco de implementación de nuevas soluciones en software de acuerdo a las permanentes exigencias de escalabilidad.
En el proyecto se denió como metodología de desarrollo RUP[16] por las siguientes ra-zones: al ser dirigida por casos de uso ofrece un marco controlado para la denición y el seguimiento del proyecto. De igual manera al ser centrada en la arquitectura, permite cons-truir una denición arquitectónica desde el principio la cual guiará el desarrollo durante el ciclo de vida del proyecto. Y al ser iterativo e incremental, permite la entrega de productos en etapas tempranas para su validación y entrega.
Como herramienta de modelamiento se denió la implementación de UML, este lenguaje contiene los diagramas y elementos necesarios para el modelamiento en cada etapa de desarrollo de la aplicación que se ha desarrollado: requisitos, diseño, codicación, despliegue, etc.
transfor-Resumen 11
mado. En el capítulo 2 se plantea la solución desde el punto de vista del ingeniero donde se justica el desarrollo de una aplicación web para gestión de la información del transformador. En el capítulo 3 se establecen los requerimientos generales del aplicativo (objetivo general y objetivos especícos) a partir de las necesidades de los usuarios. En el capítulo 4 se detalla el marco teórico sobre el cual se basó el desarrollo del proyecto. Inicialmente se describe el estado actual de la computación en la nube en Colombia, los proyectos que se han implementado los diferentes modelos SaaS, PaaS o IaaS. Apoyando esta descripción del estado actual, se repasa la evolución del concepto de la computación en la nube.
Adicional en el capitulo detalla los siguientes aspectos teóricos importantes para el proyec-to:
Computación en la nube.
Metodología RUP, de acuerdo a lo documentado por Rational4 [35]. Lenguaje de modelado UML, se revisa las vistas, diagramas y elementos. Transformador serie 15Kv, aspectos generales.
Procesos denidos para un transformador: fabricación, reparación o mantenimiento. Protocolo de pruebas según la norma NTC 1358.
Programación orientada a objetos, aspectos generales. Arquitectura aplicaciones en n-capas.
En el capítulo 5 se detalla el marco metodológico sobre el cual se desarrollo el proyecto. Principalmente este capítulo describe cómo fue la implementación de RUP en el proyecto, se concreta el objetivo, actividades y artefactos construidos para cada fase de la metodología: ini-cialización, elaboración, construcción y transición. Como elemento de apoyo a la metodología, también se puntualiza los diagramas UML utilizados para el modelamiento del sistema. Dado que los cantidad de artefactos elegidos de RUP y formalizados con UML es muy extensa, se denen los más relevantes de cada fase.
En el capítulo 6 se detalla el desarrollo del proyecto, se encuentran de los artefactos de-nidos en el anterior capítulo para cada fase: en la fase de inicialización, se encuentra la denición de los requerimientos y su formalización en los casos de uso del sistema. Durante su denición paralelamente se construye el modelo de dominio, el cual contiene la terminología que se manejará para cada elemento, rol, actividad, tarea y producto del sistema. En este ca-pítulo se plantea la aplicación bajo el modelo SaaS. En la fase de elaboración, se describe la arquitectura en la cual se centra el sistema; para la construcción de la arquitectura del sistema se implementa el modelo de vista de la arquitectura 4+1[18]. En la fase de construcción, se profundiza en el diseño e integración del producto para esto se muestra el diseño de las clases del aplicativo y sus componentes. En la fase de transición, se detalla el despliegue de la funcionalidad en el plataforma PaaS del proveedor en la nube.
Para nalizar, en el capítulo 7 encontrará las conclusiones que involucran: la industria del transformador, el modelo de la nube, la metodología del proyecto RUP, el lenguaje UML y 4Empresa consultora creadora de la metodología RUP para el despliegue, diseño, construcción, pruebas y
Resumen 12
1. PLANTEAMIENTO DEL PROBLEMA
1.1. DESCRIPCIÓN DEL PROBLEMA
En Colombia, las empresas encargadas de la fabricación, reparación y mantenimiento de transformadores serie 15Kv requieren un documento donde se informe si los transformadores que salen de la fábrica (nuevos, para reparación o mantenimiento) cumplen con los estánda-res nacionales e internacionales. Este documento se denomina protocolo de pruebas, el cual contiene los siguientes datos del equipo: identicación del transformador, características físi-cas, de construcción e incluye los resultados de las pruebas de rutina a los que fue sometido [5]. El documento es solicitado por las empresas prestadoras del servicio de energía eléctrica cuando el transformador va a ser instalado en su red eléctrica. Las pruebas registradas en el documento garantizan la eciencia del equipo al ser instalado en la red y el cumplimiento de la normatividad vigente.
Se ha realizado una encuesta (Anexo A) a cuatro actores involucrados en la producción, distribución, instalación y uso del transformador serie 15Kv: fabricante de transformadores, distribuidor de material eléctrico, ingeniero eléctrico o afín y cliente nal. El análisis de los resultados arrojaron las siguientes conclusiones:
1.1.1. Cliente nal
El cliente nal no identica el protocolo de pruebas como un elemento importante cuando adquiere un transformador.
El cliente nal no sabe cómo, ni por qué debe solicitar un protocolo de pruebas.
1.1.2. Distribuidor
No conoce la normatividad respecto al producto: Transformador serie 15Kv.
El responsable del protocolo de pruebas es el proveedor de transformador o el Cliente, no él.
1.1.3. Ingeniero eléctrico o afín
Identica el protocolo como documento importante al adquirir un transformador. Tener acceso al protocolo del transformador ayuda a su labor.
1. PLANTEAMIENTO DEL PROBLEMA 14
1.1.4. Fabricante de Transformadores
El documento es impreso desde el archivo de hoja de cálculo (.xls) y luego archivado, donde para solicitar una copia del documento se debe sacar copia física del mismo. El nivel de seguridad para el acceso a la hoja de cálculo que genera el documento es bajo o nulo, debido a que todas las personas de la organización tienen acceso a este.
No existe una herramienta para llevar un seguimiento de las variables del negocio: ventas, clientes y garantías.
Cuando el transformador es tipo mantenimiento (de segunda), no se puede vericar el historial del mismo.
No hay un procedimiento de respaldo de la información.
1.2. FORMULACIÓN DEL PROBLEMA
2. JUSTIFICACIÓN
La dicultad en la accesibilidad y disponibilidad del protocolo de pruebas, es uno de los aspectos que más afecta a los actores involucrados en el proceso de fabricación, mantenimiento y venta del transformador eléctrico. El proyecto plantea el desarrollo de una aplicación web con las siguientes funcionalidades generales:
Consulta web del protocolo donde el interesado: cliente, ingeniero, distribuidor o re-presentante de empresa de energía podrá acceder directamente al documento, de forma inmediata y segura.
Durante las etapas de los procesos de fabricación, reparación o mantenimiento el apli-cativo permitirá hacer seguimiento del estado del transformador (4.2.9). Actualmente durante los procesos de fabricación, reparación y mantenimiento el desarrollo del pro-tocolo de pruebas para transformadores serie 15Kv se realiza al nalizar cada uno, de esta manera se corre el riesgo que el equipo falle o no cumpla los requerimientos de las pruebas[6] durante el despacho del equipo. La aplicación plantea un módulo de se-guimiento para cada uno de los procesos, donde se hará la vericación del equipo en las etapas críticas, por ejemplo el ensamble de la bobina con el núcleo y la prueba de medición de la resistencia de los devanados[3].
Adicional al seguimiento de cada proceso, el aplicativo permitirá realizar seguimiento al equipo después de salir de la fábrica. Así mismo permitirá realizar un seguimiento al cliente para vericar información como garantía1 y tiempo de mantenimiento2.
La aplicación desarrollada permite el almacenamiento digital de la información, además de ofrecer un procedimiento de respaldo para reducir el riesgo de pérdida de la misma. El modelo de datos diseñado para la aplicación permitirá generar reportes de acuerdo a los requerimientos. Así mismo el ingeniero encargado de las pruebas de transformadores tendrá una herramien-ta que permitirá diligenciar el documento en campo, gracias al ambiente web. La aplicación le mostrará un formulario intuitivo que dará rapidez y exactitud a la captura de datos durante pruebas.
Las anteriores prestaciones de la aplicación web que se desarrollarán durante el proyecto, están planteadas bajo el modelo de servicio PaaS de la plataforma de computación en la nube. De esta manera el proyecto mostrará la aplicabilidad de la computación en la nube como plataforma objetivo y por medio de un formulario intuitivo que dará rapidez y exactitud a la captura de datos durante pruebas.
1Un transformador puede tener garantía de 12 hasta 36 meses dependiendo del tipo de transformador, los
transformadores serie 15Kv se manejan garantías de 18 meses.
2Un transformador se le realiza mantenimiento entre 3 y 5 años dependiendo de las condiciones atmosféricas
2. JUSTIFICACIÓN 16
3. OBJETIVOS
3.1. OBJETIVO GENERAL
Análisis y desarrollo de una aplicación web para la gestión de protocolos de pruebas para transformadores serie 15Kv, implementando el modelo de servicio SaaS (software como servi-cio) de la plataforma de computación en la nube, siguiendo la norma NTC 1358: Protocolo de Pruebas para Transformadores.
3.2. OBJETIVOS ESPECÍFICOS
Implementar un sistema de autenticación para los usuarios de la aplicación por medio de un control de acceso.
Implementar un sistema para la administración de roles y perles de usuarios para la gestión de los mismos dentro de la aplicación.
Desarrollar el módulo para diligenciamiento del protocolo de pruebas del transformador serie 15Kv durante los procesos de fabricación, reparación y mantenimiento donde se garantice el registro y seguimiento de las pruebas durante las etapas críticas de cada uno (4.2.9).
Desarrollar un módulo para consulta de protocolo de pruebas de transformadores serie 15Kv, permitiendo accesibilidad al usuario interesado desde cualquier navegador web. Desarrollar un módulo de seguimiento para el transformador serie 15Kv, el cual permitirá vericar el historial del equipo después de salir de producción.
Desarrollar un módulo de seguimiento del cliente donde se pueda vericar la condición de los productos, por ejemplo cuando los equipos adquiridos por un cliente requieran mantenimiento.
Implementar una aplicación web utilizando el modelo de servicio SaaS, demostrando la factibilidad de futuras implementaciones.
Desarrollar interfaces grácas de usuario que ayuden en la experiencia de interacción entre el aplicativo y el usuario en dispositivos móviles.
3. OBJETIVOS 18
4. MARCO REFERENCIAL
4.1. ANTECEDENTES o ESTADO DEL ARTE
Aunque el concepto de computación en la nube es relativamente nuevo en Colombia, existen varios trabajos que han sido implementados en el país. A continuación se mencionan algunos de ellos.
4.1.1. Históricos
Aunque el concepto de computación en la nube (Cloud Computing) es reciente a nivel mundial, su primera concepción la encontramos en los años 50 con el cientíco canadiense Her-bert Grosch[32] y su Ley Grosch1. Una de las conclusiones de la ley de Grosch era la eciencia resultante al centralizar el procesamiento de información en grandes centros de procesamiento aprovechando la infraestructura, su gran escala y el uso masivo por terminales nales. A partir de lo anterior la computación en la nube se presenta como un conjunto de grandes centros de computación donde se prestan servicios informáticos a los usuarios. Otra concepción de computación en la nube es como un servicio público, esta propiedad es dada por el cientíco estadounidense John McCarthy[21]. Según McCarthy el poder de procesamiento tendría un cobro como de los servicios de luz o agua. Para 1966 [27], el investigador canadiense Douglas Parkhill presentó lo que hoy en día dene la computación en la nube [37], el poder de cómputo como un sistema que permite el acceso masivo de usuarios, cobro del servicio por demanda, elasticidad según la necesidad del cliente y garantía por parte de proveedor del acceso, cada vez, en las mismas condiciones de uso. A medida que la computación evoluciona y surgen tecnologías como el sistema operativo, el microprocesador, el computador personal, etc.; ca-da una de ellas fueron estableciendo la bases de la computación en la nube, pero fue con el surgimiento de Internet que se da el ecosistema para el desarrollo y viabilidad, gracias a la universalidad y distribución de información basada en protocolos abiertos de comunicación, se concibe la Internet como una nube de acceso público. Entre las primeras estructuras de la computación en la nube para la prestación de servicios en la nube está Amazon Web Service (AWS) lanzado en 20062. En AWS encontramos servicios de almacenamiento de datos, base de datos transaccionales, redes (VPN), etc.; todos los servicios caracterizados por una estructura escalable, segura, rápida, económica y simple. Estos servicios están pensados en empresas u organizaciones con requerimientos masivos. Otras grandes empresas de la informática están participando en este mercado con sus propias plataformas:
Microsoft: Azure Services Platform [33]
1La ley enunciaba que el poder de computación aumentaba el cuadrado del costo de su producción, de tal
manera para ser 10 veces más económico se debía trabajar 100 veces más rápido, publicada en 1950.
4. MARCO REFERENCIAL 20
Google: Google App Engine3
Oracle: Oracle Cloud Computing [10]
4.1.2. Legales
Actualmente no existen leyes para la implementación, control y seguimiento de este mo-delo en Colombia, a nivel mundial muy pocas organizaciones están adelantando este tema. Por otro lados diferentes compañías a nivel mundial se unieron para crear la Cloud Security Alliance (CSA), donde se debaten las buenas prácticas para garantizar la seguridad y priva-cidad en el entorno del Cloud Computing, adicional ofrece un certicado Cloud Security Knowledge para establecer el nivel de conocimiento en seguridad, arquitectura, operaciones, encripción, vitualización, etc. Esta organización está divida en capítulos, grupos de miembros de un país que desean extender estas prácticas en su región. A continuación los datos del capítulo colombiano.
Título Proyecto: UnaCloud - Opportunistic Cloud Computing Infrastructure as a Service Model [31]
Objetivo: Desarrollar un modelo IaaS de computación en la nube, que entregue recursos y servicios computacionales fundamentales, soportándose en una infraestructura compu-tacional oportunista de crecimiento horizontal.
Modelo Cloud: Cloud IasS
Proveedor: Plataforma propia Universidad de los Andes.
Universidad de los Andes
Título Proyecto: Study and customization proposal for SaaS business model to Colom-bian SME needs [14]
Objetivo: En este artículo se explora el modelo de servicio del Software as a Service (SaaS) como una nueva forma de entregar TICs (tecnología de información y comunica-ciones) a las PyMes colombianas. El resultado nal es una caracterización del compor-tamiento de la población objetivo frente a propuestas de valor basadas en servicios. Modelo: Cloud SaaS
3Plataforma PaaS de Google, es un servicio de alojamiento web que presta Google de forma gratuita, este
4. MARCO REFERENCIAL 21
Universidad Católica del Norte - INGENIUS-Group S.A.S
Título Proyecto: Comparación de herramientas para el desarrollo de librerías enfocadas a aplicaciones web [20]
Objetivo: En este artículo de investigación presenta el proceso de desarrollo de cinco Applications Programing Interfaces (API): generación de documentos, generación de grácas, validaciones, internacionalización y multimedia, para aplicaciones web bajo ar-quitectura Cloud Computing. Para el proceso de desarrollo de cada API se realizaron consultas de herramientas, tecnologías y librerías, comparando sus ventajas y desventa-jas, teniendo en cuenta que el desarrollo cumpliera con las características establecidas para cada una de éstas, con el n de contribuir a la funcionalidad en la generación de reportes, grácas y validaciones de campos en la captura de información, para proyectos Cloud Computing.
Modelo: Cloud SaaS
4.2. MARCO TEÓRICO
4.2.1. Implementación de la computación en la nube
Existen tres escenarios de implementación de la computación en la nube: Nube Privada, Nube Pública e Nube Híbrida. Son escenarios que se han vuelto altamente atractivos para el intercambio computacional [8], de recursos de red y almacenamiento entre desarrolladores de servicios múltiples y aplicaciones de prestación de servicios [11].
Nube Privada: En este escenario las compañías procesan sus datos fuera de línea, las aplicaciones son ejecutadas de una manera segura en Datacenters. Las ventajas que posee son: Disponible en demanda, rápido aprovisionamiento de negocio, reducción del costo a través de economías de escala, exibilidad y libertad de selección, basado en el uso, controlado y asegurado por la corporación IT.
Nube Pública: Este escenario se presenta cuando la empresa necesita mover sus aplica-ciones o datos desde su interior hacia el exterior, de esta manera el escenario público se conecta con otros escenarios. Esto involucra la necesidad de adquisición de recursos de IT que son vendidos [7]. Bajo este escenario se pueden ejecutar varios tipos de servicios que van a ser explicados más adelante.
4. MARCO REFERENCIAL 22
Figura 4.1: Arquitectura de computación en nube
Fuente ESPINO, Luis. Artículo Cloud Computing como una red de servicios.
4.2.2. Arquitectura de computación en la nube
La computación en la nube nos ofrece una nueva plataforma para la prestación de servicios, orientado a la escalabilidad, donde podamos atender una demanda muy grande por parte de usuarios en la prestación de un servicio; pero de manera muy directa , inmediata en el tiempo, con un impacto en el coste y la gestión que es casi plano.
Las capas se encuentran altamente acopladas, para poder ofrecer un funcionamiento co-rrecto, además de ser similar a la arquitectura de red, se inicia desde un nivel físico hasta un nivel de aplicación, debido a que la computación en la nube maneja protocolos similares a lo que se usa en el Internet como medio de comunicación [34].
Recursos físicos: incluyen elementos como servidores, almacenamiento y red. Virtualización: incluye infraestructura virtual como un servicio.
Infraestructura: incluye software de plataforma como servicio. Plataforma: incluye componentes de aplicación como servicio.
Aplicación: incluye servicios basados en web y software como servicio.
4.2.3. Características esenciales
Autoservicio por demanda: El usuario puede requerir el aprovisionamiento de servi-cios de computo, como tiempo de servicio y almacenamiento en red, esta es soportada automáticamente por la plataforma sin interacción humana.
4. MARCO REFERENCIAL 23
Recursos compartidos: Para el usuario es transparente la arquitectura física o virtual de la plataforma, así como los procesos para el almacenamiento, procesamiento, memoria y ancho de banda que es compartido por los demás usuarios.
Rápida elasticidad: La capacidad puede ser automáticamente aprovisionada o retira-da, en algunos casos automáticamente, para escalar rápidamente las demás solicitudes demandas.
Servicio Medido: Los servicios aprovisionados al cliente deben ser medibles, para ade-más de ser facturados también ser monitoreados, registrados y proveer información ad-junta al proveedor, ejemplo: el consumo de servicio utilizado.
4.2.4. Modelos de Servicio de la computación en la nube
En el cuadro 4.1 se describen los modelos de servicio que componen el la computación en la nube: IaaS, PaaS, SaaS.
4.2.5. Software como servicio SaaS
El modelo de servicio SaaS busca integrar los elementos de un sistema de información y los procesos de gestión: por ejemplo mantenimiento, en un servicio vía web para acceder al sistema (GOMEZ et al, 2009:7-8).
4.2.5.1. Ventajas [12]
Los clientes no necesitan instalar la aplicación, ni preocuparse por requerimientos de hardware para la ejecución.
El cliente no debe preocuparse por el almacenamiento de los datos ni de los demás procesos de mantenimiento, por ejemplo copias de seguridad.
De acuerdo al diseño de la aplicación se puede garantizar acceso a un colectivo y com-partir la misma información.
Tiene acceso a gran cantidad de datos, principalmente los de consulta y actualización frecuente, el acceso vía SaaS es más práctico.
Una única copia del software es ejecutada en el servidor, permitiendo que las caracterís-ticas de equipo sean las requeridas por el desarrollador.
La actualización del software es directo, esta se realiza desde la nube sin necesidad de descargar archivo alguno. Siendo necesario la autorización del cliente.
4.2.5.2. Características [30]
Disponibilidad vía web: Acceso a través de un navegador web usando estándares abiertos.
4. MARCO REFERENCIAL 24
Tabla 4.1: Modelos de servicio de la computación en la nube Modelos Software As A
Service Plataform As AService Infrastructure As AService Características Las aplicaciones
Cobro basado en el uso: El cliente solo paga por la partes del servicio que use.
Demanda de TI mínimo: El cliente solo tiene acceso al servicio, por lo tanto no necesita preocuparse por deniciones técnicas de infraestructura.
4.2.6. Metodología RUP - Rational Unied Process [35]
4. MARCO REFERENCIAL 25
4.2.6.1. Dimensiones de RUP:
RUP es una metodología que maneja 2 dimensiones, representadas en la gura 4.2: En su eje horizontal se encuentra representado el tiempo y muestra los aspectos del ciclo de vida del proceso.
En su eje vertical encontramos las diferentes especialidades que se agrupan por activi-dades denidas de acuerdo a su naturaleza. En la imagen que se muestra a continuación podemos ver el enfoque de cada una de las disciplinas con respecto al tiempo y durante cada una de las fases.
Figura 4.2: Fases de la metodología RUP
Fuente Rueda, Julio César. Aplicación de la metodología RUP para el desarrollo rápido de aplicaciones basado en el estándar J2EE.
4.2.6.2. Características esenciales:
Dentro del proceso de desarrollo de RUP se menciona 3 características que son esenciales y están bien denidas:
Proceso dirigido por casos de uso: Utiliza los Casos de Uso para el desarrollo y manejo de las especialidades con los artefactos, roles y actividades necesarias. El soporte principal en la implementación de las fases y especialidades del RUP son los Casos de Uso. Un Caso de Uso es una representación de una unidad discreta de trabajo realizada por un usuario (u otro sistema) usando el sistema en operación [36], está relacionado con los requerimientos y conlleva a su desarrollo e implementación.
4. MARCO REFERENCIAL 26
Figura 4.3: Ciclo de vida del software en RUP
Fuente www.elbenyito.blogspot.com. Modelo RUP (Rational Unied Process)
Una de las ventajas de este modelo es que podemos ir entregando pequeños avances al cliente, de esta manera se puede ir realizando pruebas mientras se avanza en otras etapas del proyecto, el proyecto crece de una manera más rápida hasta poder completarlo en su totalidad.
Proceso centrado en la arquitectura: Este proceso dene los elementos que son de más importancia dentro del sistema. Está inuenciado entre otras por plataformas de software, sistemas operativos, motores de bases de datos, protocolos, consideraciones de desarrollo como sistemas no heredados y requerimientos no funcionales. A medida que avanzamos, RUP realiza una serie de mejoras sucesivas en una arquitectura ejecutable, creada como un prototipo evolutivo.
4.2.6.3. Fases de RUP
El ciclo de vida del software de RUP se divide en 4 fases,4.3 gura . Cada una de las fases tiene unos objetivos y puntos de control que nos ayudan a determinar si lo que estamos haciendo cumple con las expectativas y así mismo poder evaluarlo y poder pasar a la fase siguiente del proyecto. Las siguientes son las fases sobre las cuales se establece RUP:
Inicio: Durante esta etapa planteamos una serie de preguntas: ¾Cuál es el objetivo? ¾Es factible? ¾Lo compramos o lo construimos? ¾Cuánto va a costar?, estas son solo algunas de las preguntas que debemos contestar y así poder determinar la viabilidad del proyecto.
Los objetivos son:
Establecer el ámbito del proyecto y sus límites.
Encontrar los casos de uso críticos del sistema, los escenarios básicos que denen la funcionalidad.
Mostrar al menos una arquitectura candidata para los escenarios principales. Estimar el coste en recursos y tiempo de todo el proyecto.
4. MARCO REFERENCIAL 27
Los productos de la fase de inicio deben ser: Lista de requerimientos funcionales y actores. Lista de requisitos no funcionales.
Modelo de casos de uso.
Glosario: Terminología clave del dominio Lista de riesgos y planes de contingencia.
Prototipos exploratorios para probar conceptos o la arquitectura candidata. Plan de iteración para la primera iteración de la fase de elaboración.
Plan de fases.
Al terminar la fase de inicio se deben comprobar los criterios de evaluación para continuar: Todos los interesados en el proyecto coinciden en la denición del ámbito del sistema y las estimaciones de agenda.
Entendimiento de los requisitos, evidenciado por la delidad de los casos de uso princi-pales.
Las estimaciones de tiempo, coste y riesgo son creíbles.
Comprensión total de cualquier prototipo de la arquitectura desarrollada. Los gastos son similares a los planeados.
Si el proyecto no pasa estos criterios es necesario replantearlo o abandonarlo.
Elaboración: El propósito de la fase de elaboración es analizar el dominio del pro-blema, establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos.
Cuando se termina esta fase se llega a un camino de no retorno del proyecto: a partir de ese momento pasamos de las fases relativamente ligeras y de poco riesgo, las 2 primeras, a afrontar la fase de construcción, costosa y arriesgada. Es por esta razón que la fase de elaboración es de gran importancia.
En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en itera-ciones sucesivas hasta convertirse en el sistema nal. Este prototipo debe contener los casos de uso críticos identicados en la fase de inicio. También debe demostrarse que se han evitado los riesgos más graves, bien con este prototipo, bien con otros de usar y tirar.
Los objetivos de esta fase son:
4. MARCO REFERENCIAL 28
Crear un plan able para la fase de construcción. Este plan puede evolucionar en sucesivas iteraciones. Debe incluir los costes si procede.
Demostrar que la arquitectura propuesta soportará la visión con un coste razonable y en un tiempo razonable.
Al terminar deben obtenerse los siguientes productos:
Un modelo de casos de uso completo al menos hasta el 80 %, todos los casos y actores identicados, la mayoría de los casos desarrollados.
Requisitos adicionales.
Descripción de la arquitectura software. Un prototipo ejecutable de la arquitectura. Lista de riesgos y caso de negocio revisados. Plan de desarrollo para el proyecto.
Un caso de desarrollo actualizado que especica el proceso a seguir. Posiblemente un manual de usuario preliminar
La forma de aproximarse a esta fase es deniendo todo el proyecto con la profundidad mínima. Sólo se profundiza en los puntos críticos de la arquitectura o riesgos importantes.
En la fase de elaboración se actualizan todos los productos de la fase de inicio: el glosario, el caso de negocio, etc.
Los criterios de evaluación de esta fase son los siguientes: La protección de la vida y la salud humana.
La visión del producto es estable.
La arquitectura es estable. Se ha demostrado mediante la ejecución del prototipo que los principales elementos de riesgo han sido abordados y resueltos.
El plan para la fase de construcción es detallado y preciso. Las estimaciones son creíbles. Todos los interesados coinciden en que la visión actual será alcanzada si se siguen los planes actuales en el contexto de la arquitectura actual.
Los gastos hasta ahora son aceptables, comparados con los previstos.
4. MARCO REFERENCIAL 29
Construcción: La funcionalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma incremental a través de las sucesivas iteraciones.
Durante esta fase todas los componentes, características y requisitos, que no lo hayan sido hecho hasta ahora, han de ser implementados, integrados y probados, obteniéndose una versión del producto que se pueda poner en manos de los usuarios (una versión beta). El énfasis en esta fase está en controlar las operaciones realizadas, administrando los recursos ecientemente, de tal forma que se optimicen los costes, los calendarios y la calidad.
Los objetivos de esta fase son:
Minimizar los costes de desarrollo mediante la optimización de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo.
Conseguir versiones funcionales (alfa, beta y otras versiones de prueba) tan rápido como sea práctico.
Los productos de la fase deben ser:
Modelos completos (Casos de Uso, Análisis, Diseño, Despliegue e Implementación) . Arquitectura íntegra (mantenida y actualizada) .
Riesgos presentados mitigados.
Plan del proyecto para la fase de transición. Manual inicial de usuario (con suciente detalle). Prototipo operacional beta.
Transición: La nalidad de la fase de transición es poner el producto en manos de los usuarios nales, por lo tanto requerirá desarrollar nuevas versiones actualizadas del producto, completar la documentación, entrenar al usuario en el manejo del producto, en general tareas relacionadas con el ajuste, conguración, instalación y uso del producto.
Los principales objetivos de esta fase son:
Conseguir que el usuario se valga por sí mismo.
Un producto nal que cumpla con los requerimientos esperados y satisfaga las necesidades del usuario.
Los productos de esta fase son: Prototipo operacional Documentos legales
4. MARCO REFERENCIAL 30
Descripción de la arquitectura completa y corregida.
Las iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva versión. Las actividades a realizar durante las iteraciones dependerán de su nalidad, si es corregir algún error detectado, normalmente será suciente con llevar a cabo los ujos de trabajo de imple-mentación y pruebas, sin embargo, si se deben añadir nuevas características, la iteración será similar a la de una iteración de la fase de construcción. La complejidad de esta fase depende totalmente de la naturaleza del proyecto, de su alcance y de la organización en la que deba implantarse.
No todos los productos para cada fase son obligatorios ni deben cumplirse al 100 %, hay que tener en cuenta el objetivo de cada fase.
4.2.7. Lenguaje de Modelado UML - Unied Modeling Languages[13]
UML se ha convertido en uno de los lenguajes de modelado más extendidos para el diseño orientado a objetos. Construido a partir las investigaciones de James Rumbaugh (OMT4), Grady Booch (Técnica Booch5) y Ivar Jacobson (OOSE6).
UML surgió como una propuesta para:
Estandarizar un lenguaje de modelado orientado a objetos sobre el proceso de desarrollo. Generar conceptos de modelado dentro de la comunidad orientada a objetos.
Ofrecer una semántica para el modelamiento de software en diferentes circunstancias.
4.2.7.1. Componentes UML
Los componentes de UML representan las diferentes perspectivas (vistas) del sistema, a partir de diagramas especícos utilizando elementos de modelado comunes.
Vista: Una vista es una abstracción construida a partir de una serie de diagramas. Cada vista muestra un aspecto particular del sistema y su conjunto la imagen completa del sistema. El sistema es descrito a partir de aspectos funcionales (estructura y comportamiento) y no funcionales (requerimientos de tiempo, conabilidad, despliegue, etc.). Las vistas son:
Vistas de Casos de Usos: El sistema percibido por los actores externos (usuarios). Vista Lógica: Describe el diseño funcional del sistema.
Vista Componentes: Describe la organización de los componentes de código.
Vista de Procesos: Muestra la concurrencia de los elementos del sistema, validando la comunicación y sincronización.
4Object-modeling technique técnica aplicada para el análisis orientado a objetos (OOA) basado en
reque-rimientos funcionales del sistema, qué hace el sistema.
5Aplicado en el diseño orientado a objetos (OOD), busca detallar cómo será el funcionamiento del sistema. 6El método de nominado Ingeniería de Software Orientada a Objetos está basado en el concepto de caso de
4. MARCO REFERENCIAL 31
Vista de Despliegue: Muestra el despliegue del sistema en una ambiente físico entre computadoras y nodos.
Diagramas: Permiten describir el contenido de una vista. UML presente dos tipos de dia-gramas: estructural y comportamiento. Un diagrama puede ser parte de varias vistas, depende del contenido del diagrama. Algunos diagramas son:
Diagrama de Casos de Uso: Es la representación gráca de todos los actores, casos de uso e interacciones, identicados para el sistema.
Diagrama de Clase: Muestra una agrupación de elementos de modelado declarativo (estáticos), tales como clases, tipos y sus contenidos y relaciones.
Diagrama de Estados: Extiende la denición de una clase detallando los posibles estados que pueda tener un objeto, a partir de los eventos que se generan. Si el cambio de estado es generado por otro objeto, esto se debe a un mensaje. El cambio de estado se denomina transición.
Diagrama de Secuencia: Representa una colaboración dinámica entre objetos, po-niendo el foco en la secuencia de los mensajes que se intercambian, junto con las corres-pondientes ocurrencias de eventos a medida pasa el tiempo durante la secuencia. Diagrama de Actividades: Representa los procesos de negocios de alto nivel, incluidos el ujo de datos. Es utilizado para describir las actividades en una operación; el diagrama consiste de estados de acción (especicación de la actividad a realizar), un estado de acción se dene al terminar una acción.
Diagrama de Componentes: Representa la estructura física del código en términos de los componentes de código, tales como: los componentes, sus relaciones, interacciones y sus interfaces públicas.
Diagrama de Despliegue: Muestra la arquitectura física del sistema (hardware y software). Las máquinas físicas y los procesadores se representan como nodos y la cons-trucción interna puede ser representada por nodos o artefactos embebidos.
Diagrama de Comunicación: Es un diagrama que enfoca la interacción entre líneas de vida, donde es central la arquitectura de la estructura interna y cómo ella se corresponde con el pasaje de mensajes. La secuencia de los mensajes se da a través de un esquema de numerado de la secuencia.
Elementos: Los elementos representan conceptos orientados a objetos, tales como clase, objeto, estado, caso de uso, nodo, interfaz, paquete, nota, componente, actor, señal y mensaje. Un elemento puede ser usado en diferentes diagramas, sin variar su signicado. Un ele-mento de modelado tiene una denición semántica, la cual permite que su signicado no sea ambiguo. Así mismo un elemento tiene su representación gráca o símbolo gráco utilizado para ser asignado a su respectivo diagrama.
4. MARCO REFERENCIAL 33
Dispositivo eléctrico estático que consta de un devanado, o dos o más devanados con o sin núcleo magnético para introducir un acoplamiento mutuo entre circuitos eléctricos. Los transformadores son usados en sistemas eléctricos de potencia para transferir potencia por inducción electromagnética entre circuitos de la misma frecuencia, usualmente con cambios de tensión y corriente.
4.2.8.2. Clasicación
La clasicación del transformador involucra muchos aspectos, el proyecto se desarrollará basado en las siguientes tres clasicaciones, por tamaño y refrigeración sujetas a la norma NTC 317, según la tensión manejada por el transformador [29]:
Tabla 4.2: Clasicación de transformadores por tamaño
Tipo Descripción
Transformador
Distribución Transformador para transferir energía de un circuito de distribuciónprimario hasta un circuito de distribución secundario o circuito de servicio al consumidor. Los transformadores de distribución están usualmente entre 5 kVA y 500 kVA.
Transformador
Potencia Transformador que transere energía eléctrica en cualquier parte delcircuito entre el generador y los circuitos de distribución primaria.
Tabla 4.3: Clasicación de transformadores por aislamiento
Tipo Descripción
Transformador sumergido en
líquido
Transformador en el cual el núcleo y las bobinas están sumergidos en un líquido aislante.
Transformador
tipo Seco Transformador en el cual el núcleo y las bobinas están en un medio decomposición aislante seco o gaseoso.
Tabla 4.4: Clasicación de transformadores por tensión de alimentación
Tipo Descripción
Transformador
tipo 15kv Transformadores que manejan tensiones inferiores a 15.000 voltios Transformador
tipo 34,5kv Transformadores que manejan tensiones superiores a 15.000 voltioshasta 34.500 voltios
4.2.9. Procesos para transformadores serie 15Kv
4. MARCO REFERENCIAL 35
Figura 4.7: Proceso de reparación de transformador serie 15Kv
Diagrama basado en documentación suministrada por la empresa fabricante de transformadores Bobinados Técnicos Ingeniería Electrónica.
Figura 4.8: Proceso de mantenimiento de transformador serie 15Kv.
Diagrama basado en documentación suministrada por la empresa fabricante de transformadores Bobinados Técnicos Ingeniería Electrónica.
4.2.10. Protocolo de prueba para transformadores
4. MARCO REFERENCIAL 36
4.2.10.1. Informativa: Incluye los datos descriptivos del transformador iniciales, así como los datos del fabricante y del cliente.
4.2.10.2. Pruebas de Régimen Nominal: en el cuadro 4.5 se enlistan las pruebas que se deben realizar al transformador serie 15Kv cuyos resultados se registran en el protocolo de pruebas para transformador serie 15Kv. Estas pruebas se denomina ensayos de rutina según la norma NTC 380: Transformadores eléctricos. Ensayos eléctricos. Generalidades [6].
Tabla 4.5: Ensayos de rutina
Ensayo eléctrico Norma aplicable
para ejecutar el ensayo Medición de la resistencia de los devanados NTC 375 Medición de la relación de transformación, vericación de
polaridad y relación de fase NTC 471
Medición de tensión de cortocircuito NTC 1005
Medición de pérdidas con carga NTC 1005
Medición de la pérdidas y corriente sin carga (en vacío) NTC 1031
Tensión aplicada NTC 837
Sobre-tensión inducida NTC 837
Fuente ICONTEC. NTC 380 Transformadores eléctricos. Ensayos eléctricos. Generalidades.
En el cuadro 4.6 se muestra las demás pruebas realizadas a los componentes de un trans-formador serie 15Kv.
Tabla 4.6: Ensayos adicionales para transformador serie 15Kv
Ensayo Norma aplicable
para ejecutar el ensayo Especicaciones para aceites minerales nuevo. Aislantes,
para transformadores, interruptores y equipos eléctricos NTC 1465 Pinturas para tanques de transformadores NTC 3396
4.2.10.3. Características físicas del transformador: Características mecánicas
Dimensiones externas del Transformador. Pintura.
4. MARCO REFERENCIAL 38
4.2.12.1. Objetos:
Podemos denir objeto como el "encapsular de un conjunto de operaciones (métodos) que pueden ser invocados externamente, de un estado que recuerda el efecto de los servicios" [Piattini et al., 1996].
Un objeto presenta un estado interno, una interfaz para la interacción con el exterior. Se dice por esto que en la programación orientada a objetos "se unen datos y procesos", no como en su predecesora la programación estructurada, donde estaban separados en forma de variables y funciones.
Un objeto consta de:
Tiempo de vida: El ciclo de vida de un objeto en un programa siempre está limitado por el tiempo. Gran parte de los objetos sólo existen durante parte de la ejecución del programa. Los objetos se crean mediante un mecanismo denominado ejemplicación, cuando dejan de existir se dice que son destruidos.
Estado: Todos los objetos poseen un estado, denido por sus atributos. Con él se denen todas sus propiedades y el estado en que se encuentra en un determinado momento. Comportamiento: Todo objeto presenta una interfaz, denida por sus métodos, para que el resto de objetos que componen los programas interaccionen con él.
El equivalente de un objeto en el paradigma estructurado sería una variable. Así mismo la ejemplicación de objetos equivaldría a la declaración de variables y el tiempo de vida de un objeto al ámbito de una variable.
4.2.12.2. Clases:
Son abstracciones que representan a un grupo de objetos con un comportamiento e interfaz común.
Podemos denir una clase como "un conjunto de cosas (físicas o abstractas) que tienen el mismo comportamiento y características... Es la implementación de un tipo de objeto (consi-derando los objetos como instancias de las clases)".
Una clase es una plantilla para la creación de objetos. Cuando se crea un objeto (ejem-plicación) se ha de especicar de qué clase es el objeto instanciado, para que el compilador comprenda las características del objeto. Las clases presentan el estado de los objetos a los que representan mediante variables denominadas atributos. Cuando se genera un ejemplar de un objeto el compilador crea en la memoria dinámica un espacio para tantas variables como atributos tenga la clase a la que pertenece el objeto.
4.2.12.3. Métodos:
Representan el comportamiento de los objetos. En dichos métodos se modican los valores de los atributos del objeto, representan las capacidades del objeto.
4. MARCO REFERENCIAL 39
4.2.12.4. Modelo de objetos:
Existen una serie de principios fundamentales para comprender cómo se modela la realidad al crear un programa bajo el paradigma de la orientación a objetos. Estos principios son: abstracción, encapsulado, modularidad, jerarquía, paso de mensajes y polimorsmo, cuadro 4.7.
Tabla 4.7: Principios para modelamiento de objetos Principio Descripción
Abstracción Por medio de la abstracción, la mente humana modela la realidad en forma de objetos. Buscando similares entre la realidad y la posible implementación de objetos del programa que simulen el funcionamiento de los objetos reales.
Encapsulado El encapsulado permite a los objetos elegir qué información es publicada y qué información es ocultada al resto de los objetos. Para ello los objetos suelen presentar sus métodos como interfaces públicas y sus atributos como datos privados e inaccesibles desde otros objetos. Modularidad Mediante la modularidad, el programador divide su aplicación en varios
módulos diferentes (clases, paquetes o bibliotecas), cada uno de ellos con un signicado propio. Esta fragmentación disminuye el grado de dicultad y complejidad de la solución.
Jerarquía Las distintas clases de un programa se organizan mediante la jerarquía. La representación de dicha organización da a lugar de la herencia. La herencia permite a una clase hija tomar determinadas propiedades de una clase padre.
Paso de Mensajes Un objeto puede solicitar de otro objeto que realice una acción determinada o que modique su estado. El paso de mensajes se suele implementar como llamadas a los métodos de otros objetos.
Polimorsmo De acuerdo al contexto el objeto puede tener diferentes comportamientos
4.2.12.5. Relaciones entre objetos:
4. MARCO REFERENCIAL 40
Tabla 4.8: Relaciones entre objetos
Relación Descripción
Asociación Un objeto realiza llamadas a los métodos de otro objeto.
Todo/Parte Cuando una entidad existe por conjunción/composición de otras. De dicha relación surgen otras dos relaciones: agregación y/o composición. Generalización /
Especialización Cuando se puede destacar características comunes entre dos objetos. Lageneralización y la especialización son diferentes perspectivas, la generalización tiene una perspectiva ascendente, mientras que la
especialización tiene una perspectiva descendente [2].
4.2.13. Arquitectura de aplicaciones en n-capas [9]
El estilo arquitectural en n-capas se basa en una distribución jerárquica de los roles y las responsabilidades para proporcionar una división efectiva de los problemas a resolver. Los roles indican el tipo y la forma de la interacción con otras capas y las responsabilidades la funcionalidad que implementan.
Cuanto más se aumenta el proceso operativo de la empresa, las necesidades de proceso crecen hasta desbordar las máquinas. Es por ello que se separa la estructura de un programa en varias capas [1].
Las capas (tiers) se ocupan de la división lógica de componentes y funcionalidad y no tienen en cuenta la localización, gura 4.10.
Figura 4.10: Arquitectura Tradicional N-Layer (Lógica)
4. MARCO REFERENCIAL 41
4.2.13.1. Características:
Descomposición de los servicios de forma que la mayoría de las interacciones ocurre solo entre capas vecinas.
Las capas de una aplicación pueden residir en la misma máquina o pueden estar distri-buidos en varios equipos.
Los componentes de las capas se comunican de otras capas a través de interfaces bien conocidas.
Cada nivel agrega las responsabilidades y abstracciones del nivel anterior.
4.2.13.2. Principios clave:
Muestra una vista completa del modelo y a la vez proporciona sucientes detalles para entender las relaciones entre capas.
No realiza ninguna suposición sobre los tipos de datos, métodos, propiedades y sus implementaciones.
Separa de forma clara la funcionalidad de cada capa.
Cada capa contiene la funcionalidad relacionadas solo con las tareas de esa capa. Las capas inferiores no tienen dependencias de las capas superiores.
La comunicación entre capas está basado en una abstracción que proporciona un bajo acoplamiento entre capas.
4.2.13.3. Benecios:
Abstracción, ya que los cambios que se realizan a alto nivel y se puede reducir o incrementar el nivel de abstracción que se usa en cada capa del modelo.
Aislamiento, ya que se pueden realizar actualizaciones en el interior de las capas sin que esto afecte el resto del sistema.
Rendimiento, ya que distribuyendo las capas en distintos niveles físicos se puede me-jorar la escalabilidad, tolerancia a fallos y el rendimiento.
Posibilidad de realizar pruebas, ya que cada capa tiene una interfaz bien denida sobre la que realizar las pruebas y la habilidad de cambiar entre diferentes implementa-ciones de una capa.
4. MARCO REFERENCIAL 42
4.2.13.4. Cuando usarlo:
Ya tiene construidas capas de una aplicación anterior, que pueden reutilizarse o integrar-se.
Ya tiene aplicaciones que exponen su lógica a través de interfaces de servicios.
La aplicación es compleja y el alto nivel de diseño requiere la separación para que los distintos equipos puedan concentrarse en distintas áreas de funcionalidad.
La aplicación debe soportar distintos tipos de clientes y distintos dispositivos. Se quiere implementar reglas y procesos de negocio complejos o administrados.
En el cuadro 4.9 se describen cada una de las capas utilizadas para el desarrollo del proyecto [24]: presentación, negocio, acceso a datos y entidad de negocio 7.
Tabla 4.9: Capas utilizadas en el desarrollo del proyecto
Capa Descripción
Presentación La capa de presentación es la más alta en la composición de la arquitectura de la aplicación. Es la parte visible, la que se muestra al usuario y con la que interacciona.
Negocio La capa de lógica de negocio es donde se realizan las reglas del negocio y donde se manipulan los datos devueltos desde la capa de acceso a datos antes de enviarlos a la capa de presentación. Está formada por los objetos de negocio y las clases encargadas de trabajar con dichos objetos.
Acceso a Datos La capa de acceso a datos, es la capa que interactúa con la fuente de datos (base de datos). Su diseño está basado en la creación de una clase por cada entidad en la base de datos.
Entidad de
negocio Para intercambiar información entre la capa de acceso a datos y la delógica de negocio se utilizarán los objetos de negocio. Esta técnica está fundamentada en el patrón DTO (Data Transfer Object) [26].
7Un objeto de negocio se construye a partir de una clase que únicamente contiene propiedades, que se
5. MARCO METODOLÓGICO
5.1. DISEÑO METODOLÓGICO
5.1.1. Tipo de Desarrollo
La naturaleza de este proyecto es de tipo tecnológico, fue necesaria la consulta de material escrito para identicar el marco teórico de la computación en nube y su modelo SaaS, además para la denición del problema se elaboraron entrevistas informales y encuestas. El proyecto se basa en las inconformidades encontradas durante el ujo de información en el proceso de diligenciamiento de los protocolos de pruebas para transformadores serie 15kV. A partir de lo anterior, en el proyecto se desarrolló una aplicación que permita gestionar la información relacionada con el protocolo de pruebas, el producto transformador serie 15kV y el cliente.
5.1.2. Metodología del Desarrollo
Para el desarrollo del software se realizo un análisis de tipo descriptivo y cualitativo en el proceso de diligenciamiento del protocolo de pruebas de transformadores serie 15kV. Primero se identicó la problemática en la generación del protocolo como una tarea con reducido nivel tecnológico, dado que se usa actualmente un documento de excel; adicional se evidenció la necesidad de un sistema de información para el manejo de las siguientes elementos del dominio: transformador, pruebas, protocolo y clientes.
Con esta contexto sobre la mesa se necesitaba una solución que permitiera, por un lado sistematizar el proceso para la gestión del protocolo de pruebas para transformadores serie 15Kv a través de herramientas tecnológicas de software, y por el otro el aplicativo desarrollado debe seguir el modelo servicio SaaS sobre la plataforma PaaS de un proveedor en la nube.
En el proyecto se utilizó RUP4.2.6 como metodología para desarrollo de software, lo que requirió que tanto los requerimientos, como los casos de uso de sistema debían estar totalmente denidos. El seguimiento del ciclo de vida de RUP (requerimientos, análisis y diseño, imple-mentación, pruebas y evaluación) garantiza el renamiento continuo del software (actividades y artefactos) en cada etapa a través de sus iteraciones.
Para la construcción de los artefactos producto de cada fase de RUP se utilizó como lenguaje de modelamiento UML. Este lenguaje posee diagramas y elementos que permiten modelar el sistema dependiendo del contexto: casos de uso, interacción, diseño, despliegue e implementación.
5.1.3. Población Objetivo
5. MARCO METODOLÓGICO 44
Uno de los principales focos de la aplicación web desarrollada durante el proyecto, son las empresas dedicadas a la fabricación, reparación y mantenimiento de transfor-madores de voltaje. Así mismo, puede ser utilizado por ingenieros eléctricos ,o anes, independientes, que presten servicios como: prueba de transformadores en sitio.
La aplicación web sobre la plataforma de computación en nube, ofrecerá acceso tanto a distribuidores de productos eléctricos como a usuarios nales, garantizando portabilidad del protocolo.
El proyecto con su metodología demostrará la factibilidad de modelo de servicio SaaS, planteado un desarrollo como un servicio. Ofreciendo un ejemplo de la aplicabilidad en nuevos proyectos para el estudiantes o ingeniero de Sistemas.
5.1.4. Instrumentos y Equipos
Los formatos utilizados para la recolección de la información serán los siguientes:
5.1.4.1. Formatos de casos de uso:
Dichos formatos permitirán realizar un seguimiento del caso de uso, durante su diseño, desarrollo, implementación, prueba y evaluación. En su descripción debe enfatizar en el alcance.
5.1.4.2. Unidades Lingüísticas UML
UML como lenguaje de modelamiento plantea las siguientes vistas para la representación del software, se detalla los respectivos diagramas que se desarrollarán para cada una:
Vista de casos de uso.
Diagramas de casos de uso.
5. MARCO METODOLÓGICO 45
5.1.5. Procedimiento
Levantamiento de la información: Durante esta etapa el grupo se dedicará a obtener la información necesaria para iniciar el desarrollo del proyecto. Esto se hará mediante la obtención de información en la empresa.
Aplicación de la metodología RUP: En esta etapa se aplicara la metodología RUP, para el análisis, desarrollo e implementación de la aplicación.
Revisión antes de la sustentación nal.
Sustentación y entrega del documento formal del proyecto.
5.2. METODOLOGÍA DE LA INGENIERÍA DEL PROYECTO
La directriz del proyecto está enmarcada principalmente por la norma NTC 1358 para protocolo de transformadores y debido a la criticidad de esta al ser norma nacional, la etapa de análisis del proyecto debe ser rigurosa.
La metodología que se seleccionó para realizar el desarrollo del software para el proyecto es RUP. Desde su etapa inicial RUP plantea un marco claro y robusto para la construcción de software de calidad, además de pautas para desarrollos de software pequeños como grandes proyectos, permitiéndonos focalizar el objetivo del proyecto y cumplimiento de la norma; sin desconocer las demás fortalezas de la metodología misma: desarrollo iterativo, vericación de la calidad y control de cambios en el software.
5.2.1. Descripción de la Metodología en Contexto
A continuación se muestra en detalle cada una de las etapas de la metodología RUP, con los objetivos, actividades y artefactos generados para el proyecto.
5.2.1.1. Fase de Inicialización
En esta primera fase se formaliza la idea del proyecto a desarrollo. Objetivo:
Analizar una aplicación web que permita diligenciar protocolos de prueba para transfor-madores 15kV. Se destaca en esta parte la identicación de los límites del proyecto; ejemplo, Transformadores serie 15kV.
Actividades:
Identicar los requerimientos de los usuarios y las principales limitaciones que se tienen. Identicación de los actores de nuestro sistema y casos de uso.
Iniciar la búsqueda de los casos de uso críticos en el sistema. Estructurar el modelo de casos de uso.
5. MARCO METODOLÓGICO 46
Artefactos:
Lista de requerimientos. Lista de actores.
Modelo de dominio. Casos de uso de alto nivel.
5.2.1.2. Fase de elaboración
Para esta fase se dene la arquitectura y se establecen los requisitos que describirán el sistema.
Objetivo:
Denir la arquitectura del sistema en base a los casos de uso más signicativos, puntuali-zando que la arquitectura es de 3 capas.
Actividades:
Diseño de la arquitectura de software.
Denir los requerimientos de los casos de uso. Diseñar casos de uso.
Documentar casos de uso.
Denir la arquitectura del sistema (elementos más signicativos del sistema como pla-taformas software, sistemas operativos, gestor de bases de datos, protocolos, considera-ciones de desarrollo como sistemas heredados y requerimientos no funcionales).
Artefactos:
Vista de casos de uso.
5. MARCO METODOLÓGICO 47
5.2.1.3. Fase de construcción
En esta fase se construyen todas las funcionalidades y se integran como componentes en el producto.
Objetivo:
Construir un producto que se pueda llevar a los usuarios. Actividades:
Claricar requerimientos pendientes.
Administración de cambios de acuerdo a las evaluaciones realizadas por los usuarios y mejoras para el proyecto.
Diseño de funcionalidades: diseño de interfaz, diagrama de clase y diagrama de secuencia. Denición de componentes.
Diseño lógico de la base de datos. Artefactos:
Vista de interacción.
Diagrama de paquetes por módulo.
Vista de diseño.
Diagrama de clases por módulo. Diagrama de secuencia por módulo.
Vista de implementación.
Diagrama de componente por módulo.
Vista de despliegue.
Diagrama de despliegue en la plataforma de computación en la nube.
Código fuente.
5.2.1.4. Fase de transición
Durante esta fase llevó el producto de software en manos de los usuarios nales. Objetivo:
Poner el producto en manos de los usuarios nales, para poder desarrollar versiones actua-lizadas del producto, capacitación al usuario, tareas de conguración, instalación y usabilidad del producto.
Actividades:
5. MARCO METODOLÓGICO 48
Conversión de bases de datos operativas Capacitación de personal de mantenimiento
Validación del nuevo producto frente a lo esperado por el usuario Artefactos:
Prototipo operacional .
Documento de casos de uso: Vista de casos de uso completo. Documento de arquitectura: Arquitectura especicada y corregida.
Vista de casos de uso.
Vista de interacción (Modelo de dominio y Diagrama de paquetes).
Vista de diseño (Diagrama de clases, Diagrama de secuencia y Modelo de datos). Vista de implementación (Diagrama de componentes).
Vista de despliegue (Diagrama de despliegue).
Documento de datos
6. RESULTADOS Y DISCUSIÓN
6.1. RUP - INICIALIZACIÓN
6.1.1. Requerimientos
Durante la reuniones de entendimiento con los responsables del proceso en la empresa, el objetivo era la identicación de los requerimientos funcionales y no funcionales. Estos reque-rimientos se plantean a partir de las necesidades planteadas en capítulo 1.
6.1.1.1. Requerimientos funcionales
REQ001 El sistema permite la autenticación para los usuarios de la aplicación REQ002 El sistema permite la gestión de la información del cliente
REQ003 El sistema permite la gestión de las solicitudes como:
Solicitud de servicio. Pedido de suministro.
Pedido de servicio de reparación. Pedido de servicio de mantenimiento. Orden de fabricación.
Orden de servicio: fabricación / mantenimiento.
REQ004 Permite el ingreso y la salida de transformadores de las bodegas.
El sistema cuenta con dos tipos de bodega.
Bodega de entrada: almacena los transformadores para pruebas preliminares, los que está en producción.
Bodega de salida: los equipos que están listos para entregar al cliente.
REQ005 El sistema tiene un módulo para la gestión de la información del transformador. REQ006 El sistema permite el registro de los resultados de los ensayos realizados a un
