DESARROLLO E IMPLEMENTACIÓN DE UN SOFTWARE DE SIMULACIÓN PARA EL LABORATORIO DE REFRIGERACION...
-
Upload
eduard-avendano -
Category
Documents
-
view
492 -
download
0
Transcript of DESARROLLO E IMPLEMENTACIÓN DE UN SOFTWARE DE SIMULACIÓN PARA EL LABORATORIO DE REFRIGERACION...
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.