sistema para administraciÓn de la tienda “hadas …

OPCIÓN I

TESIS PROFESIONAL

QUE PARA OBTENER EL TÍTULO DE

INGENIERO INFORMÁTICO

PRESENTA:

ALEJANDRA OCÓN MENDOZA

ASESOR:

M. en C. JORGE GUADALUPE CASTELLANOS MORFÍN

CO-ASESORA:

Mtra. RAMONA EVELIA CHÁVEZ VALDEZ

VILLA DE ÁLVAREZ, COL., AGOSTO DE 2018

SISTEMA PARA ADMINISTRACIÓN DE LA TIENDA “HADAS

JOYERÍA FINA” Y LAS BASES DE DATOS DISTRIBUIDAS

Sistema para administración de la tienda “hadas joyería fina” y las bases de datos distribuidas

1


2

ÍNDICE

ÍNDICE DE FIGURAS .......................................................................................................... 3

Agradecimientos ..................................................................................................................... 5

Resumen .................................................................................................................................. 6

Capítulo I. Contexto del proyecto ........................................................................................... 8

1) Objetivos .................................................................................................................. 8

2) Justificación .............................................................................................................. 9

3) Problemas a resolver ................................................................................................ 9

4) Propuesta de solución ............................................................................................. 10

5) Hipótesis ................................................................................................................. 10

Capítulo II. Estado del Arte .................................................................................................. 13

Capítulo III. Metodología utilizada ...................................................................................... 20

Capítulo IV. Desarrollo de la propuesta ............................................................................... 24

1. Iniciación ................................................................................................................... 24

2. Elaboración ................................................................................................................ 27

3. Construcción .............................................................................................................. 56

4. Transición .................................................................................................................. 56

Capítulo V. Resultados ......................................................................................................... 58

El producto de software .................................................................................................... 58

Capítulo VI. Conclusiones y Recomendaciones ................................................................... 76

Fuentes de Información ........................................................................................................ 77


3

ÍNDICE DE FIGURAS

Figura 1: Modelo de base de datos distribuida ..................................................................... 10

Figura 2: Metodología Proceso Unificado Ágil (PUA) basado en el Proceso Unificado

Rational (RUP) ..................................................................................................................... 21

Figura 3: Modelo de negocios .............................................................................................. 29

Figura 4. Modelo de casos de uso “Abono” ......................................................................... 30

Figura 5: Modelo de casos de uso “Apartado” ..................................................................... 31

Figura 6: Modelo de casos de uso “Artículo” ....................................................................... 31

Figura 7: Modelo de casos de uso “Caja” ............................................................................. 32

Figura 8: Modelo de casos de uso “Cliente” ......................................................................... 32

Figura 9: Modelo de casos de uso “Crédito” ........................................................................ 33

Figura 10: Modelo de casos de uso “Devolución” ............................................................... 33

Figura 11: Modelo de casos de uso “Reparación” ................................................................ 34

Figura 12: Modelo de casos de uso “Traspaso” .................................................................... 34

Figura 13: Modelo de casos de uso “Usuario” ..................................................................... 35

Figura 14: Modelo de casos de uso “Venta” ......................................................................... 35

Figura 15: Modelo dominio “Abono” ................................................................................... 36

Figura 16: Modelo dominio “Apartado” ............................................................................... 36

Figura 17: Modelo dominio “Artículo” ................................................................................ 37

Figura 18: Modelo dominio “Caja” ...................................................................................... 37

Figura 19: Modelo dominio “Cliente” .................................................................................. 38

Figura 20: Modelo dominio “Crédito”.................................................................................. 38

Figura 21: Modelo dominio “Devolución” ........................................................................... 39

Figura 22: Modelo dominio “Reparación” ........................................................................... 39

Figura 23: Modelo dominio “Traspaso” ............................................................................... 39

Figura 24: Modelo dominio “Usuario” ................................................................................. 40

Figura 25: Modelo dominio “Venta” .................................................................................... 40

Figura 26: Modelo de clases ................................................................................................. 41

Figura 27: Modelo de datos "Abono" ................................................................................... 42

Figura 28: Modelo de datos "Apartado" ............................................................................... 43

Figura 29: Modelo de datos "Artículo" ................................................................................. 44

Figura 30: Modelo de datos "Caja" parte 1 de 2 ................................................................... 45

Figura 31: Modelo de datos "Caja" parte 2 de 2 ................................................................... 46

Figura 32: Modelo de datos "Cliente" .................................................................................. 47

Figura 33: Modelo de datos "Crédito" .................................................................................. 48

Figura 34: Modelo de datos "Devolución" ........................................................................... 49

Figura 35: Modelo de datos "Reparación" ............................................................................ 50

Figura 36: Modelo de datos "Traspaso" ............................................................................... 51

Figura 37: Modelo de datos "Usuario" ................................................................................. 52

Figura 38: Modelo de datos "Venta" .................................................................................... 53

Figura 39: Modelo de componentes ...................................................................................... 54

Figura 40: Modelo de despliegue .......................................................................................... 55

Figura 41: Inicio de sesión al sistema Hadas SW ................................................................. 58


4

Figura 42: Sección “Operaciones” del sistema Hadas SW ................................................... 60

Figura 43: Ventas de la sección “Operaciones” .................................................................... 61

Figura 44: Clientes de la sección “Operaciones” .................................................................. 61

Figura 45: Reparaciones de la sección “Operaciones” ......................................................... 62

Figura 46: Apartados de la sección “Operaciones” .............................................................. 62

Figura 47: Traspaso entrada de la sección “Operaciones” ................................................... 63

Figura 48: Traspaso salida de la sección “Operaciones” ...................................................... 63

Figura 49: Corte de caja de la sección “Operaciones” .......................................................... 64

Figura 50: Ajuste de inventario de la sección “Operaciones” .............................................. 64

Figura 51: Sección “Consultas” del sistema Hadas SW ....................................................... 65

Figura 52: Ventas de la sección “Consultas” ........................................................................ 66

Figura 53: Artículos de la sección “Consultas” .................................................................... 66

Figura 54: Notas de crédito de la sección “Consultas” ......................................................... 67

Figura 55: Traspaso entradas de la sección “Consultas” ...................................................... 67

Figura 56: Traspaso salida de la sección “Consultas” .......................................................... 68

Figura 57: Sección “Procesos” del sistema Hadas SW ......................................................... 69

Figura 58: Sección "Reportes" del sistema Hadas SW ......................................................... 70

Figura 59: Clientes de la sección “Reportes” ....................................................................... 71

Figura 60: Artículos de la sección “Reportes” ...................................................................... 71

Figura 61: Reporte de artículos por sucursal ........................................................................ 72

Figura 62: Movimiento de caja de la sección “Reportes” .................................................... 72

Figura 63: Sección “Configuración” del sistema Hadas SW ................................................ 73

Figura 64: Configuración de empresa ................................................................................... 74

Figura 65: Configuración de usuarios ................................................................................... 74


5

Agradecimientos

Doy gracias principalmente a mi familia por todo el esfuerzo y apoyo que me brindaron para

poder concluir mi educación superior.

También doy gracias a todos los docentes por sus enseñanzas y que siempre tuvieron la

disposición de brindar ayuda cuando fuera necesario.

Quiero agradecer de manera especial a la Mtra. Ramona Evelia Chaves Valdez, a mi asesor

de tesis él Mtro. Jorge Guadalupe Castellanos Morfin y al Ing. Jorge Esteban Gózales

Valladares por su tiempo y consejos para poder concluir satisfactoriamente el desarrollo de

esta tesis.


6

Resumen

En la actualidad se vive en un mundo donde la información es parte valiosa de los activos de

una organización, empresa o institución comercial o no comercial, por tal motivo su manejo

requiere de introducirse al mundo de la informática, para brindar un mejor servicio a quienes

necesitan hacer uso de ella para la buena toma de decisiones.

Ante esto, el inconveniente que se presenta es que la información que se administra en los

negocios crece a pasos agigantados y las bases de datos normales relacionales, no cumplen

con los requerimientos para satisfacer esta problemática, razón por la cual se tuvo la

necesidad de investigar y analizar la tecnología de gestión de bases de datos distribuidas en

sus clasificaciones más importantes las cuales permiten a los usuarios trabajar con grandes

volúmenes de datos con mayor rapidez.

Esta investigación tiene como objetivo recabar información de los beneficios que tiene el

implementar este tipo bases de datos distribuidas en el desarrollo de sistemas de información

automatizada que contemplan sucursales dentro de una empresa, independientemente cual

sea su giro. El caso de estudio que evaluamos es el negocio “Hadas Joyería Fina” una empresa

dedicada a la venta de mayoreo y menudeo de artículos de joyería, ropa y diversos accesorios.

Se tiene como resultado un sistema que permite la realización de ventas al mayoreo y

menudeo, apartados de artículos de los clientes, control de reparaciones de piezas dañadas,

asignación de artículos a crédito para los clientes frecuentes, así como también la devolución

de estos, además se pueden realizar traspasos de artículos entre las sucursales existentes.


7

Capítulo I.

Contexto del proyecto


8

Capítulo I. Contexto del proyecto

Introducción

Esta tesis presenta la información documental sobre los sistemas de bases de datos

distribuidas considerando el caso de estudio sistema para la administración de la tienda Hadas

Joyería Fina.

“Hadas Joyería Fina” es una empresa dedicada a la venta de mayoreo y menudeo de artículos

de joyería, ropa y diversos accesorios. Se conforma por dos sucursales, ambas ubicadas en

plaza San Fernando Colima, Col. y la matriz se encuentra en V. Carranza #1671 Local 1,

Residencial Esmeralda, Colima, Col.

Las ventas de menudeo se realizan al público en general y las ventas de mayoreo se realizan

únicamente a clientes con una línea de crédito ya autorizada. A estas últimas entre otros

beneficios se les otorga la oportunidad de realizar la devolución y/o apartados de artículos y

abonos al crédito, además de ofrecer una garantía de 15 días sobre artículos por defectos de

fábrica, se brinda un servicio de reparación con un costo adicional.

1) Objetivos

Objetivo general

Realizar un estudio de las bases de datos distribuidas y su impacto en los sistemas de

información desarrollados en redes locales o remotas, específicamente en el caso de

estudio de la aplicación desarrollada para la tienda “Hadas Joyería Fina” y sus

sucursales.

Objetivos específicos

• Analizar el comparativo de las ventajas y desventajas de implementar sistemas de

bases de datos centralizadas o distribuidas.

• Evaluar el impacto del uso de base de datos distribuidas en el diseño de sistemas de

información.

• Realizar el análisis de información de las actividades y procesos administrativos de

la empresa “Hadas Joyería Fina” con base a la implementación de una base de datos

distribuida.


9

2) Justificación

Este trabajo presenta un análisis para disminuir las necesidades en el manejo de información

y su manipulación a través de los sistemas de gestión de bases de datos distribuidas, con un

enfoque práctico, pero estableciendo un marco teórico que contribuye a la construcción de

modelos más robustos o soluciones alternas.

En la actualidad la tecnología en cuanto a gestores de bases de datos distribuidas a tomado

tanta fuerza que se han convertido en una buena opción, sin embargo, para realizar una

recomendación de cambiar de una de base de datos centralizada a una base de datos

distribuida, se deben considerar varios factores como el reducir costos o solucionar

problemas de escalabilidad, diseñar la representación del modelo, teniendo en cuenta que el

activo más importantes para una organización es la información y se corre el riesgo de perder

la credibilidad como profesional; de ahí nace la importancia de diseñar, ejecutar, valorar y

analizar pruebas que soporten las posibles recomendaciones que se pueden dar con respecto

a ventajas que posee un software de bases de datos distribuidas, ya que al crear un sistema

de información debe tomarse en cuenta las políticas y reglas que tenga la empresa o

exigencias de los usuarios.

Existen varias posibilidades que ofrece el mercado en cuanto a software libre, para este

estudio se han seleccionado las herramientas que han tenido mayor difusión, teniendo

presente la disponibilidad de utilidades que permitan a los usuarios una mejora de sus

procesos diarios, y presentarse como una alternativa viable y de calidad.

El sistema de información caso de estudio de esta tesis, fue desarrollado con software de

acceso libre, el lenguaje de programación Java, utilizando como herramienta de desarrollo

NetBeans 8.2.0 y MySQL como gestor de base de datos, lo que facilitó el desarrollo del

mismo.

3) Problemas a resolver

Hadas Joyería Fina manejaba sus registros mediante un sistema de gestión de información

centralizada, por el crecimiento de la tienda y el avance de la tecnología fue perdiendo

vigencia; por lo tanto, los principales problemas atendidos fueron la:

• Perdida de la integridad de la información de las bases de datos debido a la incorrecta

distribución de la información entre la matriz y las sucursales.

• Pérdida constante de la conexión a internet en las sucursales lo que provocaba

inconsistencia en la base de datos.


10

4) Propuesta de solución

Ante la problemática presentada la propuesta de solución contempló la realización de una

base de datos distribuidas como se muestra en la figura 1, esta habilita a cada sucursal tener

su propio repositorio en la cual se almacenarán los artículos existentes, ventas, apartados,

entre otros. Esto permite que mediante el uso de la red local la sucursal pueda seguir

realizando ventas y apartados sin necesidad de tener una conexión a internet.

A su vez, se cuenta con una base de datos general, cuya función principal es almacenar los

catálogos de clientes, sucursales, artículos, entre otros.

Cuando la conexión de la sucursal esté disponible se podrán realizar las transferencias de

artículos, así como actualización de los catálogos disponibles en la base de datos general.

5) Hipótesis

Para este estudio se define la siguiente hipótesis:

Las bases de datos distribuidas disminuyen la redundancia de datos en los

sistemas de información implementados en entidades económicas que operan en

lugares distantes.

La hipótesis anterior se apoya con las siguientes interrogantes:

¿Una tienda con sus sucursales puede operar con mayor eficiencia mediante una base de

datos distribuida?

¿Una tienda en su carácter de sucursal puede seguir realizando ventas y apartados sin

necesitar conexión a internet?

¿Una intranet resuelve el problema de conectividad interna?

Figura 1: Modelo de base de datos distribuida


11

¿En qué escenarios una base de datos distribuida es más conveniente que una base de datos

centralizada?

¿Es favorable el impacto de una base de datos distribuida en comparación a una base de datos

centralizada?


12

Capítulo II.

Estado del Arte


13

Capítulo II. Estado del Arte

En este capítulo se revisan los conceptos más actuales del contexto de las bases de datos y

las herramientas informáticas para su implementación.

La gestión de bases de datos ha evolucionado desde una simple aplicación informática hasta

la implementación en un entorno complejo, de tal manera que el estudio de ellas se vuelve

una parte esencial en el desarrollo de sistemas informáticos.

Definiendo las bases de datos, encontramos que son “un conjunto de datos almacenados sin

redundancia innecesarias en un soporte informático y accesible simultáneamente por

distintos usuarios y aplicaciones. Los datos deben de estar estructurados y almacenados de

forma totalmente independiente de las aplicaciones que la utilizan”, (Yera, 2014).

“Los datos son un componente fundamental de la base de datos, como se decía en la

definición están relacionados entre sí formando un conjunto con mínimas redundancias. Los

datos por si mismos no aportan conocimiento, hay que procesarlos y transformarlos”, (Yera,

2014).

“Otro componente son los sistemas de gestión de bases de datos, es un software o conjunto

de programas que permite crear y mantener una base de datos. El sistema gestor de base de

datos (SGBD) actúa como interfaz entre los programas de aplicación (usuarios) y el sistema

operativo. ”, (Yera, 2014). Es decir, proporciona un entorno para las personas que lo usan

para la recuperación y almacenamiento de la información.

Silberschatz, Korth, & Sudarshan (2002) definen un sistema de base de datos como una

colección de archivos y un conjunto de programas que permitan a los usuarios acceder y

modificar estos archivos. Uno de sus propósitos principales es proporcionar a los usuarios

una visión abstracta de los datos.

Arquitectura de los sistemas de base de datos.

“La arquitectura de los sistemas de bases de datos está enormemente influenciada por el

sistema informático subyacente en el que se ejecuta el sistema de bases de datos”,

(Silberschatz et. al.,2002).

Los sistemas de bases de datos pueden ser centralizados, donde solo una máquina funciona

como servidor, recibiendo las peticiones de múltiples maquinas clientes. Las bases de datos

distribuidas contemplan múltiples máquinas separadas geográficamente.

Silberschatz et. al (2002) definen los sistemas de bases de datos centralizadas y las

distribuidas como:


14

“Los sistemas de bases de datos centralizados son aquellos que se ejecutan en un

único sistema informático sin interaccionar con ninguna otra computadora.

Una base de datos distribuida es un conjunto de bases de datos parcialmente

independientes que (idealmente) comparten un esquema común y coordinan el

procesamiento de transacciones que acceden a datos remotos. Los procesadores se

comunican entre sí a través de una red de comunicación que gestiona el

encaminamiento y las estrategias de conexión.”

Las diferencias principales que existen entre estas dos arquitecturas de bases de datos son

que las distribuidas normalmente se encuentran en distintos lugares geográficos y se

administran de manera independiente. “Otra gran diferencia es que en un sistema distribuido

se dan dos tipos de transacciones, las locales y las globales”, (Silberschatz et. al.,2002).

“Una transacción local es aquella que accede a los datos del único sitio en el cual se

inició la transacción. Por otra parte, una transacción global es aquella que, o bien

accede a los datos situados en un sitio diferente de aquel en el que se inició la

transacción, o bien accede a datos de varios sitios distintos”, (Silberschatz et.

al.,2002).

Existen dos principales tipos de redes de comunicación, las redes de área local(LAN) y las

redes de área amplia (WAN).

"Las redes de área local conectan nodos que están distribuidos sobre áreas geográficas

pequeñas tales como un único edificio o varios edificios adyacentes. Las redes de área

amplia conectan nodos a lo largo de una extensa área geográfica. Hoy en día, la red

de área amplia más extensa que se utiliza es Internet” (Silberschatz et. al.,2002).

Silberschatz et. Al (2002) mencionan las siguientes razones para construir sistemas

distribuidos de bases de datos:

• Compartimiento de los datos:

Permite a los usuarios tener acceso a los datos que residen en otras ubicaciones.

• Autonomía:

La capacidad de cada ubicación por mantener un control sobre los datos almacenados

de manera local.

• Disponibilidad:

Los sitios restantes pueden continuar trabajando en caso de una falla en un sitio.


15

Silberschatz et. Al (2002) también mencionan los inconvenientes de construir una base de

datos con entorno distribuido:

• Costo del desarrollo del software:

Esto debido a la complejidad de implementación de un sistema distribuido.

• Probabilidad de errores:

Es más difícil asegurarse del funcionamiento durante los fallos por parte del sistema.

• Sobrecarga de procesamiento:

La comunicación entre distintos sitios puede conseguir sobrecarga, esto no sucede en

los sistemas centralizados.

Modelado

“Los modelos de análisis representan los requerimientos del cliente mediante la ilustración

del software. Los modelos de diseño representan características del software que ayudan a

los profesionales a elaborarlo con eficacia”, (Pressman, 2010, p.90).

“El lenguaje de modelado unificado (UML, Unified Modeling Language) es un estándar

propuesto para la creación de especificaciones de varios componentes de un sistema

software”, (Silberschatz et. al.,2002).

Modelo de datos

“Bajo la estructura de la base de datos se encuentra el modelo de datos: una colección de

herramientas conceptuales para describir los datos, las relaciones, la semántica y las

restricciones de consistencia”, (Silberschatz et. al.,2002).

Sistema gestor de base de datos

“Un sistema de bases de datos proporciona un lenguaje de definición de datos para especificar

el esquema de la base de datos y un lenguaje de manipulación de datos para expresar las

consultas a la base de datos y las modificaciones”, (Silberschatz et. al.,2002).

MySQL es un sistema de gestión de bases de datos relacionales de fuente abierta.


16

Lenguaje de programación

Java es un conjunto de software y especificaciones que proporciona un sistema para

desarrollar software de aplicaciones y desplegarlo en un entorno informático

multiplataforma.

“Java puede reducir costos, impulsar la innovación y mejorar los servicios de aplicaciones

como el lenguaje de programación de elección para IoT, arquitectura empresarial y

computación en la nube”, (Oracle, s.f.).

NetBeans es una herramienta para el desarrollo de aplicaciones de escritorio, móviles y web,

usando el lenguaje de programación Java, JavaScript, HTML5, PHP, C / C ++, entre otros.

Además, es gratuito y de código abierto.

Diseño para un mejor rendimiento

La etapa diferenciadora entre el diseño de una base de datos centralizada y una base de datos

distribuidos que menciona Benavides (2015) en su tesis, es el diseño de la distribución, esta

consta de dos actividades:

• Fragmentación:

Cómo y en qué partes se divide la base de datos.

• Asignación:

Dónde está ubicada cada parte de la base de datos, así como si tendremos replicación

de datos.

Benavides (2015) también especifica los aspectos a considerar en el diseño de una BD

distribuida:

• Fragmentación:

Una relación puede ser dividida en un número de sub-relaciones, denominadas

fragmentos, los cuales son entonces distribuidos.

• Asignación:

Cada fragmento debe ser almacenado en un sitio en base a una distribución óptima.

• Replicación:

El SGBD puede mantener una copia de un fragmento en diferentes sitios.

“Existen algunas reglas a considerar adicionalmente para la implementación de la base de

datos de manera distribuida” (Benavides, 2015).

Todas las reglas no son independientes entre sí, ni tienen igual importancia, pero son útiles

para entender la tecnología distribuida.


17

1. Autonomía local.

Los sitios de un sistema distribuido deben ser autónomos.

▪ Propietario local

▪ Administración local

▪ Integración local

▪ Represabilidad local

▪ Integración local

2. No dependencia de un sitio central.

No debe existir en único sitio, ya que implicaría:

▪ Cuello de botella

▪ Vulnerabilidad

3. Operación continúa.

▪ Adición de elementos

▪ Actualización de versiones

4. Independencia de Localización.

▪ El usuario desconoce dónde están físicamente los datos

5. Independencia de fragmentación.

▪ Deseable porque simplifica los programas de los usuarios y sus actividades en la

terminal

6. Independencia de réplica.

▪ La creación y destrucción de réplicas debe hacerse transparente al usuario

7. Procesamiento distribuido de consultas.

▪ Los sistemas relacionales brindan herramientas de consulta muy eficientes

▪ Varias maneras de trasladar los datos

8. Manejo distribuido de transacciones.

▪ Transacción distribuida: varios agentes de la transacción en varios lugares.

▪ Control de recuperación: una transacción atómica. Todos los agentes avanzan o

retroceden juntos.

▪ Control de recurrencia: Bloqueo mediante pasos de mensaje.

9. Independencia con respecto al equipo.

▪ El SGBD se ejecutará igual sea cual sea el equipo


18

10. Independencia con respecto al Sistema Operativo.

▪ El SGBD debe ser multioperativo sin afectar al usuario

11. Independencia con respecto a la Red.

▪ EL SGBD debe ser multioperativo sin afectar al usuario

Tal como se presentó, las bases de datos distribuidas requieren ser diseñadas considerando

aspectos prioritarios como:

• Manejo de transacciones globales y locales.

• Replicación de datos.

• Acceso a los datos desde otras ubicaciones.

• Control sobre los datos almacenados desde cada ubicación.

• Independencia con respecto a la conexión a internet.

• En caso de fallo en un sitio, los demás sitios pueden continuar trabajando.

Estas bases de datos se utilizan cuando una empresa se encuentra distribuida, ya sea de

manera lógica (divisiones, departamentos, etc.) o de manera física (sucursales, plantas, etc.).


19

Capítulo III.

Metodología utilizada


20

Capítulo III. Metodología utilizada

Para este estudio se utilizó investigación documental e investigación aplicada. La primera

por que se consultó en libros, tesis y artículos a fines al tema tratado. La segunda porque con

el caso de estudio se resuelve un problema del entorno productivo.

Hernández (2014) define la investigación como “un conjunto de procesos sistemáticos,

críticos y empíricos que se aplican al estudio de un fenómeno o problema”.

“La investigación documental” es un proceso basado en la búsqueda, recuperación, análisis,

crítica e interpretación de datos secundarios, es decir, los obtenidos y registrados por otros

investigadores en fuentes documentales, (Arias, 2006).

Arias (2006) sugiere utilizar las siguientes etapas para realizar la investigación documental:

1. Búsqueda y exploración de fuentes.

2. Lectura inicial de los documentos disponibles.

3. Elaboración de esquema preliminar o tentativo.

4. Recolección de datos mediante lectura evaluativa, fichaje y resumen.

5. Análisis e interpretación de la información recolectada en función del esquema

preliminar.

6. Formulación del esquema definitivo y desarrollo de los capítulos.

7. Redacción de la introducción y conclusiones.

8. Revisión y presentación del informe final.

La investigación aplicada como menciona Ander (s.f.) busca el conocer para hacer, para

actuar (modificar, mantener, reformar o cambiar radicalmente algún aspecto de la realidad

social). Le preocupa la aplicación inmediata sobre una realidad circunstancial antes que el

desarrollo de teorías.

Por otro lado, como metodología para el desarrollo del sistema de información se utilizó la

metodología Proceso Unificado Ágil (PUA) basado en el Proceso Unificado Rational (RUP).

PUA se basa en disciplinas y entregables incrementales con el tiempo. El ciclo de vida en

proyectos grandes es serial mientras que en los pequeños es iterativo (Figueroa R, Solís C,

Cabrera A, 2008).

RUP provee un acercamiento disciplinado para asignar tareas y responsabilidades dentro de

una organización de desarrollo (Figueroa R, et al., 2008).


21

La figura 2 muestra la metodología PUA y en ella se observan cuatro fases y siete disciplinas.

Cada fase incluye una o más iteraciones de las disciplinas consideradas. Así se tiene que la

fase de iniciación se trabaja principalmente con el modelo del sistema y la captura de

requisitos en el entorno que se desarrollará el proyecto.

En la fase de elaboración se trabaja principalmente los modelos de análisis y diseño

representados a través del Lenguaje Unificado de Modelado (UML). Schmuller define UML

como una herramienta de la actualidad para el desarrollo de sistemas, ya que permite generar

diseños que capturen ideas de forma convencional y fácil de comprender para comunicarlas

a otras personas, (Schmuller, s.f.).

En la fase de construcción se implementaron las funcionalidades del sistema establecidas en

el análisis y la base de datos previamente diseñada. Al principio se optó por el modelo de

base de datos centralizada con base al modelo de datos realizado. Esto ocasionó problemas

como la redundancia de datos y el control de inventario y ventas por sucursal. Así mismo, el

elegir este modelo de base de datos, la sucursal debía depender en todo momento de la

conexión a internet, lo cual es una de las problemáticas principales.

Se implementó una base de datos distribuida, como describe Mallea (2016) la tecnología

Bases de Datos Distribuidas es la unión de dos tipos de procesamientos de datos: sistemas de

bases de datos y la tecnología de redes. Los sistemas de bases de datos es un paradigma de

procesamiento de datos en el cual cada aplicación gestiona sus datos. La tecnología de redes

es el soporte que permite integrar a todos los datos. Las bases de datos distribuidas se utilizan

cuando una empresa se encuentra distribuida, ya sea de manera lógica (divisiones,

departamentos, etc.) o de manera física (sucursales, plantas, etc.), por lo tanto, es ideal para

Figura 2: Metodología Proceso Unificado Ágil (PUA) basado en el Proceso

Unificado Rational (RUP)


22

trabajarla con la empresa “Hadas Joyería Fina” ya que está conformada por una matriz y dos

sucursales.

Finalmente se descartó utilizar una base de datos centralizada y se optó por implementar una

base de datos distribuida debido a las siguientes razones:

• Base de datos independiente en cada sucursal.

• Mejor control y manejo de datos en cada sucursal, así como mayor rapidez en la

consulta de éstos.

• Las computadoras de cada sucursal mantienen una conexión una red local, así si se

pierde la conexión a internet el sistema puede seguir en uso, con excepción del envío

y confirmación de traspasos.

En la fase de Transición se realizó el despliegue del sistema en modo operacional en versión

alfa y se capacitó a los empleados.


23

Capítulo IV.

El sistema de administración

de la tienda “Hadas Joyería

Fina”


24

Capítulo IV. Desarrollo de la propuesta

El Proceso Unificado Rational (RUP) es un modelo en fases que identifica cuatro diferentes

en el proceso del software.

Sommerville (2005) describe las 4 fases de RUP como:

• Inicio.

Se deben identificar todas las entidades externas (personas y sistemas) que

interactuarán con el sistema y definir estas interacciones.

• Elaboración.

El objetivo es desarrollar una comprensión del dominio del problema, establecer un

marco de trabajo arquitectónico para el sistema, desarrollar el plan del proyecto e

identificar los riesgos clave del proyecto.

• Construcción.

Comprende el diseño del sistema, la programación y las pruebas.

• Transición.

Mover el sistema desde la comunidad de desarrollo a la comunidad del usuario y

hacerlo trabajar en un entorno real.

Por otro lado, PUA se basa en disciplinas y entregables incrementales con el tiempo. El ciclo

de vida en proyectos grandes es serial mientras que en los pequeños es iterativo (Figueroa R,

Solís C, Cabrera A, 2008).

Las actividades realizadas para el desarrollo del proyecto se apegan a la metodología PUA

(Proceso Unificado Ágil) basada en RUP (Proceso Unificado Rational), empleada para

controlar el proceso de ingeniería de software, se trabajó en las cuatro fases (ver figura 2),

hasta la versión alfa en la fase de Transición.

1. Iniciación

La fase de Iniciación tuvo una sola iteración y sirvió para definir con el cliente los

requerimientos del sistema y el alcance de éste.

Actividades realizadas:

• Identificar de proceso de la empresa.

• Obtener de requerimientos con base a las necesidades de la empresa y entrevistas al

cliente.

Procesos de la empresa identificados

• Realización de venta a mayoreo o menudeo.


25

• Abonos realizados por los clientes.

• Asignación de apartados a clientes.

• Manejo de artículos por sucursal.

• Operación de caja.

• Directorio de clientes.

• Créditos asignados a los clientes.

• Devoluciones de artículos realizada por los clientes.

• Gestión de reparaciones de piezas defectuosas.

• Traspasos de artículos realizados de usa sucursal a otra.

• Control de usuarios y asignación de roles.

Requerimientos obtenidos

El objetivo del modelado de los requerimientos es crear varias representaciones que

describan lo que necesita el cliente, establecer una base para generar un diseño de software

y definir un conjunto de requerimientos que puedan ser validados una vez construido el

software (Pressman, 2010, p,155).

• Requisitos funcionales

Requisito 1. El sistema debe permitir al usuario agregar y/o cancelar abonos sobre un

crédito en específico del cliente.

Requisito 2. El sistema debe permitir al usuario agregar y/o cancelar abonos en los

artículos apartados.

Requisito 3. El sistema debe mostrar los abonos realizados por cliente.

Requisito 4. El sistema debe permitir a los usuarios agregar y/o cancelar apartados de

artículos de los clientes.

Requisito 5. El sistema debe mostrar los apartados liquidados y sin liquidar de los clientes

con los siguientes datos: fecha de apartado, cantidad de artículos, descripción

de artículo, importe, cantidad abonada, saldo restante a liquidar y fecha de

vencimiento del apartado.

Requisito 6. El sistema debe mostrar al usuario los artículos existentes con sus datos

como clave, descripción, categoría, existencia, precio mayoreo, precio

menudeo y existencia.

Requisito 7. El sistema debe permitir a los administradores agregar, editar y/o eliminar

artículo.

Requisito 8. El sistema debe permitir al administrador importar un archivo de Excel con

fin de agregar nuevos artículos a la base de datos.

Requisito 9. El sistema debe permitir exportar en un documento Excel con el inventario

de esa sucursal.


26

Requisito 10. El sistema debe permitir al usuario activo realizar el corte de caja y

posteriormente generar un ticket con información detallada.

Requisito 11. El sistema debe almacenar en la nube el corte diario de cada caja.

Requisito 12. El sistema debe permitir buscar los todos movimientos realizados en una

fecha específica. Se toma como movimiento: ventas, créditos, traspasos de

entrada y de salida, apartados, liquidaciones y reparaciones, así como las

posibles cancelaciones de cualquiera de estas operaciones.

Requisito 13. El sistema debe permitir buscar los cortes de caja realizados en una fecha

determinada.

Requisito 14. El sistema debe mostrar el directorio de clientes.

Requisito 15. El sistema debe permitir al usuario agregar, editar o eliminar clientes.

Requisito 16. El sistema debe permitir al usuario la búsqueda clientes.

Requisito 17. El sistema debe permitir al usuario consultar las notas de crédito liquidadas

y sin liquidar con los siguientes datos: fecha, folio, cliente, total, usuario,

numero de nota.

Requisito 18. El sistema debe permitir al usuario cancelar notas de crédito.

Requisito 19. El sistema debe permitir al usuario la realizar devolución de artículos

asignados a un crédito.

Requisito 20. El sistema debe permitir al usuario cancelar devoluciones

Requisito 21. El sistema debe permitir agregar y/o cancelar reparaciones de piezas

incluyendo la descripción del articulo a reparar, descripción de la reparación

y nombre del cliente u origen.

Requisito 22. El sistema debe permitir dar salida a artículos en reparación al entregarse a

sus clientes

Requisito 23. El sistema debe permitir realizar búsqueda por nombre de cliente o folio en

los artículos de reparación

Requisito 24. El sistema debe mostrar y editar las reparaciones y su estado (en reparación,

listo, entregado o no se logró reparar)

Requisito 25. El sistema debe filtrar las reparaciones respecto a su estado

Requisito 26. El sistema debe permitir al usuario enviar y/o cancelar traspasos de artículos

desde una sucursal a otra, este traspaso tendrá los datos: folio, destino,

descripción artículos de traspaso (cantidad, código, descripción y precio).

Requisito 27. El sistema debe permitir al usuario aceptar y/o cancelar el traspaso de

artículos desde la sucursal destino.

Requisito 28. El sistema debe permitir consultar a detalle los traspasos de salida realizados

en una fecha determinada.

Requisito 29. El sistema debe permitir al administrador consultar a detalle los traspasos

entrantes aceptados y cancelados en una fecha determinada.

Requisito 30. El sistema debe permitir al administrador agregar, editar y modificar los

datos de la empresa, así como también sus sucursales.

Requisito 31. El sistema debe permitir al administrador agregar, editar y eliminar usuarios.


27

Requisito 32. El sistema debe permitir al administrador asignar un rol a cada usuario.

Requisito 33. El sistema debe permitir al usuario realizar venta.

Requisito 34. El sistema debe permitir al usuario cancelar una venta.

Requisito 35. El sistema debe permitir al usuario seleccionar el tipo de cliente al que se le

realizará la venta, con el fin de asignar el tipo de precio definido para este.

Requisito 36. El sistema debe permitir elegir qué tipo de documento se va a imprimir al

realizar la venta, ya sea ticket o nota de crédito.

Requisito 37. El sistema debe permitirle al usuario ingresar el código de barras del articulo

para cargarlo en la venta.

Requisito 38. El sistema debe permitir al usuario buscar un artículo por nombre y

seleccionarlo para cargarlo a la venta.

Requisito 39. El sistema debe permitir remover artículos de la venta actual.

Requisito 40. El sistema mostrara una lista de los artículos de la venta actual con su

cantidad, descripción, precio unitario y precio total.

Requisito 41. El sistema debe mostrar una ventana de pago donde se registre la cantidad y

su manera de pago, este puede ser de contado, tarjeta de crédito/débito, vales,

cheques y/o traspaso bancario.

Requisito 42. El sistema debe permitir consultar todas las ventas realizadas en un tiempo

determinado

• Requisitos no funcionales

Requisito 1. En el sistema se debe mostrar en todo momento el nombre del negocio y su

logotipo.

Requisito 2. El sistema debe generar tickets con el nombre del negocio, logotipo, dirección

y teléfono.

Requisito 3. Las notas de ventas deben tener como encabezado con el nombre y logotipo

del negocio, numero de nota de venta, fecha y nombre de la clienta. En el

cuerpo debe incluir la cantidad de artículos y descripción, precio unitario y

precio final. Al final del documento se imprime un pagaré por la cantidad total

de la nota de venta y un espacio para la firma del cliente.

Requisito 4. El color principal del sistema debe ser blanco con rosa.

Requisito 5. El sistema debe incluir un botón de sincronización con la nube para

sincronizar en el momento que se desee o en el momento que exista una

conexión a internet.

2. Elaboración

En la fase de Elaboración se modeló la arquitectura del sistema que se evidenció con los

diagramas de negocio, casos de uso, dominio, clases, datos, componentes y despliegue.


28

Esta fase constó de 11 iteraciones, ya que los modelos de casos de uso, dominio y datos

fueron realizados por cada uno de los procesos identificados de la empresa, éstos se mostrarán

por el siguiente orden:

1. Abono

2. Apartado

3. Artículo

4. Caja en operación

5. Cliente

6. Crédito

7. Devolución

8. Reparación

9. Traspaso

10. Usuario

11. Venta


• Realizar los siguientes modelos UML

o Modelo de negocio

o Modelo de casos de uso

o Modelo de dominio

o Modelo de clases

o Modelo de datos

o Modelo de componentes

o Modelo de despliegue

Modelo de negocio

El modelo de procesos de negocio describe el comportamiento y los flujos de información

dentro la empresa “Hadas Joyería Fina”. Éste captura los eventos significativos, entradas,

recursos, procesos y salidas asociados con el proceso de negocio relevante que son las ventas

al mayoreo y menudeo (Ver figura 3).


29

Figura 3: Modelo de negocios

analysis Modelo de negocio

Nota de crédito

Realizar ventas a mayoreo y menudeoSolicitud de una

compra

Ticket de venta

Catálogo de clientes

Caja en operación

Catálogo de artículos


30

Modelo de casos de uso

Un modelo de caso de uso describe la funcionalidad propuesta de un nuevo sistema. Un caso

de uso representa una unidad de interacción discreta entre un usuario (humano o máquina) y

el sistema (Systems, 2018).

Se muestra como las actividades de solicitud de abono, cancelación y registro interactúan

con los actores cliente, usuario y sistema (Ver figura 4).

Figura 4. Modelo de casos de uso “Abono”

En el caso de uso “apartado” se muestran las actividades del registro del apartado y como

afectan al sistema, así como también la cancelación de este proceso (Ver figura 5).

uc Abono

Abono

Registrar abono a cliente

Usuario

(from Actores)

Sistema

(from Actores)

Agregar abono a la nota de crédito

Incrementar el crédito disponible al

cliente

Solicitar abono

Cancelar abono

Cliente

(from Actores)

«include»

«include»


31

Figura 5: Modelo de casos de uso “Apartado”

El administrador es el único que se encarga de agregar, modificar o eliminar los artículos en

el inventario (Ver figura 6).

Figura 6: Modelo de casos de uso “Artículo”

uc Apartado

Apartado

Usuario

Registrar apartado de artículos

Verificar el crédito disponible del

clienteSistema

Disminuir el crédito del cliente

Cancelar apartadoAumentar el crédito

del cliente

«extend»

«include»

«include»

uc Artículo

Artículo

Administrador

(from Actores)

Actualizar los datos del artículo

Mostrar artículos por sucursal

Registrar artículos por sucursal

Sistema

(from Actores)

Importar / Exportar inventario en Excel


32

La caja en operación realiza las funciones de inicialización y corte, ésta debe generar un

ticket con los detalles de operación realizados por el usuario (empleado) en turno (Ver figura

7).

Figura 7: Modelo de casos de uso “Caja”

El usuario tiene las funciones de registrar un nuevo cliente, así como también modificar sus

datos y el sistema se encarga almacenar esa información (Ver figura 8).

Figura 8: Modelo de casos de uso “Cliente”

uc Caja

Caja en operación

Usuario

(from Actores)

Inicializar la caja

Realizar corte de caja

Ticket detallado de corte de caja

Almacenar el corte de la caja

Sistema

(from Actores)

uc Cliente

Cliente

Usuario

(from Actores)

Registrar cliente en el sistema

Mostar directorio de clientes

Sistema

(from Actores)

Actualizar datos de los clientes


33

El usuario se encarga del registro de artículos para agregar a crédito a un cliente, también

podría cancelar este crédito si es necesario. El sistema se encarga de verificar si el cliente

cuenta con crédito disponible para ejecutar el proceso y si es así disminuir el crédito

disponible (Ver figura 9).

Figura 9: Modelo de casos de uso “Crédito”

El usuario se encarta de registrar las devoluciones, hacer las consultas de las notas de crédito.

El cliente realiza un pago de los artículos que no se realizó la devolución. Es responsabilidad

de sistema aumentar el crédito disponible al ejecutarse estos procesos (Ver figura 10).

Figura 10: Modelo de casos de uso “Devolución”

uc Crédito

Crédito

Usuario

(from Actores)

Registrar artículos en una nota de crédito

Comprobar el crédito disponible

Disminuir el crédito disponible

Sistema

(from Actores)

Cancelar notas de crédito

Aumentar el crédito disponible

«extend»

«include»

«include»

uc Devolución

Devolución

Agregar el valor de la devolución al crédito

disponible

Realizar pago del valor total de la nota de crédito menos la devolución de

artículos

Registrar devolución de articulos correspondiente

a la nota de crédito

Sistema

(from Actores)

Cliente

(from Actores)

Usuario

(from Actores)

Consultar las notas de crédito

«include»


34

EL usuario registra una pieza para su reparación para así la persona de mantenimiento

considere esos datos para la reparación ésta. El de mantenimiento debe de dar de alta la pieza

para que el cliente pueda proceder a realizar el pago correspondiente a este servicio (Ver

figura 11).

Figura 11: Modelo de casos de uso “Reparación”

El usuario de la sucursal origen se encarga de capturar los artículos para enviar como

traspaso. El usuario de la sucursal destino se encargará de confirmar o en su caso realizar la

cancelación de dicho traspaso. El sistema debe actualizar en el inventario de la sucursal

(Ver figura 12).

Figura 12: Modelo de casos de uso “Traspaso”

uc Reparación

Reparación

Registar una reparación de pieza

de un cliente

Usuario

(from Actores)

Notificar pieza reparada

Realiza pago por reparación de la pieza

Cliente

(from Actores)

Mantenimiento

(from Actores)

uc Traspaso

Traspaso

Usuario

(from Actores)

Ingresar artículos para enviar como

traspaso a otra sucursal

Confirmar traspaso desde otra sucursal

Mostrar todos los traspasos, ya sean

confirmados o cancelados

Sistema

(from Actores)


35

El administrador es el único con acceso para registrar usuarios y asignarles roles (Ver

figura 13).

Figura 13: Modelo de casos de uso “Usuario”

El usuario se encarga de realizar las ventas seleccionando un cliente en específico, es

responsabilidad del sistema retornar el precio ya sea de mayoreo o menudeo según el

cliente seleccionado, así como actualizar el inventario al realizar este proceso. Al cliente le

corresponde realizar el pago del monto total (Ver figura 14).

Figura 14: Modelo de casos de uso “Venta”

uc Usuario

Usuario

Registrar usuario

Administrador

(from Actores)

Asignar roles a los usuarios

Actualizar usuarios

Sistema

(from Actores)

uc Venta

Venta

Registra una venta

Realiza pago en efectivo, tarjeta, vales, cheque o transferencia bancaria

Usuario

(from Actores)

Público General

(from Actores)

Cliente

(from Actores)

Asignar el precio de mayoreo o menudeo

Sistema

(from Actores)

Cancelar ventaActualizar inventario

«extend»

«include»

«include»


36

Modelo de dominio

El modelo de dominio es una vista de todos los objetos que hacen un área de interés, y sus

relaciones. Se usa para capturar los objetos significativos dentro de un sistema, organización

o cualquier dominio de destino.

Un cliente realiza un abono, este se aplica al crédito teniendo como resultado un ticket (Ver

figura 15).

Figura 15: Modelo dominio “Abono”

El apartado pertenece a un cliente y a un solo crédito, este puede contener uno o muchos

artículos (Ver figura 16).

Figura 16: Modelo dominio “Apartado”

Los artículos pueden estar asignados en todas las sucursales, estos pertenecen a una categoría

y a un departamento (Ver figura 17).

class Abono

Abono Crédito

Documento

Cliente1

realiza

1 1

aplica

1

1

genera

1

class Apartado

Apartado

Cliente

Artículo

Crédito

1

lo conforma

1..*

1

pertenece

1

1

se asigna a

1


37

Figura 17: Modelo dominio “Artículo”

La caja se encarga de registrar apartados, ventas, traspasos, créditos abonos y reparaciones.

Al realizar el corte de caja se genera un documento (Ver figura 18).

Figura 18: Modelo dominio “Caja”

El cliente puede solicitar ventas, apartados, devoluciones y reparaciones (Ver figura 19).

class Artículo

Artículo

Sucursal

Categoría Departamento

1

asignado1..*

1pertenece

1

1

pertenece1

class Caja

Caja

Venta

Traspasos

Crédito

Abonos

Apartado

Reparación

Corte de Caja

1

genera

1..*

1 registra

1..*

1

registra 1..*

1

registra

1..*

1

registra

1..*

1

registra 1..*1

registra1..*


38

Figura 19: Modelo dominio “Cliente”

El cliente puede tener muchos créditos y realizar abonos a estos (Ver figura 20).

Figura 20: Modelo dominio “Crédito”

La devolución pertenece únicamente a un cliente y contiene uno o muchos artículos (Ver

figura 21).

class Cliente

Cliente

Crédito

Venta

Apartado

Devolución

Reparación

1

se asigna

1

1

solicita

1

1

solicita

1

1

realiza

1

1

solicita

1

class Crédito

Crédito

Cliente

Abonos

Venta

Nota de Crédito A

1

contiene

1

1..*

pertenece

1

1

recibe

1..*

1genera

1

1

realiza

1..*


39

Figura 21: Modelo dominio “Devolución”

Las reparaciones pertenecen a un cliente, se realizan en una sucursal y puede generar un pago

(Ver figura 22).

Figura 22: Modelo dominio “Reparación”

Una sucursal origen realiza un traspaso a una sucursal destino, estos contienen artículos (Ver

figura 23).

Figura 23: Modelo dominio “Traspaso”

class Devolución

Devolución

Cliente

Artículo

1contiene

1..*

1

pertenece

1

class Reparación

Reparación

Cliente

Sucursal

Pago

Pieza

1

genera

1..*

1

pertenece

11

pertenece

1

1

contiene

1..*

class Traspaso

Traspaso Sucursal

Artículo

Sucursal1

dirigido

1

1

contiene

1..*

1

realiza

1


40

El usuario este asignado a una sucursal y le pertenece a un rol determinado. Puede registrar

ventas, abonos, apartados, reparaciones y traspasos (Ver figura 24).

Figura 24: Modelo dominio “Usuario”

Una sucursal puede tener una o muchas cajas en operación, estas generan ventas (Ver figura

25).

Figura 25: Modelo dominio “Venta”

class Usuario

Usuario

Sucursal Rol

Venta

Abono

Apartado

Reparación

Traspaso

Caja

1

realiza 1..*

1

registra

1..*

1

se asigna

1

1

registra1..*

1

le pertenece

1

1

registra1..*

1

está asignado

1

1

registra 1..*

class Venta

Sucursal

Venta

Caja

Artículos

Cliente

Pago

1

registra

1

1

tiene

1..*

1

genera

1

1contiene

1..*

1

genera

1..*


41

Modelo de clases

El modelo de clase es el núcleo del desarrollo y diseño orientado a objetos: expresa tanto el

estado persistente del sistema como el comportamiento del sistema. Una clase encapsula

estado (atributos) y ofrece servicios para manipular ese estado (comportamiento) (Systems,

2018) (Ver figura 26).

Figura 26: Modelo de clases

class Modelo de Clases

Artículo

+ Agregar(): void+ Eliminar(): void+ Modificar(): void

Abono

+ Agregar(): void+ Cancelar(): void

Apartado


Cliente


Crédito


Devolución


Reparación

+ Agregar(): void+ Eliminar(): void

Traspaso

+ Agregar(): void+ Cancelar(): void+ Confirmar(): void

Usuario


Venta


Departamento


Categoría


Sucursal


Caja de Operacion

+ Agregar(): void

TipoPago

Rol


42

Modelo de datos

El modelado de datos da la capacidad de representar objetos de datos, sus características y

relaciones (Pressman, 2010, p.142).

La base de datos fue desarrollada en MySQL. Éste es un sistema de gestión de base de datos

relacionales desarrollada por Oracle Corporation y es de fuente abierta.

Para una mejor apreciación del modelo de datos se realizaron por procesos (Ver figuras 27 a

38).

Figura 27: Modelo de datos "Abono"

dm Abono

Abono

«column»*PK idAbono: INT FK idCliente: INT FK idCredito: INT FK idCajaOperacion: INT FK idVenta: INT FK idApartado: INT FechaAbono: DATETIME Cantidad: FLOAT(0) TipoPago: INT Status: INT

«FK»+ FK_Abono_Apartado(INT)+ FK_Abono_CajaOperacion(INT)+ FK_Abono_Cliente(INT)+ FK_Abono_Credito(INT)+ FK_Abono_Venta(INT)

«index»+ IXFK_Abono_Apartado(INT)+ IXFK_Abono_CajaOperacion(INT)+ IXFK_Abono_Cliente(INT)+ IXFK_Abono_Credito(INT)+ IXFK_Abono_Venta(INT)

«PK»+ PK_Abono(INT)

Cliente::Cliente

«column»*PK idCliente: INT Nombre: CHAR(50) Telefono: VARCHAR(10) Correo: VARCHAR(50) Colonia: VARCHAR(50) Calle: VARCHAR(50) NoInterior: VARCHAR(10) NoExterior: VARCHAR(10) CP: VARCHAR(7) Estado: CHAR(10) Municipio: CHAR(30) Comentarios: VARCHAR(50) TipoPrecio: CHAR(20) LimiteCredito: INT

«PK»+ PK_Cliente(INT)

Credito::Credito

«column»*PK idCredito: INT FK idCliente: INT FK idVenta: INT FK idCajaOperacion: INT FechaGenerado: DATETIME FechaVencimiento: DATETIME Monto: FLOAT(0) Saldo: FLOAT(0) Status: INT

«FK»+ FK_Credito_CajaOperacion(INT)+ FK_Credito_Cliente(INT)+ FK_Credito_Venta(INT)

«index»+ IXFK_Credito_CajaOperacion(INT)+ IXFK_Credito_Cliente(INT)+ IXFK_Credito_Venta(INT)

«PK»+ PK_Credito(INT)

Apartado::Apartado

«column»*PK idApartado: INT FK idCliente: INT FK idCajaOperacion: INT FechaApartado: DATETIME FechaVencimiento: DATETIME Monto: FLOAT(0) Saldo: FLOAT(0)

«FK»+ FK_Apartado_CajaOperacion(INT)+ FK_Apartado_Cliente(INT)

«index»+ IXFK_Apartado_CajaOperacion(INT)+ IXFK_Apartado_Cliente(INT)

«PK»+ PK_Apartado(INT)

(idCredito = idCredito)

«FK»

(idCliente = idCliente)

«FK» (idCliente = idCliente)

«FK»

(idApartado = idApartado)

«FK»


«FK»


43

Figura 28: Modelo de datos "Apartado"

dm Apartado

Apartado





ApartadoArticulo

«column» FK idApartado: INT FK idArticulo: INT

«FK»+ FK_ApartadoArticulo_Apartado(INT)+ FK_ApartadoArticulo_Articulo(INT)

«index»+ IXFK_ApartadoArticulo_Apartado(INT)+ IXFK_ApartadoArticulo_Articulo(INT)

Cliente::Cliente



Abono::Abono





Articulo::Articulo

«column»*PK idArticulo: INT FK idCategoria: INT FK idDepartamento: INT Descripcion: VARCHAR(50) Menudeo: INT Mayoreo: INT Fecha: DATETIME Codigo: VARCHAR(15)

«FK»+ FK_Articulo_Categoria(INT)+ FK_Articulo_Departamento(INT)

«index»+ IXFK_Articulo_Categoria(INT)+ IXFK_Articulo_Departamento(INT)

«PK»+ PK_Articulo(INT)

(idArticulo = idArticulo)

«FK»


«FK»


«FK»


«FK»


«FK»


44

Figura 29: Modelo de datos "Artículo"

dm Articulo

Articulo





Categoria

«column»*PK idCategoria: INT NombreCategoria: VARCHAR(30)

«PK»+ PK_Categoria(INT)

Departamento

«column»*PK idDepartamento: INT NombreDepartamento: VARCHAR(50)

«PK»+ PK_Departamento(INT)

Caja::Sucursal

«column»*PK idSucursal: INT Nombre: VARCHAR(120) Calle: VARCHAR(120) NumExt: INT NumInt: VARCHAR(10) Colonia: VARCHAR(120) Municipio: VARCHAR(50)

«PK»+ PK_Sucursal(INT)

ArticuloSucursal

«column»*PK idArticuloSucursal: INT FK idArticulo: INT FK idSucursal: INT Existencia: INT Fecha: DATETIME

«FK»+ FK_ArticuloSucursal_Articulo(INT)+ FK_ArticuloSucursal_Sucursal(INT)

«index»+ IXFK_ArticuloSucursal_Articulo(INT)+ IXFK_ArticuloSucursal_Sucursal(INT)

«PK»+ PK_ArticuloSucursal(INT)

(idSucursal = idSucursal)

«FK»

(idDepartamento = idDepartamento)

«FK»

(idCategoria = idCategoria)

«FK»(idArticulo = idArticulo)

«FK»


45

Figura 30: Modelo de datos "Caja" parte 1 de 2

dm Caja

Sucursal



SucursalCaja

«column»*PK idSucursalCaja: INT FK idSucursal: INT FK idCaja: INT

«FK»+ FK_SucursalCaja_Caja(INT)+ FK_SucursalCaja_Sucursal(INT)

«index»+ IXFK_SucursalCaja_Caja(INT)+ IXFK_SucursalCaja_Sucursal(INT)

«PK»+ PK_SucursalCaja(INT)

Caja

«column»*PK idCaja: INT Nombre: VARCHAR(10)

«PK»+ PK_Caja(INT)

CajaOperacion

«column»*PK idCajaOperacion: INT FK idSucursalCaja: INT FK idUsuario: INT NombreSucursal: VARCHAR(50) NombreCaja: VARCHAR(10) Fondo: INT

«FK»+ FK_CajaOperacion_SucursalCaja(INT)+ FK_CajaOperacion_Usuario(INT)

«index»+ IXFK_CajaOperacion_SucursalCaja(INT)+ IXFK_CajaOperacion_Usuario(INT)

«PK»+ PK_CajaOperacion(INT)

CorteCaja

«column»*PK idCorteCaja: INT FK idCajaOperacion: INT FK idUsuario: INT FechaCorte: DATETIME TotalEfectivoCalculado: FLOAT(0) TotalTarjetaCalculado: FLOAT(0) TotalValesCalculado: FLOAT(0) TotalChequesCalculado: FLOAT(0) TotalTransferenciasCalculado: FLOAT(0) TotalCalculado: FLOAT(0) TotalEfectivoIngresado: FLOAT(0) TotalTarjetaIngresado: FLOAT(0) TotalValesIngresado: FLOAT(0) TotalChequesIngresado: FLOAT(0) TotalTransferenciasIngresado: FLOAT(0) TotalIngresado: FLOAT(0)

«FK»+ FK_CorteCaja_CajaOperacion(INT)+ FK_CorteCaja_Usuario(INT)

«index»+ IXFK_CorteCaja_CajaOperacion(INT)+ IXFK_CorteCaja_Usuario(INT)

«PK»+ PK_CorteCaja(INT)

Usuario::Usuario

«column»*PK idUsuario: INT FK idRol: INT Nombre: CHAR(100) Telefono: VARCHAR(10) Celular: VARCHAR(10) Correo: VARCHAR(50) NombreUsuario: VARCHAR(30) Contrasena: VARCHAR(20)

«FK»+ FK_Usuario_Rol(INT)

«index»+ IXFK_Usuario_Rol(INT)

«PK»+ PK_Usuario(INT)

Devolucion::Devolucion

«column»*PK idDevolucion: INT FK idCliente: INT FK idCajaOperacion: INT FechaDevolucion: DATETIME Status: INT

«FK»+ FK_Devolucion_CajaOperacion(INT)+ FK_Devolucion_Cliente(INT)

«index»+ IXFK_Devolucion_CajaOperacion(INT)+ IXFK_Devolucion_Cliente(INT)

«PK»+ PK_Devolucion(INT)

(idSucursalCaja = idSucursalCaja)

«FK»

(idUsuario = idUsuario)

«FK»

(idCajaOperacion = idCajaOperacion)

«FK»


«FK»


«FK»

(idCaja = idCaja)

«FK»

(idSucursal = idSucursal)

«FK»


46

Figura 31: Modelo de datos "Caja" parte 2 de 2

dm Caja

CajaOperacion





Venta::Venta

«column»*PK idVenta: INT FK idCajaOperacion: INT FK IdCliente: INT Referencia: VARCHAR(100) Fecha: DATETIME MontoTotal: FLOAT(0) Descuento: FLOAT(0) Status: INT

«FK»+ FK_Venta_CajaOperacion(INT)+ FK_Venta_Cliente(INT)

«index»+ IXFK_Venta_CajaOperacion(INT)+ IXFK_Venta_Cliente(INT)

«PK»+ PK_Venta(INT)

Traspaso::Traspaso

«column»*PK idTraspaso: INT FK idSucursalOrigen: INT FK idSucursalDestino: INT FK idCajaOperacionOrigen: INT FK idCajaOperacionDestino: INT FechaSalida: DATETIME FechaEntrada: DATETIME Status: INT

«FK»+ FK_Traspaso_CajaOperacion(INT)+ FK_Traspaso_CajaOperacion_03(INT)+ FK_Traspaso_Sucursal(INT)+ FK_Traspaso_Sucursal_02(INT)+ FK_Traspaso_Sucursal_03(INT)

«index»+ IXFK_Traspaso_CajaOperacion(INT)+ IXFK_Traspaso_CajaOperacion_02(INT)+ IXFK_Traspaso_CajaOperacion_03(INT)+ IXFK_Traspaso_Sucursal(INT)+ IXFK_Traspaso_Sucursal_02(INT)+ IXFK_Traspaso_Sucursal_03(INT)

«PK»+ PK_Traspaso(INT)

Credito::Credito





Abono::Abono





Apartado::Apartado





Reparacion::Reparacion

«column»*PK idReparacion: INT FK idCajaOperacion: INT FechaSolicitud: DATETIME FechaEntrega: DATETIME Origen: VARCHAR(50) DescripcionReparacion: VARCHAR(100) DescripcionPieza: VARCHAR(100)

«FK»+ FK_Reparacion_CajaOperacion(INT)

«index»+ IXFK_Reparacion_CajaOperacion(INT)

«PK»+ PK_Reparacion(INT)


«FK»


«FK»

(idCajaOperacionDestino = idCajaOperacion)


«FK»


«FK»


«FK»


«FK»


47

Figura 32: Modelo de datos "Cliente"

dm Cliente

Cliente



Credito::Credito





Venta::Venta





Apartado::Apartado





Devolucion::Devolucion





(IdCliente = idCliente)

«FK»

(idVenta = idVenta)

«FK»


«FK»


«FK»


«FK»


48

Figura 33: Modelo de datos "Crédito"

dm Credito

Credito





Cliente::Cliente



Venta::Venta





Abono::Abono





(idVenta = idVenta)

«FK»

(idCliente = idCliente)«FK»

(idVenta = idVenta)

«FK»


«FK»

(idCredito = idCredito)

«FK»


«FK»


49

Figura 34: Modelo de datos "Devolución"

dm Devolucion

Devolucion





DevolucionArticulo

«column» FK idDevolucion: INT FK idArticulo: INT idSucursal: INT

«FK»+ FK_DevolucionArticulo_Articulo(INT)+ FK_DevolucionArticulo_Devolucion(INT)

«index»+ IXFK_DevolucionArticulo_Articulo(INT)+ IXFK_DevolucionArticulo_Devolucion(INT)

Cliente::Cliente



Articulo::Articulo





(idDevolucion = idDevolucion)

«FK»


«FK»


«FK»


50

Figura 35: Modelo de datos "Reparación"

dm Reparacion

Reparacion

«column»*PK idReparacion: INT FK idCajaOperacion: INT FechaSolicitud: DATETIME FechaEntrega: DATETIME Origen: VARCHAR(50) DescripcionReparacion: VARCHAR(100) DescripcionPieza: VARCHAR(100)

«FK»+ FK_Reparacion_CajaOperacion(INT)

«index»+ IXFK_Reparacion_CajaOperacion(INT)

«PK»+ PK_Reparacion(INT)

ReparacionPago

«column» FK idReparacion: INT idPago: INT Monto: VARCHAR(50) TipoPago: INT

«FK»+ FK_ReparacionPago_Reparacion(INT)

«index»+ IXFK_ReparacionPago_Reparacion(INT)

(idReparacion = idReparacion)

«FK»


51

Figura 36: Modelo de datos "Traspaso"

dm Traspaso

Traspaso

«column»*PK idTraspaso: INT FK idSucursalOrigen: INT FK idSucursalDestino: INT FK idCajaOperacionOrigen: INT FK idCajaOperacionDestino: INT FechaSalida: DATETIME FechaEntrada: DATETIME Status: INT

«FK»+ FK_Traspaso_CajaOperacion(INT)+ FK_Traspaso_CajaOperacion_03(INT)+ FK_Traspaso_Sucursal(INT)+ FK_Traspaso_Sucursal_02(INT)+ FK_Traspaso_Sucursal_03(INT)

«index»+ IXFK_Traspaso_CajaOperacion(INT)+ IXFK_Traspaso_CajaOperacion_02(INT)+ IXFK_Traspaso_CajaOperacion_03(INT)+ IXFK_Traspaso_Sucursal(INT)+ IXFK_Traspaso_Sucursal_02(INT)+ IXFK_Traspaso_Sucursal_03(INT)


Caja::Sucursal



TraspasoArticulo

«column»*PK idTraspasoArticulo: INT FK idTraspaso: INT FK idArticulo: INT NoPiezas: INT

«FK»+ FK_TraspasoArticulo_Articulo(INT)+ FK_TraspasoArticulo_Traspaso(INT)

«index»+ IXFK_TraspasoArticulo_Articulo(INT)+ IXFK_TraspasoArticulo_Traspaso(INT)


Articulo::Articulo





(idTraspaso = idTraspaso)

«FK»


«FK»

(idSucursalDestino = idSucursal)

«FK»

(idSucursalOrigen = idSucursal)

«FK»


52

Figura 37: Modelo de datos "Usuario"

dm Usuario

Usuario

«column»*PK idUsuario: INT FK idRol: INT Nombre: CHAR(100) Telefono: VARCHAR(10) Celular: VARCHAR(10) Correo: VARCHAR(50) NombreUsuario: VARCHAR(30) Contrasena: VARCHAR(20)

«FK»+ FK_Usuario_Rol(INT)

«index»+ IXFK_Usuario_Rol(INT)

«PK»+ PK_Usuario(INT)

Rol

«column»*PK idRol: INT NombreRol: CHAR(20)

«PK»+ PK_Rol(INT)

Caja::CajaOperacion






«FK»

(idRol = idRol)

«FK»


53

Figura 38: Modelo de datos "Venta"

dm Venta

Venta





VentaPago

«column» FK idVenta: INT Monto: FLOAT(0) TipoPago: INT

«FK»+ FK_VentaPago_Venta(INT)

«index»+ IXFK_VentaPago_Venta(INT)

VentaArticulos

«column» FK idVenta: INT FK idArticulo: INT Cantidad: INT PrecioUnitario: FLOAT(0) Subtotal: FLOAT(0)

«FK»+ FK_VentaArticulos_Articulo(INT)+ FK_VentaArticulos_Venta(INT)

«index»+ IXFK_VentaArticulos_Articulo(INT)+ IXFK_VentaArticulos_Venta(INT)

Caja::CajaOperacion





Cliente::Cliente



Articulo::Articulo





Credito::Credito





(idVenta = idVenta)

«FK»


«FK»


«FK»


«FK»

(idVenta = idVenta)

«FK»


«FK»


«FK»

+FK_Credito_Venta

(idVenta = idVenta)

«FK»

+PK_Venta


54

Modelo de componentes

Los diagramas de componentes ilustran las piezas de software, controladores integrados, etc.,

que conformarán el sistema Hadas SW (Ver figura 39).

Figura 39: Modelo de componentes

Modelo de despliegue

Muestra la arquitectura física de un sistema informático. Puede representar los equipos y

dispositivos, mostrar sus interconexiones y el software que se encontrará en cada máquina

(Schmuller, s.f.).

La base de datos global se encuentra en la nube, aquí se almacenan todos los catálogos y las

conexiones con las sucursales.

Las bases de datos de cada sucursal funcionan de manera independiente a las demás. La PC

está conectada con una impresora normal y otra para tickets. Desde esta PC es posible

ejecutar el software Hadas SW (Ver figura 40).


55

Figura 40: Modelo de despliegue

deployment Network

Nube

MySQL

Base de

Datos

Sucursal 1

Interfaz de Usuario

Impresora Impresora de tickets

Gestiona

Respuesta Solicitud

MySQL

Base de

Datos

Sucursal N

Hadas SW


56

3. Construcción

La fase de Construcción tuvo 11 iteraciones, estas también fueron seleccionadas con base a

cada proceso identificado de la empresa, en las cuales se implementaron las funcionalidades

del sistema de acuerdo a la prioridad establecida por el cliente como se mencionan a

continuación:

1. Realización de venta al mayoreo y menudeo.

2. Directorio de clientes.

3. Créditos asignados a los clientes.

4. Abonos realizados por los clientes.

5. Devoluciones de artículos realizada por los clientes.

6. Asignación de apartados a clientes.

7. Gestión de reparaciones de piezas defectuosas.

8. Traspasos de artículos realizados de usa sucursal a otra.

9. Manejo de artículos por sucursal.

10. Operación de caja.

11. Control de usuarios y asignación de roles.


• Implementar las interfaces en el lenguaje de programación Java.

• Implementar el modelo de clases con los métodos y atributos en el lenguaje de

programación Java.

• Implementar el modelo de datos con sus datos y tipo de datos en el manejador de base

de datos MySQL.

4. Transición

En la fase de Transición se consideraron dos iteraciones, una para desplegar el sistema en el

entorno operacional en versión alfa, y la otra está pendiente para ser utilizada en la

capacitación de los empleados y poner en producción el sistema.


• Instalar el software en los equipos previstos y configurar para su operación.

• Capacitación de usuarios.


57

Capítulo V.

Resultados


58

Capítulo V. Resultados

El producto de software

Para acceder al sistema Hadas SW desde cualquier sucursal, se debe contar con un nombre

de usuario y contraseña como se muestra en la figura 41.

La interfaz principal está dividida por secciones: operaciones, consultas, reportes y

configuración, esto para facilitar al usuario el manejo del sistema. A su vez, estas secciones

cuentan con subsecciones, se mostrarán en el siguiente orden:

Operaciones

o Ventas

o Clientes

o Reparaciones

o Apartados

o Traspaso entrada

o Traspaso salida

o Corte de caja

o Ajuste de inventario

Procesos

Consultas

Figura 41: Inicio de sesión al sistema Hadas SW


59

o Ventas

o Artículos

o Notas de crédito

o Traspaso entrada

o Traspaso salida

o Corte de caja

Reportes

o Clientes

o Artículos

o Movimiento de caja

Configuración

o Empresa

o Usuarios


60

En la sección de “Operaciones” se pueden operar las ventas, clientes, reparaciones,

apartados, envío de traspasos y confirmación de éstos, corte de caja y ajuste de inventario

(Ver figura 42).

Figura 42: Sección “Operaciones” del sistema Hadas SW


61

Ventas

Se realizan las ventas al mayoreo y a menudeo, también se pueden realizar los apartados y

las agregar los artículos a crédito (nota de crédito) (Ver figura 43).

Figura 43: Ventas de la sección “Operaciones”

Clientes

Se muestra el directorio de clientes, desde esta interfaz es posible asignar abonos,

devoluciones, agregar clientes y ver el historial del cliente (Ver figura 44).

Figura 44: Clientes de la sección “Operaciones”


62

Reparaciones

Permite agregar reparaciones y también la cancelación de estas (Ver figura 45).

Figura 45: Reparaciones de la sección “Operaciones”

Apartados

Se muestran a detalle todos los apartados, desde aquí se pueden agregar abonos y liquidar los

artículos (Ver figura 46).

Figura 46: Apartados de la sección “Operaciones”


63

Traspaso entrada

En esta interfaz permite aceptar o cancelar los traspasos de los artículos enviados desde otra

sucursal (Ver figura 47).

Figura 47: Traspaso entrada de la sección “Operaciones”

Traspaso salida

Permite la captura de artículos que se van a traspasar a otra sucursal (Ver figura 48).

Figura 48: Traspaso salida de la sección “Operaciones”


64

Corte de caja

Se realiza el corte de caja una vez que el usuario a terminado su turno de trabajo (Ver figura

49).

Figura 49: Corte de caja de la sección “Operaciones”

Ajuste de inventario

El administrador tiene acceso a todos los artículos, desde aquí se pueden editar (Ver figura

50).

Figura 50: Ajuste de inventario de la sección “Operaciones”


65

En la sección de “Consultas” se realizan las consultas de las ventas realizadas, artículos,

notas de crédito, traspasos de entradas y salidas y cortes de caja (Ver figura 51).

Figura 51: Sección “Consultas” del sistema Hadas SW


66

Ventas

Se consultan las ventas realizadas en un tiempo determinado (Ver figura 52).

Figura 52: Ventas de la sección “Consultas”

Artículos

Se consulta los artículos, existencias y su historial (Ver figura 53).

Figura 53: Artículos de la sección “Consultas”


67

Notas de crédito

Catálogo de todas las notas existentes, se puede realizar cancelación de ellas (Ver figura

54).

Figura 54: Notas de crédito de la sección “Consultas”

Traspaso entradas

Consulta de todas las entradas (Ver figura 55).

Figura 55: Traspaso entradas de la sección “Consultas”


68

Traspaso salidas

Consulta de todas las salidas de traspaso de la sucursal (Ver figura 56).

Figura 56: Traspaso salida de la sección “Consultas”


69

En la siguiente sección de “Procesos” se realiza la importación y exportación del archivo

Excel (Ver figura 57).

Figura 57: Sección “Procesos” del sistema Hadas SW


70

En la siguiente sección se realizan los reportes de clientes, movimientos de caja y artículos

(Ver figura 58).

Figura 58: Sección "Reportes" del sistema Hadas SW


71

Clientes

Permite la realización del reporte de clientes ordenándolos por como el usuario desee (Ver

figura 59).

Figura 59: Clientes de la sección “Reportes”

Artículos

Genera un reporte de artículos agrupándolos ya sea por código, categoría, descripción o

precio (Ver figura 60-61).

Figura 60: Artículos de la sección “Reportes”


72

Figura 61: Reporte de artículos por sucursal

Movimiento de caja

Genera un reporte de movimientos de caja aplicando filtros de la siguiente manera (Ver

figura 62).

Figura 62: Movimiento de caja de la sección “Reportes”


73

La sección “configuración” esta asignada únicamente para los administradores del sistema,

en ella se configuran los datos de la empresa, se administran los usuarios y se asignan los

roles (Ver figura 63).

Figura 63: Sección “Configuración” del sistema Hadas SW


74

Empresa

Permite editar los datos de la sucursal en el que encuentra operando el sistema (Ver figura

64).

Figura 64: Configuración de empresa

Usuarios

Permite agregar usuarios, editarlos y asignar un rol (Ver figura 65).

Figura 65: Configuración de usuarios


75

Capítulo VI.

Conclusiones y

Recomendaciones


76

Capítulo VI. Conclusiones y Recomendaciones

El uso de una arquitectura de base de datos distribuida evitó la redundancia de datos para este

caso de estudio, logrando una mayor eficacia en la tienda con sus sucursales, ya que se pueden

seguir realizando ventas y apartados sin necesitar una conexión a internet mediante una

conectividad interna.

Esta arquitectura es más conveniente cuando se utiliza el mismo software para cada sitio

separado geográficamente y requiere el manejo de bases de datos independientes.

Se eligió trabajar con bases de datos distribuidas para lograr almacenar los datos en cada

equipo y así conseguir la disponibilidad de la información en caso de presentar fallas con la

conexión a internet. Se trabajó con el gestor de base de datos MySQL debido a que es de

fuente abierta.

Se cuenta con una base de datos distribuidas que prevé la disposición de información y

disminuye los riesgos

Se recomienda realizar un análisis sobre el funcionamiento de las bases de datos no

relacionales en entorno distribuido y evaluar si es necesario migrar la base de datos a un

lenguaje aceptado por éste y para este caso de estudio.


77

Fuentes de Información

Ander, E. (s.f.). Técnicas de investigación social. Recuperado el 05 de julio de 2018, de

https://s3.amazonaws.com/academia.edu.documents/35187740/IT_Ander-

Egg_1.pdf?AWSAccessKeyId=AKIAIWOWYYGZ2Y53UL3A&Expires=1531007

766&Signature=%2Ffbz3EdazLD4Cczli9Mu4DUtnxE%3D&response-content-

disposition=inline%3B%20filename%3DTECNICAS_DE_INVESTIGACION_SO

C

Arias, F. G. (2006). El Proyecto de Investigación, Introducción a la metodología científica.

Venezuela: Editorial Episteme.

Benavides, L. A. (01 de 2015). ANALISIS COSTO BENEFICIO DE UNA BASE DE DATOS

DISTRIBUIDA. Quito, Quito, Ecuador.

Figueroa, R. G., Solís, C. J., & Cabrera, A. A. (2008). Metodologías tradicionales vs.

metodologías ágiles. Universidad Técnica Particular de Loja, Escuela de Ciencias de

la Computación.

Hernández, R. (2014). Metodología de la investigación (Sexta Edición ed.). México:

McGRAW-HILL.

Mallea, O. D. (05 de 2016). BASE DE DATOS DISTRIBUIDAS. Recuperado el 22 de 05 de

2018, de http://www.uajms.edu.bo/revistas/wp-content/uploads/2016/06/bitabit-

art5.pdf

Oracle. (s.f.). oracle. Recuperado el 05 de 07 de 2018, de oracle: https://www.oracle.com

Pressman, R. S. (2010). Ingeniería del software. Un enfoque practico. (Séptima Edición ed.).

México, D. F.: McGRAW-HILL INTERAMERICANA EDITORES, S.A. DE C.V.

Schmuller, J. (s.f.). Aprendiento UML en 24 horas. Edo. de México: Pearson Educación

Latinoamérica.

Silberschatz, A., Korth, H., & Sudarshan, S. (2002). Fundamentos de Base de Datos (Cuarta

edición ed.). España: McGRAW-HILL.

Sommerville, Í. (2005). Ingeniería del software (Séptima edición ed.). Madrid: PEARSON

EDUCACIÓN. S.A.

Systems, S. (2018). sparx systems. Recuperado el 20 de 05 de 2018, de Tutorial de UML:

https://www.sparxsystems.com/platforms/uml.html

Yera, Á. C. (2014). Diseño y Programación de Bases de Datos. Madrid, España: Vision

Libros.

sistema para administraciÓn de la tienda “hadas …

Documents