anÁlisis y desarrollo de una aplicaciÓn web arap la gestiÓn de protocolos de...

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

2015

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

2015

Nota de aceptación:

Firma del presidente del jurado

Firma del Jurado

Bogotá, 15 de Mayo del 2015

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.

Vuela en tu sueño, danza en el viento y la noche nunca llegara.

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:

De manera muy especial agradezco a mis padres, Jaime y Mery por el gran apoyo que me han

brindado durante el transcurso de esta etapa, a mis hermanos por la motivación que me dieron para

sacar este proyecto adelante, al profesor Fernando Martínez por la paciencia y el compromiso con el

proyecto, a William mi compañero de tesis por toda la colaboración y el gran esfuerzo que hicimos

para terminar el proyecto y a todas las personas involucradas en mi proceso de formación, a los

profesores por su esfuerzo por transmitir los conocimientos y hacer de cada uno una mejor persona.

A todos gracias.

Índice general

1.. PLANTEAMIENTO DEL PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . 131.1. DESCRIPCIÓN DEL PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.1.1. Cliente �nal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.1.2. Distribuidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.1.3. Ingeniero eléctrico o afín . . . . . . . . . . . . . . . . . . . . . . . . . . 131.1.4. Fabricante de Transformadores . . . . . . . . . . . . . . . . . . . . . . . 14

1.2. FORMULACIÓN DEL PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . 14

2.. JUSTIFICACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.. OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1. OBJETIVO GENERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2. OBJETIVOS ESPECÍFICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.. MARCO REFERENCIAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1. ANTECEDENTES o ESTADO DEL ARTE . . . . . . . . . . . . . . . . . . . . 19

4.1.1. Históricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2. Legales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1.3. Investigativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2. MARCO TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.1. Implementación de la computación en la nube . . . . . . . . . . . . . . . 214.2.2. Arquitectura de computación en la nube . . . . . . . . . . . . . . . . . 224.2.3. Características esenciales . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.4. Modelos de Servicio de la computación en la nube . . . . . . . . . . . . 234.2.5. Software como servicio SaaS . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.5.1. Ventajas [12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.5.2. Características [30] . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.6. Metodología RUP - Rational Uni�ed Process [35] . . . . . . . . . . . . . 244.2.6.1. Dimensiones de RUP: . . . . . . . . . . . . . . . . . . . . . . . 254.2.6.2. Características esenciales: . . . . . . . . . . . . . . . . . . . . . 254.2.6.3. Fases de RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.7. Lenguaje de Modelado UML - Uni�ed Modeling Languages[13] . . . . . 304.2.7.1. Componentes UML . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.8. Transformadores Serie 15Kv . . . . . . . . . . . . . . . . . . . . . . . . . 324.2.8.1. Transformador de Voltaje: . . . . . . . . . . . . . . . . . . . . . 324.2.8.2. Clasi�cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.9. Procesos para transformadores serie 15Kv . . . . . . . . . . . . . . . . . 33

Índice general 2

4.2.9.1. El proceso de fabricación de un transformador serie 15Kv . . . 344.2.9.2. Proceso de reparación de transformador serie 15Kv: . . . . . . 344.2.9.3. Proceso de mantenimiento de transformador serie 15Kv: . . . . 34

4.2.10. Protocolo de prueba para transformadores . . . . . . . . . . . . . . . . 354.2.10.1. Informativa: Incluye los datos descriptivos del transformador

iniciales, así como los datos del fabricante y del cliente. . . . . 364.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 paratransformador serie 15Kv. Estas pruebas se denomina ensayosde 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: . . . . . . . . . . . . 364.2.10.4. Datos de cliente/interventor y del proveedor/Control de Calidad. 37

4.2.11. Proceso de Protocolo de prueba para Bobinados Técnicos IngenieríaElectrónica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2.12. Programación Orientada a Objetos . . . . . . . . . . . . . . . . . . . . . 374.2.12.1. Objetos: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.12.2. Clases: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.12.3. Métodos: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.12.4. Modelo de objetos: . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.12.5. Relaciones entre objetos: . . . . . . . . . . . . . . . . . . . . . 39

4.2.13. Arquitectura de aplicaciones en n-capas [9] . . . . . . . . . . . . . . . . 404.2.13.1. Características: . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.13.2. Principios clave: . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.13.3. Bene�cios: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.13.4. Cuando usarlo: . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.. MARCO METODOLÓGICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.1. DISEÑO METODOLÓGICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1.1. Tipo de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.1.2. Metodología del Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . 435.1.3. Población Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.1.4. Instrumentos y Equipos . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1.4.1. Formatos de casos de uso: . . . . . . . . . . . . . . . . . . . . . 445.1.4.2. Unidades Lingüísticas UML . . . . . . . . . . . . . . . . . . . . 44

5.1.5. Procedimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2. METODOLOGÍA DE LA INGENIERÍA DEL PROYECTO . . . . . . . . . . . 45

5.2.1. Descripción de la Metodología en Contexto . . . . . . . . . . . . . . . . 455.2.1.1. Fase de Inicialización . . . . . . . . . . . . . . . . . . . . . . . 455.2.1.2. Fase de elaboración . . . . . . . . . . . . . . . . . . . . . . . . 465.2.1.3. Fase de construcción . . . . . . . . . . . . . . . . . . . . . . . . 475.2.1.4. Fase de transición . . . . . . . . . . . . . . . . . . . . . . . . . 47

Índice general 3

6.. RESULTADOS Y DISCUSIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.1. RUP - INICIALIZACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.1.1.1. Requerimientos funcionales . . . . . . . . . . . . . . . . . . . . 496.1.1.2. Requerimiento no funcionales . . . . . . . . . . . . . . . . . . . 50

6.1.2. Actores internos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.1.2.1. Módulo de gestión de protocolos . . . . . . . . . . . . . . . . . 506.1.2.2. Módulo de gestión de usuarios . . . . . . . . . . . . . . . . . . 516.1.2.3. Módulo de gestión de transformadores . . . . . . . . . . . . . . 516.1.2.4. Módulo de gestión de cliente . . . . . . . . . . . . . . . . . . . 51

6.1.3. Actores externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.1.3.1. Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.1.3.2. Responsable de cliente . . . . . . . . . . . . . . . . . . . . . . . 526.1.3.3. Responsable de protocolo . . . . . . . . . . . . . . . . . . . . . 536.1.3.4. Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.1.3.5. Administrador del sistema . . . . . . . . . . . . . . . . . . . . . 536.1.3.6. Responsable de bodega . . . . . . . . . . . . . . . . . . . . . . 536.1.3.7. Responsable de transformador . . . . . . . . . . . . . . . . . . 53

6.1.4. Modelo de dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.1.5. Requisitos: Casos de uso de alto nivel . . . . . . . . . . . . . . . . . . . 54

6.1.5.1. Casos de uso de alto nivel . . . . . . . . . . . . . . . . . . . . . 556.2. RUP - ELABORACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2.1. Vista de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.2.1.1. Documento de casos de uso . . . . . . . . . . . . . . . . . . . . 56

6.2.2. Vista de interacción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.2.2.1. Diagrama de paquetes . . . . . . . . . . . . . . . . . . . . . . . 56

6.2.3. Vista de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.2.3.1. Diagrama de clases general. . . . . . . . . . . . . . . . . . . . 566.2.3.2. Diagrama de secuencia general. . . . . . . . . . . . . . . . . . 596.2.3.3. Modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.3. RUP - CONSTRUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.3.1. Vista de diseño. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.3.2. Vista de implementación. . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.3.2.1. Diagrama de componentes. . . . . . . . . . . . . . . . . . . . . 606.3.3. Vista de despliegue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.3.3.1. Diagrama de despliegue en la plataforma de computación enla nube. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.3.4. Código fuente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.4. RUP - TRANSICIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6.4.1. Documento de casos de uso: Vista de casos de uso completo. . . . . . . 616.4.2. Documento de arquitectura: Arquitectura especi�cada y corregida. . . . 616.4.3. Documento de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.4.4. Línea base del producto completada . . . . . . . . . . . . . . . . . . . . 61

7.. CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Índice general 4

8.. RECOMENDACIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Índice de cuadros

4.1. Modelos de servicio de la computación en la nube . . . . . . . . . . . . . . . . 244.2. Clasi�cación de transformadores por tamaño . . . . . . . . . . . . . . . . . . . . 334.3. Clasi�cación de transformadores por aislamiento . . . . . . . . . . . . . . . . . 334.4. Clasi�cación de transformadores por tensión de alimentación . . . . . . . . . . . 334.5. Ensayos de rutina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.6. Ensayos adicionales para transformador serie 15Kv . . . . . . . . . . . . . . . . 364.7. Principios para modelamiento de objetos . . . . . . . . . . . . . . . . . . . . . 394.8. Relaciones entre objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.9. Capas utilizadas en el desarrollo del proyecto . . . . . . . . . . . . . . . . . . . 42

Índice de �guras

4.1. Arquitectura de computación en nube . . . . . . . . . . . . . . . . . . . . . . . 224.2. Fases de la metodología RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3. Ciclo de vida del software en RUP . . . . . . . . . . . . . . . . . . . . . . . . . 264.4. Diagrama de Red Eléctrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5. Proceso general transformador serie 15kV . . . . . . . . . . . . . . . . . . . . . 344.6. Proceso de fabricación de transformador serie 15Kv . . . . . . . . . . . . . . . . 344.7. Proceso de reparación de transformador serie 15Kv . . . . . . . . . . . . . . . . 354.8. Proceso de mantenimiento de transformador serie 15Kv. . . . . . . . . . . . . . 354.9. Proceso de diligenciamiento de protocolo de pruebas para transformador serie

15kV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.10. Arquitectura Tradicional N-Layer (Lógica) . . . . . . . . . . . . . . . . . . . . 40

6.1. Módulos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2. Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.3. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.4. Diagrama de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.5. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.6. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.7. Modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.8. Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.9. Diagrama de despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Nomenclatura

Aceite mineral: Líquido que por sus características químicas y físicas no esbuen 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 laautoinducció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íasde seguridad en Cloud Computing , y proporcionar educa-ción sobre los usos de la computació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ásicamenteel 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 dela corriente eléctrica del transformador.

Plataforma como Servicio Modelo de servicio de la computación en la nube. Básicamenteel proveedor ofrece su plataforma de�nida por: sistema ope-rativo, un lenguaje de programación y un servidor web. Elcliente puede implementar las aplicaciones que desarrolle.

Programación Orientada a Objetos : Concepción de la realidad modeladacomo componentes (objetos), utilizando herramientas como:abstracción, encapsulación, modularidad, jerarquía y polimor-�smo.

Resistencia de los devanados : La medida de la resistencia de los devanadosse efectúa generalmente por los métodos de la caída de tensióno del puente

Índice de �guras 8

Software como servicio: Modelo de servicio de la computación en la nube. El proveedorofrece un producto de software como un servicio. El clienteaccede al producto, hace uso de lo que necesita, cuando lonecesita, donde lo necesita.

Tanque: Co�e metálico, hermético, diseñado para contener la parteactiva de un transformador y el aceite dielectrico.

Voltaje: Es la diferencia de potencial eléctrico o tensión eléctrica (de-notado dV y medido en voltios o julios por coulomb), es ladiferencia de potencial entre dos puntos o la diferencia de po-tencial de energía eléctrica por la unidad de carga eléctricaentre dos puntos

Resumen

La aplicación desarrollada para la presente tesis permite la gestión de las pruebas paratransformadores 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 manejode la información de las empresas que suministran y ofrecen servicios a transformadores. Estedesarrollo está soportado por la plataforma PaaS (Plataforma como Servicio) [22]de serviciosen la nube de Microsoft.

El desarrollo de software bajo el modelo de servicio en la nube SaaS, ofrece como servicioel producto de software; y para su implementación, el uso como plataforma objetivo de losrecursos de almacenamiento, procesamiento, memoria, ancho de banda y administración delos recursos de un proveedor de computación en nube.

La metodología de desarrollo utilizada en el proyecto es RUP (�Rational Uni�ed Process�),y está enmarcada en el paradigma de programación orientada a objetos 1. El lenguaje demodelado utilizado es UML (�Uni�ed Modeling Language�) como herramienta para modelarel sistema[23]. La plataforma en la nube que se utilizará será: �Windows Azure� 2 para elalmacenamiento de datos no estructurado y �SQL Azure� 3 para el almacenamiento en Basede Datos. Como marco de referencia se utilizó la norma NTC 1358 (Protocolo de Pruebas paraTransformadores)[5] donde se describe la estructura del documento de protocolo de pruebasserie 15Kv.

1 Concepción de la realidad modelada como componentes (objetos), utilizando herramientas como: abstrac-ción, �encapsulamiento�, modularidad, jerarquía y polimor�smo.

2 Windows Azure es la plataforma de servicios en la nube de Microsoft. La plataforma cuenta con tresservicios 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 decómputo y almacenamiento.

3 Servicio de almacenamiento de datos con estructura relacional, hace parte de la plataforma Windows Azure.

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 sistemaque puede ser ejecutado en diferentes plataformas (servidores, computadores de escritorio, te-léfonos inteligentes, tabletas ) y el segundo es la posibilidad de conectarse permanentementea 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 estascondiciones, 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 paratransformadores serie 15Kv, siguiendo la norma NTC 1358.

Se ha desarrollado una aplicación web para la gestión de la información del transformadorserie 15Kv durante los procesos de fabricación, reparación, mantenimiento y pruebas. Estaaplicación utiliza el modelo de servicio SaaS (Software como Servicio) [22], dado que se ofreceel acceso vía web a la aplicación, y en el aplicativo el usuario encontrará diferentes recursos quele dan valor a su gestión. La aplicación esta soportada por la plataforma de un proveedor deservicios en la nube, bajo el modelo de servicio PaaS (Plataforma como Servicio) [22], dondese 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ísticasde la computación en nube: demanda, accesibilidad, multi-localización, elasticidad y controlofreciendo un marco de implementación de nuevas soluciones en software de acuerdo a laspermanentes exigencias de escalabilidad.

En el proyecto se de�nió 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 de�nición y elseguimiento del proyecto. De igual manera al ser centrada en la arquitectura, permite cons-truir una de�nición arquitectónica desde el principio la cual guiará el desarrollo durante elciclo de vida del proyecto. Y al ser iterativo e incremental, permite la entrega de productos enetapas tempranas para su validación y entrega.

Como herramienta de modelamiento se de�nió la implementación de UML, este lenguajecontiene los diagramas y elementos necesarios para el modelamiento en cada etapa de desarrollode la aplicación que se ha desarrollado: requisitos, diseño, codi�cación, despliegue, etc.

Este documento de proyecto está dividido en 8 capítulos. En el capítulo 1 encontraremosel planteamiento del problema desde el punto de vista del usuario. Para el usuario se evi-dencia la no existencia de herramientas de software que apoyen y potencien la industria deltransformador en Colombia. Se analiza el problema desde el punto de vista de los diferentesusuarios del protocolo: cliente �nal, distribuidor, ingeniero eléctrico y fabricante de transfor-

Resumen 11

mado. En el capítulo 2 se plantea la solución desde el punto de vista del ingeniero donde sejusti�ca 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 yobjetivos especí�cos) a partir de las necesidades de los usuarios. En el capítulo 4 se detalla elmarco teórico sobre el cual se basó el desarrollo del proyecto. Inicialmente se describe el estadoactual de la computación en la nube en Colombia, los proyectos que se han implementado losdiferentes modelos SaaS, PaaS o IaaS. Apoyando esta descripción del estado actual, se repasala 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 de�nidos 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, seconcreta 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. Dadoque los cantidad de artefactos elegidos de RUP y formalizados con UML es muy extensa, sede�nen 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 lade�nición de los requerimientos y su formalización en los casos de uso del sistema. Durante sude�nición paralelamente se construye el modelo de dominio, el cual contiene la terminologíaque 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 laarquitectura en la cual se centra el sistema; para la construcción de la arquitectura del sistemase 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 lasclases del aplicativo y sus componentes. En la fase de transición, se detalla el despliegue dela funcionalidad en el plataforma PaaS del proveedor en la nube.

Para �nalizar, en el capítulo 7 encontrará las conclusiones que involucran: la industria deltransformador, el modelo de la nube, la metodología del proyecto RUP, el lenguaje UML y

4 Empresa consultora creadora de la metodología RUP para el despliegue, diseño, construcción, pruebas yadministración de proyectos en el proceso desarrollo de software, adquirida en el 2003 por IBM.

Resumen 12

la ingeniería de sistemas y en el capítulo 8 encontrará la recomendaciones en metodología einvestigación.

1. PLANTEAMIENTO DEL PROBLEMA

1.1. DESCRIPCIÓN DEL PROBLEMA

En Colombia, las empresas encargadas de la fabricación, reparación y mantenimiento detransformadores serie 15Kv requieren un documento donde se informe si los transformadoresque 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 cualcontiene los siguientes datos del equipo: identi�cació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éctricacuando el transformador va a ser instalado en su red eléctrica. Las pruebas registradas en eldocumento garantizan la e�ciencia del equipo al ser instalado en la red y el cumplimiento dela 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 losresultados arrojaron las siguientes conclusiones:

1.1.1. Cliente �nal

El cliente �nal no identi�ca el protocolo de pruebas como un elemento importante cuandoadquiere 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

Identi�ca el protocolo como documento importante al adquirir un transformador.

Tener acceso al protocolo del transformador ayuda a su labor.

No existe una herramienta que permita capturar los datos de la pruebas cuando elprocedimiento es en campo.

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 bajoo 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 veri�car elhistorial del mismo.

No hay un procedimiento de respaldo de la información.

1.2. FORMULACIÓN DEL PROBLEMA

¾Es factible gestionar el protocolo de pruebas de transformadores serie 15Kv durante losprocesos de fabricación, reparación o mantenimiento a través de una aplicación web?

2. JUSTIFICACIÓN

La di�cultad en la accesibilidad y disponibilidad del protocolo de pruebas, es uno de losaspectos que más afecta a los actores involucrados en el proceso de fabricación, mantenimientoy venta del transformador eléctrico. El proyecto plantea el desarrollo de una aplicación webcon 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 formainmediata 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). Actualmentedurante 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, deesta manera se corre el riesgo que el equipo falle o no cumpla los requerimientos delas 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 veri�cación del equipo enlas etapas críticas, por ejemplo el ensamble de la bobina con el núcleo y la prueba demedición de la resistencia de los devanados[3].

Adicional al seguimiento de cada proceso, el aplicativo permitirá realizar seguimientoal equipo después de salir de la fábrica. Así mismo permitirá realizar un seguimiento alcliente para veri�car información como garantía1 y tiempo de mantenimiento2.

La aplicación desarrollada permite el almacenamiento digital de la información, además deofrecer un procedimiento de respaldo para reducir el riesgo de pérdida de la misma. El modelode 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 lemostrará un formulario intuitivo que dará rapidez y exactitud a la captura de datos durantepruebas.

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 comoplataforma objetivo y por medio de un formulario intuitivo que dará rapidez y exactitud a lacaptura de datos durante pruebas.

1 Un transformador puede tener garantía de 12 hasta 36 meses dependiendo del tipo de transformador, lostransformadores serie 15Kv se manejan garantías de 18 meses.

2 Un transformador se le realiza mantenimiento entre 3 y 5 años dependiendo de las condiciones atmosféricasdonde es instalado.

2. JUSTIFICACIÓN 16

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 comoplataforma objetivo.

3. OBJETIVOS

3.1. OBJETIVO GENERAL

Análisis y desarrollo de una aplicación web para la gestión de protocolos de pruebas paratransformadores 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 dePruebas para Transformadores.

3.2. OBJETIVOS ESPECÍFICOS

Implementar un sistema de autenticación para los usuarios de la aplicación por mediode un control de acceso.

Implementar un sistema para la administración de roles y per�les de usuarios para lagestión de los mismos dentro de la aplicación.

Desarrollar el módulo para diligenciamiento del protocolo de pruebas del transformadorserie 15Kv durante los procesos de fabricación, reparación y mantenimiento donde segarantice 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 serie15Kv, permitiendo accesibilidad al usuario interesado desde cualquier navegador web.

Desarrollar un módulo de seguimiento para el transformador serie 15Kv, el cual permitiráveri�car el historial del equipo después de salir de producción.

Desarrollar un módulo de seguimiento del cliente donde se pueda veri�car la condiciónde los productos, por ejemplo cuando los equipos adquiridos por un cliente requieranmantenimiento.

Implementar una aplicación web utilizando el modelo de servicio SaaS, demostrando lafactibilidad de futuras implementaciones.

Desarrollar interfaces grá�cas de usuario que ayuden en la experiencia de interacciónentre el aplicativo y el usuario en dispositivos móviles.

Representar el desarrollo de software a partir de los modelos estáticos: Diagrama declases, diagrama de casos de uso, diagrama de componentes y diagrama de despliegue,así como los modelos dinámicos: Diagrama de estados, diagrama de actividad, diagrama

3. OBJETIVOS 18

de secuencia y diagrama de comunicación, que ofrece el lenguaje UML; de esta for-ma cada uno de los diagramas resultantes permitirá especi�car, visualizar, construir ydocumentar[23] la arquitectura tres capas de�nida para el proyecto: capa acceso a datos,capa lógica de negocio y capa presentación.

4. MARCO REFERENCIAL

4.1. ANTECEDENTES o ESTADO DEL ARTE

Aunque el concepto de computación en la nube es relativamente nuevo en Colombia, existenvarios trabajos que han sido implementados en el país. A continuación se mencionan algunosde ellos.

4.1.1. Históricos

Aunque el concepto de computación en la nube (�Cloud Computing�) es reciente a nivelmundial, 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 e�cienciaresultante al centralizar el procesamiento de información en grandes centros de procesamientoaprovechando la infraestructura, su gran escala y el uso masivo por terminales �nales. A partirde lo anterior la computación en la nube se presenta como un conjunto de grandes centrosde computación donde se prestan servicios informáticos a los usuarios. Otra concepción decomputación en la nube es como un servicio público, esta propiedad es dada por el cientí�coestadounidense John McCarthy[21]. Según McCarthy el poder de procesamiento tendría uncobro como de los servicios de luz o agua. Para 1966 [27], el investigador canadiense DouglasParkhill presentó lo que hoy en día de�ne la computación en la nube [37], el poder de cómputocomo 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, cadavez, en las mismas condiciones de uso. A medida que la computación evoluciona y surgentecnologí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 elsurgimiento de Internet que se da el ecosistema para el desarrollo y viabilidad, gracias a launiversalidad 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 lacomputació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 dedatos transaccionales, redes (VPN), etc.; todos los servicios caracterizados por una estructuraescalable, segura, rápida, económica y simple. Estos servicios están pensados en empresas uorganizaciones con requerimientos masivos. Otras grandes empresas de la informática estánparticipando en este mercado con sus propias plataformas:

Microsoft: Azure Services Platform [33]

1 La ley enunciaba que el poder de computación aumentaba el cuadrado del costo de su producción, de talmanera para ser 10 veces más económico se debía trabajar 100 veces más rápido, publicada en 1950.

2 Lanzado el 14 de Marzo del 2006. Amazon Web Services es una división de Amazon Digital Services, Inc.

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 SecurityAlliance (CSA)�, donde se debaten las buenas prácticas para garantizar la seguridad y priva-cidad en el entorno del �Cloud Computing�, adicional ofrece un certi�cado �Cloud SecurityKnowledge� 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 miembrosde un país que desean extender estas prácticas en su región. A continuación los datos delcapítulo colombiano.

Estado del capítulo: En desarrolloRegión: ColombiaLinkedIn Subgrupo: http://www.linkedin.com/groups?gid=3350616Organizador: Juan Carlos Alvarez

4.1.3. Investigativos

Universidad de los Andes

Título Proyecto: UnaCloud - Opportunistic Cloud Computing Infrastructure as a ServiceModel [31]

Objetivo: Desarrollar un modelo IaaS de computación en la nube, que entregue recursosy 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 SaaS3 Plataforma PaaS de Google, es un servicio de alojamiento web que presta Google de forma gratuita, este

servicio permite ejecutar aplicaciones sobre la infraestructura de Google.


Universidad Católica del Norte - INGENIUS-Group S.A.S

Título Proyecto: Comparación de herramientas para el desarrollo de librerías enfocadasa 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 degrá�cas, validaciones, internacionalización y multimedia, para aplicaciones web bajo ar-quitectura �Cloud Computing�. Para el proceso de desarrollo de cada API se realizaronconsultas de herramientas, tecnologías y librerías, comparando sus ventajas y desventa-jas, teniendo en cuenta que el desarrollo cumpliera con las características establecidaspara cada una de éstas, con el �n de contribuir a la funcionalidad en la generación dereportes, 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 elintercambio computacional [8], de recursos de red y almacenamiento entre desarrolladores deservicios 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, lasaplicaciones son ejecutadas de una manera segura en �Datacenters�. Las ventajas queposee son: Disponible en demanda, rápido aprovisionamiento de negocio, reducción delcosto a través de economías de escala, �exibilidad y libertad de selección, basado en eluso, 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 seconecta con otros escenarios. Esto involucra la necesidad de adquisición de recursos deIT que son vendidos [7]. Bajo este escenario se pueden ejecutar varios tipos de serviciosque van a ser explicados más adelante.

Nube Híbrida: Esta es una mezcla de los 2 anteriores escenarios mencionados, ya quese comporta como una nube privada con la particularidad que se puede compartir lainformación a través de niveles de permiso. Se tiene un control sobre nube pública através del proveedor, mientras que el control de nube privada lo hace la empresa uorganización, con la �nalidad de satisfacer las necesidades del sistema o aplicación. Eneste escenario se podría elegir los proveedores de servicio y los proveedores de serviciofederados serían capaces de compartir las cargas de servicio [19].


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 deusuarios 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 unnivel de aplicación, debido a que la computación en la nube maneja protocolos similares a loque 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 soportadaautomáticamente por la plataforma sin interacción humana.

Amplio acceso a red: El aprovisionamiento y uso de la plataforma, y sus servicios, serealiza a través de estándares de comunicación, y es viable en diferentes posibilidades decliente (ejemplo: equipos de escritorio, equipos portátiles, celulares inteligentes, tabletas).


Recursos compartidos: Para el usuario es transparente la arquitectura física o virtualde la plataforma, así como los procesos para el almacenamiento, procesamiento, memoriay 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 solicitudesdemandas.

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 enla 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 ylos procesos de gestión: por ejemplo mantenimiento, en un servicio vía web para acceder alsistema (GOMEZ et al, 2009:7-8).

4.2.5.1. Ventajas [12]

Los clientes no necesitan instalar la aplicación, ni preocuparse por requerimientos dehardware para la ejecución.

El cliente no debe preocuparse por el almacenamiento de los datos ni de los demásprocesos 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ónfrecuente, 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 dedescargar 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.

Disponibilidad según demanda: Una vez el cliente accede a software basado en SaaS, tieneacceso desde cualquier lugar y cualquier hora.


Tabla 4.1: Modelos de servicio de la computación en la nube

Modelos Software As AService

Plataform As AService

Infrastructure As AService

Características Las aplicaciones

ofrecidas por el proveedor

se ejecutan en la nube.

(WEB Mail) El acceso a

la aplicación es

independiente de la

plataforma de acceso de la

terminal. (Navegador

WEB) El usuario no

con�gura la

infraestructura de la

plataforma del proveedor.

Las aplicaciones pueden

ser creadas por el usuario

o adquirir aplicaciones con

el API de Proveedor. La

plataforma está

enmarcada por los

lenguajes, bibliotecas,

servicios y herramientas

compatibles con el

proveedor. El usuario

no maneja la plataforma

física, pero controla la

plataforma abstracta:

aplicaciones y

con�guraciones.

Proporciona al cliente

una infraestructura

basada en servicios

utilizando principalmente

la virtualización. El

cliente es el encargado de

comprar los recursos a un

proveedor para consumo

de recursos. Se aleja del

problema de la gestión de

máquinas.

Servicios Aplicaciones Sitios Web

Colaboración y

Aplicaciones de O�cina

Servicios de Pago

Software basado en Web

Plataformas de

desarrollo Bases de

datos Cola de mensajes

Servidores de

aplicaciones

Almacenamiento

Transferencia de datos

Procesamiento VLAN

Web services de Amazon,

Azure de Microsoft,

VMware vSphere

Proveedores Facebook, Linkedln,

Twitter, Googe +, Google

Docs, Google Talk, Gmail,

Hotmail, Amazon DevPay,

Saleforce.com´s

AppExchange.

Google App Engine,

Amazon SQS, Amazon S3,

Microsoft SQL Azure

Database, NetSuite

Business Operating

System

Web services de Amazon,

Azure de Microsoft,

VMware vSphere

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 necesitapreocuparse por de�niciones técnicas de infraestructura.

4.2.6. Metodología RUP - Rational Uni�ed Process [35]

Es un proceso de ingeniería de software que por sus siglas en ingles RUP signi�can �RationalUni�ed Process� (Proceso Uni�cado de Rational), es una de las metodologías estándar másimplementadas en sistemas orientados a objetos. Proporciona una manera de delegar tareasy responsabilidades dentro de una organización, asegurando la producción de un software dealta calidad ayudando a resolver las necesidades de los usuarios a través de una serie de pasoso iteraciones para así cumplir con un presupuesto y tiempo delimitado.


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 ciclode vida del proceso.

En su eje vertical encontramos las diferentes especialidades que se agrupan por activi-dades de�nidas de acuerdo a su naturaleza. En la imagen que se muestra a continuaciónpodemos ver el enfoque de cada una de las disciplinas con respecto al tiempo y durantecada 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 deaplicaciones 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 esencialesy están bien de�nidas:

Proceso dirigido por casos de uso: Utiliza los Casos de Uso para el desarrollo ymanejo de las especialidades con los artefactos, roles y actividades necesarias. El soporteprincipal en la implementación de las fases y especialidades del RUP son los Casos deUso. Un Caso de Uso es una representación de una unidad discreta de trabajo realizadapor un usuario (u otro sistema) usando el sistema en operación [36], está relacionado conlos requerimientos y conlleva a su desarrollo e implementación.

Proceso iterativo e incremental: Por medio de este modelo se propone la realizacióndel proyecto a través de una serie de iteraciones, la cuales de�nen unos objetivos que sedeben cumplir en cada una de las iteraciones y así llegar a completar todo el proyecto.


Figura 4.3: Ciclo de vida del software en RUP

Fuente www.elbenyito.blogspot.com. Modelo RUP (Rational Uni�ed Process)

Una de las ventajas de este modelo es que podemos ir entregando pequeños avances alcliente, de esta manera se puede ir realizando pruebas mientras se avanza en otras etapasdel proyecto, el proyecto crece de una manera más rápida hasta poder completarlo en sutotalidad.

Proceso centrado en la arquitectura: Este proceso de�ne los elementos que son demás importancia dentro del sistema. Está in�uenciado entre otras por plataformas desoftware, sistemas operativos, motores de bases de datos, protocolos, consideraciones dedesarrollo como sistemas no heredados y requerimientos no funcionales. A medida queavanzamos, 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 lasfases tiene unos objetivos y puntos de control que nos ayudan a determinar si lo que estamoshaciendo cumple con las expectativas y así mismo poder evaluarlo y poder pasar a la fasesiguiente 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 sonsolo algunas de las preguntas que debemos contestar y así poder determinar laviabilidad 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 de�nen lafuncionalidad.

Mostrar al menos una arquitectura candidata para los escenarios principales.

Estimar el coste en recursos y tiempo de todo el proyecto.

Estimar los riesgos, las fuentes de incertidumbre.


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 de�nición del ámbito del sistema ylas 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 proyectoy eliminar los mayores riesgos.

Cuando se termina esta fase se llega a un camino de no retorno del proyecto: a partir de esemomento pasamos de las fases relativamente ligeras y de poco riesgo, las 2 primeras, a afrontarla fase de construcción, costosa y arriesgada. Es por esta razón que la fase de elaboración esde 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 casosde uso críticos identi�cados en la fase de inicio. También debe demostrarse que se han evitadolos riesgos más graves, bien con este prototipo, bien con otros de usar y tirar.

Los objetivos de esta fase son:

De�nir, validar y cimentar la arquitectura.

Completar la visión.


Crear un plan �able para la fase de construcción. Este plan puede evolucionar en sucesivasiteraciones. Debe incluir los costes si procede.

Demostrar que la arquitectura propuesta soportará la visión con un coste razonable yen 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 actoresidenti�cados, 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 especi�ca el proceso a seguir.

Posiblemente un manual de usuario preliminar

La forma de aproximarse a esta fase es de�niendo 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 losprincipales 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 losplanes actuales en el contexto de la arquitectura actual.

Los gastos hasta ahora son aceptables, comparados con los previstos.

Si no se superan los criterios de evaluación quizá sea necesario abandonar el proyecto o re-planteárselo considerablemente.


Construcción: La funcionalidad principal de esta fase es alcanzar la capacidadoperacional 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 sidohecho hasta ahora, han de ser implementados, integrados y probados, obteniéndose una versióndel producto que se pueda poner en manos de los usuarios (una versión beta). El énfasis en estafase está en controlar las operaciones realizadas, administrando los recursos e�cientemente, detal 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 eltener que rehacer un trabajo o incluso desecharlo.

Conseguir versiones funcionales (alfa, beta y otras versiones de prueba) tan rápido comosea 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 su�ciente detalle).

Prototipo operacional � beta.

Transición: La �nalidad de la fase de transición es poner el producto en manos delos usuarios �nales, por lo tanto requerirá desarrollar nuevas versiones actualizadasdel producto, completar la documentación, entrenar al usuario en el manejo delproducto, en general tareas relacionadas con el ajuste, con�guración, instalacióny 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 necesidadesdel usuario.

Los productos de esta fase son:

Prototipo operacional

Documentos legales

Línea de base del producto completa y corregida que incluye todos los modelos delsistema


Descripción de la arquitectura completa y corregida.

Las iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva versión. Lasactividades a realizar durante las iteraciones dependerán de su �nalidad, si es corregir algúnerror detectado, normalmente será su�ciente 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 dependetotalmente de la naturaleza del proyecto, de su alcance y de la organización en la que debaimplantarse.

No todos los productos para cada fase son obligatorios ni deben cumplirse al 100%, hayque tener en cuenta el objetivo de cada fase.

4.2.7. Lenguaje de Modelado UML - Uni�ed Modeling Languages[13]

UML se ha convertido en uno de los lenguajes de modelado más extendidos para el diseñoorientado 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, apartir 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 vistamuestra 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, con�abilidad, despliegue, etc.). Las vistasson:

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 lacomunicación y sincronización.

4 �Object-modeling technique� técnica aplicada para el análisis orientado a objetos (OOA) basado en reque-rimientos funcionales del sistema, qué hace el sistema.

5 Aplicado en el diseño orientado a objetos (OOD), busca detallar cómo será el funcionamiento del sistema.6 El método de nominado Ingeniería de Software Orientada a Objetos está basado en el concepto de caso de

uso, utilizado en la diagramación del comportamiento entre usuario y el sistema.


Vista de Despliegue: Muestra el despliegue del sistema en una ambiente físico entrecomputadoras 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, casosde uso e interacciones, identi�cados 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 de�nición de una clase detallando los posiblesestados que pueda tener un objeto, a partir de los eventos que se generan. Si el cambiode estado es generado por otro objeto, esto se debe a un mensaje. El cambio de estadose 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, incluidosel �ujo de datos. Es utilizado para describir las actividades en una operación; el diagramaconsiste de estados de acción (especi�cación de la actividad a realizar), un estado deacción se de�ne al terminar una acción.

Diagrama de Componentes: Representa la estructura física del código en términosde los componentes de código, tales como: los componentes, sus relaciones, interaccionesy sus interfaces públicas.

Diagrama de Despliegue: Muestra la arquitectura física del sistema (hardware ysoftware). 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 devida, donde es central la arquitectura de la estructura interna y cómo ella se correspondecon el pasaje de mensajes. La secuencia de los mensajes se da a través de un esquemade 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 signi�cado. Un ele-mento de modelado tiene una de�nición semántica, la cual permite que su signi�cado nosea ambiguo. Así mismo un elemento tiene su representación grá�ca o símbolo grá�coutilizado para ser asignado a su respectivo diagrama.

Relación: Sirve para interconectar lo otros elementos de modelado entre sí. Algunas relacionesson:


Dispositivo eléctrico estático que consta de un devanado, o dos o más devanados con osin núcleo magnético para introducir un acoplamiento mutuo entre circuitos eléctricos. Lostransformadores son usados en sistemas eléctricos de potencia para transferir potencia porinducción electromagnética entre circuitos de la misma frecuencia, usualmente con cambios detensión y corriente.

4.2.8.2. Clasi�cación

La clasi�cación del transformador involucra muchos aspectos, el proyecto se desarrollarábasado en las siguientes tres clasi�caciones, por tamaño y refrigeración sujetas a la normaNTC 317, según la tensión manejada por el transformador [29]:

Tabla 4.2: Clasi�cación de transformadores por tamaño

Tipo Descripción

TransformadorDistribución

Transformador para transferir energía de un circuito de distribuciónprimario hasta un circuito de distribución secundario o circuito deservicio al consumidor. Los transformadores de distribución estánusualmente entre 5 kVA y 500 kVA.

TransformadorPotencia

Transformador que trans�ere energía eléctrica en cualquier parte delcircuito entre el generador y los circuitos de distribución primaria.

Tabla 4.3: Clasi�cación de transformadores por aislamiento

Tipo Descripción

Transformadorsumergido en

líquido

Transformador en el cual el núcleo y las bobinas están sumergidos enun líquido aislante.

Transformadortipo 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: Clasi�cación de transformadores por tensión de alimentación

Tipo Descripción

Transformadortipo 15kv

Transformadores que manejan tensiones inferiores a 15.000 voltios

Transformadortipo 34,5kv

Transformadores que manejan tensiones superiores a 15.000 voltioshasta 34.500 voltios

4.2.9. Procesos para transformadores serie 15Kv

En conjunto con los ingenieros de Bobinados Técnicos Ingeniería Electrónica se ha de�nidoun proceso general (macro-proceso) para transformadores serie 15kV.


Figura 4.7: Proceso de reparación de transformador serie 15Kv

Diagrama basado en documentación suministrada por la empresa fabricante detransformadores 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 detransformadores Bobinados Técnicos Ingeniería Electrónica.

4.2.10. Protocolo de prueba para transformadores

En Colombia la norma que determina el contenido del documento es el NTC 1358 Pro-tocolo de prueba para transformadores [5]. Esta norma describe el modelo del diseño delprotocolo (anexo C ). El protocolo consta de la siguientes cuatro secciones:


4.2.10.1. Informativa: Incluye los datos descriptivos del transformador iniciales, así comolos datos del fabricante y del cliente.

4.2.10.2. Pruebas de Régimen Nominal: en el cuadro 4.5 se enlistan las pruebas quese deben realizar al transformador serie 15Kv cuyos resultados se registran en elprotocolo de pruebas para transformador serie 15Kv. Estas pruebas se denominaensayos de rutina según la norma NTC 380: Transformadores eléctricos. Ensayoseléctricos. Generalidades [6].

Tabla 4.5: Ensayos de rutina

Ensayo eléctrico Norma aplicablepara ejecutar el

ensayo

Medición de la resistencia de los devanados NTC 375Medición de la relación de transformación, veri�cación de

polaridad y relación de faseNTC 471

Medición de tensión de cortocircuito NTC 1005Medición de pérdidas con carga NTC 1005

Medición de la pérdidas y corriente sin carga (en vacío) NTC 1031Tensión aplicada NTC 837

Sobre-tensión inducida NTC 837Fuente 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 aplicablepara ejecutar el

ensayo

Especi�caciones 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.

Refrigeración.


4.2.12.1. Objetos:

Podemos de�nir 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", nocomo en su predecesora la programación estructurada, donde estaban separados en forma devariables y funciones.

Un objeto consta de:

Tiempo de vida: El ciclo de vida de un objeto en un programa siempre está limitadopor el tiempo. Gran parte de los objetos sólo existen durante parte de la ejecución delprograma. Los objetos se crean mediante un mecanismo denominado ejempli�cación,cuando dejan de existir se dice que son destruidos.

Estado: Todos los objetos poseen un estado, de�nido por sus atributos. Con él se de�nentodas sus propiedades y el estado en que se encuentra en un determinado momento.

Comportamiento: Todo objeto presenta una interfaz, de�nida por sus métodos, para queel 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 laejempli�cación de objetos equivaldría a la declaración de variables y el tiempo de vida de unobjeto al ámbito de una variable.

4.2.12.2. Clases:

Son abstracciones que representan a un grupo de objetos con un comportamiento e interfazcomún.

Podemos de�nir una clase como "un conjunto de cosas (físicas o abstractas) que tienen elmismo 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-pli�cación) se ha de especi�car de qué clase es el objeto instanciado, para que el compiladorcomprenda las características del objeto. Las clases presentan el estado de los objetos a losque representan mediante variables denominadas atributos. Cuando se genera un ejemplar deun objeto el compilador crea en la memoria dinámica un espacio para tantas variables comoatributos 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 modi�can los valoresde los atributos del objeto, representan las capacidades del objeto.

Desde el punto de vista de la programación estructurada, una clase se asemejaría a unmódulo, los atributos a las variables globales de dicho módulo y los métodos a las funcionesdel módulo.


4.2.12.4. Modelo de objetos:

Existen una serie de principios fundamentales para comprender cómo se modela la realidadal 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 polimor�smo, cuadro4.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 enforma de objetos. Buscando similares entre la realidad y la posibleimplementación de objetos del programa que simulen el funcionamientode los objetos reales.

Encapsulado El encapsulado permite a los objetos elegir qué información espublicada y qué información es ocultada al resto de los objetos. Paraello los objetos suelen presentar sus métodos como interfaces públicas ysus atributos como datos privados e inaccesibles desde otros objetos.

Modularidad Mediante la modularidad, el programador divide su aplicación en variosmódulos diferentes (clases, paquetes o bibliotecas), cada uno de elloscon un signi�cado propio. Esta fragmentación disminuye el grado dedi�cultad 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. Laherencia permite a una clase hija tomar determinadas propiedades deuna clase padre.

Paso de Mensajes Un objeto puede solicitar de otro objeto que realice una accióndeterminada o que modi�que su estado. El paso de mensajes se sueleimplementar como llamadas a los métodos de otros objetos.

Polimor�smo De acuerdo al contexto el objeto puede tener diferentescomportamientos

4.2.12.5. Relaciones entre objetos:

Durante la ejecución de un programa, los diversos objetos que lo componen interaccionanentre sí para lograr una serie de objetivos comunes. Existen varios tipos de relaciones quepueden unir a los diferentes objetos, pero entre ellas destacan las relaciones de: asociación,todo/parte y generalización/especialización. Cuadro 4.8.


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, lageneralización tiene una perspectiva ascendente, mientras que laespecializació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 ylas responsabilidades para proporcionar una división efectiva de los problemas a resolver. Losroles indican el tipo y la forma de la interacción con otras capas y las responsabilidades lafuncionalidad que implementan.

Cuanto más se aumenta el proceso operativo de la empresa, las necesidades de procesocrecen hasta desbordar las máquinas. Es por ello que se separa la estructura de un programaen varias capas [1].

Las capas (tiers) se ocupan de la división lógica de componentes y funcionalidad y notienen en cuenta la localización, �gura 4.10.

Figura 4.10: Arquitectura Tradicional N-Layer (Lógica)

Fuente De la Torre, Cesar. Guía de programación en N capas orientadas al dominio con.NET 4.0.


4.2.13.1. Características:

Descomposición de los servicios de forma que la mayoría de las interacciones ocurre soloentre 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 bienconocidas.

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 su�cientes detalles paraentender las relaciones entre capas.

No realiza ninguna suposición sobre los tipos de datos, métodos, propiedades y susimplementaciones.

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 bajoacoplamiento entre capas.

4.2.13.3. Bene�cios:

Abstracción, ya que los cambios que se realizan a alto nivel y se puede reducir oincrementar 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 sinque 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 de�nidasobre la que realizar las pruebas y la habilidad de cambiar entre diferentes implementa-ciones de una capa.

Independencia, ya que elimina la necesidad de considerar el hardware y el despliegueasí como las dependencias con interfaces externas.


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 losdistintos 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 laarquitectura de la aplicación. Es la parte visible, la que se muestra alusuario y con la que interacciona.

Negocio La capa de lógica de negocio es donde se realizan las reglas del negocioy donde se manipulan los datos devueltos desde la capa de acceso adatos antes de enviarlos a la capa de presentación. Está formada porlos objetos de negocio y las clases encargadas de trabajar con dichosobjetos.

Acceso a Datos La capa de acceso a datos, es la capa que interactúa con la fuente dedatos (base de datos). Su diseño está basado en la creación de una clasepor cada entidad en la base de datos.

Entidad denegocio

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].

7 Un objeto de negocio se construye a partir de una clase que únicamente contiene propiedades, que secorresponderán en la mayoría de los casos con los campos que conforman cada tabla. Su misión principal esservir de contenedor destinado exclusivamente a la transferencia de información. Cada objeto de negocio de laaplicación lleva asociada una clase destinada a almacenar una colección de objetos de ese mismo tipo.

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 materialescrito para identi�car el marco teórico de la computación en nube y su modelo SaaS, ademáspara la de�nición del problema se elaboraron entrevistas informales y encuestas. El proyectose basa en las inconformidades encontradas durante el �ujo de información en el proceso dediligenciamiento de los protocolos de pruebas para transformadores serie 15kV. A partir delo anterior, en el proyecto se desarrolló una aplicación que permita gestionar la informaciónrelacionada 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 elproceso de diligenciamiento del protocolo de pruebas de transformadores serie 15kV. Primerose identi�có la problemática en la generación del protocolo como una tarea con reducido niveltecnológico, dado que se usa actualmente un documento de excel; adicional se evidenció lanecesidad 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 ladosistematizar el proceso para la gestión del protocolo de pruebas para transformadores serie15Kv a través de herramientas tecnológicas de software, y por el otro el aplicativo desarrolladodebe 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 querequirió que tanto los requerimientos, como los casos de uso de sistema debían estar totalmentede�nidos. El seguimiento del ciclo de vida de RUP (requerimientos, análisis y diseño, imple-mentación, pruebas y evaluación) garantiza el re�namiento continuo del software (actividadesy 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ó comolenguaje de modelamiento UML. Este lenguaje posee diagramas y elementos que permitenmodelar el sistema dependiendo del contexto: casos de uso, interacción, diseño, despliegue eimplementación.

5.1.3. Población Objetivo

El proyecto involucra los siguientes actores:

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 a�nes,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 adistribuidores de productos eléctricos como a usuarios �nales, garantizando portabilidaddel 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 ennuevos 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óndel software, se detalla los respectivos diagramas que se desarrollarán para cada una:

Vista de casos de uso.

� Diagramas de casos de uso.

Vista de interacción

� Modelo de dominio

� Diagrama de paquetes.

Vista de diseño

� Diagrama de clases.

� Diagrama de secuencia.

� Modelo de datos

Diagrama de implementación

� Diagrama de componentes.

Vista Despliegue

� Diagrama de despliegue.


5.1.5. Procedimiento

Levantamiento de la información: Durante esta etapa el grupo se dedicará a obtenerla información necesaria para iniciar el desarrollo del proyecto. Esto se hará mediante laobtenció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 paraprotocolo de transformadores y debido a la criticidad de esta al ser norma nacional, la etapade análisis del proyecto debe ser rigurosa.

La metodología que se seleccionó para realizar el desarrollo del software para el proyectoes RUP. Desde su etapa inicial RUP plantea un marco claro y robusto para la construcciónde software de calidad, además de pautas para desarrollos de software pequeños como grandesproyectos, permitiéndonos focalizar el objetivo del proyecto y cumplimiento de la norma; sindesconocer las demás fortalezas de la metodología misma: desarrollo iterativo, veri�cación dela 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, conlos 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 identi�cación de los límites del proyecto; ejemplo,Transformadores serie 15kV.

Actividades:

Identi�car los requerimientos de los usuarios y las principales limitaciones que se tienen.

Identi�cació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.

Especi�cación de casos de uso.

Especi�caciones adicionales.


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 de�ne la arquitectura y se establecen los requisitos que describirán elsistema.

Objetivo:De�nir la arquitectura del sistema en base a los casos de uso más signi�cativos, puntuali-

zando que la arquitectura es de 3 capas.Actividades:

Diseño de la arquitectura de software.

De�nir los requerimientos de los casos de uso.

Diseñar casos de uso.

Documentar casos de uso.

De�nir la arquitectura del sistema (elementos más signi�cativos 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.

� Documento de casos de uso.

Vista de interacción.

� Diagrama de paquetes general.

Vista de diseño.

� Diagrama de clases general.� Diagrama de secuencia general.� Modelo de datos.

Vista de implementación.

� Diagrama de componentes general.

Vista de despliegue.

� Diagrama de despliegue general.


5.2.1.3. Fase de construcción

En esta fase se construyen todas las funcionalidades y se integran como componentes enel producto.

Objetivo:Construir un producto que se pueda llevar a los usuarios.Actividades:

Clari�car requerimientos pendientes.

Administración de cambios de acuerdo a las evaluaciones realizadas por los usuarios ymejoras para el proyecto.

Diseño de funcionalidades: diseño de interfaz, diagrama de clase y diagrama de secuencia.

De�nició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 con�guración, instalación y usabilidaddel producto.

Actividades:

Capacitación a los usuarios .


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 especi�cada 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

Línea base del producto completada

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, elobjetivo era la identi�cació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 queestá 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 trans-formador.

6. RESULTADOS Y DISCUSIÓN 50

REQ007 El sistema tiene un módulo para el diligenciamiento del protocolo de pruebas deltransformador serie 15Kv, durante los procesos de fabricación, reparación y manteni-miento.

REQ08 El sistema permite la consulta del protocolo de pruebas de transformador serie 15Kv.

REQ09 El sistema tiene un módulo de seguimiento para el transformador serie 15Kv, el cualpermite consultar el historial del equipo después de salir de producción.

REQ010 El sistema tiene un módulo de seguimiento del cliente, donde se puede consultar lacondición de sus productos.

6.1.1.2. Requerimiento no funcionales

RNF01.1 Diseñar una aplicación web bajo una arquitectura de 3 capas:

Capa de presentación

Capa de negocio

Capa de acceso a datos.

RNF02.1 Diseñar la aplicación web que cumpla las restricciones de recursos de cuenta deevaluación de la plataforma Windows Azure:

Duración de 90 días de la cuenta

750 hora de uso de máquina virtual por mes.

1Gb de almacenamiento SQL.

RNF03.1 El sistema permite la gestión de roles y per�les de usuario.

6.1.2. Actores internos

Como primer punto se identi�can los actores internos, estos permite agrupar en un actorfuncionalidades de acuerdo a los requerimientos de�nidos anteriormente, �gura Módulos delsistema. Durante el desarrollo del presente documento se denominarán �Módulos�.

6.1.2.1. Módulo de gestión de protocolos

Este módulo contiene las siguientes características:

Gestión de pruebas de rutina.

Gestión de pruebas preliminares de ingreso de transformadores.

Generación del informe de pruebas preliminares.

Generación del protocolo de pruebas de transformador serie 15kV.


Figura 6.1: Módulos del sistema

6.1.2.2. Módulo de gestión de usuarios


Gestión de los datos de usuario: nombre de usuario y contraseña.

Asignación de roles a usuarios del sistema.

Roles con per�les de ingreso a las páginas del aplicativo.

Autenticación de los usuarios por nombre de usuario y contraseña, validado por �Capt-cha�.

6.1.2.3. Módulo de gestión de transformadores


Gestión de la información de transformadores serie 15kV

Gestión de bodegas para asignación de transformadores.

Seguimiento de transformador (historial).

6.1.2.4. Módulo de gestión de cliente


Gestión de la información del cliente.

Asignación de transformadores a cliente.

Seguimiento de productos del cliente.


Figura 6.2: Actores

6.1.3. Actores externos

Ya identi�cados los actores que forman el sistema, se identi�can los actores externos, aque-llas entidades que modi�can y usan el sistema. Durante el desarrollo del presente documentose denominarán �Actores�, �gura Actores.

6.1.3.1. Cliente

Gestiona la información general de su cuenta.

Consulta la información general de los transformadores asignados a su cuenta.

Consulta el protocolo de prueba de un transformador asignado.

6.1.3.2. Responsable de cliente

Gestiona de la información del cliente de la organización.

Asigna los transformadores en estado: fabricación, reparación o mantenimiento, a uncliente existente.

Consulta lista de clientes, seleccionar un cliente y permitir la consulta de los transforma-dores que ha adquirido, para veri�car el estado, la fecha de salida de bodega e historialde protocolos.

Consulta lista de transformadores en bodega, para veri�car el estado, el cliente, la fechade salida de bodega e historial de protocolos.

Consulta historial de protocolos.

Crea un transformador en el sistema, debe asignarle un cliente para ser creado y el nuevotransformador tendrá estado "fabricación".


6.1.3.3. Responsable de protocolo

Crea un protocolo de pruebas para un transformador en estado: fabricación, reparacióny mantenimiento.

Cada nuevo protocolo adicionar al historial de protocolos.

Realiza y registra el resultado de las respectivas pruebas para un transformador enestado: fabricación, reparación y mantenimiento.

6.1.3.4. Usuario

Una persona que utilice cualquier componente del sistema debe tener una cuenta de usuariopara acceder.

Una cuenta de usuario contiene:

Correo

Contraseña.

6.1.3.5. Administrador del sistema

Gestiona de usuarios.

Con�gura roles y per�les.

6.1.3.6. Responsable de bodega

Ingresa un transformador a la bodega para una reparación o mantenimiento. Se veri�ca siel transformador existe en el sistema y no en la bodega, si cumple se ingresa a la bodega,si no existe en el sistema se crea el transformador en el sistema: registra la informacióngeneral y se ingresa a la bodega; si está en la bodega no permite su ingreso.

Cuando se entrega a un cliente, se retira el transformador de la bodega y se registra enel historial, no se elimina del sistema.

6.1.3.7. Responsable de transformador

Gestiona la información general del transformador.

6.1.4. Modelo de dominio

Después de, diseñar los procesos (fabricación, reparación y mantenimiento), identi�car losrequerimientos y actores, se plantea un modelo de dominio que permita de�nir los conceptosmás recurrentes en el funcionamiento del sistema. En este modelo, las relaciones entre concep-tos permiten identi�car cuál concepto contiene a uno o más conceptos de tal manera se puedaveri�car su multiplicidad.

A continuación se enlistan los concepto resultantes de este análisis.


Pedido. Documento que detalla el tipo de pedido (suministro o servicio) que requiereel cliente. Si es suministro se ingresa la información del pedido. Si es servicio se asignaa un trasformador del registro.

Pedido servicio de reparación o mantenimiento. Permite especi�car que serviciose realiza al transformador ingresado.

Pedido suministro de transformador. Permite detallar los transformadores que elcliente desea adquirir.

Portafolio de transformadores. Cada cliente puede veri�car los transformadores quetiene asignado a su cuenta. Y puede veri�car la información de cada transformador.

Protocolo. Documento donde se registra los resultado de la pruebas realizadas al trans-formador, al �nalizar cada proceso de fabricación, reparación o mantenimiento.

Pruebas. Conjunto de datos requeridos por una norma ICONTEC, necesaria para laveri�cación del correcto funcionamiento del equipo en determinado aspecto.

Registro de transformadores. Contiene todos los transformadores que se han creadoen el sistema, ya sea por fabricación, reparación o mantenimiento. Antes de la creaciónde un transformador para los procesos de reparación o mantenimiento, se valida si existeen esta lista, si existe se toma la información de ella, para evitar duplicidad.

Registro de pruebas. Contiene todos los resultados de la pruebas realizadas a untransformador.

Resultados de pruebas preliminares. Documento con los resultado de las pruebaspreliminares realizadas al transformador ya existente en la bodega de entrada, paravalidar si es una reparación o un mantenimiento.

Transformador Datos del transformador que permite:

� Identi�cación del equipo.

� Especi�cación técnica.

� Especi�cación física.

Usuario. Representa al usuario dentro del sistema.

6.1.5. Requisitos: Casos de uso de alto nivel

Al puntualizar los requerimientos en la anterior sección, se de�ne las funcionalidades, al-cance y límites del sistema, así como su interacción entre módulos y actores. En esta sección elsistema comienza a de�nir partiendo de un diagrama de casos de uso, este artefacto contienela funcionalidades desde un nivel alto que permite veri�ca el funcionamiento entre actores. Acontinuación se en lista los casos de uso que componen el sistema.


6.1.5.1. Casos de uso de alto nivel

Se han de�nido como requisitos para desarrollar y entregar, la siguiente lista de casos deuso. Esta lista ha sido depurada y completada durante las dos iteraciones para esta fase deinicialización.

CU_CLI001 Realizar búsqueda de cliente

CU_CLI002 Gestionar la información del cliente

CU_CLI003 Consultar historial del cliente

CU_CLI004 Crear solicitud de cliente

CU_CLI005 Gestionar pedidos de cliente

CU_PRO001 Gestionar pruebas preliminares

CU_PRO002 Gestionar pruebas para protocolo de pruebas

CU_PRO003 Generar protocolo de pruebas

CU_PRO004 Gestionar la información del protocolo de pruebas para proceso de fabricación

CU_PRO005 Gestionar la información del protocolo de pruebas para el proceso de reparación

CU_PRO006 Gestionar la información del protocolo de pruebas para el proceso de manteni-miento

CU_PRO007 Gestionar prueba norma NTC 1465 Especi�caciones para aceites minerales

CU_PRO008 Gestionar prueba norma NTC 471 Medición de la relación de transformación,veri�cación de polaridad y relación de fase

CU_PRO009 Gestionar prueba norma NTC 375 Medición de la resistencia de los devanados

CU_PRO010 Gestionar prueba norma NTC 1005 Medición de tensión de cortocircuito

CU_PRO011 Gestionar prueba norma NTC 1031 Medición de la pérdidas y corriente sincarga (en vacío)

CU_PRO012 Gestionar prueba norma NTC 3396 Pinturas para tanques de transformadores

CU_PRO013 Gestionar prueba norma NTC 837 Tensión aplicada

CU_USU001 Autenticar usuarios de la aplicación

CU_USU002 Modi�car contraseña de cuenta de usuario

CU_USU003 Gestionar cuentas de usuario

CU_TRA001 Realizar búsqueda de transformador serie 15Kv

CU_TRA002 Gestionar la información del transformador serie 15Kv


CU_TRA003 Crear transformador en sistema

CU_TRA004 Consultar el historial de transformador

CU_TRA005 Gestionar bodega de transformadores

CU_TRA006 Modi�car asignación de transformadores a cliente

CU_TRA007 Gestionar orden de fabricación, reparación y mantenimiento

6.2. RUP - ELABORACIÓN

6.2.1. Vista de casos de uso

En esta vista se de�ne el alcancé del sistema como un conjunto de casos de uso, roles y suinteracción. Para la aplicación tenemos los 28 casos de uso y 7 roles distribuidos en 4 módulos:Módulo de gestión de cliente, Módulo de gestión de protocolos, Módulo de gestión de usuariosy Módulo de gestión transformadores, �gura 6.3.

6.2.1.1. Documento de casos de uso

Este artefacto además de contener el detalle de cada uno de los 28 casos de uso, tambiéncontiene la visión global donde se describe lo que se espera del aplicativo y su alcance, tantofuncional como técnico. El documento generado tiene como título Documento de casos deuso (anexo D )

6.2.2. Vista de interacción

6.2.2.1. Diagrama de paquetes

El diagrama contiene la organización del aplicativo, donde se garantiza que en la estructurase cumpla con la arquitectura, �gura 6.4.

6.2.3. Vista de diseño

En esta vista se detalla el paquete técnico, este proporciona al desarrollador una descripcióncompleta del producto o del componente de producto a medida que se desarrolla.

6.2.3.1. Diagrama de clases general.

El diagrama de�ne las clases y relaciones de una funcionalidad, pero también se utilizapara mostrar los subsistemas (o módulos) y la interfaces involucradas. Para la aplicación lageneración de este diagrama está muy relacionada con la plataforma de desarrollo utilizada .Net la cual crea un estructura propia para clases, interfaces, �gura 6.5.


Figura 6.3: Diagrama de casos de uso

Figura 6.4: Diagrama de paquetes


Figura 6.5: Diagrama de clases


Figura 6.6: Diagrama de secuencia

Figura 6.7: Modelo de datos

6.2.3.2. Diagrama de secuencia general.

El diagrama de�ne la secuencia entre paquetes del aplicativo. En el aplicativo la secuenciainicia de parte de cualquier interacción con la interfaz grá�ca (UI), donde se gestiona lainformación de una entidad (Common). La gestión de la información es por medio de unobjeto de negocio (BL) el cual contiene los método su�cientes para garantizar la completitudde la información de la entidad, adicional este objeto realiza el llamado al objeto de transacción(DAO). El DAO es el encargado de enviar la entidad a la base de datos, �gura 6.6.

6.2.3.3. Modelo de datos

Este modelo está basado en los conceptos identi�cados en el diagrama de dominio, con elcual se da el alcance a los datos requeridos. A partir de esta información se genera el modelorelacional que es el que a continuación se detalla en la �gura 6.7.

6.3. RUP - CONSTRUCCIÓN

6.3.1. Vista de diseño.

En esta fase, la vista de diseño está compuesta por los diagramas y elementos detalladospara el desarrollo de cada módulo. Como producto de esta fase se tiene la �Documentación de


Figura 6.8: Diagrama de componentes

Figura 6.9: Diagrama de despliegue

diseño�, la cual es generada desde la herramienta Enterprise Architect (EA) en forma de sitioweb para acceso a todos los desarrolladores. Anexo G 8.

6.3.2. Vista de implementación.

6.3.2.1. Diagrama de componentes.

El diagrama de�ne los componentes y su funcionamiento en el aplicativo, �gura 6.8.

6.3.3. Vista de despliegue.

6.3.3.1. Diagrama de despliegue en la plataforma de computación en la nube.

El diagrama de�ne la implementación del aplicativo en el PaaS de Azure, �gura 6.9.


6.3.4. Código fuente.

Como repositorio del código fuente de este proyecto se utiliza la plataforma SaaS de �Git-Hub�1, en el siguiente enlace https://github.com/williamtenth/ProtocolCloud se puede des-cargar todo el código fuente del proyecto. Para ser colaborador debe solicitarse la autorizacióna William Cuadros ([email protected]) o Jaime Aguilar ([email protected]).

6.4. RUP - TRANSICIÓN

6.4.1. Documento de casos de uso: Vista de casos de uso completo.

El documento generado tiene como título Documento de casos de uso (anexo D 83)

6.4.2. Documento de arquitectura: Arquitectura especi�cada y corregida.

El documento generado tiene como título Documento de Arquitectura (anexo F 145)

6.4.3. Documento de datos.

El documento generado tiene como título Documento de datos (anexo E 157)

6.4.4. Línea base del producto completada

La línea base de la versión desplegada en producción se encuentra en la siguiente ruta ,.1 GitHub es una plataforma de desarrollo colaborativo para alojar proyectos utilizando el sistema de control

de versiones Git. Utiliza el framework Ruby on Rails por GitHub, Inc. (anteriormente conocida como LogicalAwesome). Desde enero de 2010, GitHub opera bajo el nombre de GitHub, Inc. El código se almacena de formapública, aunque también se puede hacer de forma privada, creando una cuenta de pago.

7. CONCLUSIONES

Se implementó un control de acceso por medio de la combinación de usuario y contraseña.Se diseñó el control de tal forma que al ingresar exitosamente el usuario tiene acceso a laspáginas permitidas por su per�l y a la información del cliente asignado.

La segmentación de acceso a partir de roles y per�les, garantiza control y �exibilidad. Porun lado se garantiza el control de acceso, también permite asignar más de un role a un usuario,creando entonces un per�l.

El uso de roles es uno de los conceptos importantes en la aplicación, dirigió el diseño delos requisitos (dividir en módulos el aplicativo), la arquitectura (paquetes para cada móduloen cada capa), el diseño detallado (diseño de clases abstractas e interfaces) y la implementa-ción (división en componentes). Para la aplicación se de�nieron los roles: Cliente, ResponsableCliente (Módulo gestión de cliente) , Responsable de protocolo (Módulo de gestión de proto-colo), Administrador del sistema (Módulo de gestión de usuario), Responsable de bodega yResponsable de transformador (Módulo de gestión transformadores).

Para los procesos de un transformador (fabricación, reparación y mantenimiento) se di-señaron las mismas pruebas que garanticen calidad en el producto sin importar el proceso:NTC 1465 Especi�caciones para aceites minerales, NTC 471 Medición de la relación de trans-formación, veri�cación de polaridad y relación de fase, NTC 375 Medición de la resistenciade los devanados, NTC 1005 Medición de tensión de cortocircuito, NTC 1031 Medición de lapérdidas y corriente sin carga (en vacío), NTC 3396 Pinturas para tanques de transformadoresy NTC 837 Tensión aplicada.

Para el proyecto se planteo el concepto �pedido� como base para los procesos relacionadoscon el cliente: crear pedido y los procesos de protocolo, de tal manera que el cliente solorequiere saber el consecutivo del pedido y el podrá acceder al respectivo protocolo.

La aplicación permite al responsable de cliente, o al rol con acceso a dicho módulo, veri�carel historial de pedidos que tiene un cliente. Cuando al cliente se le crea una solicitud (suministroo servicio), el sistema relaciona la nueva solicitud con el cliente, a su vez la solicitud relacionael transformador; con este proceso el cliente, o el rol con permisos, puede consultar el estadode los pedidos o los transformadores que ha adquirido.

El desarrollo de aplicaciones bajo el modelo SaaS presenta una oportunidad en el mercadodel software. Esta oportunidad se caracterizada por su continuidad y estabilidad en el desarrollo

7. CONCLUSIONES 63

de un producto y potenciar la relación comercial con el cliente. Al adquirir software comoservicio, el cliente requiere acceso oportuno a su información; ahora, al ofrecer software comoservicio, el proveedor se responsabiliza de mantener el software y garantizar la seguridad enlos datos almacenados. De esta forma el cliente se desliga de responsabilidades que en otrosmodelos recaen en él, mantenimiento de hardware, seguridad, acceso, etc.

El diseño de las páginas garantiza que la consulta y la funcionalidad será igual tanto encomputadores como en dispositivos móviles. Se ha creado un paquetes de hojas de estilos conun patrón de diseño web adaptable (Responsive Web Design), permitiendo que las páginas seadapten dinámicamente a la resolución de la pantalla.

Si se navega desde un computador el aplicativo muestra un menú lateral con los cuatromódulos de�nidos (con sus respectivas páginas) y el respectivo formulario de la opción delmenú seleccionada. Si la aplicación es navegada desde un dispositivo móvil la hoja de estilosresponsive oculta el menú y muestra únicamente el formulario.

Dos de las fases, del ciclo de desarrollo, que mayor tiempo se destinó fue primero en lade�nición de una arquitectura de sistema y segundo en el cumplimiento de dicha arquitecturacon la de�nición del diseño detallado. Es así que para implementar una arquitectura de 4 + 1,se construyeron vistas de cada uno de los siguientes aspectos: casos de uso, interacción, diseño,implementación y despliegue.

El diseño detallado debía cumplir con la arquitectura establecida, para ello cada una delas vistas fue detallada con el uso de diagramas UML. Dejando a un lado la vista de casosde uso, la vista de interacción de�nió el alcance, para ello se utilizó el diagrama de clasestanto para el modelo de dominio como para el de paquetes. Para la vista de diseño se de�nióutilizar el diagrama de clases, el diagrama de secuencia y el diagrama datos relacional. La vistade implementación, se utilizó para detallar la funcionalidad de los componentes generados.Finalmente la vista de despliegue detalla la forma de instalar el aplicativo en la plataforma enla nube.

Los requisitos documentados en los casos de de uso, contienen la de�nición de la funciona-lidad, alcance y responsables del aplicativo. Y es por esto que los casos de uso se convierten enla base de la aplicación, dado que son el inicio y el �nal (pruebas) para cada ciclo de desarrollo(análisis, diseño, construcción y pruebas) y por supuesto para cada fase de RUP.

7. CONCLUSIONES 64

El aplicativo se dividió en módulos, para garantizar �exibilidad entre estos se eligió laarquitectura n-capas. La capa �Common� puede ser accedida desde cualquier otra, se garantizala cohesión al ofrecer interfaces a las otras capas.

8. RECOMENDACIONES

Para tener una idea clara del proceso o negocio, se recomienda realizar un diagrama delproceso antes de documentar los requisitos (casos de uso, historia de usuario). Dado que elcliente puede entender o explicar mejor el requerimiento con un grá�co.

Actualmente ha surgido un nuevo modelo de servicio en la nube CaaS (Containers-as-a-Service), donde se le garantiza una mayor administración al cliente (quien adquiere el servicio)en los aspectos: seguridad, autenticación, propiedad de los datos, gestión de usuarios, etc.Este modelo plantea que la administración y principalmente la propiedad de los datos sea delcliente, dado que en el modelo SaaS en la mayoría de los casos el propietario de los datos es elproveedor [38].

Bibliografía

[1] Luis Miguel. BLANCO. Programación en Visual Basic .NET. Grupo EIDOS, 2002. ISBN84-88457-53-7.

[2] Grady. BOOCH. Object-Oriented Analysis and Design with Applications. 2nd Edición.Benjamin-Cummings Pub. Co., 1993. Redwood City, California.

[3] INSTITUTO COLOMBIANO DE NORMALIZACIÓN Y CERTIFICACIÓN. Transfor-madores. medida de la resistencia entre devanados., 1970. TRANSFORMERS. MEASU-RE OF WINDING RESISTANCE.

[4] INSTITUTO COLOMBIANO DE NORMALIZACIÓN Y CERTIFICACIÓN. Electro-tecnica. tranformadores de potencia y distribución. terminología., 1998. NTC 317. equi-valente (EQV) a la ANSI/IEEE C57-12-80 excepto en el numeral 5.3.4.1.

[5] INSTITUTO COLOMBIANO DE NORMALIZACIÓN Y CERTIFICACIÓN. Protocolode pruebas para transformadores, 2000. NTC 1358. Segunda Actualización.

[6] INSTITUTO COLOMBIANO DE NORMALIZACIÓN Y CERTIFICACIÓN. Transfor-madores eléctricos, ensayos eléctricos, generalidades., 2001.

[7] I. CISCO SYSTEMS. Private cloud computing for enterprises, cisco white paper. 2009.

[8] INC. CISCO SYSTEMS. The Cisco Powered Network Cloud: An Exciting Managed Ser-vices Opportunity. CISCO SYSTEMS, INC., 2009.

[9] Unai. BARROS Miguel Angel. CALVARIO NELSON Javier. DE LA TORRE LLOREN-TE, Cesar. ZORRILLA CASTRO. Guia de programación en N capas orientadas al do-minio con .NET 4.0. Microsoft-Ibérica S.R.L, 2010.

[10] Rex. DEMAREST, George. WANG. Oracle cloud computing. Oracle Corporation, 1:21,2010.

[11] Luis Fernando. ESPINO BARRIOS. Cloud computing como una red de servicios. page 23,Noviembre 2009. Instituto Tecnológico de Costa Rica.

[12] David. FOX, Armando. PATTERSON. Engineering Long-Lasting Software: An AgileApproach using SaaS and Cloud Computing. Amazon, 2012.

[13] MIGUEL ÁNGEL. BRAVO SERGIO. GARCÍA PEÑALVO, FRANCISCO. CON-DE GONZALES. Tema 2: Modelo objetos. una descripción de uml. Universidad deSalamanca - Departamento de Informática y Automática., 1:261, 2008.

Bibliografía 67

[14] Olga Lucía. GÓMEZ, Juan Erasmo. GIRALDO. Estudio y propuesta de adaptación delmodelo de negocios de software as a service para satisfacer las necesidades del sectormipyme colombiano. 6to CONTECSI - International Conference on Information Systemsand Technology Management, 1:21, 2009.

[15] CCG GROUP. Mobility vs. portability, Febrero 2012.

[16] RUMBAUGH J JACOBSON I, BOOCH J. El proceso uni�cado de desarrollo de software.Pearson Educación S.A., 2000.

[17] Kathy. KOWALENKO. The smart grid a primer. IEEE INSTITUTE, page 1, 2010.

[18] PHILIPPE KRUCHTEN. Planos arquitectónicos: El modelo de 4+1 vistas de la arqui-tectura del software, Mayo 2014.

[19] J. D. LASICA. Identity in the age of cloud computing. The Aspen Institute, 2009.

[20] Javier Antonio. LÓPEZ H, Fabián Hernando. BALLESTERO R. Comparación de he-rramientas para el desarrollo de librerías enfocadas a aplicaciones web. Revista VirtualUniversidad Católica del Norte, 34:18, 2011.

[21] John. McCARTHY. Centennial keynote address. 1961.

[22] P. GRANCE T. MELL. The nist de�nition of cloud computing. page 3, 2011. NISTSpecial Publication 800-145 - The NIST De�nition of Cloud Computing.

[23] JAVIER. MENDOZA. Diseño del sistema de tarjeta de crédito con uml. Tesis DigitalesUniversidad Nacional Mayor de San Marcos, page 82, 2003.

[24] Hugo. GUERRA GRADOS Luis. MOQUILLAZA HENRÍQUEZ, Santiago Domingo. VE-GA HUERTA. Programación en n capas. Revista de investigación de sistemas e Infor-mática. UnIversIdad NacIonal Mayor de San Marcos., page 11, 2010.

[25] Francisco MORENO. Introducción a la OOP. Grupo EIDOS, 2000. Ejemplar gratuito.

[26] M. MSDN. Data transfer object, Febrero 2012.

[27] Douglas. PARKHILL. The challenge of the computer utility. 1966.

[28] CERVEZA J. y FERNANDEZ L. PIATTINI M., CALVO-MANZANO J.A. Análisis ydiseño detallado de aplicaciones informáticas de gestión. RA-MA, 1996.

[29] Alexandra. PÉREZ. Curso virtual de redes eléctricas, Marzo 2012.

[30] George. REESE. Cloud Application Architectures. O�Reilly Media, 2009.

[31] Harold. VILLAMIZAR Mario. ROSALES, Eduardo Rosales. CASTRO. Unacloud: Op-portunistic cloud computing infrastructure as a service. page 8 p., 2011.

[32] Ronak. FALVEY Sarah. RYAN, Patrick. MERCHANT. Regulation of the cloud in india.Internet Law., Volumen 15 Numero 4, Octubre 2011.

Bibliografía 68

[33] David. SHAPELL. Windows Azure and ISVS. DAVID SHAPELL & ASSOCIATES, 2009.SPONSORED BY MICROSOFT CORPORATION.

[34] P. SINGH, T. Singh. KUMAR VARA. Smart metering the clouds. 18th IEEE Interna-tional Workshops on Enabling Technologies: Infrastructures for Collaborative Enterprises,18:66�71., United States of America, 2009,.

[35] RATIONAL SOFTWARE. Rational Uni�ed Process. Best Practices for Software Deve-lopment Teams. Rational Software., 1998.

[36] Geo�rey. SPARX. El Modelo de Casos de Uso. Craftware Consultores Ltda.

[37] Simon. WARDLEY. Cloud Computing ... Deja Vu. Agosto 2009.

[38] Peter YARED. Goodbye saas - hello containers-as-a-service. Artículo web, Mayo 2015.

anÁlisis y desarrollo de una aplicaciÓn web arap la gestiÓn de protocolos de...

Documents