t-uce-0011-68

1

UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE INGENIERIA CIENCIAS FISICAS Y MATEMATICA

CARRERA DE INGENIERIA INFORMTICA

SISTEMA WEB DE INVENTARIOS Y FACTURACIN PARA EL CONTROL DE COMPONENTES Y SISTEMAS AUTOMTICOS

CONTAMATIC CIA.LTDA

TRABAJO DE GRADUACIN PREVIO A LA OBTENCION DEL TTULO DE INGENIERO INFORMTICO

AUTOR (es): Maricella Alexandra Sinchiguano Vizuete TUTOR: Ing. Jorge Morales Cardoso

Quito Ecuador 2013

Sistema de Inventarios y Facturacin de Componentes Electrnicos

ii

DEDICATORIA

Esta tesis est dedicada a Dios, quien supo darme fuerza para cumplir con mis metas

sin contar con la felicidad ms grande; mi hijo Sebastin que es el motor de mi vida la persona que da a da llena de felicidad mi corazn; todas las malas noches que te

hice pasar tiene una justificacin y esa es lo que ahora soy, gracias mi pequeo.

A mi esposo por compartir su vida conmigo y darme apoyo en los momentos ms difciles, por entenderme a pesar de no estar mucho tiempo junto a l. Gracias por brindarme tu comprensin y amor.

A mi papi por ser un pilar fundamental en mi vida y en mi carrera, la persona que desde el principio me apoyo a seguir adelante y con sus inconfundibles palabras siempre estuvo a mi lado dicindome Dale que tu si puedes.. y tena toda la razn lo logre. Gracias Papi.

A mi mami que es una de las personas ms importantes en mi vida, la que con sus

palabras supo alentarme cada vez que caa, dicindome siempre te vamos apoyar hasta el final Sigue adelante con tus metas y sueos que estar a tu lado hasta

cuando Dios lo permita.

A mis hermanos que son el complemento de mi vida, siempre estuvieron ah brindndome un abrazo y una palabra de aliento cuando pens que ya no poda ms,

Gracias Gaby y Said.

Maricella


iii

AGRADECIMIENTO

Quiero agradecer a Dios por darme sabidura para poder seguir adelante y cumplir mis metas.

A mi Pap Jos que siempre con palabras sabas supo darme un consejo y su apoyo incondicional, supo ser un padre y un amigo a pesar de ser mi abuelito; al igual que

Yoli quien siempre se preocup por m; brindndome su cario.

A mi Mami por darme apoyo incondicional en todas mis decisiones y ayudarme a

entender cuando estaba mal y corregirme de manera cariosa, gracias a ti mamita por ayudarme siempre y ser mi confidente.

A mi hermana Gaby por su ayuda incondicional con mi pequeo, por ser como una

madre cuando yo no poda estar cerca de l y darle los abrazos y besos que necesit.

A mis suegros Teresa e Ismael que gracias a su ayuda con el cuidado de mi hijo pude seguir con mi tesis y cumplir mis metas, Gracias.

A mi tutor por brindarme su ayuda y guiarme para seguir adelante con mi proyecto de tesis.

A mi revisor Mauro Rosas quien supo guiarme para poder sacar el proyecto adelante

dndome un poco de su tiempo y su conocimiento.

Maricella


iv

AUTORIZACIN DE AUDITORA INTELECTUAL

Yo, Maricella Alexandra Sinchiguano Vizuete en calidad de autor de la tesis realizada sobre el SISTEMA WEB DE INVENTARIOS Y FACTURACIN PARA EL CONTROL DE COMPONENTES Y SISTEMA AUTOMTICOS CONTAMATIC CIA.LTDA por la presente autorizo a la UNIVERSIDAD CENTRAL DEL ECUADOR, hacer uso de todos los contenidos que pertenecen o de parte de los que contiene esta obra, con fines estrictamente acadmicos o de investigacin.

Los derechos que como autor me corresponde, con excepcin de la presente

autorizacin, seguirn vigentes a mi favor, de conformidad con lo establecido con los artculos 5, 6, 8, 19 y dems pertinente de la Ley de Propiedad Intelectual y su Reglamento.

Quito 9 de Septiembre del 2013

Maricella Alexandra Sinchiguano Vizuete

CI: 1719482224


v

CERTIFICACIN

En calidad de Tutor del proyecto de investigacin: SISTEMA WEB DE INVENTARIOS Y FACTURACIN PARA EL CONTROL DE COMPONENTES Y SISTEMAS AUTOMTICOS CONTAMATIC CIA.LTDA presentado y desarrollado por Maricella Alexandra Sinchiguano Vizuete, previo la obtencin del Ttulo de Ingeniero Informtico, considero que el proyecto rene los requisitos necesarios.

En la ciudad de Quito, a los 11 das del mes de Septiembre del 2013


vi


vii


viii

CONTENIDO DEDICATORIA ............................................................................................... ii

AGRADECIMIENTO ..................................................................................... iii

AUTORIZACIN DE AUDITORA INTELECTUAL ................................... iv CERTIFICACIN .............................................................................................v RESUMEN .....................................................................................................xiv

ABSTRACT .................................................................................................... xv

CAPITULO 1 .................................................................................................. 16 1. PRESENTACIN DEL PROBLEMA ............................................................. 16

1.1. Planteamiento del problema ...................................................................... 16 1.2. Formulacin del problema ........................................................................ 16 1.3. Interrogantes de la Investigacin ............................................................... 17

1.4. Objetivos de la Investigacin ........................................................................ 17 1.4.1. Objetivo General ............................................................................... 17 1.4.2. Objetivos Especficos ........................................................................ 17

1.5. Alcance y Limitaciones para cada uno de los Mdulos ................................. 18 1.5.1. Mdulo Sistema Administrativo ............................................................... 18 1.5.2. Mdulo del Sistema de Ingresos ............................................................... 19 1.5.3. Modulo del Sistema de Egresos ................................................................ 19 1.5.4. Mtodos de Valoracin de Inventarios ...................................................... 20 1.5.5. Mdulo de Facturacin ............................................................................. 20 1.6. Justificacin e Importancia ........................................................................... 21

Comparacin entre Herramientas de Desarrollo aplicadas en la tesis. .................. 22 CAPTULO 2 .................................................................................................. 23

1. REVISN BIBLIOGRFICA ......................................................................... 23 1.2. Antecedentes ............................................................................................ 23

1.3. Marco Terico .......................................................................................... 23

2. Metodologa de Desarrollo ............................................................................... 23

2.1. Mtrica ..................................................................................................... 23

2.2. Modelo de Desarrollo ............................................................................... 25 2.3. Diagramas UML Modelamiento de la Base de Datos. ............................... 28


ix

2.4. Simbologa para realizar los casos de uso .................................................. 28

2.5. Diagramas de Secuencia ........................................................................... 29 2.6. Herramientas de desarrollo ....................................................................... 29

CAPTULO 3 .................................................................................................. 36 3. METODOLOGA ............................................................................................ 36

3.1. Diseo de la investigacin ........................................................................ 36 3.2. Diseo experimental ................................................................................. 36 3.3. Metodologa RUP ..................................................................................... 37

3.4. Metodologa de Desarrollo ........................................................................ 39 3.4.1. Modelo en Espiral .............................................................................. 39

3.5. Arquitectura de Aplicacin ....................................................................... 40 3.5.1. Ventajas de MVC .............................................................................. 43 CAPTULO 4 .................................................................................................. 44

4.1. FASE DE INICIO (METODOLOGIA RUP) DIAGRAMACIN DEL SISTEMA ................................................................... 44

Diagramas UML .............................................................................................. 44

Desarrollo del modelado del negocio ............................................................... 44

Introduccin .................................................................................................... 45 Propsito del Documento ................................................................................. 45 Diagramas de casos de uso ............................................................................... 45 Reglas de Negocio - INVENTARIOS DE CASOS DE USO ............................ 46

Requerimientos Funcionales ................................................................................... 47

4.1.1. Caso de uso: Administrador, Usuario - Ingreso al sistema. ................ 47

4.1.2. Caso de uso: Administrador - Creacin del Usuario. .......................... 49 4.1.3. Caso de uso: Administrador Modificar usuario. .............................. 52 4.1.4. Caso de Uso: Administrador - Eliminar usuario ............................... 54 4.1.5. Caso de Uso: Administrador - Creacin de un Componente Electrnico ...................................................................................................... 56 4.1.6. Caso de Uso: Administrador - Modificacin de un Componente Electrnico ...................................................................................................... 59

4.1.7. Caso de Uso: Administrador - Compra de un Componente Electrnico ...62 4.1.8. Caso de Uso: Administrador - Venta de un Componente Electrnico ...65 4.1.9. Caso de Uso: Administrador - Creacin de Clientes ......................... 68


x

4.1.10. Caso de Uso: Administrador - Carga Masiva ................................ 70

4.2. FASE DE ELABORACION ..................................................................... 71

4.3. FASE DE CONSTRUCCIN ................................................................... 73 CAPTULO 5 .................................................................................................. 74

5. FASE DE TRANSICION ................................................................................ 74 INSTALACION DE HERRAMIENTAS ................................................................ 74

SISTEMA OPERATIVO .................................................................................... 74

LENGUAJE DE PROGRAMACION .................................................................. 74

BASE DE DATOS .............................................................................................. 74

AMBIENTE DE DESARROLLO ....................................................................... 74

5.1. POSTGRESQL ......................................................................................... 74 5.2. ECLIPSE .................................................................................................. 85 5.3. JDK .......................................................................................................... 86 5.4. JBOSS ...................................................................................................... 87

CONCLUSIONES ........................................................................................... 95 RECOMENDACIONES .................................................................................. 96 GLOSARIO DE TERMINOS .......................................................................... 97 BIBLIOGRAFIA ........................................................................................... 103

MANUAL DE USUARIO ............................................................................. 105 INTRODUCCION ......................................................................................... 106 OBJETIVO .................................................................................................... 106

3. Ingreso al sistema: ...................................................................................... 106 4. ADMINISTRADOR .................................................................................. 107

2.1.1. Usuarios .......................................................................................... 108

2.1.2. Perfiles ............................................................................................ 109 2.1.3. Opciones ......................................................................................... 110

2.1.4. Perfil Opcin ................................................................................... 111

5. INVENTARIOS ......................................................................................... 112 3.1.1. Unidad ............................................................................................. 113

3.1.2. Artculos .......................................................................................... 113

3.1.3. Ingresos ........................................................................................... 115 3.1.4. Actualizar Precios ............................................................................ 116

6. Reportes Inventarios ................................................................................... 116


xi

7. FACTURACIN ....................................................................................... 118 5.1.1. Clientes ................................................................................................ 118 5.1.2. Ventas ............................................................................................. 119 5.1.3. Reportes .......................................................................................... 121 MANUAL TCNICO .................................................................................... 123 Introduccin .................................................................................................. 124

1.1 Cdigo Fuente ........................................................................................ 124

2.1 Cdigo WAR .......................................................................................... 127

Diccionario de Datos ..................................................................................... 128


xii

LISTA DE FIGURAS

Fig. 1 Ciclo de vida del Software22

Fig. 2 Actor.27

Fig. 3 Arquitectura Postgresql31

Figura 4 Fases de Metodologa RUP .37

Fig. 5 Modelo Vista Controlador39

Fig. 4.1 Modelado del Negocio...45 Fig. 4.1.1 Casos de Uso Ingreso al Sistema46

Fig. 4.1.1 Casos de Uso Ingreso al Sistema Tabla..47

Fig. 4.1.2 Creacin de Usuarios.48

Fig. 4.1.2 Casos de Uso Creacin Usuarios Tabla.49

Fig. 4.1.3 Modificacin de Usuarios 50

Fig. 4.1.3 Casos de Uso Modificacin Usuarios Tabla..51

Fig. 4.1.4 Eliminacin de Usuarios52

Fig. 4.1.4 Casos de Uso Eliminacin Usuarios Tabla53

Fig. 4.1.5 Creacin de Componentes 54

Fig. 4.1.5 Casos de Creacin de Componentes Tabla55

Fig. 4.1.6 Modificacin de Componentes..56

Fig. 4.1.6 Casos de Modificacin de Componentes Tabla.57

Fig. 4.1.7 Compra de Componentes58

Fig. 4.1.7 Casos de Compra de Componentes Tabla..59

Fig. 4.1.8 Venta de Componentes..60


xiii

Fig. 4.1.8 Casos de Venta de Componentes Tabla..61

Fig. 4.1.9 Creacin de Clientes..62

Fig. 4.1.9 Casos de Creacin de Clientes Tabla.63

Fig. 4.1.10 Carga Masiva..64

Fig. 4.1.10 Casos de Carga Masiva Tabla.65

Fig. 6 Tabla de Comparacin72

Fig. 7 Interaccin con el Cliente..74

LISTA DE TABLAS

Tabla 1 Compracion entre Java y C#...................................................................21

Tabla.4.1.6. Actores y Acciones Principales...46

Tabla 4.2. Inventarios de casos de uso.48


xiv

RESUMEN

SISTEMA WEB DE INVENTARIOS Y FACTURACIN PARA EL CONTROL DE COMPONENTES Y SISTEMAS AUTOMTICOS CONTAMATIC CIA.LTDA

El presente proyecto muestra la importancia del desarrollo en software libre del

mdulo de INVENTARIOS Y FACTURACION PARA EL CONTROL DE COMPONENTES Y SISTEMAS AUTOMTICOS (CONTAMATIC), este desarrollo se encarga de generar reportes de los componentes electrnicos ya sea para su Venta o Ingreso.

El objetivo principal de este software es interactuar las caractersticas de los componentes con sus imgenes de esta manera ayudar al usuario a manejar rpidamente las ventas con sus Clientes.

DESCRIPTORES

SISTEMA WEB DE INVENTARIOS/ACTURACIN PARA EL CONTROL DE COMPONENTES Y SISTEMAS AUTOMTICOS CONTAMATIC CIA.LTDA/UML/SOFTWARE LIBRE


xv

ABSTRACT

WEB INVENTORY SYSTEM AND BILLING FOR CONTROL OF AUTOMATED SYSTEMS AND COMPONENTS CONTAMATIC CIA.LTDA

This project shows the importance of free software development module INVENTORIES AND BILLING FOR CONTROL OF AUTOMATED SYSTEMS AND COMPONENTS (CONTAMATIC), this development is responsible for generating reports electronic components either for sale or Join.

The main purpose of this software is to interact the characteristics of the components

with their images this way help the user quickly handle sales with their customers.

DESCRIPTORS

WEB SYSTEM INVENTORY / ACTURACIN CONTROL COMPONENTS AND SYSTEMS AUTOMATIC CONTAMATIC CIA.LTDA / UML / SOFTWARE FREE


16

CAPITULO 1

1. PRESENTACIN DEL PROBLEMA

1.1.Planteamiento del problema

La empresa ContaMatic Ca. Ltda. al distribuir gran cantidad de componentes elctricos para la venta requiere de un sistema de inventarios y facturacin que sea

rpido y de fcil utilizacin pues la caracterstica de los componentes implica mantener informacin extensa de cada uno debido a su semejanza.

Al mantener un inventario y facturacin manualmente se requiere de un sistema gil el cual pueda manejar gran cantidad de productos y emitir reportes a la fecha o con fechas anteriores los mismos que se podrn visualizar en la web para su fcil comercializacin.

Al implementar el sistema dentro de la Compaa se podrn obtener varias ventajas, entre las cuales se mencionan:

La capacidad de procesar rpidamente grandes cantidades de datos, lo que no

puede ser llevado a cabo eficazmente por medios manuales.

Tener un control ms detallado de los componentes que pertenecen a la

compaa como controladores entre otros.

Controlar oportunamente la comercializacin de componentes mediante

reportes que ayuden a identificar y establecer la informacin de los componentes de acuerdo a las necesidades de la compaa que se definirn despus de realizar la toma de requerimientos y aprobacin de los mismos,

por ejemplo: ingreso de los componentes, registrar su descripcin y otros atributos de esta manera la institucin maneja control de inventario.

1.2.Formulacin del problema

De acuerdo a lo explicado anteriormente se logra evidenciar la necesidad de la empresa en organizar y clasificar los componentes incrementando su nivel de conocimiento de la informacin en cuanto al uso, ingreso y salida.


17

Con el sistema de inventarios y facturacin se obtendrn respuestas oportunas a los problemas descritos, generando conocimiento que permita dar seguimiento a diferentes movimientos que estn sujetos los conocimientos.

1.3.Interrogantes de la Investigacin

La presente tesis nace de la observacin de los problemas que se suscitan dentro del rea de trabajo, limitando la productividad del usuario, ya que an se realiza la manipulacin de la informacin lo que no permite la gestin de conocimiento.

Dentro de la investigacin se desea contestar las siguientes interrogantes:

De qu manera la propuesta del Sistema Web de Inventarios y Facturacin, favorecer a ContaMatic?

Qu tcnicas y mtodos se utilizarn en el desarrollo del sistema para la obtencin de conocimiento?

Cules herramientas de software se adaptan mejor a las necesidades de la empresa?

Cmo la creacin de un sistema de control de uso de bienes podr mejorar la organizacin de la empresa?

1.4.Objetivos de la Investigacin 1.4.1. Objetivo General

Desarrollar un software que permita la administracin de perfiles e inventarios y facturacin mediante una pgina web que nos facilitar de manera interactiva

manipular los artculos electrnicos; al igual que poder obtener las caractersticas de cada uno de los mencionados.

1.4.2. Objetivos Especficos Se realizara una actualizacin masiva de los precios de los artculos

electrnicos, habilitando un campo para ingresar el porcentaje que se calcular en cada uno de ellos.

Se har un rollback en la base en el caso que los artculos no sean actualizados de manera correcta.


18

Manejo de perfiles que permitan el ingreso al sistema y a sus aplicaciones. Manejo de Reportes tanto para Ingresos, Egresos y Kardex de los

componentes electrnicos.

Generar los reportes de los componentes electrnicos basndose en la

plantilla pedida por el Cliente.

1.5.Alcance y Limitaciones para cada uno de los Mdulos

De los objetivos planteados dentro de la investigacin podemos decir que el alcance del proyecto se establece de la siguiente manera:

1.5.1. Mdulo Sistema Administrativo

En un inicio contamos con 2 perfiles uno para el administrador y otro para el usuario encargado de manejar la contabilidad.

Este nos permite la creacin de usuarios y perfiles de acuerdo al manejo del sistema, contara de dos perfiles tanto para administrador como para la persona encargada de manejar la contabilidad.

Ingreso al Sistema: Al ingresar al sistema, se desplegara una pantalla la cual consta de dos campos

Usuario

Password.

Los campos antes mencionados una de sus caractersticas ser que el password estar encriptado en la base de datos.

Manejo de perfiles: Los perfiles se manejaran de acuerdo a lo acordado con el administrador.

Las caractersticas de los componentes sern:

Cdigo del componente

Nombre

Descripcin

Fecha Ingreso


19

Precio Manejo de inventario ( PEPS) Cantidad Mxima

Cantidad Mnimo

Cantidad Actual

1.5.2. Mdulo del Sistema de Ingresos

Ingresos: Se puede hacer referencia a las cantidades que recibe una empresa por la venta de sus productos o servicios.

El mdulo de Ingresos definir las caractersticas de cada componente, es decir constara de:


Nombre

Descripcin

PrecioManejo de Inventario(PEPS)

Fecha de Ingreso

Fecha de salida

Cantidad

Los atributos estn tomados de acuerdo a los requerimientos establecidos por el usuario.

1.5.3. Modulo del Sistema de Egresos

En esta opcin permite el registro de las salidas de los componentes, adicionalmente en la funcin de salida se har una validacin indicando si lo solicitado es mayor a lo registrado emitir un mensaje Indicando que no existe esa cantidad de componentes.

Adicionalmente el momento de calcular el stock se tom en cuenta que el precio de los componentes puede variar de acuerdo a lo que se adquiera en los diferentes meses u aos, por lo tanto se va a manejar el Stock ocupando la Metodologa PEPS.


20


Nombre

Descripcin

PrecioManejo de Inventario(PEPS)

Fecha de salida

Cantidad

1.5.4. Mtodos de Valoracin de Inventarios El mtodo que se va a usar es PEPS, ya que se pudo determinar que es una de las opciones ms ptimas tomando en cuenta la forma de manejo del inventario.

La tcnica a utilizar aplica una base especfica para evaluar los inventarios en trminos monetarios. La valuacin de inventarios es un proceso vital cuando los precios unitarios de adquisicin han sido diferentes.

Comnmente conocido como FIFO (First In, First Out), este mtodo de valoracin de inventarios se basa en la interpretacin lgica del movimiento de las unidades en el sistema de inventario, por ende el costo de las ltimas compras es el costo de las existencias.

La ventaja de aplicar esta tcnica consiste en que los inventarios estn valorados con los costos ms recientes, dado que los costos ms antiguos son los que van conformando a su medida los primeros costos de ventas o de produccin (costos de salidas). La principal desventaja de aplicar esta tcnica radica en que los costos de produccin y ventas bajos que suele mostrar, incrementa lgicamente las utilidades, generando as un mayor impuesto.

1.5.5. Mdulo de Facturacin En este mdulo se obtendr un reporte con los datos principales de la factura el cual se emitir al final de la compra.

Permitir la exploracin automtica, visualizacin y comprensin de los

datos e identificar patrones, relaciones y dependencias que impactan en los resultados finales, tales como el aumento de los ingresos.


21

De igual manera se ha determinado que se debe considerar las siguientes limitaciones:

El sistema no verificar la cantidad de usuarios que visitan las diferentes exposiciones de la empresa, ni los componentes ms visitados.

Para la facturacin se consultara los datos del cliente el cual debe estar previamente registrado en la base.

Los productos que forman parte del detalle de la factura debern estar previamente registrados en el mdulo de inventario.

Se podr aplicar o no descuentos al total de la factura y a los productos y/o

servicios de forma individual.

Restricciones

No se podr realizar un cierre de inventario cuando otro est abierto.

No se podr hacer cierres de inventario mayores a la fecha actual.

No se realizarn Backup de la base de Datos.

1.6.Justificacin e Importancia

La compaa ContaMatic requiere de un sistema de facturacin y de Inventarios que permita obtener informacin de los componentes de una manera rpida y eficiente ya

que la compaa posee un software que no procesa de manera eficaz la informacin.

ContaMatic en calidad de cliente nos ha reiterado que necesita un software fcil de entender y manejar para poder llevar mejor la estabilidad de la empresa.

La realizacin de la aplicacin es importante, ya que en la actualidad el poder contar con un inventario actualizado ayuda a llevar el control de los componentes evitando prdidas y daos.


22

Con la implementacin del sistema la empresa tendr una mejor organizacin interna dentro de sus procesos de inventarios y se ver reflejada en el trabajo diario, con la generacin de informes que permitirn llevar el control de los componentes correspondientes, as como verificar el flujo de cada uno.

Comparacin entre Herramientas de Desarrollo aplicadas en la tesis.

Se desarroll el siguiente cuadro comparativo tomando en consideracin las

caractersticas ms relevantes de cada uno de los IDEs:

Ttulo: Comparacin entre Java y C# Autor: Junta de Castilla y Len

Fuente (http://zarza.usal.es/~fgarcia/doc/tuto2/I_4.htm) Tabla 1


23

CAPTULO 2

1. REVISN BIBLIOGRFICA

1.2. Antecedentes

El uso de inventarios es una actividad muy difcil de realizar y ms aun con sistemas

manuales, con el avance de la informtica esta situacin ha venido mejorando cada da, pero solo el contar con un sistema que organice esta informacin en una base de datos no es suficiente ya que dentro de esta se guarda informacin oculta muy fundamental para mejorar la productividad en las empresas.

En la actualidad el advenimiento de nuevas tecnologas y el desarrollo de Internet hace que esta actividad ya no se la realice solo en el lugar de trabajo, con la aparicin de tcnicas de Minera de Datos, anlisis estadstico, cubos de informacin entre otras herramientas que permiten descubrir informacin importante dentro de las bases de datos.

En el nuevo mundo tecnolgico, la potencia de los equipos informticos y el desarrollo de software han permitido la creacin de grandes bases de datos de

clientes, en las que la empresa puede registrar todas las operaciones que estos realizan. Toda la informacin es almacenada en grandes bases de datos.

1.3. Marco Terico

El desarrollo de la aplicacin para la empresa ContaMatic integra en un nico

sistema todos los procesos de negocio que se necesitan para el control del inventario y facturacin.

Adicionalmente se pretende que todos los datos estn actualizados y disponibles en cualquier momento para poder brindar un mejor servicio a todos los usuarios que utilizan sus servicios.

2. Metodologa de Desarrollo

2.1.Mtrica


24

Metodologa estructurada en fases, mdulos, actividades, tareas para el desarrollo del sistema; productos obtenidos en cada tarea.1

Se enfoca directamente en el desarrollo.

Consta de las siguientes fases en el desarrollo del proyecto:

Fig.1 Ttulo: Ciclo de Vida del Software

Autor: Carlos Barbosa y Karime Beltran Fuente (http://ciclosoftware.wordpress.com/)

1. Anlisis de Sistemas.- Determina los objetivos y lmites del Sistema objeto de anlisis, caracteriza su estructura y funcionamiento. Permite alcanzar los

objetivos propuestos, es decir conseguir la comprensin detallada de los requerimientos primordiales para desarrollar un producto de software correcto y de fcil mantenimiento.

2. Diseo de Sistemas.- Implementa todos los requisitos explcitos contenidos en el modelo de anlisis y debe acumular todos los requisitos que desea el

cliente.

La importancia del diseo de software se define con la palabra CALIDAD.

Se debe cumplir con ciertas etapas del diseo:

Diseo de los Datos

Diseo Arquitectnico

1 http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/capitulo7.pdf


25

Diseo de Interfaz2

Diseo de Procedimientos

3. Construccin de Sistemas.- Es la implementacin de un lenguaje de programacin para crear las funciones definidas durante la etapa de diseo.

Adems se realiza pruebas de unidad es decir se realiza una prueba individual de cada subconjunto de la aplicacin para garantizar que se implementaron de acuerdo con las especificaciones.

4. Implantacin de Sistemas.- Se presenta el software al cliente, el orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicacin dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores.

2.2.Modelo de Desarrollo

Para realizar el desarrollo del software se utilizar el Modelo Espiral, es un modelo meta del ciclo de vida del software donde el esfuerzo del desarrollo es iterativo, tan pronto culmina un esfuerzo del desarrollo por ah mismo comienza otro; adems en

cada ejecucin del desarrollo se sigue cuatro pasos principales:

Determinar o fijar los objetivos.

En este paso se definen los objetivos especficos para posteriormente identificar las limitaciones del proceso y del sistema de software, adems se disea una planificacin detallada de gestin y se identifican los riesgos.

Anlisis del riesgo. En este paso se efecta un anlisis detallado para cada uno de los riesgos identificados del proyecto, se definen los pasos a seguir para reducir los riesgos y

luego del anlisis de estos riesgos se planean estrategias alternativas.

2 http://es.wikipedia.org/wiki/M%C3%A9trica_del_software


26

Desarrollar, verificar y validar. En este tercer paso, despus del anlisis de riesgo, se eligen un paradigma para el

desarrollo del sistema de software y se lo desarrolla.

Planificar. En este ltimo paso es donde el proyecto se revisa y se toma la decisin si se debe continuar con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan

los planes para la siguiente fase del proyecto

Con cada iteracin alrededor de la espiral, se crean sucesivas versiones del software, cada vez ms completas y, al final, el sistema de software ya queda totalmente funcional.

Adems es considerado como un modelo evolutivo ya que combina el modelo clsico con el diseo de prototipos.

El modelo en espiral esta compartida en varias actividades estructurales, tambin

llamadas regiones de tareas. Existen seis regiones de tareas que son:

Comunicacin con el cliente Esta es una tarea requerida para establecer comunicacin entre el desarrollador y el

cliente.

Planificacin Esta tarea es necesaria aplicarla para poder definir los recursos, el tiempo y otras informaciones relacionadas con el proyecto, es decir, son todos los requerimientos.

Anlisis de riesgos Esta es una de las tareas principales por lo que se aplica el modelo en espiral, es requerida para evaluar los riesgos tcnicos y otras informaciones relacionadas con el

proyecto.


27

Ingeniera Esta es una tarea necesaria ya que se requiere construir una o ms representaciones

de la aplicacin. 3

Construccin y adaptacin Esta tarea es requerida en el modelo espiral porque se necesita construir, probar, instalar y proporcionar soporte al usuario.

Evaluacin el cliente: Esta tambin es una tarea principal, necesaria para adquirir la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de

ingeniera y la de implementacin creada durante la etapa de instalacin.

Ventajas y Desventajas del Modelo Espiral

No requiere una definicin completa de los requerimientos del software a desarrollar para comenzar su funcionalidad.

En la terminacin de un producto desde el final de la primera iteracin es muy factible aprobar los requisitos.

Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos presentados tempranamente y existe la forma de poder corregirlos a tiempo.

Desventajas

Existe complicacin cuando se evala los riesgos.

Se requiere la participacin continua por parte del cliente.

Se pierde tiempo al volver producir inicialmente una especificacin completa de los requerimientos cuando se modifica o mejora el software

3 http://es.wikipedia.org/wiki/Desarrollo_en_espiral


28

2.3.Diagramas UML Modelamiento de la Base de Datos.

Lenguaje Unificado de Modelado.- Especifica una notacin estandarizada para diagramas de estado que se utiliza para describir clases, sistemas, subsistemas o

incluso procesos de negocio. 4

Los elementos bsicos de notacin que se usan para componer un diagrama son:

Circulo Lleno: Nos indica un estado Inicial. Crculo Hueco: que contiene un circulo lleno ms pequeo en el interior indicando el estado final (si existiera). Rectngulo Redondeado: denotando un estado. En la parte superior del rectngulo est el nombre del estado. Puede contener una lnea horizontal en la

mitad debajo de la cual se indican las actividades que se hacen en el estado.

2.4.Simbologa para realizar los casos de uso

Un caso de uso es una descripcin de los pasos o las actividades que debern realizarse para llevar a cabo algn proceso. Los personajes o entidades que participarn en un caso de uso se denominan actores

Los elementos que pueden aparecer en un diagrama de casos de uso son: actores, casos de uso y relaciones entre casos de uso

Actores: Un actor es una entidad externa al sistema que realiza algn tipo de interaccin con el mismo. Se representa mediante una figura humana.

Fig. 2 Ttulo: Actor

Autor: Maricella Sinchiguano Fuente: a Fundacin Wikipedia, Inc.

Casos de uso: Es una descripcin de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea

4 http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado


29

especfica, expresa una unidad coherente de funcionalidad, y se representa en el diagrama de casos de uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea especfica que el actor desea llevar a cabo usando el sistema

Un caso de uso debe:

describir una tarea del negocio que sirva a una meta de negocio

tener un nivel apropiado del detalle ser bastante sencillo como que un desarrollador lo elabore en un nico

lanzamiento

2.5. Diagramas de Secuencia

El diagrama de secuencia es un tipo de diagrama usado para modelar interaccin entre objetos en un sistema.

Muestra la interaccin de un conjunto de objetos en una aplicacin a travs del tiempo y se modela para cada caso de uso.

Ata los casos de uso con objetos y muestra como el comportamiento de un caso de uso es distribuido dentro de los objetos participantes.

Por lo general no es un buen medio de comunicacin con los Usuarios

Ofrece otra perspectiva y permite a los desarrolladores encontrar objetos perdidos y otros aspectos no definidos en la especificacin del sistema.

2.6.Herramientas de desarrollo

Java eclipse Es un entorno de desarrollo integrado de cdigo abierto multiplataforma para desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido", opuesto a las aplicaciones "Cliente-liviano" basadas en navegadores.


30

Esta plataforma, tpicamente ha sido usada para desarrollar entornos de desarrollo integrados (del ingls 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 tambin para desarrollar el mismo Eclipse).5

Eclipse provee al programador con framework muy ricos para el desarrollo de

aplicaciones grficas, definicin y manipulacin de modelos de software, aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing Framework - Framework para la edicin grfica) es un plugin de Eclipse para el desarrollo de editores visuales que pueden ir desde procesadores de texto wysiwyg hasta editores de diagramas

UML, interfaces grficas para el usuario (GUI), etc.

Dado que los editores realizados con GEF "viven" dentro de Eclipse, adems de poder ser usados conjuntamente con otros plugins, hacen uso de su interfaz grfica personalizable y profesional.

Caractersticas

Eclipse dispone de un Editor de texto con resaltado de sintaxis. La compilacin es en tiempo real. Tiene pruebas unitarias con JUnit, control de versiones con CVS, integracin con Ant, asistentes (wizards) para creacin de proyectos, clases, tests, etc., y refactorizacin

Ant es una herramienta usada en programacin para la realizacin de tareas mecnicas y repetitivas, normalmente durante la fase de compilacin y construccin (build). Es, por tanto, un software para procesos de automatizacin de compilacin, similar a Make pero desarrollado en lenguaje Java y requiere la plataforma Java, as que es ms apropiado para la construccin de proyectos Java.

Esta herramienta, hecha en el lenguaje de programacin Java, tiene la ventaja de no depender de las rdenes del shell de cada sistema operativo, sino que se basa en

archivos de configuracin XML y clases Java para la realizacin de las distintas tareas, siendo idnea como solucin multi-plataforma.

5 http://es.wikipedia.org/wiki/Eclipse


31

Capa Presentacin

Componente PrimeFaces

PrimeFaces es un componente para Java Server Faces (JSF) de cdigo abierto que cuenta con un conjunto de componentes ricos que facilitan la creacin de las aplicaciones web. 6

Prime faces est bajo la licencia de Apache License V2. Una de las ventajas de utilizar Prime faces, es que permite la integracin con otros componentes como por

ejemplo RichFaces.

Las principales caractersticas de Prime faces son:

Soporte nativo de Ajax, incluyendo Push/Comet. Kit para crear aplicaciones web para mviles.

Uso de JavaScript no intrusivo (no aparece en lnea dentro de los elementos, sino dentro de un bloque ).

Es un proyecto open Source, activo y bastante estable entre versiones.

Algunos inconvenientes podran ser:

Para utilizar el soporte de Ajax tenemos que indicarlo explcitamente, por medio de atributos especficos de cada componente.

no podemos utilizar el soporte de Ajax de JSF 2 (mediante ) con los componentes de Prime faces.

Capa Aplicacin JBoss JBoss es un servidor de aplicaciones J2EE de cdigo abierto implementado en Java puro. Al estar basado en Java, JBoss puede ser utilizado en cualquier sistema

operativo que lo soporte. JBoss Inc., adquirida por Red Hat en Abril del 2006, implementa todo el paquete de servicios de J2EE.

6 http://www.primefaces.org/showcase/ui/home.jsf


32

Beneficios

El servidor de aplicaciones puede manejar transacciones, la seguridad, escalabilidad, concurrencia y gestin de los componentes desplegados, significando que los desarrolladores pueden concentrarse ms en la lgica de negocio de los componentes

en lugar de en tareas de mantenimiento de bajo nivel.

Las caractersticas de JBoss incluyen:

Producto de licencia de cdigo abierto sin coste adicional.

Cumple los estndares. Confiable a nivel de empresa

Incrustable, orientado a arquitectura de servicios. Flexibilidad consistente Servicios del middleware para cualquier objeto de Java Ayuda profesional 24x7 de la fuente Soporte completo para JMX

Estructura

La Estructura fundamental de JBOSS es la siguiente:

a) bin

Este directorio contiene los ejecutables utilizados por JBOSS, siendo el ms importante el "script" de arranque utilizado por ste (run.sh).

b) client

Contiene los diversos archivos JAR's que sern utilizados por los distintos clientes de

los EJB's utilizados en JBOSS. Dichos archivos deben ser agregados a la variable CLASSPATH del sistema donde radica el cliente.

c) server

Este directorio contiene tres sub-directorios nombrados: all, default y minimal; cada sub-directorio contiene los distintos archivos de configuracin necesarios para

ejecutar JBOSS en diferentes modalidades. La ejecucin de JBOSS es relativamente sencilla, dentro del directorio bin de la instalacin de JBOSS se encuentran los


33

archivos de arranque en forma de "scripts" para Shell. El archivo de ejecucin run.shinicia JBOSS con los parmetros encontrados en el directorio server/default/conf.7

JBoss Enterprise Application Platform es una alternativa de cdigo abierto perfecta para la construccin, despliegue y ejecucin de Aplicaciones y Servicios Java para empresas. JBoss Enterprise Application Platform integra un servidor de aplicaciones Java EE con soporte de clster, persistencia de objetos/datos relacionales y un poderoso framework para crear aplicaciones Web 2.0 de prxima generacin, en una nica distribucin.

Hibernate

Es un servicio de persistencia objeto/relaciones y consultas para Java. Hibernate facilita a los desarrolladores crear las clases de persistencia utilizando el lenguaje Java - incluyendo la asociacin, herencia, polimorfismo y composicin y el entorno

de colecciones Java.

Capa Datos:

Base PostgreSQL

PostgreSQL es un sistema de gestin de bases de datos objeto-relacional, distribuido bajo licencia BSD y con su cdigo fuente disponible libremente. Es el sistema de gestin de bases de datos de cdigo abierto ms potente del mercado y en sus ltimas versiones no tiene nada que envidiarle a otras bases de datos comerciales.

PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de multihilos para garantizar la estabilidad del sistema. Un fallo en uno de los procesos no afectar el resto y el sistema continuar funcionando.

7 http://es.wikipedia.org/wiki/PostgreSQL


34

Fig.3 Titulo: Arquitectura Postgresql

Autor: Creative Commons Fuente: http://www.postgresql.org.es/sobre_postgresql

Aplicacin cliente: Esta es la aplicacin cliente que utiliza PostgreSQL como administrador de bases de datos. La conexin puede ocurrir va TCP/IP o sockets locales.

Demonio postmaster: Este es el proceso principal de PostgreSQL. Es el encargado de escuchar por un puerto/socket por conexiones entrantes de clientes. Tambin es el encargado de crear los procesos hijos que se encargaran de autentificar estas peticiones, gestionar las consultas y mandar los resultados a las aplicaciones clientes

Ficheros de configuracin: Los 3 ficheros principales de configuracin

utilizados por PostgreSQL, postgresql.conf, pg_hba.conf y pg_ident.conf Procesos hijos postgres: Procesos hijos que se encargan de autentificar a los

clientes, de gestionar las consultas y mandar los resultados a las aplicaciones clientes

PostgreSQL share buffer cache: Memoria compartida usada por PostgreSQL para almacenar datos en cach.

Write-Ahead Log (WAL): Componente del sistema encargado de asegurar la integridad de los datos (recuperacin de tipo REDO)

Kernel disk buffer cache: Cach de disco del sistema operativo


35

Disco: Disco fsico donde se almacenan los datos y toda la informacin necesaria para que PostgreSQL funcione

Caractersticas

Sus caractersticas tcnicas la hacen una de las bases de datos ms potentes y robustas del mercado. Su desarrollo comenz hace ms de 16 aos, y durante este tiempo, estabilidad, potencia, robustez, facilidad de administracin e implementacin de estndares han sido las caractersticas que ms se han tenido en cuenta durante su desarrollo. PostgreSQL funciona muy bien con grandes cantidades de datos y una alta concurrencia de usuarios accediendo a la vez al sistema.


36

CAPTULO 3

3. METODOLOGA

3.1. Diseo de la investigacin

La tesis a realizarse necesita de las siguientes modalidades de investigacin:

Investigacin bibliogrfica.- que consiste en compilar datos valindose del manejo adecuado de libros, pginas Web, resultados de otras investigaciones, etc., por tal razn se usar para construir el marco cientfico y adems para elaborar la propuesta de la presente tesis.

En lo que tiene que ver con la investigacin de campo.- es aquella que se realiza en el mismo lugar en que se desarrolla o produce los acontecimientos, en contacto directo con quien o quienes son gestores del problema que se investiga. Aqu se obtiene la informacin de primera mano en forma directa sin tener el control absoluto

de las variables, que permite obtener datos veraces de las tcnicas de manipulacin y procesamiento de informacin que se implementan en la unidad de trabajo y con ellos establecer el diagnstico situacional general e individual de la productividad de los usuarios dentro del proceso del manejo de informacin.

Finalmente se dir que todo este trabajo investigativo es una tesis factible, porque constituye una solucin al problema planteado.

3.2. Diseo experimental

Es la etapa ms crucial del desarrollo de un proyecto de software, ya que se divide en funcionales, condicin o capacidad de un sistema requerido por el usuario para resolver un problema o alcanzar un objetivo y no funcionales condicin o capacidad que debe poseer un sistema para satisfacer un contrato, un estndar, una especificacin u otro documento formalmente impuesto.

A menudo un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. El responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humanamquina, entonces es en este caso cuando utilizamos el


37

paradigma de construccin de prototipos, donde se inicia con la comunicacin las personas involucradas en el desarrollo ya sea cliente como programadores definen los requerimientos del software, en este punto se construir un primer prototipo y conforme va avanzando en las entrevistas se va evolucionando los prototipos a

medida que satisface las necesidades del cliente hasta llegar a una aplicacin estable.

El desarrollo de aplicacin mediante la utilizacin de este paradigma se puede resumir con las siguientes ventajas: no modifica el flujo del ciclo de vida, este modelo es til cuando el cliente conoce los objetivos generales para el software, ofrece un mejor enfoque, de la adaptabilidad de un sistema operativo, reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios, reduce costos e incrementa la probabilidad de xito.

Este paradigma tambin tiene sus desventajas ya que a los usuarios les gusta el sistema real y a los desarrolladores les gusta construir algo de inmediato. Sin embargo, la construccin de prototipos se torna problemtica por las siguientes razones: el cliente ve funcionando lo que para l es la primera versin del prototipo y puede decepcionarse al indicarle que el sistema an no ha sido construido, el

desarrollador puede caer en la tentacin de aumentar el prototipo para construir el sistema final sin tener en cuenta las obligaciones de calidad y de mantenimiento que

tiene con el cliente.

Este modelo es tambin denominado modelo de desarrollo evolutivo, para comprenderlo mejor comenzaremos con la definicin de los objetivos globales para el software, despus identificaremos los requerimientos que conocemos y los sitios del diseo en donde es necesaria ms definicin. Entonces planteamos con rapidez una iteracin de construccin de prototipos y se presenta el modelado, los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los ingenieros

de software desarrollen versiones cada vez ms completas del software.

3.3. Metodologa RUP

El Proceso de Desarrollo del Proyecto est basado en la Tcnica (RUP), es un proceso de ingeniera de software, que proporciona un enfoque disciplinado para

asignar tareas y responsabilidades dentro de una empresa.


38

El Proceso Unificado Racional, Rational Unified Process en ingls, y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a

objetos.

La meta es asegurar la produccin del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo establecidos.

El RUP no es un sistema con pasos firmemente establecidos, sino que trata de un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin, donde el software es organizado como una coleccin de unidades atmicas llamados objetos, constituidos por datos y funciones, que interactan entre s.

RUP es un proceso para el desarrollo de un proyecto de un software que define claramente quien, cmo, cundo y qu debe hacerse en el proyecto

Fig. 4 Ttulo: Fases de la metodologa RUP

Autor: Rolando Jaldn

Fuente: (http://rolandojaldin.blogspot.com/2010/10/introduccion-la-metodologia-rup-proceso.html)

RUP es explcito en la definicin de software y su trazabilidad, es decir, contempla en relacin causal de los programas creados desde los requerimientos hasta la

implementacin y pruebas.

RUP identifica claramente a los profesionales (actores) involucrados en el desarrollo del software y sus responsabilidades en cada una de las actividades.


39

3.4. Metodologa de Desarrollo

Modelo Ciclo de Vida en Espiral

Este es un proyecto que se desarrolla en el ciclo de vida en Espiral para la generacin de un software que cumpla con los requerimientos establecidos por el usuario para el manejo de inventarios en la empresa, adems con la implementacin de una tecnologa innovadora con la finalidad de cubrir todas las necesidades de la empresa.

3.4.1. Modelo en Espiral

Fase 1: PLANIFICACIN

(Determinar Objetivos)

Obtener toda la informacin posible sobre el requerimiento del Cliente.

Definir el resultado del proyecto y su papel en la estrategia global.

Determinar el tiempo y los recursos que se utilizaran en el proyecto.8

Fase 2: EVALUACIN

(Determinar la vialidad del proyecto)

Es un proyecto que se puede desarrollar?

Determinar cules son los posibles riesgos que se pueden presentar y las alternativas que se aplicaran.

Estudiar cuales son las limitaciones que pueden presentar el proyecto.

Conocer los requerimientos que debe satisfacer el sistema(funciones de contexto)

Fase 3: INGENIERA

(Desarrollo del Producto)

8 univafuadoo.files.wordpress.com/2008/10/modelo-de-espiral2.ppt


40

Diseo de un prototipo del producto final, donde cada aplicativo es de fcil manejo y con una interfaz amigable; que cumpla con las expectativas del usuario final.

Verificacin e implementacin de nuevas aplicaciones si as lo requiere el

Cliente. El producto se disea en fases que permiten la correlacin e

implementacin de nuevas aplicaciones solo en la fase que se requiera, sin necesidad de verificar todo el producto, tambin permite crear una fase,

probarla y luego avanzar a la siguiente.

Pruebas Tcnicas del prototipo terminado

Diseo en Detalle: Generar el producto o Servicio pretendido con el proyecto.

Fase 4: INSTALACIN DEL PRODUCTO

(Adecuacin del software en el lugar de trabajo)

Se instala el software y se hace seguimiento para determinar el funcionamiento correcto del mismo.

Mantenimiento preventivo y correctivo del producto.

3.5. Arquitectura de Aplicacin

El desarrollo del sistema se lo ha hecho en modelo de tres capas sistema MVC.9

El Modelo Vista Controlador (MVC) es un patrn de arquitectura de software que separa los datos de una aplicacin, la interfaz de usuario y la lgica de control, en tres componentes distintos.

9 http://www.lab.inf.uc3m.es/~a0080802/RAI/mvc.html


41

Fig. 5 Ttulo: Modelo Vista Controlador Autor: Blog de WordPress.com.

Fuente: http://prestashop5estrellas.wordpress.com/2010/03/29/el-patron-mvc-modelo-vista-controlador/

El patrn MVC se presenta frecuentemente en aplicaciones web, donde:

Controlador: Se puede decir que el controlador es el que dirige la aplicacin. Todas las peticiones

a la capa intermedia que se realicen desde el cliente son dirigidas al controlador.

El controlador es el responsable de recibir los eventos de entrada desde la vista.

Llama a la lgica de negocios para procesar y producir una respuesta.

Interpreta las entradas, informando al modelo y/o a la vista de los cambios que supongan esas entradas.

Hace que el desarrollo sea ms sencillo y limpio.

Facilita el posterior mantenimiento de la aplicacin hacindola ms escalable.

Facilita la deteccin de errores en el cdigo.

En aplicaciones J2EE el Controlador es implementado mediante un Servlet central

que, dependiendo de la cantidad de tipos de peticiones que debe gestionar, puede apoyarse de otros servlets auxiliares para procesar cada peticin.

Vista:

Las pginas JSP resultan mucho ms adecuadas para la generacin de las vistas de

los servlets.


42

Cuando la informacin que se va a enviar es esttica, es decir, no depende de datos extrados de un almacenamiento externo, podr ser implementada por una pgina o documento XHTML.

Es la encargada de generar las respuestas (XHTML) que deben ser enviadas al cliente. Cuando esta respuesta tiene que incluir datos proporcionados por el

Controlador, el cdigo XHTML de la pgina no ser fijo si no que deber ser generado de forma dinmica, por lo que su implementacin correr a cargo de una pgina JSP.

La vista gestiona la presentacin de la informacin de la aplicacin, todo lo relativo a la interfaz de usuario, los datos de que dispone para seguir

interactuando con la aplicacin.

Modelo:

En la arquitectura MVC la lgica de negocio de la aplicacin, incluyendo el acceso a los datos y su manipulacin, est encapsulada dentro del modelo. El Modelo lo forman una serie de componentes de negocio independientes del Controlador y la

Vista, permitiendo as su reutilizacin y el desacoplamiento entre las capas.

Representa a toda la informacin con la que opera la aplicacin.

Gestiona el comportamiento y los datos del dominio.

Responde a las peticiones de informacin sobre el estado que vienen de la

vista.

Es el sistema de gestin de base de datos y la lgica de negocio.

Responde a instrucciones de cambio de estado, provenientes del Controlador.

Esta arquitectura permite desarrollar software cuyo mantenimiento y perfeccionamiento son fciles de realizar.


43

3.5.1. Ventajas de MVC

Se presenta la misma informacin de distintas formas. Las vistas y comportamiento de una aplicacin deben reflejar las

manipulaciones de los datos de forma inmediata. Debera ser fcil cambiar la interfaz de usuario (incluso en tiempo de

ejecucin). Permitir diferentes estndares de interfaz de usuario o portarla a otros

entornos no debera afectar al cdigo de la aplicacin. Aplicaciones ms robustas debido al encapsulamiento Mantenimiento y soporte ms sencillo (es ms sencillo cambiar un

componente que modificar una aplicacin monoltica) Mayor flexibilidad (se pueden aadir nuevos mdulos para dotar al sistema

de nueva funcionalidad) Alta escalabilidad. La principal ventaja de una aplicacin distribuida bien

diseada es su buen escalado, es decir, que puede manejar muchas peticiones con el mismo rendimiento simplemente aadiendo ms hardware. El

crecimiento es casi lineal y no es necesario aadir ms cdigo para conseguir esta escalabilidad.


44

CAPTULO 4

4.1. FASE DE INICIO (METODOLOGIA RUP) DIAGRAMACIN DEL SISTEMA

Diagramas UML

Se incluirn todas las vistas de los diagramas de Anlisis presentes en la elaboracin del Sistema de Facturacin e Inventarios.

Casos de Uso

Diagramas de Secuencia

Desarrollo del modelado del negocio

Figura 4.1. Modelado del negocio Ttulo: Modelado del Negocio

Autor: Procesos Levantados en la empresa Fuente: Maricella Sinchiguano

REA DE GERENCIA

REA VENTAS

RECEPCION

CONTABILIDAD


45

Introduccin

El propsito de la construccin del software para la Facturacin e Inventarios de la empresa Contamatic consiste en generar modelos informticos, en base a las especificaciones funcionales validadas en las actividades de Anlisis.

Estos modelos servirn para entender mejor las especificaciones funcionales planteadas por el usuario.

Propsito del Documento

Identificar los riesgos y oportunidades del proyecto

Generar el diseo lgico de la solucin (segn aplique al tipo de proyecto) Modelo entidad relacin.

Diagramas de casos de uso

El diagrama de casos de uso representa la forma en cmo un cliente (actor) opera con el sistema en desarrollo.

Tambin nos permite verificar el tipo y orden en como los elementos interactan con cada una de las reas.

Actores Rol Acciones de cada Uno

Administrador (Gerente)

Manejo de perfiles para

habilitar el ingreso a ciertos

mdulos del aplicativo

Ingreso de Componentes

Modificacin de Componentes Realizar bsquedas de componentes mediante filtros Ejecucin de reportes Generacin de Facturas

Usuarios (Ventas -

Contabilidad -

Recepcin)

Personal que

tiene acceso

limitado a los

mdulos del aplicativo

Ingreso de Componentes con

autorizacin(Administrador) Buscar los componentes

Generacin de Reportes Generacin de Facturas

Tabla 4.1.6. Actores y acciones principales.

Ttulo: Tabla de Actores


46

Autor: Procesos Levantados en la empresa Fuente: Maricella Sinchiguano

Reglas de Negocio - INVENTARIOS DE CASOS DE USO

INVENTARIO DE CASOS DE USO La aplicacin debe validar el nivel de acceso de los usuarios por medio de perfiles ya sea

funcionario o administrador (gerente). Cdigo Caso de Uso Actores

CU-001 Ingreso al sistema Administrador, Usuarios

CU-002 Creacin de Usuarios Administrador

CU-003 Modificacin de Usuarios Administrador

CU-004 Eliminar Usuarios Administrador

CU-005 Crear Componente Administrador, Usuarios(Ventas, Contabilidad) CU-006 Modificacin de Componentes Administrador, Usuarios(Ventas, Contabilidad)

CU-007 Ingresos de Componentes

Administrador, Usuarios(Ventas, Contabilidad), Sistema

CU-008 Ventas de Componentes

Administrador, Usuarios(Ventas, Contabilidad) Sistema

CU-009 Creacin de Clientes Administrador, Usuarios

CU-010 Carga Masiva de Componentes Sistema

CU-011 Generacin de Reportes Facturas Administrador, Usuarios

Tabla 4.2. Inventario de casos de uso.

Ttulo: Modelado del Negocio Autor: Procesos Levantados en la empresa

Fuente: Maricella Sinchiguano


47

Requerimientos Funcionales

El sistema debe ser funcional al realizar el registro de los artculos y de los usuarios

quienes van a manejar el sistema.

Los administradores estarn encargados del control total sobre la informacin de desarrollo del sistema, cabe destacar que esta informacin tiene campos delicados para acceso de cualquier usuario.

Los contadores tendrn el control total sobre la informacin de Facturacin,

Inventarios y reportes del sistema.

A continuacin vamos a detallar los casos de uso que intervienen en el levantamiento de los requerimientos.

4.1.1. Caso de uso: Administrador, Usuario - Ingreso al sistema.

Ttulo: Casos de Uso Autor: Procesos Levantados en la empresa


Autor Administrador, Usuarios

Descripcin: Se debe iniciar creando el usuario por parte del administrador.

Pre-condiciones:

El usuario debe estar debidamente registrado en la base

de datos.

Ingreso al Sistema

Gerente - Admnistrador UsuariosVentas - Recepcin - Contabil idad

Fig 4.2.1 Casos de Usos CU-001 Ingreso al sistema


48

Pos - condiciones

exitosas

Al ingresar se presentara una pantalla de validacin de

Usuario y Password guardados previamente en la base.

Post-condiciones por falla

Al no estar ingresado en la base se podr visualizar un

mensaje de error, al igual si su password o usuario estn mal ingresados

Flujo normal:

1.- Se presentara una pantalla al usuario indicando que ingrese su nombre y contrasea

2.- El sistema validara que sean correctos los datos y

permitir el ingreso.

3.-La validacin de los datos es :

Usuario

Password 4.-Finalizacin del caso de uso

Flujo alternativo: Existencia del usuario en la base de datos. Excepciones Mal ingreso de Usuario y Password

Frecuencia de uso Veces que se ingrese al Sistema

Fig. 4.2.1 Casos de Uso CU-001




49

4.1.2. Caso de uso: Administrador - Creacin del Usuario.



Autor: Administrador

Descripcin: Se debe iniciar creando el usuario por parte del administrador.


Sistema

Ingreso al Sistema

Seleccionamos el Perfil -Administrador o Inventario

Valido Informacin y Guardo

En la pantalla vemos los datos creados en una grilla

Usuario Creado

Fig 4.2.2 Casos de Usos CU-002 Creacin de Usuarios

Usuarios Sistema

Doy click en la opciond el Men SISTEMA

Se visualiza 4 opciones - Damos click en Usuarios

Visualizamos una pantalla con datos del usuario a crearse


50

Pre-condiciones:

Los usuarios deben estar creados en la base de datos previamente

Pos - condiciones exitosas

El usuario podr tener acceso al aplicativo y sus respectivas pantallas.

Post-condiciones por

falla

Si existe un usuario con los mismos datos (cdula), se enviara un mensaje indicando que ya est creado.

Flujo normal:

1.-Al ingresar al sistema se despliega un men donde se

despliega las siguientes opciones.

Usuario

Perfil

Opciones

Perfil Opcin

2.-Escogemos la opcin de Usuario y registramos los siguientes datos:

Nombre

Apellido

Usuario

Contrasea

Confirmacin de la Contrasea

3.- El administrador selecciona el perfil al cual va a pertenecer el usuario.

Administrador

Inventario

4.-El sistema verifica la informacin y valida que todos los campos obligatorios estn llenos.

5.-El administrador da clic en Guardar.


51

6.- Se puede validar la informacin ingresada en una grilla que se encuentra en la parte inferior de la pantalla.

7.- Finalizacin del Caso de Uso

Flujo alternativo: Validacin de Datos - Campos obligatorios deben estar

llenos

Excepciones

Campos Obligatorios sin llenar

Mensaje indicando que deben ser llenados. Frecuencia de uso Veces que se crea un nuevo usuario





52

4.1.3. Caso de uso: Administrador Modificar usuario.




Descripcin: Se debe iniciar con la modificacin de un usuario Pre-condiciones: El usuario debe estar registrado dentro del sistema

Pos - condiciones

exitosas

El usuario podr tener acceso al aplicativo y sus respectivas

pantallas.

Ingreso al Sistema

Ingreso pantalla de Informacin del Usuario


Sistema

Doy clic en la grilla para modificar los datos

Usuario Modificado

Fig 4.2.3 Casos de Usos CU-003 Modificacin de Usuarios

Usuarios Sistema

Busco Informacin

Guardo Informacin

Modifico los Datos que se desea cambiar

Valido que este correcta la informacion y Guardo


53


Si existe un usuario con los mismos datos (cedula), se enviara un mensaje indicando que ya est creado.

Flujo normal:

1.-Se debe iniciar con el ingreso del administrador al sistema.

2.-Ingreso en la pantalla de informacin del Usuario.

3.-Doy clic en la grilla que se encuentra en la parte inferior de la pantalla para poder modificar los datos del usuario.

4.-Los Datos a modificar son: * Nombre

* Apellido * Usuario

* Password * Confirmacin del Password

5.-El sistema verifica la informacin y valida que todos los campos obligatorios estn llenos.

6.-El administrador da clic en Guardar y se guardan los datos del usuario.


Flujo alternativo: Validacin de Datos - Campos obligatorios deben estar llenos

Excepciones

Campos Obligatorios sin llenar Mensaje indicando que deben ser llenados.

Frecuencia de uso Veces que se crea un nuevo usuario





54

4.1.4. Caso de Uso: Administrador - Eliminar usuario




Descripcin: El administrador es la persona encargada de la eliminacin de los usuarios.

Pre-condiciones: El usuario debe estar registrado dentro del sistema

Pos - condiciones exitosas

El usuario podr tener acceso al aplicativo y sus respectivas pantallas.

Ingreso al Sistema

En la grilla podemos verificar la informacion del usuario


Sistema

Para eliminar los usuarios creados nos dirigimos a la grilla

Fig 4.2.4 Casos de Usos CU-004 Eliminacin de Usuarios

Seleccionamos el usuario y damos clic en el boton eliminar

Eliminar Usuario

Ingreso a la pantalla de Informacin del Usuario

Validamos los Datos a Eliminar



55


Si existe un usuario con los mismos datos (cedula), se enviara un mensaje indicando que ya est creado.

Flujo normal:

1.-Ingreso al sistema

2.-Ingresamos a la pantalla de la informacin del Usuario.

3.-Selecciono el usuario a ser eliminado

4.-Damos clic en el botn que se encuentra en la parte derecha del usuario a ser Eliminado.

5.-Validamos la informacin antes de ser eliminada.


Flujo alternativo: Al ser eliminado el usuario, ya no puede ingresar al aplicativo. Excepciones Ingreso mal de la informacin, se enviara un mensaje de error. Frecuencia de uso Veces que se elimine un usuario





56

4.1.5. Caso de Uso: Administrador - Creacin de un Componente Electrnico



Ingreso al Sistema

Doy click en ARTICULO

Doy clic en el Menu en la pestaa INVENTARIO

Nuevo Articulo

Fig 4.2.5 Casos de Usos CU-005 Creacin de Componentes Electrnicos

Area de Ventas(Ingeniero)

Area de Contabilidad

UsuarioSistema

Valido la informacin del articulo

Ingreso los nuevos articulos

Se despliega una pantalla con las caracteristicas del articulo

Guardo el Articulo

Articulo Existente

SI

Fin del Caso de Uso

NO


57


Descripcin: Se debe iniciar con la creacin de los componentes electrnicos

Pre-condiciones:

El componente electrnico debe estar registrado dentro del sistema

Pos - condiciones

exitosas

El componente y sus caractersticas se podrn visualizar sus

respectivas pantallas.


Si existe un componente con las mismas caractersticas (cdigos) se enviara un mensaje indicando que ya est creado.

Flujo normal:

1.- Al ingresar al sistema se presenta en la pantalla un men al

dar clic se aparecen algunos tems.

2.-Selecciona el formulario que permitir crear un nuevo

componente.

3.-Damos clic en el men INVENTARIO en la pestaa ARTICULO.

3.-La ingreso de los datos es :

* CODIGO * TIPO

* PRECIO * PAQUETE * CANT_MINIMA * PESO

* CATALOGO * PAGINA

* NOMBRE_CORTO * NOMBRE_LARGO * ONLINE_CATALOGO * UNIDAD

4.-El sistema verifica la informacin y valida que todos los


58

campos obligatorios estn llenos.

5.-El administrador da clic en Guardar y se guardan los datos de los componentes electrnicos.


Flujo alternativo: Validacin de Datos - Campos obligatorios deben estar llenos

Excepciones


Mensaje indicando que deben ser llenados. Frecuencia de uso Veces que se crea un nuevo componente electrnico





59

4.1.6. Caso de Uso: Administrador - Modificacin de un Componente Electrnico

Fig 4.2.6 Casos de Usos CU-006 Modificacin de Componentes Electrnicos

Ingreso al Sistema

Doy click en ARTICULO

Doy clic en el Menu en la pestaa INVENTARIO

Cambio la Informacion

Area de Ventas(Ingeniero)

Area de Contabilidad

Usuario

Sistema

Doy clic en el articulo y su informacion se desplaza en la parte superior

En la grilla se visualiza todos los articulos ingresados

Se despliega una pantalla con las caracteristicas del articulo

Valido la informacin

Guardo la Informacin

Fin del Caso de Uso


60



Autor Administrador

Descripcin: Se debe iniciar con la modificacin de los componentes electrnicos

Pre-condiciones:

El componente electrnico debe estar registrado dentro del sistema

Pos - condiciones

exitosas

La persona del rea de Contabilidad ser la encargada de ingresar a un men de opciones para acceder a los procesos correspondientes para la modificacin de la

informacin de los componentes electrnicos.


Si existe un componente electrnico con los mismos dato se

enviara un mensaje indicando que ya est creado.

Flujo normal:

1.-Se debe iniciar con el ingreso de la persona encargada en el

rea de ventas para la modificacin de los componentes

2.- El sistema presentara en una grilla la cual nos indica toda la informacin de los artculos.

3.-Luego damos clic en el artculo a ser modificado y su

informacin se presenta en la parte superior, lista para ser modificada.

3.-La validacin de los datos es : * CODIGO * TIPO * PRECIO * CANT_MAXIMA

* PAQUETE * ORDEN_MINIMA

* PESO * CATALOGO


61

* PAGINA * NOMBRE_CORTO * NOMBRE_LARGO * ONLINE_CATALOGO

* UNIDAD

4.-El sistema valida que todos los campos obligatorios estn llenos.

5.-Luego damos clic en Guardar y se guardan la informacin de los componentes electrnicos.

6.- Finalizacin del Caso de Uso.

Flujo alternativo:

Validacin de Datos

Si ya existen en la base de datos los componentes electrnicos se podr modificar la informacin.

Excepciones

Campos Obligatorios sin llenar Mensaje indicando que faltan campos por llenar.

Frecuencia de uso Veces que se crea modifica un componente electrnico





62

4.1.7. Caso de Uso: Administrador - Compra de un Componente Electrnico

Autor Sistema, Administrador, Usuarios

Descripcin: El gerente adquiere ciertos componentes electrnicos luego

los mismos sern ingresados en la base de datos.

Pre-condiciones: Los componentes deben estar registrados en la base de datos.

Pos - condiciones

exitosas

El sistema debe validar que los nuevos componentes electrnicos ya registrados tengan ciertas caractersticas para

poder realizar los clculos.

Post-condiciones por

falla

Si existen componentes electrnicos que no tienen datos

suficientes

Flujo normal:

1.-Se debe tener todos los componentes debidamente actualizada la informacin.

2.- El sistema presentara una interfaz a travs de la cual se puedan hacer bsquedas de los componentes electrnicos.

3.-Al momento de hacer un ingreso damos clic en el buscar

articulo y se despliega una pantalla donde nos indica que ingresemos el nombre y luego dar clic en BUSCAR.

4.-Ingresamos el nombre del articulo a BUSCAR y el

articulo se visualiza en una grilla ubicada en la parte inferior de la pantalla.

5.- Damos clic en la grilla y se aparece automticamente el artculo en la pantalla.

6.-Ingresamos la cantidad a comprar y el precio.

7.- Automticamente nos calcula el Precio TOTAL.


63

8.- Guardamos el Ingreso del Articulo

7.- Fin del caso de uso

Flujo alternativo:

Validacin de Datos Si ya existen en la base de datos los componentes

electrnicos se podr modificar la informacin.

Excepciones


Mensaje indicando que faltan campos por llenar.

Frecuencia de uso

Veces que se quiera saber cuntos componentes electrnicos existen



64

D

o

y

c

l

i

c

e

n

B

u

s

c

a

r

I

n

g

r

e

s

o

a

l

S

i

s

t

e

m

a

D

a

m

o

s

c

l

i

c

e

n

I

n

g

r

e

s

o

s

S

e

l

e

c

c

i

o

n

a

r

d

e

l

m

e

n

l

a

p

e

s

t

a

a

d

e

I

n

v

e

n

t

a

r

i

o

S

e

d

e

s

p

l

i

e

g

a

l

a

i

n

f

o

r

m

a

c

i

o

n

u

n

a

p

a

n

t

a

l

l

a

F

i

g

4

.

2

.

8

C

a

s

o

s

d

e

U

s

o

s

C

U

-

0

0

8

I

n

g

r

e

t-uce-0011-68

Documents