Universidad de las Ciencias Informáticas Facultad 7
Implementación del Sistema de Salud Ambiental Versión 1.0.1
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas
Autores:
Rosalía Fragoso Simón Enrique Avila Quintero
Tutores:
Ing. Reynel Fals de Pedro Ing. Leosdan Pozo Águila
Ciudad de La Habana, Julio de 2010
“Año 52 de la Revolución”
DECLARACIÓN DE AUTORÍA.
Declaramos ser autores de la presente tesis y reconocemos a la Universidad de las Ciencias Informáticas los derechos patrimoniales de la misma, con carácter exclusivo.
Para que así conste firmo la presente a los 2 días del mes de julio de 2010.
______________ ______________
Rosalía Fragoso Simón. Enrique Avila Quintero.
Firma del Autor. Firma del Autor.
______________ ______________
Ing. ReynelFals de Pedro. Ing. Leosdan Pozo Águila.
Firma del Tutor. Firma del Tutor.
DATOS DE CONTACTO.
Ing. Reynel Fals de Pedro. Graduado de Ingeniería en Ciencias Informáticas en la Universidad de las Ciencias Informáticas (UCI) en el 2006. Instructor. Durante su trabajo como profesor ha impartido la asignatura de Máquinas Computadoras, la cual imparte actualmente.
En la vinculación con la producción pertenece al Departamento de Sistemas Especializados en Medicina del Centro Especializado en Soluciones de Informática Médica y específicamente trabaja en el desarrollo del proyecto alas CSI donde se desempeña como desarrollador.
Correo Electrónico: [email protected]
Ing. Leosdan Pozo Águila. Graduado de Ingeniería en Ciencias Informáticas en la Universidad de las Ciencias Informáticas (UCI) en el 2009. Instructor recién graduado en adiestramiento. Actualmente imparte cursos de preparación para la producción en el Departamento Sistemas Especializados en Medicina.
En la vinculación con la producción pertenece al Departamento de Sistemas Especializados en Medicina del Centro Especializado en Soluciones de Informática Médica y específicamente trabaja en el desarrollo del proyecto alas Teleconsulta donde se desempeña como desarrollador.
Correo electrónico: [email protected]
IV RESUMEN
En la actualidad todo el flujo de información correspondiente a los alimentos y otros productos que se envían a Cuba se realiza de forma manual o por vía telefónica. Por ello gran parte de esa información pudiera perderse u ocurrir que se introduzcan errores humanos, además de que se hace un poco lento el proceso de trabajo. La información es regulada y manejada individualmente por cada unidad de Salud Ambiental.
El objetivo fundamental de este trabajo de diploma es realizar la implementación del Sistema Salud Ambiental, encargado de la vigilancia y seguimiento de la higiene de los productos que entran a Cuba.
El sistema se concibió usando la metodología de desarrollo (RUP), porque brinda la posibilidad de ser adaptada a las necesidades del equipo. Las herramientas que se utilizaron fueron Visual Paradigm 6.4 para (UML). Como lenguaje de programación se utilizó PHP 5 y el gestor de base de datos PostgreSQL 8.3. Como framework el Symfony 1.4.3 pues proporciona una arquitectura, componentes y herramientas para construir aplicaciones web complejas con mayor rapidez. Se reutilizan librerías como es la YUI Library 2.6. Para su confección se utilizó el NetBeans 6.8 como IDE de desarrollo por las grandes prestaciones que brinda.
Con esta aplicación la información estará centralizada, garantizando el acceso a ella mediante una interfaz gráfica amigable, segura y fácil de usar; proponiéndose incrementar los niveles de salud y satisfacción de la población mediante la vigilancia y control de los alimentos en la Cadena Puerto, Transporte y Economía Interna.
Palabras clave: Higiene de los productos, seguimiento, vigilancia.
V TABLA DE CONTENIDOS
INTRODUCCIÓN. ... 1
CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA ... 5
1.1 Justificación del Sistema Propuesto ... 5
1.2 Procesos de negocio... 5
1.3 Metodología de Desarrollo de Software ... 7
1.3.1 Proceso Unificado de Desarrollo (RUP)... 7
1.4 Lenguaje Unificado de Modelado (UML) 2.0 ... 8
1.5 Herramientas Case ... 8
1.5.1 Visual Paradigm 6.4... 9
1.6 Lenguajes de programación del lado del cliente ... 9
1.6.1 JavaScript ... 9
1.7 Lenguaje de programación del lado del servidor ... 10
1.7.1 PHP 5 ... 10
1.8 Librería y Framework ... 10
1.8.1 Symfony 1.4.3 ... 10
1.8.2 Yahoo User Interface (YUI) 2.8 ... 11
1.9 Entorno Integrado de Desarrollo (IDE) ... 11
1.9.1 NetBeans 6.8 ... 11
1.9.2 Dreamweaver 8 ... 12
1.10 Servidor Web... 12
1.10.1 Servidor Web Apache 2.2... 12
1.11 Sistema Gestor de Bases de Datos... 13
1.11.1 PostgreSQL 8.3 ... 13
VI
CAPÍTULO 2. ELEMENTOS DE ARQUITECTURA ... 15
2.1 Requerimientos No Funcionales ... 15
2.1.1 Requerimientos de Usabilidad... 15
2.1.2 Requerimiento de confiabilidad ... 15
2.1.3 Requerimientos de Soporte ... 16
2.1.4 Requerimientos de Apariencia o Interfaz Externa... 16
2.1.5 Requerimientos de Seguridad ... 16
2.1.6 Requerimientos de Software ... 16
2.1.7 Requerimientos de Hardware ... 17
2.1.8 Requerimientos de Diseño e Implementación ... 17
2.1.9 Requerimientos de Ayuda y Documentación en línea. ... 17
2.2 Arquitectura de Software y patrones arquitectónicos... 18
2.2.1 Arquitectura basada en componentes... 19
2.2.2 Modelo-Vista-Controlador (MVC) ... 20
2.3 Estrategias de Integración ... 20
2.4 Seguridad ... 21
2.5 Modelo de Despliegue ... 22
2.6 Estrategias de Codificación. Estándares y estilos... 23
CAPÍTULO 3. DESCRIPCIÓN Y ANÁLISIS DE LA SOLUCIÓN PROPUESTA ... 30
3.1 Valoración crítica del diseño propuesto por el analista... 30
3.2 Descripción de las nuevas clases u operaciones necesarias... 30
3.3 Modelo de datos... 37
3.4 Descripción de las tablas ... 39
VII
CONCLUSIONES ... 49
RECOMENDACIONES... 50
REFERENCIAS BIBLIOGRÁFICAS ... 51
BIBLIOGRAFÍA ... 53
ANEXOS ... 56
Anexo 1 Pantalla que aparece antes que el usuario se autentique ... 56
Anexo 2 Pantalla de Autenticación del Sistema Salud Ambiental ... 56
Anexo 3 Pantalla de entrada al sistema ... 57
Anexo 4 Pantalla que muestra la funcionalidad Gestionar Registro Sanitario ... 58
Anexo 5 Pantalla que muestra la funcionalidad Registrar Inspección Sanitaria Estatal ... 59
Anexo 8 Pantalla que muestra la funcionalidad: Registrar Datos de la Carga ... 62
GLOSARIO ... 63
1 INTRODUCCIÓN.
El futuro de la humanidad dependerá en gran medida del potencial humano, de la gestión de la producción y de los conocimientos que se alcanzan. El desarrollo de la Informática tiene un papel protagónico y fundamental en el mismo.
En la actualidad con el desarrollo tecnológico, particularmente en las ramas de la Informática y las Telecomunicaciones, se evidencia que es esta la era con mayor velocidad de evolución de todas aquellas que se haya conocido. Este desarrollo tecnológico ha dado surgimiento a las Tecnologías de la Informática y las Comunicaciones (TIC), las cuales están inundando el mundo referencial del ser humano, y a la vez le ayudan a conquistar conocimientos y acciones que ayer mismo parecían inaccesibles. Es por ello que en los últimos tiempos se comenzaron a dar los primeros pasos para ordenar el trabajo e impulsar el desarrollo y el uso de las TIC.
Con el surgimiento, desarrollo e implementación de las TIC se han generado varias transformaciones en la sociedad, y en un proceso acelerado de convergencia se insertan en diversos ámbitos de la vida.
A partir del año 1997 se concibe una primera estrategia de informatización como respuesta del sector de la salud a los lineamientos estratégicos para informatizar la sociedad cubana, con la finalidad de coordinar esfuerzos para el desarrollo de los procesos en el Sistema Nacional de Salud (SNS).
En Cuba, se impulsa la informatización diariamente de múltiples áreas haciendo un notable énfasis en el SNS, con lo que se posibilitará elevar la calidad del servicio brindado y la satisfacción de pacientes; así como la interconectividad entre las distintas unidades hospitalarias.
El país está inmerso en el profundo y novedoso proceso de transformaciones educacionales y sociales como programas de la Batalla de Ideas, a partir del cual se emprendieron y se emprenden nuevos programas destinados a elevar el nivel cultural de la población y su calidad de vida.
En la Universidad de Ciencias Informáticas (UCI), creada en el año 2002, se desarrollan varios proyectos de producción de software vinculados a la salud.
Dentro de esta gran universidad se encuentran varias facultades y una de ellas es la Facultad 7, la cual se dedica fundamentalmente a la informatización del sector de la salud y cuenta con un departamento de
2 Sistemas Especializados que ha tenido como propósito apoyar el proceso de informatización en cada una de las áreas de la salud. Dentro de este departamento se creó el proyecto “Control Sanitario Internacional”.
Control Sanitario Internacional cuenta con tres programas: Higiene y Epidemiología, que se encarga de la vigilancia epidemiológica al viajero; Vigilancia y Lucha Anti vectorial, que tiene la misión de contribuir a evitar la introducción y/o propagación de enfermedades introducidas por vectores, e incrementar los niveles de salud y satisfacción de la población cubana; y por último el programa de Salud Ambiental, el cual se ocupa de la vigilancia sanitaria de los productos de importación.
Salud Ambiental es la rama encaminada a estudiar cómo el medio ambiente afecta la salud del hombre.
Dentro de esta rama se tienen en cuenta cinco factores fundamentales: el estado de las aguas potables, los residuales líquidos y sólidos, la salud escolar, la salud ocupacional y la higiene de los alimentos.
En Cuba se han establecido diferentes acciones regulatorias en concordancia con las legislaciones internacionales, por lo que cada alimento que entre al país debe ser evaluado atendiendo a sus características físico-químicas, microbiológicas, toxicológicas y nutricionales. Todo esto se hace a través de la vigilancia sanitaria.
El proceso de control y vigilancia de la higiene de los alimentos importados se inicia inscribiendo el producto que se desea comercializar en Cuba, por las empresas importadoras, en el Registro Sanitario del Instituto de Nutrición e Higiene de los Alimentos, donde se lleva a cabo la evaluación sanitaria del mismo.
De esta forma, el producto queda autorizado para entrar al país y comercializarse. En este proceso se recogen una serie de datos importantes sobre las especificaciones de estos productos que serán utilizados más adelante por los inspectores sanitarios.
En la UCI se desarrolló una aplicación para el control de la higiene de los alimentos, la misma facilita la gestión de la información relacionada con el registro de los productos, las inspecciones sanitarias realizadas y los datos de los mismos cuando arriban a la frontera.
3 Esta aplicación no está en correspondencia con el lineamiento de la arquitectura propuesta por la Facultad 7 para el departamento de Sistemas Especializados debido a que se desarrolló utilizando como framework CodeIgniter, que a pesar de ser fácil de configurar y sencillo de utilizar, carece de un conjunto de funcionalidades que pudieran limitar el desarrollo óptimo de nuevas versiones del sistema actual.
Por esta razón en el curso 2008-2009 se realizó un nuevo análisis y diseño de este software, el cual no concluyó en la implementación del mismo. Actualmente se hace necesario realizar un nuevo desarrollo del Sistema de Salud Ambiental.
Por lo antes planteado se identifica como Problema a resolver ¿Cómo obtener un sistema funcional a partir del diseño realizado para viabilizar el proceso de gestión de la información relacionada con la higiene de los alimentos importados en Cuba?
Donde el Objeto de estudio es el proceso de gestión de la información referente a la Salud Ambiental en Cuba.
El Campo de acción se enfoca en el proceso de gestión de la información relacionada a la higiene de los alimentos importados en Cuba.
Se define como Objetivo general: Implementar la versión 1.0.1 del Sistema de Salud Ambiental.
Para darle solución al problema antes mencionado se plantean las siguientes Tareas de la investigación:
Realizar un análisis acerca de los procesos de negocio asociados a la higiene de los alimentos importados en Cuba para el Sistema de Salud Ambiental.
Asimilar la arquitectura definida por el Departamento de Sistemas Especializados en Medicina de conjunto con el cliente para el desarrollo del Sistema de Control Sanitario Internacional.
Actualizar el diseño de la base de datos de los procesos de negocio asociados a la higiene de los alimentos importados en Cuba para el Sistema de Salud Ambiental.
Realizar la actualización del modelo de datos.
Realizar la implementación de los procesos de negocio asociados a la higiene de los alimentos importados en Cuba para el Sistema de Salud Ambiental utilizando los patrones establecidos en el Análisis y Diseño.
4 Para dar cumplimiento a estas tareas de manera satisfactoria el presente trabajo de diploma estará estructurado en tres capítulos donde se refleja todo el trabajo investigativo, as í como todo lo referente al diseño de la base de datos y la implementación de la solución propuesta, distribuido de la siguiente manera:
Capítulo 1. Fundamentación teórica: Estudio crítico y valorativo de la metodología, tecnologías, herramientas, plataforma y librería a utilizar en el desarrollo del módulo descrito en la tesis anterior.
Capítulo 2. Elementos de arquitectura: Se realiza una explicación de la arquitectura del sistema, para lo que se exponen los requisitos no funcionales del mismo, se efectúa un análisis de los patrones o estilos arquitectónicos presentes en la propuesta de solución, además de un análisis de la estrategia de integración con otros módulos o sistemas, así como de la seguridad, una explicación de la vista de despliegue y de los estándares y estilos que se utilizaron.
Capítulo 3. Descripción y análisis de la solución propuesta: Se realiza un análisis del diseño propuesto por el analista, refinando los diagramas de clases del diseño y diagramas de interacción, así como el modelo de datos con una descripción de las tablas del mismo y por último una descripción de la vista de implementación.
5 CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA
Este capítulo es el resultado de la búsqueda de información relacionada con sistemas informatizados existentes para la gestión de la información referente a la higiene de los productos de importación.
Además se describen las herramientasy metodologías que se han utilizado para el desarrollo de la aplicación; las cuales fueron previamente definidas en el documento de arquitectura de la facultad 7 de la Universidad de la Ciencias Informáticas.
1.1 Justificación del Sistema Propuesto
En el año 2008 se implementó un sistema informático en la Facultad 7 de la UCI para dar solución al control sanitario internacional, pero este sistema no está en completa correspondencia con la arquitectura definida para el Área Temática Sistemas Especializados al estar implementado sobre el Framework CodeIgniter. Es por ello que se propuso el diseño de una aplicación Web, fundamentada en el uso del Framework Symfony, con una arquitectura más amigable y vistosa al usuario, con la ayuda de YUI.
Para diseñar el sistema se utilizó el Lenguaje Unificado de Modelado UML2.0, el más conocido y utilizado en la actualidad. Como metodología de desarrollo de software, RUP debido a que proporciona un acercamiento disciplinado a la asignación de tareas y responsabilidades en una organización de desarrollo, quedando bien documentado el software de forma perdurable y extensible.
La herramienta CASE empleada fue el Visual Paradigm 6.4, porque soporta aplicaciones Web y expo rta código de aproximadamente diez lenguajes de programación que incluyen PHP, que es el lenguaje que debe utilizarse en la implementación del sistema. Es válido señalar que tanto las herramientas como metodología y lenguaje fueron analizadas por el grupo de arquitectura de la Facultad 7 para el Área Temática Sistemas Especializados y han sido plasmadas en los lineamientos del documento de arquitectura.
1.2 Procesos de negocio
Todo el proceso comienza cuando el proveedor o la empresa importadora llega para un primer contacto con una muestra del producto que desea comercializar en Cuba al Instituto de Nutrición, que es el centro encargado de analizar la muestra y comprobar la veracidad de las especificaciones presentadas por el proveedor y luego registrar los datos o características necesarios del producto en el Registro Sanitario. De
6 ahí se genera un Certificado Sanitario el cual posee un número de licencia sanitaria que servirá para distinguir un producto de otro.
Este documento tiene validez por tres años, tiempo durante el cual ese producto puede ser importado.
Después de este tiempo el cliente puede renovar el Certificado Sanitario del producto o simplemente será eliminado. Este documento debe ser presentado en frontera una vez llegada la carga y en todo lugar donde sea solicitado dentro del país.
Cuando la carga arriba a la frontera el primer paso a realizar por los funcionarios es comprobar que dicho producto está registrado en el Registro Sanitario, para esto llaman al Instituto de Nutrición, lo comprueban y a la vez obtienen información sobre las especificaciones que están registradas para ese producto, en caso de que no lo esté, se le notifica para que sea registrado, acción que puede durar hasta 15 días como mínimo si no hay problemas.
Si el producto está registrado se procede a verificar si la carga es general o por contenedor; en caso de que sea la primera opción se realiza la inspección sanitaria estatal con el objetivo de verificar si las características observadas concuerdan con los datos de la muestra que fue registrada, en caso de que la mercancía no cumpla con los datos almacenados ya sea por diferentes causas que influyan contra la integridad del producto tales como: deterioro, parasitación, contaminación, entre otras, entonces es registrada como una incidencia; en dependencia de la cantidad de la mercancía implicada puede o no convertirse en un conflicto, y se detiene en espera de otras inspecciones.
Cuando la carga es inspeccionada nuevamente, si el problema anteriormente detectado no constituye un peligro para la salud humana, se libera el producto apto para el consumo de la población. De lo contrario el producto se decomisa y se pueden tomar cualquiera de las siguientes acciones: destrucción de la mercancía, destinar al consumo animal o reexportar el producto. Estas inspecciones se van a realizar hasta que el producto se libere o decomise por completo.
Si la carga fuera por contenedor, los funcionarios de frontera no pudieran inspeccionar la mercancía, solo observan la calidad y aspecto exterior de la carga y se le da permiso de extracción con retención en destino para que sea inspeccionada allí. El permiso de extracción es un documento que la empresa importadora puede solicitar a frontera (puerto, aeropuerto o marina) incluso antes de que su carga llegue, para evitar retrasos.
7 Una vez llegada al destino la carga por contenedor, los inspectores sanitarios municipales acuden a realizar la inspección sanitaria con el objetivo de liberarla y declararla apta para el consumo humano sino presenta problemas. Si ocurre alguna incidencia, los inspectores sanitarios municipales deben tomar las medidas pertinentes que estén a su alcance.
1.3 Metodología de Desarrollo de Software
Un proceso de software detallado y completo suele denominarse Metodología. Esta define quién debe hacer qué, cuándo y cómo debe hacerlo para obtener los distintos productos parciales y finales.
1.3.1 Proceso Unificado de Desarrollo (RUP)
La metodología RUP, se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Se plantea que el RUP es un proceso de desarrollo de software que describe un conjunto de actividades para transformar los requerimientos del cliente en un Sistema de Software [1].
Tiene como objetivo asignar tareas y responsabilidades para producir software de alta calidad, buscando satisfacer las necesidades de los clientes, ajustándose al presupuesto y a los tiempos estimados. El RUP ofrece diferentes subprocesos, que brindan un marco de trabajo adaptable y extensible a las necesidades de cada organización. RUP divide el proceso de desarrollo en ciclos, teniendo un producto al final de cada uno, y estos se dividen en fases que finalizan con un hito donde se debe tomar una decisión importante:
Inicio: Determinar la visión del proyecto.
Elaboración: Determinar la arquitectura óptima.
Construcción: Obtener la capacidad operacional inicial.
Transmisión: Obtener la liberación del proyecto.
Cada una de estas fases finaliza con un hito donde se debe tomar una decisión importante. Además agrupa las actividades en grupos lógicos definiéndose 9 flujos de trabajo principales. Los 6 primeros son conocidos como flujos de ingeniería y los tres últimos como de apoyo.
8 Figura 1: Proceso Unificado de Desarrollo.
1.4 Lenguaje Unificado de Modelado (UML) 2.0
UML es un lenguaje de modelado. Un modelo es una simplificación de la realidad. El objetivo del modelado de un sistema es capturar las partes esenciales del sistema. Para facilitar este modelado, se realiza una abstracción y se plasma en una notación gráfica. Esto se conoce como modelado visual.
UML sirve para el modelado completo de sistemas complejos, tanto en el diseño de los sistemas software como para la arquitectura hardware donde se ejecuten. Otro objetivo de este modelado visual es que sea independiente del lenguaje de implementación, de tal forma que los diseños realizados usando UML se puedan implementar en cualquier lenguaje que soporte las posibilidades de UML (principalmente lenguajes orientados a objetos).
1.5 Herramientas Case
Las herramientas de Ingeniería de Software Asistida por Ordenador (CASE por sus siglas en inglés), son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software, reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un
9 diseño del proyecto, cálculo de costes, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores, entre otras. [2]
1.5.1 Visual Paradigm 6.4
Visual Paradigm para UML es una herramienta UML profesional que soporta el ciclo de vida c ompleto del desarrollo de software: análisis y diseño orientados a objetos, construcción, pruebas y despliegue. El software de modelado UML ayuda a una más rápida construcción de aplicaciones de calidad y a un menor coste. Permite dibujar todos los tipos de diagramas de clases, código inverso, generar código desde diagramas y generar documentación. La herramienta UML CASE también proporciona abundantes tutoriales de UML, demostraciones interactivas de UML y proyectos UML. [3]
Visual Paradigm para UML se ha actualizado rápidamente en concordancia con el nuevo desarrollo de UML para proporcionar un entorno de modelado visual que reúne hoy el software, la tecnología y las necesidades de comunicación.
1.6 Lenguajes de programación del lado del cliente
Los lenguajes de programación establecen un conjunto de reglas sintácticas y semánticas, las cuales rigen la estructura del programa de computación que se escribe o edita. De esta forma, permiten a los programadores o desarrolladores, poder especificar de forma precisa los datos sobre los que se va a actuar, su almacenamiento, transmisión y demás acciones a realizar bajo las distintas circunstancias consideradas. [4]
1.6.1 JavaScript
Es un lenguaje de programación que no requiere de compilación ya que funciona del lado del cliente y los navegadores son los que soportan la carga de procesamiento.
JavaScript permite la programación de pequeños scripts, pero también de programas más grandes, orientados a objetos, con funciones, estructuras de datos complejas. Además, JavaScript pone a disposición del programador todos los elementos que forman la página web, para que éste pueda acceder a ellos y modificarlos dinámicamente.
10 1.7 Lenguaje de programación del lado del servidor
1.7.1 PHP 5
Un lenguaje del lado del servidor es aquel que se ejecuta en el servidor web, justo antes de que se envíe la página a través de Internet al cliente. Las páginas que se ejecutan en el servidor pueden realizar accesos a bases de datos, conexiones en red, y otras tareas para crear la página final que v erá el cliente.
El cliente solamente recibe una página con el código HTML resultante de la ejecución de la página PHP.
Como la página resultante contiene únicamente código HTML, es compatible con todos los navegadores.
[5]
PHP es un lenguaje que posee tanto ventajas como desventajas para los programadores, entre sus ventajas se puede destacar que es muy fácil de aprender, es rápido y multiplataforma.
Entre sus desventajas se encuentra que se necesita instalar un servidor web, donde el trabajo lo realiza el servidor y no delega al cliente. También la legibilidad del código se afecta al mezclar sentencias HTML y PHP y la programación orientada a objetos es aún muy deficiente para aplicaciones grandes.
1.8 Librería y Framework
El término framework se refiere a una estructura software compuesta de componentes personalizables e intercambiables para el desarrollo de una aplicación. En otras palabras, un framework se puede considerar como una aplicación genérica incompleta y configurable a la que se pueden añadir las últimas piezas para construir una aplicación concreta. Los objetivos principales que persigue un framework son:
acelerar el proceso de desarrollo, reutilizar código ya existente y promover buenas prácticas de desarrollo como el uso de patrones. [6]
1.8.1 Symfony 1.4.3
Symfony es un completo framework diseñado para optimizar, gracias a sus características, el desarrollo de las aplicaciones web. Para empezar, separa la lógica de negocio, la lógica de servidor y la presentación de la aplicación web. Proporciona varias herramientas y clases encaminadas a reducir el tiempo de desarrollo de una aplicación web compleja. Además, automatiza las tareas más comunes, permitiendo al desarrollador dedicarse por completo a los aspectos específicos de cada aplicación. [7]
11 Está desarrollado completamente con PHP 5. Ha sido probado en numerosos proyectos reales y se utiliza en sitios web de comercio electrónico de primer nivel. Symfony es un framework compatible con la mayoría de gestores de bases de datos, como MySQL, PostgreSQL, Oracle y SQL Server de Microsoft.
Se puede ejecutar en plataformas *nix (Unix, Linux) como en plataformas Windows.
1.8.2 Yahoo User Interface (YUI) 2.8
La Yahoo User Interface (YUI), es un conjunto de bibliotecas JavaScript, para el desarrollo de aplicaciones web interactivas usando técnicas DOM, DHTML y AJAX. Se encuentra completamente documentada y tiene elementos para: manipulación del árbol doom, animaciones, efectos, Ajax, arras trar y soltar, JSON, autocompletado, calendario, carrusel, selectores, contenedores, diálogos, data tables, layout, menús, paginadores, CSS, entre otros. [8]
YUI incluye un conjunto de fuentes CSS. Todos los componentes YUI han sido desarrollados en Open Source bajo la licencia BSD y está disponible para todo tipo de uso.
1.9 Entorno Integrado de Desarrollo (IDE)
IDE significa Entorno de Desarrollo Integrado (Integrated Development Environment, por sus siglas en ingles). Se refiere a un software que permite al programador realizar cómodamente todas las tareas de desarrollo de programas. Cualquier IDE tiene incorporado como mínimo facilidades para la ejecución que consiste en un editor de código, un compilador, un depurador y un constructor de interfaz gráfica GUI (Interfaz Gráfica de Usuario). [9]
1.9.1 NetBeans 6.8
NetBeans es una herramienta de código abierto escrito completamente en Java para programadores.
Permite escribir, compilar, depurar y ejecutar programas. Está escrito en Java pero puede servir para cualquier otro lenguaje de programación. Es un producto libre y gratuito sin restricciones de uso.
Todas las funciones de NetBeans son provistas por módulos. Cada módulo provee una función bien definida, tales como el soporte de Java, edición, o soporte para el sistema de control de versiones.
NetBeans contiene todos los módulos necesarios para el desarrollo de aplicaciones Java en una sola descarga, permitiéndole al usuario comenzar a trabajar inmediatamente.
12 1.9.2 Dreamweaver 8
Dreamweaver es la herramienta de diseño de páginas web más avanzada. [10] Cumple perfectamente el objetivo de diseñar páginas con aspecto profesional, y soporta gran cantidad de tecnologías, además muy fáciles de usar:
Hojas de estilo y capas.
JavaScript para crear efectos e interactividades.
Inserción de archivos multimedia.
Además es un programa que se puede actualizar con componentes, que fabrica tanto Macromedia como otras compañías, para realizar otras acciones más avanzadas. En resumen, el programa es realmente satisfactorio, incluso el código generado es de buena calidad.
1.10 Servidor Web
El servidor Web es un programa que corre sobre el servidor que escucha las peticiones HTTP que le llegan y las satisface. Dependiendo del tipo de la petición, el servidor Web buscará una página Web o bien ejecutará un programa en el servidor. De cualquier modo, siempre devolverá algún tipo de resultado HTML al cliente o navegador que realizó la petición. El servidor Web va a ser fundamental en el desarrollo de las aplicaciones del lado del servidor (server sideapplications), que se va a construir, ya que se ejecutarán en él. [11]
1.10.1 Servidor Web Apache 2.2
Apache está diseñado para ser un servidor web potente y flexible que pueda funcionar en la más amplia variedad de plataformas y entornos. Las diferentes plataformas y entornos, hacen que a menudo sean necesarias diferentes características o funcionalidades. Este servidor se ha adaptado siempre a una gran variedad de entornos a través de su diseño modular. El diseño permite a los administradores de sitios web elegir qué características van a ser incluidas en el servidor seleccionando, qué módulos se van a cargar, ya sea al compilar o al ejecutar el servidor. [12]
13 Características:
Corre en una multitud de Sistemas Operativos, lo que lo hace prácticamente universal.
Apache es una tecnología gratuita de código fuente abierto.
Apache es un servidor altamente configurable de diseño modular. Es muy sencillo ampliar las capacidades del servidor Web Apache. Actualmente existen muchos módulos para Apache que son adaptables a este, y están ahí para instalarlos cuando se necesiten.
Apache permite personalizar la respuesta ante los posibles errores que se puedan dar en el servidor. Es posible configurar Apache para que ejecute un determinado script cuando ocurra un error en concreto.
Tiene una alta configurabilidad en la creación y gestión de logs. Apache permite la creación de ficheros de log a medida del administrador, de este modo se puede tener un mayor control sobre lo que sucede en el servidor. [13]
1.11 Sistema Gestor de Bases de Datos
Un Sistema Gestor de Base de Datos (SGBD) es un conjunto de programas que permiten crear y mantener una Base de Datos, asegurando su integridad, confidencialidad y seguridad. Por tanto debe permitir:
Definir una base de datos: especificar tipos, estructuras y restricciones de datos.
Construir la base de datos: guardar los datos en algún medio controlado por el mismo SGBD.
Manipular la base de datos: realizar consultas, actualizarla, generar informes. [14]
1.11.1 PostgreSQL 8.3
PostgreSQL es un software libre y fue desarrollado por voluntarios de todo el mundo. Su distribución se basa en la licencia de Berkeley que no pone límites en el uso. Por lo tanto, tiene infinitas posibilidades, no sólo como una herramienta de enseñanza para los interesados en aprender sobre sistemas de bases de datos de alto rendimiento, sino como una herramienta muy útil para las aplicaciones empresariales de calidad de la producción. Dado que PostgreSQL es capaz de funcionar 24 horas 365 días, es adecuado para aplicaciones a gran escala. Además, el usuario no tiene que pagar ningún tipo de tasa de licencia, por lo que es una solución rápida para los precios.
14 Con un sistema que combine PostgreSQL y Linux, es fácil reducir el costo inicial, y ampliar el sistema al mismo tiempo que el negocio crece. PostgreSQL no es sólo un sistema de base de datos por lotes, sino que también funciona como recurso en línea con aplicaciones web. [15]
En este capítulo se realizó un análisis de las metodologías y tecnologías actuales que facilitan el desarrollo de aplicaciones web, así como de las herramientas predefinidas por el Grupo de Arquitectura de la Facultad para el Centro de Sistemas Especializados para la Salud. Lo anterior permitirá desarrollar un sistema integrado a toda una infraestructura que se ha venido desarrollando. Este tiene como finalidad constituir la base informatizada de la salud pública cubana, teniendo en cuenta las políticas de Cuba determinadas por el uso de herramientas gratuitas y bajo licencias de software libre para el desarrollo de sus aplicaciones.
15 CAPÍTULO 2. ELEMENTOS DE ARQUITECTURA
En el desarrollo de este capítulo se expone la arquitectura que ha sido determinada para el desarrollo de la aplicación de salud ambiental. Se mencionarán los requisitos no funcionales, los patrones arquitectónicos seguidos en el desarrollo de la aplicación, una explicación del modelo de despliegue y las estrategias de codificación a utilizar. Además de realizar un análisis de las posibles estrategias de integración.
2.1 Requerimientos No Funcionales
Los requerimientos no funcionales son propiedades o cualidades que el producto debe tener. Debe pensarse en estas propiedades como las características que hacen al producto atractivo, usable, rápido o confiable. Un requisito no funcional especifica restricciones físicas sobre un requisito funcional. [16]
2.1.1 Requerimientos de Usabilidad
Debe lograr que las interacciones del usuario con el sistema sean predecibles y familiares.
Debe posibilitar múltiples vías por las cuales el usuario pueda realizar una tarea.
La aplicación debe ser flexible y permitir que el usuario aprenda a usarla con facilidad.
La aplicación podrá ser usada por cualquier persona que posea conocimientos básicos en computación y en ambientes Web.
Debe brindar la posibilidad de diálogos, con el objetivo de mantener todo el tiempo orientado al usuario.
2.1.2 Requerimiento de confiabilidad
El sistema estará disponible las 24 horas del día, tanto para el trabajo de los usuarios como para las acciones de mantenimiento.
Deberá prevenir los posibles fallos y/o errores que pudieran presentarse y posibilitar una rápida recuperación en dichos casos.
16 2.1.3 Requerimientos de Soporte
El sistema estará bien documentado para garantizar futuros mantenimientos.
Se le debe dar mantenimiento periódico a los servidores de bases de datos controlando la integridad de la información.
2.1.4 Requerimientos de Apariencia o Interfaz Externa
Se podrán distinguir colores atractivos y acordes con los recomendados para los software de salud.
Debe poseer un ambiente amigable, intuitivo, sencillo y de fácil navegación, tratando as í de impedir el rechazo por parte del usuario al tener que interactuar con un sistema no conocido.
Paginación de reportes de búsqueda y listados.
Diseño perfectamente encuadrado para resoluciones de 1024 x 768, pero preparado para verse en otras resoluciones.
2.1.5 Requerimientos de Seguridad
La autenticación de los usuarios en el sistema será garantizada por el Sistema de Autenticación, Autorización y Auditoría (SAAA) al cual estará conectada la aplicación.
Las funcionalidades deberán estar restringidas de acuerdo a los diferentes roles con el objetivo de garantizar que el acceso a la información sea según el nivel de autorización.
El sistema deberá estar protegido ante el acceso no autorizado a la información.
2.1.6 Requerimientos de Software Del lado del cliente:
El cliente podrá tener acceso al sistema a través de los navegadores Internet Explorer 1.5 ó superior y Mozilla Firefox 2.0 o superior.
Sistema operativo Linux o Windows 98 o superior.
17 Del lado del servidor:
Sistema operativo Linux.
Servidor Web Apache 2.2 y PHP 5.
Servidor de Base de Datos PostgreSQL 8.3.
Framework Symfony 1.4.3.
2.1.7 Requerimientos de Hardware Del lado del cliente:
Procesador Pentium III o superior.
256 MB de memoria RAM o superior.
Monitor VGA o superior.
Tarjeta de red.
Del lado del servidor:
Procesador Pentium IV o superior.
2GB de memoria RAM o superior.
Disco Duro de 80 GB.
Monitor tipo VGA o superior.
Tarjeta de red.
2.1.8 Requerimientos de Diseño e Implementación
Se utilizarán los patrones de diseño GRASP.
Para la implementación se utilizará como lenguaje de programación PHP.
2.1.9 Requerimientos de Ayuda y Documentación en línea.
Contará con un manual de usuario para que se pueda explotar al máximo.
Contará con una ayuda digital, a la cual se podrá acceder desde cualquier parte de la aplicación.
18 2.2 Arquitectura de Software y patrones arquitectónicos
La arquitectura del software proporciona una visión global del sistema a construir. Además marca decisiones de diseño tempranas y proporciona el mecanismo para evaluar los beneficios de las estructuras de sistema alternativas.
La arquitectura a utilizar fue definida por el grupo de arquitectura del Centro Especializado en Soluciones de Informática Médica (CESIM) y el MINSAP para todos los programas implementados que se despliegan en INFOMED utilizando los patrones arquitectónicos. Un patrón de arquitectura de software describe un problema particular y recurrente del diseño, que surge en un contexto específico, y presenta un esquema genérico y probado de su solución. A continuación se muestran los patrones seleccionados con algunas de las características particulares.
Arquitectura en capas
La arquitectura en capas es la generalización de la arquitectura Cliente-Servidor, un estilo de programación, cuyo objetivo primordial es la separación de la capa de presentación, capa de negocio y la capa de datos.
Los tres niveles o capas son: [17]
Capa de presentación: Presenta el sistema al usuario, comunica y captura la información del usuario dando un m ínimo de proceso. Esta capa se comunica únicamente con la capa de negocio.
Capa de negocio: La capa de negocio es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio o incluso de lógica del negocio porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para almacenar o recuperar los mismos.
Capa de datos: La capa de acceso a datos contiene clases que interactúan con la base de datos, estas clases altamente especializadas permiten, utilizando los procedimientos almacenados
19 (funciones para interactuar con la base de datos) generados, realizar todas las operaciones con la base de datos de forma transparente para la capa de negocio.
La utilización de esta arquitectura en el caso del módulo Salud Ambiental es debido a que se logra separar la lógica de presentación de la lógica del negocio, aunque esta última se encuentra un tanto acoplada a la lógica de acceso a datos. Sin embargo, se logra una gran abstracción en cuanto al Sistema Gestor de Base Datos a utilizar, por lo que si este es reemplazado el impacto sobre la lógica del acceso a datos será mínimo.
2.2.1 Arquitectura basada en componentes
La Arquitectura Basada en componentes es una rama de la Ingeniería de Software en la c ual se trata con énfasis la descomposición del software en componentes funcionales. Esta descomposición permite convertir componentes pre-existentes en piezas más grandes de software.
Cada componente debe describir de forma completa las interfaces que ofrece, así como las interfaces que requiere para su operación y debe operar correctamente con independencia de los mecanismos internos que utilice para soportar la funcionalidad de la interfaz. Características muy relevantes de la tecnología de programación basada en componentes son la modularidad, la reusabilidad y compatibilidad y en todos ellos coincide con la tecnología orientada a objetos de la que se puede considerar una evolución.
Se debe tener en cuenta que este tipo de arquitectura permite la integración de múltiples sistemas, lo que implica una dependencia en la información gestionada por cada uno de ellos.
Se emplea esta arquitectura porque el sistema estará integrado con componentes del Sistema de Información para la Salud (SISalud) de los que consumirán algunos servicios, tales como:
Sistema de Autenticación, Autorización y Auditoría. (SAAA).
Registro de Unidades de Salud (RUS).
Registro de Ubicación (RU).
Registro Ciudadano (RC).
20 2.2.2 Modelo-Vista-Controlador (MVC)
El Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos.
Modelo: Es el objeto que representa los datos del programa. Maneja los datos y controla todas sus transformaciones. El Modelo no tiene conocimiento específico de los Controladores o de las Vistas, ni siquiera contiene referencias a ellos. Es el propio sistema el que tiene encomendada la responsabilidad de mantener enlaces entre el Modelo y sus Vistas, y notificar a las Vistas cuando cambia el Modelo.
Vista: Es el objeto que maneja la presentación visual de los datos representados por el Modelo. Genera una representación visual del Modelo y muestra los datos al usuario. Interactúa con el Modelo a través de una referencia al propio Modelo.
Controlador: Es el objeto que proporciona significado a las órdenes del usuario, actuando sobre los datos representados por el Modelo. Cuando se realiza algún cambio, entra en acción, bien sea por cambios en la información del Modelo o por alteraciones de la Vista. Interactúa con el Modelo a través de una referencia al propio Modelo. [18]
En el caso del módulo Salud Ambiental se utilizó este patrón ya que el framework utilizado (Symfony) se basa en el mismo y/o implementa de forma que el desarrollo de las aplicaciones sea rápido y sencillo.
2.3 Estrategias de Integración
El Sistema de Salud Ambiental para lograr un completo funcionamiento necesitará consumir varios servicios desarrollados con anterioridad en el SISalud. Los sistemas externos y los aspectos que se solicitarán de ellos son:
Sistema de Autenticación, Autorización y Auditoría (SAAA): este servicio permite conocer el usuario que está autenticado en el sistema, a qué nivel pertenece, qué tipo de usuario es y a qué módulos tiene acceso. Brinda una clave o token a los usuarios registrados que les permite realizar consultas a otros registros del SISalud. También se usa para darle permisos de acceso a los usuarios a las acciones determinadas (autorización).
21 Registro de Unidades de Salud (RUS) para conocer cuál es el nombre de la Unidad de Salud
(US) en la que se encuentra el usuario.
El Registro de Ubicaciones (RU): este servicio permite listar todas las provincias, municipios y las localidades de cada municipio, listar las manzanas por localidad, listar las calles por manzana y listar las calles por localidad, brindando la posibilidad de poder ubicar la dirección de los puertos, aeropuertos y almacenes donde estará la mercancía.
Registro Ciudadano (RC): este servicio permite obtener los datos relacionados con el inspector.
2.4 Seguridad
La seguridad informática consiste en asegurar que los recursos del sistema de inform ación de una organización sean utilizados de la manera que se decidió y que el acceso a la información allí contenida así como su modificación sólo sea posible a las personas que se encuentren acreditadas y dentro de los límites de su autorización.
Symfony posee herramientas que permiten la creación de aplicaciones seguras, en las que los usuarios necesitan estar autenticados antes de acceder a alguna característica o a partes de la aplicación. Añadir esta seguridad a una aplicación requiere dos pasos: dec larar los requerimientos de seguridad para cada acción y autenticar a los usuarios con privilegios para que puedan acceder estas acciones seguras.
En Symfony, los privilegios están compuestos por dos partes:
Las acciones seguras requieren que los usuarios estén autenticados.
Las credenciales son privilegios de seguridad agrupados bajo un nombre y que permiten organizar la seguridad en grupos.
Para restringir el acceso a una acción se crea y se edita un archivo de configuración YML llamado security.ymlen el directorio config/ del módulo. En este archivo se pueden especificar los requerimientos de seguridad que los usuarios deberán satisfacer para cada acción o para todas las acciones.
22 Las acciones no incluyen restricciones de seguridad por defecto, así que cuando no existe el archivo security.yml o no se indica ninguna acción en ese archivo, todas las acciones son accesibles por todos los usuarios. [19]
En el caso del sistema de Salud Ambiental las tareas de autenticación serán confiadas al componente de seguridad del Sistema de Información para la Salud (SISalud), el SAAA; para garantizar la autenticación de los usuarios y para tratar la autorización se utilizará un sistema de roles y permisos previamente definido que verificará los privilegios de cada uno de los usuarios en determinadas áreas.
2.5 Modelo de Despliegue
Un diagrama de despliegue muestra las relaciones físicas entre los componentes hardware y software en el sistema final, es decir, la configuración de los elementos de procesamiento en tiempo de ej ecución y los componentes de software (procesos y objetos que se ejecutan en ellos).
Un diagrama de despliegue es un grafo de nodos unidos por conexiones de comunicación. Un nodo puede contener instancias de componentes software, objetos, procesos (caso particular de un objeto). En general un nodo será una unidad de computación de algún tipo, desde un sensor a un mainframe.
Las instancias de componentes software pueden estar unidas por relaciones de dependencia, posiblemente a interfaces (ya que un componente puede tener más de una interfaz).
El Sistema Salud Ambiental estará desplegado de la siguiente manera:
El código fuente de la aplicación se alojará en un servidor web ubicado en Infomed al cual el usuario accederá a través de un navegador web mediante el protocolo HTTP, haciéndole peticiones y recibiendo respuesta del mismo desde una computadora cliente. Esta a su vez se encontrará conectada a una impresora mediante el puerto USB para imprimir reportes y datos útiles para el usuario.
El servidor de aplicación de Salud Ambiental se comunicará con el servidor de SiSalud haciendo uso de servicios web XML y mediante el protocolo SOAP para brindar los servicios definidos que intervienen en el correcto funcionamiento de la aplicación.
23 Esta contará también con un servidor de base de datos que establecerá una comunicación mediante el protocolo TCP/IP para el obtener los datos y ser mostrados al cliente.
A continuación se presenta el Diagrama de Despliegue correspondiente al Módulo Salud Ambiental del Sistema de Control Sanitario Internacional.
Figura 2: Diagrama de Despliegue.
2.6 Estrategias de Codificación. Estándares y estilos
Para la realización de la aplicación se tuvieron en cuenta las restricciones de nomenclaturas y los estándares de codificación definidos por el Grupo de Arquitectura y Tecnologías de la Facultad 7.
Restricciones de nomenclatura
Idioma: Se debe utilizar como idioma el español, las palabras no se acentuarán.
Identación
Objetivo: Lograr una estructura uniforme para los bloques de código así como para los diferentes
24 niveles de anidamiento.
Inicio y fin de bloque Se recomienda dejar dos espacios en blanco desde la instrucción anterior para el inicio y fin de bloque {}. Lo mismo sucede para el caso de las instrucciones if, else, for, while, do while, switch, foreach.
Aspectos Generales El identado debe ser de dos espacios por bloque de código. No se debe usar el tabulador; ya que este puede variar según la PC o la configuración de dicha tecla.
Los inicios ( { ) y cierre ( } ) de ámbito deber estar alineados debajo de la declaración a la que pertenecen y deben evitarse si hay sólo una instrucción.
Nunca colocar { en la línea de un código cualquiera, esto requiere una línea propia.
Comentarios, separadores, líneas, espacios en blanco y márgenes.
Objetivo: Establecer un modo común para comentar el código de forma tal que sea comprensible con sólo leerlo una vez.
Ubicación de comentarios
Al inicio de cada clase o función y al final de cada bloque de código.
Se recomienda comentar al inicio de la clase o función especificando el objetivo de la misma así como los parámetros que usa (especificar tipos de dato y objetivo del parámetro), entre otras cosas.
Líneas en blanco Se emplean antes y
después de
métodos, clases y estructuras.
Se recomienda dejar una línea en blanco antes y después de la declaración de una clase o de una estructura y de la implementación de una función.
Espacios en blanco
Entre operadores lógicos y aritméticos.
Se recomienda usar espacios en blanco entre estos operadores para lograr una mayor legibilidad en el código. Ejemplo:
producto = nomproducto
25 Aspectos
generales
Sobre el comentario. Se debe evitar comentar cada línea de código. Cuando el comentario se aplica a un grupo de instrucciones debe estar seguido de una línea en blanco. En caso de que se necesite comentar una sola instrucción se suprime la línea en blanco o se escribe a continuación de la instrucción.
Sobre los espacios en blanco.
No se debe usar espacio en blanco:
Después del corchete abierto y antes del cerrado de un arreglo.
Después del paréntesis abierto y antes del cerrado.
Antes de un punto y coma.
Variables y constantes Apariencia de variables
Las variables tendrán un prefijo para el tipo de datos en minúscula.
El nombre que se le da a las variables debe comenzar con la primera letra en minúscula, la cual identificara el tipo de datos al que se refiere (ver tabla 1.1). En caso de que sea un nombre compuesto se empleará notación CamellCasing**.
Ejemplo: sNombrePaciente Apariencia de
constantes
Todas sus letras en mayúscula.
Se deben declarar las constantes con todas sus letras en mayúscula.
Aspectos generales Nombres de las variables y constantes.
El nombre empleado debe permitir que con sólo leerlo se conozca el propósito de la misma.
Clases y Objeto
Objetivo: Nombrar las clases e instancias de forma estándar para todas las aplicaciones.
26 Apariencia de clases
y objetos
Primera letra en mayúscula.
Los nombres de las clases deben comenzar con la primera letra en mayúscula y el resto en minúscula. En caso de que sea un nombre compuesto se empleará notación PascalCasing*.
Ejemplo: MiClase(). Para el caso de las instancias se comenzara con un prefijo que identificara el tipo de dato; este se escribirá en minúscula.
Apariencia de atributos
Primera letra en minúscula.
El nombre que se le da a los atributos de las clases debe comenzar con la primera letra en minúscula, la cual estará en correspondencia al tipo de dato al que se refiere. En caso de que sea un nombre compuesto se empleará notación CamellCasing**.
Apariencia de las funciones
Primera letra en mayúscula.
Para nombrar las funciones se debe tratar de utilizar verbos que denoten la acción que hace la función. Se empleará notación PascalCasing*.
Ejemplo: function BuscarUnidad(). Si son funciones que obtienen un dato se emplea el prefijo get y si fijan algún valor se emplea el prefijo set.
Declaración de
parámetro en
funciones
Agrupados por tipos Poner los string 1 numéricos 2, además, agrupar según valores por defecto.
Los parámetros que se le pasan a las funciones se recomienda sean declarados de forma tal que estén agrupados por el tipo de dato que contienen, especificando el tipo de datos (tabla 1.1).
Aspectos generales Sobre las clases, los objetos, los atributos y las funciones.
El nombre empleado para las clases, objetos, atributos y funciones debe permitir que con sólo leerlo se conozca el propósito de los mismos.
Bases de Datos, Tablas, Esquemas y Campos
Apariencia de la Base Las dos primeras letras Los nombres de las Bases de Datos deben comenzar con el prefijo bd a continuación
27 de Datos. representan el tipo. underscoard y luego el nombre completamente en
minúscula.
En caso de que sea un nombre compuesto se empleará notación. Los nombres serán cortos y descriptivos. Ejemplo: bd_balancematerial.
Apariencia de las vistas
Las dos primeras letras representan el tipo.
Todas las letras en minúscula.
El nombre a emplear para las vistas deben comenzar con el prefijo vt seguido de underscoard y el nombre debe escribirse con todas las letras en minúscula para evitar problemas con el Case Sensitive del gestor.
Ejemplo:
createview „vt_finanzas‟;
Apariencia de las tablas
Las dos primeras letras representan el tipo.
Todas las letras en minúscula.
El nombre a emplear para las tablas debe comenzar con el prefijo tb seguido de underscoard y luego debe escribirse todas las letras en minúscula. En caso de que sea un nombre compuesto se utilizara underscoard para separarlo.
Ejemplo: „tb_producto‟;
Tablas que
representen Relaciones
Las dos primeras letras representan el tipo.
Todas las letras en minúscula.
El nombre a emplear para estas tablas de relación debe comenzar con el prefijo tr seguido de underscoard y el nombre será la concatenación del nombre de las dos tablas que la generaron, separados por uderscoard todo en minúscula.
Ejemplo: „tr_paciente_enfermedad‟
Tablas que
representen nomencladores.
Las dos primeras letras representan el tipo.
Todas las letras en minúscula.
El nombre a emplear para estas tablas de relación debe comenzar con el prefijo tn seguido de underscoard. El nombre será corto y descriptivo todo en minúscula.
28 Ejemplo: „tn_color_piel‟
Apariencia de los procedimientos
almacenados.
Las dos primeras letras representan el tipo.
Todas las letras en minúscula.
El nombre a emplear para los procedimientos debe comenzar con el prefijo pa seguido de underscoard y luego debe escribirse todas las letras en minúscula en caso de que sea un nombre compuesto se utilizara underscoard para separarlo.
Ejemplo:
pa _ paciente_especialidad.
Apariencia de los campos
Todas las letras en minúscula.
El nombre a emplear para los campos debe escribirse con todas las letras en minúscula para evitar problemas con el Case Sensitive del gestor.
Ejemplo:
„idproducto‟;
Nombre de los campos
En caso de
identificadores.
Todos los campos identificadores van a comenzar con el identificador id seguido de underscoard y posteriormente el nombre del campo
Ejemplo:
id_municipio.
Sentencias SQL Todas las letras en mayúscula.
Las palabras correspondientes a las sentencias SQL y sus parámetros deben ir en mayúsculas.
Aspectos generales Sobre las BD, vistas, tablas atributos y procedimientos.
El nombre empleado para las Bases de Datos, las vistas, las tablas, los campos y los procedimientos almacenados, deben permitir que con sólo leerlos se conozca el propósito de los mismos.
Controles
Apariencia de los Los controles tendrán El nombre que se le da a los controles deben
29 controles. un prefijo para el tipo de
datos en minúscula.
comenzar con las primeras letras en minúscula, las cuales identificaran el tipo de datos al que se refiere (ver tabla 1.2).En caso de que sea un nombre compuesto se empleará notación CamellCasing**.
Ejemplo: btnAceptar
**Notación PascalCasing: Los identificadores y nombres de variables, métodos y funciones están compuestos por múltiples palabras juntas iniciando cada palabra con letra mayúscula. Ejemplo:
NotacionPascalCasing.
**Notación CamellCasing: Los identificadores y nombres de variables, métodos y funciones están compuestos por múltiples palabras juntas iniciando cada palabra con letra mayúscula, excepto la primera palabra que debe iniciar con minúscula. Ejemplo: notación CamellCasing.
Estándares de codificación
Para el lenguaje de programación del lado del servidor PHP se utilizaron los estándares de codificación definidos en http://pear.php.net/manual/en/standards.php.
En este capítulo, se definieron los requisitos no funcionales con los que contará el sistema de Salud Ambiental entre los que se encuentran los de Seguridad, Software y Hardware, entre otros. Se realizó un análisis de los elementos de arquitectura presentes en el desarrollo del software, definiéndose como patrones arquitectónicos el Modelo-Vista-Controlador, la Arquitectura en Capas y la basada en Componentes.
Se definió la autenticación del sistema que será principalmente a través del SAAA y la distribución del hardware en la cual se desplegará el sistema teniéndose un servidor de aplicaciones, un servidor de aplicaciones del SISalud, uno de BD, una PC cliente y una impresora.
30 CAPÍTULO 3. DESCRIPCIÓN Y ANÁLISIS DE LA SOLUCIÓN PROPUESTA
En el desarrollo de este capítulo se abordará primeramente una valoración sobre el diseño propuesto por el analista, además de la descripción de las clases del sistema y de las tablas de la Base de Datos;
observándose también el Modelo de Datos y se presenta la Vista de Componentes.
3.1 Valoración crítica del diseño propuesto por el analista
En el diseño propuesto por el analista ocurrieron cambios durante el transcurso del desarrollo del sistema.Uno de los cambios que se realizó fue en el prototipo no funcional de la aplicación, debido a que el Centro Especializado en Soluciones de Informática Médica (CESIM) definió un diseño estándar para todas sus aplicaciones y el anterior no estaba en correspondencia con el mismo.
3.2 Descripción de las nuevas clases u operaciones necesarias
A partir del enfoque Modelo Vista Controlador (MVC) del Symfony, las nuevas clases a describir serán de tipo Controladora, Modelo o Vista (Interfaz). Seguidamente se exponen sólo las controladoras y los modelos de los casos de uso críticos del sistema.
Nombre: GestionarExtracciónphp Tipo de clase: Controladora Para cada responsabilidad:
Nombre: executeIndex()
Descripción: Muestra la vista principal para las acciones de gestionar extracción.
Nombre: Aut_Pext()
Descripción: Autoriza los permisos de extracción de un producto.
Nombre: Listp_aext()
Descripción: Mostrar todos los productos autorizados de extracción.
31 Tabla 1: Descripción de la clase controladora Gestionar Extracción
Tabla 2: Descripción de la clase controladora Autorizar Extracción Producto Nombre: Listp_pend_aext()
Descripción: Mostrar productos pendientes de autorización de extracción.
Nombre: AutorizarExtracciónProducto.php Tipo de clase: Controladora
Para cada responsabilidad:
Nombre: executeIndex()
Descripción: Muestra la vista principal para la acción de autorizar extracción de un producto.
Nombre: Aut_ext()
Descripción: Autoriza la extracción de un producto.
Nombre: GestionarInspecciónSEstatal.php Tipo de clase: Controladora
Para cada responsabilidad:
Nombre: executeIndex()
Descripción: Muestra la vista principal para las acciones de gestionar inspección sanitaria estatal.
32 Tabla 3: Descripción de la clase controladora Gestionar Inspección Sanitaria Estatal
Tabla 4: Descripción de la clase controladora Registrar Datos de Transportación Marítima o Aérea
Nombre: Add()
Descripción: Adicionar los datos de una Inspección Sanitaria Estatal.
Nombre: Search()
Descripción: Verifica si se realizó una inspección sanitaria o no.
Nombre: List()
Descripción: Mostrar los datos de las inspecciones sanitarias estatales realizadas.
Nombre: Registrar DatosTransportMarítimaoAérea.php Tipo de clase: Controladora
Para cada responsabilidad:
Nombre: executeIndex()
Descripción: Muestra la vista principal para la acción de registrar los datos de la transportación marítima o aérea.
Nombre: Add()
Descripción: Registra los datos de la transportación marítima o aérea.
Nombre: List()
Descripción: Muestra los datos de transportación marítima o aérea.
33 Tabla 5: Descripción de la clase controladora Registrar Incidencias
Tabla 6: Descripción de la clase controladora Adicionar Datos a la Carga Nombre: RegistrarIncidencias.php
Tipo de clase: Controladora Para cada responsabilidad:
Nombre: executeIndex()
Descripción: Muestra la vista principal para la acción de registrar incidencias.
Nombre: Add()
Descripción: Registra las incidencias ocurridas.
Nombre: AdicionarDatosCarga.php Tipo de clase: Controladora
Para cada responsabilidad:
Nombre: executeIndex()
Descripción: Muestra la vista principal para la acción de registrar datos de la carga.
Nombre: Add()
Descripción: Registra los datos de la carga.
34 Tabla 7: Descripción de la clase modelo Gestionar Extracción
Nombre: Gestionar Extracción.class.php Tipo de clase: Modelo
Para cada responsabilidad:
Nombre: Permiso_extraccion() Descripción: Constructor de la clase.
Nombre: Listp_aext($id_permiso_extraccion)
Descripción: Método que se encarga de mostrar todos los productos autorizados de extracción.
Nombre: Listp_pend_aext($id_permiso_extraccion)
Descripción: Método que se encarga de mostrar todos los productos pendientes de autorización de extracción.
Nombre: AutorizarExtracciónproducto.class.php Tipo de clase: Modelo
Para cada responsabilidad:
Nombre: Permiso_extraccion() Descripción: Constructor de la clase.
Nombre: Aut_ext($id_permiso_extraccion)
35 Tabla 8: Descripción de la clase modelo Autorizar Extracción de un producto
Tabla 9: Descripción de la clase modelo Gestionar Inspección Sanitaria Estatal Descripción: Método que se encarga de autorizar la extracción de un producto.
Nombre:GestionarInspecciónSEstatal.class.php Tipo de clase: Modelo
Para cada responsabilidad:
Nombre: Inspeccion()
Descripción: Constructor de la clase.
Nombre: Add($id_inspeccion)
Descripción: Método que se encarga de adicionar los datos de una Inspección Sanitaria Estatal
Nombre: Search($id_inspeccion)
Descripción: Método que se encarga de verificar si se realizó una inspección sanitaria o no.
Nombre: List($id_inspeccion)
Descripción: Método que se encarga de mostrar los datos de las inspecciones sanitarias estatales realizadas.
36 Tabla 10: Descripción de la clase modelo Registrar Datos de la Transportación Marítima o Aérea
Tabla 11: Descripción de la clase modelo Registrar Incidencias Nombre: RegistrardatosTransportaciónMarítimaoAérea.class.php Tipo de clase: Modelo
Para cada responsabilidad:
Nombre: Inspeccion()
Descripción: Constructor de la clase.
Nombre: Add($id_inspeccion)
Descripción: Método que se encarga de registrar los datos de la transportación marítima o aérea.
Nombre: List($id_inspeccion)
Descripción: Método que se encarga de mostrar los datos de transportación marítima o aérea.
Nombre: RegistrarIncidencias.class.php Tipo de clase: Modelo
Para cada responsabilidad:
Nombre: Incidencia()
Descripción: Constructor de la clase.
Nombre: Add($id_incidencia)
Descripción: Método que se encarga de registrar las incidencias ocurridas.
