Diseño orientado a objetos

(Café internet Danubio)

Daniel Leandro Muñoz Castañeda

Isai aranda Cardenas
Steven herrera

Universidad Cooperativa de Colombia

Faculta de ingeniería de sistemas
Villavicencio / Meta
2019

Página 1 de 33
 INTRODUCCIÓN

El proyecto se desarrollará de acuerdo con la metodología del curso (diseño de base de

datos y diseño orientado a objetos), se desarrollará usando Xampp Y PHPmyadmin y los
temas vistos en clase los cuales son: caso de usos, diagrama de clases. Este proyecto se
llevará acabo para un mejor funcionamiento y control de un inventario, con la base de datos
que se desarrollará.
La característica principal de este programa es facilitar el trabajo aquellas personas que
mantiene llevando un conteo de los productos, así les será más fácil saber que productos
tienen y que les hace falta.

Página 2 de 33
 Abstrac

The project will be developed according to the methodology of the course (database design
and object-oriented design), it will be developed using Xampp and PHPmyadmin and the
topics seen in class which are: use case, class diagram. This project will be carried out for a
better functioning and control of an inventory, with the database that will be developed.

The main feature of this program is to facilitate the work those people who keep a count of
the products, so it will be easier to know what products they have and what they need

Página 3 de 33
Contenido
INTRODUCCIÓN..................................................................................................................................2
Abstrac...............................................................................................................................................3
Planteamiento Del Problema.............................................................................................................5
Descripción Del Proyecto.............................................................................................................5
Objetivos............................................................................................................................................5
Objetivos General.........................................................................................................................5
Objetivos Específicos....................................................................................................................6
Justificación Del Proyecto..................................................................................................................6
Marco De Referencia..........................................................................................................................6
Marco Contextual.........................................................................................................................6
Marco Teórico............................................................................................................................11
Metodología.....................................................................................................................................14
Diseño..........................................................................................................................................16
Implementación..........................................................................................................................17
Pruebas.......................................................................................................................................18
Desarrollo ingenieril.........................................................................................................................21
Requerimientos Funcionales......................................................................................................21
Modelado.........................................................................................................................................22
Diagrama De Casos De Usos...........................................................................................................22
Referencias.......................................................................................................................................32

Página 4 de 33
 CAFÉ INTERNET DANUBIO (DISEÑO ORIENTADO A OBJETOS)

Planteamiento Del Problema

Alrededor del mundo existen muchos métodos de cómo llevar una base de datos, y

uno de ellos y de los más comunes hasta el día de hoy es llevar todo en cuaderno o una

agenda destinada para apuntar todos los artículos que salen, también usan la

herramienta Excel.

Descripción Del Proyecto

En algunos lugares no tienen un software o asesoramiento especialmente destinado para

hacer este tipo de procedimientos, por eso se diseñará una base de datos para el local (Café

internet Danubio), para mejorar el control del almacenamiento de todos los productos que

se tienen.

El proyecto propone optimizar aquellos procesos que hace demorar al administrador del

local y al dueño, el proyecto se realizara con el lenguaje java, para realizar la interfaz y

conectar a la base de datos, se almacenara todo lo que sale y entra al local

Objetivos

Página 5 de 33
Objetivos General
• Crear y diseñar una base de datos que facilite llevar todo lo que se ingrese y sale del

establecimiento dado, así será más fácil a la hora de llevar un inventario.

Objetivos Específicos
• Ahorrar tiempo a la hora de contar los productos que ingresan así mismo con los

que se salen.

• Garantizar un conteo seguro y rápido.

• Proponer una mejor atención al usuario.

• Diseñar una interfaz que sea amigable para los administradores.

Justificación Del Proyecto

La principal causa de llevar a cabo este proyecto es que no se tiene un buen manejo

del inventario de todos los productos que sé que se encuentran el establecimiento, ya que

todo lo que sale se apunta en un cuaderno; los productos que llegan se apuntan en un

archivo Excel y las facturas se aguardan es un AZ.

Marco De Referencia

este proyecto se basa en agilizar la atención a los clientes y mejorar la parte del conteo de

los productos, ya que tienen deficiencia, a la hora de llevar un inventario.

Marco Contextual

Softwares relacionados:
 Siigo®

Página 6 de 33
 Siigo. Software contable y administrativo.
Funcionalidades: Facturación, Inventario, Compras y gastos, Gestión de cobranza,
Cotizaciones, Movimientos bancarios, Flujo de caja, Nómina, Sistema Los y
Facturación electrónica.
Características (enfoque Inventarios):
 Manejo de Bodegas. Revisa los saldos de cada una de las bodegas que manejas,
para que la Gestión de Inventario sea más efectiva. Ten siempre el control sobre
las cantidades disponibles y las ya vendidas, podrás abastecer tu inventario a
tiempo, entendiendo los costos que esto genera tu conteo físico siempre igual al
del sistema.
 Rentabilidad del Producto. No compres pan para vender pan, con Siigo puedes
conocer en tiempo real la rentabilidad que generan los productos en tu
inventario y su rotación, esto te permite tomar decisiones importantes en tu
empresa y hacerla crecer con rapidez.
 Kardex. Una vez ingresas el producto al software, se empezará a escribir su
historia, registrando cada uno de sus movimientos, olvídate del método manual
para calcular entradas y salidas, ahora Siigo lo hace por ti, generando un reporte
agradable y fácil de entender.
 Costo promedio. Siigo suma el valor de todo tu inventario y lo divide en las
unidades que posees para obtener el costo promedio del producto que estas
comercializando, así al vender tendrás claridad sobre tu margen de ganancias y
hace tu empresa más rentable.cita de la fuente

Página 7 de 33
 Ilustración 1. Siigo - Software contable
Tomado de: https://www.siigo.com/lp-administrativo/?source=An2-Siigo&medio_virtual=Adwords&tit=Siigo%20Software%20Contable%20y%20Administrativo%20100%25%20en
%20Linea&ppc=1&utm_source=adwords&utm_medium=ppc&utm_campaign=%5BS%5D+-+SIIGO+BRANDING&utm_term=siigo&hsa_ver=3&hsa_ad=296192339493&hsa_net=adwords&hsa_kw=siigo&hsa_mt=p&hsa_grp=58714858255&hsa_tgt=kwd-
296798716784&hsa_cam=1534162950&hsa_src=g&hsa_acc=4512101301&gclid=Cj0KCQjw_r3nBRDxARIsAJljleErhAe_QtRI0-QUHaab-flciiwop0e7NU9py6WHwZUV9M5-neVGMwAaApAjEALw_wcB

 Square

Administración de inventario confiable y gratuita.

Función De Square: Administre su

inventario desde

cualquier lugar y sin costo

Inicie sesión en el Panel de Datos Square desde cualquier computadora y administre

su inventario dondequiera que esté. Sin compromisos ni sorpresas.

Ahorre tiempo

Inventario Square está diseñado para ayudarlo a estar menos tiempo enfrente de la

pantalla y más tiempo con sus clientes.

Administre el inventario

Página 8 de 33
de forma masiva

Descargue informes sobre el inventario actual y actualice las cantidades de forma

masiva, lo cual es muy útil cuando se agregan nuevos productos.

Evite que sus

artículos se agoten

Reciba una alerta diaria por correo electrónico para conocer la existencia detallada

de artículos con pocas unidades o que están agotados, y manténgase al tanto de lo

que tiene disponible.

Características

Configuración Rápida.

Importe miles de productos rápidamente con hojas de cálculo CSV. Agregue

fácilmente inventario siempre que sea necesario ajustar el conteo de artículos.

Informes descargables

Exporte los niveles de existencia de inventario a una hoja de cálculo imprimible

cuando lo necesite.

Alertas de artículos

Reciba un correo electrónico diario para saber cuándo hay baja existencia de

artículos o cuándo están agotados.

Página 9 de 33
 Ilustración 2. •SQUARE- Software contable
Tomado de: https://squareup.com/us/en

Ilustración 3.
•SQUARE- Software
contable
Tomado de: https://squareup.com/us/en

Marco Teórico

 Abstracción. La capacidad para encapsular y aislar la información, del diseño y

ejecución. [ CITATION Joy06 \l 9226 ]

Página 10 de 33
 Atributo. Es una característica de una entidad. Cada entidad puede tener muchos
atributos. [ CITATION Ken051 \l 9226 ]
 Base de datos. es un conjunto de datos pertenecientes a un mismo contexto y
almacenados sistemáticamente para su posterior uso.[CITATION Wik19 \l 9226 ]
 Clases. Una plantilla para crear objetos e implementar un comportamiento en un
sistema. En UML, una clase representa un objeto o un conjunto de objetos que
comparte una estructura y un comportamiento comunes. [ CITATION luc19 \l 9226 ]
 CRUD. es el acrónimo de "Crear, Leer, Actualizar y Borrar", que se usa para
referirse a las funciones básicas en bases de datos o la capa de persistencia en un
software. [CITATION Wik19 \l 9226 ]

 Diagrama de caso de uso. Representa la forma en como un Cliente (Actor) opera

con el sistema en desarrollo, además de la forma, tipo y orden en como los
elementos interactúan (operaciones o casos de uso)[ CITATION UNA10 \l 9226 ]
 Diagrama de clases. uno de los tipos de diagramas más útiles en UML, ya que
trazan claramente la estructura de un sistema concreto al modelar sus clases,
atributos, operaciones y relaciones entre objetos. [ CITATION luc19 \l 9226 ]
 Encapsulamiento. un mecanismo que consiste en organizar datos y métodos de una
estructura, conciliando el modo en que el objeto se implementa, es decir, evitando el
acceso a datos por cualquier otro medio distinto a los especificados.[ CITATION
ECU12 \l 9226 ]
 Entrada. Cualquier dato, sea textual o numérico, que se introduce en un sistema de
información para ser almacenado o procesado. La introducción pude ser mediante
formularios, pantallas, voz o formularios interactivos que se contestan en la Web.
[ CITATION Ken051 \l 9226 ]
 Sockets. una forma de comunicación entre procesos que se encuentran en diferentes
máquinas de una red, los sockets proporcionan un punto de comunicación por el
cual se puede enviar o recibir información entre procesos.[ CITATION irv12 \l 9226 ]
 Hilos. es una característica que permite a una aplicación realizar varias tareas a la
vez (concurrente-mente).[ CITATION vic11 \l 9226 ]
 Herencia.  El proceso en el que una subclase o clase derivada recibe la
funcionalidad de una superclase o clase principal, también se conoce como
"generalización". [ CITATION luc19 \l 9226 ]
 Interfaz web. se denomina interfaz al conjunto de elementos de la pantalla que
permiten al usuario realizar acciones sobre el Sitio Web que está visitando.
[ CITATION guí17 \l 9226 ]
 Integridad de datos. se refiere la correctito y completitud de la información en una
base de datos. 
 Tarjeta CRC. Es una técnica para encontrar los conceptos del dominio de la
aplicación, sus responsabilidades y como colaboran con otros para realizar tareas.
[CITATION FRA19 \l 9226 ]

Página 11 de 33
 Mensaje. Una comunicación dirigida a un objeto, que le ordena que ejecute uno de
sus métodos con ciertos parámetros asociados al evento que lo generó.[ CITATION
Wik191 \l 9226 ]
 Método. Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución
se desencadena tras la recepción de un "mensaje". Desde el punto de vista del
comportamiento, es lo que el objeto puede hacer. Un método puede producir un
cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo
mensaje para otro objeto del sistema.[ CITATION Wik192 \l 9226 ]
 Metodología de desarrollo de sistemas. Una Metodología para el Desarrollo de
Sistemas de Información es un conjunto de actividades llevadas a cabo para
desarrollar y poner en marcha un Sistema de Información.[ CITATION tha11 \l 9226 ]
 Modelado. Describe completamente aquellos aspectos del sistema que son
relevantes al propósito del modelo y a un apropiado nivel de detalle. Es una
representación abstracta de la combinación de un software y un hardware. Se utiliza
para describir el comportamiento del sistema en su totalidad. [ CITATION Ken051 \l
9226 ]
 Normalización. es un proceso que consiste en designar y aplicar una serie de reglas
a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo
relacional.[ CITATION Wik193 \l 9226 ]
 Polimorfismo. Comportamientos diferentes, asociados a objetos distintos, pueden
compartir el mismo nombre; al llamarlos por ese nombre se utilizará el
comportamiento correspondiente al objeto que se esté usando. O, dicho de otro
modo, las referencias y las colecciones de objetos pueden contener objetos de
diferentes tipos, y la invocación de un comportamiento en una referencia producirá
el comportamiento correcto para el tipo real del objeto referenciado[ CITATION
Wik194 \l 9226 ]
 Programación orienta a objetos.  es un paradigma de programación que viene a
innovar la forma de obtener resultados. Los objetos manipulan los datos de entrada
para la obtención de datos de salida específicos, donde cada objeto ofrece una
funcionalidad especial.[ CITATION Wik195 \l 9226 ]

 Requerimiento. es una necesidad documentada sobre el contenido, forma o

funcionalidad de un producto o servicio. Se usa en un sentido formal en
la ingeniería de sistemas, ingeniería de software e ingeniería de requisitos.[ CITATION
Wik196 \l 9226 ]

Página 12 de 33
 Requerimiento funcional. Un requisito funcional define una función del sistema de
software o sus componentes. Una función es descrita como un conjunto de entradas,
comportamientos y salidas.[ CITATION Wik197 \l 9226 ]
 Requerimiento no funcional. Un requisito no funcional o atributo de calidad es, en
la ingeniería de sistemas y la ingeniería de software, un requisito que sabe bien y
especifica criterios que pueden usarse para juzgar la operación de un sistema en
lugar de sus comportamientos específicos, ya que éstos corresponden a los
requisitos funcionales.[ CITATION Wik18 \l 9226 ]
 Servidores. una aplicación en ejecución capaz de atender las peticiones de un
cliente y devolverle una respuesta en concordancia. Los servidores se pueden
ejecutar en cualquier tipo de computadora, incluso en computadoras con bombillo
dedicadas a las cuales se les conoce individualmente como «el servidor».[ CITATION
Wik198 \l 9226 ]

Página 13 de 33
 Metodología

La metodología escogida para el desarrollo del aplicativo será la Programación extrema

(XP), porque nos ofrece muchas ventajas permitiendo una óptima solución a las falencias
que posee la empresa.

Ilustración 4. •metodología XP-Programación extrema

Tomado de: http://www.diegocalvo.es/wp-content/uploads/2018/04/Metodolog%C3%ADa-XP-
Programaci%C3%B3n-Extrema.jpg

Características:
 Simplicidad: el desarrollo busca un enfoque simple, práctico y preciso en el
diseño y la codificación del sistema.
 Agilidad. Tiene una duración promedio de tres a cuatro meses en el desarrollo
del sistema.
 Relación directa Cliente – Analista – Desarrollador. La comunicación con el
cliente es vital durante todo el proceso, desde la planeación hasta las pruebas.
 Se basa en el Ciclo de vida de desarrollo de sistemas. Consta de cuatro fases, las
cuales permiten dar una solución eficaz y efectiva al objetivo del sistema.
Fases

Página 14 de 33
1ª Fase: Planificación del proyecto.
• Historias de usuarios: Las historias de usuario tienen la misma finalidad que
los casos de uso, pero con algunas diferencias: Constan de 3 ó 4 líneas escritas
por el cliente en un lenguaje no técnico sin hacer mucho hincapié en los detalles;
no se debe hablar ni de posibles algoritmos para su implementación ni de
diseños de base de datos adecuados, etc.
• Velocidad del proyecto: La velocidad del proyecto es una medida que
representa la rapidez con la que se desarrolla el proyecto; estimarla es muy
sencillo, basta con contar el número de historias de usuario que se pueden
implementar en una iteración; de esta forma, se sabrá el cupo de historias que se
pueden desarrollar en las distintas iteraciones.
• Programación en pareja: La metodología X.P. aconseja la programación en
parejas pues incrementa la productividad y la calidad del software desarrollado.
El trabajo en pareja involucra a dos programadores trabajando en el mismo
equipo; mientras uno codifica haciendo hincapié en la calidad de la función o
método que está implementando, el otro analiza si ese método o función es
adecuado y está bien diseñado.
• Reuniones diarias: Es necesario que los desarrolladores se reúnan
diariamente y expongan sus problemas, soluciones e ideas de forma conjunta.
Las reuniones tienen que ser fluidas y todo el mundo tiene que tener voz y voto.
2ª Fase: Diseño.
• Diseños simples: La metodología X.P sugiere que hay que conseguir diseños
simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible
para conseguir un diseño fácilmente entendible e implementable que a la larga
costará menos tiempo y esfuerzo desarrollar.
3ª Fase: Codificación.
• La codificación debe hacerse ateniendo a estándares de codificación ya
creados. Programar bajo estándares mantiene el código consistente y facilita su
comprensión y escalabilidad.
Crear test que prueben el funcionamiento de los distintos códigos
implementados nos ayudará a desarrollar dicho código. Crear estos test antes

Página 15 de 33
 nos ayuda a saber qué es exactamente lo que tiene que hacer el código a
implementar y sabremos que una vez implementado pasará dichos test sin
problemas ya que dicho código ha sido diseñado para ese fin.
4ª Fase: Pruebas.
• Uno de los pilares de la metodología X.P es el uso de test para comprobar el
funcionamiento de los códigos que vayamos implementando.
El uso de los test en X.P es el siguiente:
Se deben crear las aplicaciones que realizarán los test con un entorno de
desarrollo específico para test.
Hay que someter a test las distintas clases del sistema omitiendo los métodos
más triviales.
Se deben crear los test que pasarán los códigos antes de implementarlos; en el
apartado anterior se explicó la importancia de crear antes los test que el código.
Un punto importante es crear test que no tengan ninguna dependencia del código
que en un futuro evaluará. Hay que crear los test abstrayéndose del futuro
código, de esta forma aseguraremos la independencia del test respecto al código
que evalúa.
Diseño
tablas de normalización

Ilustración 5. •Tablas de normalización

Fuente: Elaboración propia

Página 16 de 33
 Ilustración 6. • Base de datos XAMPP
Fuente: Elaboración propia

Implementación

Ilustración 7. •Código
Fuente: Elaboración propia

Página 17 de 33
Pruebas
Funcionamiento del programa garantizando que funcione de manera eficaz.

Ilustración 8. •Diseño de página web

Fuente: Elaboración propia

Página 18 de 33
 Historias de Usuario
Se realizan las Historias de Usuario para la definición de los requisitos
funcionales del sistema a crear:
Historia de usuario
Numero: 1
  Nombre: Creación de usuarios
Usuario: Administrador
Modificación de historia número: Iteración:
Prioridad en Negocio: Alta Puntos estimados:
Riesgo en desarrollo: Puntos reales:
Desarrollador encargado: Steven Herrera
Descripción: El administrador creara cada usuario dándoles un rol especifico a
cada uno.
Observaciones:

Historia de usuario
Numero: 2
  Nombre: Creación de clientes
Usuario: Administrador y vendedor
Modificación de historia número: Iteración:
Prioridad en Negocio: Alta Puntos estimados:
Riesgo en desarrollo: Puntos reales:
Desarrollador encargado: Leandro Martínez

Descripción: Ingresar los datos requeridos para un buen registro de cliente

Observaciones: Si por algún motivo el cliente decide ser eliminado, entonces se
realizara la tarea inmediatamente

Página 19 de 33
 Historia de usuario
Numero: 3
  Nombre: Manejo de productos
Usuario: Administrador
Modificación de historia número: Iteración:
Prioridad en Negocio: Alta Puntos estimados:
Riesgo en desarrollo: Puntos reales:
Desarrollador encargado: Steven Herrera
Descripción: Los productos deben ser ingresados correctamente en el sistema
para un buen uso de su venta.
Observaciones: En caso de no existir o querer modificar algún producto se debe
cumplir todos los requisitos por el mismo

Historia de usuario
Numero: 4
  Nombre: Generar recibo
Usuario: vendedor
Modificación de historia número: Iteración:
Prioridad en Negocio: Alta Puntos estimados:
Riesgo en desarrollo: Puntos reales:
Desarrollador encargado: Isai Aranda
Descripción: Se debe entregar un recibo al cliente a la hora de comprar sus
productos
Observaciones: El recibo debe tener fecha y id del vendedor para algún reclamo

Historia de usuario
Numero: 5 Nombre: Modificar y eliminar
  usuario
Usuario: Administrador
Modificación de historia número: Iteración:
Prioridad en Negocio: Alta Puntos estimados:
Riesgo en desarrollo: Puntos reales:
Desarrollador encargado: Steven Herrera, Isai Aranda, Leandro Martínez

Página 20 de 33
 Descripción: Modificar y eliminar los usuarios ya existentes
Observaciones: Únicamente cuando se necesita actualizar información o cuando
ya no trabaje mas

Desarrollo ingenieril

Requerimientos Funcionales

 Por medio de un nombre y contraseña el sistema dejara iniciar sesión a cada

usuario.
 El sistema permitirá crear usuarios nuevos modificar e eliminar los existentes.
 El sistema permitirá crear clientes, modificarlos e eliminarlos.
 El sistema dejará ingresar productos con su debido precio, si en caso de subir los
precios permitirá
 modificar los productos y eliminarlos en caso de que el producto no se vaya a
vender más.
 Dar una alerta cuando la cantidad de productos existentes sea muy baja.
 El sistema tendrá un reporte de ventas por cada producto.
 El sistema generara una factura para cada cliente con sus respectivos artículos
comprados e información del vendedor.
 El sistema permitirá consultar los productos ya existentes con el fin de eliminar o
modificarlos.

No Funcionales.
 Se necesita una conexión a internet para la base de datos.
 Dispositivos como un monitor, Reuter, teclado, ratón, y una torre.
 Conexión de ethernet para mayor funcionamiento.
 Televisor
 Cámaras

Página 21 de 33
 Modelado

Diagrama De Casos De Usos

Ilustración 9. Diagrama de casos de uso

Página 22 de 33
 Especificación De Cada Caso De Uso
Tabla 1. Descripción de caso de uso Iniciar sesión
Caso de usos Iniciar sesión
Identificador 1
Descripción para ingresar a la base de datos
Actor principal Administrador
Actor secundario
Precondiciones Estar registrado con usuario y contraseña
Flujo principal 1- digitar usuario
2- digitar contraseña
Post condiciones Estar en la sesión del usuario
Flujos alternativos Equivocarse en el usuario y contraseña
Fuente: elaboración propia

Tabla 2. Descripción de caso de uso Crear productos

Caso de usos Crear productos
Identificador 2
Descripción Los productos serán guardados en la base
de datos
Actor principal administrador
Actor secundario
Precondiciones Tener nuevos productos
Flujo principal 1- ingresar productos
Post condiciones Agregar los productos nuevos
Flujos alternativos Equivocarse al agregar el producto
Fuente: elaboración propia

Tabla 3. Descripción de caso de uso Consultar productos

Caso de usos Consultar productos
Identificador 2
Descripción Los productos serán consultados cuando se
necesite
Actor principal Administrador y vendedor
Actor secundario
Precondiciones Tener productos
Flujo principal 1- consultar productos
Post condiciones Consultar productos existentes
Flujos alternativos No existe ningún producto
Fuente: elaboración propia
Página 23 de 33
Tabla 4. Descripción de caso de uso Eliminar productos
Caso de usos Eliminar producto
Identificador 6
Descripción Eliminar productos vendidos o mal
digitados
Actor principal administrador
Actor secundario
Precondiciones Eliminar producto
Flujo principal 1- eliminar productos vendidos
2- eliminar productos mal digitados
Post condiciones Saber que productos eliminar
Flujos alternativos Eliminar el que no es o eliminar cuando la
venta no se allá echo
Fuente: elaboración propia

Tabla 5. Descripción de caso de uso Buscar productos

Caso de usos Buscar productos
Identificador 7
Descripción Facilita el uso de la búsqueda de un
producto
Actor principal empleado
Actor secundario
Precondiciones Tener inventario de productos
Flujo principal 1- ingresar el nombre del producto
Post condiciones Buscar el producto
Flujos alternativos Errar el nombre del producto que se va
buscar
Fuente: elaboración propia
Tabla 6. Descripción de caso de uso Modificar productos
Caso de usos Modificar productos
Identificador 8
Descripción Actualizar el inventario diariamente
Actor principal empleado
Actor secundario
Precondiciones Se genera cuando hay ventas de productos
Flujo principal 1- actualizar
Post condiciones Actualizar el inventario
Flujos alternativos Que el sistema falle
Fuente: elaboración propia

Página 24 de 33
Tabla 7. Descripción de caso de uso Generar reporte de ventas
Caso de usos Generar reporte de ventas
Identificador 9
Descripción Muestra el diario de ventas
Actor principal dueño
Actor secundario
Precondiciones Diario de venta
Flujo principal 1- ingresar para saber cuál es diario
2- ver el diario de venta
Post condiciones Rectificar
Flujos alternativos Que el sistema falle u olviden registrar la
venta
Fuente: elaboración propia
Tabla 8. Descripción de caso de uso Crear administrador
Caso de usos Crear administrador
Identificador 3
Descripción va agregar los nuevos empleados
Actor principal dueño
Actor secundario
Precondiciones Tener nuevos empleados
Flujo principal 1- registrar el nuevo cliente
2- confirmar el registros
Post condiciones Se llenó el formulario de registro de nuevo
administrador
Flujos alternativos Equivocarse al crear el nuevo
administrador
Fuente: elaboración propia
Tabla 9. Descripción de caso de uso Modificar administrador
Caso de usos Modificar administrador
Identificador 4
Descripción Cambiará a los viejos administradores por
los nuevos
Actor principal dueño
Actor secundario
Precondiciones Estar registrado como administrador
Flujo principal 1- buscar administrador
2- actualizar administrador
Post condiciones Actualizar los nuevos administradores
Flujos alternativos Equivocarse al crear el nuevo
administrador
Fuente: elaboración propia
Página 25 de 33
Tabla 10. Descripción de caso de uso Eliminar administrador
Caso de usos Eliminar administrador
Identificador 5
Descripción Eliminará a los administradores de la base
de datos
Actor principal dueño
Actor secundario
Precondiciones Estar registrado como administrador
Flujo principal 1- buscar administrador
2- eliminar administrador
Post condiciones Eliminar los administradores
Flujos alternativos no eliminar al administrador correcto
Fuente: elaboración propia

Tabla 11. Descripción de caso de uso Vender productos

Caso de usos Vender productos
Identificador 10
Descripción El administrador registrara la venta del
producto
Actor principal Administrador
Actor secundario
Precondiciones
Flujo principal 1- buscar producto
2- vender producto
3- actualizar producto
Post condiciones Venta de productos
Flujos alternativos Equivocarse al registrar el producto
vendido que no es
Fuente: elaboración propia

Página 26 de 33
Tabla 12. Descripción de caso de uso Generar factura
Caso de usos Generar factura
Identificador 11
Descripción Al realizar alguna venta, el administrador
generara la factura
Actor principal Administrador
Actor secundario
Precondiciones Haber vendido algún producto
Flujo principal 1- buscar producto
2- vender producto
3- actualizar producto
Post condiciones Imprimir la factura
Flujos alternativos Equivocarse al no registrar la venta en la
factura
Fuente: elaboración propia

Tabla 13. Descripción de caso de uso Alerta por falta de productos

Caso de usos Alerta por falta de productos
Identificador 12
Descripción Va alertar cuando no hay productos
Actor principal Administrador
Actor secundario
Precondiciones
Flujo principal 1- mostrar un mensaje de que
producto hace falta
Post condiciones
Flujos alternativos Que el sistema no muestre el mensaje
Fuente: elaboración propia

Página 27 de 33
 Diagrama De Clases

Ilustración 10. Diagrama de clase

Página 28 de 33
 Diagrama General
Ilustración 11. Diagrama General

Ilustración 12. Diagrama General

Página 29 de 33
 Anexos
Así se lleva un manejo de todos los productos que salen del establecimiento, los
productos que se ingresan al establecimiento se llevan en formato Excel.
Anexo #1. Fotografía de factura de recargas

Anexo #2. Fotografía de cuaderno con inventario de la tienda

Página 30 de 33
Anexo #3. Fotografía de la tienda Danubio y sus productos

Página 31 de 33
Referencias

Aguilar, J. (2006). campus virtual. Obtenido de

https://campusvirtual.ucc.edu.co/d2l/le/content/134463/viewContent/1071269/View
bonilla, i. (7 de Noviembre de 2012). DSP. Obtenido de http://dsp.mx/blog/sistemas-de-
informacion/49-sockets-tcp-udp
ECURED. (9 de JUNIO de 2012). Obtenido de https://www.ecured.cu/Encapsulamiento
guía digital . (2017). Obtenido de https://www.guiadigital.gob.cl/articulo/que-es-una-
interfaz.html
gutierrez, v. h. (23 de Noviembre de 2011). victorggzz. Obtenido de
http://victorggzz.blogspot.com/2011/11/hilos-o-subprocesos-puntos-extras.html
Kendall, & Kendall. (2005). Glosario. En Análisis y diseño de sistemas (6ta Edición ed.,
págs. 703-713). PEARSON.
Londoño, t. (2011). monografias. Obtenido de
https://www.monografias.com/trabajos90/metodologia-desarrollo-sistema-
informacion/metodologia-desarrollo-sistema-informacion.shtml
lucidchart. (2019). lucidchart. Obtenido de https://www.lucidchart.com/pages/es/tutorial-
de-diagrama-de-clases-uml
Patiño, F. (2019). campus virtual. Obtenido de
https://campusvirtual.ucc.edu.co/d2l/le/content/134463/viewContent/1071270/View
UNAD. (2010). unad. Obtenido de
http://stadium.unad.edu.co/ovas/10596_9839/diagramas_de_casos_de_uso.html
Wikipedia. (s.f.). Recuperado el 13 de Septiembre de 2018, de
https://es.wikipedia.org/wiki/Abstracción_(informática)
Wikipedia . (22 de mayo de 2019). Obtenido de https://es.wikipedia.org/wiki/Programaci
%C3%B3n_orientada_a_objetos
Wikipedia . (28 de marzo de 2019). Obtenido de https://es.wikipedia.org/wiki/M
%C3%A9todo_(inform%C3%A1tica)
Wikipedia. (2 de noviembre de 2018). Obtenido de
https://es.wikipedia.org/wiki/Requisito_no_funcional
Wikipedia. (29 de mayo de 2019). Obtenido de https://es.wikipedia.org/wiki/CRUD
Wikipedia. (4 de abril de 2019). Obtenido de https://es.wikipedia.org/wiki/Normalizaci
%C3%B3n_de_bases_de_datos
Wikipedia. (26 de marzo de 2019). Obtenido de
https://es.wikipedia.org/wiki/Polimorfismo_(inform%C3%A1tica)

Página 32 de 33
Wikipedia. (22 de mayo de 2019). Obtenido de https://es.wikipedia.org/wiki/Programaci
%C3%B3n_orientada_a_objetos
Wikipedia. (14 de febrero de 2019). Obtenido de
https://es.wikipedia.org/wiki/Requisito_(sistemas)
Wikipedia. (24 de marzo de 2019). Obtenido de
https://es.wikipedia.org/wiki/Requisito_funcional
Wikipedia. (13 de abril de 2019). Obtenido de https://es.wikipedia.org/wiki/Servidor

Página 33 de 33