Universidad Nacional de Avellaneda

Trabajo Práctico Nº 1
Sistema de Control de Pesajes

Alumnos : Fernández, Alejandro

Larrarte, Ezequiel Mariano
Ané, Agustín Santiago
Materia : Ingeniería de Software
Carrera : Ingeniería en Informática
Curso : C-14118-C1
Docente : Graciana Roldán
 Índice de Contenidos

1 INTRODUCCIÓN...................................................................................................1
1.1 OBJETIVO...........................................................................................................................1
1.2 GLOSARIO..........................................................................................................................1
1.3 ALCANCE...........................................................................................................................1
2 DESCRIPCIÓN GENERAL..................................................................................2
2.1 GESTIÓN DE PROVEEDORES....................................................................................................2
2.2 GESTIÓN DE TARJETAS DE IDENTIFICACIÓN................................................................................2
2.3 INTERFAZ DE COMUNICACIÓN ENTRE LA APLICACIÓN Y LA BALANZA...............................................3
2.4 MONITOR DE ACTIVIDAD.......................................................................................................3
3 REQUISITOS..........................................................................................................4
3.1 REQUISITOS FUNCIONALES.....................................................................................................4
3.1.1 Diagrama de casos de uso......................................................................................4
3.1.2 Diagramas de secuencia.........................................................................................6
3.1.3 Diagrama de clases..............................................................................................14
3.2 REQUISITOS DE USUARIO Y TECNOLÓGICOS..............................................................................14
3.3 REQUISITOS DE INTERFACES EXTERNAS...................................................................................15
3.4 REQUISITOS DE RENDIMIENTO...............................................................................................15
3.5 REQUISITOS DE DESARROLLO Y RESTRICCIONES DE DISEÑO.........................................................15

ii
 1. Introducción

1 Introducción

1.1 Objetivo
Automatizar los pesajes de tierra, facilitando las siguientes tareas:
• Gestionar los proveedores (canteras).
• Gestionar las tarjetas de identificación de los camiones.
• Registrar los pesajes de entrada y salida de cada camión.
• Generar los reportes necesarios para la conciliación de pago a proveedores.

1.2 Glosario
ABM: aplicación de alta, baja y modificación.

1.3 Alcance
El alcance del presente proyecto, comprende:
• El desarrollo de los ABM de:
◦ Gestión de proveedores
◦ Gestión de tarjetas de identificación
• El desarrollo de una interfaz de comunicación entre la aplicación y el sistema
externo de pesaje.
• Un monitor de actividad donde se podrán visualizar los últimos movimientos
registrados de la balanza (que comprende identificación del camión y pesaje).
• La generación de los siguientes reportes:
◦ Pesajes por camión.
◦ Pesajes por proveedor.

Todo lo no detallado en el presente documento como alcance, será considerado como

adicional y tratado como un nuevo proyecto.

1
 2. Descripción General

2 Descripción General

2.1 Gestión de proveedores

Se realizará un ABM para gestionar los proveedores en el cual se podrá registrar los
siguientes atributos:
• Razón social
• CUIT
• Teléfono de contacto
• Dirección
• Email
• Activo (SI / NO)
Para el alta de cada proveedor, se deberá verificar:
• Todos los atributos detallados anteriormente, serán obligatorios.
• El CUIT ingresado deberá ser válido y no estar repetido.

No se podrá eliminar un proveedor que registre actividad. En este caso, se podrá

deshabilitar el mismo indicando NO en su atributo Activo, con lo cual todas sus tarjetas
de identificación serán desactivadas.
Todos los atributos de un proveedor podrán ser modificados siempre y cuando se respeten
las mismas restricciones del procedimiento de alta.

2.2 Gestión de tarjetas de identificación

Se realizará un ABM para gestionar las tarjetas de identificación en el cual se podrá
registrar los siguientes atributos:
• Número de tarjeta
• Patente
• Marca
• Modelo
• Proveedor
• Activo (SI / NO)

Para el alta de cada tarjeta, se deberá verificar:

• Todos los atributos detallados anteriormente, serán obligatorios.
• La patente ingresada deberá ser validada y no podrá existir más de una tarjeta
activa para la misma patente.
• El proveedor deberá estar cargado previamente.

2
 2. Descripción General

No se podrá eliminar una tarjeta que registre actividad. En este caso, se podrá deshabilitar
la misma indicando NO en su atributo Activo.
Una vez que una tarjeta ha sido asignada a un camión no puede ser reasignada a otro
camión. Esto significa que no podrán ser modificadas las tarjetas dadas de alta.

2.3 Interfaz de comunicación entre la aplicación y la balanza

Los pesajes tomados por la balanza serán directamente registrados por la aplicación
mediante una interfaz de comunicación. La misma será la encargada de validar el pesaje.
Eso incluye:
• Pasajes repetidos (+/- 5% del peso ya registrado).
• Control de tarjetas inactivas o no cargadas.

2.4 Monitor de actividad

Este módulo permitirá visualizar los pesajes registrados en el día. Además permitirá
cancelar y confirmar los pesajes entrantes y salientes.

3
 3. Requisitos

3 Requisitos

3.1 Requisitos funcionales

3.1.1 Diagrama de casos de uso

4
 3. Requisitos

CASO DE USO: Alta de proveedor

ACTORES: Pago a Proveedores
CURSO NORMAL ALTERNATIVAS
1. Pago a Proveedores ingresa los datos del nuevo proveedor,
verificando previamente el CUIT con la página de la AFIP.
2. El sistema verifica si el CUIT existe. 2.1 Si el CUIT existe y además está activo, se cancela el alta
informando el motivo.
2.2 Si el CUIT ya está registrado anteriormente y está inactivo, se
cancela el alta (se invoca al caso de uso "Activar Proveedor").
3. El sistema verifica que todos los datos obligatorios fueron 3.1 En caso de que algun dato obligatorio no se haya ingresado, se
ingresados. informa al usuario.
5. El sistema activa el nuevo proveedor (se invoca al caso de uso
"Activar Proveedor").

CASO DE USO: Alta de Tarjeta de Identificación

ACTORES: Recepción
CURSO NORMAL ALTERNATIVAS
1. Recepción ingresa los datos de la nueva tarjeta de
identificación.
2. El sistema verifica que el proveedor exista y esté activo. 2.1. Si el proveedor no existe, se permite generar dar de alta
uno nuevo (se invoca el caso de uso "Alta de proveedor").
3. El sistema verifica que la tarjeta no exista. 3.1 Si la tarjeta existe y se encuentra activa, se informa el error
y se cancela el alta. 3.2 Si
la tarjeta existe y se encuentra inactiva, se informa el error y se
cancela el alta (se invoca el caso de uso "Activar Tarjeta de
Identificación").
4. El sistema asigna un número de tarjeta de identificación y
activa la tarjeta

CASO DE USO: Registrar Pesaje

ACTORES: Balanza
CURSO NORMAL ALTERNATIVAS
1. La balanza envía los datos del pesaje.
2. El sistema verifica que la tarjeta este exista y esté activa. 2.1. Si la tarjeta de identificación no existe o está inactiva, se
informa el error a la balanza.
3. El sistema verifica que no exista un pesaje previo para la
tarjeta de identificación y genera un pesaje de entrada, en caso
de existir se genera un pesaje de salida.
4. Si es un pesaje de salida, el sistema verifica que no sea un 4.1. Si el pesaje es repetido, se informa el error a la balanza.
pesaje repetido (> 10% del pesaje de entrada).
5. El sistema registra el pesaje.

CASO DE USO: Baja de Proveedor

ACTORES: Pago a Proveedores
CURSO NORMAL ALTERNATIVAS
1. Pago a Proveedores selecciona el Proveedor.
2. El sistema verifica que el Proveedor no registre actividad. 2.1. Si el proveedor registra actividad, se ofrece la posibilidad
de desactivar al Proveedor (se invoca el caso de uso
"Desactivar Proveedor").
3. El sistema solicita confirmación.
4. Pago a Proveedores confirma la operación.
5. El sistema elimina el Proveedor seleccionado.

5
 3. Requisitos

3.1.2 Diagramas de secuencia

6
3. Requisitos

7
3. Requisitos

8
3. Requisitos

9
3. Requisitos

10
3. Requisitos

11
3. Requisitos

12
3. Requisitos

13
 3. Requisitos

3.1.3 Diagrama de clases

3.2 Requisitos de usuario y tecnológicos

El sistema deberá contemplar los siguientes requisitos tecnológicos:
• El sistema deberá operar bajo Linux (versión CentOS 6 x64).
• Se requiere un servidor dedicado para este sistema (que será instalado por
personal de la empresa).
• Se necesita también asociar nuestro sistema a un servidor de autenticación de
usuarios (el cual ya está funcionando en la empresa).

14
 3. Requisitos

3.3 Requisitos de interfaces externas

El conjunto balanza-lector de tarjetas de identificación posee un dispositivo electrónico
que convierte las lecturas de este conjunto en información legible por la interfaz de
comunicación. Aquí es donde comienza la entrada de datos del sistema.

3.4 Requisitos de rendimiento

No aplica.

3.5 Requisitos de desarrollo y restricciones de diseño

Es diseño esta basado en el patrón MVC ajustado para una aplicación WEB.

15