resultados

Adjunto una de las tareas que he realizado con mis alumnos CFGS Desarrollo de Aplicaciones Web en el módulo de Desarrollo en Entorno Cliente.

UT04 Práctica 3: ERP

Vamos a construir la estructura de objetos necesaria para implementar un pequeño framework que represente un mini ERP para la gestión de almacén. En concreto, el almacén estará compuesto por un conjunto de tiendas, en las que se puede encontrar una serie de productos, clasificados por categorías.

A continuación, se detalla los objetos que debemos implementar junto con su funcionalidad. Ten en cuenta que deberás implementar también la estructura de objetos necesaria para gestionar las excepciones que genere la aplicación.

Para el desarrollo de la práctica deberás utilizar la herramienta de gestión de versiones GIT e ir guardando una copia de la versión realizada en GitHub.

1. Objeto StoreHouse

Este objeto mantendrá el estado del almacén, donde debemos relacionar los productos que tenemos en el almacén, con las categorías a las que pertenecen y las tiendas en las que se pueden encontrar, con el stock de cada producto.

 La información que debe mantener es:

• Nombre del almacén.
• Los productos que hayamos añadido en el almacén.
• Las categorías de productos que tengas en el almacén.
• Las tiendas en las que están disponibles los productos.
• El stock de cada producto.
• Categoría por defecto. Todos los productos deben pertenecer al menos una categoría, la categoría por defecto es utilizada cuando un producto no encaja en ninguna categoría.
• Tienda por defecto. De la misma manera cada producto debe pertenecer al menos una tienda.

Los métodos a implementar para este objeto son

 

Método	Funcionalidad	Argumentos	Retorno	Excepciones
Getter setter name	Para la propiedad Name	String	String	- El nombre no puede ser vacío
Getter categories	Devuelve un iterador que permita recorrer las categorías.	-	Iterador de Category	-
Getter shops	Devuelve un iterador que permita recorrer las tiendas.	-	Iterador de Shop	-
addCategory	Añade una nueva categoría	Objeto Category	Number con el nº de elementos	- La categoría no puede ser null. - La categoría ya existe
removeCategory	Elimina una categoría. Al eliminar la categoría, sus productos pasan a la de por defecto.	Objeto Category	Number con el nº de elementos	- La categoría no está registrada
addProduct	Añade un nuevo producto asociado a una o más categorías.	- Objeto Product - Objeto Category	Number con el nº de elementos	- Product no puede ser null.
removeProduct	Elimina un producto junto con todas sus relaciones con otros objetos del alamacen.	Objeto Product	Number con el nº de elementos	- Product no existe.
addProductInShop	Añade un Product en una tienda con un nº de unidades.	- Object Product - Object Shop - Number	Number con el nº de elementos.	- Product no existe. - Shop no existe.
addQuantityProductInShop	Dado un Product y un Shop, se suman la cantidad de elementos al stock de esa tienda. Por defecto 1.	- Object Product - Object Shop - Number	Stock del producto en la tienda.	- Product no existe. - Shop no existe. - El stock no puede ser negativo.
getCategoryProducts	Devuelve la relación de todos los productos añadidos en una categoría con sus cantidades en stock. Si pasamos un tipo de producto, el resultado estará filtrado por ese tipo.	Objeto Category Tipo de Product.	Iterador de Productos	- La categoría no puede ser null.
addShop	Añade una nueva tienda.	Objeto Shop	Number con el nº de tiendas.	- La tienda no puede ser nula. - La tienda ya existen.
removeShop	Eliminar una tienda. Al eliminar una tienda, los productos de la tienda pasan a la tienda genérica.	Objeto Shop	Number con el nº de elementos	- La tienda no existente.
getShopProducts	Devuelve la relación de todos los productos añadidos en una tienda con su stock. Si pasamos un tipo de producto, el resultado estará filtrado por ese tipo.	Objeto Shop. Tipo de Product.	Iterador de Productos	- La tienda no puede ser null.

Tabla 1 Métodos del objeto StoreHouse

 

1. Objeto Category

Con este objeto podemos crear la estructura de categorías del almacén. Sus propiedades serán:

• title: Con el título de la categoría.
• description: Con la descripción de la misma.

Sus métodos serán los habituales getter y setter de estas propiedades, aunque el título no podrá ser vacío.

1. Objeto Product

Objeto que representa un producto. Tendrá las siguientes propiedades:

• serialNumber: Número de serie del producto. Obligatorio.
• name: Nombre del producto. Obligatoria.
• description: Descripción de la imagen
• price: Precio del producto. Obligatorio.
• tax: Porcentaje de impuestos sobre el precio del producto.
• images: Array con diferentes imágenes sobre el producto.

Como métodos tendrá los getter y setter habituales para cada propiedad.

1. Objetos heredados de Product

Necesitamos tener al menos 3 subclases de Product que permitan especializar su comportamiento. Podrás elegir estas subclases, así como sus propiedades. Algunos ejemplos podrían ser ropa, calzado, música, electrónica, etc, siempre y cuando las 3 subclases no sean demasiado parecidas a las propuestas como ejemplos trabajados en la unidad.

1. Objeto Coords

Coordenadas para adjuntar a un objeto Shop como veremos en el siguiente punto. Sus propiedades son:

• latitude: Latitud.
• longitude: Longitud.

Los métodos serán getter y setter, siendo ambas propiedades obligatorias.

1. Objeto Store

Información de una tienda. Sus propiedades son:

• CIF: Código de identificación fiscal.
• name: Nombre de la tienda. Obligatorio.
• address: Dirección.
• phone: Teléfono.
• coords. Objeto Coords donde se ubique la tienda.

Como métodos tendrá los getter y setter habituales teniendo en cuenta las propiedades que son obligatorias.

 

Relación entre objetos

Las bases de datos NOSQL son aquellas que utilizan almacenes de objetos para contener la información, en lugar de utilizar relaciones entre tablas como ocurre con las relacionales. Un ejemplo es MongoDB la cual almacena documento en un formato parecido a JSON. Como veremos en próximas unidades, un documento JSON es un objeto literal traducido a string para que pueda ser portable. Estos documentos son fácilmente interpretables por un humano, por lo que no necesitan ser procesados. Por último, pueden ser transferibles a través de red para comunicar componentes de una aplicación, o de forma más habitual, entre un cliente y servidor.

Un ejemplo de documento JSON podría ser utilizado para representar un usuario. El siguiente ejemplo vemos cómo podemos utilizar esta representación para un usuario con una propiedad _id, name, contact, y dob con la fecha de nacimiento.

{

    "_id": "52ffc33cd85242f436000001",

    "name": "Tom Hanks",

    "contact": "987654321",

    "dob": "01-01-1991"

 }

Otro ejemplo podría ser utilizado para representar una dirección.

{

    "_id": "52ffc4a5d85242602e000000",

    "building": "22 A, Indiana Apt",

    "pincode": 123456,

    "city": "Los Angeles",

    "state": "California"

} 

Como vemos, ambos siguen una estructura similar a la de un objeto literal. Ambos, JSON y los objetos literales son formatos intercambiables.

MongoDB utiliza los dos modelos de relación de objetos citados. Veamos unos ejemplos.

Modelo embebido o de relación embebida

En este modelo, los objetos subordinados están embebidos dentro del objeto principal. Un ejemplo es el siguiente, donde tenemos un usuario y un array con todas sus posibles direcciones.

{

    "_id": "52ffc33cd85242f436000001",

    "contact": "987654321",

    "dob": "01-01-1991",

    "name": "Tom Benzamin",

    "address": [

       {

          "building": "22 A, Indiana Apt",

          "pincode": 123456,

          "city": "Los Angeles",

          "state": "California"

       },

       {

          "building": "170 A, Acropolis Apt",

          "pincode": 456789,

          "city": "Chicago",

          "state": "Illinois"

       }

    ]

} 

Esto nos crea la ventaja de que si queremos acceder al contenido se encuentra disponible inmediatamente. No tenemos que hacer ningún paso extra para recuperarlo. El inconveniente viene en el mantenimiento de los datos y su repetición. Dos usuarios podrían tener la misma dirección, si queremos modificar un dato de la dirección tendríamos que ir objeto tras objeto comprobando si es la dirección que estamos buscando para actualizar el dato.

Modelo relación por referencia

En este caso los objetos subordinados residen en otro documento o estructura, y son referenciados mediante una propiedad con forma de identificador. En este ejemplo, las direcciones son referenciadas por un identificador.

{

    "_id":"52ffc33cd85242f436000001",

    "contact": "987654321",

    "dob": "01-01-1991",

    "name": "Tom Benzamin",

    "address_ids": [

       "52ffc4a5d85242602e000000",

       "52ffc4a5d85242602e000001"

    ]

}

La ventaja de este modelo es el mantenimiento, ya que los datos están centralizados, pero el inconveniente es que tendremos que realizar varios pasos para encontrar la información, el usuario, y una vez encontrado, habría que buscar todas las direcciones que le pueden pertenecer a través de los id aportados por el objeto del usuario.

Nunca hay soluciones perfectas, todo depende de las necesidades de nuestra aplicación, y qué beneficia más a nuestra lógica de negocio.

Consejos de implementación

Para la implementación de la práctica necesitaremos diseñar una estructura que nos permita mantener todos los objetos que vayamos creando, tiendas, categorías y productos.

Como propuesta de implementación, aunque no tiene que ser la única, y otros tipos también podrían considerarse válidos, tenemos una solución mixta con los dos modelos.

Solución 1

• Crear un array con las tiendas. El cuál almacenará cada uno de los objetos Store.

let _stores = [];

• Crear un array con las categorías.

let _categories = [];

• Cada elemento en la categoría puede ser un objeto literal con dos propiedades, una con la categoría, y la otra un array que contenga los productos asignados a esa categoría.

{

    category: category,

    products:[]

}

• Los objetos Product en el array de productos pueden ser un objeto literal con el objeto Product y una propiedad que referencie la tienda en la que está ubicado.

{

    product: product,

    store: _stores[storePosition].CIF

}

Solución 2

La solución dos es hacer el objeto Store el principal:

• Partimos de los dos arrays.

let _stores = [];

let _categories = [];

• Las categorías son objetos independientes, sin embargo, las tiendas deben ser objetos literales para contener el array de productos.

{

    store: store,

    products:[]

}

• Por cada producto añadido debemos crear un objeto literal indicando el objeto Product y referenciando el título de la categoría asignada.

{

    product: product,

    category: _categories [categoryPosition].title

}

Esta aproximación nos podría dar la ventaja de transformar la estructura para que un producto pudiese pertenecer a varias categorías utilizando un array, pudiendo guardar en el array más de una referencia de categoría a través de su título.

{

    product: product,

    categories: []

}

Nota

Implementa una función de testeo de toda la funcionalidad implementada en la aplicación a través de la consola. Esta funcionalidad es imprescindible para corregir la práctica. Si la función no está implementada la nota final será de 0.

Podrás realizar cualquier cambio en la funcionalidad propuesta siempre y cuando esté justificada y mejore la funcionalidad propuesta.

Si consideras el diseño de los objetos, excepciones o argumentos de entrada y salida de los diferentes métodos también lo pueden realizar, siempre y cuando estén justificados.

Calificación

Es obligatorio que la práctica esté subida en GitHub para su corrección y etiquetada con la versión realizada.

La siguiente tabla muestra cómo se calificará esta práctica:

Criterio de evaluación	Puntos
Implementación de la aplicación. Verificación de funcionamiento.	3 puntos
Gestión de excepciones	1 punto
Eficiencia / Seguridad. Verifica el uso de funciones estándar y verifica los ámbitos de acceso a los objetos de tu aplicación.	1 punto
Estructura OO. Verificación del código siga el paradigma de orientación a objetos.	1 punto
Comentarios. Deberás comentar el código que has implementado.	1 punto
Uso de patrones de diseño y características avanzadas de objetos Transformación de los arrays por iteradores. (1,5 puntos) Uso del patrón Singleton (1 puntos) Empaquetado en módulos (0,5 puntos)	3 puntos

Tabla 2 Calificación