Sei sulla pagina 1di 53

UNIVERSIDAD AUTNOMA DEL ESTADO DE HIDALGO

INSTITUTO DE CIENCIAS BSICAS E INGENIERA


REA ACADMICA DE COMPUTACIN Y ELECTRNICA
LIC. EN SISTEMAS COMPUTACIONALES

PROYECTO DE INVESTIGACIN

Prototipo del sistema


FarManager
QUE PRESENTA:
P.L.S.C. Claudia Citlali Santander Hernndez

ASESOR:
Ing. Guillermo Hernndez Garca

Noviembre de 2015

Introduccin
Actualmente el uso de herramientas informticas en distintos mbitos provee
muchos beneficios, una empresa sin importar el giro al que pertenezca puede
explotar estas herramientas teniendo una ventaja competitiva, porque al adaptarlo
a sus funciones diarias se logra una importante mejora en la calidad de servicio y
una reduccin en los tiempos de espera de los clientes.
Una empresa comercial basa sus acciones en la compra y venta de bienes,
productos o servicios, es necesario contar con un software que permita agilizar
estos procesos.
Una farmacia, dada las caractersticas de los servicios que ofrece, puede
aprovechar los beneficios relacionados con ventas, compras y control de
inventarios que proporcionan los sistemas puntos de venta.

Antecedentes
Software punto de venta
Los sistemas punto de venta son la evolucin del siglo XXI de la clsica caja
registradora, compuesto por un sistema de hardware y software.
Actualmente existe mucho software punto de venta, entre los ms conocidos y
usados estn:
MyBusiness POS
Creado por MyBusiness POS Desarrollos, S. A. de C. V., es una empresa
dedicada a la fabricacin de software de punto de venta, control administrativo y
facturacin electrnica.

Versiones:

MyBusinessPOS 2002

MyBusinessPOS 2004

MyBusinessPOS 2006 Delta

MyBusinessPOS 2008 Elite

MyBusinessPOS 2010

MyBusinessPOS 2011

MyBusinessPOS 2012 V.12

MyBusinessPOS es un sistema de paga. Los requerimientos mnimos son:


Requerimientos:
Mnimos: procesador a 1 GHz, 512 Mb en RAM, 100 Mb libres en disco duro,
monitor SVGA color, CD-ROM, mouse, no-break en el servidor.
Deseables: procesador a 1.5 GHz, 1 GB en RAM, 300 Mb libres en disco duro,
monitor SVGA color, CD-ROM, mouse, tarjeta de red, mdem, internet, no-break
en el servidor.
Sistemas operativos: Windows XP Service Pack 3 o superior, 2000, NT, Vista
(Excepto Windows Vista Starter), incluyendo Windows 8 o 8.1
Nota importante: MyBusiness POS 2012 viene preinstalado con ms SQLServer
Expresstm de Microsofttm , soporta hasta 4GB de informacin de forma gratuita. 1
(Desarrollos, 2002)
SICAR
Desarrollado por la empresa SICAR S. A. de C. V., es una empresa dedicada a la
fabricacin de software de punto de venta de paga con funciones para farmacia
3

como son; venta de medicamento controlado, reportes de recetas, reportes de


ventas, lotes y caducidades, etc.
Versiones:

SICAR 1.8
SICAR 1.9
SICAR 2.0

Requerimientos:

Procesador de 32 bit (x86) o 64 bits (x64) a un gigahercio (GHz) o ms.


Memoria RAM de 1 gigabyte (GB) (32 bits 64bits).
Espacio disponible en disco rgido de 16 GB (32bits 64bits).
Sistema Operativo Windows XP, Windows Vista, Windows 7, Linux o MAC

OsX.
Java SE 6 Para descargarlo siga el siguiente enlace.
Requisitos adicionales para usar ciertas funciones:
Acceso a Internet (Puede tener costes adicionales).
Navegador Web Internet Explorer - Chrome Firefox.
(C.V., 2008)

Definicin del problema


La mayora de las micro o pequeas empresas inician sus actividades llevando
procesos manuales, es el caso de la farmacia Torres. A pesar de contar con
equipos de cmputo, utiliza un proceso manual de control de ventas e inventarios,
lo cual provoca prdida de tiempo al realizar el inventario, adems no se tiene un
buen control sobre los medicamentos y ventas generadas, lo anterior ocasiona
inconvenientes como son: prdida de frmacos, falta de control sobre las
existencias, informacin imprecisa sobre ingresos, egresos y desconocimiento de
las utilidades a fin de saber la rentabilidad del negocio.
A menudo se opta por utilizar software punto de venta comercial, lo que obliga a
las empresas a adaptarse a las caractersticas impuestas y muchas veces no se
ocupa la mayora de sus funcionalidades. En muchas ocasiones es necesario
recurrir a software a medida, el software es creado a partir de los requisitos
4

especficos de la empresa que lo contrata. Por lo tanto, es un software que se


ajusta a la perfeccin al modelo de negocio de la empresa y reporta un beneficio
mayor que el simple uso de un software punto de venta comercial.
Dada la problemtica existente se crear un prototipo del punto de venta para la
farmacia Torres. Se debe realizar el anlisis y diseo de una base de datos con
fines administrativos, donde se deber establecer las fases de la metodologa
incremental. El diseo de la base de datos del sistema punto de venta debe
contar con parmetros de seguridad en la integridad de datos, confiabilidad y
disponibilidad de la informacin. Tambin ser diseado por niveles fsico, lgico y
de vista, es importante hacer una buena eleccin del SGBD 1 y la arquitectura con
la que se va a trabajar. Se necesita establecer el software y hardware que se debe
utilizar para la realizacin del mismo.

Justificacin

Actualmente en el mercado existe una gran variedad de software punto de venta


que permite llevar un control en el rea de ventas, sin embargo adaptar los
productos de software a los procesos generales de una farmacia en particular es
muy difcil, por lo que se decidi desarrollar un sistema a la medida, acorde a las
necesidades particulares de la farmacia Torres. Con esto se pretende automatizar
los principales procesos relacionadas con la venta, control de inventarios,
proporcionando una ventaja competitiva y grandes beneficios principalmente
financieros.
Con el control y la monitorizacin sobre el inventario, se puede ayudar a reducir la
prdida de frmacos por robos, derroche o mal uso por parte de los empleados,
facilitando el control de existencias. Tambin permite agilizar las consultas sobre
la existencia, precio, caractersticas de un determinado frmaco y la posibilidad de
vender un producto por el precio correcto. Adems, en el proceso de cambio de
1 Sistema Gestor de Bases de Datos
5

precio a productos, es difcil realizar la actividad de manera manual, pero si se


tuviera el software de manera automtica se realizara el cambio de precio. A
travs de informes generados se proporciona

un conocimiento preciso sobre

ingresos, egresos y utilidades que se obtienen en determinado tiempo, mejorando


la calidad de servicio y reduciendo tiempos de espera de los clientes. Adems de
los beneficios anteriores que son del ramo transaccional u operativo se contar
con informacin para un futuro desarrollo de mdulos, enfocados a la toma de
decisiones del dueo de la farmacia.

Objetivos
Objetivo general
Realizar el prototipo del software punto de venta siguiendo la metodologa
incremental para la farmacia Torres.
Objetivos especfi cos
1. Obtener informacin del proceso general de control que utiliza la farmacia
Torres.
2. Realizar el anlisis y diseo de la base de datos para el sistema punto de
venta.
3. Determinar el SGBD que se usar, asi como la compatibiladad con los
lenguajes de programacin y consulta.
4. Realizar el anlisis y diseo de la interfaz de usuario.
5. Determinar el lenguaje y software en el que se desarrollar la interfaz de
usuario.
6. Implementar requerimientos y optimizaciones necesarios para la conexion
entre la base de datos e interfaz de usuario.
7. Documentar el anlisis y diseo de la base de datos e interfaz de usuario
mediante diagramas o algoritmos.
6

8. Desarrollar prototipo.

Capitulo I.- Marco terico


1.1 Punto de Venta
Un Punto de Venta es la versin computarizada de una caja registradora
tradicional o de un cuaderno para llevar las cuentas, puede contar con muchas
funciones. Un punto de venta otorga control sobre las operaciones de negocio y
son utilizados para registrar ventas, beneficios, pedidos, inventarios, historial de
clientes, etc.
1.1.1 Componentes de un punto de venta
Software de Terminal Punto de Venta
Este es el sistema encargado de realizar todo el proceso de venta desde la
captura de los productos en una base de datos, mediante una interfaz de usuario
para facilitar los procesos.
Hardware punto de venta
Un punto de venta est compuesto fsicamente por un dispositivo central, en la
mayora de los casos una computadora, tambin se tiene varios dispositivos de
entrada y salida, entre los que estn escner de cdigos, impresora, cajn de
dinero, terminal de cobro para tarjeta de crdito o dbito. (Conesa, 2013)

1.2 El ciclo de vida del desarrollo de sistemas


El ciclo de vida del desarrollo de sistemas consiste en que los sistemas se
desarrollan mejor utilizando un ciclo especfico de actividades para la realizacin
7

de cualquier programa. A pesar de que el desarrollo de sistemas es por fases,


como se muestra en la figura 1, nunca se realizan como pasos aislados ms bien,
es posible que varias actividades ocurran de manera simultnea, y algunas de
ellas podran repetirse.

Figura 1. Fases del ciclo de vida para el desarrollo de sistemas

Identificacin de problemas, oportunidades y objetivos


En esta primera fase del ciclo de vida del desarrollo de sistemas, el analista se
ocupa de identificar problemas, oportunidades y objetivos. Aqu se determina con
precisin cules son los problemas, las situaciones susceptibles de mejorar
utilizando sistemas computarizados, averiguar lo que la empresa pretende
conseguir. Las actividades de la fase consisten en entrevistar a los encargados de
coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del
proyecto y documentar los resultados.
Determinacin de los requerimientos de informacin
La fase va enfocada a comprender la informacin que necesitan los usuarios para
llevar a cabo sus actividades. Entre las herramientas que se utilizan al determinar
los requerimientos de informacin de un negocio se encuentran mtodos
interactivos como las entrevistas, los muestreos, la investigacin de datos
8

impresos y la aplicacin de cuestionarios, hasta mtodos de amplio alcance como


la elaboracin de prototipos, para obtener una pronta retroalimentacin por parte
de los usuarios es un poco diferente.
Esta fase es til para que el analista confirme la idea que tiene de la organizacin,
as como sus objetivos. Los implicados son el analista y los usuarios; el analista
de sistemas necesita conocer los detalles de las funciones del sistema actual: el
quin, se refiere a la gente involucrada, el qu son las actividades del negocio, el
dnde describe el entorno el entorno donde se desarrollan las actividades, el
cundo indica el momento oportuno y el cmo describe la manera en que se
realizan los procedimientos actuales del negocio que se estudia, preguntar la
razn por la cual se utiliza el sistema actual. Al trmino de esta fase, el analista
debe conocer el funcionamiento del negocio con informacin muy completa acerca
de la gente, los objetivos, los datos y los procedimientos implicados.
Anlisis de las necesidades del sistema
La fase determina las necesidades y requerimientos del sistema, con el uso de
herramientas, tcnicas o modelos. Una de las herramientas es el uso de
diagramas de flujo de datos para graficar las entradas, los procesos, las salidas de
las funciones del negocio en una forma grfica estructurada. A partir de los
diagramas de flujo de datos se desarrolla un diccionario de datos que enlista todos
los datos utilizados en el sistema, as como sus respectivas especificaciones.
Diseo del sistema recomendado
En esta fase se utiliza la informacin recopilada en las primeras fases para realizar
el diseo lgico del sistema de informacin, se disean procedimientos precisos
asegurando que la captura de los datos a ingresar al sistema sean correctos,
facilitando la entrada eficiente de datos al sistema de informacin mediante
tcnicas adecuadas de diseo de formularios y pantallas.

La interfaz conecta al usuario con el sistema y por tanto es sumamente


importante. El diseo de la interfaz de usuario forma parte del diseo lgico del
sistema de informacin, se interacta con los usuarios para disear la salida en
pantalla o impresa que satisfaga las necesidades de informacin de estos ltimos.
Finalmente, el analista debe disear controles y procedimientos de respaldo que
protejan al sistema, datos, desarrollar paquetes de especificaciones de programa
para los programadores. Cada paquete debe contener esquemas para la entrada
y la salida, especificaciones de archivos, as como detalles del procesamiento;
tambin podra incluir rboles o tablas de decisin, diagramas de flujo de datos, un
diagrama de flujo de sistema, con los nombres y funciones de cualquier rutina de
cdigo previamente escrita.
Desarrollo y documentacin del software
En la quinta fase del ciclo de vida del desarrollo de sistemas, el analista trabaja de
manera conjunta con los programadores para desarrollar cualquier software
original necesario. Entre las tcnicas estructuradas usadas en el diseo y
documentacin del software se encuentran los diagramas de estructura, los
diagramas de Nassi-hneiderman2 y el pseudocdigo. Durante esta fase el analista
tambin trabaja con los usuarios con el fin de que la documentacin sea efectiva,
como manuales de procedimientos, ayuda en lnea y sitios Web que incluyan
respuestas a preguntas frecuentes. La documentacin indica a los usuarios cmo
utilizar el software y lo que deben hacer en caso de problemas derivados de su
uso.
Prueba y mantenimiento del sistema
Antes de poner el sistema en funcionamiento es necesario probarlo. Una parte de
las pruebas las realizan los programadores solos, y otra la llevan a cabo de
manera conjunta con los analistas de sistemas. Primero se realiza una serie de
2 Tcnica hibrida entre Diagramas de Flujo y Pseudocdigo.
10

pruebas con datos de muestra para determinar con precisin cules son los
problemas y posteriormente se realiza otra con datos reales del sistema actual.
El mantenimiento del sistema de informacin y la documentacin empiezan en
esta fase, llevndose a cabo de manera rutinaria durante toda su vida til. Gran
parte del trabajo habitual del programador consiste en el mantenimiento, como por
ejemplo las actualizaciones de programas.
Implementacin y evaluacin del sistema
En la ltima fase se capacita a los usuarios en el manejo del sistema. Se tiene que
planear una conversin gradual del sistema anterior al actual. El proceso incluye la
conversin de archivos de formatos anteriores a los nuevos, o la construccin de
una base de datos, la instalacin de equipo y la puesta en produccin del nuevo
sistema.
La evaluacin se lleva a cabo durante cada una de las fases, tambin se debe
evaluar es si el sistema cumple las expectativas de los usuarios a quienes va
dirigido y si lo estn utilizando realmente.
El trabajo de sistemas es cclico, cuando se termina una fase del desarrollo de
sistemas se pasa a la siguiente, pero el surgimiento de un problema podra obligar
a regresar a la fase previa y modificar el trabajo realizado (Kenneth E. Kendall,
2005).

1.3 Modelos de Proceso del software


Un modelo de proceso del software es una descripcin de un proceso del software
que se presenta desde una perspectiva particular. Es una abstraccin de un
proceso real.
1.3.1 Modelo en cascada
El modelo en cascada, llamado algunas veces ciclo de vida clsico se basa en un
enfoque sistemtico, secuencial hacia el desarrollo del software. Este modelo es el
11

paradigma ms antiguo para la ingeniera del software, el inicio de cada etapa


debe esperar a la finalizacin de la etapa anterior.
La principal ventaja del modelo es su
sencillez, ya que sigue los pasos intuitivos
como se muestra en la figura 2, que son
necesarios a la hora de desarrollar el
software. Un proyecto rara vez sigue una
secuencia lineal, en este modelo el proceso
de creacin del software tarda mucho tiempo

Figura 2. Fases del modelo en


cascada

puesto que las fases establecidas tienen que seguir un orden, el software se utiliza
hasta estar completo. Las etapas previas a la de prueba deben estar bien
desarrolladas ya que cualquier error de diseo detectado en las pruebas conducen
necesariamente al rediseo y nueva programacin del cdigo afectado,
aumentando los costos del desarrollo (Pressman, 2006).
1.3.2 Modelo incremental
El modelo incremental combina elementos del modelo en cascada aplicado en
forma iterativa. Como se muestra en la figura 3, el modelo aplica secuencias
lineales de manera escalonada conforme avanza el tiempo en el calendario. Es
incremental entrega una serie de lanzamientos llamado incrementos que
proporcionan de forma progresiva ms funcionalidad; cada secuencia lineal
produce incrementos de software (Pressman, 2006).

12

Figura 3. Modelo incremental

En un proceso de desarrollo incremental, los clientes identifican que servicios son


ms importantes y cuales menos, entonces se definen varios incrementos en
donde cada uno proporciona un subconjunto de la funcionalidad del sistema. La
asignacin de servicios a los incrementos depende de la prioridad del servicio con
los servicios de prioridad ms alta entregados primero.
Al utilizar un modelo incremental el primer incremento es un producto esencial,
que se entrega al cliente para una evaluacin detallada, dependiendo el resultado
de la evaluacin se desarrolla un plan para el incremento siguiente. El plan afronta
la modificacin del producto esencial con el fin de satisfacer mejor las necesidades
del cliente, la entrega de caractersticas y funcionalidad adicionales. Este proceso
se repite despus de la entrega de cada incremento hasta obtener el producto
completo. El modelo se enfoca en la entrega de un producto operacional con cada
incremento, los primeros incrementos son versiones incompletas del producto
final, pero proporcionan al usuario la funcionalidad que necesita (Sommerville,
2005) .
El desarrollo incremental es til sobre todo cuando el personal necesario para una
implementacin completa no est disponible. Mediante este modelo se genera
software operativo de forma rpida y en etapas tempranas del ciclo de vida del
software, los clientes no tienen que esperar hasta la entrega del sistema completo
13

para sacar provecho de l. El primer incremento satisface los requerimientos ms


crticos de tal forma que pueden utilizar el software inmediatamente, reduciendo el
coste en el cambio de alcances y requisitos; es ms fcil probar y depurar una
iteracin pequea, lo cual permite gestionar riesgos de una forma ms sencilla.
En el uso de este modelo se requiere una experiencia importante para definir los
incrementos y distribuir en ellos las tareas de forma proporcionada, entre sus
principales inconvenientes se puede destacar que cada fase de una iteracin es
rgida y no se superponen con otras, los incrementos son relativamente pequeos,
pueden surgir problemas referidos a la arquitectura del sistema porque no todos
los requisitos se han reunido (Pressman, 2006).

1.3.4 Modelo en espiral


Originalmente este modelo fue propuesto por Bohem, se representa como una
secuencia de actividades con retrospectiva de una actividad a otra,

como se

muestra en la figura 4 se representa como una espiral. Cada ciclo en la espiral


representa una fase del proceso del software, el ciclo ms interno podra referirse
a la viabilidad del sistema, el siguiente ciclo a la definicin de requerimientos, el
siguiente al diseo del sistema y as sucesivamente.

14

Figura 4. Modelo en espiral para el proceso del software

Cada ciclo de la espiral se divide en cuatro sectores:


1. Definicin de objetivos: en esta fase se definen los objetivos especficos. Se
identifican las restricciones del proceso o producto y se traza un plan
detallado de gestin. Se identifican los riesgos, dependiendo de estos se
planean estrategias alternativas.
2. Evaluacin y reduccin de riesgos: se lleva a cabo un anlisis detallado
para cada riesgo identificado, se definen los pasos para reducirlos.
3. Desarrollo y validacin: en esta etapa se elige un modelo para el desarrollo
del sistema.
4. Planificacin: el proyecto se revisa y se toma la decisin de si se debe
continuar con un ciclo posterior a la espiral. Si se decide continuar, se
desarrollan los planes para la siguiente fase del proyecto.
La diferencia principal entre el modelo en espiral y los otros modelos del proceso
del software es la consideracin explicita del riesgo en el modelo en espiral.
Un ciclo en espiral empieza con la elaboracin de objetivos, como el rendimiento y
la funcionalidad. Entonces se enumeran formas alternativas de alcanzar estos
15

objetivos y las restricciones impuestas en cada una de ellas. Cada alternativa se


evala contra cada objetivo y se identifican las fuentes de riesgo del proyecto. El
siguiente paso es resolver estos riesgos mediante actividades de recopilacin de
informacin como detallar ms el anlisis, la construccin de prototipos y la
simulacin. Una vez que se lleva a cabo cierto desarrollo, seguido de una
actividad de planificacin para la siguiente fase del proceso (Sommerville, 2005).

1.4 Prototipos
Un prototipo es una versin inicial de un sistema software que se utiliza para
demostrar conceptos, probar opciones de diseo, en general, informarse ms del
problema y sus posibles soluciones. Tambin se puede usar a fin de reducir el
tiempo requerido para desarrollar la documentacin del usuario.

Figura 5. Etapas del desarrollo de prototipos

Como se muestra en la figura 5, en la primera etapa del desarrollo de prototipos se


debe especificar los objetivos de la construccin desde el inicio del proceso para
evitar que los usuarios finales malinterpreten su funcin, tambin se decide que
incluir o excluir del sistema prototipo, en el desarrollo del prototipo, es importante
tener en cuenta el manejo de errores, fiabilidad y calidad se pueden reducir los
estndares. Por ltimo se evala el prototipo utilizando los objetivos establecidos
en un principio.
1.4.1 Clases de prototipos

16

Figura 6.- Clases de prototipos

Prototipo corregido
La primera clase de elaboracin de prototipos tiene que ver con la construccin de
un sistema que funciona pero se corrige simultneamente, como se muestra en la
figura 6. En la ingeniera a este enfoque se le llama elaboracin de una tabla
experimental.
Prototipo no funcional
El segundo tipo de prototipo es un modelo no funcional a escala configurado para
probar ciertos aspectos del diseo. Un modelo no funcional a escala de un sistema
de informacin podra producirse cuando la codificacin requerida por las
aplicaciones es demasiado extensa para incluirse en el prototipo pero cuando se
puede conseguir una idea til del sistema a travs de la elaboracin de un
prototipo de la entrada y la salida. En este caso, el procesamiento debido al
excesivo costo y el tiempo requerido no podra incluirse en el prototipo. Sin
embargo, an se podran tomar algunas decisiones sobre la utilidad del sistema
con base en la entrada y la salida incluidas en el prototipo.
Primer prototipo de una serie
Este prototipo involucra la creacin de un primer modelo a escala completa de un
sistema, con frecuencia llamado piloto. El prototipo es completamente funcional y
es una materializacin de lo que el diseador espera ser una serie con
caractersticas idnticas. Es til cuando se planean muchas instalaciones del
mismo sistema de informacin. El modelo funcional a escala completa permite a
17

los usuarios experimentar la interaccin real con el nuevo sistema, pero minimiza
el costo de superar cualquier problema que se presente.
Prototipo de caractersticas seleccionadas
Involucra la creacin de un modelo funcional que incluya algunas, pero no todas
las caractersticas que tendr el sistema final. Al elaborar prototipos de sistemas
de informacin de esta manera, se incluyen algunas de las caractersticas
principales. Por ejemplo, en la pantalla podra aparecer un men del sistema que
muestre seis caractersticas: agregar un registro, actualizar un registro, eliminar un
registro, buscar una palabra clave en un registro, listar un registro o examinar un
registro. Sin embargo, en el prototipo del sistema tal vez slo estn disponibles
tres de las seis caractersticas, de manera que el usuario podra agregar un
registro, eliminar un registro y listar un registro.
Cuando se recurre a este tipo de elaboracin de prototipos, el sistema se completa
por mdulos de forma que si las caractersticas que se incluyen en los prototipos
se evalan exitosamente, se puedan incorporar en el sistema final ms grande sin
necesidad de realizar demasiado esfuerzo en la interaccin. Los prototipos hechos
de esta forma son parte del sistema real, no son solo un modelo (Kenneth E.
Kendall, 2005).

1.5 Sistemas centralizados


Al ejecutar un nico sistema informtico sin interactuar con ninguna otra
computadora se le conoce como arquitectura centralizada, van

desde los

sistemas de bases de datos monousuario ejecutndose en computadoras


personales hasta los sistemas de bases de datos de alto rendimiento
ejecutndose en grandes sistemas.
1.5.1 Sistemas cliente-Servidor
Los sistemas se han ido distanciando de las arquitecturas centralizadas, debido a
la rapidez y potencia de los computadores personales que han remplazado la
gestin de los sistemas centralizados sobre las terminales e interfaz de usuario.
18

Como consecuencia los sistemas centralizados actualmente actan como


sistemas servidores que satisfacen las peticiones generadas por los sistemas
clientes.
1.5.2 Elementos de un sistema de informacin
Como se muestra en la Figura 7, la funcionalidad de un sistema de informacin
comprende dos grandes partes; la parte visible del usuario y el sistema
subyacente.

Figura 7.- Funcionalidades de un sistema de informacin

El sistema subyacente gestiona el acceso a las estructuras, la evaluacin,


optimizacin de consultas, el control de concurrencia y la recuperacin. La parte
visible al usuario de un sistema est formado por herramientas como formularios,
diseadores de informes y facilidades graficas de interfaz de usuario.
La interfaz entre la parte visible y el sistema subyacente puede ser SQL 3 o una
aplicacin. Con las normas ODBC 4 y JDBC5 se puede crear la interfaz entre

3 Siglas en ingls Structured Query Language o Lenguaje de Consulta Estructurado.


4 Siglas en ingls Open Database Connectivity o Conectividad Abierta de Bases de Datos.
5 Siglas en ingls Java DataBase Connectivity o Conectividad de Bases de Datos Java.
19

clientes y servidores, si un cliente que utiliza estas interfaces puede conectarse a


cualquier servidor que las proporcione (Abraham Silberschatz, 2002).
1.5.2 Interfaz JDBC para conexin entre Base de datos e interfaz
grfi ca de usuario
JDBC es una API6 de bajo nivel, establece una conexin con una base de datos
enviando sentencias SQL, es decir que las sentencias SQL se puedan mezclar
con Java, por ejemplo, que una variable de Java pueda ser usada en una
sentencia SQL para recibir o dar valores (Muoz, 2010).
Modelo de dos capas JDBC
En este modelo la aplicacin Java se conecta
directamente con la base de datos, el driver JDBC
especfico para la conexin estar instalado en el
sistema local. En la configuracin cliente/servidor el
programa cliente enva instrucciones SQL a la base de

Figura 8.- Modelo de dos


capas JDBC

datos, esta las procesa y enva los resultados de vuelta al usuario (Afergan, 1997).

1.6 Base de datos


Un sistema til debe recuperar datos eficientemente, esto ha conducido al diseo
de estructuras de datos complejas para la representacin de los datos en una
base de datos, mediante un lenguaje de definicin de datos, tal como SQL para
especificar el esquema de la base de datos (Educacin, 2001).
Los niveles que se manejan son:
Nivel fsico: El nivel ms bajo de abstraccin describe cmo se almacenan
realmente los datos.

6 Siglas en ingls Application Programming Interface o Interfaz de Programacin de


Aplicaciones
20

Nivel lgico: El siguiente nivel ms alto de abstraccin describe qu datos se


almacenan en la base de datos y qu relaciones existen entre esos datos.
Nivel de vistas: El nivel ms alto de abstraccin describe slo parte de la base de
datos completa.
Ejemplares y esquemas
El esquema fsico describe el diseo fsico en el nivel fsico, mientras que el
esquema lgico describe el diseo de la base de datos en el nivel lgico. Una
base de datos puede tener tambin varios esquemas en el nivel de vistas, a
menudo denominados subesquemas, que describen diferentes vistas de la base
de datos (Educacin, 2001).

1.7 NetBeans IDE


Es un entorno integrado de desarrollo en el que se puede realizar tareas
asociadas a la programacin escribir, compilar, depurar, y ejecutar programas en
Java, pero puede servir para cualquier otro lenguaje de programacin. Existe
adems un nmero importante de mdulos para extender NetBeans IDE, que es
un producto libre y gratuito sin restricciones de uso. Contiene muchas
funcionalidades, para distintos tipos de aplicaciones y para facilitar al mximo la
programacin, la prueba y la depuracin de las aplicaciones que se desarrollan,
tambin incorpora un editor propio (Community, 2000).

21

Capitulo II Anlisis de
requerimientos de informacin y
diseo de la base de datos
2.1 Determinacin de los requerimientos de informacin
2.1.1 Procesos generales de la empresa
Ventas
Los empleados de mostrador surten los medicamentos y otros productos
farmacuticos a los clientes, tambin hacen un registro diario de las ventas de
forma manual en una libreta. La dispensacin de medicamentos controlados 7 se
realiza slo con receta mdica. En el caso de recetas cuyo tratamiento descrito
por el mdico se complete con la venta de la Farmacia, la receta original se retiene
y se le asigna un folio consecutivo, se sella la receta original y la copia del
paciente indicando la cantidad surtida, la fecha y la firma del vendedor.
Compras
El propietario es el encargado de la adquisicin de medicamentos en empresas
proveedoras legalmente establecidas, actualmente slo se adquieren los
medicamentos en FarmaAmigo y FarmaSana de Pachuca. Ocasionalmente se
comprarn insumos para la salud de venta libre como sueros, algodones, alcohol y
suplementos alimenticios, en tiendas de conveniencia. Toda compra es respaldada
con facturas, las cuales se guardarn por al menos 365 das.
Los medicamentos se envasan en materiales adecuados como cartones en el
lugar del proveedor y se transportan en automvil al domicilio de la farmacia. Una
vez que llegan los medicamentos a la Farmacia, stos se colocan en el rea de
Recepcin, los antibiticos se registran en la Bitcora de control de Antibiticos.
Se verifica que el producto fsico coincida con la factura revisando el principio
activo, nombre comercial, presentacin, cantidad de piezas y fecha de caducidad.
7 Grupo IV, antibiticos, venta con receta mdica.
22

Posteriormente, se les adiciona la etiqueta de precio y se colocan en los


anaqueles o vitrinas adecuadas en orden alfabtico del principio activo.
En el caso de percatarse de medicamentos en mal estado fsico; sellado
incorrecto, tapa abierta, escurrimiento, frascos rotos, etc., stos se destinan al
rea de Devolucin para su devolucin al proveedor y s son antibiticos se dan
de baja en la bitcora de control.
Finanzas
En cada cambio de turno se hace la suma total de los productos vendidos y se
contrasta con el dinero en caja para comprobar que no falte o sobre dinero. El
empleado del turno vespertino hace el cierre del da anotando en una libreta
cuanto se vendi en el da de medicamentos y otros productos farmacuticos, en
esta libreta el dueo tambin anota los gastos generados en el da, cada fin de
mes se hace la sumatoria total de las ventas del mes obteniendo las ganancias, a
este total se restan los gastos totales del mes para conocer la rentabilidad del
negocio.
2.1.2 Estudio de factibilidad
Factibilidad Operativa
La empresa cuenta con equipo de cmputo necesario para la implementacin del
punto de venta.
Factibilidad Legal
Para el desarrollo de esta propuesta no hay ley ni norma que impida la ejecucin
de la misma.
Factibilidad Presupuestaria
Previa informacin financiera proporcionada por la empresa, se realizar un
presupuesto, determinando respectivos montos y tiempo de pago, para lo cual se
23

considerar el tiempo del ciclo de vida del punto de venta, incluyendo el equipo de
trabajo involucrado, hardware y software necesario. Tras la aprobacin del
prototipo se dar seguimiento al proyecto, contrastando ingresos y gastos,
representndolos en un flujo de caja para determinar el crecimiento financiero con
el uso del punto de venta.
2.1.3 Procesos generales y particulares a automatizar
mediante el sistema de informacin.

Diagrama conceptual
En la Figura 9, se representan representa la funcionalidad completa de los
procesos generales de la empresa, mostrando su interaccin y las relaciones entre
los procesos particulares de ventas, compras y finanzas. Se definen los conjuntos
de funcionalidades afines que el sistema debe cumplir para satisfacer todos los
requerimientos. Este diagrama nos permite visualizar como las funciones ms
importantes que se deben realizar, usndolas como las opciones ms importantes
del men para el punto de venta.

Figura 9.- Diagrama conceptual del proceso general

24

Diagrama de casos de uso

Figura 10. Diagrama de casos de uso

En este diagrama muestra la interaccin esencial del comportamiento de los


actores con el sistema, como lo ilustra la Figura 10, para comprender mejor el
diagrama se identifican los actores como:
Vendedor o empleado de mostrador: es quien est encargado de la venta de
medicamentos en la farmacia, requiere servicios del punto de venta.
Propietario o administrador: es quien tiene los mximos privilegios como el de
gestionar reportes, modificar el inventario de medicamentos, autorizar salidas o
descuentos. Requiere servicios del punto de venta.
Cliente: Es quien inicia el proceso de venta.

25

Diagramas de secuencia

Figura 11.- Diagrama de secuencia de acceso al punto de venta

Diagrama de acceso al sistema


Como se muestra en la Figura 11, en proceso de autentificacin del sistema punto
de venta el usuario requiere estar registrado en el sistema, adems de tener una
contrasea vlida. El sistema verifica los datos ingresados, en caso de ser
incorrectos pide al usuario ingresarlos nuevamente, cuando el sistema autentifique
correctamente al usuario se activan los privilegios dependiendo del tipo de cuenta
accesada.
Diagrama agregar producto o actualizar existencias
Dentro de una cuenta se necesita ingresar al apartado de inventario, para agregar
un producto nuevo, se llenar un formulario con los datos del producto o la factura
de compra, posteriormente el sistema validar si los datos son correctos y
actualizar el inventario dando de alta el nuevo producto. Para actualizar las
existencias de un producto que ya este dado de alta en la base de datos, es
necesario proporcionar al sistema el cdigo de barra o el nombre, se validan estos
datos y se muestra el producto, con la opcin editar permite modificar y actualizar
existencias. La Figura 12 muestra este proceso.
26

Figura 12.- Diagrama de secuencia agregar producto o actualizar existencias

Diagrama de punto de venta


La Figura 13 representa el proceso de venta, se requiere una lista con productos
con existencias validas previamente ingresados, el vendedor deber escoger el
tipo de cliente dependiendo s requiere factura o no, se ingresan los productos a
vender, se obtiene el total, el cliente paga. Una venta actualiza el inventario
decrementando la existencia de los productos vendidos.

Figura 13.- Diagrama de secuencia general del punto de venta

27

Diagrama de gestin de productos


La gestin de productos se refiere a la accin de editar o eliminar un producto, si
se modifica, el sistema muestra los atributos del producto, el administrador
modifica los campos y posteriormente el sistema actualiza el inventario,
regresando a la ventana de inventario, este proceso se muestra en la Figura 14.

Figura 14.- Diagrama de gestin de productos.

Diagrama de gestin de reportes


El proceso para generar un reporte se muestra en la Figura 15 se debe elegir el
tipo en el sistema, el cual procesa la peticin y genera el reporte dependiendo de
los parmetros solicitados.

Figura 15.- Diagrama de gestin de reportes

28

Diagrama de clases
Las diferentes clases que componen el sistema FarManager y como se relacionan
unas con otras se representan en la Figura 16, definiendo los atributos y mtodos
de los objetos usados. Las clases estn representadas por rectngulos, con el
nombre de la clase y sus comportamientos.

Figura 16.- Diagrama de clases.

2.2 Diseo de Base de Datos

29

Un buen diseo de la base de datos nos proporciona una estructura estable ya


que de ello depender que nuestros datos estn correctamente actualizados y la
informacin sea precisa.
Al realizar un buen diseo de base de datos podremos obtener reportes efectivos
y eficientes. El diseo se realiza a partir de la problemtica de la farmacia Torres y
todo el contexto sobre la informacin que se usa.
2.2.1 Diagrama Entidad Relacin

Figura 17. Diagrama E-R de la base de datos

El diagrama de la Figura 17 muestra el modelado de datos conceptual, dando una


percepcin real de los datos representar la estructura lgica de la base de datos a
crear, proporcionando un mtodo sencillo y fcil para identificar las caractersticas
ms sobresalientes y la relacin que existe entre los datos. La nomenclatura que
este diagrama usa es:

Rectngulos representan conjuntos de entidades.


Elipses representan atributos.
Rombos representan relaciones entre conjuntos de entidades.
30

Lneas que unen los atributos con los conjuntos de entidades y los
conjuntos de entidades con las relaciones.

2.2.2 Diagrama relacional


En el diseo de la base de datos a menudo se traduce el modelo Entidad Relacin
para crear el modelo relacional. El modelo relacional establece el esquema de la
base de datos mediante un conjunto de tablas que representan las relaciones de
los datos. En la Figura 18 se puede apreciar como los datos de cada tabla
describen las principales caractersticas de los datos involucrados con las
necesidades del punto de venta.

Figura 18.- Diagrama Relacional

2.2.3 Normalizacin 4FN

31

Se realiz la normalizacin requerida

encaminada a eliminar redundancias e

inconsistencias de dependencia en el diseo de las tablas, creando una tabla


maestra y una detalle para las tablas de venta y compra, Figura 19.

Figura 19.- Cuarta Forma Normal

Se us MySQLWorbench 6.1 CE para la representacin visual de las tablas,


vistas, procedimientos almacenados y claves forneas de la base de datos,
adems permite la creacin del Script 8 bajo el lenguaje SQL y es compatible con
los SGBD que son regidos bajo este mismo lenguaje.
Ofrece adems, la sincronizacin del modelo en desarrollo con la base de datos
real, tambin se puede realizar una ingeniera directa e ingeniera inversa para
exportare e importar el esquema de una base de datos.
En el diseo de la base de datos se gener un diccionario de la base de datos
para facilitar el uso de las variables dentro de ella, incluidas en el Anexo 2 9.

8 Ver Anexo 1
9 Ver Anexo 2
32

Capitulo III.- Diseo y Desarrollo


de Interfaz de Usuario
La interfaz de usuario prototipo se crear en NetBeans IDE 8.0.

3.1 Diseo de Interfaces


En la interfaz de usuario se tendr una pantalla de inicio al sistema que servir
para la identificacin y autentificacin de los usuarios, como se muestra en la
Figura 20.

Figura 20.- Pantalla de inicio

Despus de haber ingresado al sistema se muestra la pgina principal, Figura 21


mediante la cual se puede acceder a los principales mdulos del sistema ventas,
inventario y gestin de reportes.

33

Figura 21.- Ventana principal del sistema punto de venta

La ventana de Punto de Venta muestra un formulario para agregar nuevos o


modificar productos del inventario, tambin se puede aadir la imagen del
producto, Figura 22.

Figura 22.- Ventana Punto de Venta

34

La interfaz para agregar un nuevo producto contendr los campos necesarios para
su captura, optando por un diseo sencillo pero intuitivo, como se puede apreciar
en la Figura 23.

Figura 23.- Ventana Agregar nuevo producto.

En el mdulo de inventario tambin se tendr una ventana que permita modificar


las caractersticas de un producto o consultar detalles. La ventana estar dividida
en segmentos dependiendo la accin a realizar, como se muestra en la figura 24.

Figura 24.- Ventana detalle de productos

35

Finalmente para los reportes se tiene una pantalla sencilla, donde se podr
consultar las ventas e inventario de productos basndonos en un tiempo, en la
ventana contendr una funcin para guardar el reporte en una ruta especfica,
Figura 25.

Figura 25.- Ventana de reportes

Al generar un reporte este contendr el diseo de acuerdo a la Figura 26.

Figura 26.- Diseo de reportes

36

3.2 Desarrollo de interfaces


En el desarrollo del punto de venta FarManager se tienen los paquetes, Figura 27
necesarios que se explicaran a continuacin:

Imgenes: donde se guardan todas las imgenes para el desarrollo de la la


aplicacin ejecutable.
Interfaz: contiene las clases que se integran, en este caso una clase por
ventana a crear.
Reportes: Almacena todos los formularios que se generan en este mdulo.
Utileras: se muestran las funcionalidades especiales, como la conexin,
obtener hora y fecha, as como algunas validaciones.
Libreras: se encuentran las libreras fundamentales como MySQL JDBC
Driver y JDK necesarias para la conexin a la base de datos.

Figura 27.- Estructura de archivos NetBeans

Las ventanas de los componentes principales fueron desarrolladas en la vista de


diseo grfico del formulario Figura 28, facilitando la estructura de desarrollo,
enfocando el uso principalmente de los eventos y acciones ejecutados en la
programacin.

37

Figura 28.- Vista diseo grfico

3.3 Conexin a la base de datos


Para la integracin de la base de datos con la interfaz grfica se realiz la
conexin usando MySQL JDBC Driver, JDK, montando un servidor local, ya que
la farmacia no cuenta con sucursales, la base de datos permanecer
localmente, para esto se us WampServe, Figura 29.

Figura 29.- WampServer

38

Conclusiones
Una empresa comercial que basa sus acciones en la compra y venta de
productos, puede aprovechar el uso de tecnologas para obtener una ventaja
competitiva, principalmente agilizando procesos de venta y un control adecuado
del inventario.
El desarrollo de este prototipo permiti definir los requerimientos para la Farmacia
Torres, demostrando que para el caso particular de esta empresa es conveniente
adquirir un software a medida, que se adapte a sus necesidades y procesos,
tomando en cuenta la factibilidad operativa y financiera de la empresa.
Es fundamental el desarrollo del prototipo siguiendo una metodologa viable y
realizar un buen anlisis, ya que esta fase del ciclo de vida del desarrollo es la
base para las fases posteriores. Una eleccin adecuada de las herramientas con
las que se va a trabajar puede definir el xito de un proyecto y su adecuado uso
puede optimizar y reducir el tiempo de desarrollo.
Tambin es muy importante tener una buena comunicacin con las personas
involucradas en los procesos que se pretenden automatizar mediante el punto de
venta. La aprobacin del prototipo conllevara al desarrollo final del punto de venta
aadiendo nuevas funcionalidades que apoyen a tomas de decisin en un futuro.

39

Bibliografa
Abraham Silberschatz, H. F. (2002). Fundamentos de bases de datos. Madrid :
McGrawHill.
Afergan, M. (1997). Java soluciones instantaneas. Mxico: Prentice Hall.
C.V., A. R. (01 de 01 de 2008). SICAR, Toda una experiencia. Recuperado el 08
de 09 de 2015, de SICAR, Toda una experiencia: http://www.sicar.mx/
Community, N. (2000). NetBeans. Recuperado el 12 de Octubre de 2015, de
NetBeans: https://netbeans.org/
Conesa, M. J. (2013). Repositorio Bibliogrfico UPCT. Recuperado el 09 de
septiembre de 2015, de Repositorio Bibliogrfico UPCT:
http://repositorio.bib.upct.es/dspace/
Desarrollos, M. P. (01 de enero de 2002). MyBusiness POS Desarrollos, S.A. de
C.V. Recuperado el 9 de septiembre de 2015, de MyBusiness POS
Desarrollos, S.A. de C.V.: https://www.mybusinesspos.com/
Educacin, P. (2001). Introduccin a los sistemas de bases de datos. Mexico:
Pearson Educacin.
Kenneth E. Kendall, J. E. (2005). Anlisis t diseo de sistemas. Mexico: Pearson
Educacin.
Muoz, F. F. (2010). dcc.uchile. Recuperado el septiembre de 2015, de
dcc.uchile: http://users.dcc.uchile.cl/~lmateu/CC60H/Trabajos/jfernand/
Pressman, R. S. (2006). Ingeniera del software. Mxico: McGrawHill.
Sommerville, I. (2005). Ingeniera del software. Madrid: Pearson.

40

Anexos
Anexo 1.- Script de la base de datos para el punto de venta
-- MySQL Workbench Forward Engineering
SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,
FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE,
SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';
-- ------------------------------------------------------ Schema Puntodeventa
-- ----------------------------------------------------CREATE SCHEMA IF NOT EXISTS `Puntodeventa` DEFAULT CHARACTER SET utf8
COLLATE utf8_general_ci ;
USE `Puntodeventa` ;
-- ------------------------------------------------------ Table `Puntodeventa`.`Cuenta`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `Puntodeventa`.`Cuenta` (
`id_cuenta` INT NOT NULL COMMENT '',
`contrasea` VARCHAR(45) NULL COMMENT '',
`tipo` VARCHAR(45) NULL COMMENT '',
PRIMARY KEY (`id_cuenta`) COMMENT '')
ENGINE = InnoDB;
-- -----------------------------------------------------

41

-- Table `Puntodeventa`.`Empleado`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `Puntodeventa`.`Empleado` (
`id_empleado` INT NOT NULL AUTO_INCREMENT COMMENT '',
`nombre` VARCHAR(45) NULL COMMENT '',
`email` VARCHAR(45) NULL COMMENT '',
`direccion` VARCHAR(45) NULL COMMENT '',
`edad` INT NULL COMMENT '',
`telefono` INT(10) NULL COMMENT '',
`Cuenta_id_cuenta` INT NOT NULL COMMENT '',
PRIMARY KEY (`id_empleado`) COMMENT '',
INDEX `fk_Empleado_Cuenta_idx` (`Cuenta_id_cuenta` ASC) COMMENT '',
CONSTRAINT `fk_Empleado_Cuenta`
FOREIGN KEY (`Cuenta_id_cuenta`)
REFERENCES `Puntodeventa`.`Cuenta` (`id_cuenta`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `Puntodeventa`.`Cliente`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `Puntodeventa`.`Cliente` (
`id_cliente` INT NOT NULL AUTO_INCREMENT COMMENT '',
`nombre` VARCHAR(45) NOT NULL COMMENT '',
`rfc` VARCHAR(45) NULL COMMENT '',
`telefono` INT(10) NULL COMMENT '',

42

`email` VARCHAR(45) NULL COMMENT '',


`curp` VARCHAR(45) NULL COMMENT '',
PRIMARY KEY (`id_cliente`) COMMENT '')
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `Puntodeventa`.`Venta`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `Puntodeventa`.`Venta` (
`id_venta` INT NOT NULL AUTO_INCREMENT COMMENT '',
`fecha` DATE NULL COMMENT '',
`hora` TIME(6) NULL COMMENT '',
`total` DOUBLE NULL COMMENT '',
`subtotal` DOUBLE NULL COMMENT '',
`Empleado_id_empleado` INT NOT NULL COMMENT '',
`Cliente_id_cliente` INT NOT NULL COMMENT '',
PRIMARY KEY (`id_venta`) COMMENT '',
INDEX `fk_Venta_Empleado1_idx` (`Empleado_id_empleado` ASC) COMMENT
'',
INDEX `fk_Venta_Cliente1_idx` (`Cliente_id_cliente` ASC) COMMENT '',
CONSTRAINT `fk_Venta_Empleado1`
FOREIGN KEY (`Empleado_id_empleado`)
REFERENCES `Puntodeventa`.`Empleado` (`id_empleado`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Venta_Cliente1`
FOREIGN KEY (`Cliente_id_cliente`)
REFERENCES `Puntodeventa`.`Cliente` (`id_cliente`)
43

ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `Puntodeventa`.`Categoria`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `Puntodeventa`.`Categoria` (
`id_Categoria` INT NOT NULL AUTO_INCREMENT COMMENT '',
`nombre` VARCHAR(45) NULL COMMENT '',
PRIMARY KEY (`id_Categoria`) COMMENT '')
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `Puntodeventa`.`Producto`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `Puntodeventa`.`Producto` (
`id_producto` INT NOT NULL AUTO_INCREMENT COMMENT '',
`nombre` VARCHAR(45) NULL COMMENT '',
`precio_unitario` DOUBLE NULL COMMENT '',
`existencia` INT NULL COMMENT '',
`laboratorio` VARCHAR(45) NULL COMMENT '',
`caducidad` DATE NULL COMMENT '',
`imagen` LONGBLOB NULL COMMENT '',
`lote` VARCHAR(45) NULL COMMENT '',
`descripcion` VARCHAR(100) NULL COMMENT '',
`Categoria_id_Categoria` INT NOT NULL COMMENT '',
PRIMARY KEY (`id_producto`) COMMENT '',

44

INDEX `fk_Producto_Categoria1_idx` (`Categoria_id_Categoria` ASC)


COMMENT '',
CONSTRAINT `fk_Producto_Categoria1`
FOREIGN KEY (`Categoria_id_Categoria`)
REFERENCES `Puntodeventa`.`Categoria` (`id_Categoria`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `Puntodeventa`.`Proveedor`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `Puntodeventa`.`Proveedor` (
`id_Proveedor` INT NOT NULL AUTO_INCREMENT COMMENT '',
`nombre` VARCHAR(45) NULL COMMENT '',
PRIMARY KEY (`id_Proveedor`) COMMENT '')
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `Puntodeventa`.`Detalle_venta`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `Puntodeventa`.`Detalle_venta` (
`Venta_id_venta` INT NOT NULL COMMENT '',
`Producto_id_producto` INT NOT NULL COMMENT '',
`precio` DOUBLE NULL COMMENT '',
`cantidad` INT NULL COMMENT '',
`importe` DOUBLE NULL COMMENT '',
PRIMARY KEY (`Venta_id_venta`, `Producto_id_producto`) COMMENT '',

45

INDEX `fk_Venta_has_Producto_Producto1_idx` (`Producto_id_producto` ASC)


COMMENT '',
INDEX `fk_Venta_has_Producto_Venta1_idx` (`Venta_id_venta` ASC)
COMMENT '',
CONSTRAINT `fk_Venta_has_Producto_Venta1`
FOREIGN KEY (`Venta_id_venta`)
REFERENCES `Puntodeventa`.`Venta` (`id_venta`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Venta_has_Producto_Producto1`
FOREIGN KEY (`Producto_id_producto`)
REFERENCES `Puntodeventa`.`Producto` (`id_producto`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `Puntodeventa`.`Compras`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `Puntodeventa`.`Compras` (
`id_compras` INT NOT NULL AUTO_INCREMENT COMMENT '',
`fecha` DATE NULL COMMENT '',
`hora` TIME(6) NULL COMMENT '',
`subtotal` DOUBLE NULL COMMENT '',
`total` DOUBLE NULL COMMENT '',
`Proveedor_id_Proveedor` INT NOT NULL COMMENT '',
PRIMARY KEY (`id_compras`, `Proveedor_id_Proveedor`) COMMENT '',
INDEX `fk_Producto_has_Proveedor_Proveedor1_idx`
(`Proveedor_id_Proveedor` ASC) COMMENT '',
46

CONSTRAINT `fk_Producto_has_Proveedor_Proveedor1`
FOREIGN KEY (`Proveedor_id_Proveedor`)
REFERENCES `Puntodeventa`.`Proveedor` (`id_Proveedor`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- ------------------------------------------------------ Table `Puntodeventa`.`Detalle_compra`
-- ----------------------------------------------------CREATE TABLE IF NOT EXISTS `Puntodeventa`.`Detalle_compra` (
`id_detalle_compras` INT NOT NULL AUTO_INCREMENT COMMENT '',
`costo` DOUBLE NULL COMMENT '',
`cantidad` INT NULL COMMENT '',
`importe` DOUBLE NULL COMMENT '',
`Producto_id_producto` INT NOT NULL COMMENT '',
`Compras_id_compras` INT NOT NULL COMMENT '',
PRIMARY KEY (`id_detalle_compras`) COMMENT '',
INDEX `fk_Detalle_compra_Producto1_idx` (`Producto_id_producto` ASC)
COMMENT '',
INDEX `fk_Detalle_compra_Compras1_idx` (`Compras_id_compras` ASC)
COMMENT '',
CONSTRAINT `fk_Detalle_compra_Producto1`
FOREIGN KEY (`Producto_id_producto`)
REFERENCES `Puntodeventa`.`Producto` (`id_producto`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Detalle_compra_Compras1`
47

FOREIGN KEY (`Compras_id_compras`)


REFERENCES `Puntodeventa`.`Compras` (`id_compras`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

Anexo 2.- Diccionario de datos


Medicamento
Id medicamento

Guarda el nmero nico para el medicamento

Nombre

Guarda el nombre del medicamento

Sustancia activa

Contiene el nombre de la sustancia activa

Descripcin

Contiene una breve descripcin

Laboratorio

Almacena el nombre laboratorio que fabrica el


medicamento en una cadena.

Existencia

Guarda el nmero de existencias del mismo

Costo compra

medicamento.
Guarda

Precio Unitario

el

precio

en

que

se

compr

el

medicamentos (valor double)


Almacena el precio de venta al pblico del

Fecha de caducidad

medicamento (valor double)


Almacena

la

fecha

de

caducidad

Alta_medicamento()

medicamento.
Permite dar de alta un medicamento.

Baja_medicamento()

Permite dar de baja un medicamento.

Modificar_medicamento( Permite
)

modificar

los

atributos

de

del

un

medicamento en el inventario.
Guarda las modificaciones que se hacen en

Actualizar_medicamento Modificar_medicamento()
48

()

Muestra los medicamentos en base a los


parmetros:

Generar

Existencia, nombre, laboratorio y fecha de

Consultas_medicament

caducidad.

o()

Categora
Id categora

Contiene el nmero nico de categora para el

Nombre

inventario.
Almacena el nombre de la categora a la que

Alta_categoria()

pertenece una medicamento


Permite dar de alta una categora

Baja_categoria()

Permite dar de baja una categora

Modificar_categoria

Permite modificar los atributos de la Categora

()

Guarda las modificaciones que se hacen en

Actualizar_categoria

Modificar_categoria()

()

Muestra las categorias en base al Nombre

Consultas_categoria
()

Ventas
Id ventas

Guarda un valor nico de venta.

Medicamento

Contiene el nombre del medicamento vendido y


su descripcin

Cantidad

Contiene la cantidad de medicamento vendido

Fecha de venta

Almacena la fecha en que se efectu la venta

Subtotal

Contiene el subtotal (no incluye descuento o IVA)


de la venta (valor double)

IVA

Guarda el

Descuento

double)
Contiene

impuesto de valor agregado (valor


el

valor

del

descuento

de

un
49

Forma de pago

medicamento, si lo tiene

Total

Se elige si es efectivo o por tarjeta.


Cantidad total (incluye descuento o IVA) a pagar

Actualizar_inventario()

por el cliente
Modifica el stock dependiendo el medicamento y
cantidad vendido

Generar

Muestra las ventas en base a los parmetros:

Consultas_ventas()

Fecha de venta (da, mes o ao), Medicamento,


Forma de pago, Total

50

Compra
Id compra

Es valor entero para guardar el nmero nico

Fecha de compra

compra.

Medicamento

Contiene la fecha de compra de un medicamento

Proveedor

Guarda el nombre del medicamento comprado

Cantidad

Guarda el nombre del proveedor a quien se le hizo la

Total

compra.

Importe

Guarda la cantidad de medicamentos que se

Subtotal

compraron.

Total

Guarda el valor por la compra realizada.

de

En un valor doubl almacena el importe de la compra


Descuento

En un valor doubl guarda el subtotal por la compra

IVA

realizada.
En un valor doubl almacena el total por la compra

Forma de pago

de medicamentos
Contiene el valor del descuento de un medicamento,
si lo tiene
Guarda el impuesto de valor agregado (valor double)

Alta_compra()

Se elige si es efectivo o por tarjeta.


Permite dar de alta una compra

Modificar_compra()

Permite modificar los atributos de una compra

Actualizar_compra()

Permite guardar las modificaciones que se hacen en


Modificar_compra()y actualizar el inventario

Generar

Muestra las compras en base a los parmetros:

Consultas_compra()

Fecha

de

compra,

Medicamento,

Proveedor,

Cantidad, Total, Forma de pago

Conexin
con

Contiene un Objeto de la clase Conection


51

resultado

Contiene un Obejto tipo Resulset y guarda el


resultado de una consulta

sentencia

Contiene un objeto tipo Statement se usa para


enviar sentencias SQL a la base de datos

user

Almacena una cadena con el nombre del


usuario en la base de datos.

password

Almacena una cadena con la contrasea del


usuario en la base de datos.

Connection conectar()

Funcin que permite establecer la conexin

con la base de datos


ResultSet consultar(String Mtodo para realizar una consulta requiere de
sql)

una Sentencia SQL, y regresa un Objeto tipo


Resulset, contiene resultado de la consulta.
Cada elemento de la lista es uno de los

int

agregar(String

Object ...obj)

registros de la base de datos.


sql, Mtodo para realizar las inserciones en la
base de datos
instruccin SQL (INSERT) que se llevara a
cabo
obj valores a ingresar en las columnas

int

respectivas de la tabla
agregarimagen(String Mtodo para agregar imagen a una base de

sql,FileInputStream file,int datos


longitud, Object ...obj)

Sentencia SQL (INSERT) a la base de datos


file ruta donde se encuentra la imagen
longitud en bytes de la imagen

ImageIcon getFoto(String Mtodo para obtener la foto de una base de


sql)

datos y poder visualizarla en la aplicacin


Sentencia sql consulta a la base de datos
Regresa un objeto ImageIcon

52

53

Potrebbero piacerti anche