DESARROLLO E IMPLEMENTACIÓN DE UN SOFTWARE DE SIMULACIÓN DE SISTEMAS DE REFRIGERACIÓN POR COMPRESION DE VAPOR

(CICLO IDEAL) PARA EL LABORATORIO DE REFRIGERACION MECANICA DE LA PLANTA PILOTO PESQUERA DE TAGANGA DE LA UNIVERSIDAD

DEL MAGDALENA

LUIS ALFREDO AGUDELO GUERREROJUAN CARLOS SILVA JARAMILLO

UNIVERSIDAD DEL MAGDALENAFACULTAD DE INGENIERIA

PROGRAMA DE INGENIERIA DE SISTEMASSANTA MARTA D.T.C.H

2006

DESARROLLO E IMPLEMENTACIÓN DE UN SOFTWARE DE SIMULACIÓN DE SISTEMAS DE REFRIGERACIÓN POR COMPRESION DE VAPOR

(CICLO IDEAL) PARA EL LABORATORIO DE REFRIGERACION MECANICA DE LA PLANTA PILOTO PESQUERA DE TAGANGA DE LA UNIVERSIDAD

DEL MAGDALENA

LUIS ALFREDO AGUDELO GUERREROJUAN CARLOS SILVA JARAMILLO

Proyecto de Memoria de Grado presentado al Comité Evaluador como requisito parcial para optar el titulo de Ingeniero de Sistemas

Director: OMAR RODRIGUEZ

Ingeniero Electrónico

UNIVERSIDAD DEL MAGDALENAFACULTAD DE INGENIERIA

PROGRAMA DE INGENIERIA DE SISTEMASSANTA MARTA D.T.C.H

2006

ii.

Nota de aceptación

______________________________________

______________________________________

______________________________________

____________________________________Presidente del Jurado

________________________________Jurado

________________________________Jurado

Santa Marta, 6 Marzo de 2006

iii.

A mi Madre que con empeño, esfuerzo y sacrificio me ha educado para convertirme en un hombre de bien, útil para la sociedad.A mi Padre quien me enseño, que si quería ser zapatero, fuese el mejor Por que de nada sirve el doctor si es el ejemplo malo del pueblo.A mi Hermano a ese amigo y confidente el cual trato de brindarle lo mejor de mí para que en un mañana pueda verme como un ejemplo.A mi abuelo Marcos Guerrero que con sus sabios consejos me mostró los dos caminos, y solo yo debería escoger cual tomar. A la mujer que ha estado a mi lado estos últimos seis años, brindándome amor y paciencia.

iv.

Luis Alfredo

A mi Madre, Hermanas y Amigos

Juan Carlos

AGRADECIMIENTOS

Los autores expresan sus sinceros agradecimientos a:

La Universidad del Magdalena por brindarnos la oportunidad de

convertirnos en profesionales y personas integras.

A todos los profesores del programa de ingeniería de sistemas y de la

Universidad del Magdalena, por todas sus enseñanzas

Al Ing. Omar Rodríguez, por su confianza y apoyo profesional, humana

y a ese optimismo que tuvo en nosotros durante todos estos años.

Al Ing. Álvaro Espeleta, coordinador de la planta piloto pesquera de la

universidad del magdalena, por su apoyo e inmensa colaboración.

v.

A la ingeniera Leidy Trout Rizzo por su abnegada colaboración y el

gran empeño manifestado en nuestro proyecto.

A nuestros Amigos y compañeros Hermides, Marlon, Álvaro, Yamid,

Fernando, Julio, Carlos, Nain, Nelly ,Tatiana ,Lorena, Gina, Jorge, Jesús

Uribe, Pupo y Miguel Angel por acompañarnos en el duro camino

hacia la consecución de este sueño, por compartir con nosotros sus

conocimientos, alegrías, tristezas, triunfos y fracasos.

Son muchos los recuerdos que quedan, unos buenos y otros malos,

pero los malos siempre terminaban en buenos.

A todas aquellas personas que de una manera u otra hicieron posible

el logro de este objetivo.

TABLA DE CONTENIDO Pág.

1. INTRODUCCIÓN_____________________________________________15

2. OBJETIVOS_________________________________________________16

2.1. GENERAL_______________________________________________16

2.2. ESPECIFICOS___________________________________________16

3. JUSTIFICACIÓN_____________________________________________17

4. MARCO DE REFERENCIA_____________________________________18

4.1. MARCO TEÓRICO________________________________________184.1.1. REFRIGERACION______________________________________184.1.2. SIMULACION__________________________________________214.1.3. LABORATORIOS VIRTUALES_____________________________224.1.4. POO. Programación Orientada a Objetos. ____________________23

vi.

4.1.4.1. Características de los Lenguajes POO:___________________264.1.5. Base de Datos._________________________________________284.1.6. Ingeniería Del Software.__________________________________30

4.1.6.1. Método del ciclo de vida para desarrollo de sistemas.________304.1.6.2. Método de desarrollo por Análisis y Diseño Estructurado._____304.1.6.3. Método de desarrollo de sistemas por prototipos.___________30

4.1.7. UML. Unified Modeling Language.__________________________33

4.2. MARCO CONCEPTUAL____________________________________41

5. DISEÑO METODOLÓGICO_____________________________________43

5.1. Fase de Inicio____________________________________________435.1.1. Definición del alcance y estudio de factibilidad del proyecto.______435.1.2. Entrevista con el jefe. ____________________________________435.1.3. Recolección y tratamiento de la información requerida para la realización del Software._______________________________________445.1.4. Revisión y estudio de la información.________________________445.1.5. Identificación y clasificación de procesos._____________________445.1.6. Definición de una visión aproximada del proyecto;______________455.1.7. Definición del alcance y estudio de factibilidad del proyecto_______455.1.8. Factibilidad técnica y tecnológica___________________________465.1.9. Factibilidad operativa____________________________________465.1.10. Recolección y tratamiento de la información_________________465.1.11. Revisión y estudio de la información recolectada._____________465.1.12. Definición de una visión aproximada del proyecto;____________465.1.13. Identificación y clasificación de procesos.___________________475.1.14. Definición de la arquitectura provisional, en esta etapa________51

5.1.14.1. Clases Candidatas:________________________________51

5.2. Fase de Elaboración_______________________________________525.2.1. Se especifica en detalle la mayoría de los casos de uso_________525.2.2. Definición e implementación del núcleo central de la arquitectura del sistema_____________________________________________________535.2.3. Modelage de datos______________________________________54

5.2.3.1. Modelo Entidad Relación______________________________545.2.3.2. . Modelo Lógico de la base de Datos____________________55

5.2.4. Catálogo de módulos de la aplicación________________________595.2.5. Modelo de Despliegue____________________________________605.2.6. Diagramas de Secuencia_________________________________665.2.7. Modelo de pruebas del sistema____________________________755.2.8. Arquitectura Técnica_____________________________________77

5.3. Fase de Construcción______________________________________785.3.1. Desarrollo del modulo Diseñador de Sistemas de Refrigeración___785.3.2. Desarrollo del Modulo Cálculos_____________________________785.3.3. Desarrollo de los Módulos Graficas P-h y T-s__________________785.3.4. .Desarrollo del Modulo Animación___________________________78

vii.

5.3.5. .Desarrollo del Modulo Información paso a paso_______________78

5.4. Configuración general del sistema____________________________78

5.5. . Fase de Transición_______________________________________79

5.6. Pruebas y documentación__________________________________79

5.7. . Formalización del sistema_________________________________82

6. CRONOGRAMA_____________________________________________83

7. PRESUPUESTO_____________________________________________84

8. CONCLUSIONES____________________________________________85

9. RECOMENDACIONES________________________________________86

10. BIBLIOGRAFIA____________________________________________87

LISTA DE TABLAS

Tabla 1. Descripción de los casos de uso______________________________47

Tabla 2. Lista de entidades____________________________________________55

Tabla 3. Tabla refrigerante_____________________________________________55

Tabla 4. Tabla sobrecalentado_________________________________________56

Tabla 5. Tabla index_sobrecalentado__________________________________56

Tabla 6. Tabla saturado_______________________________________________57

Tabla 7. Tabla tema___________________________________________________58

viii.

Tabla 8. Tabla pagina_________________________________________________58

Tabla 9. Módulos principales del sistema_______________________________59

Tabla 10. Módulos auxiliares___________________________________________59

Tabla 11. Modelo de pruebas del sistema_______________________________75

Tabla 12. Resultados de las pruebas funcionales del sistema____________79

Tabla 13. Cronograma_________________________________________________83

Tabla 14. Presupuesto________________________________________________84

LISTA DE FIGURAS

Figura 1. Diagrama de alta y baja presion............................................................20

Figura 2. Esquema de RUP (Proceso unificado Racional).............................33

Figura 3. Definición de una visión aproximada...................................................47

Figura 4. Definición de la arquitectura provision...............................................51

Figura 5. Modelo de casos de uso..........................................................................52

figura6 .Modelo de clases........................................................................................53

Figura 7.Modelo entidad - relación.........................................................................54

Figura 8. Pantallazo inicial........................................................................................60

Figura 9. Cuadro de Dialogo para el enlace de componentes........................61

ix.

Figura 10. Formulario de inserción de Nuevos componentes........................61

Figura 11. Cuadro de Dialogo de Cálculos...........................................................62

Figura 12. Interfaz de animación.............................................................................63

Figura 13. Interfaz de Información pasó a paso..................................................64

Figura 14. Interfaz grafica P-h (Presión –Entalpia).............................................64

Figura 15. Interfaz grafica T-s (Temperatura – Entropía)..................................65

Figura 16 Diagramas de Secuencia. Escenario crear nuevo sistema...........66

Figura 17 Diagramas de Secuencia. Escenario crear nuevo sistema e ingresar un compresor..............................................................................................68

Figura 18 Diagramas de Secuencia. Escenario eliminar Componente. Compresor , intercambiador y separador de aceite..........................................69

Figura 19 Diagramas de Secuencia. Escenario eliminar Componente........70

Figura 20 Diagramas de Secuencia. Escenario Enlazar la entrada de un componente (compresor) a otro (evaporador)....................................................71

Figura 21 Diagramas de Secuencia. Escenario enlazar la entrada de un componente con un intercambiador (caso especial)........................................71

Figura 22 Diagramas de Secuencia. Escenario ejecución de un sistema. . .72

Figura 23 Diagramas de Secuencia. Escenario pausar, detener y reanudar la ejecución de un sistema.......................................................................................73

Figura 24 Diagramas de Secuencia. Escenario Ver información paso a paso de un sistema.....................................................................................................74

GLOSARIO

ACCESORIO: un accesorio proporciona al sistema básico unas mejoras u obtiene en el mismo un grado de funcionamiento que sería prácticamente imposible de conseguir con los componentes del sistema básico que normalmente se encuentra en el comercio. Estos accesorios pueden tener innumerables formas y tamaños y servir para diferentes usos, pero su principal cometido es siempre mejorar o hacer más efectivo un sistema de refrigeración. Son estos: Separador de aceite, Intercambiador de calor, Filtro secador, Acumulador de succión.

x.

ACUMULADOR DE SUCCIÓN: el acumulador es un dispositivo que tiene como función recoger el líquido antes de que llegue al compresor. Este líquido se evapora en el acumulador y retorna al compresor en forma de gas.

BTU: es la cantidad de calor requerida para aumentar la temperatura de una libra de agua 1°F.

CAMBIO DE ESTADO: paso de un estado a otro de la naturaleza.

CARGA: Cantidad de calor acumulada en un recinto.

CICLO IDEAL: fases de un sistema en donde las condiciones son las mejores. Los elementos esenciales en un sistema de refrigeración básico, son: el compresor, el condensador, el dispositivo de control de líquido refrigerante y el evaporador.

COMPRESOR: la función de un compresor es la de tomar vapor refrigerante a baja temperatura y presión y descargarlo luego de aumentarlas ambas.

CONDENSADOR: es el componente del sistema de refrigeración mediante el cual el calor se transfiere a otro medio que lo absorbe y lo traslada a un punto final previamente determinado. El condensador es la puerta a través de la cual el calor que no se desea fluye fuera del sistema de refrigeración.

DISPOSITIVO DE EXPANSIÓN: es un dispositivo destinado a controlar el caudal de líquido refrigerante que entra al evaporador

ENTALPIA: Magnitud termodinámica de un cuerpo, igual a la suma de su energía interna más el producto de su volumen por la presión exterior.

ENTROPIA: Magnitud termodinámica que mide la parte no utilizable de la energía contenida en un sistema.

EVAPORADOR: el evaporador es la parte del Sistema de Refrigeración que absorbe el calor que no es deseable en determinado sitio para que pueda ser transferido o transportado al condensador a través del cual es cedido a un medio condensador. El Evaporador es la puerta a través de la cual el calor indeseable penetra al sistema de refrigeración.

FILTRO SECADOR: es un medio de eliminar la humedad y partículas sólidas de un sistema de refrigeración

INTERCAMBIADOR DE CALOR: el intercambiador de calor es un dispositivo que se utiliza para transferir calor del líquido refrigerante al gas de succión. El intercambiador de calor tiene dos principales usos. El primero es reducir la

xi.

temperatura o subenfriar el líquido refrigerante que va desde el condensador al dispositivo de expansión. Esta reducción de la temperatura es necesaria en sistemas que tienen grandes caídas de presión para impedir la evaporación rápida en la línea de líquido. El segundo empleo del intercambiador es asegurarse que el gas de succión que va al compresor es seco (es decir, que no va acompañado de líquido refrigerante)

INTERPOLACIÓN MATEMATICA: Calcular el valor aproximado de una magnitud en un intervalo cuando se conocen algunos de los valores que toma a uno y otro lado de dicho intervalo.

LINEA DE LÍQUIDO: sección de tubería por donde el refrigerante circula en estado liquido.

PROPIEDADES DE LOS REFRIGERANTES: pueden clasificarse en dos principales categorías: termodinámicas y físicas.

PROPIEDADES FÍSICAS: son aquellas que no tienen relación directa con la cantidad de calor que un refrigerante puede absorber o mover. Las propiedades físicas más importantes son: miscibilidad, tendencia a la fuga, olor, toxicidad, inflamabilidad, localización de fugas y reacción con la humedad.

PROPIEDADES TERMODINÁMICAS: son aquellas que tienen relación con el movimiento del calor. Las propiedades termodinámicas de principal interés son: presión, temperatura, volumen, densidad, entalpía y entropía. Para cada refrigerante hay publicadas tablas, que dan en detalle las propiedades termodinámicas para varias temperaturas y presiones.

R-12: designación del refrigerante con que son conocidos en la industria. Su nombre común es Refrigerante 12 y su formula química es CCL2F2.

R-717: designación del refrigerante con que son conocidos en la industria. Su nombre común es Amoníaco y su formula química es NH3.

RECIBIDOR DE LÍQUIDO: sirve para almacenar líquido refrigerante en el sistema de refrigeración. Muchos sistemas de refrigeración tienen grandes variaciones de carga, de tal manera que la cantidad de refrigerante requerida no es la misma en todos los momentos de funcionamiento. De no existir el recipiente de líquido, el refrigerante no requerido se acumularía en el condensador ocasionando traumas al funcionamiento del sistema

REFRIGERANTE: es un fluido que absorbe calor por evaporación a baja temperatura y presión y lo cede a más alta temperatura y presión.

xii.

SEPARADOR DE ACEITE: el separador de aceite sirve para reducir la cantidad de aceite que normalmente circula por un sistema e incrementar, por tanto, su rendimiento. Todos los sistemas de refrigeración tienen algo de aceite circulando a través de ellos. En algunos casos, la cantidad de aceite en circulación puede afectar el grado de transferencia de calor en el evaporador e incluso afectar al funcionamiento de un dispositivo de expansión. En éstos casos un separador de aceite que reduzca la circulación del mismo dentro del sistema, puede mejorar el rendimiento del evaporador y reducir los problemas.

TEMPERATURA DE CONDENSACIÓN temperatura en la cual una sustancia pasa de estado gaseoso a liquido

TEMPERATURA DE EVAPORACIÓN: temperatura en la cual una sustancia pasa de estado liquido a gaseoso

TEMPERATURA DE SATURACIÓN: es otra forma de denominar las temperaturas que implican cambios de estado.

TEMPERATURA DE SOBRECALENTAMIENTO: grados de temperatura, por encima del punto de ebullición, que adquiere una masa de vapor por adición de calor.

xiii.

RESUMEN

El objetivo de este trabajo es desarrollar e implementar un software de simulación de sistemas de refrigeración por compresión de vapor (ciclo ideal) para dos tipos de refrigerantes, para el laboratorio de Refrigeración Mecánica de la planta piloto pesquera de Taganga de la Universidad del Magdalena. Para el proceso de desarrollo de software se aplico la metodología del Proceso unificado de Racional (RUP); permitiendo a los autores transformar los requerimientos capturados con la ayuda del Lenguaje Unificado de Modelado (UML), a través de diagramas de casos de uso, de actividades y del Usuario- Cliente, en un producto software codificado con el lenguaje de programación Visual Basic.NET en conjunto con el Sistema Manejador de Base de Datos de Microsoft Access. Se utiliza la interpolación matemática, los valores de Temperaturas y cantidad de Calor a remover indicados por el usuario y datos de la tabla de propiedades Termodinámicas del refrigerante seleccionado para obtener la simulación del sistema de Refrigeración que se aprecian en las graficas T-h y P-s. Consiguiendo el desarrollo e implementación de un software de simulación de Sistemas de Refrigeración por compresión de vapor (ciclo ideal) para dos tipos de refrigerantes, para el laboratorio de Refrigeración mecánica de la planta piloto de taganga de la Universidad del Magdalena.

Abstract: The objective of this work is to develop and to implement a software of simulation of refrigeration systems for compression of vapor (ideal cycle) for two types of coolant, for the laboratory of the fishing plant pilot's of Taganga of the University of the Magdalena Mechanical Refrigeration. For the process of software development you applies the methodology of the unified Process of Rational (RUP); allowing the authors to transform the requirements captured with the help of the Unified Language of Modeling (UML), through diagrams of cases of use, of activities and of the User - Client, in a product software coded with the language of Visual programming Basic.NET together with the System of database of Microsoft Access. It is used the mathematical interpolation, the values of Temperatures and quantity of Heat to remove indicated by the user and data of the chart of Thermodynamic properties of the coolant one selected to obtain the simulation of the system of Refrigeration that you/they are appreciated in the graphic T-h and P-s. Getting the development and implementation of a software of simulation of Systems of Refrigeration for compression of vapor (ideal cycle) for two types of coolant, for the laboratory of the plant pilot's mechanical Refrigeration.

xiv.

1. INTRODUCCIÓN

El proceso de refrigeración consiste en reducir la temperatura de un espacio determinado y mantenerla baja y controlada, son ejemplos enfriar alimentos, conservar determinadas sustancias o conseguir un ambiente agradable. Al almacenamiento refrigerado de alimentos perecederos, pieles, productos farmacéuticos y otros se conoce como almacenamiento en frío. La importancia de la refrigeración es que a temperaturas bajas evita el crecimiento de bacterias e impide algunas reacciones químicas no deseadas que pueden tener lugar a temperatura ambiente.

En el laboratorio de refrigeración del centro planta piloto de taganga de la Universidad del Magdalena los estudiantes demuestran sus conocimientos en termodinámica e identifican el origen de fallas presentadas en un sistema de refrigeración, el cual fue elaborado para ese propósito.

Existen varias razones por la que se necesita la permanente vigilancia de un instructor con los que operan los sistemas de refrigeración; una de ellas es el no contar en el laboratorio con otro instrumento para realizar las prácticas sin peligro de dañar los elementos, otra es la de vigilar adecuadamente los procesos a desarrollar. Esto ha permitido identificar la posibilidad de mejorar la manera en que se desarrolla el laboratorio de refrigeración de los estudiantes de ingeniería pesquera, ubicada en la planta piloto de taganga que hace parte de la Universidad Del Magdalena, una alternativa que tendrá como producto un software o aplicativo como la herramienta de apoyo que permitirá manipular de manera virtual variables como son: tiempo, temperatura, presión en tiempo real; sin temor de averiar ningún elemento y mucho menos tener que invertir dinero en materiales para el estudio o reparación de sistemas de refrigeración.

Dado que la simulación es la representación de un proceso o fenómeno mediante otro mas simple, que permite analizar sus características; Pero la simulación no es solo eso también es algo muy cotidiano, hoy en día, puede ser desde la simulación de un examen, que le hace la maestra a su alumno para un examen de Estado, la producción de textiles, alimentos, juguetes, construcción de infraestructuras por medio de maquetas, hasta el entrenamiento virtual de los pilotos de combate.

15.

2. OBJETIVOS

2.1.GENERAL

Desarrollar e Implementar un software de simulación de Sistemas de Refrigeración por compresión de vapor (ciclo ideal) para dos tipos de refrigerantes, para el laboratorio de Refrigeración Mecánica de la planta piloto pesquera de Taganga de la Universidad del Magdalena.

2.2.ESPECIFICOS

Elaborar un modulo de Diseño de Sistemas, de refrigeración, que permita a los usuarios construir y verificar su correcta implementación y funcionamiento, mostrando un mensaje de error en caso de que exista.

Elaborar sistemas con inconsistencias convencionales para que el usuario las identifique y corrija.

Elaborar un modulo en el cual se realicen cálculos efectivos para un sistema de refrigeración por compresión de vapor (ciclo ideal).

Elaborar un modulo donde se puedan monitorear el comportamiento de las variables presión, temperatura y tiempo (Graficación de variables).

Elaborar un modulo en el cual el usuario guarde las practicas realizadas en el laboratorio.

Elaborar un modulo que muestre la teoría de refrigeración a través de una interfaz de usuario agradable (gráficos, iconos, video, etc.).

Desarrollar la documentación de usuario para cada uno de estos módulos que conformará en conjunto la documentación del software completo a implementar en la planta piloto pesquera de Taganga.

Elaborar un modulo que integre los módulos del sistema.

16.

3. JUSTIFICACIÓN

La investigación propuesta busca, mediante la aplicación de la teoría y los conceptos básicos de Refrigeración y del área de preparación de los autores la de ingeniería del Software, POO, UML y BD; contribuir en el desarrollo y el aprendizaje de los estudiantes ingeniería pesquera de la universidad del magdalena presentando la herramienta de ayuda para la planta piloto de taganga.

Para lograr el cumplimiento de los objetivos de estudio, se acude al empleo de métodos de desarrollo de software y de una herramienta de modelado como lo es UML para especificar y diseñar sistemas. Ya que ofrece un modo estándar de visualizar, construir, documentar y conectar los elementos de un sistema basado en el software; además representa un activo importante para la profesión de los autores. Así, el producto se apoya en técnicas de ingeniería para el análisis y desarrollo de software que permitan obtener un sistema de alta calidad que cumpla con las necesidades del usuario.

El interés de los autores esta fomentado por incrementar sus conocimientos en métodos de desarrollo de Software, UML, en la tecnología de Programación Orientada a Objetos (POO), de especializarnos en un lenguaje que permita el desarrollo de aplicaciones Windows como lo es Visual .NET; de contribuir a la solución del problema planteado que afecta a la dependencia permitiéndole mejorar los procedimientos de desarrollo de laboratorios. El cumplimiento de estos objetivos llevará a los autores a obtener un titulo académico.

El resultado de este trabajo es un aplicativo o software que permitirá preparar a los estudiantes antes de tener un acercamiento directo con un sistema real de refrigeración; además de fortalecer los conocimientos y disminuir costos de mantenimiento del sistema de refrigeración.

17.

4. MARCO DE REFERENCIA

4.1. MARCO TEÓRICO

4.1.1. REFRIGERACION

Un sistema de refrigeración se emplea para mantener cierta región del espacio a una temperatura menor que la de su entorno. El fluido de trabajo puede aparecer en dos fases( refrigeración por compresión de vapor). Es común asociar la refrigeración con la conservación de alimentos y acondicionamiento de aire en los edificios. No obstante, las técnicas de refrigeración se necesitan en muchas otras situaciones. Como son el empleo de combustibles líquidos para la propulsión de cohetes, el oxígeno líquido para la fabricación del acero, el nitrógeno líquido para la investigación a temperaturas bajas (criogénia), y para técnicas quirúrgicas y el gas natural licuado para transporte intercontinental son solo algunos ejemplos de los muchos que la refrigeración es esencial.El uso de hielo de origen natural o artificial como refrigerante estaba muy extendido hasta poco antes de la I Guerra Mundial, cuando aparecieron los refrigeradores mecánicos y eléctricos. La eficacia del hielo como refrigerante es debida a que tiene una temperatura de fusión de 0 °C y para fundirse tiene que absorber una cantidad de calor equivalente a 333,1 kJ/kg. Los alimentos que se mantienen a esta temperatura o ligeramente por encima de ella pueden conservarse durante más tiempo.

Los procesos industriales existentes para conseguir temperaturas inferiores a las del ambiente son: por cambio de fase o expansión de un gas comprimido. El efecto de refrigeración se debe a la absorción de calor en la evaporación. Para que el proceso sea continuo es preciso que el vapor pase de nuevo a estado líquido. Este método empleado da nombre al proceso y así se distingue entre refrigeración por compresión y por absorción, el objetivo de este proyecto es la refrigeración por compresión de vapor. Para alcanzar o mantener en un lugar determinado una temperatura baja es necesario que el sistema refrigerante absorba calor a esa temperatura y lo ceda a otra superior, generalmente la del ambiente y esta la definición dada al efecto de refrigerar, la transferencia de calor de un sitio donde no es deseable a otro donde no importa cederlo. El trabajo mecánico para el ciclo de compresión del vapor acciona

18.

un compresor, que mantiene baja presión en un evaporador y una presión más alta en un condensador.

La temperatura a la cual se evapora un líquido (o se condensa un vapor) depende de la presión; así pues, si se hace trabajar la máquina con un fluido adecuado, éste se evaporará a una baja temperatura en el evaporador de baja presión (tomando calor de su entorno) y se condensará a una temperatura más alta en el condensador de alta presión (desprendiendo calor a su entorno).El líquido de alta presión formado en el condensador precisa devolverse al evaporador con un gasto controlado.

Es de conocimiento que la solo presencia de una sal en el hielo reduce en varios grados el punto de fusión del mismo.

El ciclo de refrigeración básico consta de cuatro elementos esenciales que son: Compresor, condensador, válvula de expansión y evaporador.

a) El compresor succiona vapor a baja presión y temperatura y lo descarga como vapor a alta presión. Esta acción da como resultado

- Un descenso en la presión en el evaporador, la cual produce una temperatura de evaporación más baja que la del aire ambiente o del agua que deberá ser enfriada.

- Una corriente de refrigerante a través del sistema.

b) En el condensador el refrigerante cambia de estado pasando de vapor a líquido teniendo como resultado un calor que es añadido al aire.

c) En la válvula de expansión el líquido a alta presión es estrangulado convirtiéndose en líquido a baja presión.

d) En el evaporador el refrigerante extrae calor de los alimentos pasando de líquido a vapor.Un refrigerante se define como un fluido que absorbe calor por evaporación a baja temperatura y presión y que cede calor, por condensación, a más alta temperatura y presión.

Debido a que el refrigerante cambia de líquido a gas y viceversa, el calor latente de vaporización que debe absorber el refrigerante lo toma del medio a enfriar produciendo en este un descenso en su temperatura a la vez que se produce la evaporación del refrigerante. La absorción de calor por evaporación de un refrigerante produce el enfriamiento.

El dióxido de carbono sólido, conocido como hielo seco o nieve carbónica, también se usa como refrigerante. A la presión atmosférica normal no tiene fase líquida, y sublima directamente de la fase sólida a la gaseosa a una temperatura de -78,5 °C.

19.

La nieve carbónica es eficaz para conservar productos a bajas temperaturas mientras dura su sublimación.

Los dispositivos de control de líquido refrigerante tienen solamente la función de controlar la corriente de refrigerante que entra al evaporador. Esto representa un estrechamiento en la línea de líquido. Cada sistema de refrigeración funciona con dos diferentes y definidos niveles de presión. La línea que divide estos dos niveles es la que se muestra en la grafica. Uno de sus extremos se encuentra en la válvula de descarga del compresor y el otro extremo se encuentra en el dispositivo de control de líquido refrigerante.

Por definición, el lado de Alta de los sistemas incluye todos los componentes que trabajan a la presión de condensación o por encima de ella (descarga del compresor, condensador, depósito de líquido y toda la tubería de interconexión entre estos hasta la entrada de la válvula de expansión). Para efectos prácticos todo el compresor se considera como parte del lado de alta.

El lado de Baja de un sistema incluye todos los elementos que trabajan a la presión de evaporación o por debajo de ella (el dispositivo de control, el evaporador y toda la tubería de interconexión de estos elementos hasta la succión del compresor). Para efectos prácticos se considera que todo el dispositivo de control hace parte del lado de baja. El lado de baja se llama también: Presión de Succión o Presión de Baja.

Figura 1. Diagrama de alta y baja presion

En el país contamos con un entrenador de refrigeración asistido por computador construido por el SENA. El software contiene información en cifras y gráficos de variables como presiones de alta y baja, corriente, potencia y temperatura de condensador y evaporador. Que se actualizan en tiempo real al tomar los datos del sistema de refrigeración que han adaptado para tal propósito, este muestra al estudiante apartes importantes de la teoría de refrigeración al momento de operarlo, pero este no cuenta con una interfaz grafica adecuada para identificar claramente los comportamientos que toman las variables durante el ciclo de refrigeración, debido a que estos cambios se deben mostrar de forma agradable, didáctica y eficaz para estimular la comprensión y el estudio de estos sucesos .

CONDENSADOR

RECIBIDOR

COMPRESOR

EVAPORADOR

DISPOSITIVO DE EXPANSION

20.

4.1.2. SIMULACION

La simulación es la representación de un o fenómeno mediante otro mas simple, que permite analizar sus características; Pero la simulación no es solo eso también es algo muy cotidiano, hoy en día, puede ser desde la simulación de un examen, que le hace la maestra a su alumno para un examen, la producción de textiles, alimentos, juguetes, construcción de infraestructuras por medio de maquetas, hasta el entrenamiento virtual de los pilotos de combate.Las aplicaciones recreativas, hoy muy extendidas y mejoradas principalmente por los adelantos en este campo, están especialmente diseñadas para crear un pasatiempo que logre sacar de la rutina al ser humano, y que el mejor de los casos de otro modo seria impracticable debido a su costo. Estas consisten en crear ambientes y decorados artificiales con sonido en algunos casos, que logran una perfecta simulación de cualquier tipo de contenido, creando el pasatiempo perfecto.

La gran evolución de los métodos informáticos tanto en su aspecto de hardware como software, ha permitido afrontar la resolución de complejos físicos matemáticos cuya resolución analítica resultaría prácticamente imposible. De hecho muchos de dichos problemas hace ya años que están planteados, solo falta un medio adecuado para la obtención de resultados prácticos. Así pues la simulación intenta reproducir la realidad a partir de resolución numérica mediante ordenador, de las ecuaciones matemáticas que describen dicha realidad. Por lo tanto hay que asumir que la simulación es tan exactas como sea las ecuaciones de partida y la capacidad de los ordenadores para resolverlas, lo cual fija limites a su utilización.

Mediante la simulación numérica es posible generar sólidos de aspectos casi reales, comprobar su comportamiento bajo diversas condiciones de trabajo, estudiar el movimiento conjunto de grupos de sólidos, etc. Esto permite un conocimiento mucho mas profundo de un producto antes de que exista físicamente, siendo posible detectar muchos de los problemas que de otro modo se hubieran detectado en el servicio real.

21.

4.1.3. LABORATORIOS VIRTUALES

Una de las definiciones de “laboratorios virtuales” que se ha aplicado a la enseñanza a distancia es la que las definen como “simulaciones de prácticas manipulativas que pueden ser hechas por la/el estudiante lejos de la universidad y el docente”. Los laboratorios virtuales son imitaciones digitales de prácticas de laboratorio o de campo, reducidas a la pantalla de la computadora (simulación bidimensional) o en sentido estricto, a una visión más realista con profundidad de campo y visión binocular, que requiere que la persona se coloque un casco de realidad virtual.

Estos laboratorios comenzaron a desarrollarse en 1997 en el Centro de Investigación Académica de la Universidad Estatal a Distancia de Costa Rica. Si se juzga con base en la información recolectada, fueron de los primeros laboratorios virtuales para enseñanza a distancia a nivel mundial.

Los laboratorios son un elemento clave en la formación integral y actualizada de un ingeniero. No se puede concebir un ingeniero que no haya realizado prácticas de laboratorio en su trayectoria de formación inicial. Los avances tecnológicos de los últimos años han abierto posibilidades para cambiar la estructura rígida de los laboratorios tradicionales, por una estructura flexible que se apoya en las computadoras, circuitos de acondicionamiento, hardware de adquisición de datos y software. Constituyen todos estos elementos la plataforma sobre la cual se desarrolla la instrumentación virtual.

En este contexto una de las herramientas básicas de la instrumentación virtual lo constituyen las simulaciones.

la simulación y en consecuencia la virtual, resume toda la teoría relacionada con el proceso en el cual se sustituyen las situaciones reales por otras creadas artificialmente y de las cuales el estudiante debe aprender ciertas acciones, habilidades, hábitos, etc., que posteriormente deberá transferir a la situación de la vida real con igual efectividad.

Se considera la simulación como una actividad en la que el estudiante no acumula información teórica, sino que la lleva a la práctica, con lo cual esta se identifica con el entrenamiento puramente.

El empleo de la simulación en el proceso de formación de profesionales tiene sus particularidades, dadas en la explotación de simulaciones que modelen actividades de aplicación, preferiblemente incluyendo la presencia de instrumentos virtuales, funcionamiento de circuitos, dispositivos, procesos productivos, etc., con vistas a potenciar una actuación de los futuros profesionales acorde a los requerimientos de su futuro contexto laboral.

22.

Respecto a la contratación experimental tradicional, la simulación ofrece las siguientes ventajas:

Ofrece la posibilidad de repetir, en condiciones idénticas y a partir de su modelación, procesos y fenómenos, algo difícil de lograr en condiciones reales, y por tanto, estudiar sistemáticamente sus comportamientos hasta lograr los objetivos deseados. Se optimiza así el proceso de aprendizaje. Elimina los riesgos que siempre se presentan en la interacción con la realidad, tanto para dispositivos, instrumentos, etc., como para los estudiantes; con lo que se crea confianza en ellos para implicarse en el estudio de esa realidad. Permite la realimentación inmediata, pues los efectos que se logran en el funcionamiento del sistema, fenómeno o proceso que se simula, como resultado de introducir modificaciones en determinados parámetros, resultan inmediatos; lo que permite corregir la actuación del estudiante en cada momento.

4.1.4. POO. Programación Orientada a Objetos. 1

El término de Programación Orientada a Objetos indica más una forma de diseño y una metodología de desarrollo de software que un lenguaje de programación, ya que en realidad se puede aplicar el Diseño Orientado a Objetos (En inglés abreviado POO, Object Oriented Design), a cualquier tipo de lenguaje de programación.

El desarrollo de la POO empieza a destacar durante la década de lo 80 tomando en cuenta la programación estructurada, a la que engloba y dotando al programador de nuevos elementos para el análisis y desarrollo de software.

La POO permite a los programadores escribir software, de forma que esté organizado en la misma manera que el problema que trata de modelizar. Los lenguajes de programación convencionales son poco más que una lista de acciones a realizar sobre un conjunto de datos en una determinada secuencia. Si en algún punto del programa modificamos la estructura de los datos o la acción realizada sobre ellos, el programa cambia.

La POO aporta un enfoque nuevo, convirtiendo la estructura de datos en el centro sobre el que pivotan las operaciones. De esta forma, cualquier modificación de la estructura de datos tiene efecto inmediato sobre las acciones a realizar sobre ella, siendo esta una de las diferencias radicales respecto a la programación estructurada.

1 BALENA, Francesco. Programación Avanzada con Microsoft Visual Basic .NET. España: McGraw-Hill 2003. pag 168

23.

En esta forma de diseño se descomponen los requerimientos del programa paso a paso, hasta llegar a un nivel que permite expresarlos mediante procedimientos y funciones. La POO estructura los datos en objetos que pueden almacenar, manipular y combinar información.

En resumen, la programación estructurada presta atención al conjunto de acciones que manipulan el flujo de datos (desde la situación inicial a la final), mientras que la programación orientada a objetos presta atención a la interrelación que existe entre los datos y las acciones a realizar con ellos. La POO proporciona las siguientes ventajas sobre otros lenguajes de programación

Uniformidad. Ya que la representación de los objetos lleva implícita tanto el análisis como el diseño y la codificación de los mismos.

Comprensión. Tanto los datos que componen los objetos, como los procedimientos que los manipulan, están agrupados en clases, que se corresponden con las estructuras de información que el programa trata.

Flexibilidad. Al tener relacionados los procedimientos que manipulan los datos con los datos a tratar, cualquier cambio que se realice sobre ellos quedará reflejado automáticamente en cualquier lugar donde estos datos aparezcan.

Estabilidad. Dado que permite un tratamiento diferenciado de aquellos objetos que permanecen constantes en el tiempo sobre aquellos que cambian con frecuencia permite aislar las partes del programa que permanecen inalterables en el tiempo.

Reusabilidad. La noción de objeto permite que programas que traten las mismas estructuras de información reutilicen las definiciones de objetos empleadas en otros programas e incluso los procedimientos que los manipulan. De esta forma, el desarrollo de un programa puede llegar a ser una simple combinación de objetos ya definidos donde estos están relacionados de una manera particular.

Uno de los puntos clave a remarcar es que la programación orientada a objetos no sustituye a ninguna metodología ni lenguaje de programación anterior. Todos los programas que se realizan según POO se pueden realizar igualmente mediante programación estructurada. Su uso en la actualidad se justifica porque el desarrollo de todas las nuevas herramientas basadas en un interfase de usuario gráfico como Windows, OS/2, x-Windows, etc. Es mucho más sencillo.

Los lenguajes POO incorporan la posibilidad de encapsular también las estructuras de datos que sirven como base a las funciones. Aportan por tanto un nivel superior en cuanto a protección de información.Identidad, clasificación, polimorfismo y herencia caracterizan a los lenguajes orientados a objetos. Cada uno de estos conceptos puede utilizarse aisladamente, incluso aparecen en otras metodologías de programación, pero juntos se

24.

complementan en una relación sinérgica. Los beneficios de la programación orientada a objetos son más que los que pueden verse a simple vista. El énfasis en las propiedades esenciales de un objeto, fuerza al desarrollador a pensar cuidadosamente que es un objeto y que es lo que hace con el resultado de que el sistema es normalmente más preciso, general y robusto que si pusiéramos el énfasis en los procedimientos y los datos por separado

Los requerimientos anteriores afectan la elección de un lenguaje orientado a objetos como herramienta para el desarrollo de programas en:

Claridad. Al ligar de forma evidente la estructura de la información con los procedimientos que la manipulan, los programas ganan en claridad a la hora de desarrollarlos y mantenerlos. Esto supone una ventaja frente a los lenguajes procedurales, aunque éstos podrían suplir esta deficiencia mediante una correcta elección de los nombres de las variables y funciones, lo que se denomina una <<oportuna codificación>>.

Complejidad. Cuando la complejidad de un problema es abarcable por una sola persona, resolverlo con una herramienta u otra no aporta grandes ventajas. Pero cuando este desarrollo la tiene que realizar un equipo grande, debe existir una forma para aislar partes de problema.

Tamaño. Las aplicaciones orientadas a objetos son ideales para la realización de programas de gran tamaño. Las facilidades de encapsulación y asociación de las funciones a los datos que manipulan, simplifican el proceso de desarrollo. De hecho las bases de datos orientadas a objetos suponen un gran adelanto, ya que aúnan la flexibilidad en la manipulación de los POO con la capacidad de consulta de un DBMS (Data Base Management System)

Relación entre Datos. Por el mismo motivo se verán beneficiados aquellos programas que impliquen una relación compleja entre los datos. Este tipo de complejidad permite la utilización de todas las ventajas de los lenguajes de programación orientados a objetos. Propiedades como la herencia (donde los objetos pueden heredar estructura y operaciones de objetos predecesores), la encapsulación, etc. Muestran en este tipo de programas todas sus ventajas.Rapidez. En este aspecto, los lenguajes orientados a objetos muestran una clara desventaja frente a otros lenguajes que se acercan más a las especificaciones de la máquina. Si la rapidez es crítica, se puede elegir un lenguaje de programación como C++, que aporta toda la funcionalidad de los lenguajes orientados a objetos con la rapidez y la compatibilidad de C.

Gestión de recursos. Las aplicaciones orientadas a objetos demandan normalmente más recursos del sistema que las aplicaciones procedurales. La creación dinámica de objetos, que ocupa un lugar en la memoria del ordenador, puede acarrear graves problemas. Una de las soluciones, que incluye alguno de los lenguajes OOP, es

25.

liberar a menudo el espacio que los objetos dejan de utilizar. Este procedimiento de optimización como garbage collection (recolección de basura, implementado en java), minimiza los efecto de la creación dinámica de objetos.

Interface de usuario. El interface de usuario es uno de los aspectos más importantes en la programación actual. La aparición de sistemas de explotación que soportan un interface gráfico de usuario como Windows, X-Windows o Presentación Manager hace que la mayoría de los usuarios prefieran que sus programas corran bajo este tipo de interface. Este es uno de los puntos fuertes para la elección de un lenguaje POO. La mayoría de los interfaces gráficos actuales han sido diseñados o rediseñados en base a la POO. Existen en el mercado librerías de clases que soportan todos los dispositivos de control de ventanas como menús, combobox, listas, barras de herramientas, etc.

Lenguajes orientados a objetos. Los lenguajes OOP implementan de manera distinta los conceptos de programación orientada a objetos. No existe el lenguaje perfecto capaz de satisfacer todas las necesidades y que se adapte a todos los estilosA Continuación unos consejos que facilitarán la elección del lenguaje de programación adecuado:

· Si los programas se van a sentar en una cualidad concreta de los POO como herencia, se debe elegir el que mejor soporte le dé.· Los lenguajes interpretados sirven para realizar un desarrollo rápido o para aquellos programas que necesiten una actualización constante. Si el programa necesita rapidez o es crítico respecto al tamaño, se debe considar el uso de lenguajes que incorporen compilador.

· No <<reinvente la rueda>>. Si el lenguaje le proporciona una librería de clases no existe el porque reescribirlas de nuevo, se debe usar las que le ofrece el sistema. Es más se debe tomar como factor de elección las librerías de clases que el compilador incorpora o que estén disponibles en el mercado.· Si se necesita mejorar la calidad del programa previniendo errores, utilice un lenguaje que permita definir las variables con sus tipos asociados.· Si la memoria del sistema es limitada, utilizar lenguajes que permitan la creación y destrucción automática de clases dependiendo de su utilización.

4.1.4.1. Características de los Lenguajes POO:

Herencia múltiple. Esta característica suele ser común a la mayoría de los lenguajes POO, aunque introduce un problema al existir la posibilidad de que el objeto sucesor herede el mismo atributo, aunque con distinto tipo y valor, de mas de un predecesor. Alguno de los lenguajes de programación soluciona este problema de forma automática, aunque los más populares generan un error en el tiempo de compilación.

26.

Eficiencia. Los lenguajes POO arrastraron en un principio la reputación de ser ineficaces. Esto se debía en gran medida a que los primeros lenguajes (como Smalltalk) eran interpretados y no compilados. La existencia de compiladores permite a los desarrolladores ganar rapidez. Actualmente, usando un buen lenguaje orientado a objetos como C++, Java, etc. Junto con las librerías apropiadas para la realización de un programa, puede que se ejecute más rápidamente que el mismo programa compilado con un lenguaje procedural.

Asignación de tipos. Los lenguajes orientados a objetos varían de forma sustancial la forma por la que se aproximan a la asignación de tipos. Por asignación de tipos entendemos que cada variable sea identificada como perteneciente a una clase (asignación fuerte) o sea simplemente un objeto indeterminado (asignación débil). Eiffel y C son dos lenguajes basados en la asignación fuerte, frente a Smalltalk, en el que todas las variables definidas pertenecen a una clase indeterminada.La asignación fuerte sirve a dos propósitos. Por una parte para que el desarrollador pueda identificar a que clase pertenece cada operación. De forma concreta, en aquellos lenguajes donde está implementado el operator overloading (refefinición de operador), el compilador puede reconocer a través de las clases que entran como parámetros en la operación que operación tiene que utilizar.

Por otra, este tipo de declaración permite al compilador un mayor grado de optimización, ya que conoce en todo momento el espacio que ha de asignar

Manejo de memoria. Los POO son lenguajes que utilizan de manera intensiva la memoria de la computadora. Hay dos tipos de aproximación a la gestión de memoria.El sistema en tiempo de ejecución libera la memoria automáticamente a medida que los objetos dejan de utilizarse.

El sistema tiene instrucciones concretas para liberar la memoria explícitamente. Este el enfoque adoptado por lenguajes como C++, que aportan dos operadores: crear y destruir. El primero reserva automáticamente memoria, mientras que el segundo la libera.

Encapsulación. Consiste en separar aquellos atributos del objeto que deben ser conocidos por el resto, de aquellos necesarios para su funcionamiento propio. No es propio de los lenguajes orientados a objetos, pero la capacidad de éstos para unir las estructuras de datos a los procedimientos que los modifican lo hacen más potente que los lenguajes llamados <<Modulares>>

4.1.5. Base de Datos.

27.

Un archivo es un elemento de información conformado por un conjunto de registros. Estos registros a su vez están compuestos por una serie de caracteres o bytes. Los archivos, alojados en dispositivos de almacenamiento conocidos como memoria secundaria, pueden almacenarse de dos formas diferentes: archivos convencionales o bases de datos.

Los archivos convencionales, pueden organizarse como archivos secuenciales o archivos directos. Sin embargo, el almacenamiento de información a través de archivos convencionales presenta una serie de limitaciones que restringen de manera importante la versatilidad de los programas de aplicación que se desarrollan.

Archivos convencionales. El uso de sistemas de información por parte de las organizaciones requiere el almacenamiento de grandes cantidades de información, ya sea para el uso mismo del sistema, para generar resultados o para compartir dicha información con otros sistemas.

Las formas en las cuales pueden organizarse son archivos secuenciales o archivos directos. En los archivos secuenciales los registros están almacenados en una secuencia que depende de algún criterio definido. Por ejemplo, pueden almacenarse los registros de los empleados de la empresa de manera secuencial de acuerdo al departamento al que pertenecen o de acuerdo a su antigüedad.

Si se desea consultar o modificar información, también es necesario buscar uno por uno en los registros hasta encontrarla.

Los archivos directos permiten acceder directamente un registro de información sin tener que buscar uno a uno por todos los registros del archivo, utilizando una llave de acceso dentro del archivo.

Definición de Base de Datos. Se define una base de datos como una serie de datos organizados y relacionados entre sí, los cuales son recolectados y explotados por los sistemas de información de una empresa o negocio en particular.

Las bases de datos proporcionan la infraestructura requerida para los sistemas de apoyo a la toma de decisiones y para los sistemas de información estratégicos, ya que estos sistemas explotan la información contenida en las bases de datos de la organización para apoyar el proceso de toma de decisiones o para lograr ventajas competitivas. Por este motivo es importante conocer la forma en que están estructuradas las bases de datos y su manejo.

Componentes principales. Datos. Los datos son la Base de Datos propiamente dicha.

28.

Hardware. El hardware se refiere a los dispositivos de almacenamiento en donde reside la base de datos, así como a los dispositivos periféricos (unidad de control, canales de comunicación, etc.) necesarios para su uso.

Software. Está constituido por un conjunto de programas que se conoce como Sistema Manejador de Base de Datos (DMBS: Data Base Management System). Este sistema maneja todas las solicitudes formuladas por los usuarios a la base de datos.

Usuarios. Existen tres clases de usuarios relacionados con una Base de Datos:

1. El programador de aplicaciones, quien crea programas de aplicación que utilizan la base de datos. 2. El usuario final, quien accesa la Base de Datos por medio de un lenguaje de consulta o de programas de aplicación. 3. El administrador de la Base de Datos (DBA: Data Base Administrator), quien se encarga del control general del Sistema de Base de Datos.

Ventajas en el uso de Bases de Datos. Globalización de la información. Permite a los diferentes usuarios considerar la información como un recurso corporativo que carece de dueños específicos.

Eliminación de información redundante, duplicada.

Eliminación de información inconsistente. Si el sistema esta desarrollado a través de archivos convencionales, dicha cancelación deberá operarse tanto en el archivo de facturas del Sistema de Control de Cobranza como en el archivo de facturas del Sistema de Comisiones.

Permite compartir información. Varios sistemas o usuarios pueden utilizar una misma entidad.

Permite mantener la integridad en la información. Solo se almacena la información correcta.

Independencia de datos. La independencia de datos implica un divorcio entre programas y datos; es decir, se pueden hacer cambios a la información que contiene la base de datos o tener acceso a la base de datos de diferente manera, sin hace cambios en las aplicaciones o en los programas

29.

4.1.6. Ingeniería Del Software.

El desarrollo de sistemas de información computarizados consta de dos partes principales, el Análisis de sistemas y Diseño de sistemas.

Análisis de sistemas. El Análisis de sistemas, es un proceso de recolección, clasificación e interpretación de información y hechos, además de la identificación y diagnóstico de problemas. El tratamiento conjunto de los anteriores elementos permite obtener conclusiones acerca del estado de la organización y recomendar acciones que mejorarán su sistema de información. Hay muchas maneras de enfrentarse el análisis de sistemas y todas están orientadas básicamente al mismo objetivo: entender un sistema complejo y modificarlo de alguna manera. Las modificaciones pueden consistir en un subsistema nuevo, componentes nuevos, un nuevo conjunto de transformaciones, etc. El objetivo es mejorar el funcionamiento interno del sistema para hacerlo más eficiente, modificar las metas del sistema, cambiar las señales de salida, lograr las mismas metas con un conjunto diferente de señales de entrada, realizar algunas mejoras similares o simplemente crear uno nuevo.

Diseño de sistemas. El Diseño de sistemas es el proceso en el cual se planifica como se ejecutarán las recomendaciones dadas en el paso anterior. En él se puede contemplar desde complementar el sistema, hasta reemplazarlo totalmente, pasando por la consideración de modificaciones parciales. En el proceso se determina también el papel que desempeñarán las computadoras para hacer más eficiente el desempeño del sistema.

Las metodologías que se han utilizado hasta este momento para desarrollar software, las denominaremos “Metodologías tradicionales de Análisis y Diseño de Sistemas de Información”, las cuales se fundamentan en la descomposición del sistema en subsistemas funcionales.

Metodologías tradicionales de análisis y diseño. En la década de los ochenta, se consolidaron las metodologías tradicionales de desarrollo de software aplicables a diferentes sistemas de información. Los enfoques o métodos más importantes son los siguientes:

4.1.6.1. Método del ciclo de vida para desarrollo de sistemas.

4.1.6.2. Método de desarrollo por Análisis y Diseño Estructurado.

4.1.6.3. Método de desarrollo de sistemas por prototipos.

30.

El primero es considerado por muchos autores, como un enfoque general para el desarrollo de software, más que un método.

El método del ciclo de vida para el desarrollo de sistemas. Se divide según Kendall en siete etapas, a saber:

Identificación de problemas, oportunidades y objetivos. Determinación de los requerimientos de información. Análisis de las necesidades del sistema. Diseño del sistema recomendado. Desarrollo y documentación del software. Prueba y mantenimiento del sistema. Implantación y evaluación del sistema.Se puede considerar como el método genérico por excelencia para el desarrollo de sistemas computarizados de información. Se aplica a casos en los que el desarrollo del sistema se puede manejar como proyecto y cubre varios departamentos de la empresa.

El método de desarrollo por análisis y diseño estructurado. Consta de dos fases principales, el Análisis y el Diseño de sistemas. En la mayoría de los casos se utiliza complementariamente con el Método de Ciclo de Vida, es decir se enmarca dentro de él. Se basa, como ya se dijo en la introducción, en la descomposición de un sistema complejo en subsistemas funcionales. Esto último es quizá, lo que lo ha convertido en la metodología de mayor éxito en el ámbito de las metodologías tradicionales.

Es adecuado para abordar el Desarrollo de todo tipo de Aplicaciones, principalmente cuando se trata de sistemas complejos que pueden dividirse en partes menos complejas.

El Método de desarrollo de sistemas por prototipos. Se basa precisamente en la construcción de prototipos. Un prototipo es un sistema que funciona como cualquier otro sistema, sólo que no es un sistema finalizado sino que necesita ser perfeccionado reiterativamente. Se construye con el propósito de probar conjeturas, ideas y suposiciones relacionados con el nuevo sistema. Permite evaluar el diseño y la información de salida a partir de datos de entrada, que deben ser completamente reales para lograr la mayor efectividad.

Es recomendable su uso en las siguientes condiciones: cuando se tiene poca información sobre el sistema de estudio, los costos y riesgos de cometer errores son altos y cuando se tiene poca experiencia en desarrollo de algún tipo especial de sistema.

Rational Unified Process (Rup): Es un proceso de Ingeniería de Software planteado por Kruchten (1996) cuyo objetivo es producir software de alta calidad, es

31.

decir, que cumpla con los requerimientos de los usuarios dentro de una planificación y presupuesto establecidos.RUP toma en cuenta las mejores prácticas en el modelo de desarrollo de software en particular las siguientes:• Desarrollo de software en forma iterativa (repite una acción).• Manejo de requerimientos.• Utiliza arquitectura basada en componentes.• Modela el software visualmente (Modela con Unified Modeling Language, UML)• Verifica la calidad del software.• Controla los cambios.El proceso iterativo de RUP se organiza en fases (Kruchten, 1996), cada fase seConcluye con una piedra de milla (mile stone) principal.

Es importante resaltar que la inclusión de piedras de millas o puntos de revisión, es sumamente importante y en estos puntos se revisan los requerimientos establecidos para cada fase, basados en los controles de calidad. De esta manera, si un producto o proceso no pasa el punto de revisión de calidad, se rediseña o se cancela, evitando así, los problemas de coste extra, de trabajo, y de productos de mala calidad, que no satisfacen los requerimientos establecidos a nivel educativo, comunicacional, técnico y de diseño gráfico. En la figura 2 se puede observar la expresión gráfica equivalente al tiempo y esfuerzo que se dedican a cada una de las fases de RUP. En esta gráfica se puede observar que la inversión de tiempo y esfuerzo en la primera fase y segunda fase es pequeña en comparación con la tercer fase, garantizando así que la mayor parte del trabajo, costo y esfuerzo se realice si y solo si, ha pasado la segunda piedra de milla, o sea, el segundo control de revisión de calidad.

Figura 2. Esquema de RUP (Proceso unificado Racional)

32.

4.1.7. UML. Unified Modeling Language.2

El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software. UML entrega una forma de modelar cosas conceptuales como lo son procesos de negocio y funciones de sistema, además de cosas concretas como lo son escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de software reusables.

“...Cuando los primeros programadores comenzaron a crear aplicaciones para usuarios de negocios, una vez más las figuras llegaron al rescate, varias técnicas con orientación grafica tal como la producción de diagramas de definición de datos usado por programadores y los diagramas entidad-relación usados por aplicaciones de base de datos relacionales, llegaron a convertirse en el principal enfoque para facilitar el análisis y diseño tan bien como un recurso de registro y comunicación de requerimientos de sistemas. Hoy, en el mundo orientado a objetos y de la computación distribuida, los diagramas UML sirven a este propósito.…UML ofrece un recurso estándar de la industria de modelado de sistemas complejos. El modelado es un concepto básico de objetos orientados al desarrollo. Uno de los principales beneficios de modelar es que el proceso de desarrollo es más productivo y sus sistemas se desarrollaran más en encontrar requerimientos. …Llena el vació entre el mundo de los clientes, usuarios, y analistas entendiendo la de los desarrolladores, ingenieros, y arquitectos implementadores de sistemas. …UML

2 STEVENS, Perdita. Utilización de uml en ing. De l software con objetos y componentes.Madri: pearson Educación,

33.

ayuda a capturar sus requerimientos. Permite definir que es lo que debe hacer el sistema, a través de casos de uso y de actividades, y permite representar gráficamente los objetos que hará. …UML 1.5 incluye nueve tipos diferentes de diagramas, mucho de los cuales son especialmente relevantes para el desarrollo.…por ejemplo, los diagramas de maquina de estados son realmente relevantes para aplicaciones de tiempo real, pero mucho menos relevante para el modelado de aplicaciones enfocado a datos…”3

Modelo de Clases

Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.

Un diagrama de clases esta compuesto por los siguientes elementos:

Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso. Clase: Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde:

o Superior: Contiene el nombre de la Clase o Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public). o Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Atributos y Métodos:

3

34.

o Atributos: Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son: public (+): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. private (-): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden acceder). protected (#): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser acezado por métodos de la clase además de las subclases que se deriven (ver herencia). o Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características: public (+): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. private (-): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden acceder). protected (#): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser acezado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia). Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes).

Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:

uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n) número fijo: m (m denota el número).

Herencia (Especialización/Generalización):

Indica que una subclase hereda los métodos y atributos especificados por una Superclase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Superclase (public y protected),

Agregación:

35.

Para modelar objetos complejos, no bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:

Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo"). Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).

La flecha en este tipo de relación indica la navegabilidad del objeto referenciado. Cuando no existe este tipo de particularidad la flecha se elimina.

Asociación:

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.

Dependencia o Instanciación (uso):

Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el objeto Aplicación):

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicación).

Casos Particulares:

Clase Abstracta:

36.

Una clase abstracta se denota con el nombre de la clase y de los métodos con letra "itálica". Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos (aún no han sido definidos, es decir, sin implementación). La única forma de utilizarla es definiendo subclases, que implementan los métodos abstractos definidos.

Clase parametrizada:

Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los parámetros que deben ser pasados a la clase para que esta pueda ser instanciada. El ejemplo más típico es el caso de un Diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden ser genéricos. La generalidad puede venir dada de un Template (como en el caso de C++) o bien de alguna estructura predefinida (especialización a través de clases).

Casos de Uso (Use Case)

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso).

Un diagrama de casos de uso consta de los siguientes elementos:

Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicación.

Elementos

Actor:

Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.

37.

Caso de Uso:

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

Relaciones:

o Asociación

Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

o Dependencia o Instanciación

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.

o Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).

uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.

De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.

Diagrama de Interacción

38.

El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en petición a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades claramente.

Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o el de Casos de Uso (son diferentes).

Los componentes de un diagrama de interacción son:

Un Objeto o Actor. Mensaje de un objeto a otro objeto. Mensaje de un objeto a si mismo.

Elementos

Objeto/Actor:

El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa las llamadas a métodos del objeto. 4

Mensaje a Otro Objeto:

Se representa por una flecha entre un objeto y otro, representa la llamada de un método (operación) de un objeto en particular.

Mensaje al Mismo Objeto:

4 STEVENS, Perdita pag 120

39.

No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a métodos desde el mismo objeto en estudio

40.

4.2.MARCO CONCEPTUAL

BASE DE DATOS: colección de archivos interrelacionados, son creados con un DBMS (Sistema Manejador de Base de Datos). El contenido de una base de datos engloba a la información concerniente de una organización, de tal manera que los datos estén disponibles para los usuarios, una finalidad de las base de datos es eliminar la redundancia o al menos minimizarla. Los tres componentes principales de un sistema de base de datos son el hardware, el software DBMS y los datos a manejar.

CLASE: es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio

HERENCIA: es la capacidad de derivar una nueva clase (la clase derivada o heredada) de una clase más sencilla (la clase base). La clase derivada hereda todos los campos, propiedades y métodos de la clase base y puede modificar el comportamiento de cualquiera de estas propiedades y métodos para remplazarlas. También podrá agregar nuevos campos, propiedades y métodos a las clases heredadas.

IMPLANTACIÓN: proceso de puesta en funcionamiento del sistema. En esta fase se verifica que el sistema cumple todos los requisitos, que es capaz de manipular los volúmenes de información requeridos, de trabajar dentro de los tiempos de respuesta deseados, etc. INFORMACIÓN: es un conjunto de datos organizados de manera consistente, referentes al objeto de interés los cuales son manejados según la necesidad del usuario.

SISTEMA: conjunto de partes que desarrollan actividades y se interrelacionan para cumplir con un fin dado.

SOBRECARGA: es proporcionar varios métodos con el mismo nombre pero con diferentes firmas de parámetros, es decir con un numero distinto de parámetros o con parámetros de diferentes tipos.

SOFTWARE: serie de instrucciones que se cargan en la memoria de la computadora que le indican como resolver un problema o llevar a cabo una tarea, llamado también programa y aplicativo.

41.

SISTEMA DE REFRIGERACIÓN: proceso por el que se reduce la temperatura de un espacio determinado y se mantiene esta temperatura baja con el fin, por ejemplo, de enfriar alimentos, conservar determinadas sustancias o conseguir un ambiente agradable.

UML (Unified Modeling Language): lenguaje Unificado de Modelado, es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema software. Se usa para entender, diseñar, configurar, mantener y controlar la información sobre los sistemas a construir.

TECNOLOGÍA .NET: termino que hace referencia al entorno de programación de Visual Studio .NET; la Programación es orientada a objetos real, incluyendo características avanzadas como herencia y sobrecarga de métodos. Encontrar un paradigma común de programación para las aplicaciones relacionadas con Internet, fue una de las razones primordiales del surgimiento de este nuevo lenguaje que interrumpe de forma abrupta la manera de programación de todos aquellos que han programado en versiones anteriores de este lenguaje. Ofrece una visión orientada a objetos del sistema operativo Windows e incluye cientos de clases que encapsulan los objetos más importantes del núcleo de Windows. La especificación de lenguaje común (CLS) es un conjunto de especificaciones que Microsoft ha suministrado para ayudar a los fabricantes de compiladores. Estas especificaciones fijan el grupo mínimo de características que un lenguaje .NET debe tener. Los lenguajes compatibles con CLS son VB.NET, C#, manager C++ y JScript. Muchos otros fabricantes de lenguajes están trabajando en el desarrollo de lenguajes .NET como lo son, Perl, Cobol, Smalltalk, Eiffel, Python, Pascal y APL.5

5 BALENA, Francesco. Programación Avanzada con Microsoft Visual Basic .NET. España: McGraw-Hill 2003 pag 64

42.

5. DISEÑO METODOLÓGICO6

Para el proceso de desarrollo de software se aplico la metodología del Proceso unificado de Racional (RUP), el cual nos permite aplicar un enfoque disciplinado para la construcción, desarrollo y mantenimiento del software. Además de ser un marco de trabajo genérico, es un conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software, a través de cuatro fases donde cada una tiene objetivos y termina con modelos o documentos desarrollados que han alcanzado un estado predefinido. Dentro de cada fase se descompone adicionalmente el trabajo en iteraciones o mini-proyectos. El Proceso Unificado utiliza el Lenguaje Unificado de Modelado (UML) para preparar todos los esquemas de un sistema software.

En el desarrollo del proyecto se seguirá la metodología RUP en la cual el desarrollo se organiza en una serie de mini-proyectos o iteraciones dentro de cada una de las fases definidas en dicha metodología, con el fin de obtener un sistema que pueda ser probado y ejecutado.

A continuación se presentan cada una de las fases,

5.1.Fase de Inicio

5.1.1. Definición del alcance y estudio de factibilidad del proyecto.

5.1.2. Entrevista con el jefe. Entrevistas realizadas al personal encargado de manejar directamente la información de interés para el proyecto. Estas entrevistas será realizadas por los responsables del proyecto y complementadas con la observación directa de la manipulación de los datos, lo que nos ayudará a una identificación clara de los datos necesarios para la creación del sistema.

El usuario (Profesor o Estudiante en los casos de usos detallados realizan las mismas operaciones) diseña su sistema de refrigeración, empleando los elementos que suministrará la

6 PRESSMAN, Roger. Ingeniería del Software, Un Enfoque Práctico. Cuarta Edición. Madrid (España). McGraw-Hill, 1998. pag 143

43.

herramienta software como son: evaporador, condensador, compresor, dispositivo de expansión, intercambiador, filtro secador, separador de aceite, recibidor de liquido y acumulador de succión. Una vez considere este listo se ejecutaría, sino se encuentra error en su diseño. De ser así, se debe mostrar un mensaje acorde al error encontrado.En la ejecución del diseño se debe mostrar una animación del sistema creado, permitiéndole al usuario pasar del estado de ejecución al de diseño donde podrá adicionar otro elemento.El aplicativo debe mostrar las graficas de comportamiento del sistema diseñado que son T-s y P-h para un refrigerante, Temperatura de evaporación, temperatura de condensación y carga dados por el usuario. Además de obtener los valores de las variables Cantidad de refrigerante en circulación, Potencia del compresor, Coeficiente de funcionamiento y Relación de compresión.También de mostrar durante la animación información de teoría de Refrigeración; Además de líneas por donde se encuentre el refrigerante en estado liquido o vapor.

5.1.3. Recolección y tratamiento de la información requerida para la realización del Software.

5.1.4. Revisión y estudio de la información recolectada, La información recolectada se consignará en formatos diseñados para tal efecto, teniendo en cuenta que las entradas, transformaciones y salidas que se dan en los procesos, queden plasmadas de una forma clara para un mejor entendimiento de los mismos. Estos formatos serán diligenciados por parte nuestra y en algunos casos, serán modificados por el personal directamente encargado en la planta piloto de taganga.

5.1.5. Identificación y clasificación de procesos.

44.

5.1.6. Definición de una visión aproximada del proyecto; se encuentra un modelo de casos de usos simplificados que contenga los casos de usos más críticos.

5.1.7. Definición del alcance y estudio de factibilidad del proyecto

Durante el desarrollo de los laboratorios de refrigeración existe el peligro latente de dañar los componentes del sistema, de refrigeración, por el uso inadecuado que se le puede llegar a dar a elementos delicados o costosos; lo que suscita la vigilancia constante del instructor durante la realización de estas actividades, para prevenir la manipulación inadecuada, de las cuales podría no requerirse su total acompañamiento en algunas de estas.

El uso de sistemas de refrigeración durante prácticas trae consigo el desgaste progresivo de componentes causado por la propia actividad, el empleo inadecuado o el factor humano; consiguiéndose un costo para el sostenimiento o mantenimiento del sistema de refrigeración

Los costos de reparación o mantenimiento pueden convertirse en impedimento para no realizar alguna práctica, por el no desembolso o el mismo tiempo que se toma para cumplir con el procedimiento en estos casos.

Esta situación hace necesaria la implementación de herramientas que permitan generar habilidades en estudiantes, de disminuir o controlar aquellas manipulaciones que pueden representar riesgo al sistema de refrigeración; al mismo tiempo de reducir costos de mantenimiento.

La incorporación de una herramienta que simule y muestre el comportamiento del sistema de refrigeración por compresión de vapor, con situaciones anormales del sistema, que permita preparar a los estudiantes antes de tener un acercamiento directo con un sistema real de refrigeración además de fortalecer los conocimientos; es la razón que motiva a los autores a mostrar la alternativa de un software o aplicativo como la herramienta de apoyo para el estudio de sistemas de refrigeración.

La elaboración de este proyecto se convertirá en el primer paso o la primera fase de uno mayor que contará con características adicionales, como la de implementación de otros ciclos de refrigeración de vapor como el multietapa, de cascada y otros sistemas como el de absorción, adicionando otros refrigerantes ya que este solo cuenta con dos tipos . Como también seria el de controlar directamente un sistema de refrigeración, funcionalidades que no serán implementadas en este proyecto.

45.

5.1.8. Factibilidad técnica y tecnológica

Contando con métodos de desarrollo de Software, POO, UML y BD; el producto se apoyará en técnicas de ingeniería para el análisis y desarrollo de software que permitan obtener un sistema de alta calidad que cumpla con las necesidades del usuario. Además de disponer con un lenguaje para el desarrollo o codificado de aplicaciones Windows como lo es Visual Basic.NET.

5.1.9. Factibilidad operativa

La planta piloto de taganga, cuenta con una infraestructura adecuada y con las herramientas de software necesarias para la puesta en marcha del proyecto, en el proceso de consolidación del software de simulación de sistemas de refrigeración por compresión de vapor (ciclo ideal) para el laboratorio de refrigeración mecánica de esta dependencia de la Universidad del Magdalena.

5.1.10. Recolección y tratamiento de la información requerida para la realización del Software.

Información relacionada con Sistemas de Refrigeración, documentación acerca de las herramientas de análisis y diseño de sistemas. Revisión de documentos relacionados con Teoría de Refrigeración. Consultas en Internet con el fin de obtener información actualizada sobre herramientas de análisis y diseño de sistemas. Consultas bibliográficas de temas relacionados con los Sistemas de Bases de Datos, Sistemas de Información, etc.

5.1.11. Revisión y estudio de la información recolectada.

La información obtenida será clasificada por su naturaleza e importancia.

5.1.12. Definición de una visión aproximada del proyecto;

se encuentra un modelo de casos de usos simplificados que contenga los casos de usos más críticos.

46.

Figura 3. Definición de una visión aproximada

5.1.13. Identificación y clasificación de procesos.

Tabla 1. Descripción de los casos de uso

Nombre de Caso de Uso Insertar ComponenteNecesario/Deseable NecesarioPrioridad 1Descripción Permite ingresar un componente al

Panel o área de trabajoActor Principal EstudianteCurso Básico de eventos Seleccionar el tipo de componente

Adicionarlo al panel ActivoCaminos de excepción Ausencia de panel Precondiciones O Crear Nuevo Sistema o

Abrir ArchivoPost- Condiciones Enlazar Componente

Nombre de Caso de Uso Eliminar ComponenteNecesario/Deseable NecesarioPrioridad 1Descripción Permite eliminar un componente que

se encuentre seleccionado del Panel o área de trabajo

Actor Principal EstudianteCurso Básico de eventos Seleccionar Componente

Eliminar Enlaces

47.

Borrar Componente del panelCaminos de excepción Ausencia de ComponentesPrecondiciones Insertar ComponentePost- Condiciones

Nombre de Caso de Uso Enlazar componenteNecesario/Deseable NecesarioPrioridad 1Descripción Permite conectar el componente

seleccionado con otro que indique el Estudiante

Actor Principal EstudianteCurso Básico de eventos Seleccionar Componente

Elegir componente DestinoGraficar Enlace

Caminos de excepción Ausencia de ComponentePrecondiciones Insertar ComponentePost- Condiciones Ejecutar Sistema

Nombre de Caso de Uso Ejecutar SistemaNecesario/Deseable NecesarioPrioridad 1Descripción Coloca en marcha el funcionamiento

del sistema diseñado por el estudianteActor Principal EstudianteCurso Básico de eventos Comprobar sistema Enlazado

Comprobar Enlace correctoCaminos de excepción Ausencia de Sistema

Enlaces ErróneosPrecondiciones Enlazar ComponentePost- Condiciones Realizar Animación

Nombre de Caso de Uso Realizar AnimaciónNecesario/Deseable NecesarioPrioridad 1Descripción Muestra la puesta en marcha del

sistemaActor Principal Realizar CálculosCurso Básico de eventos Crear Líneas frías y calientes

Seleccionar Compresor del SistemaCaminos de excepción Enlaces IncorrectosPrecondiciones Enlazar componentePost- Condiciones Mostrar Información paso a paso

48.

Nombre de Caso de Uso Detener EjecuciónNecesario/Deseable NecesarioPrioridad 1Descripción Interrumpe la ejecución del sistema y

reanuda el entorno de diseñoActor Principal EstudianteCurso Básico de eventos Conocer Estado del SistemaCaminos de excepción No exista animaciónPrecondiciones Realizar AnimaciónPost- Condiciones Habilitar Entorno de Diseño

Nombre de Caso de Uso Mostrar Información Paso a PasoNecesario/Deseable NecesarioPrioridad 1Descripción Muestra Información de acuerdo a la

posición del punto que se desplaza durante la animación

Actor Principal EstudianteCurso Básico de eventos Conocer Estado actual de AnimaciónCaminos de excepción Ausencia de AnimaciónPrecondiciones Realizar animaciónPost- Condiciones

Nombre de Caso de Uso Realizar CálculosNecesario/Deseable NecesarioPrioridad 1Descripción Obtiene de capacidad del compresor,

la cantidad de refrigerante en circulación

Actor Principal Ejecutar SistemaCurso Básico de eventos Ingresar refrigerante, Temperatura de

condensación y de evaporaciónCaminos de excepción No existe SistemaPrecondiciones Ejecutar SistemaPost- Condiciones Ver Gráficos

Nombre de Caso de Uso Ver gráficosNecesario/Deseable NecesarioPrioridad 1Descripción Muestra Información del

comportamiento del sistema de acuerdo a unos parámetros dados por el Estudiante, de manera grafica

Actor Principal EstudianteCurso Básico de eventos Seleccionar Refrigerante

49.

Seleccionar Tipo de GraficoCaminos de excepción No se realizaron los cálculosPrecondiciones Realizar CálculosPost- Condiciones

Nombre de Caso de Uso Crear Nuevo SistemaNecesario/Deseable NecesarioPrioridad 1Descripción Habilita el entorno para el diseño de

un nuevo sistema de refrigeraciónActor Principal EstudianteCurso Básico de eventos Crear PanelCaminos de excepción Numero de paneles=5Precondiciones Numero de paneles<5Post- Condiciones Insertar Componente

Nombre de Caso de Uso Abrir SistemaNecesario/Deseable DeseablePrioridad 2Descripción Permite abrir un sistema diseñado por

el estudiante que fue guardadoActor Principal EstudianteCurso Básico de eventos Crear PanelCaminos de excepción No existe archivoPrecondiciones Guardar SistemaPost- Condiciones Ejecutar Sistema

Insertar ComponenteEnlazar Componente

Nombre de Caso de Uso Guardar SistemaNecesario/Deseable DeseablePrioridad 2Descripción Guarda el sistema diseñadoActor Principal EstudianteCurso Básico de eventos Seleccionar ComponentesCaminos de excepción No exista panelPrecondiciones Crear Nuevo Sistema

Crear PanelPost- Condiciones Abrir Sistema

50.

5.1.14. Definición de la arquitectura provisional, en esta etapa

Figura 4. Definición de la arquitectura provision

5.1.14.1. Clases Candidatas:

Evaporador, Condensador, FiltroSeca, DispositivoEx, Compresor, RecibeAceite (tiene una relación de composición con la clase compresor, por cada compresor deberá existir un objeto recibeAceite), intercambiador, AltaPresion(tiene una relación de composición con la clase intercambiador, por cada intercambiador deberá existir un objeto AltaPresion), Recibidor, Separador, RetornaAceite(tiene una relación de composición con la clase Separador, por cada Separador deberá existir un objeto RetornaAceite), Anotación

51.

5.2.Fase de Elaboración

Desarrollo de la fase de Elaboración

5.2.1. Se especifica en detalle la mayoría de los casos de uso

Figura 5. Modelo de casos de uso

52.

5.2.2. Definición e implementación del núcleo central de la arquitectura del sistema

figura6 .Modelo de clases

53.

5.2.3. Modelage de datos

5.2.3.1. Modelo Entidad Relación

Figura 7.Modelo entidad - relación

54.

5.2.3.2. . Modelo Lógico de la base de Datos

Lista de EntidadesTabla 2. Lista de entidades

Nombre Tipo Llave Primaria # atributos

REFRIGERANTE independiente Referencia 8

SOBRECALENTADO dependiente Referencia, Presion, Temp

6

Index_SOBRECALENTADO dependiente Referencia, Incremento

4

SATURADO dependiente F, Referencia 12

TEMA independiente NumTema 3

PAGINA dependiente NumTema, Pag 4

Tabla 'REFRIGERANTE': Almacena información de cada uno de los refrigerantes que soporta el aplicativoAtributos

Tabla 3. Tabla refrigeranteLlave Atributo Tipo No null Unique Descripción

Referencia Text SI NO Nombre conocido en la industria

Formula Text SI NO Formula Química

Nombre Text SI NO Nombre Común

TempMinima Long Integer SI NO Temperatura en ºF

TempMaxima

Long Integer SI NO Temperatura en ºF

Incremento Long Integer SI NO Salto de los valores de la Temperatura en ºF

zoomH Double SI NO Valor en que se ampliará en la grafica p-h

zoomS Long Integer SI NO Valor en que se ampliará en la grafica T-s

55.

Tabla 'SOBRECALENTADO': Almacena información de las propiedades Termodinámicas de los refrigerantes sobrecalentados.

AtributosTabla 4. Tabla sobrecalentado

Llave Atributo Tipo No null Unique Descripción

Referencia Text SI NO Nombre conocido en la industria

Presion Double SI NO

Temp Long Integer SI NO Temperatura ºF

V Double SI NO Volumen

H Double SI NO Entalpía

S Double SI NO Entropía

Tabla 'Index_SOBRECALENTADO': índice de acceso a la tabla Sobrecalentado

AtributosTabla 5. Tabla index_sobrecalentado

Llave Atributo Tipo No null Unique Descripción

Refrigerante Text SI NO

Incremento Long Integer SI NO Temperatura ºF

Pini Long Integer SI NO Presion Inicial

Pfin Long Integer SI NO Presión Final

56.

Tabla 'SATURADO': Almacena información de las propiedades Termodinámicas de los refrigerantes Saturado.

AtributosTabla 6. Tabla saturado

Llave Atributo Tipo No null Unique Descripción

F Long Integer SI NO Temperatura ºF (farengei)

Refrigerante Text SI NO

psi Double SI NO Presion en unidades psi

Vf Double SI NO Volumen en estado Liquido

Vfg Double NO NO Volumen mezcla Liquido-Gas

Vg Double SI NO Volumen en estado vapor

Hf Double SI NO Entalpía en estado liquido

Hfg Double NO NO Entalpía mezcla liquido-vapor

Hg Double SI NO Entalpía en estado vapor

Sf Double SI NO Entropía en estado Liquido

Sfg Double NO NO Entropía mezcla Liquido-vapor

Sg Double SI NO Entropía en estado vapor

Tabla 'TEMA': tabla que almacena información de la teoría de refrigeración por tema

Atributos

57.

Tabla 7. Tabla tema

Llave Atributo Tipo No null Unique Descripción

NumTema Long Integer SI NO No. De Tema

Nombre Text SI NO

Cantidad Long Integer NO NO Cantidad de Paginas

Tabla 'PAGINA': Información de los temas almacenada por paginas

AtributosTabla 8. Tabla pagina

Llave Atributo Tipo No null Unique Descripción

NumTema Long Integer SI NO No. De Tema

Pag Long Integer SI NO No. de pagina

Imagen Text SI NO

Texto Memo SI NO

.

58.

5.2.4. Catálogo de módulos de la aplicación

a) Módulos principales

Tabla 9. Módulos principales del sistema

Nombre Tipo FuncionalidadDiseñador

de Sistemas

de Refrigeraci

ón

Interfaz - Procedimiento

Inserción, eliminación y enlaces de componentes

Cálculos Interfaz - Procedimiento

Despliegue de datos obtenidos. Potencia del compresor, Cantidad de Refrigerante en circulación, coeficiente de funcionamiento, Relación de compresión y calor de Condensación

Grafica P-h

Interfaz - Procedimiento

Despliegue del comportamiento grafico del sistema diseñado

Grafica T-s Interfaz- Procedimiento

Despliegue del comportamiento grafico del sistema diseñado

Información paso a

paso

Interfaz- Procedimiento

Mostrar Información de la teoría de Refrigeración

Animación Interfaz- Procedimiento

Despliegue del funcionamiento del sistema.

b) Módulos auxiliares

Procedimientos Tabla 10. Módulos auxiliares

Nombre Invocado por FuncionalidadEjecución Animación Invocar a Evaluador de Sistema y colocar en

marcha un nuevo proceso donde se ejecutará la animación

Evaluador de sistema

Ejecución Informar de errores encontrados en sistema diseñado

59.

5.2.5. Modelo de Despliegue

A continuación se presentan formas o cuadros de diálogos que se deben incluir en el sistema informático.

Formulario Principal. Muestra la vista inicial del Software

Figura 8. Pantallazo inicial

60.

Cuadro de Dialogo para el enlace de componentes

Figura 9. Cuadro de Dialogo para el enlace de componentes

Usuario: Esta interfaz permite la selección del componente con el que se enlazará otro a su entrada.Frecuencia de Uso: A solicitud

Formulario de inserción de Nuevos componentes

Figura 10. Formulario de inserción de Nuevos componentes

61.

Usuario: Este formulario permite el ingreso de nuevos componentes al panel o Sistema mediante de botones establecidos en la barra de herramientas componentes.Frecuencia de Uso: A solicitud

Cuadro de Dialogo de Cálculos

Figura 11. Cuadro de Dialogo de Cálculos

Usuario: Permite la obtención de los valores de variables como son: Refrigerante en Circulación, Coeficiente de Funcionamiento, Relación de compresión, Potencia del Compresor. Para un refrigerante, un valor de Temperatura de evaporación y condensación y una carga definidas por el usuario.Frecuencia de Uso: A solicitud, cuando se ejecute el sistema

62.

Interfaz de animación

Figura 12. Interfaz de animación

Usuario: Representa el sistema diseñado mostrándolo con líneas frías y calientes, además del sentido de circulación del refrigerante mediante un punto que se desplaza.Frecuencia de Uso: A solicitud, definido el refrigerante a emplearse

63.

Interfaz de Información pasó a paso

Usuario: Despliegue de la teoría de Refrigeración durante la animación del sistema diseñado, de acuerdo a la ubicación del punto de desplazamiento.Frecuencia de Uso: A solicitud.

Figura 13. Interfaz de Información pasó a paso

Interfaz grafica P-h (Presión –Entalpía)

Figura 14. Interfaz grafica P-h (Presión –Entalpia)

Usuario: Despliegue del comportamiento del comportamiento grafico del sistema diseñado en su variación de presión y entalpíaFrecuencia de Uso: A solicitud, durante la ejecución

64.

Interfaz Grafica T-s (Temperatura – Entropía)Usuario: Despliegue del comportamiento del comportamiento grafico del sistema diseñado en su variación de Temperatura y entropíaFrecuencia de Uso: A solicitud, durante la ejecución

Figura 15. Interfaz grafica T-s (Temperatura – Entropía)

65.

5.2.6. Diagramas de Secuencia

Muestra el escenario crear nuevo sistema e ingresar un componente al panel

Seudocódigo:// Crear nuevo sistemaDeclarar variable panelCrear nuevo objeto panelAsignar variable panel a frmPrincipal como formulario hijoHabilitar funciones de frmPrincipalMostrar Nuevo panel

//Crear nuevo componente evaporador//Declarar y crear un nuevo objeto del tipo evaporadorNuevoEvaporador(frmPrincipal)

Funcion nuevoEvaporador(frmPrincipal)Establecer valores iniciales del componenteAsignar componente al panel activo

Fin

Figura 16 Diagramas de Secuencia. Escenario crear nuevo sistema

Muestra el escenario Crear nuevo sistema e ingresar un compresor

66.

Seudocódigo:

// Crear nuevo sistemaDeclarar variable panelCrear nuevo objeto panelAsignar variable panel a frmPrincipal como formulario hijoHabilitar funciones de frmPrincipalMostrar Nuevo panel

//Crear nuevo componente compresor//Declarar y crear un nuevo objeto del tipo compresorNuevocompresor (frmPrincipal)

Funcion Nuevocompresor (frmPrincipal)Establecer valores iniciales del componenteAsignar componente al panel activoDeclarar y crear un nuevo objeto del tipo RecibeAceiteRecibeAceite(frmPrincipal)

Funcion RecibeAceite (frmPrincipal)Establecer valores iniciales del componenteAsignar componente al panel activo

finfin

67.

Figura 17 Diagramas de Secuencia. Escenario crear nuevo sistema e ingresar un compresor

Muestra eliminar Componente. Aplica a Compresor y de forma similar a intercambiador y separador de aceite

Seudocódigo:

//Eliminar componente CompresorBorra (frmPrincipal)

Funcion Borra(frmPrincipal) Si esta enlazado entonces Quitar enlaces del componente

//Remover componente del panel activoPanel.remove(Compresor)

Fin

68.

Figura 18 Diagramas de Secuencia. Escenario eliminar Componente. Compresor , intercambiador y separador de aceite

Muestra eliminar Componente. Aplica a los demás componentes

Seudocódigo:

//Eliminar componente evaporadorBorra(frmPrincipal)

Funcion Borra (frmPrincipal) Si esta enlazado entonces Quitar enlaces del componente

//Remover componente del panel activoPanel.remove(evaporador)

fin

69.

Figura 19 Diagramas de Secuencia. Escenario eliminar Componente.

Enlazar la entrada de un componente(compresor) a otro (evaporador)

Seudocodigo

Funcion EnlazarEntrada(frmPrincipal)Declarar variable selección tipo componenteMostrar cuadro de dialogo EnlazarSelección:=returnSelect(Evaporador)

Enlazar()GraficarEnlace()Fin

70.

Figura 20 Diagramas de Secuencia. Escenario Enlazar la entrada de un componente (compresor) a otro (evaporador)

El siguiente diagrama muestra como enlazar la entrada de un componente con un intercambiador (caso especial). Si un componente enlazará su entrada con un intercambiador se deberá permitir elegir entre si se conectará por la línea de alta o la línea de baja del intercambiador

Figura 21 Diagramas de Secuencia. Escenario enlazar la entrada de un componente con un intercambiador (caso especial)

71.

Muestran como se lleva a cabo la ejecución de un sistema. Si existe un sistema y esta correctamente enlazado muestra la ejecución y realiza los cálculos sino muestra mensajes de alerta

SeudocodigoEjecutar()Funcion ejecutar()

Declarar variable valor, estado tipo booleanValor:=comprobarSistemaEnlazado()Si valor=trae entonces

Estado:=comprobarEnlaces()Si estado=trae entonces

Animación.show()Sino

Alerta()FinSino

Alerta()finfin

Figura 22 Diagramas de Secuencia. Escenario ejecución de un sistema

72.

Muestra como se lleva a cabo el pausar, detener y reanudar la ejecución de un sistema

Seudocodigo:FrmPrincipalDetener()

Funcion Detener()//cerrar la ventana CalculoCalculo.close()//cerrar la ventana de AnimaciónAnimación.close()//Finalizar hilo de ejecución de animaciónthreadAnimacion.finalize()

fin

Figura 23 Diagramas de Secuencia. Escenario pausar, detener y reanudar la ejecución de un sistema

73.

El escenario Ver información paso a paso mientras se esta ejecutando un sistema

Seudocodigo//mostrar información paso a paso:frmPrincipal Leyenda.show()

:AnimacionSeleccionaComponente(:componente)Pausar()

Funcion SeleccionaComponente(:componente)muestraInformacion(:componente)fin

Figura 24 Diagramas de Secuencia. Escenario Ver información paso a paso de un sistema

74.

5.2.7. Modelo de pruebas del sistema

Escenarios

Tabla 11. Modelo de pruebas del sistema

Función Escenario Resultado esperado

DatosRequeridos

Nuevo Sistema

Se trata del la creación de un nuevo sistema de refrigeración.

Habilitación de funciones de la barra de herramientas Componentes y de la barra de menú

Intento de crear un nuevo sistema estando abiertos cinco sistemas de Refrigeración

Mensaje de error inmediatamente.

Abrir Sistema Intento de abrir un sistema estando abiertos cinco sistemas de Refrigeración.

Mensaje de error inmediatamente

Intento de abrir un sistema existente

Mostrar los componentes Guardados

Insertar Componente

Se trata del la creación de un nuevo Componente de refrigeración estando creados diez del mismo componente

Mensaje de error inmediatamente. Impedir la inserción

Eliminar Componente

Intento de Eliminar un componente siendo el único en el sistema de Refrigeración.

deshabilitar funciones de la barra de herramientas Componentes y de la barra de menú

Enlazar Componente

Intento de Enlazar un componente existiendo varios en el sistema de Refrigeración.

Mostrar en un cuadro de dialogo los componente que se encuentran ingresados en el sistema de refrigeración

Selección del componente con el que se enlazara, por parte del usuario

Ejecutar Sistema

Se trata de la Ejecución del sistema de refrigeración con componentes que no se encuentran enlazados o parcialmente enlazados.

Mensaje de error inmediatamente

Panel activo, Compresor del sistema

Se trata de la Ejecución del sistema de refrigeración con

Verificar que exista un sistema armado y

Panel activo, Compresor del sistema

75.

Función Escenario Resultado esperado

DatosRequeridos

más de un compresor en el sistema. Al que alguno de ellos se encuentra enlazado a otros componentes.

verificar que se encuentren enlazados con los componentes adecuados.Se realiza solamente con el 1er compresor ingresado.

Se trata de la Ejecución del sistema de refrigeración con componentes que se encuentran enlazados y con componentes no adecuados

Mensaje de error inmediatamente

Panel activo, Compresor del sistema

Se trata de la Ejecución del sistema de refrigeración con componentes que se encuentran enlazados y con componentes adecuados

Mostrar ventana de calculo

Panel activo, Compresor del sistema

Calculo Intento de Cerrar la ventana Mostrarla nuevamente

Tabla Refrigerante

Selección de un refrigerante Mostrar animación y los cálculos obtenidos para los valores carga, Temp. de evaporación y de condensación en la ventana calculo

Tabla Refrigerante, Sobrecalentado, Saturado, index_sobrecalentado

Modificación de la carga, Temp. de evaporación y de condensación en la ventana calculo por el usuario

Valores esperados para los datos de entrada

Tabla Refrigerante, Sobrecalentado, Saturado, index_sobrecalentado

Mostrar Información paso a paso

Desplegar la ventana información paso a paso durante la ejecución del sistema de refrigeración

Pausa de la ejecución en un componente y despliegue de información en relación al componente

Estado del hilo de ejecución, Tabla tema

Reanudar Ejecución

Se trata de reanudar la ejecución cuando este presente la ventana información paso a paso

Actualizar la información en la ventana

Estado del hilo de ejecución, Tabla tema

Se trata de reanudar la ejecución cuando NO este presente la ventana información paso a paso

Reanuda animación

Estado del hilo de ejecución

76.

5.2.8. Arquitectura Técnica

Se requieren pocas licencias para el uso del software como lo es el gestor de bases de datos de Microsoft Access y la codificación de este en Visual Basic.Net. Licencias con las que cuenta la universidad del Magdalena, no se requiere la compra de software para el desarrollo.

Software. El sistema manejador de bases de datos elegido es Microsoft Access 2003, por ser un motor relacional con un buen nivel de desempeño. Se debe tener uno de los siguientes Sistemas Operativos con Microsoft Internet Explorer 5.01 o posterior instalado en el equipo donde se implementara el aplicativo.

Microsoft® Windows® 98 Microsoft® Windows® 98 Segunda edición Microsoft® Windows® Millennium Edition (Windows Me) Microsoft® Windows NT® 4 (Workstation o Server) con Service Pack 6a Microsoft® Windows® 2000 (Professional, Server, o Advanced Server) con el último Windows service pack y actualizaciones críticas que se pueden obtener en el sitio Web Microsoft Security (www.microsoft.com/security). Microsoft® Windows® XP en todas sus variantes Home, Professional o Server Familia de Microsoft® Windows® Server 2003

Hardware. Para la implementación del programa, se usará el equipo con el que cuenta el laboratorio de refrigeración de la planta piloto de Taganga, que puede soportar perfectamente el sistema informático nuevo.

El equipo donde se desee implementar el aplicativo debe contar con los siguientes requerimientos: Microprocesador Pentium de 233 MHz o superior (o equivalente) Se recomienda 128 megabytes (MB). 64 MB de RAM es el mínimo 30 MB de espacio libre en el disco duro. Unidad lectora de CD-ROM

77.

5.3.Fase de Construcción

5.3.1. Desarrollo del modulo Diseñador de Sistemas de Refrigeración

Implantación de la base de datos Evaluador de Sistema de Refrigeración Ejecutor de Sistema de Refrigeración

5.3.2. Desarrollo del Modulo Cálculos

Funciones Matemáticas Utilizadas en la Teoría de Refrigeración

Cantidad de refrigerante en circulación (masa)ER Efecto Refrigerante, m Masa, h1 entalpia, h4 entalpiam= CR/ERER= h1-h4

Coeficiente de Funcionamiento. CFCF= ER/QWQW= h2 –h1

Relación de Compresión. RCRC=PresionAbsolutaCondensacion/PresionAbsolutaEvaporacion

Potencia del Compresor. PP= m * QW ó P=m*(h2- h1)

Calor de Condensación. QcondQcond= m*(h2 – h3)

5.3.3. Desarrollo de los Módulos Graficas P-h y T-s

5.3.4. .Desarrollo del Modulo Animación

5.3.5. .Desarrollo del Modulo Información paso a paso

5.4. Configuración general del sistema

Ajustes a los módulos desarrollados

78.

5.5. . Fase de Transición

Estrategia para la Transición

Tipo de transición elegidoEl período de transición será corto, se espera que se faciliten las tareas que se venían haciendo. La transición está programada para inicios de este.

Plan de entrenamiento

El entrenamiento o capacitación, se centra en el adiestramiento del Profesor de teoría de refrigeración con la aplicación.

Para el entrenamiento se necesitan los siguientes recursos:Hardware: un equipo que actúe como cliente, con tarjeta de redSoftware: software de red, navegador de Internet

5.6. Pruebas y documentación

Revisión del cumplimiento documental Revisión de la consecución de los objetivos Ejecución de acciones correctiva y preventivas Actualización y ajuste de la aplicación Documentación de ajustes y cambios

Resultados de las pruebas funcionales del sistema

Tabla 12. Resultados de las pruebas funcionales del sistema

Función Escenario Resultado esperado

Resultado obtenido

Fecha de la prueba

Persona que

efectuó la

prueba

Solución Fecha de la

corrección

Encargado de la

corrección

Nuevo Sistema

Se trata del la creación de un nuevo sistema de refrigeración.

Habilitación de funciones de la barra de herramientas Componentes y de la barra de menú

El esperado Autores - profesor

Intento de crear un nuevo sistema estando abiertos cinco sistemas de

Mensaje de error inmediatamente.

El esperado Autores

79.

Función Escenario Resultado esperado

Resultado obtenido

Fecha de la prueba

Persona que

efectuó la

prueba

Solución Fecha de la

corrección

Encargado de la

corrección

Refrigeración

Abrir Sistema

Intento de abrir un sistema estando abiertos cinco sistemas de Refrigeración.

Mensaje de error inmediatamente

El esperado Autores- profesor

Intento de abrir un sistema existente

Mostrar los componentes Guardados

ERRORNo muestra lo que debería estar guardado

6/09/2005 Profesor- Usuario

Corregir la función abrir archivo

7/09/2005 Juan Carlos Silva

Insertar Componente

Se trata del la creación de un nuevo Componente de refrigeración estando creados diez del mismo componente

Mensaje de error inmediatamente. Impedir la inserción

El esperado Autores- profesor

Eliminar Componente

Intento de Eliminar un componente siendo el único en el sistema de Refrigeración.

deshabilitar funciones de la barra de herramientas Componentes y de la barra de menú

El esperado Autores- profesor

Enlazar Componente

Intento de Enlazar un componente existiendo varios en el sistema de Refrigeración.

Mostrar en un cuadro de dialogo los componente que se encuentran ingresados en el sistema de refrigeración

ERRORSolución no adecuada

20/9/2005 Profesor Modificar el cuadro de dialogo a las sugerida

23/9/2005 Juan Carlos Silva

Ejecutar Sistema

Se trata de la Ejecución del sistema de refrigeración con componentes que no se encuentran enlazados o parcialmente enlazados.

Mensaje de error inmediatamente

El esperado Profesor

Se trata de la Ejecución del sistema de refrigeración con más de

Verificar que exista un sistema armado y verificar que se encuentren

ERRORAlgunos componentes se enlazan a otros sin

3/10/2005 Autores- Profesor

Depurar y corregir la función enlace Correcto

9/10/2005 Juan Carlos Silva

80.

Función Escenario Resultado esperado

Resultado obtenido

Fecha de la prueba

Persona que

efectuó la

prueba

Solución Fecha de la

corrección

Encargado de la

corrección

un compresor en el sistema. Al que alguno de ellos se encuentra enlazado a otros componentes.

enlazados con los componentes adecuados.Se realiza solamente con el 1er compresor ingresado.

mostrarse el mensaje de mal enlace

Se trata de la Ejecución del sistema de refrigeración con componentes que se encuentran enlazados y con componentes no adecuados

Mensaje de error inmediatamente

ERRORAlgunos componentes se enlazan a otros sin mostrarse el mensaje de mal enlace

17/10/2005

Autores- Profesor

Depurar y corregir la función enlace Correcto

21/10/2005 Juan Carlos Silva

Se trata de la Ejecución del sistema de refrigeración con componentes que se encuentran enlazados y con componentes adecuados

Mostrar ventana de calculo

ERRORAlgunos componentes se enlazan a otros sin mostrarse el mensaje de mal enlace

31/10/2005

Autores- Profesor

Depurar y corregir la función enlace Correcto

3/11/2005 Juan Carlos Silva

Calculo Intento de Cerrar la ventana

Mostrarla nuevamente

El esperado

Selección de un refrigerante

Mostrar animación y los cálculos obtenidos para los valores carga, Temp. de evaporación y de condensación en la ventana calculo

ERROREn la animación no se muestran líneas frías y calientes.

14/11/2005

Autores- Profesor

Depurar y corregir la función enlace Correcto

18/11/2005 Juan Carlos Silva

Modificación de la carga, Temp. de evaporación y de condensación en la ventana calculo por el usuario

Valores esperados para los datos de entrada

Los esperados

Mostrar Desplegar la Pausa de la ERROR 28/11/200 Autores- Depurar y 3/12/2005 Juan

81.

Función Escenario Resultado esperado

Resultado obtenido

Fecha de la prueba

Persona que

efectuó la

prueba

Solución Fecha de la

corrección

Encargado de la

corrección

Información paso a paso

ventana información paso a paso durante la ejecución del sistema de refrigeración

ejecución en un componente y despliegue de información en relación al componente

Información no tiene relación con el componte seleccionado

5 Profesor corregir la función información paso a paso

Carlos Silva

Reanudar Ejecución

Se trata de reanudar la ejecución cuando este presente la ventana información paso a paso

Actualizar la información en la ventana

ERRORInformación no tiene relación con el componte seleccionado

13/11/2005

Autores- Profesor

Depurar y corregir la función información paso a paso

18/12/2005 Juan Carlos Silva

Se trata de reanudar la ejecución cuando NO este presente la ventana información paso a paso

Reanuda animación

Los esperados

5.7. . Formalización del sistema

Entrega formal del sistema

82.

6. CRONOGRAMA

FASE

TIEMPO EMPLEADO

2005 2006

Marzo Abril Mayo Junio Julio Agosto Sept Octubre Nov Dic Enero Feb

Semanas 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2Recolección de Información y definición de requerimientos                                                                                            Diseño del sistema                                                                                            

Implementación y prueba de unidades (Codificación)                                                                                            Implementación y pruebas                                                                                            

Tabla 13. Cronograma

83.

7. PRESUPUESTO

Tabla 14. Presupuesto

CONCEPTO UNIDADVALOR UNIDAD

CANTIDAD TOTAL

1. Recursos

 1,1 Recurso Humano

Asesoráis 2 horas/semanales 20.000 7 140.000

1,2 Recursos Comp.  

Equipos Hora Maquina/4 5.000 880 2.160.000

Internet Mensualidad 35.000 2 70.000

 

Subtotal   4.610.000

2, Gastos Generales

 2,1 Papelería

papel Resma * 500h 9.000 1 9.000

Fotocopias Mat. Inev Fotocopia 50 100 5.000

CD RW Por unidad 2.500 4 10.000

Otros       50.000

        0

Subtotal       74.000

3,Viaticos  

Transporte 2 personas 4.000 20 80.000

         

Subtotal       80.000

 

         

Total       4.764.000

84.

8. CONCLUSIONES

Después del análisis, desarrollo e implementación de este software podemos concluir lo siguiente:

Con la realización de este proyecto se hizo un aporte significativo en el proceso de educación de los estudiantes de ingeniería Pesquera de la Universidad del Magdalena, la cual está comprometida con la sociedad y la comunidad universitaria con el mejoramiento de la calidad.

Después de analizar los procesos y procedimientos de enseñanza en el laboratorio de refrigeración actuales de la planta piloto pesquera de la Universidad, analizar los metodologías aplicadas definimos que mediante la utilización de equipos computacionales, software especializados, se logró la estructuración y desarrollo de un laboratorio virtual en el laboratorio de la planta piloto de taganga de la Universidad del Magdalena, que sirve como soporte para el seguimiento, monitoreo del aprendizaje de los estudiantes, ya que en este momento cuentan con una ayuda didáctica que facilita el aprendizaje.

Al evaluar el diseño y la información de salida del sistema, a partir de datos de entrada, por medio de la construcción de prototipos, se comprobó que la plataforma sobre al cual se desarrolló el sistema es estable y a la vez confiable.

85.

9. RECOMENDACIONES

El desarrollo del software Educativo se realizo bajo requerimientos establecidos por el coordinador del laboratorio de la planta piloto de taganga. Actualmente los estudiantes cuentan con una herramienta efectiva para realizar practicas que tengan que ver con el diseño de sistemas de refrigeración por compresión de vapor (ciclo ideal) .Los autores recomendamos:

implementar otros refrigerantes en el software ya que este solo cuenta con dos.

se recomienda la implementación de otros ciclos de refrigeración por compresión de vapor como el multietapa, cascada y otros sistemas como el de absorción de vapor

. se recomienda la creación de una interfaz de control para el manejo de componentes .

86.

10.BIBLIOGRAFIA

DOSSAT, Roy J. Principios de Refrigeración. México: CECSA, 2004. 200 p.

PITA, Edgard G. Principios y Sistemas de Refrigeración. México, 2004. 497 p.

CAYÓN R, Olaya Ch. Cálculo y Diseño de la Línea de Frió en la C.P.P.P.T. Tesis de Grado Ingeniero Pesquero.

MÉNDEZ A. Carlos Eduardo. METODOLOGIA, Diseño y desarrollo del Proceso de Investigación. Colombia: Editorial Nomos, 3ª edición 2003. 247 p.

STEVENS, Perdita y POOLEY, Rob. UTILIZACIÓN DE UML, en ingeniería del Software con Objetos y componentes. España: Pearson Educación 2002, 312 p.

BALENA, Francesco. Programación Avanzada con Microsoft Visual Basic .NET. España: McGraw-Hill 2003.

JACOBSON, Ivar; BOOCH, Grady y RUMBAUGH, James. EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE. Madrid: Pearson Educación 2000. 464p.

INSTITUTO COLOMBIANO DE NORMAS TÉCNICAS Y CERTIFICACIÓN. Tesis y otros trabajos de grado. Bogotá. ICONTEC, 2004. NTC 1486.

PRESSMAN, Roger. Ingeniería del Software, Un Enfoque Práctico. Cuarta Edición. Madrid (España). McGraw-Hill, 1998.

MIRANDA MIRANDA, Juan José. Gestión de Proyectos. MM Editores, 2a. Edición.

ODELL, JAMES J. Advanced Object-Oriented Analysis & Design Using UML, Cambridge University Press, New York1998

JACOBSON, IVAR , El Proceso Unificado de Desarrollo de Software, Addison Wesley Madrid 2000

BOOCH, Grady y JACOBSON, Ivar. El lenguaje unificado de modelado. Adison Wesley, 1996.

BURCH, John y GRUDNITSKI, Gary. Diseño de Sistemas de Información. Teoría y Práctica. México: Grupo Noriega Editores, 1992.

87.

KENDALL, Kenneth y KENDALL, Julie E. Análisis y diseño de sistemas. México: Prentice Hall, 1991.

LARMAN, Craig. UML y Patrones. Una introducción al análisis y diseño orientado a objetos y al proceso unificado. 2da. Ed. Prentice Hall, 2003.

SOMMERVILLE, Ian. Ingeniería de Software. 6ta. Ed. México: Addison Wesley, 2002.

88.