UNIVERSIDAD DE ORIENTE SEDE JULIO ANTOMIO MELLA

FACULTAD DE INGENIERIA ELÉCTRICA

DEPARTAMENTO DE INFORMÁTICA

SISTEMA DE INFORMACIÓN PARA LA GESTIÓN Y CONTROL DE

LOS RECURSOS Y SERVICIOS ADMINISTRATIVOS DEL CIROA

Tesis para optar al grado de Ingeniero en Informática

Estudiante Diplomante:

DUSTIN EDWARD FRASER

Tutor:

ALBERTO SANCHEZ MATURELL

Santiago de Cuba, Cuba, (Junio, 2010)

2010, Dustin Edward Fraser

UNIVERSIDAD DE ORIENTE SEDE JULIO ANTOMIO MELLA

FACULTAD DE INGENIERIA ELÉCTRICA

DEPARTAMENTO DE INFORMÁTICA

SISTEMA DE INFORMACIÓN PARA LA GESTIÓN Y CONTROL

DE LOS RECURSOS Y SERVICIOS ADMINISTRATIVOS DEL

CIROA

Estudiante Diplomante:

DUSTIN EDWARD FRASER

Tesis (Proyecto) presentada(o) a la Comisión integrada por los

profesores:

TUTOR: Ing. Alberto Sánchez Maturell

OPONENTE: MSc. Pedro Milá Ortiz

TRIBUNAL: MSc. Ernesto Rodríguez Fernàndez

TRIBUNAL: Ing. Martin Morcate

TRIBUNAL: Ing. Daylet Clavería Âvila

Para completar las exigencias del grado de Ingeniero Informático.

Santiago de Cuba, (Junio, 2010)

DECLARACIÓN DE AUTORÍA.

Declaro que soy el único autor de este trabajo y autorizo a la

Universidad de Oriente (UO) y << >> a hacer

uso de este trabajo como estimen conveniente.

Para que así conste firmo la presente a los días del mes de

del 2010.

______________ ______________

Dustin Edward Fraser Alberto Sanchez Maturell

Firma del Autor Firma del Tutor

OPINIÓN DEL USUARIO DEL TRABAJO DE DIPLOMA.

El Trabajo de Diploma, titulado Sistema de Información para La Gestión y

Control de los recursos y servicios administrativos del CIROA, fue

realizado en la Universidad de Oriente, Facultad de Ingeniería Eléctrica,

Carrera de Informática. Esta entidad considera que, en correspondencia

con los objetivos trazados, el trabajo realizado le satisface

Totalmente

Parcialmente en un ____ %

Los resultados de este Trabajo de Diploma le reportan a esta entidad los

beneficios siguientes (cuantificar):

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

Como resultado de la implantación de este trabajo se reportará un efecto

económico que asciende a ________.

Y para que así conste, se firma la presente a los ____ días del mes de

________ del año _____.

________________________________ ____________

Representante de la entidad Cargo

___________ ___________

Firma Cuño

OPINIÓN DEL TUTOR DEL TRABAJO DE DIPLOMA. Título:

Autor: Dustin Edward Fraser

El tutor del presente Trabajo de Diploma considera que durante su

ejecución el estudiante mostró las cualidades que a continuación se

detallan.

<Aquí el tutor debe expresar cualitativamente su opinión y medir

(usando la escala: muy alta, alta, adecuada) entre otras las

cualidades siguientes:

- Independencia

- Originalidad

- Creatividad

- Laboriosidad

- Responsabilidad >

<Además, debe evaluar la calidad científico-técnica del trabajo

realizado (resultados y documento) y expresar su opinión sobre el

valor de los resultados obtenidos (aplicación y beneficios) >

Por todo lo anteriormente expresado considero que el estudiante está

apto para ejercer como Ingeniero Informático; y propongo que se le

otorgue al Trabajo de Diploma la calificación de <nota>. <Además, si

considera que los resultados poseen valor para ser publicados,

debe expresarlo también>

_________________________ _______________

Alberto Sanchez Maturell

Firma Fecha

Dedicatoria.

A mis Padres, hermanos y amigos,

quienes me apoyaron mucho.

A mí querido hijo por quien

trabajo tanto.

Agradecimientos.

AGRADECIMIENTOS.

A Dios por haberme dado la oportunidad de venir a estudiar en Cuba y pasar los años

sin alguna dificultad grave. Por siempre no dejar que las vueltas de la vida me caen.

A los compañeros del aula como Omar, Hubert, Ricardo, Fernando, Jorge y Madrazo

quienes me apoyaron mucho especialmente en los primeros pasos de la carrera.

A todos mis profesores, en especial la profesora Lucia Sotomayor y al profesor Alberto

Sanchez Maturell.

En fin, a mi país, Guyana y Cuba y todos los que están a mi lado y saben que yo los

aprecio.

Índice General.

ÍNDICE GENERAL.

INTRODUCCIÓN. ...................................................................................................... 8

CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA. ............................................... 15

Introducción. ................................................................................................... 15

1.1 Fundamentos del diseño Teórico de Investigación. Conceptos generales.

15

1.1.1 ¿Qué es gestión? ........................................................................ 15

1.1.2 Funciones de gestión. ................................................................. 15

1.1.3 ¿Qué es gestión de software? .................................................. 16

1.1.4 ¿Por qué el software es necesario? ......................................... 16

1.1.5 ¿Qué es un Sistema Informático? ............................................ 17

1.1.6 Ingeniería de software. ............................................................... 18

1.1.7 Diseño Web. ................................................................................. 18

1.1.8 Arquitectura de sitios web. ......................................................... 19

1.1.9 Arquitectura de aplicaciones web. ............................................ 20

1.1.10 Arquitectura cliente-servidor .................................................... 21

1.2 Fundamentos del diseño Tecnológico de la Investigación. Tendencias,

Herramientas y Tecnología a utilizar. ................................................. 22

1.2.1 Aplicaciones Ricas de Internet (RIA)........................................ 22

1.2.2 Adobe Flex Builder. ..................................................................... 23

1.2.3 Lenguaje de Programación a utilizar. ....................................... 24

1.2.4 Eclipse. .......................................................................................... 28

1.2.5 Sistema de Gestión de Base de Datos (SGBD). .................... 29

1.3 Metodologías de desarrollo del software y herramientas CASES. . 33

1.3.1 Metodologías agiles y pesadas. ........................................................ 33

1.3.2 El Lenguaje Unificado de Modelación UML ............................ 38

1.3.3 Herramienta CASE. Rational Rose. ......................................... 39

1.4 Patrón de arquitectura Tres Capas. ..................................................... 40

CAPÍTULO 2. ESTUDIO PRELIMINAR DEL SISTEMA. ................................. 44

Introducción. ................................................................................................... 44

2.1 Objeto de estudio. ................................................................................... 44

2.1.1 Objeto de automatización. ......................................................... 44

2.1.2 Información que se maneja........................................................ 45

Índice General.

2.2 Modelo de negocio. ................................................................................. 46

2.2.1 Identificación de los actores del negocio. ................................ 46

2.2.2 Identificación de los trabajadores del negocio. ....................... 47

2.2.3 Descripción de los procesos de negocio. ................................ 48

2.2.3 Realización de los casos de uso del negocio. ........................ 49

2.2.4 Diagrama de clases de objetos del negocio. .......................... 51

2.2.5 Especificación de los requisitos funcionales. .......................... 52

2.2.6 Especificación de los requisitos no funcionales. .................... 55

2.2.7 Definición de los Casos de Uso. ............................................... 57

Conclusiones Parciales. ................................................................................ 68

CAPÍTULO 3. ANÁLISIS Y DISEÑO DEL SISTEMA ........................................ 69

Introducción. ................................................................................................... 69

3.1 Modelo de Análisis. ................................................................................. 69

3.2 Modelo del Diseño. ................................................................................. 70

3.2.1 Diagrama de Clases del Diseño. .............................................. 70

3.2.3 Modelo Físico de la BD. ............................................................ 71

3.2.6 Diagrama de Despliegue. ........................................................... 71

Conclusiones Parciales. ................................................................................ 73

CAPÍTULO 4. IMPLEMENTACIÓN Y PRUEBA DEL SISTEMA. .................... 74

Introducción. ................................................................................................... 74

4.1 Diagrama de componentes. ................................................................. 75

4.2 Prueba de caja negra. ............................................................................ 75

Conclusiones Parciales. ................................................................................ 76

GLOSARIO DE TÉRMINOS .................................................................................. 77

CONCLUSIONES GENERALES. ......................................................................... 82

RECOMENDACIONES. ......................................................................................... 83

REFERENCIA BIBLIOGRáFica ........................................................................... 84

BIBLIOGRáFICA ...................................................................................................... 85

ANEXO 1. MODELO DE NEGOCIO. ................................................................... 86

Índice General.

ANEXO 2. DIAGRAMA DE CLASES DEL ANÁLISIS. ...................................... 88

ANEXO 3. DIAGRAMA DE CLASES DEL DISEÑO. ......................................... 91

ANEXO 4. DIAGRAMA FISICO DE LA BASE DE DATOS. ............................. 94

ANEXO 5. DIAGRAMA DE COMPONENTES. ................................................... 95

ANEXO 6. VISTA DE LA SISTEMA. .................................................................... 96

Resumen.

RESUMEN.

Actualmente las empresas reflejan la enorme necesidad de aplicar Sistemas de Gestión como una

herramienta precisa para profundizar en el control de toda la información que se desea manejar. En el

Centro Recreativo Orestes Acosta denominada “CIROA” perteneciente a la Empresa Provincial de

Recreación y Alojamiento, “Parque Baconao”, se dificulta mucho la administración de servicios y de

productos en el almacén y otros recursos logísticos sin una herramienta informática, esta gestión es

realizada de forma primitiva, es decir manualmente, lo cual hace que se dificulte la productividad, no

existe un historial de la demanda de los clientes, un registro de los hechos económicos, etc. Por lo que el

presente trabajo consiste en el análisis, diseño e implementación de la solución a la problemática

definida, es decir una aplicación Web para mejorar la gestión de los procesos de negocios existentes.

Se utilizó herramientas tecnológicas novedosas tales como Flex SDK que incluye su propio compilador

que a través del MXML nos permite crear interfaces sofisticadas con efectos visuales y con

comportamiento y como un complemento a este está Action Script como lenguaje de programación que

sigue el paradigma Orientado a Objetos que en el ambiente desarrollo de Flex desarrolla la lógica del

cliente añadiendo interacción dinámica entre los componentes de la aplicación. Como metodología el

Proceso Unificado de Desarrollo de Software versión Ultra Light con ayuda del Lenguaje Unificado de

Modelación (UML: Unified Modeling Language) y su herramienta por excelencia el Rational Rose,

quienes se encargan de crear destrezas indispensables para crear sistemas de software bien diseñados,

robustos y de fácil mantenimiento.

Palabras Claves: Gestión, Sistema, logística de almacén, administración de servicios, recursos,

Abstract.

ABSTRACT.

At present many business entities are desirous of implementing information technology systems as a tool

to guarantee the control of all the information that they process. The business entity named Centro

Recreativo Orestes Acosta, CIROA, belonging to the state run business; Parque Bacanoa has many

difficulties with the administration of the services, products in storage and also other logistic resources.

They are desirous of implementing an information technology system since most of their records are stored

on hard copies. This is difficult to maintain since the information is never readily available by those

personnel that require it and this in turn affects the productivity of the business. Most importantly there

does not exist a history of the demands by clients, a registry of sales, among other things. That is the

reason for this current project which intends to analyze, design and implement a solution to the defined

problem, in other words a Web application that will better the business process of this entity.

For the development of this project, technology such as the Flex SDK along with MXML was used to

guarantee sophisticate GUI interfaces; Action script as part of the program logic and PHP as the database

model. The version Ultra Light of the Rational Unified Process was used as the design methodology along

with the Unified Modeling Language as it supplement. The tool named Rational Rose was also used to

create and design the software.

Keywords: business entity, information technology, sales, Web application, logistic.

Introducción.

8

INTRODUCCIÓN.

La informática es una ciencia eminentemente de apoyo administrativo, ya que proporciona la información

de calidad que se necesita en cada una de las etapas del proceso administrativo, lo que permite la toma

de decisiones con menor grado de riesgos. Los sistemas de información intervienen y son necesarios en

cada una de las etapas del proceso administrativo de la organización, proporcionando información como

graficas de de aumento o disminución de la demanda de algún producto o servicio, de las ventas, etc.

El Centro Recreativo Orestes Acosta es una unidad básica de la Empresa Provincial de Recreación y

Alojamiento, Parque Baconao. El tiene como estructura organizacional una dirección con varios sub-

departamentos y tres bloques gastronómicos.

Los bloques son los principales centros de costos que se dedica a la preparación del servicio de

gastronomía. Se ofrece este servicio por lo que esta elaborado en la carta menú. Esta carta menú

designa al conjunto de alimentos y bebidas que deben ser debidamente elaborados. Los mismos pueden

conformar una o varias comidas, tales como, un desayuno, un almuerzo, una cena concentrada, un buffet

y otros. La correcta planificación y selección de los alimentos y bebidas distribuidos en grupos permite al

personal especializado programar de forma oportuna y profesional las actividades y el trabajo integral de

las cocinas. Antes de hacer esto, hay que tener información sobre los alimentos y bebidas que existe en el

almacén para nombrar a la lista detallada, el listado de precios, o lo que es lo mismo la carta menú.

En ella aparece el conjunto de platos que la cocina puede preparar en cualquier momento del servicio o

petición del cliente, con la particularidad de que cada manjar que se especifica lleva un precio

determinado. Tanto la variedad de los precios como los precios deben ir en correspondencia con la

categoría del establecimiento.

Los sub-departamentos son:

Recursos Humanos

Economía

Aseguramiento

Servicios

Mantenimiento

Introducción.

9

Recreación

Los tres bloques gastronómicos son:

Bloque 1:

i. Discoteca

ii. Heladería

Bloque 2:

i. Parrillada

ii. Bar

Bloque 3:

i. Restaurante

ii. Cafetería

Misión de la Empresa

Es una organización que brinda servicios de alojamiento, recreación y gastronomía a través de playas y

otras instalaciones, en moneda nacional líberamente convertible para satisfacer con calidad las

necesidades de los clientes y alcanzar la eficacia de la organización y los trabajadores.

Visión

Lograr la satisfacción de los clientes con la calidad que estos desean y merecen, con ética y

profesionalidad, con un personal calificado y emprendedor, conjuntamente con el uso adecuado del

medio ambiente, el entorno geográfico cultural y el financiamiento constituirán el soporte que posibilita

dicho logro.

Servicios que ofrecen

En el CIROA se ofrece una variedad de servicios recreativos durante toda la semana menos los lunes. Los

lunes se hace una limpieza general, revisión y reparación de los mobiliarios. También, los jefes hablan con

los trabajadores de los problemas existentes, el plan cultural que se dan en la semana, etc. Desde el

Introducción.

10

martes al domingo se ofrece servicios de Restaurante, Heladería, Bar, Cafetería, Cabaret, Piscina, Sala

de bailar, Discoteca y servicio de Gimnasio.

El jefe de Servicios del CIROA es el encargado manipular toda la información concerniente a los servicios

que prestan, en la entidad, a la población. Algunos de estos servicios siguen ciertas normas y son

llenados varios formularios para dar y cumplir un buen servicio. Todas las informaciones se controlan de

forma manual lo que trae consigo que se dificulte el adecuado control de la información, ocasionando

principalmente un mayor esfuerzo de trabajo para los administrativos, entre otras razones encontramos

que no existe un historial de los servicios prestados que brinde la información estadística.

Por lo anteriormente expuesto se hace necesario dar solución al problema a resolver de la no existencia

de una herramienta informática en el Centro Recreativo Orestes Acosta que permita la segura

administración de la información de los servicios que se prestan y los productos almacenados.

Según los estudios realizados hasta el momento en la etapa que se describe, los fenómenos detectados

son los siguientes:

Los datos relacionados a los clientes y los hechos económicos se guarda en papeles,

deteriorándose con el tiempo, haciendo tediosa la búsqueda de la información referente a un

historial de los servicios prestados.

No conocen de antemano qué materias primas deben utilizar, permitiéndose controlar y planificar

las compras y el almacenaje en función de la producción y las ventas.

No saben con tiempo suficiente qué equipos van a utilizar con mayor rigor, dándose paso al

cumplimento de los planes de higiene, manteamiento, control de vectores y el ahorro de energías

planificadas.

Para crear una oferta hay que realizar una gestión de averiguación de la disponibilidad de un

conjunto de alimentos y bebidas en el almacén.

Introducción.

11

Cuando se crea una oferta hay que designar al conjunto disponible de alimentos y bebidas que

deberán ser debidamente elaborados. Los mismos depende si es un desayuno, un almuerzo, una

cena concentrada, un buffet y otros.

Los precios de cada oferta se calcula de forma manual en función de la unidad/medida que sale del

almacén.

En los casos de solicitudes por clientes o los bloques, los pedidos de almacén se hacen mediante

una solicitud por escrito.

Se desconoce la relación entre las ventas, los cobros y las salidas del almacén

Dado este problema queda definido como objeto de estudio administrar los hechos económicos, la

demanda de los servicios y el almacén. El campo de acción es el Centro Recreativo Orestes Acosta

quién requiere de una solución informática que permita la debida y segura gestión de la información.

Por lo antes planteado el objetivo general es desarrollar un análisis, diseño e implementación de un

sistema informático capaz de automatizar los procesos de administración de productos en el almacén y

otros recursos logísticos y en el Centro Recreativo Orestes Acosta.

Como objetivos específicos se tiene:

Utilizar el Proceso de Unificado de Desarrollo del Software para obtener un diseño sofisticado del

sistema.

Obtener los Modelos de Casos de Uso, Análisis y Diseño del sistema utilizando como herramienta

CASE, Rational Rose y como lenguaje de modelado UML.

Implementar el sistema.

Para dar cumplimiento a los objetivos trazados, se desarrollaron las siguientes tareas:

Realizar un estudio del entorno de trabajo y su estado actual.

Identificar las necesidades del cliente.

Introducción.

12

Describir los procesos que se van a automatizar en el sistema.

Declarar los requisitos que debe cumplir el sistema.

Modelar conceptualmente las clases que están implicadas en el sistema.

Desarrollar los diagramas que describen el diseño Web del sistema.

Diseñar el modelo físico de la base de datos del sistema.

Realizar el diseño de la interfaz de usuario.

Implementación y prueba del sistema.

De acuerdo a lo anterior argumentado se define entonces como idea a defender que con el desarrollo del

sistema informático para la administración de los servicios, y productos en el almacén entre otros recursos

logísticos en el Centro Recreativo Orestes Acosta se garantizará el mayor, adecuado y seguro control

administrativo de estas informaciones.

La investigación se desarrolla sobre la base de la concepción dialéctico materialista. Se han empleado

métodos científicos fundamentalmente los métodos teóricos:

Métodos Teóricos

Inducción y Deducción: Es empleado para realizar un análisis de las necesidades del

área del centro, de disponer de un sistema informático para la administración de la

información de los productos en el almacén y otros recursos logísticos.

Análisis y Síntesis: Utilizada para el estudio de las varias herramientas de las que se

dispone, así como para el análisis de la información estudiada.

Modelación: Es la técnica fundamental a usar para el diseño del sistema informático a

desarrollar.

Histórico – lógico: Para el análisis del objeto en su devenir histórico, teniendo en cuenta

los antecedentes, desarrollo y perfeccionamiento del proceso del desarrollo de

aplicaciones y servicios Web en el mundo y en Cuba.

Además de los métodos teóricos que se mencionaron anteriormente, también son utilizados métodos

empíricos como:

Introducción.

13

Métodos Empíricos

Entrevista: Utilizada con personal del centro para obtener información clara y detallada.

Estudio de Materiales: Fue empleada para informarse del contenido de los documentos

manejados en la entidad.

De la investigación se obtuvo como aporte teórico un mayor conocimiento de las tecnologías novedosas,

proporcionando una nueva arquitectura de desarrollo web a utilizar, así como la concepción sistémica de

los elementos del diseño. Como aporte práctico se tiene la automatización de la información referente de

los servicios que se prestan en el Ciroa, que permite a su vez tener un mayor control sobre los mismos y

rapidez en la búsqueda de información y generación de reportes.

Estructura de la tesis.

Este documento cuenta con Introducción, 3 capítulos, conclusiones, recomendaciones, bibliografías y

anexos:

Capítulo 1:

En este capítulo se abordan aspectos del marco teórico conceptual de investigación que explican

claramente el uso de las tecnologías actuales con las que se trabajarán, además de incluir las

herramientas que conforman el desarrollo de la aplicación, así como la metodología que se utilizará en el

proceso del desarrollo del software.

Capítulo 2:

En este capítulo se trabaja con la modelación del negocio mediante una investigación del proceso en

cuestión que se realiza en la entidad en la cual se está trabajando, se definen las reglas que rigen el

negocio, además se obtienen los actores y trabajadores del mismo. Se realiza además el levantamiento

de captura de requisitos tanto no funcionales como funcionales y se representa su interacción con los

actores del sistema mediante el modelo de casos de uso del sistema.

Introducción.

14

Capítulo 3:

En este capítulo se aborda el análisis y el diseño del sistema definiendo el modelo arquitectónico utilizado

de esta forma los diagramas de análisis y diseño. Además se propone el diseño físico de la base datos, el

diagrama de despliegue y el de componentes, así como la ingeniería web.

Capitulo 4:

En este capítulo se aborda la disciplina de implementación y prueba del sistema. En la implementación se

empieza con el resultado del diseño y se implementa el sistema en términos de componentes, es decir,

ficheros de código fuente, scripts, ejecutables y similares. Afortunadamente, la mayor parte de la

arquitectura del sistema es capturada durante el diseño, siendo el propósito principal de la implementación

desarrollar la arquitectura y el sistema como un todo. Durante la implementación se definieron los

diagramas de componentes de los casos de usos críticos. Durante la fase prueba se realizan las pruebas

a los casos de uso críticos.

Capítulo 1.Fundamenetación Teórica.

15

CAPÍTULO 1. FUNDAMENTACIÓN TEÓRICA.

Introducción.

Diseñar el ambiente y dimensionar los recursos computacionales que una organización necesita y su

crecimiento en el tiempo, es una tarea que puede ser realizada de muchas formas diferentes. Para un

mejor entendimiento del problema que existe se hizo varias entrevistas al personal especializado de dicha

organización, de manera que nos permitiera cumplir satisfactoriamente con este proyecto.

Este proyecto se desarrollo en el departamento de servicios del CIROA, el cual se encarga de atender a

todas las solicitudes de los clientes, siendo servicio de recreación, gastronomía o las dos. El proyecto

nació de una necesidad que tiene la organización de contar con la información adecuada para la toma de

decisiones en el momento preciso. Esta organización como muchas en el mundo se dio cuenta de que los

sistemas de gestión se han convertido en un recurso de vital importancia, ya que el uso de estos sistemas

informáticos garantiza procesar y obtener una mayor variedad de información, seguridad, satisfacción al

cliente y que pueda contar con información mas actualizada en poco tiempo.

En este capítulo se realiza una valoración y definición de los aspectos que serán abordados en la tesis

desde el punto de vista teórico conceptual relacionados con el sistema. Tiene el objetivo de describir y

caracterizar las diferentes tendencias y tecnologías actuales sobre las que se apoya la propuesta.

1.1 Fundamentos del diseño Teórico de Investigación. Conceptos generales.

1.1.1 ¿Qué es gestión?

Proceso mediante el cual se obtiene, despliega o utiliza una variedad de recursos básicos para apoyar los

objetivos de la organización. Es un proceso que desarrolla actividades productivas con el fin de generar

mayor rendimiento de los factores que en él intervienen. [1]

1.1.2 Funciones de gestión.

Planificar: proceso de establecer objetivos con el fin de alcanzar determinados objetivos.

(Establecimientos de objetivos, elaboración de planes, etc.)

Capítulo 1.Fundamenetación Teórica.

16

Organizar: proceso de dividir el trabajo y de coordinar el logro de resultados que tienen propósito

común.

Dirigir: proceso de conducir y coordinar esfuerzos laborales de las personas que integran una

organización. Función mediante el cual se ponen en marcha las tareas programadas.

Controlar: proceso de supervisar las actividades y resultados, comparándolos con los objetivos y

tomando las acciones correctivas, si son necesarias. [4]

1.1.3 ¿Qué es gestión de software?

Las aplicaciones o software de gestión son aquellas diseñadas para sustituir o mejorar las políticas,

procesos, uno o varios procedimientos, tanto comerciales como administrativos, que habitualmente realiza

una persona en una empresa o institución de forma presencial, por un software, que permita realizar al

cliente los mismos procedimientos de forma no presencial o disminuir el esfuerzo empleado para los

mismos. El proceso de la información comercial constituye la mayor de las áreas de aplicación del

software de gestión. Los sistemas discretos (por ejemplo: nóminas, cuentas de haberes-débitos,

inventarios, etc.), han evolucionado hacia el software de gestión (SIG) que accede a una o más base de

datos que contienen información comercial. Las aplicaciones en esta área reestructuran los datos

existentes para facilitar las operaciones comerciales o gestionar la toma de decisiones. Además de las

tareas convencionales de procesamiento de datos, las aplicaciones de software de gestión también

realizan cálculo interactivo. [6]

1.1.4 ¿Por qué el software es necesario?

Las empresas que operan en el siglo XXI se enfrentan a muchos retos, significativos, entre ellos:

Rentabilidad

Competitividad

Globalización

Velocidad de los cambios

Capacidad de adaptación

Capítulo 1.Fundamenetación Teórica.

17

Crecimiento

Tecnología

Equilibrar estos y otros requisitos empresariales puede constituir un proceso difícil y desalentador. Es aquí

donde entran en juego el software de gestión, al permitir aprovechar y desarrollar el potencial existente en

la organización.

La implementación de un software de gestión eficaz puede ayudar a:

Gestionar los riesgos sociales, medioambientales y financieros.

Mejorar la efectividad operativa.

Reducir costos.

Aumentar la satisfacción de clientes y partes interesadas.

Proteger la marca y la reputación.

Lograr mejoras continuas.

Potenciar la innovación.

Eliminar las barreras al comercio.

Aportar claridad al mercado.

1.1.5 ¿Qué es un Sistema Informático?

Un sistema informático, como todo sistema, es el conjunto de partes interrelacionadas, en este caso

hardware, software. Un sistema informático típico emplea una computadora que usa dispositivos

programables para capturar, almacenar y procesar datos. La computadora personal o PC, junto con la

persona que lo maneja y los periféricos que los envuelven, resultan de por sí un ejemplo de un sistema

informático. Incluso la computadora más sencilla se clasifica como un sistema informático, porque al

menos dos componentes (hardware y software) tienen que trabajar unidos. Pero el genuino significado de

"sistema informático" viene mediante la interconexión. Muchos sistemas informáticos pueden

interconectarse, esto es, unirse para convertirse un sistema mayor. La interconexión de sistemas

informáticos puede tornarse difícil debido a incompatibilidades. A veces estas dificultades ocurren a nivel

Capítulo 1.Fundamenetación Teórica.

18

de hardware, mientras que en otras ocasiones se dan entre programas informáticos que no son

compatibles entre sí. [5]

1.1.6 Ingeniería de software.

Ingeniería de software es la disciplina o área de la informática que ofrece métodos y técnicas para

desarrollar y mantener software de calidad. Esta ingeniería trata con áreas muy diversas de la informática

y de las Ciencias de la Computación, tales como construcción de compiladores, Sistemas Operativos, o

desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de

Sistema de Información y aplicables a infinidad de áreas (negocios, investigación científica, medicina,

producción, logística, banca, control de tráfico, meteorología, derecho, Internet, Intranet, etc.).

Una definición precisa aún no ha sido contemplada en los diccionarios, sin embargo se pueden citar las

enunciadas por algunos de los más prestigiosos autores:

Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de

programas de computadora y a la documentación asociada requerida para desarrollar, operar y

mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software.

Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de

obtener software de modo rentable, que sea fiable y trabaje en máquinas reales. [7]

1.1.7 Diseño Web.

El diseño Web es una actividad que consiste en la planificación, diseño e implementación de sitios Web y

páginas Web. No es simplemente una aplicación del diseño convencional sobre Internet ya que requiere

tener en cuenta cuestiones tales como navegabilidad, interactividad, usabilidad, arquitectura de la

información y la interacción de medios como el audio, texto, imagen y video. Se lo considera dentro del

Diseño Multimedia.

La unión de un buen diseño con una jerarquía bien elaborada de contenidos aumenta la eficiencia de la

web como canal de comunicación e intercambio de datos, que brinda posibilidades como el contacto

directo entre el productor y el consumidor de contenidos, característica destacable del medio Internet. El

Capítulo 1.Fundamenetación Teórica.

19

diseño web ha visto amplia aplicación en los sectores comerciales de Internet especialmente en la World

Wide Web. Asimismo, a menudo la web se utiliza como medio de expresión plástica en sí. Artistas y

creadores hacen de las páginas en Internet un medio más para ofrecer sus producciones y utilizarlas

como un canal más de difusión de su obra.

Ventajas del diseño Web con estándares:

Proporcionar sitios que sean accesibles a más gente y a más tipos de dispositivos Web

Simplificar el código y reducir el tamaño de los archivos.

Mejor indexación en los buscadores.

Reducción en el tiempo de desarrollo.

1.1.8 Arquitectura de sitios web.

Sitio Web

Componentes de su Arquitectura Básica:

o Servidor Web

o Conexión de Red

o Uno o más navegadores (browsers) clientes

La información que un sitio Web pone a disposición de los usuarios está en cierto formato y se almacena

en ficheros. Los clientes los solicitan por nombre y si es necesario proporcionan los platos específicos

junto con su petición. Estos ficheros son denominados „páginas Web‟ y representan el contenido de un

sitio Web. El servidor web distribuye las páginas con información formateada a los clientes que las

solicitan. La petición se realiza sobre una conexión de red y utiliza el protocolo HTTP.

El usuario interactúa con el sitio Web por medio de un browser, aplicación que se ejecuta en la máquina

cliente y que se conecta con un servidor a través de la red y le solicita páginas. Una vez que la solicitud de

página ha sido satisfecha, la conexión finaliza. El browser sabe cómo comunicarse con el servidor Web

(vía HTTP) y cómo mostrar la información devuelta por el servidor. Muchas páginas contienen

Capítulo 1.Fundamenetación Teórica.

20

hipervínculos (links) hacia otras (posiblemente ubicadas en otro servidor Web), que el browser puede

solicitar fácilmente. El usuario navega por el Web pinchando en los links y pidiendo páginas a los

servidores Web.

Figura 1-1: Arquitectura web.

1.1.9 Arquitectura de aplicaciones web.

Aplicación Web

Extiende un Sitio Web, permitiendo al usuario invocar la lógica del negocio

o modificar el estado del negocio en el servidor

Componentes básicos:

o Navegador del cliente (browser HTML/XML)

o Servidor Web (comunica con clientes vía HTTP)

o Servidor de Aplicaciones (maneja lógica del negocio)

o (Servidor de Bases de Datos)

Componentes avanzados

o Scripts, applets, controles, objetos distribuidos,...

Una aplicación Web es un sistema cliente/servidor con los componentes básicos que ahí aparecen. La

arquitectura de una aplicación Web es esencialmente la misma que la de un sitio Web, pero puede ser

mucho más compleja. [2]

Diferencia principal entre Sitio Web y Aplicación Web:

Capítulo 1.Fundamenetación Teórica.

21

La capacidad del usuario para (por medio de navegación o introducción de información (texto,

selecciones en checkbox, información en fichero)) afectar el estado de la lógica del negocio sobre

el servidor (más allá de los contadores de visitas o el „log‟ de uso del sitio).

Si no existe lógica de negocio en el servidor, el sistema NO es una aplicación Web. Ejemplo:

motores de búsqueda.

Aquellos sistemas donde el servidor Web (o el servidor de aplicaciones que utiliza un servidor Web

para la entrada de usuario) permite que la lógica del negocio se vea afectada a través de los

browsers, son considerados aplicaciones web. Ejemplo: reserva de vuelos.

¿Qué ventajas poseen las Aplicaciones Web?

Extrapolación y sindicación absoluta: El hecho de que todas las aplicaciones se realicen sobre Web, va a

permitir que entre ellas se pueda compartir toda la información.

Ubicuidad: La Web ya se ha consagrado como el canal de interoperabilidad por excelencia. Es decir, las

aplicaciones basadas en Web pueden desarrollarse en cualquier terminal (y no necesariamente en los

PC): ordenadores, móviles, PDAs, TV digital. Esto permite tener la información en todo momento y desde

cualquier terminal con conexión a Internet.

Seguridad: La capacidad de seguridad y de protección de datos de servidores de empresas profesionales

será siempre mucho mayor que la mantenida en servidores compartidos o en los mismos ordenadores de

gestión diaria. Pérdidas de datos por fallos del sistema, virus, ataques, son constantes en los ordenadores

personales sin que se mantengan copias de seguridad adecuadas y siendo el coste de restauración muy

elevado para estas empresas.

1.1.10 Arquitectura cliente-servidor

Esta arquitectura consiste básicamente en un programa cliente que realiza peticiones a otro programa -el

servidor- que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una

sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a través de una red

de computadoras. En esta arquitectura la capacidad de proceso está repartida entre los clientes y los

Capítulo 1.Fundamenetación Teórica.

22

servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la

gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del

sistema.

La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta

necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de

servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras

que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma. Una

disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes

programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de

distribución del sistema. La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no

hay distribución, tanto a nivel físico como a nivel lógico.

1.2 Fundamentos del diseño Tecnológico de la Investigación. Tendencias, Herramientas y

Tecnología a utilizar.

1.2.1 Aplicaciones Ricas de Internet (RIA).

Son un nuevo tipo de aplicaciones con más ventajas que las tradicionales aplicaciones Web. Esta surge

como una combinación de las ventajas que ofrecen las aplicaciones Web y las aplicaciones tradicionales.

Normalmente en las aplicaciones Web, hay una recarga continua de páginas cada vez que el usuario

pulsa sobre un enlace. De esta forma se produce un tráfico muy alto entre el cliente y el servidor, llegando

muchas veces, a recargar la misma página con un mínimo cambio. Otra de las desventajas de las

tradicionales aplicaciones Web es la poca capacidad multimedia que poseen. Por ejemplo: para ver un

vídeo es necesario usar un programa externo para su reproducción. [11]

En los entornos RIA, en cambio, no se producen recargas de página, ya que desde el principio se carga

toda la aplicación, y sólo se produce comunicación con el servidor cuando se necesitan datos externos

como datos de una Base de Datos o de otros ficheros externos. Las capacidades multimedia son totales

gracias a que estos entornos tienen reproductores internos y no hace falta ningún reproductor del sistema

operativo del usuario.

Capítulo 1.Fundamenetación Teórica.

23

Hay muchas herramientas para la creación de entornos RIA. Entre estas se puede mencionar las

plataformas Adobe Flash, Adobe Flex y Adobe AIR de Adobe, uniPaaS de Magic Software, AJAX,

OpenLaszlo, Silverlight de Microsoft, JavaFX Script de Sun Microsystems, Bindows de MB Technologies y

Java script.

1.2.2 Adobe Flex Builder.

Adobe Flex es el término con el que se denomina a la tecnología que da soporte al desarrollo de las

aplicaciones RIA, Rich Internet Applications (Aplicaciones Ricas de Internet).

Flex agrupa una serie de tecnologías publicadas desde Marzo de 2004 por Macromedia para dar soporte

al despliegue y desarrollo de Aplicaciones Enriquecidas de Internet, basadas en su plataforma propietaria

Flash. Además posee como principal objetivo permitir a los desarrolladores de aplicaciones Web construir

rápida y fácilmente Aplicaciones Ricas de Internet posibilitando que el cliente solo cargue la aplicación una

vez, mejorando así el flujo de datos frente a aplicaciones basadas en HTML (eg.PHP, ASP, JSP, CFMX),

las cuales requieren de ejecutar plantillas en el servidor para cada acción.

Otros de los criterios que se tuvo en cuenta para optar por esta tecnología es que Flex es un marco de

trabajo gratuito de código abierto para crear aplicaciones web expresivas y muy interactivas que se

implantan coherentemente en los principales exploradores, equipos de sobremesa y sistemas operativos,

ofrece un lenguaje basado en estándares moderno y un modelo de programación que admite los patrones

de diseño habituales. MXML, un lenguaje declarativo basado en XML, se utiliza para describir el aspecto y

comportamiento de la interfaz de usuario, y ActionScript 3, un potente lenguaje de programación orientado

a objetos, se utiliza para crear la lógica de clientes. Asimismo, Flex incorpora una biblioteca de

componentes muy completa con más de 100 componentes de interfaz de usuario extensibles y de eficacia

demostrada para crear RIA, así como un depurador interactivo de aplicaciones de Flex.

Las aplicaciones de Internet sofisticadas creadas con Flex pueden ejecutarse en el explorador utilizando el

omnipresente software Adobe Flash Player o en el escritorio utilizando Adobe AIR. Esto permite que las

aplicaciones de Flex se ejecuten de un modo coherente en todos los exploradores importantes y en

múltiples sistemas operativos del escritorio. Y mediante Adobe AIR, el tiempo de ejecución en múltiples

Capítulo 1.Fundamenetación Teórica.

24

sistemas operativos, ahora las aplicaciones de Flex pueden acceder a los datos locales y a los recursos

de sistema del escritorio.

Adobe Flex Builder 3 acelera el desarrollo de aplicaciones de Flex. Es una herramienta de desarrollo

basada en Eclipse que incorpora las siguientes funciones: códigos inteligentes, depuración interactiva

estratificada, además del diseño visual del aspecto y comportamiento de la interfaz de usuario de las

aplicaciones de Internet sofisticadas. Flex Builder 3 incluye el marco de trabajo completo de Flex, incluidos

los compiladores, la biblioteca de componentes y los depuradores. [12]

1.2.3 Lenguaje de Programación a utilizar.

Los lenguajes de programación son técnicas estándar de comunicación que permiten expresar

instrucciones que han de ser ejecutadas en una computadora. Consisten en un conjunto de reglas

sintácticas y semánticas que definen un programa informático.

En la actualidad los lenguajes de programación para la Web se clasifican en dos grupos teniendo en

cuenta donde se implementan respecto a la arquitectura Cliente/Servidor, nombrándose lenguajes del lado

del cliente y lenguajes del lado del servidor.

1.2.3.1 ActionScript.

ActionScript es un lenguaje de programación orientado a objetos (OOP), utilizado en especial en

aplicaciones web animadas realizadas en el entorno Adobe Flash, la tecnología de Adobe para añadir

dinamismo al panorama web. Fue lanzado con la versión 4 de Flash, y desde entonces hasta ahora, ha

ido ampliándose poco a poco, hasta llegar a niveles de dinamismo y versatilidad muy altos en la versión

10 (Adobe Flash CS4) de Flash.

ActionScript es un lenguaje de script, esto es, no requiere la creación de un programa completo para que

la aplicación alcance los objetivos. El lenguaje está basado en especificaciones de estándar de industria

ECMA-262, un estándar para Java script, de ahí que ActionScript se parezca tanto a Java script.

Capítulo 1.Fundamenetación Teórica.

25

La versión más extendida actualmente es ActionScript 3.0, que significó una mejora en el manejo de

programación orientada a objetos al ajustarse mejor al estándar ECMA-262 y es utilizada en las últimas

versiones de Adobe Flash y Flex y en anteriores versiones de Flex.(..).

Ventajas de ActionScript.

ActionScript aumenta las posibilidades de creación de scripts de las versiones anteriores de

ActionScript.

Se ha diseñado para facilitar la creación de aplicaciones muy complejas con conjuntos de

datos voluminosos y bases de código reutilizables y orientadas a objetos.

Aunque no se requiere para el contenido que se ejecuta en Adobe Flash Player 9,

ActionScript 3.0 permite introducir unas mejoras de rendimiento que sólo están disponibles

con AVM2, la nueva máquina virtual. [1]

1.2.3.2 MXML.

MXML es un lenguaje descriptivo desarrollado inicialmente por Macromedia hasta el 2005 para la

plataforma FLEX de Adobe. MXML se basa en XML y su acrónimo "Multimedia eXtensible Markup

Language “lenguaje que describe interfaces de usuario, crea modelos de datos y tiene acceso a los

recursos del servidor, del tipo RIA (Rich Internet Application).

MXML tiene una mayor estructura en base a etiquetas, similar a HTML, pero con una sintaxis menos

ambigua, proporciona una gran variedad e inclusive permite extender etiquetas y crear sus propios

componentes. [8]

1.2.3.3 PHP (Hypertext Pre-processor).

Se utilizó como lenguaje de programación del lado del servidor PHP, aunque existen en este grupo otros

como: PERL, ASP, JSP, PHP Estos lenguajes permiten desarrollar lógica del negocio dentro del servidor,

y posibilitan el acceso a las bases de datos y el procesamiento de la información.

Capítulo 1.Fundamenetación Teórica.

26

PHP: El lenguaje php tiene gran popularidad a la hora de desarrollar aplicaciones de gestión, respecto a

los demás lenguajes del lado del servidor, por sus características y su facilidad de aprendizaje. Es un

lenguaje interpretado de alto nivel embebido en páginas HTML y ejecutado en el servidor. Es un lenguaje

de programación (originario del nombre PHP Tools, o Personal Home Page Tools) que sirve

principalmente para proporcionar características dinámicas a una página Web. PHP se interpreta y ejecuta

directamente en el servidor en el que está albergada la página Web, con lo que el visitante a la misma

únicamente recibe el resultado buscado por el código en el que está escrito. [9]

Características: Velocidad, estabilidad, seguridad y simplicidad.

Velocidad: No solo la velocidad de ejecución, la cual es importante, sino además no crea demoras

en la máquina. Por esta razón no debe requerir demasiados recursos de sistema.

Estabilidad: La velocidad no sirve de mucho si el sistema se cae cada cierta cantidad de

ejecuciones. Ninguna aplicación es 100% libre de bugs1, pero teniendo de respaldo una increíble

comunidad de programadores y usuarios es mucho más difícil para estos sobrevivir. PHP utiliza

su propio sistema de administración de recursos y dispone de un sofisticado método de manejo

de variables, conformando un sistema robusto y estable.

Seguridad: El sistema debe poseer protecciones contra ataques. PHP provee diferentes niveles de

seguridad, estos pueden ser configurados desde el archivo .ini.

Simplicidad: Se les debe permitir a los programadores generar código productivamente en el

menor tiempo posible. Usuarios con experiencia en C y C++ podrán utilizar PHP rápidamente.

¿Por qué usar PHP?

Es un lenguaje multiplataforma.

Completamente orientado a la web.

Capacidad de conexión con la mayoría de los motores de base de datos que se utilizan en la

actualidad, destaca su conectividad con MySQL y PostgreSQL.

Capítulo 1.Fundamenetación Teórica.

27

Capacidad de expandir su potencial utilizando la enorme cantidad de módulos (llamados ext's o

extensiones).

Posee una amplia documentación en su página oficial, entre la cual se destaca que todas las

funciones del sistema están explicadas y ejemplificadas en un único archivo de ayuda.

Es libre, por lo que se presenta como una alternativa de fácil acceso para todos.

Permite aplicar técnicas de programación orientada a objetos.

Biblioteca nativa de funciones sumamente amplia e incluida.

No requiere definición de tipos de variables aunque sus variables se pueden evaluar también por el

tipo que estén manejando en tiempo de ejecución.

Tiene manejo de excepciones (desde PHP5).

Si bien PHP no obliga a quien lo usa a seguir una determinada metodología a la hora de programar

(muchos otros lenguajes tampoco lo hacen), aun estando dirigido a alguna en particular, el programador

puede aplicar en su trabajo cualquier técnica de programación y/o desarrollo que le permita escribir código

ordenado, estructurado y manejable.

Comparando PHP con Java es evidente que no se pude negar que Java es un lenguaje muy potente y es

compilado más eficiente que cualquier lenguaje interpretado, como PHP. Aun así Java como lenguaje de

programación, al contrario que PHP no puede ser tratado de una manera tan a la ligera y superficial, ya

que si estamos hablando del desarrollo web, debemos centrarnos en un sector de todo el mundo que

rodea a Java, concretamente en el de JSP, Servlets y demás.

Java es totalmente modular, pero al tratarse de un análisis entre dos tecnologías de desarrollo web,

consideramos el término modularización como la separación en capas definidas en un modelo

arquitectónico, MVC (Modelo Vista-Controlador). La modularidad de un sistema tiene vital importancia en

el aspecto de la consistencia, robustez, mantenibilidad y demás aspectos necesarios para el análisis. La

tecnología Java usada en cualquier portal web posee una estructura claramente diferenciada, pudiendo

diferenciar con facilidad el modelo MVC con sus diferentes módulos. En cuanto a PHP, podemos decir que

Capítulo 1.Fundamenetación Teórica.

28

se pierde un tanto la pista de la modularidad pero se ha intentado solucionar esto con los frameworks

MVC para PHP5 como Symfony o Zend Framework y la existencia de los “módulos” ya desarrollados y

libre distribución que facilitarán la tarea de los programadores. Siendo esto vital para el trabajo a

desarrollar, ya que uno de los estilos arquitectónicos que se va utilizar es de Llamadas y Retornos,

específicamente de tres capas.

Además es conveniente mencionar que cuando se realiza el diseño de un proyecto y se elige una

tecnología a usar, durante la etapa de desarrollo se debe orientar el proceso al pensamiento de que una

vez implementado y puesto en funcionamiento, serán necesarias nuevas mejoras, que no deben suponer

un coste demasiado elevado ni que mucho menos produzca un empobrecimiento del sistema actual. La

experiencia ha demostrado que una vez finalizado el desarrollo, puede ocurrir que las mejoras del sistema

no sean implementadas por su programador original y sí por otra persona o empresa externa, como Java

es mas difícil por el tiempo que consume en su estudio y entendimiento, PHP es una técnica poco

estructurada, y esto no quiere decir que pueda dar origen a un empobrecimiento del código,

repercutiendo normalmente a su rendimiento; pues esto depende del alcance y complejidad del proyecto y

la existencia de profesionales con altos conocimientos de análisis que sepan usar PHP siempre y cuando

lo hagan orientado a objetos.

Otra de las ventajas de PHP frente a Java sea en cuestión de rendimiento ya que el primero es mucho

menos pesado, lo que produce una sensación al usuario de rapidez y mayor usabilidad. Java es ejecutado

en cliente mientras que PHP es ejecutado en Servidor, lo que libera de tareas al cliente y suele mejorar su

rendimiento.

1.2.4 Eclipse.

Eclipse es un entorno de desarrollo integrado de código abierto multiplataforma para desarrollar lo que el

proyecto llama "Aplicaciones de Cliente Enriquecido", opuesto a las aplicaciones "Cliente-liviano" basadas

en navegadores. Esta plataforma, típicamente ha sido usada para desarrollar entornos de desarrollo

integrados (del inglés IDE), como el IDE de Java llamado Java Development Toolkit (JDT) y el compilador

(ECJ) que se entrega como parte de Eclipse (y que son usados también para desarrollar el mismo

Eclipse). Sin embargo, también se puede usar para otros tipos de aplicaciones cliente, como BitTorrent

Azureus. [10]

Capítulo 1.Fundamenetación Teórica.

29

Eclipse es también una comunidad de usuarios, extendiendo constantemente las áreas de aplicación

cubiertas. Un ejemplo es el recientemente creado Eclipse Modeling Project, cubriendo casi todas las áreas

de Model Driven Engineering. Eclipse fue desarrollado originalmente por IBM como el sucesor de su

familia de herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundación Eclipse, una

organización independiente sin ánimo de lucro que fomenta una comunidad de código abierto y un

conjunto de productos complementarios, capacidades y servicios.

El entorno de desarrollo integrado (IDE) de Eclipse emplea módulos (en inglés plug-in) para proporcionar

toda su funcionalidad al frente de la plataforma de cliente rico, a diferencia de otros entornos monolíticos

donde las funcionalidades están todas incluidas, las necesite el usuario o no. Este mecanismo de módulos

es una plataforma ligera para componentes de software.

Adicionalmente a permitirle a Eclipse extenderse usando otros lenguajes de programación como son

C/C++ y Python, permite a Eclipse trabajar con lenguajes para procesado de texto como LaTeX,

aplicaciones en red como Telnet y Sistema de gestión de base de datos. La arquitectura plugin permite

escribir cualquier extensión deseada en el ambiente, como sería Gestión de la configuración. Se provee

soporte para Java y CVS en el SDK de Eclipse. Y no tiene por qué ser usado únicamente para soportar

otros lenguajes de programación. La versión de Eclipse utiliza para la realización de presente trabajo fue

Ganymede que es la versión consecutiva a Europa.

1.2.5 Sistema de Gestión de Base de Datos (SGBD).

La manipulación de la información como elemento primario de muchos procesos que a diario se llevan a

cabo, es una de las áreas de la informática que se ha explotado desde el mismo surgimiento de ésta como

ciencia aplicada. El hecho de que una información persista en un entorno de almacenamiento para poder

ser consultada y modificada según se necesite, es un elemento a tener en cuenta en infinidad de procesos

y procedimientos que continuamente se desarrollan. [3]

Los sistemas de gestión de bases de datos son un tipo de software muy específico, dedicado a servir de

interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. Son sistemas formados por un

conjunto de datos y un paquete de software para la gestión del mismo, de modo que se controla el

almacenamiento de datos redundantes, los datos resultan independientes de los programas que los usan,

Capítulo 1.Fundamenetación Teórica.

30

se almacenan las relaciones entre los datos juntos con éstos y se puede acceder a los datos de diversas

formas. Para la construcción de aplicaciones de gestión se destacan por su eficiencia gestores como:

Oracle, que es considerado uno de los más potentes, MySQL, SQL Server y PostgreSQL , que es

considerado el Sistema de Gestión de Bases de Datos de código abierto (gratuito y con código fuente

disponible) más avanzado del mundo. PostgreSQL posee las características de los más potentes sistemas

comerciales como Oracle o SQLServer:

Completo soporte para transacciones.

Soporte para construcciones SQL del tipo subselect3.

Orientación a objetos con herencia de tablas.

Herramientas gráficas de diseño y administración de bases de datos.

Los SGBD Proveen facilidades para la manipulación de grandes volúmenes de datos. Simplifican la

programación de chequeos de consistencia manejando las políticas de respaldo adecuadas, garantizan

que los cambios de la base serán siempre consistentes sin importar si hay errores en el disco, o hay

muchos usuarios accediendo simultáneamente a los mismos datos, o se ejecutaron programas que no

terminaron su trabajo correctamente, etc. Permiten realizar modificaciones en la organización de los datos

con un impacto mínimo en el código de los programas y permiten implementar un manejo centralizado de

la seguridad de la información (acceso a usuarios autorizados), protección de información, de

modificaciones, inclusiones.

Sistemas de Gestión de Base de Datos libres.

PostgreSQL

MySql

Firebird

SQLite

Sistemas de Gestión de Base de Datos no libres.

Oracle

Capítulo 1.Fundamenetación Teórica.

31

Open Access

Microsoft Access

Microsoft SQL Server

NexusDB

Sistemas de Gestión de Base de Datos más utilizados.

Microsoft SQL Server

Oracle

MySQL

Microsoft SQL Server: Es un sistema de gestión de bases de datos relacionales (SGBD) basado en el

lenguaje Transact-SQL, y específicamente en Sybase IQ, capaz de poner a disposición de muchos

usuarios grandes cantidades de datos de manera simultánea. Soporta procedimientos almacenados,

Incluye también un potente entorno gráfico de administración, que permite el uso de comandos DDL y

DML gráficamente, permite trabajar en modo cliente-servidor, donde la información y datos se alojan en el

servidor y las terminales o clientes de la red sólo acceden a la información. Además permite administrar

información de otros servidores de datos.

Oracle: Es un sistema de gestión de base de datos relacional Se considera a Oracle como uno de los

sistemas de bases de datos más completos, destacando soporte de transacciones estabilidad,

escalabilidad y soporte multiplataforma.

MySQL: Es un sistema de gestión de base de datos relacional, multihilo y multiusuario con más de seis

millones de instalaciones. MySQL es muy utilizado en aplicaciones web, como Drupal o phpBB, en

plataformas (Linux/Windows-Apache-MySQL-PHP/Perl/Python), y por herramientas de seguimiento de

errores como Bugzilla. Su popularidad como aplicación web está muy ligada a PHP, que a menudo

aparece en combinación con MySQL. MySQL es una base de datos muy rápida en la lectura cuando

utiliza el motor no transaccional MyISAM. En aplicaciones web hay baja concurrencia en la modificación

de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este

Capítulo 1.Fundamenetación Teórica.

32

tipo de aplicaciones. Maneja su propia seguridad, tiene su propia base de datos de usuarios que chequea

la conexión de un identificador válido, usa el puerto 3306 por defecto, inaccesible para intrusos, siempre y

cuando esté bloqueado, incluye todos los elementos necesarios para preparar diferentes niveles de

acceso a usuarios y proteger los datos, mediante un sistema de permisos elegante y potente.

Motor de Base de Datos MySql (Relacional).

Para la realización del presente trabajo se decidió tomar a MySql como Motor de Base de Datos por

diversas razones donde su utilidad se traduce en ventajas, entre las que se pueden mencionar las

siguientes:

Acceso a las bases de datos de forma simultánea por varios usuarios y/o aplicaciones.

Seguridad: En forma de permisos y privilegios, determinados usuarios tendrán permiso para

consulta o modificación de determinadas tablas. Esto permite compartir datos sin que

peligre la integridad de la base de datos o protegiendo determinados contenidos.

Potencia: SQL es un lenguaje muy potente para consulta de base de datos, usar un motor

nos ahorra una enorme cantidad de trabajo.

Portabilidad: SQL es también un lenguaje estandarizado, de modo que las consultas hechas

usando SQL son fácilmente portables a otros sistemas y plataformas.

MySQL está escrito en C y C++ y probado con multitud de compiladores y dispone de APIs para

muchas plataformas diferentes.

Conectividad: permite conexiones entre diferentes máquinas con distintos sistemas operativos. Es

corriente que servidores Linux o Windows, usando MySQL, sirvan datos para ordenadores con

Windows, Linux, Solaris, etc. Para ello se usa TCP/IP, tuberías, o sockets Unix.

Es multihilo, con lo que puede beneficiarse de sistemas multiprocesador.

Capítulo 1.Fundamenetación Teórica.

33

1.3 Metodologías de desarrollo del software y herramientas CASES.

1.3.1 Metodologías agiles y pesadas.

El Proceso Unificado Racional (RUP): Es un proceso de desarrollo de software y junto con el Lenguaje

Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis,

implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos

firmemente establecidos, sino una metodología adaptable al contexto y necesidades de cada

organización. [10]

El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los

elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. RUP

divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable

según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del

problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al

establecimiento de una línea base de la arquitectura. Durante la fase de inicio las iteraciones hacen mayor

énfasis en actividades de modelado del negocio y de requerimientos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la linea base de la arquitectura,

abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis, diseño y

una parte de implementación orientado a la línea base de la arquitectura. En la fase de construcción, se

lleva a cabo la construcción del producto por medio de una serie de iteraciones.

Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su

implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas

iteraciones hasta que se termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la

comunidad de usuarios. Como se puede observar en cada fase participan todas las disciplinas, pero que

Capítulo 1.Fundamenetación Teórica.

34

dependiendo de la fase el esfuerzo dedicado a una disciplina varía, sus tres características fundamentales

son.

1. Dirigido por los casos de uso:

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para

definir los contenidos de las iteraciones. La idea es que cada iteración coja un conjunto de casos de

uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño,

implementación, prueba, etc.

2. Centrado en la arquitectura:

El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del

sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura software de

un sistema. La analogía con la construcción es clara, cuando construyes un edificio existen diversos

planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc.

3. Iterativo e incremental:

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número

variable según el proyecto y las cuales se definen según el nivel de madurez que alcanzan los

productos que se van obteniendo con cada actividad ejecutada. La terminación de cada fase ocurre

en el hito correspondiente a cada una, donde se evalúa que se hayan cumplido los objetivos de la

fase en cuestión.

Aun así, aunque RUP certifica a gran medida los software en cuanto a calidad ya que impone un proceso

disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente, existe como

gran desventaja que es un proceso muy detallado con un fuerte énfasis en planificar inspirado por otras

disciplinas de la ingeniería y genera a la vez un exceso de documentación de esta manera en reacción a

la burocracia que impone el RUP existen otros tipos de metodologías que ayudan al proceso de

desarrollo, el término ágil aplicado a las metodologías en el desarrollo de software nace en febrero de

Capítulo 1.Fundamenetación Teórica.

35

2001, con el objetivo de esbozar los valores y principios que deberían permitir a los equipos desarrollar

software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto.

Las metodologías ágiles ofrecen una solución para gran cantidad de proyectos pequeños. Una de las

cualidades más destacables en una metodología ágil es su sencillez, tanto en su aprendizaje como en su

aplicación, reduciéndose así los costos de implantación en un equipo de desarrollo.

En este grupo se encuentra una de las más exitosas (XP), es una de las metodologías de desarrollo de

software más usada en la actualidad para proyectos de corto plazo y equipos pequeños. La metodología

consiste en una programación rápida o extrema, cuya particularidad es tener como parte del equipo, al

usuario final, pues es uno de los requisitos para llegar al éxito del proyecto, se fundamenta en pruebas

unitarias para obtener los posibles errores, refabricación es decir, reutilización de código, para lo cual se

crean patrones o modelos estándares, siendo más flexible al cambio y la programación en pares.

Otra es RUP Ultra Light, como versión simplificada de RUP que describe fácilmente el aseguramiento del

negocio de aplicaciones de software usando técnicas y conceptos ágiles. Divide el proceso de desarrollo

en 10 pasos fundamentales inmersos en cuatro fases de desarrollo al igual que RUP: Inicio, Elaboración,

Construcción y Transición.

Para desarrollar la MDS RUP Ultra Light se deben seguir los siguientes pasos:

1. Realizar un Diagrama de Casos de Uso: Una vez identificadas todas las funcionalidades del

software a construir, se debe representar todos estos casos de uso en un diagrama teniendo en

cuenta además, a los actores involucrados y las relaciones existentes entre ellos (actor-caso de

uso, actor- actor, caso de uso- caso de uso).

2. Priorizar los Casos de Uso a trabajar: Luego de identificar los casos de uso del sistema, se debe

hacer una lista de prioridad de casos de uso, donde la prioridad es el riesgo que conllevan. Los

riesgos es todo lo que puede afectar el buen desarrollo del sistema como puede ser: necesidad de

cambiar la arquitectura, no escoger los requisitos adecuados, no construir un sistema correcto, etc.

Se debe determinar cuáles son los requerimientos más importantes a desarrollar en las primeras

iteraciones y cuáles deben dejarse para más tarde.

Capítulo 1.Fundamenetación Teórica.

36

3. Generar los Documentos de Caso de Uso: Para un mejor entendimiento de la funcionalidad

asociada a cada caso de uso se necesita un documento que describa de forma breve o extendida

lo que hace el caso de uso, más allá de la representación gráfica de su Diagrama de Casos de

Uso.

El documento de Caso de Uso debe ser generado por el Analista del proyecto y debe tener de una

forma u otra la siguiente estructura:

“Descripción Breve. De lo que hace el Caso de Uso.

Precondiciones. Condiciones que deben ser cumplidas antes de ejecutar el Caso de Uso.

Flujo Básico. Descripción paso a paso de las acciones a realizar por el Usuario cuando

trabaja de forma correcta en este Caso de Uso.

Flujo Alternativo. Detalle de los pasos que seguirá el usuario cuando no trabaje de forma

correcta en este requerimiento, ejemplo: validaciones, etc.

Postcondiciones. Las acciones que se deben realizar después de que se ha terminado de

ejecutar el Caso de Uso.

Interfaz Gráfica. Prototipo de cómo debe quedar la pantalla del caso de uso para ser vista

por los usuarios”.

4. Generar los Diagramas de Secuencia: Un diagrama de secuencia permite conocer la forma en la

que los objetos se comunicarán en una pantalla para cumplir su objetivo a través de la ordenación

temporal de mensajes durante su ciclo de vida. No es indispensable hacer este gráfico pero

ayudará a que el Arquitecto de Software comprenda mejor lo que debe hacer, y los

Implementadores podrán hacer mejor su trabajo.

5. Diseñar el Framework del proyecto: El Arquitecto de Software del proyecto diseñará las clases que

serán usadas en todo el Software. Es un trabajo bastante delicado ya que el mal diseño de las

clases involucra que no sean implementadas las funcionalidades de cada clase de forma correcta,

Capítulo 1.Fundamenetación Teórica.

37

lo cual conllevará a escribir un “Spaghetti Code”, que significa que el código estará difuso. Esta

etapa de diseño debe ser revisada cuidadosamente y se recomienda la utilización de Patrones de

Diseño de Software de ser posible.

6. Creación de la Base de Datos: El diagrama de clases del diseño desarrollado constituye el punto

de partida para el diseño de la Base de Datos del proyecto pues se puede utilizar la Capa de Datos

del mismo, donde se alojan las clases Entidad.

7. Construir la máscara la WebSite o Aplicación Windows: Simultáneamente al desarrollo de los

pasos 4, 5 y 6 se pueden ir realizando las plantillas para la creación de las páginas web

ayudándose de los gráficos de las GUI (Graphic User Interface o Interfaz Gráfica de Usuario) que

se encuentran en los Documentos de Casos de Uso.

8. Programar las funcionalidades de los Casos de Uso: Una vez terminadas las clases, se comienzan

a programar las funcionalidades de los Casos de Uso. Para ello, los programadores se apoyan en

los documentos de CU desarrollados por los analistas y basándose en el Diagrama de Secuencia y

en las clases diseñadas por el Arquitecto escriben el código que se necesita para que el caso de

uso funcione.

9. Probar los Requerimientos del Software: Independientemente que en el Documento de Casos de

Uso se describa detalladamente cómo debe funcionar el requerimiento y que se hayan realizado

los diagramas, siempre se escapan algunos detalles que se deben corregir en una etapa de

pruebas exhaustivas, que no deben ser hechas por las mismas personas que programaron los CU.

10. Integrar los requerimientos concluidos: Al finalizar es indispensable unir lo que se ha realizado por

diferentes programadores de forma tal que el sistema funcione como un todo y ponerlo a

disposición de los usuarios.

Se selecciona como Metodología de Desarrollo a utilizar RUP Ultra Light, pues siendo una versión

simplificada de RUP ofrece las facilidades y ventajas de esta potente metodología, de forma ágil, o sea

adaptada al contexto de la aplicación a realizar (software pequeño, y poco complejo en un período de

desarrollo corto). Además las bases de la metodología se adaptan a las condiciones de trabajo existentes

Capítulo 1.Fundamenetación Teórica.

38

para el apoyo al desarrollo del software y agiliza la interpretación de los procesos en versiones

simplificadas. En este caso particular el equipo de desarrollo se compone solo de una persona, que debe

desempeñar todos los roles de la Ingeniería de Software necesarios para el desarrollo de la solución y

además se dispone de un período corto de tiempo. Razones por las cuales se necesita reducir el proceso

de desarrollo de la herramienta en cuestión con la utilización de la antes mencionada metodología de

desarrollo.

1.3.2 El Lenguaje Unificado de Modelación UML

Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el

lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado

por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y

documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo),

incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos

concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes

reutilizables.

Es importante resaltar que UML es un "lenguaje" para especificar y no para describir métodos o procesos.

Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir.

En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en el desarrollo de

software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de

software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué

metodología o proceso usar.

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de

Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento.

Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos,

sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no

por eso se toma UML sólo para lenguajes orientados a objetos.

Capítulo 1.Fundamenetación Teórica.

39

1.3.3 Herramienta CASE. Rational Rose.

Las herramientas CASE son un conjunto de métodos, utilidades y técnicas que dan asistencia a los

analistas, ingenieros de software y desarrolladores, durante todos los pasos del ciclo de vida de desarrollo

de un software y facilitan el mejoramiento del ciclo de vida del desarrollo de sistemas de información,

completamente o en alguna de sus fases. CASE es una sigla, que corresponde a las iniciales de:

Computer Aided Software Engineering; y en su traducción al Español significa Ingeniería de Software

Asistida por Computación. Estas herramientas nos pueden ayudar en tareas como el proceso de realizar

un diseño del proyecto, calculo 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.

Para el modelado visual se utilizará Rational Rose siendo una herramienta de gran fortaleza en el diseño,

despliegue, construcción, pruebas y administración de proyectos en el proceso desarrollo de software.

Esta herramienta de diseño de software es el producto más completo de la familia Rational Rose. Perfecto

para el modelado UML, permite “trabajar en diseños de base de datos con capacidad de representar la

integración de los datos y los requerimientos de aplicación a través de diseños lógicos y físicos”.

Rational Rose tiene capacidad para proporcionar el desarrollo iterativo y de ingeniería. Permite a los

diseñadores aprovechar las ventajas de desarrollo iterativo (a veces llamado desarrollo evolutivo), ya que

la nueva aplicación se puede crear en etapas, la salida de una iteración se convierte en la entrada a la

siguiente iteración, garantizando que el producto final cumpla con las funcionalidades y la calidad

esperada.

Existen otras como Visual Paradigm para UML es una de las herramientas UML CASE del mercado,

considerada como muy completa y fácil de usar, con soporte multiplataforma y que proporciona buena

facilidades de interoperabilidad con otras aplicaciones. Fue creada para el ciclo vital completo del

desarrollo del software que lo automatiza y acelera, permitiendo la captura de requisitos, análisis, diseño e

implementación.

Capítulo 1.Fundamenetación Teórica.

40

1.4 Patrón de arquitectura Tres Capas.

La programación por capas es un estilo de programación en el que el objetivo primordial es la

separación de la lógica de negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar

la capa de datos de la capa de presentación al usuario.

La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso

de que sobrevenga algún cambio, sólo se ataca al nivel requerido sin tener que revisar entre código

mezclado.

Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este modo, cada grupo

de trabajo está totalmente abstraído del resto de niveles, de forma que basta con conocer la API que

existe entre niveles.

En el diseño de sistemas informáticos actual se suele usar las arquitecturas multinivel o Programación

por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo que permite el diseño

de arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades

aumenten).

Capítulo 1.Fundamenetación Teórica.

41

El diseño más utilizado actualmente es el diseño en tres niveles (o en tres capas).

Capas y niveles

1.- Capa de presentación: es la que ve el usuario (también se la denomina "capa de usuario"), presenta

el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de

proceso (realiza un filtrado previo para comprobar que no hay errores de formato). Esta capa se

comunica únicamente con la capa de negocio. También es conocida como interfaz gráfica y debe tener

la característica de ser "amigable" (entendible y fácil de usar) para el usuario.

2.- 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 (e 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 solicitar al gestor de base de datos para almacenar o recuperar datos de él.

También se consideran aquí los programas de aplicación.

3.- Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Está

formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos,

reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.

Todas estas capas pueden residir en un único ordenador, si bien lo más usual es que haya una multitud

de ordenadores en donde reside la capa de presentación (son los clientes de la arquitectura

cliente/servidor). Las capas de negocio y de datos pueden residir en el mismo ordenador, y si el

crecimiento de las necesidades lo aconseja se pueden separar en dos o más ordenadores. Así, si el

tamaño o complejidad de la base de datos aumenta, se puede separar en varios ordenadores los cuales

recibirán las peticiones del ordenador en que resida la capa de negocio.

Si, por el contrario, fuese la complejidad en la capa de negocio lo que obligase a la separación, esta

capa de negocio podría residir en uno o más ordenadores que realizarían solicitudes a una única base

de datos. En sistemas muy complejos se llega a tener una serie de ordenadores sobre los cuales corre la

capa de datos, y otra serie de ordenadores sobre los cuales corre la base de datos.

Capítulo 1.Fundamenetación Teórica.

42

En una arquitectura de tres niveles, los términos "capas" y "niveles" no significan lo mismo ni son

similares.

El término "capa" hace referencia a la forma como una solución es segmentada desde el punto de vista

lógico:

Presentación/ Lógica de Negocio/ Datos.

En cambio, el término "nivel" corresponde a la forma en que las capas lógicas se encuentran distribuidas

de forma física. Por ejemplo:

Una solución de tres capas (presentación, lógica del negocio, datos) que residen en un solo

ordenador (Presentación+lógica+datos). Se dice que la arquitectura de la solución es de tres

capas y un nivel.

Una solución de tres capas (presentación, lógica del negocio, datos) que residen en dos

ordenadores (presentación+lógica, lógica+datos). Se dice que la arquitectura de la solución es

de tres capas y dos niveles.

Una solución de tres capas (presentación, lógica del negocio, datos) que residen en tres

ordenadores (presentación, lógica, datos). La arquitectura que la define es: solución de tres

capas y tres niveles

Se podrá con este estilo arquitectónico de tres capas facilitar el mantenimiento al tener separados los

componentes del sistema y el origen de los datos es independiente, mientras que con una arquitectura de

dos capas lógicas dividido en presentación y datos, el mantenimiento es muy difícil, se corre el riesgo de

saturar de conexiones al servidor, y requerirá muchas llamadas al servidor para operaciones simples

haciendo que el cliente realice todo el trabajo de computo mientras el servidor provee los datos, además a

esto emplea mucho ancho de banda.

Capítulo 1.Fundamenetación Teórica.

43

Conclusiones.

En este capítulo se abordaron los temas más actuales sobre la importancia del uso de herramientas

informáticas para una mejor gestión de la información y control de los procesos, además posibilitó una

mejor comprensión de los conceptos manejados y de los objetivos que nos trazamos, así como los temas

más actuales tratados en el mercado en cuanto a tecnologías, metodologías, herramientas y lenguajes

usados para realizar el análisis y el diseño en el presente trabajo.

Lo más factible según la investigación realizada es realizar una aplicación Web que responda a las

necesidades del proceso de gestión y control que es está llevando a cabo en el CIROA con una interface

agradable. Usar para la implementación la tecnología SDK Flex que incluye su compilador, MXML basado

en XML que permite crear interfaces sofisticadas con efectos visuales y con comportamiento y como un

complemento a este esta ActionScript como lenguaje de programación que sigue el paradigma Orientado

a Objetos que en el ambiente desarrollo de Flex actúa de forma análoga al lenguaje JavaScript, con AS se

puede añadir interacción dinámica entre los componentes de la aplicación. La serialización binaria de

Action Script (AS2, AS3) y los objetos de clase php como lenguaje del lado del servidor se hará

directamente desde el XML independientemente que existen buenos remoting para la comunicación que

facilitan mayor rapidez como AMFPHP que se comunica directamente con los objetos de clases PHP en el

servidor. Para la comunicación con la Base de Datos se utilizará Flex Data Services es el componente que

permite a Flex conectarse con componentes de código dinámico del lado del servidor, por ejemplo

componentes Java, .NET, ColdFusion, PHP, ASP, o Servicios Web, específicamente el httpservices y para

almacenar los datos se trabajará con el MySQL debido a las ventajas que los mismos ofrecen.

Capítulo 2.Estudio Preliminar del Sistema.

44

CAPÍTULO 2. ESTUDIO PRELIMINAR DEL SISTEMA.

Introducción.

Todas las organizaciones que se preocupan por su expansión se dan cuenta de la importancia del tema

de la gestión de la información y su seguridad. El rápido desarrollo de la tecnología en informática permite

la personalización de sistemas informáticas para apoyar la toma de decisiones aprovechando el

conocimiento y las vivencias organizacionales.

En este capítulo se describe la modelación analítica del sistema a desarrollar basada en el estudio

preliminar de otros sistemas para lograr un efecto positivo en la implementación de estos modelos en un

entorno. Se estudia las diferentes formas de organizar, planear y desarrollar cada uno de los pasos para

alcanzar los resultados positivos que estos nuevos aportes auguran.

También, se explica como se lleva a cabo la solicitud de un servicio por un cliente, el trabajo con el mismo

en el departamento de servicio, la salida del almacén y las actividades en los bloques. Se presenta

además la propuesta del sistema y se especifican los requerimientos funcionales y no funcionales. Se

realiza el modelado del negocio y se realiza la definición de los casos se uso, de los actores que se

intervienen en ellos y se muestra el diagrama resultante se caso de uso.

2.1 Objeto de estudio.

2.1.1 Objeto de automatización.

Se desea automatizar todos los procesos expresados anteriormente, o sea la segura administración de la

información de los productos almacenados en el centro y los servicios que se prestan. Obtener la

información de los productos en el almacén para que luego puedan informar oportunamente a los clientes

la forma en que se ofertarán y ser distribuidos a los diferentes bloques para promover las creaciones del

chef, barman y otros. Después, se cuenta con la venta y cobros del mismo.

Capítulo 2.Estudio Preliminar del Sistema.

45

Por lo tanto, teniendo en cuenta los argumentos planteados hasta este momento en relación a los

servicios de CIROA, se propone el presente proyecto de sistema como vía para integrar la operatividad de

todos los servicios.

2.1.2 Información que se maneja.

La información que se manipula serán todos los datos de los clientes, hoja de pedido, planificación

operativa, hoja de existencia de almacén y la hoja de resumen de ingresos diariamente y mensualmente.

En la hoja de datos de los clientes se especifica el nombre de la empresa o persona, tipo de servicio que

requieren, día y hora de la actividad y en que lugar. Se especifica la salida de almacén, la oferta y el cobro

de la misma.

La hoja de pedido lleva el nombre del centro de costo (ejemplo cafetería), el titulo “Pedido”, fecha, una

identificador, los productos con su unidad de medida, la cantidad de la misma y la firma de autorización.

La planificación operativa lleva el nombre de los platos, salida almacén, normas técnicas, raciones, precio

costo, precio venta, costo plan, venta plan, el costo por peso, un identificador de orden.

La existencia de almacén lleva los datos como el tipo del producto, el nombre de producto, la

unidad/medida y la cantidad. Existen dos tipos de productos, productos en moneda nacional y producto en

pesos convertible.

La hoja de resumen de ingresos se hace cada día por un mes específico. La información que se manipula

son la fecha, el nombre de la unidad de costo, ejemplo restaurante, los ingresos en moneda nacional y

pesos convertible. En la hoja existen todas las unidades con sus ingresos respectivamente.

2.1.3 Breve descripción de la propuesta.

Para el sistema, se propone una arquitectura cliente-servidor basada donde se utilicen principios y

tecnologías web con procesamiento de la información de manera dinámica y multiplataforma. El sistema

es encaminando al proceso de gestionar y controlar los recursos y servicios administrativos manteniendo

todo un historial de los procesos que se llevan a cabo para ofrecer un mejor servicio con mas control. Se

presenta con una interfaz amigable y fácil de entender para los usuarios finales. Para la utilización del

Capítulo 2.Estudio Preliminar del Sistema.

46

sistema se pretende que el usuario se autentique para verificar su nivel de acceso según los privilegios del

rol que ejecuta en el sistema. Además el control se realizará por los centros de costos, posibilitando

conocer los productos que serán utilizados de acuerdo a qué servicio se ofrece.

De acuerdo al servicio y los productos elegidos se define y planifica la lista detallada (carta menú) del

conjunto de platos que la cocina puede preparar en cualquier momento. Además, debe asignar los precios

de cada oferta que se calcula en función de la unidad/medida del producto que sale del almacén y verifica

la correspondencia entre ella y los ingresos. Una vez realizados los cálculos, puede realizar reportes

mostrando los hechos económicos para su control y una futura evaluación.

2.2 Modelo de negocio.

Al sistema en cuestión que se propone desarrollar es necesario realizarle un estudio que identifique todo

lo que tiene que ver con los procesos de negocios, siendo capaz de entender la estructura y dinámica de

la organización a través de las actividades de cada proceso que se desea automatizar. Se identificarán los

objetos del dominio o del negocio implicados en el mismo, este modelado también establece las

competencias requeridas en cada proceso: sus trabajadores, sus responsabilidades, y las operaciones

que llevan a cabo.

Los propósitos que se persiguen al realizarse el modelado del negocio son:

Entender la estructura y la dinámica de la organización.

Entender los problemas actuales u identificar mejoras potenciales

Asegurase de que los clientes, usuarios finales y los desarrolladores tienen una idea común de

la organización.

Derivar los requerimientos del sistema a partir del modelado de negocio que se obtenga.

2.2.1 Identificación de los actores del negocio.

Un actor del negocio es cualquier individuo, grupo, entidad, organización, máquina o sistema de

información externos; con los que el negocio interactúa. Lo que se modela como actor es el rol que se

juega cuando se interactúa con el negocio para beneficiarse de sus resultados.

Capítulo 2.Estudio Preliminar del Sistema.

47

Los actores del negocio para el problema que nos ocupa son listados a continuación.

Actores del negocio Justificación

Cliente. El cliente, que puede ser una persona, un grupo de

personas, una empresa, es el que solicita y recibe los

diferentes servicios que brinda el centro.

Proveedor. Es la persona encargada de entregar la planilla de

solicitud de servicios telemáticos a sus subordinados,

especificando cuales son los servicios a los que se tendrá

acceso.

Tabla II-1: Descripción de los actores del negocio.

2.2.2 Identificación de los trabajadores del negocio.

Un trabajador del negocio es una abstracción de una persona (o grupo de personas), una máquina o un

sistema automatizado; que actúa en el negocio realizando una o varias actividades, interactuando con

otros trabajadores del negocio y manipulando entidades del negocio. Representa un rol.

Capítulo 2.Estudio Preliminar del Sistema.

48

Trabajadores del negocio Justificación

Jefe de servicio. Se encarga de recepcionar las solicitudes de los servicios

gastronómicos, revisa la disponibilidad de los productos,

la planificación operativa y crea las ofertas según las

cartas menú.

Jefe de Recreación. Recibe las solicitudes de alquiler del local, realiza contrato

marco según el tipo de actividad recreativa y la

disponibilidad de los medios de recreación.

Jefe de Almacén. Es el encargado de realizar todos los movimientos en el

almacén según la planificación operativa del jefe de

servicio y la entrada o salida de mercancías del almacén.

Tabla II-2: Descripción de los trabajadores del negocio.

2.2.3 Descripción de los procesos de negocio.

Solicitar servicio de recreación: El cliente se persona en la institución y solicita al jefe de recreación el

alquiler del local para una determinada actividad, el jefe de recreación verifica la disponibilidad de locales

y medios según la agenda del mes y la fecha que el cliente dispone para la actividad y el tipo de actividad,

si es posible la reserva se registra la solicitud del cliente con toda la información de contacto en la

planificación operativa del área de recreación y se le informa la fecha de confirmación de para realizar la

reserva y oficializarla legalmente según el contrato.

Solicitar servicio de gastronomía: Como regla fundamental para solicitar este tipo de servicio el cliente

debe poseer una reserva y un contrato del área de recreación, este se persona en el departamento del

jefe de servicio y solicita las ofertas disponibles según el tipo de actividad que puede brindar la institución,

Capítulo 2.Estudio Preliminar del Sistema.

49

el jefe de servicio verifica la planificación operativa de la existencia de los productos en el almacén y

ofrece la carta menú y crea la oferta con los platos que el cliente desee.

Realizar solicitud de servicio: El cliente se persona en la institución y solicita un servicio, los servicios

pueden ser administrados por el jefe de recreación en caso de que sea de alquiler de local o directamente

al jefe de servicio en caso de que sea una actividad con aseguramiento logístico, los responsables

registran las solicitudes.

Cancelar solicitud: El cliente se persona en la institución e informa al jefe de recreación la cancelación

de la reserva recreativa, el jefe de recreación verifica la existencia de la reserva y el contrato y cancela la

solicitud, el cliente cuenta con 72h de antelación a la fecha de la actividad para cancelar la reserva y se le

sea devuelto los honorarios cobrados según contrato, si cancela con menos de 24h se le descuenta un

30% del alquiler del local.

Abastecer almacén: Los proveedores llegan al almacén con la mercancía solicitada previamente por la

empresa, el jefe de almacén realiza la recepción de la misma dejando constancia mediante el documento

de I.R., el acta de recepción, y la tarjeta de estibas.

Ver diagrama de Casos de Uso del Negocio en el Anexo 1.

2.2.3 Realización de los casos de uso del negocio.

NOMBRE DEL CASO DE USO DEL

NEGOCIO:

Realizar solicitud de servicio

ACTORES DEL NEGOCIO: Cliente (Inicia)

PROPÓSITO: Realizar la solicitud de un servicio.

CASOS DE USO ASOCIADOS -

Resumen: El caso de uso se inicia cuando el Cliente se persona en la institución

comunica al Jefe de servicio su deseo de solicitar un servicio de alquiler de local o

preparación de servicios de gastronomía, para solicitar un servicio gastronómico se

debe tener en cuenta la disponibilidad del alquiler del local y haber efectuado la reserva

recreativa y firmado contrato, el jefe de servicio trasmita al cliente al área de recreación,

una vez firmado contrato puede entonces solicitar la disposición de las ofertas.

Capítulo 2.Estudio Preliminar del Sistema.

50

Tabla II-3: Descripción del proceso de negocio “Realizar solicitud de servicio”

NOMBRE DEL CASO DE USO DEL

NEGOCIO:

Solicitar Servicio de Recreación

ACTORES DEL NEGOCIO: Cliente (Inicia)

PROPÓSITO: Realizar la solicitud de un servicio de Recreación.

CASOS DE USO ASOCIADOS -

Resumen: El caso de uso se inicia cuando el Cliente comunica al Jefe de Servicios su

deseo a solicitar un servicio recreación. El Jefe de Servicios remite al cliente hacia el

jefe de recreación, este realiza todas las actividades necesarias comunicando al Cliente

la fecha de disponibilidad del lugar, creando contratos de intención con el Cliente si esta

de acuerdo. Al finalizar entrega los formularios que se han llenando.

Tabla II-4: Descripción del proceso de negocio “Solicitar Servicio de Recreación”

NOMBRE DEL CASO DE USO DEL

NEGOCIO:

Solicitar Servicio de Gastronomía

ACTORES DEL NEGOCIO: Cliente (Inicia)

PROPÓSITO: Realizar la solicitud de un servicio de

Gastronomía.

CASOS DE USO ASOCIADOS -

Resumen: El caso de uso se inicia cuando el Cliente comunica al Jefe de Servicios su

deseo a solicitar un servicio gastronómico. El Jefe de Servicios realiza todas las

actividades necesarias comunicando al Cliente de los productos en existencia y la forma

en que se ofertarán según la carta menú, y se crea la oferta para el cliente.

Tabla II-5: Descripción del proceso de negocio “Solicitar Servicio de Gastronomía”

Capítulo 2.Estudio Preliminar del Sistema.

51

NOMBRE DEL CASO DE USO DEL

NEGOCIO:

Cancelar Solicitud

ACTORES DEL NEGOCIO: Cliente (Inicia)

PROPÓSITO: Realizar la cancelación de los servicios.

(Cancelar el servicio de recreación).

CASOS DE USO ASOCIADOS -

Resumen: El caso de uso se inicia cuando el Cliente comunica al Jefe de Servicios su

deseo de cancelar el alquiler del local suspendiendo la actividad planificada. El Jefe de

Servicios realiza todas las actividades necesarias comunicando al Cliente, es necesario

cancelar para cumplir las clausulas del contrato en el tiempo determinado.

Tabla II-6: Descripción del proceso de negocio “Cancelar Solicitud”

NOMBRE DEL CASO DE USO DEL

NEGOCIO:

Abastecer almacén

ACTORES DEL NEGOCIO: Proveedores (Inicia)

PROPÓSITO: Abastecer de mercancías el almacén para poder

ofrecer los servicios de gastronomía de cada

centro de costo.

CASOS DE USO ASOCIADOS -

Resumen: El Caso de Uso inicia en cuanto el proveedor llega al almacén con la

mercancía y esta es recibida por el jefe del mismo, el proceso de recepción queda

plasmado mediante los documentos de I.R., el acta de recepción, y tarjeta de estibas.

Tabla II-7: Descripción del proceso de negocio “Abastecer almacén”

2.2.4 Diagrama de clases de objetos del negocio.

El diagrama de clases, como artefacto que se construye para describir el modelo de objetos del negocio,

muestra la participación de los trabajadores y entidades del negocio y la relación entre ellos.

Ver diagrama de Objetos del Negocio en el Anexo 1.

Capítulo 2.Estudio Preliminar del Sistema.

52

2.2.5 Especificación de los requisitos funcionales.

R1 Autentificar Usuario: El sistema debe ser capaz de autentificar cada uno de los usuarios que

están registrados en el sistema entrando como datos el nombre de usuario y contraseña.

R2 Cambiar Contraseña: El sistema debe brindarle la posibilidad a cada usuario el cambio de

contraseña, luego de registrarse en el mismo.

R3 Gestionar Usuario: La información que se maneja es (nombre, CI, rol, nombre de usuario y

contraseña). El sistema debe ser capaz de:

R3.1 Registrar nuevo usuario.

R3.2 Modificar datos usuario.

R3.3 Eliminar usuario.

R4 Realizar Auditoría del Sistema: El sistema debe brindarle al administrador la posibilidad de

verificar todos los movimientos realizados en es el sistema.

R5 Gestionar registro de solicitudes: La información que se maneja es (Código de solicitud, datos

del cliente: Tipo de solicitud, nombre y apellidos, CI, dirección, teléfono, cargo, descripción de la

actividad (si servicio gastronómico), cantidad de persona, fecha de solicitud, fecha de actividad,

hora de inicio y hora de fin, estado, centro de costo). El sistema debe ser capaz de:

R5.1 Registrar nueva solicitud.

R5.2 Modificar solicitud.

R5.3 Eliminar solicitud.

R6 Gestionar libro general de actuación e incidencias: La información que se maneja es (fecha de

pedido, hora, estado, usuario, persona que origina el aviso, cliente, descripción del pedido, numero

de contrato, código, destino final según centro de costo, datos de nota (Plato, descripción,

cantidad, unidad, precio, valor)). El sistema debe ser capaz de:

R6.1 Registrar incidencia (pedidos cliente).

Capítulo 2.Estudio Preliminar del Sistema.

53

R6.2 Modificar incidencia (pedidos cliente).

R6.3 Eliminar incidencia (pedidos cliente).

R7 Gestionar el Recibo de Mercancía: La información que se maneja en la vista general (código,

descripción interna, proveedor, familia tipo de producto).

R7.1 Crear acta de Recepción y Tarjeta de Estibas según los productos.

R7.1.1 Insertar un nuevo producto a la tarjeta de estiba.

R7.1.2 Eliminar un producto de la tarjeta de estiba,

R7.1.3 Duplicar un producto de la tarjeta de estiba.

R7.2 Modificar tarjeta estiba: El sistema debe permitir la modificación de la tarjeta estiba, la

información a manejar es en un plano general (cantidad de producto en existencias, cantidad

retirada del producto).

R7.3 Asignar precios y referencia: El sistema debe permitir por producto registrar la siguiente

información: costes (coste añadido, concepto, precio unitario), precio de ventas

R7.4 Mostrar consumo (meses importes y unidades).

R7.5 Mostrar vista de navegación.

R8 Gestionar vale salida del almacén: La información que se maneja es (fecha de salida, hora,

estado, centro de costo, id de incidencia, id productos, descripción, cantidad). El sistema debe ser

capaz de:

R8.1 Registrar vale de salida de productos a gastronomía.

R8.2 Modificar vale de salida.

R8.3 Eliminar vale de salida.

R9 Gestionar proveedores: La información que se maneja es (código proveedor, razón social,

nombre empresa, dirección, teléfonos, contactos), cubiertos por los siguientes contratos (fecha

desde-hasta, descripción, estado activo o renovado), Datos bancarios (entidad bancaria, sucursal,

digito de control, cuenta)). El sistema debe ser capaz de:

R9.1 Registrar datos proveedores.

R9.2 Modificar datos de proveedores.

Capítulo 2.Estudio Preliminar del Sistema.

54

R9.3 Activar/Desactivar proveedores.

R10 Gestionar pedidos a proveedores: La información que se maneja es (numero de pedido,

código de proveedor, nombre, organismo al que pertenece, fecha del pedido, orden de compra,

tipo de movimiento pedido/devolución, notificación al almacén). El sistema debe ser capaz de:

R10.1 Registrar pedidos.

R10.2 Actualizar pedidos.

R10.3 Eliminar o devolver pedidos.

R10.4 Mostrar consumo de compras acumuladas a proveedores (meses, importe).

R11 Gestionar libro de mensajería interna:

R11.1 Redactar y enviar un nuevo mensaje.

R11.2 Eliminar mensaje.

R11.3 Actualizar Libro.

R12 Mostrar reporte de Almacén:

R12.1 Parte de entrega de productos de almacén a gastronomía.

R12.2 Movimiento de devoluciones del almacén a sus proveedores.

R12.3 Movimiento de productos por centro de costo.

R13 Mostrar reporte de proveedores y pedidos.

R13.1 Relación de proveedores.

R13.2 Productos pedidos a proveedor

R13.3 Listado de pedidos pendientes a recibir.

R14 Mostrar Planificación operativa

R14.1 Mostrar Planificación Operativa de un mes y un año en específico.

R14.2 Mostrar Planificación Operativa del mes vigente.

R15 Gestionar cartas menú. La información que se maneja es (nombre del centro de costo, código

de la carta, plato, precio, gramaje). El sistema debe ser capaz de:

Capítulo 2.Estudio Preliminar del Sistema.

55

R16.1 Registrar datos carta menú.

R16.2 Modificar datos carta menú

R16.3 Eliminar datos carta menú.

R16 Administrar Economía y Finanzas: El sistema debe ser capaz de dar la posibilidad al Jefe de

Servicios de crear una ficha de costo de una nueva carta menú, así como mostrar, modificar o

imprimir la ficha de costo de una carta en específico.

R17 Administrar centro de costo: El sistema debe permitir la inserción de un nuevo centro de costo,

así como modificar las características de este o eliminarlo

2.2.6 Especificación de los requisitos no funcionales.

RNF1. Requisitos de confiabilidad

1.1. Disponibilidad –. La aplicación deberá estar disponible las 8 horas del día laborables. El acceso de

mantenimiento debe ser en horas en que los trabajadores no estén utilizando el Sistema.

1.2. Tiempo medio entre fallos – .Debe ser generalmente de unos 2 años, de acuerdo a la degradación

del sistema en su uso continuo.

1.3. Tiempo medio de reparación – Debe estar permitido que el sistema quede fuera de operación

luego de haber fallado un día aproximadamente.

1.4. Exactitud – el Sistema debe constar de una gran exactitud al dar la información requerida en las

salidas del sistema.

1.5. Errores – Categoría de errores:

Menor –que en el sistema no se encuentre registrado un tipo de procedimiento que se lleve a

cabo en el centro.

Significativos–que no se hayan especificado correctamente los roles de los usuarios para el

acceso de estos por niveles al Sistema.

Capítulo 2.Estudio Preliminar del Sistema.

56

Críticos– Que hayan pérdidas de datos o inhabilitadas para el uso de ciertas partes del

funcionamiento del sistema.

.RNF2. Eficiencia.

2.1. Tiempo de respuesta por transacción promedio: 0.1s (segundos), máximo: 1mt (minutos).

2.2. Rendimiento: la cantidad de datos que pueden ser transferidos en un segundo es de 10Mb

(Mega bite).

2.3. Capacidad: el número de usuarios o transacciones que el sistema puede alojar depende de

la capacidad del medio de almacenamiento magnético que esté disponible en el servidor de

datos.

2.4. Modos de degradación: el modo de operación después de que el sistema ha sido

degradado de alguna forma debe ser aceptable y lograr una máxima seguridad para que no

siga degradándose aún más.

2.5. Utilización de recursos: el sistema utilizará todo tipo de recursos o medios de

almacenamiento como son las memorias flash, discos duros de los servidores, también

utilizará recursos de comunicación como son los cableados de redes de intercomunicación

entre máquinas y servidores.

RNF3. Requisitos de soporte.

3.1. El sistema debe ser extensible, siendo capaz de asimilar nuevos módulos.

3.2. El sistema de garantizar la facilidad de mantenimiento.

3.3. La instalación del sistema debe ser fiable y simple.

RNF4. Requisito de usabilidad.

4.1 La aplicación provee interfaces que pueden ser usadas por cualquier usuario con

conocimientos básicos en el manejo de la computadora.

4.2 Debe contener una ayuda que guíe al usuario de acuerdo al Rol en el manejo del sistema.

Capítulo 2.Estudio Preliminar del Sistema.

57

4.3 La aplicación deberá estar disponible las 24 horas del día.

RNF5. Requisitos de documentación online de usuarios y ayuda al sistema.

5.1 El sistema contará con una sesión de ayuda que trate el funcionamiento del sistema y el

modo de trabajarlo.

5.2 El sistema debe mostrar avisos y como medio de apoyo las ayudas concerniente al tipo de

aviso.

RNF6. Requisitos de Seguridad.

6.1. Identificar al usuario antes de que pueda realizar cualquier acción en el sistema y proteger

la información de accesos no autorizados.

RNF7. Requisitos de Software.

7.1. Sistema Operativo Microsoft Windows XP o versiones superiores y SO GNU Linux.

7.2. Flash Player 9.0.

2.2.7 Definición de los Casos de Uso.

Los casos de uso describen las especificaciones de un sistema. Son documentos narrativos que incluyen

la secuencia de los eventos de un actor (agente externo) que utiliza el sistema para completar un proceso.

Los casos de uso describen que hace el sistema, no como lo hace, por lo que en su modelación se hace

necesario tener en cuenta la separación de los objetivos entre las vistas externas e internas.

Definición de los actores del sistema.

Para el sistema que se propone, se definen los siguientes actores y casos de uso:

Capítulo 2.Estudio Preliminar del Sistema.

58

Nombre del actor Descripción

Jefe de servicio. Se encarga de recepcionar las solicitudes de los servicios

gastronómicos, revisa la disponibilidad de los productos,

la planificación operativa y crea las ofertas según las

cartas menú, administra las incidencias y actuaciones.

Jefe de Recreación. Gestiona las solicitudes de alquiler del local, realiza

contrato marco según el tipo de actividad recreativa y la

disponibilidad de los medios de recreación, actualiza la

planificación operativa del mes correspondiente en los

últimos 15 días del mes anterior.

Jefe de Almacén. Es el encargado de realizar todos los movimientos en el

almacén según la planificación operativa del jefe de

servicio y la entrada o salida de mercancías del almacén.

Administrador. Incorpora nuevos usuarios con roles definidos, puede

modificar sus datos y eliminarlos del sistema. Administra

usuarios directamente. Administra las características

técnicas del sistema.

Usuario. El usuario es la persona o grupo de estas encargados

de realizar todas las operaciones básicas en el

sistema, como cambiar contraseña, autenticar usuario,

mostrar planificación operativa y la gestión del libro de

mensajería interna.

Usuario W. Es la persona o grupo de personas encargadas de

realizar tareas tales como: Mostrar Reporte de

almacén y el listado de todos los pedidos realizados a

los proveedores.

Tabla II-8: Descripción de los actores del sistema

Capítulo 2.Estudio Preliminar del Sistema.

59

Listado de los Casos de Uso del sistema.

Caso de Uso: 1 Autenticar usuario

Actores: Usuario(inicia)

Propósito: Permite el acceso al sistema.

Resumen:

El Caso de Uso se inicia cuando el usuario desea acceder de

una manera segura a la aplicación introduciendo su Id y

contraseña, verificando los datos entrados y se le da acceso al

usuario según el rol.

Referencias: R1

Prioridad: Crítico

Caso de Uso: 2 Cambiar Contraseña

Actores: Usuario (inicia)

Propósito: Permite la modificación de la contraseña.

Resumen:

El Caso de Uso se inicia cuando el usuario introduce la nueva

contraseña a cambiar por la contraseña antigua ya registrada en

la base de datos.

Referencias: R2

Prioridad: Secundario

Capítulo 2.Estudio Preliminar del Sistema.

60

Caso de Uso: 3 Gestionar Usuario

Actores: Administrador (inicia)

Propósito: Permite gestionar un usuario nuevo o uno ya existente.

Resumen:

El Caso de Uso se inicia cuando el Administrador selecciona la

opción deseada, ya sea agregar usuario, actualizar usuario, o

eliminar usuario en la vista Gestionar Usuario.

Referencias: R3

Prioridad: Crítico

Caso de Uso: 4 Realizar Auditoria del Sistema

Actores: Administrador(inicia)

Propósito: Permite la verificación de todos los movimientos realizados en el

sistema.

Resumen: El Caso de Uso se inicia cuando el Administrador desea ver un

historial de todos los cambios realizados en el Sistema.

Referencias: R4

Prioridad: Secundario

Caso de Uso: 5 Gestionar Registro de Solicitudes.

Actores: Jefe de Recreación (inicia)

Propósito: Permite gestionar el registro de solicitudes de los servicios de

recreación.

Resumen:

El Caso de Uso se inicia cuando el Jefe de Recreación

selecciona la opción deseada, ya sea registrar solicitud,

modificar solicitud, cancelar solicitud o confirmar solicitud, en la

vista Gestionar registro de solicitudes.

Referencias: R5

Prioridad: Crítico

Capítulo 2.Estudio Preliminar del Sistema.

61

Caso de Uso: 6 Gestionar libro general de actuación e incidencias.

Actores: Jefe de Servicios (inicia)

Propósito: Permite gestionar las solicitudes gastronómicas.

Resumen:

El Caso de Uso se inicia cuando el Jefe de Servicios selecciona

la opción deseada, ya sea registrar pedido, actualizar pedido,

eliminar o imprimir pedido, en la vista Gestionar libro general de

incidencias.

Referencias: R6

Prioridad: Crítico

Caso de Uso: 7 Gestionar Recibo de Mercancía.

Actores: Jefe de Almacén (inicia)

Propósito: Permite gestionar el recibo de mercancía.

Resumen:

El Caso de Uso se inicia cuando el Jefe de Almacén selecciona

la opción deseada, ya sea crear acta de recepción y tarjeta de

estiba, modificar tarjeta de estiba, asignar precios y referencia,

mostrar consumo y vista de navegación, en la vista Gestionar

Recibo de Mercancía.

Referencias: R7, R7.1, 7.1.1, 7.1.2, 7.1.3, R7.2, R7.3, R7.4, R7.5.

Prioridad: Crítico

Capítulo 2.Estudio Preliminar del Sistema.

62

Caso de Uso: 8 Gestionar Vale de salida del almacén

Actores: Jefe de Almacén(inicia)

Propósito: Permite la gestión de los productos que salen del almacén para

gastronomía.

Resumen:

El Caso de Uso se inicia cuando el Jefe de Almacén selecciona

la opción deseada, ya sea registrar vale de salida, actualizar vale

de salida, eliminar vale de salida de la vista “Gestionar vale de

salida del almacén”

Referencias: R8, R8.1, R8.2, R8.3

Prioridad: Crítico

Caso de Uso: 9 Gestionar proveedores

Actores: Jefe de Almacén(inicia)

Propósito: Permite la gestión de los proveedores que abastecen la entidad.

Resumen:

El Caso de Uso se inicia cuando el Jefe de Almacén selecciona

la opción deseada, ya sea registrar proveedor, modificar

proveedor, activar o desactivar proveedor, de la vista “Gestionar

Proveedor”.

Referencias: R9, R9.1, R9.2, R9.3

Prioridad: Crítico

Capítulo 2.Estudio Preliminar del Sistema.

63

Caso de Uso: Gestionar pedidos a proveedores

Actores: Jefe de Almacén(inicia)

Propósito: Permite la gestión de los pedidos a los proveedores.

Resumen:

El Caso de Uso se inicia cuando el Jefe de Almacén selecciona

la opción deseada, ya sea registrar pedido, actualizar pedido,

eliminar pedido, devolver pedido o mostrar el consumo de

compras a proveedores de la vista “Gestionar pedidos a

Proveedores”.

Referencias: R10,R10.1, R10.2, R10.3

Prioridad: Secundario

Caso de Uso: 11 Gestionar Libro de Mensajería interna

Actores: usuario(inicia)

Propósito: Permite la gestión de mensajería interna entre los usuarios del

sistema

Resumen:

El Caso de Uso se inicia cuando el usuario desea escribir un

mensaje, enviarlo, eliminar un mensaje, actualizar libro, o ver

todos los mensajes recibidos o enviados

Referencias: R11

Prioridad: secundario

Capítulo 2.Estudio Preliminar del Sistema.

64

Caso de Uso: 12 Mostrar reporte de Almacén

Actores: Usuario W(inicia)

Propósito: Permite mostrar un reporte de todos los movimientos realizados

en el almacén.

Resumen:

El Caso de Uso se inicia cuando el Usuario W selecciona la

opción deseada, ya sea mostrar: parte de entrega de productos

a gastronomía, el movimiento de devoluciones del almacén a sus

proveedores, registros de movimientos al almacén por

proveedores o el movimiento de productos por centro de costo,

de la vista “Mostrar Reporte de Almacén”.

Referencias: R12, R12.1, R12.2, R12.3, R12.4.

Prioridad: Crítico

Caso de Uso: 13 Mostrar reporte de proveedores y pedidos.

Actores: Usuario W(inicia)

Propósito: Permite mostrar un reporte de todos proveedores que abastecen

la entidad y de los pedidos realizados a estos.

Resumen:

El Caso de Uso se inicia cuando el Usuario W selecciona la

opción deseada, ya sea mostrar: relación de proveedores,

productos pedidos a proveedor, listado de pedidos pendientes a

recibir, de la vista “Mostrar Reporte de proveedores y pedidos”.

Referencias: R13, R13.1, R13.2, R13.3.

Prioridad: Secundario

Capítulo 2.Estudio Preliminar del Sistema.

65

Caso de Uso: 14 Mostrar Planificación operativa de recreación

Actores: usuario(inicia)

Propósito: Permite al usuario observar la planificación operativa de

recreación

Resumen:

El Caso de Uso se inicia cuando el usuario desea observar las

actividades recreativas planificadas para el mes vigente o

planificaciones operativas anteriores.

Referencias: R14, R14.1, R14.2

Prioridad: Secundario

Caso de Uso: 16 Gestionar cartas menú

Actores: Jefe de Servicios(inicia)

Propósito: Permite la gestión de todas las cartas menú de todos los centros

de costos.

Resumen:

El Caso de Uso se inicia cuando el Jefe de Servicios selecciona

la opción deseada, ya sea crear carta menú, eliminar carta

menú, modificar o mostrar una carta menú, de la vista

“Gestionar cartas menú”.

Referencias: R16, R16.1, R16.2

Prioridad: Crítico

Capítulo 2.Estudio Preliminar del Sistema.

66

Caso de Uso: 17 Administrar economía y finanzas

Actores: Jefe de Servicios(inicia)

Propósito: Permite Administrar las fichas de costo de las cartas menú

Resumen:

El Caso de Uso se inicia cuando el Jefe de Servicios selecciona

la opción deseada, ya sea registrar dicha de costo, mostrar ficha

de costo e imprimir ficha de costo de la vista “Economía y

Finanzas”

Referencias: R17

Prioridad: Crítico

Capítulo 2.Estudio Preliminar del Sistema.

67

Diagrama de Casos de Uso del sistema.

Figura 1-1: Diagrama de casos de uso del sistema

Gestionar libro general de

ncidencias

(from Use Cases)

Jefe de servivio

(f rom Actores)

Gestionar registro de solicitudes

(from Use Cases)

Jefe de recreacion

(f rom Actores)

Gestionar el Recibo de Mercancía

(from Use Cases)

Gestionar vale salida del almacén:

(from Use Cases)

Gestionar proveedores

(from Use Cases)

Gestionar pedidos a proveedores:

(from Use Cases)

Jefe de almacen

(f rom Actores)

Mostrar reporte de Almacén

(from Use Cases)

Mostrar reporte de proveedores y

pedidos.

(from Use Cases)

Usuario w

(f rom Actores)

Autentificar Usuarios

(from Use Cases)

Cambiar de Contraseña

(from Use Cases)

Gestionar libro de mensajería

interna

(from Use Cases)

Mostrar Planificación operativa

(from Use Cases)

Usuario

(f rom Actores)

Gestionar Usuarios

(from Use Cases)

Realizar Auditoría al Sistema

(from Use Cases)Administrador

(f rom Actores)

Capítulo 2.Estudio Preliminar del Sistema.

68

Conclusiones Parciales.

En este capítulo quedaron definidos los procesos del negocio, logrando un mayor entendimiento de cómo

ocurre la gestión y control de los servicios que se presta a la población cuando solicitan un servicio, así

como la distribución de los productos y recursos a los diferentes centros de costos, y la recepción de la

mercancía en el CIROA.

Además se obtuvieron los requerimientos funcionales y no funcionales de la aplicación a partir del modelo

del negocio obtenido. Posteriormente, y partiendo de los requisitos del sistema fueron presentados los

casos de uso y sus relaciones con los actores. Culminando con la obtención de el ciclo de desarrollo de la

aplicación.

Capítulo 3. Análisis y Diseño.

69

CAPÍTULO 3. ANÁLISIS Y DISEÑO DEL SISTEMA

Introducción.

Para desarrollar una aplicación, también es necesario contar con descripciones detalladas y de alto nivel

de la solución lógica y saber cómo se satisfacen los requerimientos y las restricciones. El diseño pone de

relieve la solución lógica: cómo el sistema cumple con los requerimientos. [Larman, 1999]

En este capítulo abordamos las etapas de análisis y diseño, importante en la obtención de destrezas para

la creación y mantenimiento exitoso del sistema, donde se ponen de manifiesto a través del modelo

conceptual y los diagramas de interacción y clases.

3.1 Modelo de Análisis.

Para crear una aplicación de software hay que describir el problema y las necesidades investigación o

requerimientos: en que consiste el conflicto y que debe hacerse. El Análisis se centra en una investigación

del problema, no en la manera de definir una solución. [Larman, 1999] Por ejemplo, si se desea un nuevo

sistema de información computarizada de una biblioteca, debemos preguntarnos cuales procesos de la

institución se relacionan con su uso.

En esta etapa de análisis podremos razonar más sobre los aspectos internos del sistema. También

podremos usar un lenguaje más formal para apuntar detalles relativos a los requisitos del sistema.

El paso esencial de un análisis orientado a objetos es descomponer el problema en conceptos u objetos

individuales. El modelo conceptual es la representación gráfica de los mismos. [Larman, 1999]

VER Modelo de Clases del análisis en ANEXO 2.

Capítulo 3. Análisis y Diseño.

70

3.2 Modelo del Diseño.

En la etapa de diseño modelamos el sistema y encontramos su forma para que soporte todos los

requisitos. [Larman, 1999]

3.2.1 Diagrama de Clases del Diseño.

El diagrama de clases describe gráficamente las especificaciones de las clases de software [Larman,

1999]. Contiene la siguiente información:

Clases, asociaciones y atributos.

Métodos.

Información sobre los tipos de atributos.

Navegabilidad.

Dependencias.

VER Diagrama de Clases del diseño en ANEXO 3, el mismo ha sido separado en subsistemas como se

muestra a continuación.

Seguridad

Gestionar ofertas y

serviciosReporte

Busquedas

Gestionar provedores y

productos

Figura 1-2: Diagrama de paquetes del sistema

Capítulo 3. Análisis y Diseño.

71

3.2.3 Modelo Físico de la BD.

El Diagrama Entidad Relación (también conocido como DER, o diagrama E-R) es un modelo de red que

describe con un alto nivel de abstracción la distribución de datos almacenados en un sistema, en otras

palabras es el encargado de mostrar las relaciones entre las diferentes entidades dentro de una

aplicación.

Se ha aplicado a los datos la teoría de la normalización; con la finalidad de diseñar una base de datos más

eficiente. Es un proceso que se basa en la descomposición aplicando varias fases. Tras completar cada

fase se dice que la relación está en Primera Forma Normal (1FN), Segunda Forma Normal (2FN), Tercera

Forma Normal (3FN) o Forma Normal de BoyceCodd (FNBC). Existen también la Cuarta Forma Normal

(4FN) y la Quinta Forma Normal (5FN).

El diseño lógico de la Base de Datos ha sido normalizada hasta la Tercera Forma Normal (3FN). Ya que

no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.

VER Diagrama Físico de la Base de Dato en ANEXO 4, el mismo ha sido separado en cuatro partes.

3.2.6 Diagrama de Despliegue.

El arquitecto debe prestar especial atención a la configuración de hardware en la cual se desplegará el

sistema, identificando Nodos Procesadores (Computadoras), Dispositivos, y Protocolos. Para representar

esta información emplea el elemento de UML denominado Diagrama de Despliegue.

Capítulo 3. Análisis y Diseño.

72

Impresora

PC_Cliente <Servidor Web y

SBD>Http / TCP / IP

USB

Pentium IV

512MBRAM

80GB HDD

APPServer

MySQL

Figura 1-3: Diagrama de despliegue

En el diagrama anterior, se muestran los tres tipos de elementos: Dispositivos, Procesadores y

Protocolos. A continuación se brindan ejemplos de estos elementos:

Procesadores: Nodos que tienen capacidad de procesamiento, computadoras por lo general. Ej.

Maquina Cliente, Servidor de Datos, Servidor Web, Servidor de Aplicaciones, Servidor de Correo.

Dispositivos: Nodos que no tienen capacidad de procesamiento. Ej. Impresora, Scanner, WebCam,

Lector de Tarjeta.

Protocolos: Estándares que deben existir implementados en la red entre máquinas, para efectuar

cierta comunicación.

Capítulo 3. Análisis y Diseño.

73

Conclusiones Parciales.

Con desarrollo de este capítulo se obtuvo el diagrama de clases del análisis, donde se plantearon los

conceptos más significativos en el dominio del problema planteado. Este diagrama esta formado por

clases preliminares, que se refinaron y perfeccionaron hasta obtener un diagrama de clases, diagrama de

clases de diseño Web, que se representa por estereotipos como: Server Page, Client Page y HTML Form

(páginas servidoras, páginas clientes y formularios), entre otras. Además de las relaciones y asociaciones

entre ellas, navegabilidad, roles y multiplicidad.

Además, fue elaborado el Diagrama Entidad Relación, modelo que facilita la generación y creación de la

Base de Datos del Sistema. Así como las descripciones de las clases y tablas, de los diagramas de

Clases y Diagrama Físico de la base de Datos, respectivamente.

Capítulo 4. Implementación y Prueba.

74

CAPÍTULO 4. IMPLEMENTACIÓN Y PRUEBA DEL SISTEMA.

Introducción.

Partiendo de los resultados del diseño, en el presente capítulo se analiza la disciplina de implementación,

la cual denota el estado actual del sistema en términos de componentes y subsistemas de

implementación. Además se definen las pruebas del software como elemento crítico para la garantía de la

calidad del software y revisión final del cumplimiento de las especificaciones del diseño y de la

codificación.

El esta fase describe cómo los elementos del modelo del diseño, como las clases, se implementan en

términos de componentes, como ficheros de código fuente, ejecutables, etc. El modelo de implementación

describe también como se organizan los componentes de acuerdo con los mecanismos de estructuración

y modularización disponibles en el entorno de implementación y en el lenguajes de programación

utilizados, y cómo dependen los componentes unos de otros.

Para este software van a ser aplicadas las pruebas de caja negra que no son más que aquellas que se

llevan a cabo sobre la interfaz del software. O sea, su objetivo es demostrar que todas las funciones del

software están operativas, que según una entrada se produzca el resultado correcto. Estas pruebas

permiten encontrar:

Funciones incorrectas o ausentes.

Errores de interfaz.

Errores en estructuras de datos o en accesos a las Bases de Datos externas.

Errores de rendimiento.

Errores de inicialización y terminación.

Capítulo 4. Implementación y Prueba.

75

4.1 Diagrama de componentes.

Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones entre ellos.

En el siguiente diagrama se representan los componentes dada su distribución física por capas lógicas de

la arquitectura de la aplicación. Los diagramas que especifican las relaciones entre los diferentes

componentes que forman al sistema se muestran en los anexos. Ver Anexo 5.

4.2 Prueba de caja negra.

Caso de uso: Autenticar Usuario

Caso de prueba: Ingresar la contraseña o nombre de usuario mal.

Entrada: Ingresar en el campo de texto una contraseña o usuario incorrecto.

Resultado: Se muestra un mensaje informando que la contraseña o

usuario son incorrectos y que debe verificar los datos o sino

contactar con el administrador del sistema.

Condiciones:

Caso de uso: Gestionar información de los usuarios.

Caso de prueba: Insertar usuario con un nombre de usuario ya existente.

Entrada: Insertar usuario con nombre de usuario „diego‟

Resultado: Se muestra un mensaje informando que el nombre de usuario

ya está siendo usado por otro usuario.

Condiciones: Ya debe existir un usuario con Nick „diego‟

Conclusiones Parciales.

76

Conclusiones Parciales.

En este capítulo se obtuvo como resultado fundamental el modelo de implementación, el cual incluye entre

sus elementos los subsistemas de implementación y los componentes con sus dependencias.

El modelo de implementación fue usado como entrada principal de la etapa de prueba. Durante esta etapa

cada construcción generada en la implementación se sometió a diferentes pruebas para comprobar su

integridad y funcionamiento. Se obtuvo como resultado las pruebas de caja negra y un sistema más

robusto y menos propenso a errores o a fallas del funcionamiento.

Glosario de Términos.

77

GLOSARIO DE TÉRMINOS

ASP: (Active Server Pages) Paginas Activas del Servidor.

Base de Datos: (DataBase). Conjunto de datos relacionados que se almacenan de forma que se pueda

acceder a ellos de manera sencilla, con la posibilidad de relacionarlos, ordenarlos en base a diferentes

criterios, etc. Las bases de datos son uno de los grupos de aplicaciones de productividad personal más

extendidos. Entre las más conocidas pueden citarse dBase, Paradox, Access y Aproach, para entornos

PC, y Oracle, ADABAS, DB/2, Informix o Ingres, para sistemas medios y grandes.

Browser: Navegador. Aplicación para visualizar documentos WWW y navegar por Internet. En su forma

más básica son aplicaciones hipertexto que facilitan la navegación por los servidores de navegación de

Internet. Los más avanzados, cuentan con funcionalidades plenamente multimedia y permiten

indistintamente la navegación por servidores WWW, FTP, Gopher, acceso a grupos de noticias, la gestión

del correo electrónico, etc.

CASE: (Computer Aided Software Engineering). Bajo el término de Ingeniería de Software Asistida por

Ordenador se incluyen una serie de herramientas, lenguajes y técnicas de programación que permiten la

generación de aplicaciones de manera semiautomática. Las herramientas CASE liberan al programador

de parte de su trabajo y aumentan la calidad del programa a la vez que disminuyen sus posibles errores.

Casos de Uso: Un casos de uso es una secuencia de transacciones que son desarrolladas por un

sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de

uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción

con los usuarios y/o otros sistemas.

Cliente Servidor: Modelo lógico de una forma de proceso cooperativo, independiente de plataformas

hardware y sistemas operativos. El concepto se refiere más a una filosofía que a un conjunto determinado

de productos. Generalmente, el modelo se refiere a un puesto de trabajo o cliente que accede mediante

una combinación de hardware y software a los recursos situados en un ordenador denominado servidor.

Glosario de Términos.

78

DHTML: Dynamic HTML, son aplicaciones que contienen objetos y eventos y se procesan en el lado del

cliente dentro del navegador Web.

Hardware: Conjunto de componentes materiales de un sistema informático. Cada una de las partes

físicas que forman un ordenador, incluidos sus periféricos. Maquinaria y equipos (CPU, discos, cintas,

modem, cables, etc.). En operación, un computador es tanto hardware como software. Uno es inútil sin el

otro. El diseño del hardware especifica los comandos que puede seguir, y las instrucciones le dicen qué

hacer. El hardware es "almacenamiento y transmisión".

HTML: (Hiper Text Transfer Protocol). Protocola de transferencia de HiperTexto. Es el protocolo de

Internet que permite que los exploradores del WWW recuperen información distribuidos, colaborativos y

de diferentes medios, de los servidores.

HTTP: (HyperText Markup Language). Lenguaje de marcado de Hipertexto. Es el lenguaje estándar para

describir el contenido y la apariencia de las páginas en el WWW, es decir, es un conjunto de

especificaciones para el intercambio de ficheros (texto, gráfico, imagen, sonido, vídeo) en la Web.

Internet: Red de ordenadores mundial que permite comunicación y transferencia de datos, noticias y

opiniones entre personas y usuarios conectadas a ella.

Intranet: Es una red privada que pertenece a una organización, diseñada y desarrollada siguiendo los

protocolos propios de Internet, la cual puede ser accesible solo por sus miembros o empleados. Puede

tratarse de una red aislada, es decir no conectada a Internet. La mayoría de las Intranet, están

configuradas de forma que sus usuarios puedan tener acceso a Internet sin permitir que los usuarios de

Internet tengan acceso a los equipos de la Intranet.

Jscript o JavaScript: JavaScript, al igual que Java o VRLM, es una de las múltiples maneras que han

surgido para extender las capacidades del lenguaje HTML. JavaScript no es un lenguaje de programación

propiamente dicho. Es un lenguaje script u orientado a documento, como pueden ser los lenguajes de

macros que tienen muchos procesadores de texto. Nunca podrás hacer un programa con JavaScript, tan

sólo podrás mejorar tu página Web con algunas cosas sencillas (revisión de formularios, efectos en la

barra de estado, etc...) y, ahora, no tan sencillas (animaciones usando HTML dinámico, por ejemplo).

Glosario de Términos.

79

JavaScript y Java son dos cosas distintas. Principalmente porque Java sí que es un lenguaje de

programación completo. Lo único que comparten es la misma sintaxis.

Link: Apuntadores de Hipertexto que sirven para saltar de una información a otra, o de un servidor a otro,

cuando se navega por Internet.

Microsoft: (Microsoft Corporation, Redmond, WA) Compañía de software más grande del mundo.

Microsoft fue fundada en 1975 por Paul Allen y Bill Gates, dos estudiantes universitarios que escribieron el

primer intérprete BASIC para el microprocesador 8080 de Intel. Aunque también se conoce por sus

lenguajes de programación y aplicaciones para computadores personales, el éxito sobresaliente de

Microsoft se debe a sus sistemas operativos DOS y Windows.

MVC: (Model-View-Controller) Modelo Vista Controlador.

TCP/IP: Transmision Control Protocol/Internet Protocol. Sistema de protocolos, definidos en RFC 793, en

los que se basa buena parte de la comunicación de Internet. TCP/IP es el estándar de protocolo de

comunicaciones requerido por las computadoras que acceden a Internet.

Flash Player: Adobe Flash Player es una aplicación en forma de reproductor multimedia creado

inicialmente por Macromedia y actualmente distribuido por Adobe Systems. Permite reproducir archivos

SWF que pueden ser creados con la herramienta de autoría Adobe Flash, con Adobe Flex o con otras

herramientas de Adobe y de terceros.

Framework: Es una estructura conceptual y tecnológica de soporte definida, normalmente con artefactos

o módulos de software concretos, con base en la cual otro proyecto de software puede ser organizado y

desarrollado. Típicamente, puede incluir soporte de programas, bibliotecas y un lenguaje interpretado

entre otros programas para ayudar a desarrollar y unir los diferentes componentes de un proyecto.

Oracle: Empresa especializada en la fabricación de programas de base de datos (en ordenadores).

PHP: (Preprocessed Hypertext Pages) Páginas de Hipertexto Peprocesadas. Fue creado por Rasmus

Lerdorf a finales de 1994, aunque no hubo una versión utilizable por otros usuarios hasta principios de

Glosario de Términos.

80

1995. Esta primera versión se llamó, Personal Home Page Tools. Al principio, PHP sólo estaba

compuesto por algunas macros que facilitaban el trabajo a la hora de crear una página Web. Hacia

mediados de 1995 se creo el analizador sintáctico y se llamó PHP/F1 Versión 2, y sólo reconocía el texto

HTML y algunas directivas de mSQL. A partir de este momento, la contribución al código fue pública.

RDBMS: (Relational Data Base) Administrador de bases de datos relacional.

Red: Se ha dicho muchas veces que el futuro de la informática está en las comunicaciones. Es una

afirmación bastante obvia que hoy tiene ya sentido pleno. La intercomunicación entre ordenadores permite

no sólo el intercambio de datos, sino también compartir recursos de todo tipo, optimizando así elevadas

inversiones. Las redes son el soporte para estas conexiones y (aparte la diferenciación más genérica

entre redes públicas y privadas), según el objeto de definición, la terminología es variada.

RUP: (Rational Unified Process) Proceso Unificado de Rational.

Servidor: Genéricamente, dispositivo de un sistema que resuelve las peticiones de otros elementos del

sistema, denominados clientes. (Ver: Cliente/servidor).

SGBD: Sistema de Gestión de Bases de Datos.

Sistema: En informática, este término utilizado sin otra palabra que lo adjetive designa un conjunto de

hardware y software específico.

Software: " El software se ocupa de los detalles de un negocio en constante cambio y debe procesar

transacciones en una forma lógica. Los lenguajes se utilizan para programar el software. La lógica y el

lenguaje involucrados en el análisis y la programación son por lo general mucho más complejos que

especificar un requerimiento de almacenamiento y de transmisión. El software es "lógica y lenguaje.

SQL: (Structured query language) Lenguaje de preguntas estructurado, lenguaje que utiliza bases de

datos para pedir información de las mismas.

Sun: Sun Microsystem Inc. Una de las firmas norteamericanas más importantes en la fabricación y

comercialización de estaciones de trabajo, entre otros productos.

Glosario de Términos.

81

UML: (Unified Modeling Language) Lenguaje de Modelación Unificado. Es una notación Standard para

modelar objetos del mundo real como primer paso en el desarrollo de programas orientados a objetos.

Web o WWW: (World Wide Web) Telaraña o malla mundial. Sistema de información con mecanismos de

hipertexto creado por investigadores del CERN. Los usuarios pueden crear, editar y visualizar documentos

de hipertexto. También llamado W3.

XML: (Extensible Markup Language) Es un meta-lenguaje que permite definir lenguajes de marcado

adecuados a usos determinados. En la práctica corresponde a un estándar que permite a diferentes

aplicaciones interactuar con facilidad a través de La Red. XML.

Conclusiones Generales.

82

CONCLUSIONES GENERALES.

Del análisis de los resultados de esta investigación se plantean las conclusiones siguientes:

Los sistemas informáticos de gestión de información es una herramienta de vital importancia para

el seguro control de toda la información ya que el proceso manual con que desarrollan los

procesos dificulta la gestión y la calidad de los servicios.

Lo más factible según la investigación realizada es realizar una aplicación Web usando tecnologías

novedosas como Flex, AS, PHP, MySql.

Las necesidades de los clientes fueron identificadas a través de la definición de los requerimientos.

Fueron identificados 17 casos de uso, 11 representan la arquitectura base del sistema y fueron los

primeros a implementar. En la correspondiente descripción y expansión de los casos de uso, se

detallan los procesos y especificaciones de cada uno.

Se realizó el análisis y diseño del paquete de seguridad, mostrando a través de los diagramas de

clases del análisis y diseño, y los de interacción; los conceptos más significativos en el dominio del

problema así como el comportamiento interno del sistema.

Se dispone una Base de Datos capaz de adaptarse fácilmente a las posteriores versiones del

sistema

Con el diseño e implementación del sistema se provee al CIROA de una herramienta eficaz para la

gestión oportuna de parte de la información que se maneja en el centro.

Recomendaciones.

83

RECOMENDACIONES.

Hacer un estudio más profundo de la seguridad en las bases de datos en todos los niveles que

existen para evitar el mal uso de los recursos a la hora de la aplicación y calificación de los

servicios administrativos.

Profundizar acerca de la administración del sistema, principalmente referente a los permisos de

escritura/lectura.

Completar los ciclos de desarrollo de la aplicación, para darle al sistema toda la funcionalidad

requerida.

Elaborar la ayuda en línea y un manual de usuario.

Probar el sistema en el centro, con el fin de explotar sus potencialidades y contribuir de esa forma

a las mejoras que se les deben hacer al software como potenciar un modulo de inventario y otro de

gestión de activos fijos.

Referencia Bibliográfica.

84

REFERENCIA BIBLIOGRÁFICA

[1]. “ActionScript”Colectivo de Autores. Adobe Flex 3. Programming ActionScript 3. Adobe System

Incorporated. 2008.

[2]. “Aplicación Web”. http://es.wikipedia.org/Aplicacion Web. Febrero 10, 2010

[3. “Base de Datos”. http://es.wikipedia.org/wiki/BasedeDatos. Enero 11, 2010.

[4. “Gestión”. http://www.gestionyadministracion.com/Gestion. Enero 20, 2010.

[5]. “Sistema Informático”. http://es.wikipedia.org/wiki/Sistema_informatico. Marzo 5, 2010.

[6.] “Software Gestión Comercia”l. http://www.datahousecompany.com.ar/Sist. Diciembre 10, 2009

“El Proceso Unificado de Desarrollo de Software”. Addison Wesley, 1999.

[7]. “Ingeniería del Software”Choque Aspiazu, Guillermo.”Ingeniería del Software, Principios y

Conceptos”. La Paz, Bolivia, Diciembre 2002.

[8]. “MXML”. http://es.wikipedia.org/MXML. Febrero 10 2010

[9]. “PHP”.Laura Thomson, Luke Welling. ”Desarrollo Web con PHP y MySQL”.

[10]. “Proceso Unificado de Desarrollo”.Jacobson Ivar, Booch Grady, Rumbaugh James.

[11].” RIAs” http://es.wikipedia.org/Rich_Internet_Applications. Enero 22, 2010

[12].”Adobe Flex”. http://www.adobe.com/. Febrero 9, 2010.

Bibliografía.

85

BIBLIOGRÁFICA

1. Base de Datos http://es.wikipedia.org/wiki/BasedeDatos. Enero 11, 2010.

2. Colectivo de Autores. Adobe Flex 3. Programming ActionScript 3. Adobe System Incorporated.

2008.

3. Choque Aspiazu, Guillermo.”Ingeniería del Software, Principios y Concepts”. La Paz, Bolivia,

Diciembre 2002.

4. Flex. http://www.adobe.com/. Febrero 9, 2010.

5. Flex. http://www.flex.org. Febrero 8, 2010.

6. Gestión. http://www.gestionyadministracion.com/Gestion. Enero 20, 2010.

7. Jacobson Ivar, Booch Grady, Rumbaugh James. “El Proceso Unificado de Desarrollo de

Software”. Addison Wesley, 1999.

8. Laura Thomson, Luke Welling. ”Desarrollo Web con PHP y MySQL”.

9. MXML. http://es.wikipedia.org/MXML. Febrero 10 2010.

10. RIAs http://es.wikipedia.org/Rich_Internet_Applications. Enero 22, 2010.

11. Sistema Informático”. http://es.wikipedia.org/wiki/Sistema_informatico. Marzo 5, 2010.

12. Software Gestión Comercial. http://www.datahousecompany.com.ar/Sist. Diciembre 10, 2009.

Anexos.

86

ANEXO 1. MODELO DE NEGOCIO.

Abastecer almacen

(from Casos de uso del Negocio)

Proveedor

(f rom Actores del negocio)

Realizar solicitud de servicio

(from Casos de uso del Negocio)

Solicitar servicio gastronomico

(from Casos de uso del Negocio)

Solicitar servicio recreacion

(from Casos de uso del Negocio)

Cancelar solicitud

(from Casos de uso del Negocio)

Cliente

(f rom Actores del negocio)

Anexos.

87

Plan operacional

Contrato de intensionNota de pedidos

Jefe de recreacion

Ofertas de platos

Listado de productos

Jefe de servicio

Acta de recepcion

Jefe de almacen

Tarjeta de estiba

Modelo de objetos del negocio

Anexos.

88

ANEXO 2. DIAGRAMA DE CLASES DEL ANÁLISIS.

CU: Autenticar

CU: Gestionar Usuario

Anexos.

89

CU: Gestionar Recibo de Mercancías

CU: Gestionar Solicitudes

Anexos.

90

CU: Gestionar Libro de incidencias

Anexos.

91

ANEXO 3. DIAGRAMA DE CLASES DEL DISEÑO.

Subsistema: Seguridad

Anexos.

92

Subsistema: Gestión servicios

Anexos.

93

Subsistema: Gestión pedidos y proveedores

Fr_crearTarjetaEstiba

productos

proveedores

proveedores.as

SP_gestionarProveedores

<<Query>>

<<Submit>>

Fr_registrarProveedores

CP_proveedores .mxml

<<Build>>

<<Include>>

1

1

Fr_modificarProveedores

1

1

1

1

1

1

Fr_ModificarTarjetaE

CP_tarjetaEstiba .mxml

1

1

1

1

1

1

1

1

productos.as

<<Include>>

CP_indexPrincipal .mxml

(f rom paquete de gestion of ertas y serv icios)

<<Link>>

pedidos

devoluciones

pedidos.as

Fr_registrarPedidos

CP_pedidos .mxml

<<Include>>

1

1

Fr_modificarPedidos

1

11

1

1

1

SP_gestionarProductos

<<Submit>>

<<Build>>

<<Link>>

<<Query>>

SP_gestionarPedidosp

<<Link>>

<<Build>>

<<Query>>

<<Query>>

<<Submit>>

SP_alertas

alertas<<Query>>

Anexos.

94

ANEXO 4. DIAGRAMA FISICO DE LA BASE DE DATOS.

Anexos.

95

ANEXO 5. DIAGRAMA DE COMPONENTES.

Subsistema: Gestión servicios

GestionarSolicitu

d .php

<<Server Page>>

Index Principal

.html

IU_RegistrarSolicitud

.mxml

<<Client Page>>

IU_EliminarSolici

tud .mxml

<<Client Page>>

GestionarSolicitud .as

<<Client Page>>

RegistrarSolicitud

.mxml

<<Client Page>>

Solicitudes .php

<<Server Page>>

conexion_class

.php

<<Server Page>>

BD

GestionarUsuario

s .php

<<Server Page>>

IU_RegistrarUsu

ario .mxml

<<Client Page>>

IU_ModificarUsu

ario mxml

<<Client Page>>

IU_EliminarUsua

rios .mxml

<<Client Page>>

Usuarios .php

<<Server Page>>

GestionarUsuarios .as

<<Client Page>>

Anexos.

96

ANEXO 6. VISTA DE LA SISTEMA.

Vista del Jefe de Servicio: Gestionar Plato.

Vista del Jefe del Almacén: Gestionar Mercancía.