A que se dbee DAM - Entornos de desarrollo

Análisis

Descripción del problema

La descripción del problema viene determinado en el enunciado de la tarea y se reproduce a continuación:

Diseñar una aplicación para una tienda especializada en vender productos estéticos.

La tienda desea trabajar con software libre. Además, desea explícitamente que la aplicación sea capaz de cumplir las siguientes tareas:

• Proporcionar facturas de las ventas.
• Llevar la cuenta de lo que vende cada trabajador.
• Controlar el stock de productos en almacén.
• Operar con lector de código de barras y tarjetas de crédito.
• Controlar los precios de los productos y ofrecer la posibilidad de operar con ellos.
• El tiempo de respuesta de la aplicación ha de ser lo menor posible.
• No se podrán procesar dos peticiones a la vez, aunque haya varios equipos funcionando simultáneamente.
• La empresa también quiere almacenar información de sus trabajadores: DNI, nombre, apellidos, número de la Seguridad Social, fecha de nacimiento, teléfono y localidad. Asimismo, de los productos interesa almacenar: código, marca, nombre comercial, precio, cantidad.

Requisitos funcionales y diagrama de casos de uso

El sistema registrará cualquier operación, tanto de clientes, productos como de empleados. Las operaciones son de alta, baja o modificación así como impresión de facturas, uso del lector de código de barras y datáfono.

Para dicho registro se necesitarán datos como los siguientes:

• Ventas, cambios o devoluciones: Se llevará un registro de las ventas, cambios o devoluciones para facilitar el control de productos y las estadísticas. Se registrará cada operación con su correspondiente dependiente en la base de datos. Siempre que se realice una operación de este tipo, se emitirá la correspondiente factura una vez se haya terminado la operación con éxito.
• Control de empleados. El sistema mantendrá un registro con los datos de los empleados que se podrán dar de alta, baja o modificación según necesidad. Esta funcionalidad requiere de una base de datos propia.
• Mediante el lector de código de barras se identificará cada producto para altas o ventas.
• No se permitirá la concurrencia, para evitarla, cada operación que se realice bloqueará las tablas correspondientes hasta que finalize la operación.
• Se añadirá la detección del pago mediante tarjeta.

Requisitos no funcionales

• No se permitirá la concurrencia, para evitarla, cada operación que se realice bloqueará las tablas correspondientes hasta que finalize la operación y entonces continuará con la siguiente.
• El tiempo de respuesta debe de ser el menor posible.
• Se debe de cumplir la ley vigente correspondiente con la protección de datos.

Se utilizará Modelo en Cascada con Realimentación ya que en principio no se preveen grandes cambios en la naturaleza del negocio, no es un desarrollo muy complejo y los requisitos están muy claros y especificados.

Diagrama de casos de uso

Se definen los siguientes actores:

• Cliente: Es el actor que efectúa las compras. No es un actor que entre en el sistema pero que debe de estar definido ya que interactúa con el sistema y puede ser que se apliquen descuentos por cliente y se requiera identificación.
• Dependiente: Es el usuario básico que manipula el sistema. Realizará las operaciones  de venta, reserva de productos, actualización de stock, cambios y devoluciones. Todas estas operaciones deben de utilizar la lectura del código de barras del producto mediante el lector. La operación de venta está asociada a la generación de una factura, que puede ser impresa o no además de poner imprimir un duplicado si es necesario. Cualquier operación relacionada con el cliente y venta o devolución está asociada a la forma de pago y con las opciones de pago con tarjeta o contado.
• Superusuario: Este usuario tiene los permisos y funciones heredadas del depediente además de algunas más. Este usuario podrá dar de baja, alta o modificación de productos o precios según corresponda. También será el encargado de generar las estadísticas de venta y de mantener la información relacionada con los empleados.
• Administrador: El administrador del sistema es una persona ajena a la tienda ya que se ha acordado un mantenimiento. Los términos del mantenimiento serán acordados con el cliente en la fase de análisis. El administrador heredará todos los permisos de los demás actores de la aplicación para poder realizar las pruebas y resolución de incidencias que fuesen necesarias además del mantenimiento del sistema.

[pic 1]

Diseño

En esta fase se especifican las entidades y las relaciones entre ellas además de la selección del lenguaje de programación y del sistema gestor de base de datos.

Teniendo en cuenta los requisitos del cliente y que desea que se utilice software libre se ha decidido usar utilizar plataforma Linux y  Java como lenguaje de programación. Como gestor de base de datos se elije MySQL.

Se utiliza Linux ya que es el único sistema operativo libre con gran soporte y difusión.

Java ya que es un lenguaje versatil, con gran implantación, independiente de la plataforma, soporte para trabajo en red y orientado a objetos. Se utilizará el entorno de desarrollo NetBeans por ser libre, de facil uso y gran difusión.

MySQL ya que es de gran aceptación, tiene soporte  y está apoyada por grandes compañías. Soporta gran cantidad de registros, rápida y disponible para gran cantidad de plataformas. Seguridad. Al no necesitar concurrencia según especificaciones y no se prevee grandes tasas de modificación se podrá utilizar el motor no transaccional MyISAM que permite gran rapidez siendo una de los requisitos del sistema.

Clases y entidades propuestas:

• Producto
• Cliente
• Venta
• Dependiente
• Factura
• Cambio
• Devolucion
• Lector
• Superusuario
• Administrador

Codificación

Al usar Java se utilizará la orientación a objetos ya que agiliza las tareas de mantenimiento y es ideal para aplicaciones grandes donde se prevee crecimiento. Por otra parte se utilizará el IDE NetBeans ya que en el puedes escribir el código fuente y automáticamente el código objeto además del ejecutable.

...