Modelo de Analisis

UNIVERSIDAD TECNOLÓGICA Curso: 5k3
NACIONAL Profesor:
Facultad Regional Córdoba Fidelibus, Mario Alberto
Ingeniería en Sistemas de J.T.P:
Información Chami Levy, Celia
Cátedra de PROYECTO Destefanis, Maria Laura
5º Nivel Ayudante:
Duran, Javier Rubén
Proyecto:
TecnoPez: Producto de Software para gestión

de criaderos de truchas
Carpeta:
Modelo de Análisis y Diseño
Grupo: 5 Integrantes:
Felippa Marcos
Ochoa Rodrigo
Tolosa Nicolás
Segunda Parte. Verme David
Nota: Para facilitar su publicación, este trabajo se
encuentra segmentado en dos partes.
Universidad Tecnológica Nacional TecnoPez Software
Facultad Regional Córdoba Análisis y Diseño, 5k3, 2005
Índice
Índice 1
Introducción 3
Modelo de Análisis 4
Descriptivos de diagramas de colaboración genéricos. 5
Caso registro 6
Caso consulta 7
Caso baja 8
Caso modificación 9
Análisis del paquete de atención al cliente 10
Análisis del paquete: atención al turista 11
Atención al turista: descripciones y diagramas de colaboración de…. 12
Diagrama de clases: paquete atención al turista 34
Análisis del paquete: Cliente 39
Cliente: Descripciones y diagramas de colaboración de análisis. 40
Cliente: Diagrama de clases. 43
Análisis del paquete: pedido 44
Pedido: Descripciones y diagramas de colaboración de análisis. 45
Pedido: Diagrama de Clases 70
Diagrama de Transición de Estados: Clase Pedido 73
Análisis del Paquete: Reclamos 74
Reclamos: Descripciones y diagramas de colaboración de análisis. 75
Reclamos: Diagrama de Clases 86
Diagrama de Transición de estados: Reclamo 87
Análisis del Paquete: Ventas 88
Ventas: Descripciones y diagramas de colaboración de análisis. 89
Ventas: Diagrama de Clases 113
Análisis del Paquete: Producción. 117
Análisis del Paquete: Alimentación 118
Alimentación: Descripciones y diagramas de colaboración de análisis. 119
Alimentación: Descripciones y diagramas de colaboración de análisis. 137
Análisis del Paquete: Clasificación e incubación 140
Clasificación e incubación: Descripciones y diagramas de colaboración 141
de análisis.
Clasificación e incubación: Diagrama de Clases 161
Diagrama de transición de estados: Lote de ovas. 164
Análisis del Paquete: compras 165
Compras: Descripciones y diagramas de colaboración de análisis. 166
Compras: Diagrama de Clases 188
Pedido a proveedor: Diagrama de transición de estados 189
Análisis del Paquete: Enfermedades y control de Estanques 190
Enfermedades y control de Estaques.: Descripciones y diagramas de 191
colaboración de análisis.
Enfermedades y control de estanques: Diagrama de Clases 216
Análisis del Paquete: Faenamiento y envasado 217
Faenamiento y envasado: Descripciones y diagramas de colaboración 218
de análisis.
Faenamiento y envasado: Diagrama de Clases 231
Análisis del Paquete: Producto 232
Producto: Descripciones y diagramas de colaboración de análisis. 233
Producto: Diagrama de Clases 237
Análisis del Paquete: Sistema 238
Sistema: Descripciones y diagramas de colaboración de análisis. 239
Paquete Sistema: Diagrama de Clases 250
Modelo de Diseño 251
Modelo de despliegue y Arquitectura 252
Descripción grafica de la arquitectura 254
Diagrama de Clase de Diseño: Clases encargadas de la persistencia. 255
Diagrama de colaboración de diseño: Acceso a Datos 256
Ochoa, Tolosa, Verme, Felippa – Pagina 2

Modelo de seguridad 258

Diagrama de Clases: Clases de Interfaz 259
Aspectos de Implementación: Componentes y generación de código. 261
Estándares de codificación 262
Responsabilidad de los actores del sistema 272
Modelo de datos: DER 278
DER: Paquete Sistema 278
DER: Paquete de Atención al Cliente 279
DER: Producción 280
Estimación del tamaño del producto 281

Introducción
En esta carpeta presentamos una refinación del modelo anterior, se
procede a describir de manera fina a todos los uses case encontrados en el
modelo anterior y refinar clases, que fueron analizadas mediante diagramas
de colaboración con el objetivo de determinar una forma de trabajar y de
analizar el dominio del problema.
Se incluye, el caso de uso, el paquete donde se encuentra, y en algunos
casos su realización seguida de un diagrama de clases que contiene las clases
involucradas con el caso de uso.
La intención de esta sección es plantear una metodología de trabajo
independiente de la plataforma donde se desarrolle buscando orientarla hacia
la arquitectura pretendida.
Se incluyen también los diagramas de casos de uso que sufrieron
pequeñas modificaciones en el proceso de refinamiento, para facilitar la
interpretación de este documento.
Por cada paquete se tiene las descripciones a trazo fino de análisis de los
casos de uso y en algunos se encuentran sus realizaciones (para tomar como
referencia a la hora de programar). Al final de cada paquete se encuentra el
diagrama de clases correspondiente al paquete y si el paquete tiene alguna
clase con estado se encuentra su correspondiente DTE. Colocamos los
diagramas de transición de estados en la etapa de análisis, porque nos resulto
más útil tenerlos a ese nivel.

Modelo de Análisis
El modelo de análisis, continuo con la organización de paquetes
planteada en la anterior entrega.
Producción Atención al Cl iente
Sistema
Se observa un nuevo paquete Sistema, que encapsula aspectos mas

relacionados con la implementación, entre ellos el manejo de usuarios
permisos, roles, inicio de sesión, etc.
Para simplificar la compresión de los diagramas de colaboración, se
omitió la instanciación de las interfaces, pero para cada interfaz se supone
que el actor emite el mensaje seleccionar opción x, y la interfaz x se
despliega.
A continuación un diagrama de colaboración de ejemplo de una
instanciación de interfaz de usuario.
2. despl egarInterfazRegistrarAli mentos
1. seleccionarOpcionRegistrarAlimento
: Interfaz de
: Encargado de Ali mentos
Producción

Descriptivos de Diagramas de Colaboración Genéricos
Los diagramas de colaboración correspondientes a las altas, bajas,

modificación y consultas (simples) de una entidad tendrán una estructura
similar a la descripta a continuación. Para facilitar la comprensión se incluirá
un ejemplo de cada caso.
En la colaboración se involucran los siguientes objetos:
Actor: es quien inicia la colaboración.
Interfaz: es el objeto que interactúa con el actor tomando los mensajes
enviados por el, y mostrando los resultados obtenidos de la acción de ejecutar
el mensaje.
Además la interfaz delegara en el gestor los mensajes enviados por el
actor.
Gestor: es quien se encarga de obtener los resultados solicitados por la
interfaz, para lo cual, se relacionara con la colección correspondiente.
Colección: es la encargada de conocer las instancias de la entidad en
cuestión.
Objeto de Entidad: representa las instancias de los objetos.

Caso Registro
Inicialmente, al actor involucrado en la colaboración envía un mensaje
(indicando los datos necesarios para crear un nuevo objeto) a la interfaz
correspondiente indicando que registre una instancia de la entidad.
Luego, se enviaran sucesivamente mensajes pasando por el gestor y la
colección hasta que llega a la entidad, momento en el cual se crea el nuevo
objeto.
Ejemplo:
1. registrarCliente(RazonSocial : , direccion : , telefono : , tipoDocumento : , nroDocumento : , email : , condicionIVA : , CUIT : , descripcion : , observaciones : , tipo...
5. registrarClienteAutogestion(nombreDeUsarioPass...
: Interfaz de
clientes
: Encargado de Atencion
al Cliente
6. registrarUsuarioAutogestion(nombre : , pass...
7. registrarUsuario(nombre : , pass...
: Cliente
: Gestor de Clientes
8. actualizar(cliente : Cliente)
: Coleccion de Clientes

Caso consulta
Se inicia cuando el actor envía un mensaje a la interfaz correspondiente
indicando que desea consultar los objetos de la entidad en cuestión.
Posteriormente se envían sucesivos mensajes que pasan por el gestor y la
colección hasta llegar a le entidad. Este mensaje devuelve un array con los
objetos de entidad consultados.
Ejemplo:
1. consultarCliente(razonSocial : , tipoDocumento : , nroDocumento : , descripcion...
: Interfaz de
: Encargado de Atencion clientes
al Cl iente
2. consultarCliente(razonSocial : , tipoDocumento : , nroDocumento : , descripci on...

: Coleccion de Clientes : Gestor de Cli entes
: Cliente

Caso baja
El actor selecciona el objeto que desea dar de baja enviando el mensaje
seleccionar a la interfaz. Este mensaje llega a la colección para que de esa
forma se seleccione al objeto y el gestor conocerá al objeto seleccionado.
Finalmente el actor envía el mensaje darDeBaja a la interfaz, la cual
envía un mensaje el gestor para que de de baja al objeto. Dado que el gestor
conoce al objeto en cuestión, se enviara un mensaje directamente a la
entidad, para que se de de baja al objeto.
Ejemplo:
1. consultarCli ente(razonSoci al : , tipoDocumento : , nroDocumento : , descri pcion...
5. selecci onarCl iente( ) 7. darDeBajaCli ente( )
: Interfaz de
: Encargado de Atenci on clientes
al Cl iente
6. selecci onarCl iente( )
8. darDeBajaCli ente( )
9. darDeBajaCli ente( )
3. consultarCli ente(razonSocial : , tipoDocumento : , nroDocumento : , descri pcion...

: Colecci on de Clientes : Gestor de Cl ientes
10. darDeBaj aCliente( )
: Cli ente

Caso Modificación
El actor selecciona el objeto que desea dar de baja enviando el mensaje
seleccionar a la interfaz. Este mensaje llega a la colección para que de esa
forma se seleccione al objeto y el gestor conocerá al objeto seleccionado.
Finalmente el actor envía el mensaje Modificar (indicando los datos
necesarios) a la interfaz, la cual envía un mensaje el gestor para que
modifique al objeto. Dado que el gestor conoce al objeto en cuestión, se
enviara un mensaje directamente a la entidad, para que se modifique al
objeto.
Ejemplo:
5. selecci onarCliente( )
: Interfaz de
: Encargado de Atenci on clientes
al Cliente
7. modificarCli ente(razonSoci al : , di recci on : , telefono : , tipoDocumento : , nroDocumento : , email : , condi ci onIVA : , CUIT : , descripcion : , observaciones : , tipo...
6. selecci onarCli ente( )
8. modificarCliente(razonSocial : , di recci on : , telefono : , tipoDocumento : , nroDocumento : , email : , condicionIVA : , CUIT : , descri pcion : , observaciones : , ti po...

: Colecci on de Clientes : Gestor de Clientes
9. modi ficarCli ente(razonSoci al : , direccion : , telefono : , tipoDocumento : , nroDocumento : , email : , condi cionIVA : , CUIT : , descri pcion : , observaciones : , tipo...
10. modificarCliente(razonSocial : , di reccion : , telefono : , tipoDocumento : , nroDocumento : , email : , condi ci onIVA : , CUIT : , descripcion : , observaciones : , tipo...
: Cli ente

Análisis del Paquete: Atención al cliente.
Pedi dos
Atención al Cl iente
Reclamos
Cliente
Atención al turista Ventas

Análisis del Paquete: Atención al turista
<<extend>>
29- Registrar Cliente

(f rom Cliente)
12- Registrar Cobro
30- Registrar Visita
(f rom Ventas)
48- Registrar especies
28- Consultar Cliente

49- Modifi car especies
<<extend>> (f rom Cliente)
63- Consultar visitas de turistas

50- Dar de baj a especies
Encargado de
31- Registrar Pesca 54- Emitir Listado de Lagunas y
Atencion al Cl iente
Especi es
60- Dar de baja a pesca registrada
53- Dar de baja laguna
61- Modificar registro de pesca 52- Modificar laguna
88- Modificar Tarifas 86- Registrar Tarifas
51- Registar Laguna
62- Consultar Registro de Pesca

87- Consultar Tarifas

Atención al Turista: Descripciones y diagramas de colaboración

de análisis.
Nivel del Use Case: Negocio Sistema de información
Nombre del Use Case: Registrar visita. Id: 30
Actor principal: Encargado de atención al cliente.
Tipo de Use Case: Concreto Abstracto
Objetivo: Registrar una nueva visita.
Precondiciones: Usuario logeado y con permisos para registrar a la visita
Poscondiciones:
Éxito:
• Visita registrada.
Fracaso:
• Use Case cancelado porque no se encuentra el cliente que realiza la visita.
• Use Case cancelado porque los datos de la visita no son correctos.
Curso normal Curso alternativo
1. El UC Comienza, cuando encargado de atención
al cliente selecciona la opción Visita de Turistas.
2. El encargado de atención al cliente selecciona
la opción “Nueva Visita”.
3. El sistema solicita que se seleccione el cliente
que realiza la visita.
4. El encargado de atención al cliente encuentra y 4.1 El encargado de atención al cliente NO
selecciona el cliente que realiza la visita. encuentra el cliente que realiza la visita.
4.1.1 El sistema pregunta si desea registrar
un nuevo cliente y el encargado de atención
al cliente si desea.
4.1.2 Se extiende en el Use Case “Registrar
Cliente”
4.1.1.1 Se cancela el Use Case.
5. El sistema solicita que se ingresen los datos de
la visita (fecha, hora, cantidad de pescadores,
cantidad de personas).
6. El encargado de atención al cliente ingresa los
datos solicitados.
7. El encargado de atención al cliente confirma la
operación.
8. El sistema valida los datos ingresados y son 8.1 El sistema valida los datos ingresados y
correctos. NO son correctos.
8.1.1 El sistema informa lo ocurrido.
8.1.2 Se cancela el Use Case.
9. El sistema registra la nueva visita.
10. El sistema pregunta si se desea registrar el 10.1 El sistema pregunta si se desea registrar
cobro al cliente ahora, y el encargado de atención el cobro al cliente ahora, y el encargado de
al cliente NO lo desea. atención al cliente si lo desea.
Cobro”.
11. Fin del Use Case.
Asociaciones de extensión: “Registrar Cobro”, “Registrar Cliente”.
Asociaciones de inclusión: No aplica.
Use Case donde se incluye: No aplica.
Use Case al que se extiende: No aplica.
Use Case de generalización: No aplica.
Historia de cambios
Versión Fecha Descripción de cambios Autor
1 07/06/2005 Creación Grupo de Desarrollo
2 17/07/2005 Modificación Grupo de Desarrollo


Nombre del Use Case: Registrar pesca. Id: 31
Objetivo: Registrar una nueva pesca.
Precondiciones: Usuario logeado y con permisos para registrar la pesca.
Poscondiciones:
Éxito:
• Pesca registrada.
Fracaso:
• Use Case cancelado porque los datos de la pesca no son correctos.
al cliente selecciona la opción Pesca.
la opción “Nueva Pesca”.
3. El sistema solicita que se seleccione la visita a
la cual se le desea registrar la pesca.
la visita a la cual se le va a registrar la pesca.
la pesca (cantidad pescada, especie y laguna en
que se realizó la pesca).
datos solicitados.
operación.
9. El sistema registra la nueva pesca.
Cobro”.
Asociaciones de extensión: “Registrar Cobro”.
Historia de cambios

10. registrarPesca(Especie, Cantidad, Laguna)
1. buscarVisitas(Nombre, Apellido) 6. consultarLagunas( )
: Encargado de
Atencion al Cliente
5. seleccionarVisita( )
: Gestor de Laguna
: Interfaz de Visitas
7. consultarLagunas( )
2. buscarVisitasDe(Nombre, Apellido)
3. buscarVisita(Nombre, Apellido)
: Gestor de visitas y pesca
: Coleccion de Lagunas
: Coleccion De Visitas
8. consultarLagunasYEspecies( )
4. consultar(Nombre, Apellido)
: Visita
: Laguna

9. consultarEspecies(Nombre)
: Detalle de Visita
: Coleccion de Especies
: Pesca
El diagrama de colaboración comienza con el mensaje

buscarVisitas(Nombre, Apellido). Este mensaje determina los filtros para
realizar la búsqueda de la visita que posteriormente será registrada. Luego
este mensaje se propaga hasta la entidad de visitas pasando previamente por
el gestor de visitas y la colección correspondiente.
El gestor conoce la colección que debe consultar para realizar la
búsqueda de la visita, y le delega la correspondiente responsabilidad.

Los mensajes de búsqueda devuelven los resultados de la búsqueda (si es

que se obtienen) a la clase que lo inicio. De esta forma llega un conjunto de
visitas que serán mostradas por la interfaz para que el cliente en el mensaje 5
pueda seleccionar la visita deseada.
Posteriormente se lleva a cabo el mensaje 6 consultarLagunas y 9
consultarEspecies para que como resultado de esto se muestre al encargado
de atención al cliente las lagunas existentes en las que se pueden realizar las
pescas, y las especies que se encuentran en las correspondientes lagunas.
Como resultado de esto el encargado de atención al cliente envía el
mensaje 10 registrarPesca indicando la laguna en la que se realizo la pesca,
las especies pescadas y las correspondientes cantidades.
Este mensaje se propaga a través del gestor de visitas y la colección de
visitas para que finalmente se registre la visita con la correspondiente pesca.


Nombre del Use Case: Registrar pesca. Id: 31
Objetivo: Registrar una nueva pesca.
Precondiciones: Usuario logeado y con permisos para registrar la pesca.
Poscondiciones:
Éxito:
• Pesca registrada.
Fracaso:
• Use Case cancelado porque los datos de la pesca no son correctos.
al cliente selecciona la opción Pesca.
la opción “Nueva Pesca”.
3. El sistema solicita que se seleccione la visita a
la cual se le desea registrar la pesca.
la visita a la cual se le va a registrar la pesca.
la pesca (cantidad pescada, especie y laguna en
que se realizó la pesca).
datos solicitados.
operación.
9. El sistema registra la nueva pesca.
Cobro”.
Asociaciones de extensión: “Registrar Cobro”.
Historia de cambios


Nombre del Use Case: Registrar especie. Id: 48
Objetivo: Registrar una nueva especie.
Precondiciones: Usuario logeado y con permisos para registrar la especie.
Poscondiciones:
Éxito:
• Especie registrada.
Fracaso:
• Use Case cancelado porque los datos de la especie no son correctos.
al cliente selecciona la opción Especie.
la opción “Nueva Especie”.
la especie (nombre, tamaño, color, peso).
datos de la especie.
operación.
6. El sistema valida los datos ingresados y los 6.1 El sistema valida los datos ingresados y
datos son correctos. NO son correctos.
7. El sistema registra la nueva especie.
Asociaciones de extensión: No aplica.
Historia de cambios


Nombre del Use Case: Modificar Especie. Id: 49
Objetivo: Modificar los datos de una especie existente.
Precondiciones: Usuario logeado y con permisos para modificar especie.
Poscondiciones:
Éxito:
• Especie actualizada.
Fracaso:
• Use Case cancelado por no existir la especie a modificar.
al cliente selecciona la opción Especies.
2. El sistema solicita el nombre de la especie.
3. El encargado de atención al cliente ingresa el
nombre de la especie.
4. El sistema emite un listado con el resultado de 4.1 El encargado de atención al cliente NO
la búsqueda, y el encargado de atención al cliente encuentra la especie a modificar.
selecciona la que desea modificar. 4.1.1 Se cancela el Use Case.
la opción “Modificar Especie”.
6. El encargado de atención al cliente modifica los
datos de la especie (nombre, tamaño, color,
peso).
operación.
8. El sistema actualiza los datos de la especie.
Historia de cambios


Nombre del Use Case: Dar de baja a especie. Id: 50
Objetivo: Dar de baja a especie.
Precondiciones: Usuario logeado y con permisos para dar de baja a especie.
Poscondiciones:
Éxito:
• Especie dada de baja.
Fracaso:
• Use Case cancelado por no existir la especie a dar de baja.
al cliente selecciona la opción Especies.
2. El sistema solicita los parámetros de búsqueda
de las especies(nombre)
parámetros de búsqueda y el sistema le informa
los resultados de la búsqueda.
selecciona la especie a dar de baja. encuentra la especie a dar de baja.
la opción “Dar de Baja a especie”.
operación.
7. El sistema da de baja a la especie.
Historia de cambios


Nombre del Use Case: Registrar laguna. Id: 51
Objetivo: Registrar una nueva laguna.
Precondiciones: Usuario logeado y con permisos para registrar a la laguna
Poscondiciones:
Éxito:
• Laguna registrada.
Fracaso:
• Use Case cancelado porque los datos de la laguna no son correctos.
al cliente selecciona la opción Lagunas.
la opción “Nueva Laguna”.
la laguna (descripción, ubicación, capacidad,
tamaño).
datos de la laguna.
5. El sistema muestra las especies existentes y
solicita que seleccionen las mismas y que ingresen
cantidades correspondientes a la laguna.
6. El encargado de atención al cliente ingresa las
especies que contiene la laguna y sus respectivas
cantidades.
operación.
9. El sistema registra la nueva laguna.
Historia de cambios


Nombre del Use Case: Modificar Laguna. Id: 52
Objetivo: Modificar los datos de una laguna existente.
Precondiciones: Usuario logeado y con permisos para modificar a la laguna
Poscondiciones:
Éxito:
• Laguna actualizada.
Fracaso:
• Use Case cancelado por no existir la laguna a modificar.
de las lagunas(descripción, ubicación, capacidad,
tamaño).
parámetros de búsqueda.
selecciona la laguna a modificar. encuentra la laguna a modificar.
la opción “Modificar laguna”.
datos de la laguna (descripción, ubicación,
capacidad, tamaño).
7. El encargado de atención al cliente si es
necesario modifica las especies que posee las
lagunas y las cantidades de las correspondientes
especies.
operación.
9. El sistema actualiza los datos de la laguna.
Historia de cambios


Nombre del Use Case: Dar de baja a laguna. Id: 53
Objetivo: Dar de baja a una laguna existente.
Precondiciones: Usuario logeado y con permisos para dar de baja a la laguna.
Poscondiciones:
Éxito:
• Laguna dada de baja.
Fracaso:
• Use Case cancelado por no existir la laguna a dar de baja.
de las lagunas(descripción, ubicación, capacidad,
tamaño).
selecciona la laguna a dar de baja. encuentra la laguna a dar de baja.
la opción “Dar de Baja a laguna”.
operación.
7. El sistema da de baja a la laguna.
Historia de cambios


Nombre del Use Case: Emitir listado de lagunas y especies. Id: 54
Objetivo: Emitir un listado de lagunas y las especies que contienen.
Precondiciones: Usuario logeado y con permisos para emitir listado de laguna y especies.
Poscondiciones:
Éxito:
• Informe de especies, lagunas generado.
Fracaso:
• Cancelado, operario no válido.
1. El UC Comienza, cuando el usuario selecciona
la opción Emitir informe de lagunas y especies.
2. El usuario selecciona las lagunas que quiere que
desea que formen parte del informe y las fechas
que desea analizar.
3. El sistema genera el informe mostrando, la
cantidad de pescados, especie en cada laguna,
ubicación, haciendo hincapié en las especies en
peligro de extinción y las lagunas con condiciones
optimas para realizar la pesca.
Historia de cambios

1. emi ti rListadoDeLagunasYEspecies( )
: Interfaz de
5. seleccionarLaguna(i d[]) Lagunas
: Encargado de
Atenci on al Cl iente 2. consultarLagunas( )
6. emi ti rInformeDeLagunasYEspecies(id[])
: Gestor de Laguna
7. consultarLagunas(i d[])
3. consultarLagunas( )
4. consultarLaguna( )
8. consultarLagunasYEspecies( )
: Colecci on de Lagunas : Laguna
9. consultarPobl acion( )
: Detall e de laguna
El diagrama de colaboración comienza con el mensaje

emitirListadoDeLagunasYEspecies y este hace que el sistema busque y muestre
las lagunas existentes para que el encargado de atención al cliente pueda
seleccionar la deseada. El sistema consigue hacer esto enviando el mensaje
ConsultarLagunas el cual se envía hasta la entidad de lagunas.
El encargado de atención al cliente selecciona la laguna de la cual desea
obtener el listado de lagunas y especies enviando el mensaje
seleccionarLaguna(id). El sistema consulta la laguna y las especies la obtiene
del detalle de la laguna, y de esta forma muestra el listado deseado.


Nombre del Use Case: Dar de baja a pesca registrada. Id: 60
Objetivo: Dar de baja a un registro de pesca.
Precondiciones: Usuario logeado y con permisos para dar de baja a pesca
Poscondiciones:
Éxito:
• Registro de pesca dado de baja.
Fracaso:
• Use Case cancelado por no existir el registro de pesca a dar de baja.
• Use Case cancelado por falta de pescas para dar de baja.
al cliente selecciona la opción Pescas.
de las pescas (fecha, nombre del visitante).
4. El sistema devuelve los resultados y estos 4.1 No se encuentran pescas con los filtros
existen. colocados.
selecciona el registro de pesca a dar de baja. encuentra el registro de pesca a dar de baja.
la opción “Dar de Baja a registro de pesca”.
operación.
7. El sistema da de baja al registro de pesca. Y
actualiza las poblaciones de las lagunas.
Historia de cambios


Nombre del Use Case: Modificar Tarifas. Id: 88
Objetivo: Modificar los datos de una tarifa existente.
Precondiciones: Usuario logeado y con permisos para poder modificar tarifas.
Poscondiciones:
Éxito:
• Tarifa actualizada.
Fracaso:
• Use Case cancelado por no existir la tarifa a modificar.
al cliente selecciona la opción Tarifas.
de la tarifa (concepto, precio, fecha de vigencia).
selecciona la tarifa a modificar. encuentra la tarifa a modificar.
la opción “Modificar Tarifa”.
datos de la tarifa (concepto, precio, fecha de
vigencia).
operación.
8. El sistema actualiza los datos de la tarifa.
Historia de cambios


Nombre del Use Case: Modificar Registro de Pesca. Id: 61
Objetivo: Modificar los datos de un registro de pesca existente.
Precondiciones: Usuario logeado y con permisos para registrar pesca.
Poscondiciones:
Éxito:
• Registro de pesca actualizado.
Fracaso:
• Use Case cancelado por no existir el registro de pesca a modificar.
• Use Case cancelado por falta de resultados en la búsqueda de pescas.
al cliente selecciona la opción Pescas.
de las pescas (fecha, nombre del visitante).
4. El sistema informa los resultados al usuario y 4.1 No se encuentran resultados de pescas.
estos existen. 4.1.1 Se cancela el Use Case.
selecciona el registro de pesca a modificar. encuentra el registro de pesca a modificar.
la opción “Modificar Registro de pesca”.
datos de la pesca (cantidad pescada, especies,
lagunas).
operación.
9. El sistema actualiza los datos del registro de
pesca.
Historia de cambios
1 17/07/2005 Creación ntolosa
1.1 30/07/2005 Modificación. rochoa

tipomov: incremento o
1. buscarPescas(fecha, nombre del visitante) 13. modificarPesca(especie, cantidad, tipomov) decremento de pesca
en una laguna de una
determinada especie.
6. seleccionarPesca(id) : Interfaz de Pesca
: Encargado de
Atencion al Cliente 7. seleccionarPesca(id)
11. consultarTodas( )
2. buscarPescas(fecha, nombre del visitante)
14. actualizarPesca(especie, cantidad, tipomov)
15. actualizarPesca(especie, cantidad, tipomov)

: Pesca : Gestor de visitas y pesca : Gestor de Especies
3. buscarPescas(fecha, nombre del visitante)

16. actualizarPoblacion(especie, cantidad, tipodemov)
17. actualizarPoblacion(especie, cantidad, tipodemov)
12. consultarTodas( )
8. buscarPesca(id)
: Laguna : Detalle de laguna
10. buscarPesca(id) 9. buscarPesca(id)
5. obtenerPesca( ) 4. obtenerPesca( )
: Detalle de Visita : Visita : Coleccion De Visitas : Coleccion de Especies


Nombre del Use Case: Consultar Registro de pesca. Id: 62
Objetivo: Consultar las pescas realizadas por los turistas.
Precondiciones: Usuario logeado y con permisos para consultar registro de pesca.
Poscondiciones:
Éxito:
• Pescas de turistas consultadas.
Fracaso:
al cliente selecciona la opción Ficha de Pescas.
de las pescas (cantidad pescada, especies,
lagunas, fechadesde, fechahasta).
4. El sistema muestra los resultados de la
búsqueda.
Historia de cambios
1. consultarRegistroDePesca(cantidadPesc, especies, lagunas, fechadesde, fechahasta)
: Interfaz de Pesca
: Encargado de
Atencion al Cliente
2. consultarPescas(cantidad pescada, especies, lagunas, fechadesde, fechahasta)
3. consultarPescas(cantidad pescada, especies, lagunas, fechadesde, fechahasta)

: Coleccion De Visitas : Gestor de visitas y pesca
6. consultarPesca( )
4. obtenerPesca( )
: Pesca
5. obtenerPesca( )
: Visita : Detalle de Visita


Nombre del Use Case: Consultar Visitas de Turistas. Id: 63
Objetivo: Consultar las visitas realizadas por los turistas.
Precondiciones: Usuario logeado y con permisos para consultar turista.
Poscondiciones:
Éxito:
• Visitas de turistas consultadas.
Fracaso:
al cliente selecciona la opción Visitas de Turistas.
de la Visita (fecha, hora, cliente, cantidad de
pescadores).
búsqueda.
Historia de cambios
1. consultarVisitas(fecha, hora, cliente, cantidad de pescadores) 2. consultarVisita(fecha, hora, cliente, cantidad de pescadores)
: Interfaz de Visitas
: Encargado de : Gestor de visitas y pesca
Atenci on al Cliente
3. consultarVisitas(fecha, hora, cliente, cantidad de pescadores)

: Coleccion De Vi si tas
: Visita
4. consultar( )
5. consultar( )
: Detalle de Visita


Nombre del Use Case: Registrar tarifa. Id: 86
Objetivo: Registrar una nueva tarifa.
Precondiciones: Usuario logeado y con permisos para poder registrar tarifa
Poscondiciones:
Éxito:
• Tarifa registrada.
Fracaso:
• Use Case cancelado porque los datos de la laguna no son correctos.
la opción “Nueva Tarifa”.
la tarifa (concepto, precio, fecha de vigencia).
datos de la tarifa.
operación.
7. El sistema registra la nueva laguna.
Historia de cambios

1. RegistrarT arifa(concepto, precio, fecha vigenci a)
: Interfaz de
T arifas
: Encargado de
Atenci on al Cl iente
2. regi strarT ari fa(concepto, precio, fecha vi gencia)
3. regi strarTari fa(concepto, precio, fecha vi gencia)

: Colecci on De Tarifas : Gestor de Tari fas
4. regi strarT ari fa(concepto, precio, fecha vigencia)
: T ari fa


Nombre del Use Case: Consultar Tarifas. Id: 87
Objetivo: Consultar las Tarifas existentes.
Precondiciones: Usuario logeado y con permisos para poder consultar tarifas.
Poscondiciones:
Éxito:
• Tarifas consultadas.
Fracaso:
de la tarifa (concepto, precio, fecha de vigencia).
búsqueda.
Historia de cambios

Diagrama de Clases: Paquete Atención al Turista
Gestor de Especies
especieSeleccionada : Especie
resultadoDeBusqueda[] : Especie
coleccionDeEspecies : Coleccion de Especies
1
registrarEspecie(nombre, tamaño maximo, peso maximo, color, tamaño minimo, peso minimo, observ aciones)
consultarEspecies(Nombre)
modif icarEspecie(nombre, tamaño maximo, peso maximo, color, tamaño minimo, peso minimo, observ aciones)
seleccionarEspecie(id)
darDeBajaEspecieSeleccionada()
consultarTodas()
obtenerEspecie(id)
Coleccion de Especies
especies[] : Especie
1
darDeBajaEspecie(EspecieSeleccioanda : Especie)
consultarTodas()
obtenerEspecie(id)
1..*
Especie
nombre
tamaño maximo
color
peso maximo
tamaño minimo
peso minimo
observ aciones
id
consultarEspecie(nombre)
darDeBaja()
consultar()
Interf az de Especies
gestorDeEspecies : Gestor de Especies
seleccionarEspecie()
darDeBajaEspecie()

Gestor de Laguna
lagunaSeleccionada : Laguna
coleccionDeLagunas : Coleccion de Lagunas
Coleccion de Lagunas detalleDeLaguna : Detalle de Laguna
lagunas[] : Laguna gestorDeEspecies : Gestor de Especies
consultarLagunas() consultarLagunas()
guardarLaguna(Laguna : Laguna) cargarDatosLaguna(descripción, ubicación, capacidad, tamaño)
buscarLaguna(descripción, ubicación, capacidad, tamaño) 1 cargarEspecie(id, cantidad)
buscarLaguna(id) registrarLaguna()
borrarLaguna(Laguna : Laguna) buscarLagunas(descripción, ubicación, capacidad, tamaño)
consultarLagunas(id[]) seleccionarLaguna(id)
modificarLaguna(laguna : Laguna) modificarLaguna(descripción, ubicación, capacidad, tamaño)
modiciarDetalleLag(Especie, cantidad)
borrarLaguna()
emitirInformeDeLagunasYEspecies(id[])
...
Laguna
capacidad
tamaño
descripcion
ubicación
detalledelaguna : Detalle de laguna Interfaz de Lagunas
id
gestorDeLaguna : Gestor de Laguna
crearLaguna(descripción, ubicación, capacidad, tamaño, detalle) gestorDeEspecies : Gestor de Especies
consultarEspecies()
darDeBaja() cargarDatosLaguna(descripción, ubicación, capacidad, tamaño)
consultarLagunasYEspecies() cargarEspecie(id, cantidad)
modificarLaguna(descripción, ubicación, capacidad, tamaño) registrarLaguna()
modificarDetalle(Especie, cantidad) cancelarRegistracionDeLaguna()
consultarLaguna() buscarLagunas(descripción, ubicación, capacidad, tamaño)
actualizarPoblacion(especie, cantidad, tipodemov) seleccionarLaguna(id)
modificarLaguna(descripción, ubicación, capacidad, tamaño)
modificarDetalleLaguna(Especie, cantidad)
borrarLaguna()
emitirListadoDeLagunasYEspecies()
seleccionarLaguna(id[])
Detalle de laguna
especie : Especie
cantidad
consultarPoblacion() n
modificarPoblación(Especie, cantidad)
cargarDetalle(especie, cantidad)
actualizarPoblacion(especie, cantidad, tipodemov) Especie
(from Espe...

T arifa
Colecci on De Tarifas concepto
precio
tarifas[] : Tarifa
fechaDeVigenci a
id
registrarT arifa(concepto, precio, fecha vigenci a) *
consul tarT ari fa(concepto)
consultarT ari fa(concepto)
modifi carT arifa(concepto, precio, fecha vigencia)
modifi carT arifa(concepto, precio, fecha vigenci a)
obtenerT arifa(id)
darDeBajaT arifa()
1 registrarT arifa(concepto, precio, fecha vigenci a)
Gestor de T ari fas

coleccionDeT arifas : Col eccion De T ari fas Interfaz de Tarifas
tarifaSelecci onada : T arifa
gestorDeT ari fas : Gestor de T arifas
resul tadoDeBusqueda[]
1 Regi strarT ari fa(concepto, preci o, fecha vigencia)

registrarT arifa(concepto, precio, fecha vigenci a)
consultarT ari fa(concepto)
consul tarT ari fa(concepto)
seleccionar T ari fa()
sel eccionar T ari fa()
modifi carT arifa(concepto, precio, fecha vigenci a)
modifi carT arifa(concepto, precio, fecha vigencia)
buscarT arifa(id)

Pegar aca
Class Diagram: Visita / Visita Page

Pegar aquí atención al turista / atención al turista.

Análisis del Paquete: Cliente
Cliente
Encargado de
Cobros Encargado de
Pedidos
28- Consultar Cliente
57- Dar de baja al Cliente 29- Registrar Cliente
Encargado de
58- Modificar datos del Cliente
Atencion al Cliente

Cliente: Descripciones y diagramas de colaboración de

análisis.
Nombre del Use Case: Modificar datos del Cliente. Id: 58
Objetivo: Modificar los datos de un cliente existente.
Precondiciones: Usuario logeado y con permisos para poder modificar datos del cliente.
Poscondiciones:
Éxito:
• Cliente actualizado.
Fracaso:
• Use Case cancelado por no existir el cliente a modificar.
al cliente selecciona la opción Clientes.
del cliente (razón social, dirección, teléfono, tipo
y número de documento, mail, condición de IVA,
CUIT/CUIL, nombre, apellido).
selecciona al cliente a modificar. encuentra al cliente a modificar.
la opción “Modificar Cliente”.
datos del cliente (razón social, dirección,
teléfono, tipo y número de documento, mail,
condición de IVA, CUIT/CUIL, nombre, apellido).
operación.
8. El sistema actualiza los datos del cliente.
Historia de cambios

Nombre del Use Case: Consultar Cliente. Id: 28
Objetivo: Consultar los datos de los clientes existentes.
Precondiciones: Usuario logeado y con permisos para poder consultar cliente
Poscondiciones:
Éxito:
• Clientes consultados.
Fracaso:


y número de documento, mail, condición de IVA,
búsqueda.
Historia de cambios

Nombre del Use Case: Registrar cliente. Id: 29
Objetivo: Registrar un nuevo cliente.
Precondiciones: Usuario logeado y con permisos para registrar al cliente.
Poscondiciones:
Éxito:
• Cliente registrado.
Fracaso:
• Use Case cancelado porque los datos del cliente no son correctos.
la opción “Nuevo Cliente”.
3. El sistema solicita que se ingresen los datos del
cliente (razón social, dirección, teléfono, tipo y
número de documento, mail, condición de IVA,
datos del cliente.
5. El sistema solicita que se ingresen los datos
para crear la autogestión del cliente (password,
nombre de usuario).
datos de la autogestión del cliente.
operación.
9. El sistema registra al nuevo cliente.


Use Case al que se extiende: “Registrar Visita”.
Historia de cambios
1 07/06/2005 Creación

Nombre del Use Case: Dar de baja a cliente. Id: 57
Objetivo: Dar de baja a un cliente.
Precondiciones: Usuario logeado y con permisos para dar de baja al cliente.
Poscondiciones:
Éxito:
• Cliente dada de baja.
Fracaso:
• Use Case cancelado por no existir el cliente a dar de baja.
de los clientes (razón social, dirección, teléfono,
tipo y número de documento, mail, condición de
IVA, CUIT/CUIL, nombre, apellido).
selecciona al cliente a dar de baja. encuentra al cliente a dar de baja.
la opción “Dar de Baja a cliente”.
operación.
7. El sistema da de baja al cliente.
Historia de cambios

Cliente: Diagrama de Clases
Pegar aquí el diagrama de clases cliente

Análisis del Paquete: Pedido

Pedidos
40- Registrar Recepcion de Remitos

<<extend>>
20- Registrar envio de pedido 7- Emitir Remito

4- Emitir Listado de pedidos a armar
130- Consultar Pedidos
65- Anular Remito

Encargado de
Pedidos
14- Anular Pedido
5- Registrar armado del pedido

131- Registrar Transportista 134- Consultar Transportistas
<<include>>
133- Dar de baja transportista 132- Modificar Transportista
Encargado de 6- Consultar Existencia de Productos

Cobros
<<extend>>
Encargado de Venta 44- Consultar existencia de

productos a futuro
<<extend>>
<<extend>>
36- Registrar pedido

(f rom Cliente)

Pedido: Descripciones y diagramas de colaboración de análisis.

Nombre del Use Case: Consultar transportista. Id: 134
Actor principal: Encargado de pedido.
Objetivo: Consultar los datos de los transportistas existentes.
Precondiciones: Usuario logeado y con permisos para consultar transportista
Poscondiciones:
Éxito:
• Transportistas consultados.
Fracaso:
• Use case cancelado por no obtener resultados de la búsqueda.
1. El Use Case Comienza, cuando encargado de
pedido selecciona la opción transportistas.
del transportista (razón social, CUIT).
3. El encargado de producción ingresa los
4 El sistema realiza la búsqueda, obtiene 4.1 No se encuentran resultados de la
resultados y los muestra. búsqueda.
Historia de cambios


Nombre del Use Case: Emitir listado de pedidos a armar. Id: 4
Actor principal: Encargado de pedidos.
Objetivo: Informar sobre los pedidos pendientes para armar.
Precondiciones: Usuario logeado y con permisos para emitir listado a armar.
Poscondiciones:
Éxito:
• Listado de pedidos a armar emitido.
Fracaso:
1. El UC Comienza, cuando el encargado de
pedidos selecciona la opción Pedidos.
2. El encargado de pedidos selecciona la opción
Emitir listado de Pedidos a armar.
3. El sistema solicita que se ingresen los
parámetros de búsqueda de pedidos (cliente,
fecha de emisión, fecha de entrega, prioridad).
4. El encargado de pedidos ingresa los parámetros
de búsqueda.
5. El sistema emite el listado de pedidos a armar
en base a los parámetros ingresados.
Historia de cambios
1. buscarPedidosParaArmar(fecEmisD, fecEmisH, fecEntregaD, fecEntregaH, prioridad)
: Interfaz de
: Encargado de Pedidos Pedidos

: Coleccion de Pedidos : Gestor de pedidos
4. consultarPedido( )
: Pedido


Nombre del Use Case: Registrar armado de pedido. Id: 5
Objetivo: Registrar el armado de un pedido existente.
Precondiciones: Usuario logeado y con permisos para registrar el pedido.
Poscondiciones:
Éxito:
• Armado de pedido registrado.
Fracaso:
• Use Case cancelado por no existencia del pedido.
• Use Case cancelado por no existencia de productos.
• Use Case cancelado por invalides de los datos ingresados.
1. El UC Comienza, cuando encargado de pedidos
selecciona la opción Pedidos.
parámetros de búsqueda de los pedidos (fecha de
emisión, fecha de entrega, prioridad, cliente).
de búsqueda.
4. El sistema realiza la búsqueda teniendo en 4.1 No se encuentran resultados de la
cuenta los pedidos que están con estado búsqueda.
pendiente de Armar, obtiene resultados y los 4.1.1 Se cancela el Use Case.
muestra.
5. El encargado de pedidos encuentra el pedido a 5.1 El encargado de pedidos No encuentra el
armar y lo selecciona. pedido a armar.
5.1.1 Se cancela el Use case.
6. El sistema muestra los productos incluidos en el
pedido y sus correspondientes cantidades.
7. El encargado de pedidos consulta la existencia 7.1 El encargado de pedidos consulta la
de productos (se incluye el use case Consultar existencia de productos (se incluye el use
Existencia de productos) y hay existencia. case Consultar Existencia de productos) y NO
hay existencia.
8. El encargado de pedidos ingresa para cada
producto la cantidad y el lote al cual pertenecen.
9. El encargado de pedidos ingresa la fecha de
armado.
10. El encargado de pedidos confirma la
operación.
11. El sistema valida los datos y son correctos. 11.1 El sistema valida los datos ingresados y
NO son correctos.
12. El sistema registra el armado del pedido.
13. El sistema valida si el pedido seleccionado es 13.1 El sistema valida si el pedido
de entrega en mostrador y si lo es. seleccionado es de entrega en mostrador y no
lo es (se envía).
13.1.1 El sistema actualiza el estado del
pedido seleccionado como Pendiente de
enviar.
13.1.2 Fin del Use Case.
14. El sistema actualiza el estado del pedido
seleccionado como Entregado.


Use Case donde se incluye: Consultar existencia de productos.
Historia de cambios

lote de
faenamiento
1. buscarPedidosParaArmar(fecEmi sD, fecEmisH, fecEntregaD, fecEntregaH, pri oridad)

17. regi strarArmado(Fecha)
5. seleccionarPedidoArmar(id) 11. regi strarArmadoDePedido(producto, cantidad, idLote)

: Interfaz de
2. buscarPedidosParaArmar(fecEmi sD, fecEmisH, fecEntregaD, fecEntregaH, prioridad)

18. regi strarArmado(Fecha)
6. seleccionarPedido(id)
8. consultarProductosDelPedido( )
12. registrarArmadoProducto(producto, cantidad, loteDeFaenamiento)
7. obtenerPedido(id)
: Colecci on de Pedidos 22. actualizarPedi do(Pedido) : Gestor de pedidos

3. buscarPedidosParaArmar(fecEmi sD, fecEmisH, fecEntregaD, fecEntregaH, pri oridad)
4. consultarPedi do( )
21. regi strarResponsableDeArmado(UsuarioSis)
13. verificarLoteDeFaenamiento(i dLote)
19. cambiarEstadoDeArmado(fecha)
15. registrarArmado(producto, cantidad)
9. consultarProductos( )
: Detall e de pedido 16. regi strarArmado( ) : Pedido

10. consultarProductos( ) el estado si guiente a armado
variara segun el ti po de
entrega
20. getUsuarioLogueado( )
: Gestor de Faenamiento
: Gestor de Usuarios
14. buscarLote(id)
: Coleccion de Lotes de
Faenamiento
El diagrama de colaboración comienza con el mensaje 1

buscarPedidosParaArmar. Este mensaje se propaga hasta la entidad de pedido
(pasando por el gestor de pedido y la colección de pedido), de esta forma se
buscan los pedidos que están pendientes de armado y se los muestran al
encargado de pedido. El encargado de pedido selecciona el pedido que desea
armar con el mensaje seleccionarPedidoArmar(id). El id representa el pedido
seleccionado. A través del mensaje consultarProductosDelPedido se buscan los

productos incluidos en el pedido seleccionado con el objetivo de mostrárselo

al encargado de pedidos.
El encargado de pedido mediante el mensaje registrarArmadoDePedido
inicia el registro del pedido a armar. Este mensaje desencadena los mensajes
de verificarLoteDeFaenamiento para que de esta forma se indique con que
lote de faenamiento se realiza el armado con el objeto de que el cliente
pueda realizar un reclamo e indicar el lote defectuoso.
Finalmente, se registra el armado del pedido con el mensaje 17
registrarArmado(fecha) y se actualiza el estado del pedido con el mensaje
cambiarEstadoDeArmado(fecha).


Nombre del Use Case: Consultar existencia de productos. Id: 6
Actor principal: Encargado de venta.
Objetivo: Consultar la existencia (disponibilidad) de los productos.
Precondiciones: Usuario logeado y con permisos para consultar existencia de producto.
Poscondiciones:
Éxito:
• Existencia de productos consultados.
Fracaso:
1. El UC Comienza, cuando Encargado de venta
selecciona la opción Productos.
2. El Encargado de venta selecciona la opción
consultar existencia de productos.
de los productos (nombre, precio, tipo,
vencimiento).
4. El encargado de venta ingresa los parámetros
de búsqueda.
5. El sistema muestra los productos y sus
respectivas existencias de acuerdo a los
parámetros de búsqueda ingresados.
Asociaciones de inclusión: “Registrar armado de pedido”.
Use Case al que se extiende: “Registrar Pedido”.
Historia de cambios

1. consultarDisponibilidad(nombre, precio, tipo, vencimiento)
: Interfaz de
: Encargado de Venta Productos
2. consultarDisponibil idad(nombre, precio, tipo, vencimiento)
5. calcularExistenciaActual(Producto)
: Existencia de productos : Gestor de Productos
3. buscarProductos(nombre)
4. consultar( )
: Producto : Colecci on de Productos
El diagrama se inicia cuando el encargado de venta envía el mensaje

consultarDisponibilidad. Este mensaje es enviado al gestor de productos, el
cual se encarga de buscar el producto del cual se desea conocer la existencia,
y luego de obtener los productos deseados, envía un mensaje a la entidad
existencia de productos para que le informa sobre la existencia (stock) de los
mismos.


Nombre del Use Case: Emitir remito. Id: 7
Objetivo: Emitir un remito para el envió de un pedido.
Precondiciones: Usuario logeado y con permisos para emitir remito
Poscondiciones:
Éxito:
• Remito generado y emitido.
Fracaso:
• Use case cancelado por no existencia de envió de pedido.
• Use Case cancelado por no existencia del transportista.
1. El UC Comienza, cuando Encargado de pedidos
selecciona la opción Remitos.
Nuevo Remito.
3. El sistema solicita que se seleccione el envió de
pedido deseado.
4. El encargado de pedidos busca el envió de
pedido correspondiente.
5. El encargado de pedidos encuentra y selecciona 5.1 El encargado de pedidos NO encuentra.
el envió de pedido correspondiente. 5.1.1 Se cancela el Use Case.
6. El sistema muestra el destino y la fecha de
envió del envió de pedido seleccionado.
7. El sistema solicita que se seleccione el
transportista.
8. El encargado de pedidos busca al transportista.
9. El encargado de pedidos encuentra al 9.1 El encargado de pedidos NO encuentra al
transportista y lo selecciona. transportista.
10. El encargado de pedidos confirma la
operación, definiendo la fecha y las observaciones
si fuere necesario.
11. El sistema registra el remito.
12. El sistema emite el remito registrado.
Use Case al que se extiende: “Registrar envió de pedido”.
Historia de cambios

14. regi strarRemito(fecha, observaciones)
:
interfazDeEnvi os
: Encargado de Pedi dos
2. buscarEnvioDePedidosSinRemitos( )
5. selecci onarEnvioDePedido(id)
7. obtenerT ransportistas( )
11. seleccionarTransportista(id)
15. registrarRemito(fecha, observaciones)
19. emi tirComprobanteRemito( )
: Colecci on de Envio de 6. obtenerEnvi oDePedido(id) : Gestor de Envios

pedido 3. buscarEnvioDePedidoSinRemito( )
16. obtenerPedi do( ) 8. obtenerT odos( )

12. seleccionarT ransportista(id)
18. registrarRemito(remito)
: Envio de pedido
17. regi strarRemito(fecha, pedido, observaciones)
: Gestor de Transportistas
: Coleccion de Remi to
: Remito
13. obtenerT ransportista(id)

9. obtenerTodos( )
: Colecci on de Transportistas


Nombre del Use Case: Anular pedido. Id: 14
Objetivo: Anular un pedido existente.
Precondiciones: Usuario logeado para anular pedido.
Poscondiciones:
Éxito:
• Pedido anulado.
Fracaso:
• Use Case cancelado por no encontrar resultados en la búsqueda.
emisión, fecha de entrega, prioridad, cliente).
de búsqueda.
4. El sistema muestra el resultado de la búsqueda. 4.1 No se encuentran resultados de
búsqueda.
5. El encargado de pedidos encuentra el pedido a 5.1 El encargado de pedidos No encuentra el
anular y lo selecciona. pedido a anular.
6. El sistema muestra el pedido y su detalle.
7. El encargado de pedido selecciona la opción
Anular Pedido.
8. El encargado de pedidos confirma la operación.
9. El sistema anula el Pedido seleccionado.
Historia de cambios


Nombre del Use Case: Registrar envió de pedido. Id: 20
Actor principal: Encargado de ventas.
Objetivo: registrar el envió de un pedido existente.
Precondiciones: Usuario logeado y con permisos para registrar envió de pedido.
Poscondiciones:
Éxito:
• Envió de pedido registrado.
Fracaso:
• Use Case cancelado por invalidez de los datos ingresados.
1. El UC Comienza, cuando encargado de ventas
selecciona la opción Envió de Pedidos.
2. El encargado de ventas selecciona la opción
Nuevo Envió de Pedido.
3. El sistema muestra los pedidos pendientes de
envió ordenados por prioridad.
4. El encargado de ventas busca el pedido a
enviar.
5. El encargado de pedidos encuentra el pedido al 5.1 El encargado de pedidos NO encuentra el
cual se le desea registrar el envió y lo selecciona. pedido al cual se le desea registrar el envió.
6. El sistema solicita que se ingrese el destino, la
fecha de entrega y observaciones si hicieran falta.
7. El encargado de ventas ingresa los datos
solicitados.
8. El encargado de ventas confirma la operación.
9. El sistema valida los datos y son correctos. 9.1 El sistema valida los datos y no son
correctos.
9.1.1 El sistema informa la invalidez de los
datos.
10. El sistema registra el envió de pedido y
actualiza el estado de pedido a Enviado.
11. El sistema pregunta si se desea registrar un 11.1 El sistema pregunta si se desea registrar
remito, y el encargado de ventas no lo desea. un remito, y el encargado de ventas si lo
desea.
11.1.1 Se extiende el Use Case “Emitir
Remito”.
Asociaciones de extensión: “Emitir Remito”.
Historia de cambios

1. buscarPedidosPendi entesDeEnvio( )
7. regi strarDatosEnvio(destino, fechaDeEntrega, observaciones)
11. confirmarRegi stroDeEnvio( )
:
: Encargado de Venta interfazDeEnvios
2. buscarPedidosPendientesAEnviar( )
14. cambiarEstadoAEnviado( ) 8. regi strarDatosDeEnvio(destino, fechaDeEntrega, observaciones)
12. regi strarEnvio( )
: Pedido
13. regi strarEnvio(Envi oDePedido)
: Gestor de pedidos
9. registrarEnvio(destino, fechaDeEntrega, observaciones, pedido)
3. buscarPedidosPendientesAEnviar( )
: Coleccion de Pedidos 15. actualizarPedido(Pedi do)
16. actualizar(envioDePedido)
: Gestor de Usuarios : Envio de pedido
: Colecci on de Envio de
pedido


Nombre del Use Case: Registrar pedido. Id: 36
Actor principal: Encargado de ventas.
Objetivo: registrar un nuevo pedido.
Precondiciones: Usuario logeado y con permisos para registrar pedido.
Poscondiciones:
Éxito:
• Pedido registrado.
Fracaso:
• Use Case cancelado por no existencia del cliente.
• Use Case cancelado por invalidez de los datos ingresados.
1. El UC Comienza, cuando encargado de ventas
2. El encargado de ventas selecciona la opción
Nuevo Pedido.
3. El sistema solicita que se busque el cliente.
4. El encargado de ventas busca el cliente que
realiza el pedido.
5. El encargado de pedidos encuentra al cliente y 5.1 El encargado de pedidos NO encuentra al
lo selecciona. cliente.
5.1.1 El sistema pregunta al encargado de
ventas si desea registrar al cliente y si desea.
5.1.1.1 Se extiende el Use Case “Registrar
Cliente”.
6. El sistema solicita que se ingresen la fecha
deseada de entrega del pedido, la prioridad y
observaciones.
7. El encargado de ventas ingresa los datos
solicitados.
8. El sistema solicita que seleccionen los
productos a incluir en el pedido.
9. El encargado busca y selecciona los productos
deseados y cantidad.
10. El sistema verifica la fecha de entrega y no es 10.1 El sistema verifica la fecha de entrega y
inmediata. es inmediata.
10.1.1 Se extiende el use case “Consultar
existencia de productos”.
11. El sistema consulta al usuario si la entregar
será en mostrador o mediante envio.
12. El encargado de ventas confirma la operación.
13. El sistema pregunta si desea consultar 13.1 El usuario desea consultar existencia a
existencia a futuro y no desea. futuro.
13.1.1 Se extiende el use case “Consultar
existencia de productos a futuro”
14. El sistema valida los datos y son correctos. 14.1 El sistema valida los datos y no son
correctos.
13.1.1 El sistema informa la invalidez de los
datos.
14. El sistema registra el pedido y coloca el estado
como “Pendiente de Armar”
Asociaciones de extensión: Consultar existencia de productos, Registrar Cliente, Consultar
existencia de productos a futuro.


Historia de cambios
1. buscarCliente(razonSocial, tipoDocumento, nroDocumento, descripcion) 4. seleccionarCliente(id)
7. crearPedido(fechaEntrega, prioridad, observaciones, tipoentrega)
18. registrarPedidoSel( ) : Interfaz de

: Encargado de Venta 10. buscarProductos(nombre) Pedidos
13. selecProducto(id, cantidad)
2. consultarCliente(razonSocial, tipoDocumento, nroDocumento, descripcion)
5. consultarCliente(id) 19. registrarPedidoSel( )
8. crearPedido(fechaE ntrega, prioridad, observaciones, tipentrega)
: Gestor de Productos
14. seleccionarProducto(id, cantidad)

16. buscarP roducto(id)

15. buscarProducto(id)
6. consultarCliente(id)
23. registrarPedido(Pedido)
: Gestor de pedidos
: Coleccion de Pedidos
17. calcularExistenciaActual(Producto)
: Coleccion de Clientes 22. estadoAPendienteArmar( )
: Coleccion de Productos
20. crearDetalle(producto[], cantidad[])
: E xistencia de productos
9. crearPedido(fechaE ntrega, prioridad, observaciones, tipoDeEntrega)
: P edido
Si la fecha no fuera la actual
9.1. getUsuarioLogueado( ) se calcula la estimacion de la
exsitencia a futuro con el
metodo correspondiente
21. agregarProducto(P roducto, cantidad)
: Detalle de pedido


Nombre del Use Case: Registrar recepción de remito. Id: 40
Objetivo: Registrar el armado de un pedido existente.
Precondiciones: Usuario logeado y con permisos para registrar la recepción del remito.
Poscondiciones:
Éxito:
• Entrega de remito registrada.
Fracaso:
• Use Case cancelado por no existencia del remito.
selecciona la opción Remitos.
Registrar recepción de remito.
3. El sistema solicita que se seleccione el remito
correspondiente.
4. El encargado de pedidos busca al remito
correspondiente.
5. El encargado de pedidos encuentra el remito y 5.1 El encargado de pedidos No encuentra el
lo selecciona. remito.
6. El sistema pregunta si se ha entregado 6.1 El sistema pregunta si se ha entregado
correctamente y si se ha entregado correctamente correctamente y NO se ha entregado
el remito. correctamente el remito.
6.1.1 El encargado de pedidos confirma la
operación.
6.1.2 El sistema valida los datos y son
correctos.
6.1.2.1 El sistema valida los datos y no son
correctos.
6.1.2.2 El sistema informa lo ocurrido.
6.1.3 El sistema actualiza al remito como
recibido.
6.1.4 Fin del Use Case.
8. El sistema valida los datos y son correctos. 8.1 El sistema valida los datos ingresados y
NO son correctos.
9. El sistema actualiza el envió de pedido
correspondiente al remito como recibido
(actualiza la fecha de recepción del envió de
pedido).
10. El sistema actualiza el estado del pedido como
Entregado.
Historia de cambios

1. buscarRemito(fecha de emisión, fecha de entrega, transportista, cli ente)

4. seleccionarRemito(id)
7. registrarEntrega(fecha)
:
: Encargado de Pedidos interfazDeEnvios
2. buscarRemitos(fecha de emisión, fecha de entrega, transportista, cliente)

5. seleccionarRemito(id)
: Coleccion de Remito : Gestor de Envios

12. actualizarRemito(remito)
6. obtenerRemito(id)
3. buscarRemtios(fecha de emisión, fecha de entrega, transportista, cliente)
13. actualizarRemito( )
10. actualizarEstadoAEntregado(fecha)
: Envio de pedido
: Remito
14. actualizarPedi do(Pedido)
11. actualizarFechaDeRecepcion(fecha)
: Pedido
15. actualizar( )
: Colecci on de Pedidos
16. actualizar(envioDePedido)
: Coleccion de Envio de
pedido


Nombre del Use Case: Consultar existencia de productos a futuro. Id: 44
Objetivo: Obtener una estimación de la existencia (disponibilidad) de los productos a futuro.
Precondiciones: Usuario logeado para consultar existencia de productos.
Poscondiciones:
Éxito:
• Existencia de productos consultados.
Fracaso:
1. El UC Comienza, cuando Encargado de venta
selecciona la opción Productos.
2. El Encargado de venta selecciona la opción
consultar existencia de productos a futuro.
(nombre, código, descripción, fecha de
estimación).
de búsqueda.
5. El sistema realiza la búsqueda y muestra los
productos y la correspondiente estimación de
existencia a futuro para cada uno de ellos.
Asociaciones de inclusión: No aplica
Historia de cambios

1. consultarDisponibil idad(nombre, precio, tipo, venci miento)
: Interfaz de
Productos
: Encargado de Venta
2. consultarDisponibilidad(nombre, precio, tipo, vencimiento)
3. calcularExistenciaAFuturo(producto)
: Existencia de productos : Gestor de Productos
5. consultar( )
: Producto : Colecci on de Productos


Nombre del Use Case: Anular remito. Id: 65
Objetivo: Anular un remito existente.
Precondiciones: Usuario logeado y con permisos para poder anular remito
Poscondiciones:
Éxito:
• Remito anulado.
Fracaso:
• Use Case cancelado por no existencia del remito.
pedidos selecciona la opción Remito.
emisión, fecha de entrega, transportista, cliente).
de búsqueda.
4. El sistema muestra el resultado de la búsqueda. 4.1 No se encuentran resultados de
búsqueda.
5. El encargado de pedido encuentra el remito a 5.1 El encargado de pedidos No encuentra el
anular y lo selecciona. remito a anular.
6. El sistema muestra el remito y su detalle.
Anular Remito.
9. El sistema anula el Remito seleccionado.
Historia de cambios


Nombre del Use Case: Consultar Pedido. Id: 130
Actor principal: Encargado de Pedido.
Objetivo: Consulta pedido existente
Precondiciones: Usuario logeado y con permisos para poder consultar pedido
Poscondiciones:
Éxito:
• Pedido consultados.
Fracaso:

1. El Use Case Comienza, cuando Encargado de
pedido selecciona la opción Pedido.
(cliente, estado, fecha de entrega, fecha de
emisión, prioridad).
3. El encargado de pedido ingresa los parámetros
de búsqueda.
4. El sistema realiza la búsqueda y muestra los 4.1 No se encuentran resultados de
pedidos correspondientes. búsqueda.
5. El encargado de pedidos encuentra el pedido 5.1 el encargado de pedido no encuentra el
que desea consultar y lo selecciona pedido.
6. El encargado de pedido selecciona al opción ver
detalle de pedido.
7. El sistema muestra el detalle del pedido
seleccionado
Asociaciones de inclusión: No aplica
Historia de cambios

1. buscarPedidos(fecha de emisión, fecha de entrega, priori dad, cl iente)
: Interfaz de
2. buscarPedidos(fecha de emisión, fecha de entrega, priori dad, cliente)
3. buscarPedido(fecha de emisi ón, fecha de entrega, pri oridad, cli ente)

: Colecci on de Pedidos : Gestor de pedidos
4. consultarPedi do( )
: Pedido


Nombre del Use Case: Registrar transportista. Id: 131
Objetivo: Registrar un nuevo transportista.
Precondiciones: Usuario logeado y con permisos para registrar transportista
Poscondiciones:
Éxito:
• Transportista registrado.
Fracaso:
• Use Case cancelado porque los datos del transportista no son correctos.
pedidos selecciona la opción Transportista.
nuevo transportista.
transportista (razón social, CUIT, dirección,
teléfono, condición de IVA, e-mail).
3. El encargado de pedidos ingresa los datos del
nuevo transportista.
4. El sistema realiza la búsqueda y obtiene 4.1 No se encuentran resultados de la
resultados. búsqueda.
5. El encargado de pedido confirma la operación.
7. El sistema registra al nuevo transportista.
Historia de cambios


Nombre del Use Case: Modificar Transportista. Id: 132
Objetivo: Modificar los datos de un transportista existente.
Precondiciones: Usuario logeado y con permisos para poder modificar a transportista.
Poscondiciones:
Éxito:
• Transportista actualizado.
Fracaso:
• Use Case cancelado por no existir transportista a modificar.
• Use case cancelado por invalidez de los datos.
producción selecciona la opción Transportista.
5. El encargado de producción busca al 5.1 El encargado de producción NO encuentra
transportista, lo encuentra y lo selecciona. el transportista a modificar.
la opción “Modificar Transportista”.
7. El encargado de producción modifica los datos
del transportista (razón social, CUIT, dirección,
teléfono, condición de IVA, e-mail).
7. El encargado de producción confirma la
operación.
9. El sistema actualiza los datos del transportista.
Historia de cambios


Nombre del Use Case: Dar de baja a transportista. Id: 133
Actor principal: Encargado de pedido.
Objetivo: Dar de baja a un cliente.
Precondiciones: Usuario logeado y con permisos para dar de baja al transportista.
Poscondiciones:
Éxito:
• transportista dado de baja.
Fracaso:
• Use Case cancelado por no existir el transportista a dar de baja.
pedido selecciona la opción Transportistas.
5. El encargado de producción busca al 5.1 El encargado de producción NO encuentra
transportista, lo encuentra y lo selecciona. el transportista a dar de baja.
la opción “Dar de baja Transportista”.
7. El encargado de pedido confirma la operación.
8. El sistema da de baja al transportista.
Historia de cambios

Pedido: Diagrama de Clases
Pegar aquí diagrama de clases detalle de pedido

<<control>>
Gestor de Transportistas
coleccionDeTrans portis tas : Colecc ion de Transportistas
trans portistaSelecc ionado : Transportista
regis trarTrans portista(razón s ocial, CUIT, direc ción, teléfono, condición de IVA, e-mail)
busc arTrans portis ta(raz ón social, CUIT)
seleccionarTransportista(id)
darDeBajaTrans portis taSelec()
modificarTransportista(razón social, CUIT, direcc ión, teléfono, condic ión de IVA, e-mail)
obtenerTodos()
<<entity >>
Colec cion de Transportistas
transportistas[] : Transportis tas
registrar(Transportis ta)
buscarTrans portista(raz ón s ocial, CUIT)
obtenerTransportis ta(id)
darDeBajaTrans portista(Transportista : Transportista) ...
ac tualiz arTrans portis ta(Transportista : Transportista)
obtenerTodos()
<<Interface>>
Interfaz de Transportista
gestorDeTransportis tas : Gestor de Transportis tas
registrarTrans portista(raz ón social, CUIT, direc c ión, teléfono, c ondición de IVA, e-mail)
buscarTransportistas(raz ón social, CUIT)
s elecc ionarTrans portista(id)
darDeBajaTransportistaSelec()
modific arTrans portis ta(razón social, CUIT, dirección, teléfono, condición de IVA, e-mail)
1..*
<<entity >>
Transportista
raz on social
c uit
direccion
telefono
c ondic ion de iv a
mail
id
registrar(raz ón soc ial, CUIT, direc ción, teléfono, condición de IVA, e-mail)
modific ar(razón social, CUIT, dirección, teléfono, condición de IVA, e-mail)
c onsultar()
darDeBaja()

Colec cion de Env io de pedido Envio de pedido

destino
actualiz ar(envioDePedido : Envio de pedido) fec haDeEnv io
busc arEnvioDePedidoSinRemito( ) fec haDeRec epcion
obtenerEnv ioDePedido( id) remito : R emito
oper arior : UsuarioSis
observac iones
id
pedido
registrarEnv io(des tino, fec haDeEntr ega, observaciones, pedido : Pedido)

emitirRemito()
modific arEnv io()
obtenerPedido() : Pedido
ac tualiz arFechaDeRec epcion(fecha)
Remito
tr ansportis ta : Transportita
Ges tor de Env ios pedido : Pedido
c olecionDeEnv ioDePedido : Colecc ion de Env io de pedido obser vaciones
gestorDePedidos : Ges tor de pedidos id
gestorDeTrans portis tas : Gestor de Trans portis tas n
trans porTis taSelec cionado registrarRemito(fecha, pedido : Pedido, observ aciones : String)
envioDePedidoSelec cionado : Envio de Pedido emitirRemito()
remito : R emito anularRemito()
pedido : Pedido c onsultar(fec ha de emisión, fecha de entrega, trans portis ta, c liente)
registrarEntrega(fecha)
busc arEnv ioDePedidos SinRemitos () actualiz arRemito()
s elecc ionarEnv ioDePedido(id)
obtenerTransportistas()
s elecc ionarTrans portis ta(id)
regis trarRemito(fecha, observac iones)
emitirComprobanteRemito()
busc arR emitos (fecha de emisión, fecha de entrega, trans portis ta, c liente)
s elecc ionarRemito(id)
anularRemito()
regis trarEntrega(fecha)
Colec cion de R emito

r emito[] : Remito
r egistrarRemito(remito : Remito) : Boolean

buscarR emtios (fec ha de emisión, fec ha de entrega, trans portis ta, c liente)
obtenerRemito(id)
ac tualiz arRemito( remito : Remito)
interfazD eEnv ios

gestor DePedidos : Ges tor de Pedidos
gestor DeEnv ios
busc arPedidos PendientesDeEnv io()

s elecc ionarPedido(id)
regis tr arDatosEnvio(destino, fec haDeEntrega, obs ervac iones )
c onfirmarRegis troDeEnvio()
busc arEnv ioDePedios SinRemitos()
s elecc ionarEnv ioDePedido(id)
s elecc ionarTrans portis ta(id)
regis tr arRemito(fec ha, observac iones)
busc arRemito(fec ha de emis ión, fec ha de entrega, tr ansportista, cliente)
s elecc ionarRemito(id)
anular Remito()
regis tr arEntrega(fecha)

Diagrama de Transición de Estados: Clase Pedido
Regi strar Pedido
Si el pedi do no esta
marcado para entrega en
Pendiente de Armar mostrador
Registrar Armado de Pedidos
Pendiente de
enviar
Registrar Armado de Pedidos
Regi strar Envio de Pedido
Si el pedido se
entrega en
mostrador
Envi ado
Regi strar Recepcion de Remitos
Entregado

Análisis del Paquete: Reclamos
Reclamos
72- Registrar reclamo por autogestión
39- Emitir resol ucion de reclamo 43- Emitir informe de incovenientes y

reclamos
Cliente
70- Dar de baja al Reclamo
37- Modificar Resoluci ón de Reclamo
71- Modificar Reclamo

38- Registrar Resolucion de reclamo
Encargado de
Atencion al Cliente
136- Consultar resoluci ón de reclamos
<<extend>> Encargado de
126- Consultar operarios a cargo de
Pedidos
lotes de produccion
73- Registrar Reclamo

(f rom Cliente)

Reclamos: Descripciones y diagramas de colaboración de

análisis.

Nombre del Use Case: Consultar resolución de reclamos. Id: 136
Objetivo: Consultar las resolución aplicadas a un reclamo.
Precondiciones: Usuario logeado y con permisos para consultar resolución de reclamos.
Poscondiciones:
Éxito:
• Resolución de reclamo consultada.
Fracaso:
• Use Case cancelado por no obtener resultado de la búsqueda.
• Use Case cancelado por no existir el reclamo.
• Use Case cancelado por no existir la resolución asociadas al reclamo.
1. El Use Case Comienza cuando encargado de
atención al cliente selecciona la opción Reclamos.
del reclamo (cliente, fecha y hora de reclamo,
descripción).
4. El sistema realiza la búsqueda y muestra el 4.1 El sistema no obtiene resultado de la
resultado. búsqueda.
5. El encargado de atención al cliente busca y 5.1 El encargado de atención al cliente no
selecciona al reclamo. encuentra al reclamo.
la opción ver Resoluciones.
7. El sistema verifica si el reclamo posee 7.1 El sistema verifica si el reclamo posee
resoluciones asociadas y si posee. resoluciones asociadas y no posee.
7.1.2 Se cancela el use case.
8. El sistema muestra las resoluciones aplicadas al
reclamo.
Historia de cambios


Nombre del Use Case: Modificar resolución de reclamos. Id: 37
Objetivo: Modificar la resolución realizada a un reclamo.
Precondiciones: Usuario logeado y con permisos para modificar resolución de reclamos.
Poscondiciones:
Éxito:
• Resolución de reclamo actualizada.
Fracaso:
• Use Case cancelado por no existir la resolución a modificar.
• Use Case cancelado por no datos inválidos.
• Use case cancelado por no existir resoluciones asociadas al reclamo.
descripción).
7. El sistema verifica si el reclamo posee 7.1 El sistema verifica si el reclamo posee
resoluciones aplicadas y posee. resoluciones aplicadas y no posee.
reclamo.
9. El sistema solicita que se seleccione la
resolución del reclamo a modificar.
10. El encargado de atención al cliente busca la 10.1 El encargado de atención al cliente no
resolución a modificar y la selecciona. encuentra la resolución a modificar.
11. El sistema solicita que se ingrese la nueva
medida tomada en la resolución del reclamo.
11. El encargado de atención al cliente ingresa la
nueva medida tomada en la resolución.
12. El encargado de atención al cliente confirma
la operación.
13. El sistema valida los datos de la resolución y 13.1 El sistema valida los datos de la
son validos. resolución y no son validos.
14. El sistema actualiza la resolución del reclamo.


Historia de cambios


Nombre del Use Case: Registrar resolución de reclamos. Id: 38
Objetivo: Registrar la revoluciona aplicada a un reclamo.
Precondiciones: Usuario logeado y con permisos para registrar resolución de reclamos.
Poscondiciones:
Éxito:
• Resolución de reclamo registrada.
Fracaso:
descripción).
reclamo si es que hay.
8. El sistema solicita que se ingrese la medida
tomada.
medida tomada en la resolución.
la operación.
11. El sistema valida los datos de la resolución y 11.1 El sistema valida los datos de la
son validos. resolución y no son validos.
12. El sistema actualiza la resolución del reclamo.
Historia de cambios


Nombre del Use Case: Modificar resolución de reclamos. Id: 39
Objetivo: Emitir resolución de reclamo
Poscondiciones:
Éxito:
Fracaso:
la opción Emitir resolución de reclamos.
(cliente, fecha y hora del reclamo)
4. El sistema realiza la búsqueda de los reclamos 4.1 El sistema no obtiene resultado de la
cuyo estado sea solucionado y muestra el búsqueda.
resultado. 4.1.1 Se cancela el Use Case.
la opción enviar mail al cliente para informar la
resolución.
6. Para cada reclamo, el sistema verifica que el 6.1 Para cada reclamo el sistema verifica que
cliente asociado al mismo tenga e-mail y tiene. el cliente asociado al mismo tanga e-mail y
no tiene.
6.1.1 El sistema no envía el mail al cliente.
6.1.2 El sistema informa al encargado de
atención al cliente que no se pudo enviar el
e-mail.
6.1.2 Fin del use case.
7. El sistema envía en e-mail al cliente.
Historia de cambios


Nombre del Use Case: Emitir informe de inconvenientes y reclamos. Id: 43
Objetivo: Emitir un informe estadístico de los inconvenientes ocurridos indicando los mas
frecuentes.
Precondiciones: Usuario logeado y con permisos para consultar resolución de reclamos.
Poscondiciones:
Éxito:
• Informe de inconvenientes y reclamos generado y emitido.
Fracaso:
la opción Emitir Informe de inconvenientes y
reclamos.
2. El sistema solicita los parámetros del informe
(cliente, fecha y hora de reclamo, descripción,
estado).
4. El sistema realiza la búsqueda y obtiene un 4.1 El sistema no obtiene resultado de la
5. El sistema muestra el resultado de la búsqueda
(cliente que realiza el reclamo, descripción del
reclamo, resolución tomada, estado del reclamo)
e indica cuales son las causas mas frecuentes de
los reclamos.
Historia de cambios


Nombre del Use Case: Dar de baja a reclamo. Id: 70
Actor principal: Encargado de atención a cliente.
Objetivo: Dar de baja a reclamo de cliente.
Precondiciones: Usuario logeado y con permisos para dar de baja a reclamo
Poscondiciones:
Éxito:
• Reclamo dado de baja.
Fracaso:
• Use Case cancelado por no encontrar el reclamo.
pedido selecciona la opción Reclamos.
del reclamo( fecha, cliente, estado , descripción)
5. el encargado de atención al cliente selecciona 5.1 El encargado atención al cliente No
la opción dar de baja. encuentra el reclamo a dar de baja.
operación.
7. El sistema da de baja al reclamo.
Historia de cambios


Nombre del Use Case: Modificar reclamo. Id: 71
Objetivo: Modificar los datos de un reclamo
Precondiciones: Usuario logeado y con permisos para poder modificar datos del reclamo.
Poscondiciones:
Éxito:
• Reclamo modificado.
Fracaso:
• Use Case cancelado por no existir reclamo a modificar.
• Use Case cancelado por encontrar el reclamo.
1. El Use Case comienza, cuando encargado de
atención al cliente selecciona la opción reclamos.
2. El sistema solicita lo parámetros de búsqueda
del reclamo( fecha, cliente, estado , descripción)
la opción modificar reclamo.
datos del reclamo, cliente descripción, estado ,
detalle del reclamo
operación.
9. El sistema actualiza los datos del reclamo.
Historia de cambios


Nombre del Use Case: Registrar reclamo por autogestión. Id: 72
Actor principal: Cliente.
Objetivo: Registrar un reclamo a través de la autogestión.
Precondiciones: No aplica.
Poscondiciones:
Éxito:
• Reclamo registrado.
Fracaso:
• Use Case cancelado por usuario incorrecto.
• Use case cancelado porque el cliente cancela la operación.
• Use case cancelado por datos inválidos.
1. El UC Comienza, cuando el cliente selecciona la
opción Autogestión de Reclamos.
2. El sistema solicita que se ingrese el nombre de
usuario y contraseña.
3. El cliente ingresa el nombre de usuario y
contraseña.
4. El sistema valida el nombre de usuario y 4.1 El sistema valida el nombre de usuario y
contraseña y son válidos. contraseña y No son válidos.
5. El cliente selecciona la opción Nuevo Reclamo.
6. El sistema solicita que se ingrese el motivo del
reclamo.
7. El cliente ingresa el motivo del reclamo.
8. El cliente confirma la operación. 8.1 El cliente cancela la operación.
9. El sistema valida los datos ingresados y son 9.1 El sistema valida los datos ingresados y no
correctos. son correctos.
10. El sistema registra el reclamo.
Historia de cambios


Nombre del Use Case: Registrar reclamo. Id: 73
Actor principal: Encargado de atención al cliente, encargado de pedido.
Objetivo: Registrar un reclamo
Precondiciones: Usuario logeado y con permisos para registrar resolución de reclamos.
Poscondiciones:
Éxito:
• Resolución de reclamo registrada.
Fracaso:
• Use Case cancelado por no existir el cliente
• Use Case cancelado por el usuario.
1. El Use Case Comienza cuando el
usuario(encargado de atención al cliente o
encargado de pedidos) selecciona la opción
Reclamos.
2. El usuario selecciona la opción nuevo reclamo.
3. El sistema solicita que se ingrese los datos del
usuario
4. El sistema verifica que el cliente exista, si el 4.1 Se cancela el Use case por no existir el
cliente existe cliente.
5. El sistema solicita que se ingrese el nuevo
reclamo.
6. El usuario ingresa del nuevo reclamo los datos
(cliente, fecha y hora de reclamo, descripción,
detalle, identificador).
7. El usuario confirma la operación. 7.1 El usuario cancela la operación.
correctos. son correctos.
9. El sistema registra el reclamo.
Historia de cambios


Nombre del Use Case: Consultar operarios a cargo de lotes de producción. Id: 126
Objetivo: Consultar los operarios que estaban a cargo de un determinado lote de producción.
Poscondiciones:
Éxito:
Fracaso:
• Use Case cancelado por no existir la resolución a modificar.
• Use case cancelado por no existir resoluciones asociadas al reclamo.
atención al cliente selecciona la opción Consultar
operarios a cargo de lotes de producción.
2. El sistema solicita el número de lote de
faenamiento correspondiente al producto.
3. El encargado de atención al cliente ingresa el
número de lote de faenamiento correspondiente
al producto.
4. El sistema verifica que el número de lote de 4.1 El sistema verifica que el número de lote
faenamiento ingresado sea correcto y si es de faenamiento ingresado sea correcto y no
correcto. es correcto.
5. El sistema busca en los resultados de los planes 5.1 El sistema no obtiene resultado de la
de faenamiento y envasado los operarios que búsqueda.
generaron el lote de faenamiento ingresado y 5.1.1 Se cancela el Use Case.
obtiene el resultado.
6. El sistema muestra los datos del operario que
dio origen al lote de faenamiento y los datos del
plan de faenamiento y envasado correspondiente
(estanque faenado, fecha de inicio, fecha de fin,
descripción).
Historia de cambios

Reclamos: Diagrama de Clases
Pegar aquí: diagrama de clases reclamos

Diagrama de Transición de estados: Reclamo
Regi strar Reclamo o Registrar Reclamo por Autogestion
Registrar Resolucion de Reclamo
Pendiente
Registrar Resoluci on de Reclamo
No
solucionado
Registrar Resol ucion de Reclamo Emitir resol ucion de reclamo
Emitir resolucion de reclamo (sin informe al cliente)
Solucionado Emitir resolución de reclamo

Informado al
Cliente
Emitir resol ucion de reclamo (sin informe al cliente)
Sin informar
al cliente

Análisis del Paquete: Ventas
Ventas
77- Autoconsulta de cuenta corriente

Cliente
158- Registrar Credito al Cliente
75- Consultar Cobros y deudores
74- Anular Cobro
Encargado de
Cobros
125- Consultar Ventas

78- Emitir Resumenes de Cuenta
127- Inhabilitar cuenta corriente.

13- Registrar Venta
126- Dar de Alta a Cuenta Corriente 12- Registrar Cobro
Encargado de
Atencion al Cliente
76- Consultar Cuentas Corrientes
Administrador
(f rom Actores del Sistema
...)de Inf ormación)
155- Registrar Forma de Pago
157- Consultar Forma de Pago

156- Dar de Baja Forma de Pago

Ventas: Descripciones y diagramas de colaboración de análisis.

Nombre del Use Case: Registrar crédito al cliente. Id: 158
Actor principal: Encargado de cobros.
Objetivo: registrar crédito al cliente.
Precondiciones: Usuario logueado y con permisos para registrar crédito al cliente.
Poscondiciones:
Éxito:
• Crédito al cliente registrado.
Fracaso:
• Use case cancelado por no existir el cliente.
1. El Use Case Comienza cuando el Encargado de
cobros selecciona la opción Registrar Crédito
Cliente.
2. El Encargado de cobros selecciona la opción
Nuevo crédito.
3. El sistema solicita que se ingrese al cliente
deseado.
4. El Encargado de cobros busca al cliente 4.1 El Encargado de cobros busca al cliente
deseado, lo encuentra y lo selecciona. deseado y no lo encuentra.
5. El sistema solicita que se ingrese el monto a
acreditar al cliente.
6. El Encargado de cobros ingresa el monto a
acreditar al cliente.
7. El Encargado de cobros ingresa una observación
indicando porque se realiza el crédito al cliente.
8. El Encargado de cobros confirma la operación.
9. El sistema registra el crédito al cliente.
Historia de cambios

1. consultarCli ente(razonSocial , tipoDocumento, nroDocumento, descripcion)

5. seleccionarCliente(id)
9. regi strarCredio(monto, observaci ones, fecha)
: Interfaz de Ventas
: Encargado de Cobros
10. regi strarCredito(monto, fecha, observaciones)

2. consultarCli ente(razonSocial, tipoDocumento, nroDocumento, descripcion)
12. regi strar(m onto, fecha, cliente, observaciones, usuario)
11. getUsuari oLogueado( )

: Gestor de Usuarios : Gestor de Ventas : Credito
3. consultarCli ente(razonSoci al , tipoDocumento, nroDocum ento, descripcion)

7. consultarCli ente(id)
13. agregar(credito)
: Gestor de Cl ientes
: Coleccion de Credi to
8. consultarCli ente(id)
4. consultarCliente(razonSoci al , tipoDocumento, nroDocumento, descripcion)


Nombre del Use Case: Registrar Cobro. Id: 12
Objetivo: Registrar un nuevo cobro.
Precondiciones: Usuario, logueado y con permisos para realizar cobro.
Poscondiciones:
Éxito:
• Cobro registrado.
Fracaso:
• Caso de Uso Cancelado por falta de comprobantes para pagar.
al cliente selecciona la opción Cobros.
2. El sistema solicita el nombre del cliente y busca 2.1 No tiene comprobantes pendientes a
los comprobantes pendientes a pagar y este tiene pagar.
comprobantes. 2.1.1 Se cancela el Use Case.
los comprobantes a cancelar, el monto a cancelar
y el descuento si se aplicara.
4. El sistema calcula y muestra el monto total a
cobrar.
7. El sistema informa las formas de pago actuales
y el usuario selecciona la que desea.
operación.
9. El sistema registra el cobro y actualiza el saldo
de las ventas. Y las cuentas corrientes.
10. El sistema emite un comprobante de pago a
nombre del cliente.
Use Case al que se extiende: “Registrar Pesca”, “Registrar Visita”.
Historia de cambios
1.1 31/07/2005 Modificación por copy and paste Rochoa

1. bus c arComprAPagar( nombre)
4. s elec CompAPag(idComp, montoAPag, des c )

: Interfaz de Cobr os
11. s elec FormaDePago( id)
: Enc argado de Cobros
14. regis trarCobr o( )
2. busc arComAPagar(nombre)
12. s elec FormaPag(id)
9. c ons ultar Formas DePago( ) 23. emitir ComprobanteCobroSelec ( )

5. s elec C ompAPag(idComp, montoAPag, des c )
16. getUs uar ioLogueado( ) 15. regis trarC obroSelec ( )
6. bus c arVenta( id)
: Ges tor de Us uarios
10. cons ultar ( )

: Ges tor de Ventas
: Gestor de Cobros
13. obtener(Id)
3. busc arVentas D eudoras (nombre)
7. bus c arVenta( id)
17. c rearCobr o(fec ha, us uario, v enta, monto, pago, des c uento, formaPago)
: C olec c ion de For mas de
Pago
: Colec c ion de Ventas
: Colec c ion de Cobr os
8. c ons ultar Venta( )

18. regis trarCobr o(fec ha, us uario, v enta, monto, pago, des c uento, formaPago)
19. pagar( monto, des c uento, c obro)
: Detalle de c uenta c orriente
: Venta
22. c rear(c obr o, v enta, tipomov ) : Venta
: Cobro
20. ac tualiz arCuenta(cobro, v enta, tipomov )
24. ac tualiz ar( Cuenta)

: Cuenta Corriente
21. ac tualiz arCuenta( c obro, v enta, tipomov )
: Cliente
: C olec c ion de C uenta

C orriente


Nombre del Use Case: Registrar Venta. Id: 13
Objetivo: Registrar una venta.
Precondiciones: Usuario logueado y con permisos para registrar venta.
Poscondiciones:
Éxito:
• Venta registrada.
Fracaso:
• Use Case cancelado por no existir el cliente
1. El UC Comienza, cuando encargado de cobros
selecciona la opción Ventas.
2. El encargado de cobros selecciona la opción
“Nueva Venta”.
3. El sistema solicita que se ingrese el cliente.
4. El encargado de cobros busca y encuentra al 4.1 El encargado de cobros busca y No
cliente y lo selecciona. encuentra al cliente.
la venta (fecha, vendedor, observación).
6. El encargado de cobros ingresa los datos
solicitados.
7. El sistema solicita que se ingresen los ítems
(servicios, productos, pedidos) a incluir en la
venta y sus respectivas cantidades.
8. El encargado de cobros ingresa los ítems a
incluir en la venta y sus respectivas cantidades.
9. El sistema pregunta si se desea realizar un 9.1 Si se desea realizar un descuento.
descuento, y no se desea realizar un descuento. 9.1.1 El encargado de atención al cliente
ingresa el descuento a realizar en el cobro.
cobrar.
11. El sistema solicita que se ingrese la forma de
pago.
forma de pago.
la operación.
14. El sistema registra la venta.
Historia de cambios
Este caso de uso tiene 3 realizaciones distintas según se trate de adquir un producto, servicio o
facturar un pedido.

Registrar venta de pedido

10. buscarPedidos(fecha de emisión, fecha de entrega, prioridad)
22. cargarDescuento(pesos)
28. seleccionarFormaDePago(id) : Interfaz de Ventas
: Encargado de 33. registrarVenta( )
Atencion al Cliente
27. consultar( )
31. obtenerFormaDePago(Id) : Gestor de Cobros
: Coleccion de Formas de
Pago 26. consultarFormasDePago( )
30. selecFormaPag(id)
34. registrarVentaSeleccionada( )
29. seleccionarFormaDePago(id)
25. buscarFormasDePago( )
23. cargarDescuento(monto)
: Venta 20. calcularTotal( )
9. asginarCliente(cliente) 15. seleccionarPedido(id)
32. asignarFormaDePago(formaDePago) 11. buscarPedidos(fecha de emisión, fecha de entrega, prioridad)
24. cargarDescuento(pesos) 6. seleccionarCliente(id)
21. calcularTotal( ) 2. consultarCliente(razonSocial, tipoDocumento, nroDocumento, descripcion)
18. asignarPedido(Pedido)
: Gestor de Ventas

35. registrarVenta(venta)
12. buscarPedidos(fecha de emisión, fecha de entrega, prioridad, cliente)

: Coleccion de Ventas

: Coleccion de Pedidos
13. buscarPedido(fecha de emisión, fecha de entrega, prioridad, cliente)

: Gestor de pedidos

Registrar venta de producto

14. agregarProducto(id, cantidad)
24. cargarDescuento(pesos) : Interfaz de Ventas
: Encargado de 29. registrarVenta( )
Atencion al Cliente

: Detalle de venta
17. agregarProducto(producto, cantidad) 15. agregarProducto(id, cantidad)
27. calcularTotal( )
: Venta
19. consultarFormasDePago( )
: Gestor de Ventas
23. asignarFormaDePago(formaDePago)
16. agregarDetalle(Producto, cantidad) 3. consultarCliente(razonSocial, tipoDocumento, nroDocumento, descripcion)
9. asginarCliente(cliente) 7. consultarCliente(id)
: Gestor de Cobros
: Gestor de Productos
: Gestor de Clientes 20. consultar( )
: Coleccion de Productos
: Coleccion de Formas de
Pago

Registrar venta de servicio

16. consultarTarifa(concepto)
20. seleccionarTarifa(id)
31. registrarVenta( )
: Encargado de
Atencion al Cliente
: Interfaz de Ventas
25. agregarTarifa(tarifa) : Detalle de venta 2. consultarCliente(razonSocial, tipoDocumento, nroDocumento, descripcion)

21. agregarTarifa(id)
: Venta
9. asginarCliente(cliente) 12. consultar( )
15. asignarFormaDePago(formaDePago)
24. agregarTarifa(tarifa)
11. consultarFormasDePago( ) : Coleccion de Formas de
: Gestor de Ventas Pago
: Gestor de Cobros
22. buscarTarifa(id)

: Gestor de Tarifas : Gestor de Clientes
19. consultarTarifa(concepto) 4. consultarCliente(razonSocial, tipoDocumento, nroDocumento, descripcion)

23. obtenerTarifa(id) 8. consultarCliente(id)
: Coleccion De Tarifas


Nombre del Use Case: Anular Cobro. Id: 74
Objetivo: Anular un cobro existente.
Precondiciones: Usuario logeado y con permisos para anular el cobro.
Poscondiciones:
Éxito:
• Cobro registrado.
Fracaso:
• Use case cancelado por no obtener resultado de la búsqueda.
• Use case cancelado por no existir el cobro a anular.
selecciona la opción Cobros.
de los cobros (nombreCliente, fecha).
3. El encargado de cobros ingresa los parámetros
de búsqueda.
5. El encargado de cobros encuentra y selecciona 5.1 El encargado de atención al cliente NO
al cobro a anular. encuentra al cobro a anular.
la opción “Anular Cobro”.
7. El encargado de cobros confirma la operación.
8. El sistema actualiza el cobro como anulado.
9. El sistema actualiza la cuenta corriente del
cliente.
Historia de cambios

1. buscarCobro(nombreCliente, fecha)
4. anularCobro(nombreCliente, fecha)
: Interfaz de Cobros
2. buscarCobro(nombreCliente, fecha)
5. selecci onarCobro(i d)
: Colecci on de Cobros : Gestor de Cobros

11. anularCobro(cobro)
10. opnam e
6. obtenerCobro(i d)
8. anularCobro(usuario)
3. buscarCobro(nombreCli ente, fecha)
9. anularCobro(cobro)
: Venta : Cobro : Gestor de Usuarios


Nombre del Use Case: Consultar cobros y deudores. Id: 75
Objetivo: Informar sobre los deudores existentes y cobros pendientes.
Precondiciones: Usuario logeado y con permisos para consultar cobros y deudores.
Poscondiciones:
Éxito:
• Cobros y deudores consultados.
Fracaso:
selecciona la opción Cuenta Corriente.
Consultar cobros y deudores.
parámetros de búsqueda (cliente, fecha de cobro,
cobrador).
de búsqueda.
5. El sistema realiza la búsqueda y muestra los 5.1 El sistema no obtiene resultados de la
clientes deudores y los cobros relacionados. búsqueda.
Historia de cambios
1. consultarCobros(cliente, fecha de cobro, cobrador)
: Interfaz de Cobros

: Coleccion de Cobros : Gestor de Cobros


Nombre del Use Case: Consultar cuenta corriente. Id: 76
Objetivo: consultar la cuenta corriente de un cliente.
Precondiciones: Usuario logeado y con permisos para poder consultar cuenta corriente.
Poscondiciones:
Éxito:
• Cuenta corriente de cliente consultada.
Fracaso:
• Use case cancelado por no encontrarse al cliente.
• Use cace cancelado porque el cliente no tiene cuenta corriente habilitada.
al cliente selecciona la opción Cuenta Corriente.
Consultar.
3. El sistema solicita que se seleccione el cliente.
4. El encargado de atención al cliente busca y 4.1 El encargado de atención al cliente busca
encuentra al cliente. y No encuentra al cliente.
5. El sistema verifica que el cliente tenga una 5.1 El sistema verifica que el cliente tenga
cuenta de corriente habilitada y la tiene. una cuenta corriente habilitada y no la tiene.
5. El sistema muestra los datos de la cuenta
corriente del cliente (fecha de alta, limite de
crédito, plazo de crédito, saldo total) y el detalle
de la misma (ventas y cobros realizados).
Historia de cambios


: Interfaz de Cuentas
Corrientes
: Encargado de
Atencion al Cliente

6. seleccionarClienteYConsultarCuenta...
9. consultarCuenta(cliente)
: Gestor de Cuentas Corrientes
: Coleccion de Cuenta
Corriente
13. consultarCreditos(cliente)
10. emitirResumen( )
4. consultarCliente(razonSocial, tipoDocumento, nroDocumento, descripcion) : Coleccion de Credito

: Cuenta Corriente
11. consultarCobros( )
12. consultarVenta( )
: Detalle de cuenta corriente


Nombre del Use Case: Auto consulta de cuenta corriente. Id: 77
Actor principal: Cliente.
Objetivo: No aplica.
Precondiciones: no aplica.
Poscondiciones:
Éxito:
• Cuenta corriente consultada.
Fracaso:
• Use case cancelado por invalidez del nombre de usuario y contraseña.
• Use case cancelado porque el cliente no posee una cuenta corriente habilitada.
1. El UC Comienza, cuando el cliente selecciona la
opción Auto consulta de Cuenta Corriente.
3. El cliente ingresa el nombre de usuario y
contraseña.
4. El sistema valida el nombre de usuario y 4.1 El sistema valida el nombre de usuario y
contraseña y son válidos. contraseña y No son válidos.
5. El sistema verifica que el usuario tenga una 5.1 El sistema verifica que el usuario tenga
cuenta corriente habilitada y la tiene. una cuenta corriente habilitada y NO la
tiene.
6. El cliente selecciona la opción Consultar.
7. El sistema muestra los datos de la cuenta
corriente del cliente (fecha de alta, limite de
crédito, plazo de crédito, saldo total) y el detalle
de la misma (ventas y cobros realizados).
Historia de cambios

1. iniciarSesion(nombreDeUsuario, Pass)
5. consultarCuentaCorriente( )
: Interfaz de
: Cliente Autoconsulta...
2. iniciarSesionClienteAutogestion(nombre, pass)
6. consultarCuentaCorrienteAutogestion( )
3. buscarClientePorUsuarioAutogestion(usuario)
: Coleccion de Clientes : Gestor de Clientes
4. iniciarSesion(usuario, pass)
8. seleccionarClienteYConsultarCuenta(id)
7. obtenerCliente( )
: Cliente de autogestion Corriente
15. consultarCreditos(cliente)
: Coleccion de Credito
10. consultarCliente(id) : Cuenta Corriente


Nombre del Use Case: Emitir resúmenes de cuenta corriente. Id: 78
Objetivo: Informar sobre los estados de cuenta de los clientes.
Precondiciones: Usuario logeado y con permiso para emitir resúmenes de cuenta corriente.
Poscondiciones:
Éxito:
• Resúmenes de cuenta corriente generada.
Fracaso:
Emitir Resúmenes de cuenta corriente.
parámetros de búsqueda (clientes, fechas de
ventas, fechas de cobros).
de búsqueda.
5. El sistema consulta las cuentas corrientes de los
clientes.
6. El sistema emite los resúmenes de cuenta de
los clientes mostrando para cada cliente sus datos
personales, el saldo total de la cuenta corriente y
los cobros y ventas incluidos en la cuenta
corriente.
Historia de cambios


Corrientes
: Encargado de
Atencion al Cliente
4. seleccionarClienteYConsultarCuenta(id)
: Coleccion de Credito 13. consultarCreditos(cliente)

Corriente

: Cuenta Corriente


Nombre del Use Case: Consultar Ventas. Id: 125
Objetivo: Consultar los datos de una venta.
Precondiciones: Usuario logeado y con permisos para poder consultar ventas.
Poscondiciones:
Éxito:
• Ventas consultadas.
Fracaso:
• Use case cancelado por no existir la venta a consultar.
selecciona la opción Ventas.
Consultar Ventas.
parámetros de búsqueda (cliente, fecha,
vendedor).
de búsqueda.
5. El sistema realiza la búsqueda y muestra el 5.1 El sistema no obtiene resultados de la
6. El encargado de cobros encuentra la venta a 6.1 El encargado de cobros no encuentra la
consultar y la selecciona. venta a consultar.
7. El encargado de cobros selecciona la opción Ver
detalle.
8. El sistema muestra el detalle de la venta
seleccionada (productos, tarifas, cantidades y
subtotales correspondientes).
Historia de cambios


Nombre del Use Case: Dar de alta a Cuenta Corriente. Id: 126
Objetivo: Dar de alta a la cuenta corriente de un cliente.
Precondiciones: Usuario logeado y con permisos para dar de alta a cuenta corriente.
Poscondiciones:
Éxito:
• Cuenta Corriente dada de alta.
Fracaso:
• Use Case cancelado por no existir el cliente.
• Use Case cancelado por datos inválidos.
al cliente selecciona la opción Cuenta Corriente.
la opción “Nueva Cuenta Corriente”.
3. El sistema solicita que se seleccione el cliente.
4. El encargado de atención al cliente busca y 4.1 El encargado de atención al cliente busca
encuentra al cliente y lo selecciona. y No encuentra al cliente.
la cuenta corriente (fecha de alta, limite de
crédito, plazo de crédito, nombre de usuario para
auto consulta, password).
datos solicitados.
operación.
correctos. No son correctos.
8.1.1 El sistema informa lo sucedido.
8. El sistema registra la cuenta corriente.
Historia de cambios


9. registrarNuevaCuenta(fecha de alta, limite de crédito, plazo de crédito, nombre de usuario para auto consulta, password)
: Encargado de Corrientes
Atencion al Cliente
10. registrarNuevaCuenta(fecha de alta, limite de crédito, plazo de crédito, nombre de usuario para auto consulta, password)

14. agregar(cuenta)
11. registarClienteAutoGestion(nombreUsuario, pass)

Corriente
13. registrarNuevaCuenta(fecAlta, limiteCrédito, plazoDeCredito, cliente, usuario)
: Cliente de autogestion
: Cuenta Corriente


Nombre del Use Case: Inhabilitar Cuenta Corriente. Id: 127
Objetivo: Dar de baja a una cuenta corriente existente.
Precondiciones: Usuario logeado y con permisos para inhabilitar cuenta corriente.
Poscondiciones:
Éxito:
• Cuenta Corriente inhabilitada.
Fracaso:
• Use Case cancelado por no existir la cuenta corriente.
• Use Case cancelado por no obtener resultados de la búsqueda.
1. El UC Comienza, cuando Encargado de cobros
parámetros de búsqueda (fecha de alta, cliente)
de búsqueda.
resultados obtenidos. búsqueda.
5. El Encargado de cobros busca y encuentra a la 5.1 El Encargado de cobros busca y No
cuenta corriente y lo selecciona. encuentra a la cuenta corriente.
deshabilitar Cuenta Corriente.
6. El Encargado de cobros ingresa la fecha de
baja.
7. El Encargado de cobros confirma la operación.
correctos. No son correctos.
8.1.1 El sistema informa lo sucedido.
8. El sistema da de baja a la cuenta corriente.
Historia de cambios


Nombre del Use Case: Registrar Forma de pago. Id: 155
Actor principal: Administrador.
Objetivo: Registrar una forma de pago.
Precondiciones: Usuario logueado y con permisos para registrar forma de pago.
Poscondiciones:
Éxito:
• Forma de pago registrada.
Fracaso:
• Use case cancelado por invalidez de la descripción de la forma de pago.
1. El Use Case Comienza cuando el administrador
selecciona la opción Forma de Pago.
2. El administrador selecciona la opción “Nueva
Forma de Pago”.
3. El sistema solicita que se ingrese la descripción
de la forma de pago.
4. El administrador ingresa la descripción de la
forma de pago.
5. El administrador confirma la operación.
6. El sistema valida la descripción ingresada y es 6.1 El sistema valida la descripción ingresada
valida. y no es valida.
7. El sistema registra la forma de pago.
Historia de cambios


Nombre del Use Case: Dar de baja a forma de pago. Id: 156
Objetivo: Dar de baja a forma de pago.
Precondiciones: Usuario logueado y con permisos para dar de baja forma de pago.
Poscondiciones:
Éxito:
• Forma de pago dada de baja.
Fracaso:
• Use case cancelado por invalidez de la descripción de la forma de pago.
• Use case cancelado porque la operación no es permitida.
2. El sistema solicita la descripción de la forma de
pago.
forma de pago.
5. El administrador selecciona la opción Dar de
baja a forma de pago.
6. El administrador confirma la operación.
7. El sistema valida la operación solicitada y es 7.1 El sistema valida la operación y no es
valida. valida.
8. El sistema da de baja a la forma de pago.
Historia de cambios


Nombre del Use Case: consultar forma de pago. Id: 156
Objetivo: consultar forma de pago.
Precondiciones: Usuario logueado y con permisos para dar de baja forma de pago.
Poscondiciones:
Éxito:
• Formas de pago consultadas.
Fracaso:
• Use case cancelado por no obtener.
• Use case cancelado porque la operación no es permitida.
2. El sistema solicita la descripción de la forma de
pago.
forma de pago.
Historia de cambios

Ventas: Diagrama de Clases
Pegar aquí diagrama de clase cobro.

Pegar aquí diagrama de clases cuenta corriente

Pegar aquí diagrama de clases detalle de venta

Pegar aquí venta

Analisis del Paquete: Produccion.
Producción
Alimentación
Clasificación e
incubación Producto
Compras
Enfermedades y control de
Faenamiento y
estanques
envasado

Análisis del Paquete: Alimentación
Ali mentaci ón
2- Verificar existencia de alimentos

3- Registrar Alimentación
<<extend>>
<<extend>>
Encargado de
83- Emitir informe de existencia de Compras
81- Consultar Alimentos alimentación
<<extend>>
80- Modificar Alimentos Encargado de

Producción
64- Emitir Listado de alimentos a
comprar
79- Registrar Alimento
1- Generar Plan de Alimentación
82- Dar de baja al Alimento
55- Dar de baja a parámetros de

planificación de almientación 85- Modificar Parámetros de
Planificación de Alimentación
84- Registrar Parámetros de

Planificación de Alimentación

Alimentación: Descripciones y diagramas de colaboración de

análisis.

Nombre del Use Case: Modificar parámetros de planificación
de alimentación. Id: 85
Actor principal: Encargado de producción.
Objetivo: Modificar parámetros para la correcta generación de planes de alimentación.
Precondiciones: Usuario logeado para modificar parámetros de planificación de alimentación.
Poscondiciones:
Éxito:
• Parámetros de planes de alimentación actualizados.
Fracaso:
• Cancelado por datos no válidos.
• Cancelado por usuario.
1. El UC Comienza, cuando el usuario (Encargado
de producción) selecciona la opción “Modificar
Parámetros de planes de alimentación”.
2. El sistema muestra por pantalla la fecha y el
usuario actualmente conectado.
correspondientes al parámetro de plan de
alimentación (especie, intervalo, cantidad,
relación tamaño/alimento, relación
cantidad/alimento, relación especie/alimento,
relación grasa/especie, relación
proteínas/especie, relación fibra/especie).
4. El usuario ingresa los datos correspondientes a
los parámetros de plan de alimentación.
5. El sistema valida los datos ingresados y estos 5.1 El sistema valida los datos ingresados y
son correctos. estos no son correctos.
5.1.1 Se cancela el UC.
6. El sistema solicita la confirmación de la
operación.
7. El usuario confirma la operación. 7.1 el usuario cancela la operación.
7.1.1 se cancela el UC.
8. El sistema registra las modificaciones del
parámetro de plan de alimentación.
9. Fin del use case.
Historia de cambios


Nombre del Use Case: registrar alimento. Id: 79
Objetivo: registrar un nuevo tipo de alimento que será utilizado para la planificación y ejecución
de la alimentación.
Precondiciones: Usuario logeado y con permisos para registrar alimento.
Poscondiciones:
Éxito:
• Alimento registrado.
Fracaso:
• Cancelado por el usuario al cancelar operación.
de producción) selecciona la opción registrar
alimento.
2. El sistema muestra por pantalla la fecha actual
y el usuario actualmente conectado y el número
de alimento que se le asignará al nuevo alimento.
3. El sistema solicita al usuario los datos del
alimento (nombre, descripción, grasa, fibra,
humedad, ceniza, proteína)
4. El usuario ingresa los datos del alimento.
5. El sistema verifica los datos ingresados 5.1 El sistema verifica los datos ingresados
validándolos y consultando los alimentos ya validándolos y consultando los alimentos ya
existentes. Los datos son correctos. existentes. Los datos NO son correctos.
5.1.1 Se cancela el U.C.
6. el sistema registra el nuevo alimento.
7. Fin del U.C.
Historia de cambios

1. obtenerIdNuevoAli mento( )
5. registrarAl imento(nombre, descripci ón, grasa, fibra, humedad, ceniza, proteína)
: Interfaz de Alimentos
: Encargado de
Producción
2. obtenerNuevoIdAlimento( )
6. regi strarAlimento(nombre, descripción, grasa, fibra, humedad, ceni za, proteína)
: Colecci on de Alimentos 8. agregarAli mento(alimento) : Gestor de Al imentos

3. obtenerNuevoIdAli mento( )
7. regi strar(nombre, descripción, grasa, fibra, humedad, ceniza, proteína)
: Alimento : Gestor de Usuarios


Nombre del Use Case: Modificar alimento. Id: 80
Objetivo: Modificar los datos de un registro de alimento existente que luego será utilizado en la
planificación de la alimentación.
Precondiciones: Usuario logeado y con permisos para modificar alimento.
Poscondiciones:
Éxito:
• Datos de alimento modificado
Fracaso:
• Cancelado por datos no validos.
• Cancelado por falta de resultados.
de producción) selecciona la opción “alimentos”.
2. El sistema solicita que busque el alimento a 2.1 No se encuentran resultados.
modificar por alguna característica (nombre, 2.1.1 Se cancela el Use Case.
descripción, grasa, fibra, humedad, ceniza,
proteína).
3. El usuario selecciona el alimento a modificar y
selecciona la opción “Modificar”.
4. El sistema solicita el ingreso de las
modificaciones deseadas.
5. El usuario modifica los datos deseados y 5.1 El usuario selecciona “Cancelar”
confirma la operación (descripción, tipo, grasa, 5.1.1 Se cancela el UC.
proteína, fibra, ceniza, humedad).
6. El sistema verifica que los datos modificados 6.1 El sistema verifica que los datos
sean correctos, y estos si lo son. modificados sean correctos, y estos no lo son.
7. El sistema actualiza los datos del alimento.
8. Fin del U.C.
Historia de cambios

1. consultarAlimentos(nombre, descripci ón, grasa, fibra, humedad, ceniza, proteína)

4. seleccionarAl imento(id)
7. modi ficarAli mento(nombre, descri pción, grasa, fibra, humedad, ceniza, proteína)
: Interfaz de Ali mentos

: Encargado de
Producción
2. buscarAl imentos(nombre, descripción, grasa, fibra, humedad, ceni za, proteína)

5. selecci onarAl imento(id)
9. modi ficarAli mento(nombre, descri pción, grasa, fibra, humedad, ceniza, proteína, usuari o)
: Colecci on de Al imentos
: Gestor de Alimentos
11. actualizarAli mento(alim ento)
6. obtenerAli mento(id)
3. buscarAlimentos(nombre, descripción, grasa, fibra, humedad, ceni za, proteína)
10. modificar(nombre, descripci ón, grasa, fi bra, humedad, ceniza, proteína, usuari o)
: Ali mento


Nombre del Use Case: Consultar alimento. Id: 81
Objetivo: Obtener un listado de alimentos que cumplan con ciertas condiciones ingresadas por el
usuario.
Precondiciones: Usuario logeado y con permisos para consultar alimento.
Poscondiciones:
Éxito:
• Consulta de alimentos realizada.
Fracaso:
2. El sistema solicita el ingreso de los parámetros
de filtro de la consulta.
3. El usuario Ingresa los parámetros de filtro para 3.1 El usuario selecciona “Cancelar”
la consulta de los alimentos (nombre, descripción, 3.1.1 Se cancela el UC.
proteína, grasa, fibra, ceniza, humedad).
4. El sistema consulta los datos de los alimentos
que cumplan con los parámetros ingresados.
5. El sistema emite listado con los datos de los
alimentos consultados
6. Fin del U.C.
Historia de cambios
1 07/06/2005 Creación dverme
1.1 1/08/2005 Corrección. rochoa

1. consultarAlimentos(nombre, descripción, grasa, fibra, humedad, ceniza, proteína)
: Interfaz de Alimentos
: Encargado de
Producción
2. buscarAl imentos(nombre, descripción, grasa, fi bra, humedad, ceniza, proteína)
3. buscarAlimentos(nom bre, descripción, grasa, fibra, humedad, ceniza, proteína)
: Coleccion de Alimentos : Gestor de Alimentos
4. consultar( )
: Ali mento


Nombre del Use Case: Dar de baja a alimento. Id: 82
Objetivo: Dar de baja a un registro de alimento existente por lo cual no podrá ser utilizado para la
planificación de la alimentación.
Precondiciones: Usuario logeado y con permisos para dar de baja a alimento.
Poscondiciones:
Éxito:
• Alimento dado de baja
Fracaso:
• No se encuentran resultados.
2. El sistema solicita los parámetros para buscar el 2.1 El sistema no encuentra resultados.
alimento a dar de baja (nombre, descripción, 2.1.1 Se cancela el Use Case.
grasa, fibra, humedad, ceniza, proteína) y el
encargado los ingresa y el sistema encuentra
resultados.
3. El usuario selecciona el alimento a dar de baja
y selecciona la opción “Dar de baja”.
operación.
5. El usuario confirma la operación. 5.1 El usuario selecciona “Cancelar”
6. El sistema da de baja al alimento
7. Fin del U.C.
Historia de cambios
1 07/06/2005 Creación Dverme

1. consultarAlimentos(nombre, descri pción, grasa, fibra, humedad, ceniza, proteína)

4. seleccionarAlimento(id)
7. darDeBajaAlimentoSeleccionado( )
: Interfaz de Alim entos
: Encargado de
Producción
2. buscarAlimentos(nombre, descripción, grasa, fibra, humedad, ceniza, proteína)

5. seleccionarAlimento(id)
9. darDeBajaAlimentoSeleccionado( )
11. actualizarAlimento(alimento)
6. obtenerAlimento(id)
3. buscarAlimentos(nombre, descripción, grasa, fibra, humedad, ceniza, proteína)
: Coleccion de Alimentos : Gestor de Alimentos
10. darDeBaja(usuario)
: Alimento


Nombre del Use Case: Registrar parámetros de planificación de alimentación. Id: 84
Objetivo: Registrar parámetros para la correcta generación de planes de alimentación.
Precondiciones: Usuario logeado y con permisos para registrar parámetros de plan de
alimentación.
Poscondiciones:
Éxito:
• Parámetros de planes de alimentación cargados.
Fracaso:
de producción) selecciona la opción “Registrar
Parámetros de planes de alimentación”.
2. El sistema muestra por pantalla la fecha y el
usuario actualmente conectado.
alimentación (especie, intervalo, cantidad,
relación tamaño/alimento, relación
cantidad/alimento, relación especie/alimento,
relación grasa/especie, relación
proteínas/especie, relación fibra/especie).
los parámetros de plan de alimentación.
operación.
8. El sistema registra el nuevo parámetro de plan
de alimentación.
Historia de cambios


Nombre del Use Case: Generar plan de alimentación. Id: 1
Objetivo: Emitir un plan de alimentación para los estanques y lotes correspondientes.
Precondiciones: Usuario logeado y con permisos para generar plan de alimentación.
Poscondiciones:
Éxito:
• Plan de alimentación generado.
Fracaso:
• Cancelado por el usuario al no estar disponible el estanque deseado.
• Cancelado por el usuario al no aceptar el plan de alimentación.
de producción) selecciona la opción Generar Plan
de Alimentación.
2. El sistema filtra los estanques teniendo en
cuenta aquellos que están produciendo y que
están pendientes de realizar un plan de
alimentación.
3. El sistema muestra la información de todos los
estanques consultados (Número, ubicación,
capacidad, tamaño, descripción, responsable).
4. El sistema solicita al usuario que seleccione el
estanque al cual se le generará el plan de
alimentación.
5. El estanque deseado por el usuario se 5. 1 El estanque deseado por el usuario NO se
encuentra entre los disponibles. encuentra entre los disponibles (el usuario
selecciona cancelar).
6. El usuario selecciona el estanque al cual se le
generará el plan de alimentación.
7. el sistema muestra en pantalla los datos de los
estanques seleccionado, junto con la fecha actual
y el usuario actualmente conectado.
8. El sistema consulta los datos de los proveedores
(Razón social, CUIT) y solicita al usuario los datos
relacionados con el alcance del pan de
alimentación (fecha de vigencia, proveedores de
alimento deseados)
9. El sistema realiza una nueva consulta acerca de
los datos del estanque seleccionado(Estado,
población de peces, planes de alimentación
aplicados, capacidad máxima, distribución de
lotes de peces)
10. el sistema realiza una consulta del stock de
alimentos teniendo en cuenta la/las especies a ser
alimentadas (se extiende el Use Case “Verificar
existencia de alimentos”).
11. el sistema genera un plan de alimentación
para el estanque seleccionado y los lotes
correspondientes, mostrando la cantidad de
alimentos a utilizar, el tipo de alimento, la
frecuencia de alimentación, la calidad mínima
requerida de acuerdo al lote, los horarios de
alimentación, los proveedores disponibles de los
alimentos utilizados, el stock de los alimentos

alertando en caso de alimentos cuyo stock este

por debajo del punto de pedido.
12. El sistema solicita al usuario la confirmación
del plan.
13. El usuario acepta el plan de alimentación 13.1 El usuario no acepta el plan de
propuesto. alimentación propuesto.
14. El sistema registra un nuevo plan de
alimentación y actualiza el estado del estanque y
los lotes.
15. El sistema emite el plan realizado al usuario
final.
Historia de cambios
1 30/072005 Creación Grupo de Desarrollo


Nombre del Use Case: Verificar existencia de alimentos Id: 2
Actor secundario: Encargado de compras.
Objetivo: Informar la existencia actual de alimentos.
Precondiciones:
Poscondiciones:
Éxito:
• Informe de stock de alimentos informada.
Fracaso:
•
1. El Use Case inicia cuando el sistema necesita
verificar la existencia de alimentos.
2. El sistema en base al tipo de alimento
consultado, determina la cantidad actual de
alimentos.
3. El sistema informa si existen la cantidad de 3.1 No existen la cantidad de alimentos
alimentos requeridos y existen. requerida.
3.1.1 El sistema emite una notificación al
encargado de compras.
Use Case al que se extiende: Generar plan de alimentación, emitir listados de alimentos a
comprar, emitir informe de existencia de alimentos.
Historia de cambios


Nombre del Use Case: Registrar alimentación. Id: 3
Objetivo: Registrar el proceso de alimentación, para cada estanque y actualizar la existencia de
alimentos y el seguimiento de estanques.
Precondiciones: Usuario logeado y con permisos para registrar alimentación.
Poscondiciones:
Éxito:
• Alimentación de estanques registrada, existencia de alimentos al día, seguimiento de
estanques actualizado.
Fracaso:
Alimentación en estanque”.
2. El sistema consulta los datos de los estanques
(Número, descripción, ubicación, plan de
alimentación asignado) y de los planes de
alimentación existentes (Fecha desde, fecha
hasta, periodo de alimentación –Próxima
alimentación-).
3. El sistema muestra por pantalla todos los
estanques antes consultados filtrando aquellos
que no están produciendo o que están en
mantenimiento solicitando al usuario que
seleccione el plan utilizado para la alimentación.
4. El estanque deseado por el usuario se 4.1 El estanque deseado por el usuario no se
encuentra disponible. encuentra disponible (el usuario selecciona
cancelar)
5. El usuario selecciona el estanque utilizado.
6. El sistema consulta los datos del plan de
alimentación del estanque seleccionado.
7. El sistema muestra por pantalla los datos
consultados (nombre de alimento, cantidad,
horario de alimentación, estanque
correspondiente).
8. El sistema solicita al usuario que ingrese los
datos de la alimentación.
9. El usuario ingresa los datos de la alimentación
realizada (nombre de alimento, cantidad,
horario).
10. El sistema verifica que los datos ingresados se 10.1 El sistema verifica que los datos
correspondan con la planificación y estos ingresados se correspondan con la
corresponden. planificación y estos NO corresponden.
10.1.1 El sistema informa de la desviación.
11. El sistema consulta el stock de alimentos
alertando al usuario en caso de que el nuevo stock
de los alimentos estén por debajo del punto de
pedido o por debajo del stock mínimo.
12. El usuario acepta la operación. 12. El usuario cancela la operación.
12.1 Se cancela el U.C.
13. El sistema registra la alimentación
actualizando el stock de alimentos y el
seguimiento de estanques y de lotes (Fecha,

alimento, nombre alimento, cantidad de

alimentos, operario)
14. Fin del U.C.
Historia de cambios


Nombre del Use Case: Dar de baja a parámetro de alimentación. Id: 3
Objetivo: Dar de baja un parámetro de plan de alimentación por lo cual ya no será utilizado para
la generación de las planificaciones.
Precondiciones: Usuario logeado y con permisos para dar de baja a parámetro
Poscondiciones:
Éxito:
• Parámetro de alimentación dado de baja.
Fracaso:
de producción) selecciona la opción “Dar de baja
a parámetro de alimentación”.
2. El sistema consulta todos los parámetros de
alimentación existentes.
consultados.
parámetro de alimentación a dar de baja.
5. El usuario selecciona el parámetro de 5.1 El usuario selecciona “Cancelar”
alimentación al cual se le desea dar de baja. 5.1.1 Se cancela el UC.
operación.
7. El usuario confirma la operación. 7.1 El usuario No confirma la operación.
8. El sistema da de baja al parámetro de
alimentación.
9. Fin del U.C.
Historia de cambios


Nombre del Use Case: Emitir listado de alimentos a comprar. Id: 64
Objetivo: Emitir un informe con el stock de alimentos informando aquellos que están por debajo
del punto de pedido y alertando de aquellos que están por debajo del stock mínimo.
Precondiciones: Usuario logeado y con permisos para emitir listado de alimentos a comprar.
Poscondiciones:
Éxito:
• Listado de alimentos a comprar emitido con potenciales proveedores.
Fracaso:
de producción) selecciona la opción “Emitir
listado de alimentos a comprar”.
2. El sistema muestra por pantalla la fecha actual.
3. El sistema solicita los parámetros de filtro para
el informe (Nombre de alimento, descripción de
alimento, grasa, proteína, fibra).
4. El usuario ingresa los parámetros de filtro. Si no
los ingresa el sistema tendrá en cuenta toda la
información.
operación.
7. El sistema consulta los datos de los alimentos
(se extiende el Use Case “Verificar existencia de
alimentos”) y de los proveedores relacionados.
8. El sistema genera un informe que contempla
(Alimento, punto de pedido, stock, mínimo,
posible proveedor, condición de stock mínimo y
punto de pedido, posible gasto potencial de poner
al día el stock)
9. Fin del U.C.
Historia de cambios


Nombre del Use Case: Emitir informe de existencia de alimentos. Id: 83
Objetivo: Emitir un listado con el stock de los alimentos actuales.
Poscondiciones: Usuario logeado y con permisos para emitir informe de existencia de alimentos.
Éxito:
• Listado de stock de alimentos emitido.
Fracaso:
• Cancelación de usuario
1. El Use Case comienza cuando usuario
selecciona la opción “Alimentos”.
2. El usuario selecciona la opción “Stock de
alimentos”.
3. El sistema solicita los parámetros de filtro de la
consulta (Alimento, tipo, Proveedor).
4. El usuario ingresa los parámetros de filtro de la
consulta.
operación.
7. El sistema consulta los datos de los artículos
que se correspondan con los parámetros
ingresados. (Se extiende al Use Case “Verificar
existencia de alimentos”)
8. El sistema elabora un informe conteniendo el
stock de los artículos, indicando aquellos que
están debajo del punto de pedido y debajo del
stock mínimo.
9. El sistema emite el informe correspondiente.
10. Fin del UC.
Asociaciones de extensión: Verificar existencia de alimentos.
Use Case al que se extiende: No aplica
Historia de cambios

Alimentación: Diagrama de Clases
Alimento
nombre
id
gras a
fibra
humedad
c eniza
proteina
regis trar(nombre, desc ripción, grasa, fibra, humedad, c eniz a, proteína)
darDeBaja(us uario)
modific ar(nombre, desc ripción, gras a, fibra, humedad, ceniz a, proteína, us uario)
c ons ultar()
0..*
Colec c ion de Alimentos

alimentos [] : Alimento
obtenerNuev oIdAlimento()
agregarAlimento(alimento : Alimento)
bus carAlimentos (nombre, des c ripción, grasa, fibra, humedad, c eniz a, proteína)
obtenerAlimento(id)
ac tualiz arAlimento(alimento : Alimento)
Gestor de Alimentos
colec cionDeAlimentos : Colec c ion de Alimentos
alimentoSelec : Alimento
usuario : UsuarioSis
obtenerNuev oIdAlimento()
regis trarAlimento(nombre, des c ripc ión, gras a, fibra, humedad, c eniza, proteína)
bus c arAlimentos(nombre, des c ripc ión, gras a, fibra, humedad, c eniza, proteína)
selec cionarAlimento(id)
modificarAlimento(nombre, des c ripc ión, gras a, fibra, humedad, c eniz a, proteína, us uario)
darDeBajaAlimentoSelec c ionado()
Interfaz de Alimentos
ges torDeAlimentos : Ges tor de Alimentos
obtenerIdNuev oAlimento()
registrarAlimento(nombre, des c ripción, grasa, fibra, humedad, c eniz a, proteína)
consultarAlimentos(nombre, des cripc ión, grasa, fibra, humedad, c eniz a, proteína)
selecc ionarAlimento(id)
modific arAlimento(nombre, des c ripción, gras a, fibra, humedad, c eniz a, proteína)
darDeBajaAlimentoSelec c ionado()

Parametro de Alimentacion
intervalo
cantidad
relacionTamañoAlimento
relacionCantidadAlimento
relacionEspeciAlimento
especie : Especie
relacionGrasaEspecie
relacionProteinasEspecie
relacionFibrasEspecies
consultar()
registrar(especie, intervalo, cantidad, relTam/Al, relCant/Al, relaEsp/Al, relGrasa/Esp, relProt/Esp, relFib/Esp, usuario)
modificar()
darDeBaja()
0..*
Coleccion de Parametros de Alimentacion

parametros[] : Parametro de Alimentacion
actualizar(param : Parametro de Alimentacion)

obtener(id)
Interfaz de Parametros de Alimentacion

gestorDeParametros : Gestor de Parametros de Alimentacion
parametroSel : Parametro de Alimentacion
registrar(intervalo, cantidad, relTam/Al, relCant/Al, relaEsp/Al, relGrasa/Esp, relProt/Esp, relFib/Esp)

registrarNuevoParametro()
Gestor de Parametros de Alimentacion

coleccionDeParametros : Coleccion de Parametros de Alimentacion
especieSel
gestorDeEspecies : Gestor de Especies
registrarParam(intervalo, cantidad, relTam/Al, relCant/Al, relaEsp/Al, relGrasa/Esp, relProt/Esp, relFib/Esp)

buscarEspecies()
Gestor de Especies
(from Especie)
especieSeleccionada : Especie
resultadoDeBusqueda[] : Especie
coleccionDeEspecies : Coleccion de Especies
registrarEspecie(nombre, tamaño maximo, peso maximo, color, tamaño minimo, peso minimo, observaciones)
modificarEspecie(nombre, tamaño maximo, peso maximo, color, tamaño minimo, peso minimo, observaciones)
darDeBajaEspecieSeleccionada()
consultarTodas()
obtenerEspecie(id)

Pegar diagrama de clase alimentación.

Análisis del Paquete: Clasificacion e incubación
Clasificación e
incubación
96- Registrar clase de lote 10- Registrar clasificación de lotes
<<extend>>
97- Modificar Clase de Lote

89- Registrar Parametrización de
Plan de Clasificación
27- Registar crecim iento de ovas y
alevinos
11- Emitir plan de clasificación
41- Emitir informes de seguimiento 25- Registrar lote a incubar

de lotes
Encargado de
Producción
21- Registrar estanque y lote listo a
fanear
93- Registrar Estanque
90- Modificar Parametrización de

plan de Clasificación
94- Modificar Estanque
91- Consultar planes de

Clasificación
92- Dar de baja a parámetros de

Planificación de Clasificación
95- Dar de baja a Estanque
98- Consultar Estanques

Clasificación e incubación: Descripciones y diagramas de


Nombre del Use Case: Consultar Estanque. Id: 98
Objetivo: Consultar los datos de los estanques existentes.
Precondiciones: Usuario logeado y con permisos para poder consultar estanque
Poscondiciones:
Éxito:
• Estanques consultados.
Fracaso:
1. El UC Comienza, cuando encargado de
producción selecciona la opción Estanques.
del estanque (ubicación, capacidad, tamaño,
identificador, descripción, fecha de alta,
responsable).
4. El sistema solicita al usuario que confirme la
operación.
existentes de acuerdo a los parámetros de
búsqueda ingresados.
consultados
Historia de cambios


Nombre del Use Case:
Registrar clasificación de lotes Id: 10
Objetivo: registrar la clasificación de los lotes.
Precondiciones: Usuario logeado y con permisos para registrar clasificación de lotes.
Poscondiciones:
Éxito:
• Clasificación de lote registrado.
Fracaso:
1. El use case comienza, cuando el encargado de
producción selecciona la opción “Registrar
clasificación de lotes”
2. El sistema consulta los datos de los estanque
actualmente en producción (Número, población,
ubicación, estado, plan de clasificación asignado).
consultados (Estanque, población, ubicación, plan
de clasificación asignado) filtrando aquellos que
no se encuentran produciendo o que están en
mantenimiento.
estanque al cual se le registrará la clasificación.
5. El estanque deseado se encuentra entre los 5.1 El estanque deseado no se encuentra
disponibles. entre los disponibles (el usuario selecciona
“cancelar”).
registrará una clasificación.
clasificación asignado al estanque seleccionado y
del seguimiento del mismo (Estanque, población
del estanque, lote de peces actuales, fecha de
vigencia, última clasificación aplicada, fecha de
próxima clasificación, operario responsable,
cantidad de cada clase esperada en la próxima
clasificación).
8. El sistema muestra por pantalla los datos de los
estanques y planes de clasificación antes
consultados ordenándolos de acuerdo a la fecha
de próxima clasificación esperada.
datos de la clasificación.
10. El usuario ingresa los datos de la clasificación
(Fecha, operario a cargo, cantidad de peces
clasificados, cantidad de peces de cada clase de
acuerdo a la calidad del pez-cabeza, cuerpo, cola-
, cantidad de peces de cada clase de acuerdo al
tamaño del pez).
10. El sistema compara los datos ingresados con
los esperados de acuerdo al plan de clasificación.
11. los datos ingresados son correspondientes al 11.1 Los datos ingresados no son
plan. correspondientes al plan, el sistema alerta la
desviación.

11.1.1 El usuario cancela la operación

11.1.1.1 Se cancela el UC.
11.1.2 El usuario modifica los datos

deseados.( sigue en punto 12)
11.1.3 El usuario selecciona no modificar

registración (sigue en punto 12).

operación.
13.1.1 Fin del UC.
14. El sistema registra la nueva clasificación,
actualizando el seguimiento del estanque (fecha,
resultado de clasificación) y el resultado de
clasificación (fecha, especie, clase de acuerdo a
la calidad, clase de acuerdo al tamaño, cantidad)
del lote correspondiente.
15. Fin del UC.
Use Case al que se extiende: “Registrar Crecimiento de ovas y alevinos”
Historia de cambios

1. buscarEstanques(Número, ubicación, capacidad, tamaño)

4. selecci onarEstanque(id)
8. regi strarClasificacion(EstanqueDestino, cantidad, clase, fecha)
: Interfaz de
: Encargado de Clasifi cacion
Producción

5. seleccionarEstanque(id)
10. registrarClasifi cacion(clase, estanqueDestino, fecha)
: Coleccion de Estanques

12. actualizarEstanque(estanque)
: Gestor de Clasificacion
7. consultarPlan( ) 13. registrarClasificacion(clase, fecha, cantidad, estanqueDestiono)
: Estanque
: Seguimiento de Estanque
14. registrarClasifi cacion(clase, fecha, cantidad, estanqueDestino)
: Resultado de Clasificacion
11. registrarClasificacion(lote, catidad, clase)

: Clasificacion


Nombre del Use Case: Emitir plan de clasificación. Id: 11
Objetivo: Generar un nuevo plan para la clasificación de los estanques.
Precondiciones: Usuario logeado y con permiso para generar plan de clasificación.
Poscondiciones:
Éxito:
• Plan de clasificación generado.
Fracaso:
1. El UC. Comienza, cuando el usuario (Encargado
de producción) selecciona la opción “Generar Plan
de Clasificación”.
existentes (Número, ubicación, capacidad,
tamaño).
3. El sistema muestra los datos de los estanques
consultados filtrando aquellos que no están
produciendo o que están en mantenimiento.
estanque al cuál se le generará el plan de
clasificación.
“Cancelar”
5.1.1 Se cancela UC.
realizará el plan de clasificación.
7. El sistema consulta los datos del estanque
(numero, ubicación, capacidad, tamaño), del
seguimiento del estanque (lotes actuales, especie,
clase de lote, cantidad) y de los demás planes de
clasificación (estanque, fecha de próxima
clasificación).
8. El sistema consulta los datos de los parámetros
de clasificación (especie, relación edad/tamaño,
tamaños óptimos para clasificación)
9. El sistema calcula la fecha potencial para
realizar la clasificación y las clases de lotes
esperados (teniendo en cuenta las especies y
clases de lotes existentes en el estanque) y los
potenciales estanque destino de la clasificación
(teniendo en cuenta las fechas de clasificación ya
existentes).
10. El sistema genera un plan de clasificación la
información calculada conteniendo: estanque,
fecha de próxima clasificación, detalle (clase de
acuerdo a calidad, clase de acuerdo al tamaño,
cantidad esperada).
11. El sistema muestra por pantalla el plan
generado.
operación.
14. El sistema registra el nuevo plan de

clasificación generado actualizando los datos del

seguimiento de estanque (planes aplicados).
15. Fin del UC.
Historia de cambios

: Interfaz de
: Encargado de Clasificacion
Producción
: Estanque
7. emitirPlanDeClasificación( )
: Gestor de Clasificacion
8. consultarLotesActuales( )
12. consultarPlanDeClasificacion( )
13. generarPlanDeClasificacion( )
: Seguimiento de Estanque
16. consultarEstanquesDisponibles(fecha)
9. obtenerUltimaClasificacion( )
: Coleccion de Estanques
: Plan de clasificación
15. calcularPlanEstimado( )
: Coleccion de Clasificaciones
14. obtenerParametro(Especie)
10. obtenerLotesActuales( )
: Parametro de clasificación
11. obtenerLote( )
: Coleccion de Parametros de
clasificacion
: Clasificacion : Resultado de Clasificacion


Nombre del Use Case: Registrar estanque y lote listo para faenar. Id: 21
Objetivo: Registrar un estanque y los lotes correspondientes como listos para faenar.
Precondiciones: Usuario logeado y con permiso para registrar estanque listos para faenar.
Poscondiciones:
Éxito:
• Plan de clasificación generado.
Fracaso:
• cancelado por usuario.
1. El UC. Comienza cuando el encargado de
estanque listo para faenar”.
2. El sistema solicita al usuario que ingrese el
estanque al cual se lo registrará como listo para
faenar.
3. El usuario ingresa el número de estanque. 3.1 El usuario selecciona la opción “Mostrar
estanques potenciales”
3.1.1 El sistema consulta los datos de los
estanques (número, población) y de los
seguimientos correspondientes (resultados de
clasificación) y de los resultados de
clasificación (fecha, especie, clase de
acuerdo a tamaño, cantidad).
3.1.2 El sistema filtra los resultados de
clasificación teniendo en cuenta solo el
último de cada estanque.
3.1.3 El sistema muestra por pantalla los
datos consultados y filtrados ordenando los
estanques de acuerdo al tamaño promedio de
los lotes correspondientes indicando cual o
cuáles son los más óptimos para registrar
como listo para faenar.
3.1.4 El sistema solicita al usuario que
selecciones al estanque que se lo registrará
como listo para faenar.
3.1.5 El usuario selecciona el estanque
correspondiente (Continua en el punto 4).
3.1.5.1 El usuario selecciona “Cancelar”.
3.1.5.1.1 Fin del UC.
ingresado (Numero, tamaño, capacidad, lotes
actuales) y de los lotes correspondientes al
estanque (Especie, cantidad, clase de acuerdo al
tamaño, clase de acuerdo a la calidad)
consultados.
6. El sistema solicita al usuario la confirmación de
la operación.
7. El usuario confirma la operación. 7. El usuario cancela la operación.
7.1 Se cancela el UC.
8. El sistema registra al estanque y los como listo
para faenar.
9. Fin del UC.


Historia de cambios

Nombre del Use Case: Registrar lote a incubar Id: 25
Objetivo: Registrar el inicio de una incubación de un lote de ovas.
Precondiciones: Usuario logeado y con permiso para registrar lote a incubar.
Poscondiciones:
Éxito:
• Lote a incubar registrado.
• Seguimiento de lotes y estanques actualizado.
Fracaso:
producción selecciona la opción “Registrar lote a
incubar.”
2. El sistema consulta los datos de los lotes de
ovas existentes (Número, clase, estado, fecha de
ingreso)
lotes consultados ordenándolos de acuerdo a la
fecha de ingreso (primero el más antiguo).
lote al cual se incubará.
5. El usuario selecciona el lote al cual se incubará. 5.1 El usuario cancela la operación.
6. El sistema muestra en pantalla los datos del
lote de ovas seleccionados y solicita al usuario
ingrese el número del estanque en el cuál se
realizará la incubación.
7. El usuario ingresa el número de estanque en el 7.1 El usuario selecciona la opción buscar
cual se realizará la incubación. estanque.
7.1.1 El sistema consulta los datos de los
estanques (Número, tamaño, capacidad,
estado.
7.1.2 El sistema muestra por pantalla
aquellos estanques que están disponibles
para incubar (no están produciendo o están
en mantenimiento).
7.1.3 El sistema solicita al usuario que
seleccione el estanque en el cual se realizará
la incubación.
7.1.4 El usuario selecciona el estanque
correspondiente.
datos correspondientes a la incubación (cantidad a
incubar, clase de ova).
9. El usuario ingresa los datos de la incubación.
10. El sistema muestra en pantalla la cantidad de

ovas aun pendiente de incubar.

operación.
13. El sistema registra la operación actualizando
el estado del lote de ovas (incubando) y la fecha
de incubación.
14. Fin del UC.
Historia de cambios


Nombre del Use Case: Registrar crecimiento de ovas y alevinos Id: 27
Objetivo: registrar el crecimiento de las ovas y alevinos.
Precondiciones: Usuario logeado y con permisos para registrar crecimiento de ovas y alevinos.
Poscondiciones:
Éxito:
• Crecimiento de ovas y alevinos registrados.
• Seguimiento de lotes y estanques actualizado
Fracaso:
•
crecimiento de ovas y alevinos”
2. El sistema consulta los datos de los lotes de
incubación (Número, Estanque, Estado).
3. El sistema muestra por pantalla aquellos lotes
de incubación (Número, Estanque, fecha de
incubación) que están en estado “Incubando”.
lote de incubación al cual se registrará el
crecimiento.
5. El usuario selecciona el lote de incubación al 5.1 El usuario selecciona “Cancelar”
cual se registrará el crecimiento. 5.1.1 Fin del UC.
resultados de una muestra tomada del lote de
incubación (Muestra tomada, Especie, Tamaño
promedio, peso promedio). [Una muestra NO es
parte del sistema]
7. El sistema consulta los parámetros de
clasificación (especie, relación edad/tamaño,
Tamaños óptimos para clasificación)
8. El sistema compara la información ingresada
por el usuario con los parámetros de clasificación
consultados.
9. El sistema determina que el lote no debe ser 9.1 El sistema determina que el lote debe ser
clasificado. clasificado.
9.1.1 El sistema actualiza el estado del lote
de ovas (clasificado) y la fecha de
clasificación.
9.1.1 Se extiende el UC. “Registrar
clasificación de lotes”.
Fin del UC.
Asociaciones de extensión: “Registrar Clasificación de lotes”
Historia de cambios


Nombre del Use Case: Emitir informe de seguimiento de lotes. Id: 41
Objetivo: Emitir un informe de los estanques mostrando el porcentaje de las clases de los lotes
que contiene y el rendimiento de los mismos.
Precondiciones: Usuario logeado y con permisos para emitir informe de seguimiento de lote.
Poscondiciones:
Éxito:
• Informe de seguimiento de lote emitido.
Fracaso:
producción selecciona la opción “Emitir informe
de seguimiento de lotes”
(Número, Ubicación, Capacidad, población)
3. El sistema muestra pos pantalla los datos de los
estanques seleccionados.
estanque del cual se quiere obtener el informe.
5. El usuario selecciona el estanque del cual se 5.1 El usuario selecciona cancelar.
quiere obtener el informe. 5.1.1 Se cancela el UC.
6. El sistema muestra por pantalla los datos del
estanque seleccionado (Número, Ubicación,
Capacidad, población)
operación.
seleccionado (Número, Ubicación, Capacidad,
Población, Su seguimiento), los datos del
seguimiento del mismo (Lotes actuales,
Resultados de clasificación), de los resultados de
clasificación (fecha, especie, clase de acuerdo a
la calidad, clase de acuerdo al tamaño, cantidad)
y de los parámetros de clasificación (especie,
relación edad/tamaño).
10. El sistema determina las proporciones de las
clases de los lotes existentes en el estanque
teniendo en cuenta el resultado de clasificación
con fecha más reciente (el último) y sumando las
cantidades de este resultado.
11. El sistema compara los datos de los resultados
de Clasificación (Fecha, especie, clase de acuerdo
al tamaño) con los parámetros de clasificación
(especie, relación edad/tamaño) calculando las
diferencias de rendimiento.
12. El sistema acumula las cantidades de los
resultados de clasificación teniendo en cuenta la
clase de acuerdo a la calidad.
13. El sistema genera un informe conteniendo:
Estanque, Proporción de cada clase de acuerdo a
tamaño, proporción de cada clase de acuerdo a la
calidad, diferencias entre el rendimiento esperado

y el real (Calculado en el punto 11).

14. El sistema muestra por pantalla el resultado
del informe.
15. Fin del UC.
Historia de cambios

Nombre del Use Case: Registrar parámetros de
Planificación de clasificación. Id: 89
Objetivo: Registrar parámetros para la correcta generación de planes de clasificación.
Precondiciones: Usuario logeado y con permisos para registrar parámetros de plan de
clasificación.
Poscondiciones:
Éxito:
• Parámetros de planes de clasificación cargados.
Fracaso:
Parámetros de planes de clasificación”.
tamaños óptimos para clasificación).
los parámetros de plan de clasificación.
operación.
8. El sistema registra el nuevo parámetro de plan
de clasificación.
Historia de cambios



Nombre del Use Case: Modificar parámetros de planificación
de clasificación. Id: 90
Objetivo: Modificar parámetros para la correcta generación de planes de clasificación.
Precondiciones: Usuario logeado y con permisos para modificar parámetros de planificación de
clasificación.
Poscondiciones:
Éxito:
• Parámetros de planes de clasificación actualizados.
Fracaso:
Parámetros de planes de clasificación”.
2. El sistema muestra por pantalla la fecha.
tamaños óptimos para clasificación).
los parámetros de plan de clasificación.
operación.
parámetro de plan de clasificación.
Historia de cambios


Nombre del Use Case: Consultar planes de clasificación. Id: 91
Objetivo: Mostrar información acerca de los planes de clasificación existentes.
Precondiciones: Usuario logeado y con permiso para consultar planes de clasificación.
Poscondiciones:
Éxito:
• Planes de clasificación consultados.
Fracaso:
• Cancelado por usuario

1. El UC. Comienza, cuando el usuario (Encargado
de producción) selecciona la opción “Consultar
planes de Clasificación”.
2. El sistema consulta los estanques existentes
(número).
parámetros de filtro de la consulta (estanque,
fecha de próxima clasificación, clase de acuerdo a
calidad, clase de acuerdo al tamaño, cantidad
esperada).
4. El usuario ingresa los parámetros de la
consulta.
operación.
6.1.1 Fin del UC.
7. El sistema consulta los datos de los planes de
clasificación (Estanque, fecha de próxima
clasificación, clase de acuerdo al tamaño, clase
de acuerdo a la calidad, cantidad esperada) y de
los estanques correspondientes (Número,
Población, ubicación) que cumplan con los
8. El sistema muestra por pantalla los resultados
de la consulta.
9. Fin del UC.
Historia de cambios


Nombre del Use Case: Dar de baja a parámetro de clasificación. Id: 92
Objetivo: Dar de baja un parámetro de plan de clasificación por lo cual ya no será utilizado para
la generación de las planificaciones.
Precondiciones: Usuario logeado y con permisos para dar de baja a parámetro de plan de
clasificación
Poscondiciones:
Éxito:
• Parámetro de plan clasificación dado de baja.
Fracaso:
a parámetro de plan de clasificación”.
plan de clasificación existentes.
consultados.
parámetro de clasificación a dar de baja.
5. El usuario selecciona el parámetro de 5.1 El usuario selecciona “Cancelar”
clasificación al cual se le desea dar de baja. 5.1.1 Se cancela el UC.
operación.
8. El sistema da de baja al parámetro de
clasificación.
9. Fin del U.C.
Historia de cambios


Nombre del Use Case: Registrar estanque. Id: 93
Objetivo: Registrar un estanque que será utilizado para la producción.
Precondiciones: Usuario logeado y con permisos para registrar estanque.
Poscondiciones:
Éxito:
• Estanque registrado.
Fracaso:
• Use Case cancelado porque los datos del estanque no son correctos.
producción selecciona la opción “Estanques”.
2. El encargado de producción selecciona la
opción “Nuevo Estanque”.
estanque (ubicación, capacidad, tamaño,
responsable).
4. El encargado de producción ingresa los datos
del estanque.
5. El sistema solicita al usuario que confirma la
operación.
operación.
8. El sistema registra al nuevo estanque.
Historia de cambios


Nombre del Use Case: Modificar datos del estanque. Id: 94
Objetivo: Modificar los datos de un estanque existente.
Precondiciones: Usuario logeado y con permisos para poder modificar datos del estanque.
Poscondiciones:
Éxito:
• Estanque actualizado.
Fracaso:
• Use Case cancelado por no existir el estanque a modificar.
responsable).
4. El encargado de producción encuentra y 4.1 El encargado de producción NO encuentra
selecciona al estanque a modificar. al estanque a modificar.
opción “Modificar estanque”.
responsable).
operación.
8. El sistema actualiza los datos del estanque.
Historia de cambios


Nombre del Use Case: Dar de baja a estanque. Id: 95
Objetivo: Dar de baja a un estanque.
Precondiciones: Usuario logeado y con permisos para dar de baja al estanque.
Poscondiciones:
Éxito:
• Estanque dada de baja.
Fracaso:
• Use Case cancelado por no existir el estanque a dar de baja.
1. El UC Comienza, cuando Encargado de
de los estanques (número, ubicación, descripción,
capacidad, tamaño).
3. El Encargado de producción ingresa los
4. El Encargado de producción encuentra y 4.1 El Encargado de producción NO encuentra
selecciona al estanque a dar de baja. al estanque a dar de baja.
5. El Encargado de producción selecciona la
opción “Dar de Baja a estanque”.
6. El Encargado de producción confirma la 6.1 El encargado de producción cancela la
operación. operación.
7. El sistema da de baja al estanque.
Historia de cambios


Nombre del Use Case: Registrar clase de lote. Id: 96
Objetivo: Registrar una clase de lote que será utilizada para la clasificación de peces.
Precondiciones: Usuario logeado y con permisos para registrar clase de lote.
Poscondiciones:
Éxito:
• Clase de lote registrada.
Fracaso:
• Use Case cancelado porque los datos de la clase de lote no son correctos.
producción selecciona la opción “Clases de lotes”.
opción “Nueva Clase de lote”.
la clase de lote (Número, descripción).
4. El encargado de producción ingresa los datos de
la clase de lote.
operación.
operación.
8. El sistema registra a la nueva clase de lote.
Historia de cambios


Nombre del Use Case: Modificar clase de lote. Id: 97
Objetivo: Modificar los datos de una clase de lote.
Precondiciones: Usuario logeado y con permisos para modificar clase lote.
Poscondiciones:
Éxito:
• Clase de lote actualizada.
Fracaso:
clase de lote”.
correspondientes a la clase de lote (Descripción).
4. El usuario ingresa los datos correspondientes.
operación.
8. El sistema registra las modificaciones de la
clase de lote.
Historia de cambios

Clasificación e incubación: Diagrama de Clases
Resultado de Clasificacion
Estanque
estanqueDestino : Estanque
ubiacion cantidad
suSeguimiento : Seguimiento de estanque lote : Lote de peces
name clase : Clase de Lote
capacidad
tamaño registarResultado()
identificador consultarResultado()
descripcion obtenerLote()
fechadealta registrarClasificacion(lote, catidad, clase)
responsable : UsuarioSis
habilitacion : Habilitación de Lotes en Estanque *
planDeFaenamiento : Plan de Faenamiento y envasado
id
claseDeLote : Clase de Lote
especie : Especie
alimentarEstanque()
registarAlimentacion()
registarEstanque()
modificarEstanque()
consultar()
darDeBaja()
emitirPlanDeClasificación()
registrarClasificacion()
ListoParaFaena() *
emitirInformeDeSeguimiento()
habilitarEstanque()
controlarCondiciones()
registrarSolución()
registrarControlDeEstanque()
registrarEnfermedad()
registrarTratamiento()
consultarPlan()
0..* Seguimiento de Estanque
planesAplicados[] : Plan de alimentación

operarioACaro : UsuarioSis
enfermedadesOcurridas[] : Enfermedad
solucionesAplicadas[] : Soluciones de estanques
coleccionDeClasificaciones : Coleccion de Clasificaciones
generarPlanDeAlimentacion()
registrarAlimentacion()
consultarSeguimiento()
registrarSolucionAplicada()
consultarSolucionesAplicadas()
registrarEnfermedad()
consultarLotesActuales()
consultarPlanDeClasificacion()
registrarClasificacion(clase, fecha, cantidad, estanqueDestiono)
Coleccion de Estanques
estanques[] : Estanque
buscarEstanques(Número, ubicación, capacidad, tamaño)

seleccionarEstanque(id)
consultarEstanquesDisponibles(fecha : Fecha)
actualizarEstanque(estanque : estanque)
Gestor de Estanques
buscarEstanques()

Coleccion de Clasificaciones
0..* clasificaciones[] : Clasificacion

obtenerUltimaClasificacion()
Clasificacion
resultados[] : Resultados de Clasificacion

estanqueOrigen : Estanque
fecha
id
obtenerLotesActuales()
registrarClasificacion(clase, fecha, cantidad, estanqueDestino)
Lote de Peces
fecha
especie
loteDeOvas : Lote de Ovas
id
Gestor de Clasificacion
Interfaz de
Clasificacion estanqueSeleccionado : Estanque
buscarEstanques(Número, ubicación, capacidad, tamaño)

buscarEstanques(Número, ubicación, capacidad, tamaño) seleccionarEstanque(id)
seleccionarEstanque(id) registrarClasificacion(clase, estanqueDestino, fecha)
registrarClasificacion(EstanqueDestino, cantidad, clase, fecha)

Pegar aquí diagrama de clases de clasificacion e incubacion

Diagrama de transición de estados: Lote de ovas.
Regi strar Lote de Ovas
Pendiente a
Incubar
Regi strar Lote a Incubar
Incubando
Regi strar Creci miento de Ovas y Alevinos
Clasifi cado

Análisis del Paquete: compras
<<extend>> Compras
105- Emitir Orden de Pago
<<extend>>
33- Registrar pedido a prov eedor
107- Anular Orden de Pago
32- Consultar of ertas de prov eedor 34- Registrar recepcion de pedido

de prov eedor
135- Registrar Gasto

Encargado de
Compras 9- Registrar Pago
56- Registrar prov eedor
108- Anular Pago
102- Modif icar datos de prov eedor
137- Registrar Insumo

35- Registrar of ertas de prov eedor
138- Modif icar Insumo
103- Dar de baja a prov eedor

59- Consultar Pagos y Ordenes de
Pago
104- Consultar Prov eedores
139- Consultar Insumos

140- Dar de baja insumo 99- Registrar por autogestion
of ertas de prov eedor
155- Registrar Lote de Ovas

Prov eedor
100- Registrar por autogestion

Prov edor 101- Modif icar por autogestion
datos de prov eedor

Compras: Descripciones y diagramas de colaboración de análisis.

Nombre del Use Case: Registrar lote de ovas. Id: 155
Actor principal: Encargado de compras
Objetivo: Registrar lote de ovas
Precondiciones: Usuario logeado y con permisos para registrar lote de ovas.
Poscondiciones:
Éxito:
• Lote de ovas registrado.
Fracaso:
1. El Use Case comienza cuando encargado de
compras selecciona la opción Lote de ovas
2. El encargado de compras selecciona la opción
Nuevo Lote de Ovas.
lote (número, cantidad, estado, especie).
4. El encargado de compras ingresa los datos del
lote.
5. El encargado de compras confirma la
operación.
validos. son validos.
7. El sistema registra el lote de ovas.
Historia de cambios


Nombre del Use Case: Registrar pago Id: 9
Objetivo: Registrar un nuevo gasto.
Precondiciones: Usuario logeado y con permisos para registrar un nuevo pago.
Poscondiciones:
Éxito:
• Pago registrado.
Fracaso:
• Use case cancelado porque el encargado de compras cancela la operación.
• Use cancelado por datos inválidos.
1. El Use Case inicia cuando encargado de
compras selecciona la opción Pago.
Nuevo Pago.
parámetros de búsqueda (estado, monto, fecha de
vencimiento, fecha de generación, fecha de
pago ).
4. El encargado de compras ingresa los parámetros
de búsqueda.
6. El encargado de compras selecciona las
compras a pagar.
8. El encargado de compras para cada compra
ingresa el monto a pagar.
7. El sistema registrar el nuevo pago
Historia de cambios

Nombre del Use Case: Consultar oferta de proveedores Id: 32
Objetivo: Seleccionar la mejor oferta de proveedores
Precondiciones: Usuario logeado y con permisos para seleccionar ofertas
Poscondiciones:
Éxito:
• Mejor oferta seleccionada
Fracaso:


• Use case cancelado por no encontrar el insumo
• Use case cancelado por no encontrar ofertas para el insumo seleccionado.
compras selecciona la opción ofertas de
proveedores
2. El sistema solicita que ingrese los parámetros
de búsqueda del insumo del cual se desean
consultar las ofertas (marca, tipo, descripción,
código).
de búsqueda.
5. El encargado de compras busca y selecciona el 5.1 El encargado de compras no encuentra al
insumo. insumo.
Ver Ofertas.
7. El sistema consulta las ofertas realizadas por 7.1 El sistema consulta las ofertas realizadas
los proveedores para el insumo seleccionado y por los proveedores para el insumo
obtiene resultados. seleccionado y no obtiene resultados.
8. El sistema muestra para el insumo seleccionado
las mejores ofertas realizadas por los proveedores
de acuerdo al método utilizado (matriz de
homogenización).
Historia de cambios


Nombre del Use Case: Registrar proveedor Id: 56
Objetivo: Registrar la oferta realizada por un proveedor
Precondiciones: Usuario logeado y con permisos para registrar proveedor
Poscondiciones:
Éxito:
• Proveedor registrado
Fracaso:
compras selecciona la opción Proveedor
nuevo proveedor.
3. El sistema solicita que se seleccionen los datos
del nuevo proveedor( razón social, cuit, condición
iva, cargo, ingreso brutos, domicilio, teléfono,
mail)
nuevo proveedor.
5.El encargado de compras confirma la operación. 5.1 El encargado de compras cancela la
operación.
6. El sistema valido los datos ingresados. 6.1 El sistema valida los datos ingresados y no
son validos.
7. El sistema registrar el nuevo insumo.
Historia de cambios


Nombre del Use Case: Registrar recepción de pedido a proveedor Id: 34
Objetivo: Registrar la recepción de un pedido proveedor
Precondiciones: Usuario logeado y con permisos para registrar una recepcion
Poscondiciones:
Éxito:
• Recepción registrado
Fracaso:
• Use case cancelado por no obtener resultados de la busqueda.
• Use case cancelado por no encontrar el pedido.
• Use Case cancelado por extender a Use Case Emitir orden de Pago
compras selecciona la opción Pedidos por
proveedor.
nueva recepción de pedido.
3. El sistema solicita que se seleccionen los
parámetros de búsqueda del pedido ( insumo,
fecha de recepción, proveedor, estado).
de búsqueda.
6. El encargado de compras para cada pedido que 6.1 El encargado de compras no encuentra el
se encuentra pendiente de recepción busca y pedido.
selecciona al proveedor que esta entregando la 6.1.1 Se cancela el Use Case.
mercadería.
del pedido que llego.
8.El encargado de compras ingresa los datos del
pedido entrante(cantidad, precio , insumo)
9.El encargado de compras confirma la operación. 9.1 El encargado de compras cancela la
operación.
10.El sistema valida los datos ingresados y son 10.1 El sistema valida los datos ingresados y
validos. no son validos.
11.El sistema registrar el nuevo pago
12. El encargado de compras no genera orden de 12.1 El encargado de compras desea generar
pago a ese proveedor orden de pago.
12.1.1 Se extiende a Use Case Emitir orden
de pago.
Historia de cambios


Nombre del Use Case: Registrar oferta de proveedor Id: 35
Precondiciones: Usuario logeado y con permisos para seleccionar ofertas
Poscondiciones:
Éxito:
• Oferta de proveedor registrada
Fracaso:
• Use case cancelado por no encontrar el proveedor.
compras selecciona la opción Ofertas de
proveedores
nueva oferta.
3. El sistema solicita que se seleccione el
proveedor.
3. El encargado de compras busca al proveedor y 3.1 El encargado de compras no encuentra al
lo selecciona. proveedor.
la oferta del proveedor (insumo, precio, cantidad,
fecha de validez).
5. El encargado de compras ingresa los datos
solicitados.
operación.
7. El sistema verifica la validez de los datos 7.1 El sistema verifica la validez de los datos
ingresados y son validos. ingresados y no son validos.
8. El sistema registra la oferta del proveedor.
Historia de cambios


Nombre del Use Case: Registrar proveedor Id: 56
Precondiciones: Usuario logeado y con permisos para registrar proveedor
Poscondiciones:
Éxito:
• Proveedor registrado
Fracaso:
compras selecciona la opción Proveedor
nuevo proveedor.
3. El sistema solicita que se seleccionen los datos
del nuevo proveedor( razón social, cuit, condición
iva, cargo, ingreso brutos, domicilio, teléfono,
mail)
nuevo proveedor.
5. El encargado de compras confirma la 5.1 El encargado de compras cancela la
6. El sistema valido los datos ingresados. 6.1 El sistema valida los datos ingresados y no
son validos.
Historia de cambios


Nombre del Use Case: Consultar pagos y órdenes de pago. Id: 59
Objetivo: Consultar pagos y sus ordenes
Precondiciones: Usuario logeado y con permisos para consultar pagos y ordenes de pago.
Poscondiciones:
Éxito:
• Pagos y órdenes de pagos consultadas.
Fracaso:
compras selecciona la opción Pago
2. El sistema solicita que se seccione la opción
consultar Pagos o consultar ordenes de pagos
deseada.
de búsqueda para la opción deseada
de búsqueda.
5. El sistema muestra los datos de la opción
consultada.
Historia de cambios


Nombre del Use Case: Registrar por auto gestión oferta de proveedor. Id: 99
Actor principal: Proveedor
Objetivo: Registrar oferta del proveedor a través de la auto gestión
Precondiciones: Usuario logeado y con permisos para usar auto gestión
Poscondiciones:
Éxito:
• Oferta de proveedores actualizadas.
Fracaso:
• Use Case cancelado por no encontrar el proveedor.
• Use Case cancelado por no confirmar la operación.
1. El Use Case comienza, cuando el proveedor
selecciona la opción registrar ofertas, desde la
pagina web del negocio.
2. El sistema solicita el password y nombre de
usuario.
3. El proveedor ingresa su nombre y password.
5. El usuario selecciona la opción registrar oferta
la oferta de ese proveedor (precio, cantidad,
insumo).
7. El usuario ingresa los datos de su oferta.
8. El sistema valida los datos ingresado 8.1 El sistema valida los datos ingresados y no
son validos.
9. El sistema registra la nueva oferta.
Historia de cambios


Nombre del Use Case: Registrar por auto gestión proveedor. Id: 100
Objetivo: Registrar proveedor a través de la auto gestión
Poscondiciones:
Éxito:
• Proveedor registrado.
Fracaso:
1. El Use Case comienza, cuando el proveedor
selecciona la opción registrar proveedor.
2. El sistema solicita el password y nombre de
usuario del proveedor.
3. El proveedor ingresa su nombre y password.
4. El sistema valida los datos y son validos. 4.1 El valida los datos y no son validos.
5. El proveedor selecciona la opción Nuevo
proveedor.
proveedor (razón social, CUIT, condición de IVA,
ingresos brutos, domicilio, teléfono, mail, nombre
de usuario, contraseña).
7. El proveedor ingresa sus datos.
8. El proveedor confirma la operación. 8.1 El proveedor cancela la operación.
9. El sistema valida los datos ingresado y son 9.1 El sistema valida los datos ingresados y no
10. El sistema registra al proveedor.
Historia de cambios


Nombre del Use Case: Modificar por auto gestión datos del proveedor. Id: 101
Objetivo: Modificar los datos del proveedor a través de la auto gestión.
Poscondiciones:
Éxito:
• Proveedor modificado.
Fracaso:
1. El Use Case comienza cuando el proveedor
selecciona la opción proveedores.
3. El proveedor ingresa los datos solicitados.
5. El sistema muestra los datos del proveedor que
inicio la sesión (razón social, cuit, condición iva,
domicilio, teléfono, mail, password, nombre de
usuario).
6. El proveedor selecciona la opción Modificar
Datos.
7 El sistema solicita que se ingresen los nuevos
datos del proveedor.
8. El proveedor ingresa los datos.
9. El proveedor confirma la operación. 9.1 El proveedor cancela la operación.
11. El sistema actualiza los datos del proveedor.
12 Fin del Use Case.
Historia de cambios


Nombre del Use Case: Modificar datos del proveedor. Id: 102
Objetivo: Modificar los datos de un proveedor existente
Precondiciones: Usuario logeado y con permisos para poder modificar datos de un proveedor
Poscondiciones:
Éxito:
• Proveedor actualizado.
Fracaso:
• Use Case cancelado por no existir el proveedor a modificar.
• Use Case cancelado porque el enc. de compras no encuentra al proveedor
compras selecciona la opción Proveedores.
y número de documento, mail, condición IVA,
CUIT
de búsqueda.
5. El encargado de compras encuentra y 5.1 El encargado de compras NO encuentra al
selecciona al proveedor a modificar. proveedor a modificar.
“Modificar Proveedor”.
6. El encargado de compras modifica los datos del
cliente (razón social, dirección, teléfono, mail,
condición de IVA, CUIT).
operación.
8. El sistema actualiza los datos del proveedor
Historia de cambios


Nombre del Use Case: dar de baja a proveedor. Id: 103
Objetivo: dar de baja a un proveedor existente
Precondiciones: Usuario logeado y con permisos para poder modificar datos de un proveedor
Poscondiciones:
Éxito:
• Proveedor dado de baja.
Fracaso:
• Use Case cancelado por no existir el proveedor a modificar.
• Use case cancelado por no encontrar resultados de la búsqueda.
compras selecciona la opción Proveedores.
del proveedor (razón social, CUIL).
de búsqueda.
5. El encargado de compras encuentra y 5.1 El encargado de compras NO encuentra al
selecciona al proveedor a dar de baja. proveedor a dar de baja.
“Dar de baja Proveedor”.
8. El sistema da de baja al proveedor.
Historia de cambios


Nombre del Use Case: Consultar proveedores. Id: 104
Objetivo: Consultar los datos de los insumos existentes
Precondiciones: Usuario logeado y con permisos para poder consultar proveedores
Poscondiciones:
Éxito:
• Proveedores consultados.
Fracaso:
compras selecciona la opción Proveedores
del proveedor (razón social, cuit, teléfono, mail).
3. El encargado de compra ingresa los parámetros
de búsqueda
búsqueda.
Historia de cambios


Nombre del Use Case: Emitir orden de pago. Id: 105
Objetivo: emitir orden de pago
Precondiciones: Usuario logeado y con permisos para poder registrar orden de pago
Poscondiciones:
Éxito:
• Orden de pago registrada y emitida
Fracaso:
• Use Case cancelado por no existir el proveedor.
• Use case cancelado por que no se le adeudan pedidos al proveedor.
• Use case cancelado porque no se incluyen pedidos en la orden de pago.
compras selecciona la opción Orden de pago.
2. El encargado de compra selecciona la opción
Nueva Orden de Pago
3. El sistema solicita que se ingrese el proveedor.
4. El encargado de compras busca al proveedor, lo 3.1 El encargado de compras busca y no
encuentra y lo selecciona. encuentra al proveedor.
5. El sistema busca los pedidos del proveedor cuyo 4.1 El sistema busca los pedidos del
estado es pendiente de pago, obtiene resultados y proveedor cuyo estado es pendiente de pago
los muestra. y no obtiene resultados.
6. El sistema solicita que se seleccionen los
pedidos del proveedor a pagar.
7. El encargado de compras selecciona los pedidos
del proveedor que se desea pagar.
pagar.
9.1.1Se cancela el Use Case
10. El sistema valida que se incluyan pedidos en la 10.1 El sistema valida que se incluyan
orden de pago y se incluyen pedidos. pedidos en la orden de pago y no se incluyen
pedidos.
11. El sistema registra la orden de pago.
12. El sistema emita la orden de pago.
Historia de cambios


Nombre del Use Case: Anular orden de pago. Id: 107
Objetivo: Emitir orden de pago
Precondiciones: Usuario logeado y con permisos para poder anular orden de pago
Poscondiciones:
Éxito:
• Orden de pago anulada
Fracaso:
• Use Case cancelado por no existir la orden de pago.
• Use case cancelado porque el encargado de compras no encuentra la orden de pago.
• Use case cancelado porque encargado de compras cancela la operación.
compras selecciona la opción Orden de pago.
2. El sistema solicita que se ingrese los
parámetros de búsqueda ( fecha de emisión ,
proveedor)
3. El encargado de compras ingresa los datos
solicitados.
4. El sistema realiza la búsqueda y muestra el 4.1 El sistema busca las ordenes de pago y
resultado no obtiene resultados.
5. El sistema solicita que se seleccione la orden de
pago a anular.
6. El encargado de compras busca y selecciona la 6.1 El encargado de compras no encuentra la
orden de pago. orden de pago
6.1.1 Se cancela el Use Case
anular orden de pago.
8.1.1 Use Case cancelado.
9. El sistema anula la orden seleccionada
Historia de cambios


Nombre del Use Case: Anular pago Id: 108
Objetivo: Anular un nuevo pago existente
Precondiciones: Usuario logeado y con permisos para anular un pago.
Poscondiciones:
Éxito:
• Pago anulado.
Fracaso:
• Use case cancelado por no obtener resultados del a búsqueda.
• Use Case cancelado porque encargado de compras no encuentra pago.
compras selecciona la opción Pagos.
anular Pago.
parámetros de búsqueda (fecha de pago, monto,
cobrador, numero de pago ).
de búsqueda.
6. El encargado de compras busca y selecciona los 6.1 El encargado de compras no encuentra el
pagos que ya se realizaron y que coinciden con los pago.
parámetros de búsqueda. 6.1.1 Se cancela el use case.
8. El encargado de compras selecciona el pago
que será anulado.
9. El sistema solicita que se ingrese el motivo por
el cual será anulado el pago.
10. El encargado de compras ingresa los motivos.
anular pago.
7. El sistema anula el pago.
Historia de cambios


Nombre del Use Case: Registrar gasto Id: 135
Objetivo: Registrar un nuevo gasto.
Precondiciones: Usuario logeado y con permisos para registrar un nuevo gasto.
Poscondiciones:
Éxito:
• Gasto registrado.
Fracaso:
compras selecciona la opción Registrar Gasto.
Nuevo Gasto.
gasto (descripción, fecha, monto, operario).
gasto.
7. El sistema registrar el nuevo gasto.
Historia de cambios


Nombre del Use Case: Registrar insumo Id: 137
Objetivo: Registrar un insumo.
Precondiciones: Usuario logeado y con permisos para registrar un insumo.
Poscondiciones:
Éxito:
• Insumo registrado.
Fracaso:
compras selecciona la opción Insumos.
Nuevo Insumo.
insumo (nombre, marca, precio, tipo,
descripción).
insumo.
Historia de cambios


Nombre del Use Case: Modificar datos del insumo Id: 138
Objetivo: Modificar los datos de un proveedor existente
Precondiciones: Usuario logeado y con permisos para poder modificar datos de un insumo
Poscondiciones:
Éxito:
• Insumo actualizado.
Fracaso:
• Use Case cancelado por no existir el insumo a modificar.
• Use Case cancelado por no obtener resultado en la búsqueda.
compras selecciona la opción Insumo.
del insumo (nombre, marca, precio, tipo,
descripción)
de búsqueda.
5. El encargado de compras encuentra y 5.1 El encargado de compras NO encuentra el
selecciona el insumo a modificar. insumo a modificar.
“Modificar Insumo”.
6. El encargado de compras modifica los datos del
insumo(nombre, marca, precio, tipo, descripción)
operación.
8. El sistema actualiza los datos del insumo
Historia de cambios


Nombre del Use Case: Consultar insumo. Id: 139
Objetivo: Consultar los datos de los insumos existentes
Precondiciones: Usuario logeado y con permisos para poder consultar insumos
Poscondiciones:
Éxito:
• Insumos consultados.
Fracaso:
• Use Case cancelado por no encontrar el insumo.
compras selecciona la opción Insumos
del insumo (precio, tipo, marca, alimento).
3. El encargado de compra ingresa los parámetros
de búsqueda
búsqueda.
Historia de cambios


Nombre del Use Case: Dar de baja al insumo. Id: 140
Objetivo: Dar de baja a un insumo
Precondiciones: Usuario logeado y con permisos para dar de baja al insumo
Poscondiciones:
Éxito:
• insumo dado de baja.
Fracaso:
• Use Case cancelado por no existir el insumo a dar de baja.
• Use case cancelado porque encargado de compras no encuentra el insumo
compras selecciona la opción Insumos
del insumo (marca, tipo, identificador).
3. El encargado de copras ingresa los parámetros
de búsqueda.
5. El encargado de compras busca al insumo, lo 5.1 El encargado de compras NO encuentra el
encuentra y lo selecciona. insumo a dar de baja.
“Dar de baja a insumo”.
operación.
8. El sistema da de baja al insumo.
Historia de cambios

Compras: Diagrama de Clases
Pegar aquí, diagrama de clases de compras

Pedido a proveedor: Diagrama de transición de estados
Regi strar Pedido a Proveedor pedi do
pagado
Emitir orden de de pago
pendiente de
pago
Regi strar recepci on de pedido a proveedor

Anular Pedido A Proveedor
anul ado
entregado

Análisis del Paquete: Enfermedades y control de

Estanques
Enfermedades y control de
estanques
105- Emitir Orden de Pago 26- Registrar Veterinario

<<extend>>
(from Compras)
<<extend>>
143- Dar de baja Veterinario
117- Registrar Solución

8- Registrar habilitación de lotes de 17- Registrar solución aplicada a
peces en estanque estanque
142- Modificar Veterinario
16- Consulta soluciones
recomendadas a estanque
119- Dar de baja a solución

115- Consultar enfermedades y
tratamientos
15- Registrar control de estanque
110- Dar de baja tratamiento de

enfermedad
130- Emitir plan de control de

estanques. Encargado de
Producción 111- Modificar Tratamiento de
enfermedad
42- Emitir informe de seguimiento

de estanques
109- Registrar parámetros de

control de estanque.
19- Registrar tratramientos aplicados a

enfermedades y resultados
128- Consultar y modificar

parametros de control
118- Alertar por desviacion en

condiciones de estanques.
129- Dar de baja a parametros de

control
18- Consultar base de conocim iento
de enfermedades
116- Registrar estado de sensores
113- Modificar enfermedades No olvidar agendar en

cada caso de uso,
Alerta electronica, informacion de auditorioa
mail sms, u otras. de que lote y quienes
114- Dar de baja enfermedad 112- Registrar enfermedad intervinieron.

Enfermedades y control de Estaques.: Descripciones y diagramas

de colaboración de análisis.

Nombre del Use Case: Dar de baja a veterinario. Id: 143
Objetivo: Dar de baja a un veterinario.
Precondiciones: Usuario logeado y con permisos para dar de baja al veterinario.
Poscondiciones:
Éxito:
• Veterinario dado de baja.
Fracaso:
• Use Case cancelado por no existir el veterinario a dar de baja.
producción selecciona la opción Veterinarios.
de los veterinarios (nombre, apellido, matricula).
selecciona al veterinario a dar de baja. al veterinario a dar de baja.
opción “Dar de Baja a veterinario”.
7. El sistema da de baja al veterinario.
Historia de cambios


Nombre del Use Case: Registrar habilitación de lotes de
Peces en estanques. Id: 8
Objetivo: Cuando un control fue exitoso y aprobado por un veterinario esto se registra.
Precondiciones: Usuario logeado y con permisos para registrar habilitación de lotes de peces en
estanques.
Poscondiciones:
Éxito:
• Habilitación de lotes de peces en estanques registrados.
Fracaso:

habilitación de lotes de peces en estanque”
de control) mostrando solo aquellos que tienen un
control registrado.
estanque al cual se le registrará la habilitación.
“cancelar”).
registrará la habilitación.
7. El sistema consulta los datos de los controles
aplicados al estanque y de los veterinarios y
solicita al usuario que ingrese los datos de la
habilitación del estanque (fecha, encargado,
control aplicado, veterinario responsable).
operación.
10. El sistema valida los datos y estos son 10.1 El sistema valida los datos y estos no son
correctos. correctos.
11. El sistema registra la habilitación de lote de
peces en estanque.
12. Fin del UC.
Historia de cambios


Nombre del Use Case: Registrar control de estanque. Id: 15
Objetivo: Registrar el control que se le realizó a un estanque determinado.
Precondiciones: Usuario logeado y con permisos para registrar control de estanque.
Poscondiciones:
Éxito:
• Control de estanques registrado.
Fracaso:
producción selecciona la opción “Registrar control
de estanque”
mantenimiento.
estanque al cual se le registrará el control.
“cancelar”).
registrará el control.
clasificación asignado al estanque seleccionado
(Estanque, lote de peces actuales, fecha de
vigencia, fecha de próximo control, operario
responsable, valores de control esperados) y del
seguimiento del mismo (población del estanque,
último control aplicado).
seguimiento de estanques y planes de control
antes consultados ordenándolos de acuerdo a la
fecha de próximo control esperado.
datos del control realizado.
10. El usuario ingresa los datos del control (Fecha,
operario a cargo, parámetros controlados, valor
obtenido para cada parámetro).
10. El sistema compara los datos ingresados con
los esperados de acuerdo al plan de control.
11. los datos ingresados son correspondientes al 11.1 Los datos ingresados no son
plan. correspondientes al plan, el sistema alerta la
desviación.
11.1.1 El usuario cancela la operación
11.1.1.1 Se cancela el UC.
11.1.2 El usuario modifica los datos

deseados.( sigue en punto 12)

11.1.3 El usuario selecciona no modificar

registración (sigue en punto 12).

operación.
13.1.1 Fin del UC.
14. El sistema registra el nuevo control,
actualizando el seguimiento del estanque (fecha,
resultado del control) y el resultado del control
(estanque, fecha, parámetros, valores obtenidos
para cada parámetro) del lote correspondiente.
15. Fin del UC.
Historia de cambios


Nombre del Use Case: Consultar soluciones recomendadas a estanques Id: 16
Objetivo: Consultar posibles soluciones para un problema encontrado referente a un parámetro de
control.
Precondiciones: Usuario logeado y con permisos para consultar soluciones recomendadas a
estanques.
Poscondiciones:
Éxito:
• Soluciones consultadas.
Fracaso:
1. El use case comienza cuando el encargado de
producción selecciona la opción “Soluciones”
de las soluciones (nombre parámetro de control,
operario)
3. El usuario ingresa los parámetros de búsqueda
de las soluciones.
operación.
6. El sistema en base a los parámetros ingresados
consulta los datos de la base de conocimiento
(parámetro de control, soluciones), de las
soluciones (problema que ataca, insumo, dosis,
periodo, descripción).
7. El sistema muestra la información consultada
anteriormente sugiriendo una solución.
8. fin del UC.
Historia de cambios


Nombre del Use Case: Registrar solución aplicada a estanque Id: 17
Objetivo: Registrar cunado se detecta un parámetro de control
Precondiciones: Usuario logeado y con permisos para registrar solución aplicada.
Poscondiciones:
Éxito:
• Estanques consultados.
Fracaso:
Solución aplicada a estanque”.
(Número, estado) y muestra los estanques que
están en mantenimiento.
estanque al cual se le aplico la solución.
4. El usuario selecciona el estanque al cual se le 4.1 El usuario cancela la operación.
aplico la solución. 4.1.1 Se cancela el UC.
parámetros de búsqueda de soluciones aplicadas
(problema que ataca, insumo, dosis, periodo).
6. El usuario interesa los parámetros de búsqueda
de soluciones aplicadas.
7. El sistema consulta y muestra los datos los
datos de las soluciones aplicadas en base a los
8. La solución aplicada ya existe. 8.1 La solución no existe.
8.1.1 Se extiende el UC. “Registrar solución”
9. El sistema actualiza los datos del seguimiento
del estanque (soluciones aplicadas).
10. Fin del UC.
Asociaciones de extensión: “Registrar solución”
Historia de cambios


Nombre del Use Case: Consultar base de conocimiento de enfermedades Id: 18
Objetivo: Consultar posibles soluciones a una enfermedad de acuerdo a los tratamientos que se
encuentran en la base de conocimientos.
Precondiciones: Usuario logeado y con permisos para consultar base de conocimientos de
enfermedades.
Poscondiciones:
Éxito:
• Posible solución encontrada.
Fracaso:
• Posible solución no encontrada.
producción selecciona la opción “Consular
soluciones de enfermedades”
de las enfermedades (nombre enfermedad,
síntomas, efectos)
3. El usuario ingresa los parámetros de búsqueda
de las enfermedades.
operación.
6. El sistema en base a los parámetros ingresados
consulta los datos de la base de conocimiento
(Enfermedad, tratamientos), y de las tratamientos
existentes para esa enfermedad (Medicamentos,
dosis, actividades, tiempo de solución,
resultados).
7. El sistema muestra la información consultada 7.1 El sistema no encuentra un tratamiento
anteriormente sugiriendo un Tratamiento. para esa enfermedad.
8. fin del UC.
Historia de cambios


Nombre del Use Case: Registrar tratamientos
aplicados a enfermedades y resultados Id: 19
Objetivo: Registrar la enfermedad encontrada y el tratamiento aplicado.
Precondiciones: Usuario logeado y con permisos para registrar tratamiento aplicado a
enfermedad.
Poscondiciones:
Éxito:
• Tratamiento registrado.
Fracaso:
tratamiento de enfermedad”
mantenimiento.
estanque al cual se le registrará el tratamiento.
“cancelar”).
registrará un Tratamiento.
7. El sistema consulta los datos de las
enfermedades (nombre, síntoma) y solicita al
usuario que ingrese los datos del tratamiento
aplicado (Nombre, Enfermedad que ataca,
medicamentos, dosis, operario que lo realizo,
fecha, actividades, resultados, tiempo).
8. El usuario ingresa los datos del tratamiento.
son correctos. estos NO son correctos.
10.- El sistema registra el nuevo tratamiento.
Historia de cambios


Nombre del Use Case: Registrar veterinario. Id: 26
Objetivo: Registrar un veterinario que será utilizada para control de los estanques.
Precondiciones: Usuario logeado y con permisos para registrar veterinario.
Poscondiciones:
Éxito:
• Veterinario registrado.
Fracaso:
• Use Case cancelado porque los datos del veterinario no son correctos.
producción selecciona la opción “Veterinarios”.
opción “Nuevo Veterinario”.
veterinario (Nombre, Apellido, matricula,
teléfono, dirección, correo electrónico).
4. El encargado de producción ingresa los datos
del veterinario.
operación.
operación.
8. El sistema registra al nuevo veterinario.
Historia de cambios


Nombre del Use Case: Emitir informe de seguimiento de estanques. Id: 42
Objetivo: Emitir un informe de los estanques mostrando el porcentaje de las clases de los
estanques que contiene y el rendimiento de los mismos.
Precondiciones: Usuario logeado y con permisos para emitir informe de seguimiento de estanque.
Poscondiciones:
Éxito:
• Informe de seguimiento de estanque emitido.
Fracaso:
producción selecciona la opción “Emitir informe
de seguimiento de estanques”
(Número, Ubicación, Capacidad, población)
3. El sistema muestra pos pantalla los datos de los
estanques seleccionados.
estanque del cual se quiere obtener el informe.
5. El usuario selecciona el estanque del cual se 5.1 El usuario selecciona cancelar.
quiere obtener el informe. 5.1.1 Se cancela el UC.
estanque seleccionado (Número, Ubicación,
Capacidad, población)
operación.
seleccionado (Número, Ubicación, Capacidad,
Población, Su seguimiento), los datos del
seguimiento del mismo (lotes actuales, Resultados
de clasificación), de los resultados de clasificación
(fecha, especie, clase de acuerdo a la calidad,
clase de acuerdo al tamaño, cantidad) y de los
parámetros de clasificación (especie, relación
edad/tamaño).
10. El sistema determina las proporciones de las
clases de los estanques existentes en el estanque
teniendo en cuenta el resultado de clasificación
con fecha más reciente (el último) y sumando las
cantidades de este resultado.
11. El sistema compara los datos de los resultados
de Clasificación (Fecha, especie, clase de acuerdo
al tamaño) con los parámetros de clasificación
(especie, relación edad/tamaño) calculando las
diferencias de rendimiento.
12. El sistema acumula las cantidades de los
resultados de clasificación teniendo en cuenta la
clase de acuerdo a la calidad.
13. El sistema genera un informe conteniendo:
Estanque, Proporción de cada clase de acuerdo a
tamaño, proporción de cada clase de acuerdo a la
calidad, diferencias entre el rendimiento esperado

y el real (Calculado en el punto 11).

14. El sistema muestra por pantalla el resultado
del informe.
15. Fin del UC.
Historia de cambios

Nombre del Use Case: Registrar parámetros de
Control de estanque. Id: 109
Objetivo: Registrar parámetros para el correcto control de los estanques.
Precondiciones: Usuario logeado y con permisos para registrar parámetros de control de
estanque.
Poscondiciones:
Éxito:
• Parámetros de control de estanque cargados.
Fracaso:
Parámetros de control de estanque”.
correspondientes al parámetro de control de
estanque (Nombre parámetro, Unidad de medida,
Especie involucrada, valor mínimo, valor máximo,
valor óptimo).
los parámetros de control de estanque.
operación.
8. El sistema registra el nuevo parámetro de
control de estanque.
Historia de cambios


Nombre del Use Case: Dar de baja a tratamiento de enfermedad. Id: 110
Objetivo: Dar de baja a un tratamiento de enfermedad.
Precondiciones: Usuario logeado y con permisos para dar de baja al tratamiento de enfermedad.
Poscondiciones:
Éxito:
• Tratamiento de enfermedad dada de baja.
Fracaso:
• Use Case cancelado por no existir el tratamiento de enfermedad a dar de baja.
1. El UC Comienza, cuando el Encargado de
producción selecciona la opción Tratamientos de
enfermedades.
de los tratamientos de enfermedades
(enfermedad que ataca, fecha, encargado,
actividades).
selecciona al tratamiento de enfermedad a dar de al tratamiento de enfermedad a dar de baja.
baja. 4.1.1 Se cancela el Use Case.
opción “Dar de Baja a tratamiento de
enfermedad”.
7. El sistema da de baja al tratamiento de
enfermedad.
Historia de cambios


Nombre del Use Case: Modificar tratamiento de enfermedad. Id: 111
Objetivo: Modificar los datos de un tratamiento de enfermedad.
Precondiciones: Usuario logeado y con permisos para modificar tratamiento de enfermedad.
Poscondiciones:
Éxito:
• Tratamiento de enfermedad actualizado.
Fracaso:
tratamiento de enfermedad”.
correspondientes al tratamiento de enfermedad
(Nombre, Enfermedad, medicamentos, dosis,
operario, actividades, fecha, resultados, tiempo
de solución).
4. El usuario ingresa los datos correspondientes.
operación.
tratamiento de enfermedad.
Historia de cambios


Nombre del Use Case: Registrar enfermedad. Id: 112
Objetivo: Registrar una enfermedad que será tratada en los estanques.
Precondiciones: Usuario logeado y con permisos para registrar enfermedad.
Poscondiciones:
Éxito:
• Enfermedad registrada.
Fracaso:
• Use Case cancelado porque los datos de la enfermedad no son correctos.
producción selecciona la opción “Enfermedades”.
opción “Nueva Enfermedad”.
la enfermedad (nombre, nombre científico,
causas, síntomas, efectos).
4. El encargado de producción ingresa los datos de
la enfermedad.
operación.
operación.
8. El sistema registra a la nueva enfermedad.
Historia de cambios


Nombre del Use Case: Modificar enfermedad. Id: 113
Objetivo: Modificar los datos de una enfermedad existente.
Precondiciones: Usuario logeado y con permisos para modificar datos de la enfermedad.
Poscondiciones:
Éxito:
• Enfermedad actualizada.
Fracaso:
• Use Case cancelado por no existir el enfermedad a modificar.
producción selecciona la opción Enfermedades.
de la enfermedad (nombre, nombre científico,
síntomas, efectos, causas).
selecciona a la enfermedad a modificar. a la enfermedad a modificar.
opción “Modificar enfermedad”.
operación.
8. El sistema actualiza los datos de la
enfermedad.
Historia de cambios


Nombre del Use Case: Dar de baja a enfermedad. Id: 114
Objetivo: Dar de baja a un enfermedad existente.
Precondiciones: Usuario logeado y con permisos para dar de baja a enfermedad.
Poscondiciones:
Éxito:
• Enfermedad dada de baja.
Fracaso:
• Use Case cancelado por no existir la enfermedad a dar de baja.
producción selecciona la opción Enfermedades.
de las enfermedades (nombre, nombre científico,
selecciona a la enfermedad a dar de baja. a la enfermedad a dar de baja.
opción “Dar de Baja a enfermedad”.
7. El sistema da de baja a la enfermedad.
Historia de cambios


Nombre del Use Case: Consultar enfermedades y tratamientos. Id: 115
Objetivo: Consultar los datos de las enfermedades y los tratamientos correspondientes realizados.
Precondiciones: Usuario logeado y con permisos para consultar enfermedades y tratamientos.
Poscondiciones:
Éxito:
• Enfermedades y tratamientos consultados.
Fracaso:
producción selecciona la opción “Enfermedades y
tratamientos”.
operación.
6. El sistema consulta los datos de las
enfermedades existentes de acuerdo a los
parámetros de búsqueda ingresados y consulta los
datos de todos los tratamientos realizados
correspondientes a las enfermedades consultadas
(Nombre, fecha, encargado, operario,
medicamentos, dosis, actividades, resultados,
tiempo de solución).
consultados
Historia de cambios


Nombre del Use Case: Registrar estado de sensores Id: 116
Objetivo: registrar la clasificación de los lotes.
Precondiciones: Usuario logeado y con permisos para registrar estado de los sensores.
Poscondiciones:
Éxito:
• Estado del sensor registrado.
Fracaso:
1. El UC. Comienza cuando el Encargado de
producción selecciona la opción “Registrar estado
de los censores”.
2. El sistema consulta y muestra los datos de los
censores existentes (Identificador, parámetro de
control que controla y solicita al usuario que
seleccione el sensor del cual desea que se registre
el estado.
3. El usuario selecciona el sensor del cual quiere 3.1 El usuario selecciona cancelar.
registrar el estado. 3.1.1 Se cancela el UC.
4. El sistema consulta los últimos datos tomados
por el sensor (que lo hace periódicamente) y los
datos del parámetro de control que controla
(Valor mínimo, valor máximo, valor optimo)
tomados por el sensor alertando al usuario en caso
de diferencia con el parámetro de control
correspondiente.
6. Fin del UC.
Use Case al que se extiende: No aplica
Historia de cambios


Nombre del Use Case: Registrar solución Id: 117
Objetivo: Registrar una solución que será aplicada en los controles.
Precondiciones: Usuario logeado y con permisos para registrar solución.
Poscondiciones:
Éxito:
• Solución registrada.
Fracaso:
soluciones”.
datos de la nueva solución (problemas que ataca,
insumos requeridos, dosis, periodo y descripción)
3. El usuario ingresa los datos de la solución.
operación.
6. El sistema valida los datos y estos son 6.1 El sistema valida los datos y estos no son
correctos. correctos.
6.1.2 Fin del UC.
6. El sistema registra la nueva solución.
7. Fin del UC.
Historia de cambios


Nombre del Use Case: alertar por desviación en
Condiciones de estanques. Id: 118
Objetivo: Alertar en caso de desviaciones con respecto a los parámetros de control.
Precondiciones: Datos de sensor recibido
Poscondiciones:
Éxito:
• Desviaciones alertadas.
Fracaso:
1. El use case comienza cuando el sistema detecta
desviación entre un parámetro de control de
estanque y un dato tomado por el sensor de un
estanque.
2. El sistema consulta los datos del parámetro de
control correspondiente (nombre parámetro, valor
optimo, valor mínimo, unidad de medida).
3. El sistema calcula las diferencias existentes y
genera un informe de la situación conteniendo
(fecha, hora, descripción)
4. El sistema envía vía mail o mensaje de texto el
informe generado.
5. Fin del UC.
Historia de cambios


Nombre del Use Case: Dar de baja a solución. Id: 119
Objetivo: Dar de baja a una solución existente.
Precondiciones: Usuario logeado y con permisos para dar de baja a solución.
Poscondiciones:
Éxito:
• Solución dada de baja.
Fracaso:
• Use Case cancelado por no existir la solución a dar de baja.
producción selecciona la opción Soluciones.
de las soluciones (nombre, nombre científico,
selecciona a la solución a dar de baja. a la solución a dar de baja.
opción “Dar de Baja a solución”.
7. El sistema da de baja a la solución.
Historia de cambios


Nombre del Use Case: Consultar y modificar Parámetros de control
de clasificación. Id: 128
Objetivo: Modificar parámetros para el control de los estanques.
Precondiciones: Usuario logeado y con permisos para modificar Parámetros de control de
estanques.
Poscondiciones:
Éxito:
• Parámetros de control actualizados.
Fracaso:
Parámetros de control”.
correspondientes al parámetro de control
(Nombre parámetro, valor optimo, valor mínimo,
valor máximo, unidad de medida).
los parámetros de control.
operación.
parámetro de control.
Historia de cambios


Nombre del Use Case: Dar de baja a parámetro de control. Id: 129
Objetivo: Dar de baja a un parámetro de control.
Precondiciones: Usuario logeado y con permisos para dar de baja a parámetro control.
Poscondiciones:
Éxito:
• Parámetro de control dado de baja.
Fracaso:
a parámetro de control”.
control existentes.
consultados.
parámetro de control a dar de baja.
5. El usuario selecciona el parámetro de control al 5.1 El usuario selecciona “Cancelar”
cual se le desea dar de baja. 5.1.1 Se cancela el UC.
operación.
8. El sistema da de baja al parámetro de control.
9. Fin del U.C.
Historia de cambios


Nombre del Use Case: Emitir plan de control de estanque. Id: 130
Objetivo: Emitir un plan para el seguimiento y el control de un estanque.
Precondiciones: Usuario logeado y con permiso para generar plan de control de estanque.
Poscondiciones:
Éxito:
• Plan de control de estanque generado.
Fracaso:
• Cancelado por datos incorrectos.
de producción) selecciona la opción Generar Plan
de Control de estanque.
2. El sistema consulta los datos de los estanque.
en pantalla.
4. El sistema solicita al usuario que selección el
estanque al cual se le generara el plan de control.
5. El usuario selecciona el estanque del cual
quiere generar el plan.
6. El sistema le solicita al usuario ingrese los datos
del plan de control de estanque (Fecha,
parámetros a medir, encargado, resultado
esperado, resultado de medición)
7. El usuario ingresa los datos del plan de control.
9. El sistema registra el nuevo plan de control.
10. Fin del UC.
Historia de cambios


Nombre del Use Case: Modificar datos del veterinario. Id: 142
Objetivo: Modificar los datos de un veterinario existente.
Precondiciones: Usuario logeado y con permisos para poder modificar datos del veterinario.
Poscondiciones:
Éxito:
• Veterinario actualizado.
Fracaso:
• Use Case cancelado por no existir el veterinario a modificar.
producción selecciona la opción Veterinarios.
del veterinario (Nombre, apellido, matricula).
selecciona al veterinario a modificar. al veterinario a modificar.
opción “Modificar veterinario”.
del veterinario (nombre, apellido, matricula,
teléfono, dirección, correo electrónico).
operación.
8. El sistema actualiza los datos del veterinario.
Historia de cambios

Enfermedades y control de estanques: Diagrama de Clases
Pegar aquí, enfermedades y control de estanques.

Análisis del Paquete: Faenamiento y envasado
Faenamiento y
env asado
121- Emitir listado de asignacion de
47- Dar de baja operario tareas y equipos
122- Consultar T areas y equipos
45- Registrar operario

<<extend>>
46- Modificar datos operari o
120- Registrar asignacion de tareas

Encargado de
a operari os
Faenamient...
22- Consultar operari os y

disponibilidad <<extend>>
23- Emitir listado de estanques a

faenar 106- Registrar tarea y equipos
141- Generar Plan de Faenamiento

y Envasado 24- Registar resultado del
faenamiento y envasado
124- Modificar T area y equipos
123- Dar de baja tarea y equipos

Faenamiento y envasado: Descripciones y diagramas de


Nombre del Use Case: Generar plan de faenamiento y envasado. Id: 141
Actor principal: Encargado de faenamiento y envasado
Objetivo: Generar el plan de faenamiento y envasado.
Precondiciones: Usuario logeado y con permisos para generar plan de faenamiento y envasado.
Poscondiciones:
Éxito:
• Plan de faenamiento y envasado generado.
Fracaso:
• Use case cancelado por no existir el estanque a faenar.
• Use case cancelado porque el encargado de faenamiento y envasado cancela la operación.
faenamiento y envasado selecciona la opción
Faenamiento y envasado.
2. El encargado de faenamiento y envasado
selecciona la opción Nuevo plan de faenamiento y
envasado.
3. El sistema consulta los estanques que están
produciendo y que no están en mantenimiento y
muestra los datos de los estanques que cumplen
estas condiciones.
estanque al cuál se le generará el plan de
faenamiento y envasado.
5. El encargado de faenamiento y envasado busca 5.1 El encargado de faenamiento y envasado
y selecciona el estanque al que desea generar el no encuentra al estanque al que desea
plan. generar el plan.
5.1.1 Se cancela UC.
6. EL encargado de faenamiento y envasado
selecciona la opción Generar Plan.
(numero, ubicación, capacidad, tamaño) y del
seguimiento del estanque (lotes actuales, especie,
clase de lote, cantidad).
8. El sistema consulta las asignaciones de tareas
existentes (fecha y hora de realización, tarea,
operario).
9. El sistema calcula los productos esperados
(teniendo en cuenta las especies y clases de lotes
existentes en el estanque).
10. El sistema genera un plan de faenamiento y
envasado que contiene la siguiente información:
estanque a faenar, fecha de inicio, fecha de fin,
tareas a realizar y operarios asignados, productos
esperados.
11. El sistema muestra por pantalla el plan
generado.
operación.
14. El sistema registra el nuevo plan de

Historia de cambios

Nombre del Use Case: Consultar operario y disponibilidad Id: 22
Objetivo: obtener información relacionada al operario y a la disponibilidad horaria de los mismos.
Precondiciones: Usuario logeado y con permisos para consultar operarios y disponibilidades.
Poscondiciones:
Éxito:
• Operario y disponibilidades consultadas.
Fracaso:
• Use case cancelado por no encontrar al operario
• Use case cancelado por no encontrar tareas asignadas al operario.
operarios.
de búsqueda del operario (nombre, apellido,
cargo).
ingresa los parámetros solicitados.
y selecciona al operario. no encuentra al operario.
selecciona la opción Ver Disponibilidad.
7. El sistema consulta las asignaciones asociadas
al operario seleccionado.
8. El sistema obtiene resultados de la búsqueda y 8.1 El sistema no obtiene resultados de la
muestra la descripción de la tarea, tipo de tarea, búsqueda.
fecha y tiempo. 8.1.1 Se cancela el use case.
Historia de cambios


Nombre del Use Case: Emitir listado de estanques a faenar. Id: 23
Objetivo: informar sobre los estanques que están en condiciones de ser faenados.
Precondiciones: Usuario logeado y con permisos para emitir el listado de estanques a faenar.
Poscondiciones:
Éxito:
• Listado de estanques a faenar emitido.
Fracaso:
Estanques.
selecciona la opción emitir listado de estanques a
faenar.
teniendo en cuenta aquellos cuyo estado es listo
para faenar.
4. El sistema obtiene resultados del a búsqueda. 4.1 El sistema no obtiene resultados de la
búsqueda.
listos para faenar (ubicación, capacidad, tamaño,
descripción)
6. El sistema emite un listado con los estanques
listos para faenar.
Historia de cambios


Nombre del Use Case: Registrar resultado de faenamiento y envasado. Id: 24
Objetivo: Registrar el resultado del faenamiento y envasado.
Precondiciones: Usuario logeado y con permisos para poder registrar resultado de faenamiento y
envasado.
Poscondiciones:
Éxito:
• Resultado de faenamiento y envasado registrado.
Fracaso:
• Use case cancelado por no existir el plan de faenamiento y envasado.
• Use Case cancelado porque el operario encargado de faenamiento y envasado cancela la
operación.
• Use case cancelado por no existir los productos.
Faenamiento y envasado.
selecciona la opción Registrar Resultado de Plan.
3. El sistema solicita que se ingrese al plan de
faenamiento y envasado correspondiente.
y selecciona al plan de faenamiento y envasado. no encuentra al plan de faenamiento y
envasado.
5. El sistema muestra los datos del plan de
faenamiento y envasado (estanque a faenar, fecha
de inicio, fecha de fin, tareas a realizar y
operarios a cargo, productos esperados).
6. El sistema solicita que se ingrese los productos
obtenidos y sus respectivas cantidades.
y selecciona los productos obtenidos. no encuentra los productos obtenidos.
ingresa para cada producto seleccionado la
cantidad obtenida.
9. El sistema solicita que se ingresen los productos
desechados y sus respectivas cantidades.
10. El encargado de faenamiento y envasado 10.1 El encargado de faenamiento y envasado
busca y selecciona los productos desechados. no encuentra los productos desechados.
ingresa para cada producto seleccionado la
cantidad desechada.
confirma la operación. cancela la operación.
12.1.1 Se cancela el Use case
13. El sistema registra el resultado del plan de
14. El sistema crea los lotes de faenamiento
resultantes del faenamiento y envasado con los
siguientes datos (fecha de creación, número de
lote, operario que lo generó).
15. El sistema actualiza la existencia de los

productos de acuerdo a los productos obtenidos y

sus correspondientes cantidades.
Asociaciones de extensión: “Registrar tareas y equipos”, “Consultar tareas y equipos”.
Historia de cambios

Nombre del Use Case: Registrar operario. Id: 45
Objetivo: Registrar operario.
Precondiciones: Usuario logeado y con permisos para registrar operario.
Poscondiciones:
Éxito:
• Operario registrado.
Fracaso:
• Use case cancelado porque el encargado de faenamiento y envasado cancela la operación.
operarios.
selecciona la opción Nuevo operario.
operario (nombre, apellido, cargo, tipo de
documento, número de documento, domicilio,
teléfono, mail).
ingresa los datos solicitados.
6. El sistema verifica que los datos ingresados son 6.1 El sistema verifica que los datos son
validos y lo son. validos y no lo son.
7. El sistema registra al nuevo operario.
Historia de cambios


Nombre del Use Case: Modificar datos del operario Id: 46
Objetivo: Modificar los datos de un operario existente
Precondiciones: Usuario logeado y con permisos para poder modificar datos del operario
Poscondiciones:
Éxito:
• Operario actualizado.
Fracaso:
• Use Case cancelado por no existir el operario a modificar.
• Use cancelado porque operario encargado de faenamiento y envasado cancela la
operación.
operarios.
del operario (nombre, apellido, numero de
documento, tipo, cargo)
ingresa los parámetros de búsqueda.
encuentra y selecciona el operario a modificar. NO encuentra el operario a modificar.
selecciona la opción “Modificar Operario”.
modifica los datos del operario (nombre, apellido,
cargo, tipo de documento, número de documento,
domicilio, teléfono, mail)
8. El sistema actualiza los datos del operario
Historia de cambios


Nombre del Use Case: Dar de baja operario Id: 47
Objetivo: Dar de baja a un operario existente
Precondiciones: Usuario logeado y con permisos para poder dar de baja a un operario
Poscondiciones:
Éxito:
• Operario dado de baja.
Fracaso:
• Use Case cancelado por no existir el operario a dar de baja.
• Use cancelado porque operario encargado de faenamiento y envasado cancela la
operación.
operarios.
del operario (nombre, apellido, numero de
documento, tipo, cargo)
ingresa los parámetros de búsqueda.
encuentra y selecciona el operario a dar de baja. NO encuentra el operario a dar de baja.
selecciona la opción “Dar de Baja Operario”.
7. El sistema da de baja al operario seleccionado
Historia de cambios


Nombre del Use Case: Registrar tareas y equipos Id: 106
Objetivo: Registrar una tarea y equipo
Precondiciones: Usuario logeado y con permisos para poder registrar tareas y equipos
Poscondiciones:
Éxito:
• Tarea y equipo registrado.
Fracaso:
• Use Case cancelado por invalidez de los datos.
operación.
faenamiento y envasado selecciona tareas.
selecciona la opción nueva tarea.
la tarea( descripción, duración, tipo, supervisor,
conocimiento necesarios)
ingresa los datos solicitados
5. El sistema solicita que se ingresen los equipos
necesarios para realizar la tarea.

ingresa los datos de los equipos (descripción,
función, capacidad).
validos No son validos
8.1.1 El sistema informa lo ocurrido
9. El sistema registra la tarea y los equipos
asignados
Use Case al que se extiende: “Registrar asignación de tareas y equipos”.
Historia de cambios


Nombre del Use Case: Registrar asignación de tareas a operario Id: 120
Objetivo: Registrar una tarea a un operario
Precondiciones: Usuario logeado y con permisos para poder registrar una tareas a un operario
Poscondiciones:
Éxito:
• Tarea registrada a un operario
Fracaso:
• Use Case cancelado por no existir el operario.
• Use case cancelado por no existir la tarea.
operación.
Asignaciones.
selecciona la opción asignar tareas a operarios.
3. El sistema solicita que se seleccione al
operario.
y selecciona al operario. no encuentra al operario
5. El sistema consulta las tareas y equipos
necesarios y muestra los resultados obtenidos (Se
extiende el use case consultar Tareas y equipos).
6. El sistema solicita que se ingrese las tareas a
asignar.
y selecciona las tareas. no encuentra la tarea deseada.
7.1.1 El sistema pregunta si se desea
registrar la tarea, y si se desea.
7.1.1.1 Se extiende el use case “Registrar
Tarea y equipos”.
7.1.2 El sistema pregunta si se desea
registrar la tarea y no se desea.
7.1.2.1 Se cancela el use case.
8. El sistema muestra los equipos necesarios para
realizar las tareas seleccionadas.
9. El sistema solicita que para cada tarea se
seleccione la fecha y hora de realización.
ingresa la fecha y hora de realización de cada
tarea seleccionada.
13. El sistema registra la tarea y los equipos
asignados

Asociaciones de extensión: “Registrar tareas y equipos”, “Consultar tareas y equipos”.

Historia de cambios

Nombre del Use Case: Emitir listados de asignación de tareas y equipos. Id: 121
Objetivo: Registrar una tarea a un operario
Precondiciones: Usuario logeado y con permisos para poder emitir listado de asignación de tareas
y equipos.
Poscondiciones:
Éxito:
• Listado de asignaciones de tareas y equipos emitido.
Fracaso:
• Use Case cancelado por no obtener resultados de la búsqueda.
Asignaciones.
selecciona la opción emitir listado de asignaciones
a operarios.
3. El sistema solicita que se ingresen los filtros
para realizar el listado (operarios, fecha y hora de
asignación, tareas, equipos).
ingresa los filtros deseados.
5. El sistema consulta las asignaciones realizadas a
los operarios de acuerdo a los filtros ingresados.
6. El sistema obtiene el resultado. 6.1 El sistema no obtiene resultado de la
búsqueda.
7. El sistema emite un listado que incluye
operarios, tareas asignadas, equipos a utilizar,
fecha y hora de realización.
Historia de cambios


Nombre del Use Case: Consultar tareas y equipos Id: 122
Objetivo: Consultar los datos de una tarea y los equipos necesarios para realizarla.
Precondiciones: Usuario logeado y con permisos para poder consultar tareas y equipos
Poscondiciones:
Éxito:
• Tarea y equipo consultados.
Fracaso:
• Use Case cancelado por no encontrar la tarea
• Use Case cancelado porque no se obtienen resultados de la búsqueda.
parámetros de búsqueda de la tarea (descripción,
tipo).
ingresa los parámetros deseados.
4. El sistema realiza la búsqueda y muestra los 4.1 El sistema realiza la búsqueda y no
resultados. obtiene resultados.
y selecciona a la tarea a consultar. no encuentra la tarea a consultar.
6. El sistema muestra los datos de la tarea
(descripción, duración, tipo, supervisor,
conocimiento necesarios) y los datos de los
equipos necesarios para realizar la tarea
(descripción, función, capacidad).
Use Case al que se extiende: “Registrar asignación de tareas y equipos”.
Historia de cambios


Nombre del Use Case: Dar de baja tareas y equipos Id: 123
Objetivo: Dar de baja una tarea y los equipos necesarios para realizarla.
Precondiciones: Usuario logeado y con permisos para poder dar de baja tareas y equipos
Poscondiciones:
Éxito:
• Tarea y equipo dado de baja.
Fracaso:
• Use Case cancelado por no encontrar la tarea a dar de baja.
operación.
tipo).
y selecciona a la tarea a dar de baja. no encuentra la tarea a dar de baja.
selecciona la opción dar de baja Tarea.
8. El sistema da de baja a la tarea selecciona y los
equipos necesarios para realizarla.
Historia de cambios


Nombre del Use Case: Modificar tareas y equipos Id: 124
Objetivo: Modificar los datos de una tarea y los equipos necesarios para realizarla.
Precondiciones: Usuario logeado y con permisos para poder modificar tareas y equipos
Poscondiciones:
Éxito:
• Tarea y equipo modificados.
Fracaso:
• Use Case cancelado por invalidez de los datos.
operación.
tipo).
y selecciona a la tarea a modificar. no encuentra la tarea a modificar.
la tarea( descripción, duración, tipo, supervisor,
conocimiento necesarios)
ingresa los datos solicitados.
8. El sistema solicita que se ingresen los equipos
necesarios para realizar la tarea.

ingresa los datos de los equipos (descripción,
función, capacidad).
12. El sistema modifica los datos de la tarea y los
equipos asignados.
Historia de cambios

Faenamiento y envasado: Diagrama de Clases
Pegar aquí, faenamiento y envasado.

Análisis del Paquete: Producto
Producto
Encargado de Venta
66- Registrar Producto
68- Dar de baja al producto
67- Modificar Producto
69- Consultar Productos

Producto: Descripciones y diagramas de colaboración de

análisis.
Nombre del Use Case: Consultar producto. Id: 69
Objetivo: Obtener un listado de producto que cumplan con ciertas condiciones ingresadas por el
usuario.
Precondiciones: Usuario logeado y con permisos para consultar producto.
Poscondiciones:
Éxito:
• Consulta de producto realizada.
Fracaso:
1. El Use case comienza, cuando el usuario
encargado de venta selecciona la opción Gestión
de Productos.
productos existentes.
3. El usuario selecciona el producto a modificar y
selecciona la opción “Consultar”.
4. El sistema solicita el ingreso de los parámetros
de filtro de la consulta.
5. El usuario Ingresa los parámetros de filtro para 5.1 El usuario selecciona “Cancelar”
la consulta de los productos (tipo, nombre, precio 5.1.1 Se cancela el UC.
mayorista, precio minorista)
6. El sistema consulta los datos de los productos
que cumplan con los parámetros ingresados.
7. El sistema emite listado con los datos de los
alimentos consultados
8. Fin del U.C.
Historia de cambios


Nombre del Use Case: registrar producto. Id: 66
Objetivo: registrar un nuevo producto.
Precondiciones: Usuario logeado y con permisos para registrar producto
Poscondiciones:
Éxito:
• Producto registrado.
Fracaso:
• Cancelado por datos inválidos.
1. El Use Case Comienza, cuando el usuario
encargado de Venta selecciona la opción Gestión
de Productos.
datos (nombre , tipo, precio minorista, pecio
mayorista, código, descripción)
3. El encargado de venta ingresa los datos del
producto.
4. El sistema valida los datos ingresados y los 4.1 El sistema valida los datos ingresados y no
datos son correctos son correctos.
4.2.1 Se cancela Use Case.
5 El sistema registra al nuevo producto.
6. Fin del U.C.
Historia de cambios


Nombre del Use Case: Modificar producto. Id: 67
Objetivo: Modificar los datos de un registro de producto existente.
Precondiciones: Usuario logeado y con permisos para modificar producto.
Poscondiciones:
Éxito:
• Datos de producto modificado
Fracaso:
• Cancelado por datos no validos.
1. El Use case comienza, cuando el usuario
Encargado de venta selecciona la opción Gestión
de Producto
productos existentes.
3. El usuario selecciona el alimento a modificar y
selecciona la opción modificar producto.
4. El sistema solicita el ingreso de las
modificaciones deseadas.
5. El usuario modifica los datos deseados y 5.1 El usuario selecciona “Cancelar”
confirma la operación (descripción, nombre , tipo, 5.1.1 Se cancela el UC.
precio mayorista , precio minorista.
6. El sistema verifica que los datos modificados 6.1 El sistema verifica que los datos
sean correctos, y estos si lo son. modificados sean correctos, y estos no son
correctos.
7. El sistema actualiza los datos del alimento.
8. Fin del U.C.
Historia de cambios


Nombre del Use Case: Dar de baja a alimento. Id: 68
Objetivo: Dar de baja a un registro de producto existente.
Precondiciones: Usuario logeado y con permisos para dar de baja a producto.
Poscondiciones:
Éxito:
• Producto dado de baja
Fracaso:
1. El Use Case comienza, cuando el usuario
encargado de Venta selecciona la opción gestión
de productos.
del producto (tipo, descripción, nombre , código)
de búsqueda.
4. El sistema realiza la búsqueda, obtiene 4.1 No se encuentran resultados de la
5. El encargado de venta busca al producto y lo 5.1 El usuario no encuentra el producto
selecciona 5.1.1 Se cancela el UC.
6. El encargado de venta selecciona la opción dar
de baja producto.
operación.
8. El sistema da de baja al producto.
9. Fin del U.C.
Historia de cambios

Producto: Diagrama de Clases
Producto
Lote nombre
tipo
numero precio
fechadeincubacion id
cantidadInicial
estado consultar()
Especie : Especie
1
registrarAlimentacion()
registrarLote()
cambiarEstado()
registrarClasificacion()
emitirInformeDeSeguimiento()
1..* 1..n n
Existencia de productos
producto : Producto
cantidad
fecha
estimacionAFuturo
lote : Lote
calcularExistenciaActual(Producto : Producto)
calcularExistenciaAFuturo(producto : Producto)
0..*
Seguimiento de Estanque
(from C las ific ac ...
planesAplicados[] : Plan de alimentación
operarioACaro : UsuarioSis
enfermedadesOcurridas[] : Enfermedad Seguimiento de Lote
(from Clas ificación e inc ubac ...
solucionesAplicadas[] : Soluciones de estanques
coleccionDeClasificaciones : Coleccion de Clasificaciones AlimentosAplicado : Alimento
porcentajedeLote
generarPlanDeAlimentacion() cantidad
registrarAlimentacion() fechadesegmentacion
consultarSeguimiento() operarioACargo : UsuarioSis
registrarSolucionAplicada() estado
consultarSolucionesAplicadas() estanquesDestinados[] : Estanque
registrarEnfermedad() resultadoClasificacion[] : Resultado de clasificacion
consultarLotesActuales() registrarAlimentacion()
consultarPlanDeClasificacion() cambiarEstado()
registrarClasificacion(clase, fecha, cantidad, estanqueDestiono) registrarClasificación()
consultar()
habilitarLote()
actualizarProductosCreados()

Análisis del Paquete: Sistema
Sistema
144- Regi strar Usuario 148- Regi strar Permisos 149- Registrar Rol es
150-Modi ficar Rol

147- Dar de Baja al Usuari o
145- Cambiar Contraseña
151- Dar de Baja Permiso
Administrador
(from Actores del Sistema de Información)
...)
153- Cerrar Cesion
152- Dar de Baja al Rol
154- Modificar Usuari o

146- Ini ci ar Sesi on
Usuari o
...)
Encargado de Cobros
Encargado de Atencion
...) al Cl iente
...)
Encargado de Venta Encargado de

Faenamient...
...)
...)
Encargado de
Producción Encargado de Compras
...) (from Actores del Sistema de Información)
...)
Encargado de Pedidos
...)

Sistema: Descripciones y diagramas de colaboración de análisis.

Nombre del Use Case: Registrar usuario Id: 144
Actor principal: Administrador
Objetivo: Registrar un nuevo usuario.
Poscondiciones:
Éxito:
• Usuario registrado.
Fracaso:
• Use Case cancelado por seleccionar “cancelar”.
selecciona la opción usuarios.
2. El administrador selecciona la opción Nuevo
Usuario.
usuario (nombre real, nombre de usuario,
password, fecha de alta, rol).
4. El administrador ingresa los datos del usuario.
5. El administrador confirma la operación. 5.1 El administrador no confirma la
operación.
5.1.1 Se cancela el use Case.
7. El sistema registra al nuevo usuario.
Historia de cambios


Nombre del Use Case: Cambiar contraseña Id: 153
Actor principal: Usuario
Objetivo: Cambiar una contraseña
Precondiciones: Que el usuario tenga permiso para cambiarse la contraseña
Poscondiciones:
Éxito:
• Contraseña cambiada.
Fracaso:
1. El Use Case Comienza cuando el usuario
secciona la opción cambiar contraseña.
2. El sistema solicita que se ingrese la contraseña
y el password.
3. El usuario ingresa sus datos.
4. El sistema valida los datos ingresados y los 4.1 Los datos no son correctos.
mismos son correctos. 4.1.1 Se cancela el Use Case.
5. El usuario selecciona la opción cambiar
contraseña.
6. El sistema solicita que se ingrese el nuevo
nombre y password.
7. El usuario ingresa su nueva contraseña y su
nombre.
8. El usuario confirma la operación. 8.1 Los datos no son correctos.
9. El sistema valida los datos ingresados y los 9.1 Los datos no son correctos.
mismos son correctos. 9.1.1 Se cancela el Use Case.
Historia de cambios


Nombre del Use Case: Inicio de sesión Id: 146
Objetivo: Abrir una nueva sesión
Poscondiciones:
Éxito:
• Sesión iniciada.
Fracaso:
• Use Case cancelado por inconsistencia de datos
secciona la opción inicio de sesión cuando abre
una nueva aplicación.
2. El sistema solicita nombre de usuario y
password.
3. El usuario ingresa su nombre de usuario y su
password.
4. El usuario confirma el inicio de sesión
5. El Sistema verifica los datos y los mismos son 5.1Los datos no son correctos
correctos. 5.1.1 El sistema informa lo ocurrido.
7. El Sistema inicia la sesión
Historia de cambios


Nombre del Use Case: Dar de baja al usuario Id: 147
Objetivo: Actualizar la fecha de baja de un usuario existente.
Poscondiciones:
Éxito:
• Usuario dado de baja.
Fracaso:
• Use case cancelado por no existir el usuario.
selecciona la opción Usuarios.
parámetros de búsqueda del usuario (nombre de
usuario, nombre real, fecha de alta).
3. El administrador ingresa los parámetros de
búsqueda.
5. El administrador busca y selecciona al usuario a 5.1 El administrador no encuentra al usuario
dar de baja. a dar de baja.
6. El administrador selecciona la opción dar de
baja a usuario.
operación.
8. El sistema actualiza la fecha de baja del
usuario con la fecha actual.
Historia de cambios


Nombre del Use Case: Registrar permiso Id: 148
Objetivo: Registrar un nuevo permiso de acceso.
Poscondiciones:
Éxito:
• Permiso registrado.
Fracaso:
selecciona la opción Permisos.
Permiso.
permiso (descripción, código).
4. El administrador ingresa los datos del permiso.
operación.
7. El sistema registra al nuevo permiso.
Historia de cambios


Nombre del Use Case: Registrar rol Id: 149
Objetivo: Registrar un nuevo rol.
Poscondiciones:
Éxito:
• Rol registrado.
Fracaso:
• Use case cancelado por no existir los permisos.
selecciona la opción Roles.
Rol.
rol (descripción, nombre).
4. El administrador ingresa los datos del rol.
5. El sistema solicita que se ingresen los permisos
asociados al rol.
6. El administrador busca y selecciona los 6.1 El administrador no encuentra los
permisos que desea asociar al rol. permisos que desea asociar al rol.
operación.
9. El sistema registra al nuevo rol y los permisos
asociados.
Historia de cambios


Nombre del Use Case: Modificar rol Id: 150
Objetivo: Modificar un rol existente y los permisos asociados al mismo.
Poscondiciones:
Éxito:
• Rol y permisos asociados modificados.
Fracaso:
• Use case cancelado por no existir el rol a modificar.
• Use case cancelado por no existir los permisos a asociar al rol.
selecciona la opción Roles.
parámetros de búsqueda del rol (nombre,
descripción).
búsqueda.
5. El administrador busca y selecciona el rol a 5.1 El administrador no encuentra el rol a
modificar. modificar.
7. El administrador selecciona la opción modificar
rol.
8. El sistema muestra los datos del rol (nombre,
descripción) y los permisos asociados al mismo.
8. El sistema solicita que se ingrese el nombre y la
descripción del rol.
9. El administrador ingresa los datos.
10. El sistema solicita que se ingresen los permisos
asociados.
11. El administrador busca y selecciona los 11.1 El administrador no encuentra los
permisos que desea asociar al rol. permisos que desea asociar al rol.
operación.
14. El sistema actualiza el rol y los permisos
asociados.

Historia de cambios

Nombre del Use Case: Dar de baja permiso Id: 151
Objetivo: dar de baja a un permiso de acceso.
Poscondiciones:
Éxito:
• Permiso dado de baja.
Fracaso:
• Use case cancelado por no existir el permisos a dar de baja.
selecciona la opción Permisos.
parámetros de búsqueda del permiso (código,
descripción).
búsqueda.
5. El administrador busca y selecciona el permiso 5.1 El administrador no encuentra el permiso
a dar de baja. a dar de baja.
baja permiso.
operación.
8. El sistema da de baja al permiso.
Historia de cambios


Nombre del Use Case: Dar de baja rol Id: 152
Objetivo: dar de baja a un rol.
Poscondiciones:
Éxito:
• Rol dado de baja.
Fracaso:
• Use case cancelado por no existir el permisos a dar de baja.
selecciona la opción Rol.
parámetros de búsqueda del rol (nombre,
descripción).
búsqueda.
5. El administrador busca y selecciona el rol a dar 5.1 El administrador no encuentra el rol a dar
de baja. de baja.
baja rol.
operación.
8. El sistema da de baja al rol.
Historia de cambios


Nombre del Use Case: Cerrar de sesión Id: 153
Objetivo: Cerrar una sesión
Poscondiciones:
Éxito:
• Sesión cerrada.
Fracaso:
• Use Case cancelado por seleccionar “cancelar”
secciona la opción cerrar sesión.
2. El usuario confirma cerrar sesión. 2.1 El usuario selecciona cancelar.
3. El sistema cierra la sesión y muestra la pantalla
de inicio.
Historia de cambios


Nombre del Use Case: Modificar usuario Id: 154
Objetivo: Modificar los datos de un usuario existente.
Poscondiciones:
Éxito:
• Usuario modificado.
Fracaso:
• Use case cancelado por no existir el usuario.
selecciona la opción Usuarios.
parámetros de búsqueda del usuario (nombre de
usuario, nombre real, fecha de alta).
búsqueda.
5. El administrador busca y selecciona al usuario a 5.1 El administrador no encuentra al usuario
dar de baja. a dar de baja.
6. El administrador selecciona la opción modificar
usuario.
usuario (nombre real, nombre de usuario, fecha
de alta, password, rol).
8. El administrador ingresa los datos del usuario.
operación.
11. El sistema actualiza los datos del usuario.
Historia de cambios

Paquete Sistema: Diagrama de Clases
Interfaz de
UsuarioSi s
Seguridad
cargo 1
fechadealta Coleccion de Usuarios
fechadebaj a
nombreDeUsuari o 0..* 1
pass
fechaCaducaPass
fechaUl timoAcceso
Gestor de Usuari os
nombreReal
permiso : Rol
registrar()
modifi car()
darDeBaj a()
consul tar() 1
consul tarDi sponi bi lidad()
Coleccion de Funciones
Coleccion de Roles
1 0..* 0..*
Rol
descripcion FuncionesT ecnoPez
0..*
id descripcion
nombreCorto casoDeUsoQueHabi lita
crearRol() crearPermiso()
consultarRol() cancelarPermi so()
modificarRol ()
darDeBaj aRol()

Modelo de Diseño
En este modelo, se busca plantear aspectos más relacionados con la
implementación. Se incluye una descripción del modelo de despliegue y una
introducción a la arquitectura de TecnoPez.
Al final de este documento, se encuentra el modelo relacional de la base
de datos, que se utilizara en la implementación.
También incluimos una serie de estándares de codificación (adaptados de
estándares de Microsoft y otras fuentes de Internet), que se utilizarán a la
hora de programar nuestro producto.
El objetivo de esta sección, es orientar hacia una implementación común
y homogénea entre el grupo de trabajo. Por el tamaño del proyecto se busca
dar lineamientos de diseño lo suficientemente flexibles como para adaptarse
a las implementaciones de los casos de uso correspondientes.
Planteamos como se realizara el acceso a datos, con las clases de diseño
que se requerirán y demostramos con un breve ejemplo, como interactúan las
clases para obtener datos y mostrabas al usuario en un diagrama de
colaboración. Buscando así establecer el concepto con el cual se trabajará en
el resto del desarrollo de TecnoPez.

Modelo de despliegue y Arquitectura

Servidor De
Base De Datos
Servidor Web
Servidor de
Servidor de interfaces web
Aplicación LAN
TecnoPez será implementado con tecnología de Microsoft, más

concretamente con la plataforma .NET FrameWork, lo cual condiciona y nos
brinda oportunidades a la hora de desarrollar el diagrama de desligue.
La implementación se realizara de manera tal de que la capa de negocio
de la aplicación se encuentre separada de la capa de persistencia y de la de
interfaz. Procurando llegar al clásico modelo de 3 capas.
Esta decisión se realizó por las ventajas que lleva este modelo a la hora
de realizar el mantenimiento del software o adaptarlos a requerimientos
específicos de cada negocio. Por lo que nos permitirá reutilizar un alto
porcentaje de código con el correspondiente ahorro de tiempo y dinero que
esto produce.
La capa de persistencia permanecerá en el Servidor de Base de datos que
interactúa con el Servidor de Aplicaciones. Este último contiene los
componentes que utiliza TecnoPez para brindar persistencia a las clases,
mediante objetos del paquete Sistema analizado anteriormente se encarga de
interactuar con los objetos provistos por el .Net Framework para acceso a
datos.
Se proveerá dos implementaciones de las clases de acceso a datos de
TecnoPez, una para acceso a cualquier base de datos (que tengan interfaz
OleDbc) y una especialmente diseñada para Microsoft SQL Server, que
utilizará clases especificas brindadas por Microsoft, que mejoran el
rendimiento de TecnoPez con este conocido motor de base de datos (más
adelante se ofrece una vista de las clases que acceden a bases de datos tipo
OleOdbc).
El nodo “Servidor de Aplicación”, brindará los componentes necesarios
para la funcionalidad de tecnopez. Estos componentes se tratarán de clases
distribuidas en una estructura de paquetes (que Microsoft .NET denomina
Nameespaces), que se adjunta a continuación. Estos componentes serán

utilizados por el servidor de interfaces web LAN, el cuál se encargará de

generar el código html necesario para enviar a las pc clientes de los usuarios.
Las cuales actuarán como clientes pasivos, (estaciones bobas) encargadas solo
de mostrar la interfaz.
Tanto el servidor de aplicaciones, el servidor de interfaces, como el
servidor de base de datos, podrían convivir en un mismo host (pc física), aquí
solo se esta describiendo el despliegue lógico de la implementación de
TecnoPez.
Por último el servidor de aplicaciones, brindará Web Services, al servidor
Web de la empresa en donde se implemente TecnoPez. Los Web Services son
objetos que permiten el intercambio de información entre aplicaciones vía
protocolo http y mediante xml, lo cuál nos independiza a TecnoPez de la
página institucional del cliente (criaderos de truchas), permitiendo así
adaptar las funcionalidades de autogestión (Recepción de reclamos, ofertas,
consulta de cuenta corriente, etc.) de TecnoPez a absolutamente cualquier
ambiente donde se desea implementar.
Al mismo tiempo TecnoPez proveerá clases aspx, que brindaran Proxy
Web Services, es decir trasladarán (teniendo en cuenta rigurosos protocolos
de seguridad) los Web Services que brinda el servidor de aplicaciones a el
servidor web, permitiendo así que TecnoPez interactúe con cualquier
aplicación conectada a Internet que tenga soporte XML. Esto lo hará gracias a
la tecnología Web Services que brinda el .Net Framework de Microsoft.
Dicho en palabras más simples y con un ejemplo, nuestros proveedores
podrían integrar sus aplicaciones a TecnoPez de manera rápida, segura y
sencilla, de esa forma el proveedor nos podría brindar sus ofertas
directamente desde sus sistemas de información al suscribirse al Web Service
Proxy que TecnoPez ofrece en el servidor web de la empresa (puede obtener
más información de los Web Service en la página en
http://msdn.microsoft.com ).
La interfaz, como anteriormente se dijo será web, para ello se utilizará
Internet Information Server de Microsoft, el cuál permite correr aplicaciones
asp.net que contendrán las interfaces de TecnoPez.
A continuación se adjunta una descripción de la arquitectura de
TecnoPez, más gráfica que la que brinda UML.

Descripción grafica de la arquitectura
Aplicaciones de 3eros
Usuario de Autogestion (clientes, provedores)
(interacutando con WebServices)
Internet
Servidor de Base de Datos
Via
WebServices Servidor de Aplicaciones
Servidor de interfaces WEB Lan

Servidor Web De La Empresa

Diagrama de Clase de Diseño: Clases encargadas de la

persistencia.
Se encuentran en el paquete Sistema, este paquete encapsula
comportamientos referidos con la implementación del sistema. Entre las
clases de este encontramos las relacionadas con la capa de persistencia que
permiten el acceso a datos e independizan este del resto de las clases de
TecnoPez. A continuación se incluye un pequeño diagrama de clases
encargadas de la persistencia.
System::Exception
Sistema::clsSQL
-objConexion : OleDbConnection
-objOrigen : clsOrigenDeDatos
-booConectado : Boolean
-strMensaje : String
-objException : Exception
-objTransaccion : OleDbTransaction
Sistema::clsOrigenDeDatos +getMensaje() : String
-strDSN : String +getError() : Exception
+estaConectado() : Boolean
+origen() : String
+New()
+toString() : String +iniciarTransaccion () : Boolean
+New() +confirmarTrans() : Boolean
+denegarTrans() : Boolean
+ejecutarSQL(entrada strSQL : String) : Integer
+getDataReader(entrada strSQL : String) : OleDbDataReader
#Finalize()
OleDb::OleDbDataReader
OleDb::OleDbTransaction OleDb::OleDbConnection

Diagrama de colaboración de diseño: Acceso a Datos

Se busca con este diagrama, establecer un estándar para acceso a datos
en todo TecnoPez (separando así la capa de persistencia, del resto del
software).
En el siguiente diagrama se muestra como interactúan las clases para
poder realizar una consulta de todos los usuarios registrados. Las clases
principales están descriptas en el diagrama de clase anterior, mientras que las
clases provistas por el .Net Framework (proveniente del paquete OleDb) no
fueron especificadas ya que no serán desarrolladas por TecnoPez sino
utilizadas y estas son desarrolladas por Microsoft (donde están
documentadas).
: clsInterfazDeUsari os
1. consultarUsuari os(nombre : String) 18. New( )

21. setearDatos( )
: Usuari oSis
23. resultadoDeBusqueda(Usuari osSis: ArrayList)
19. Read( )
: ArrayList
: clsGestorDeUsuarios 20. Item(Item : String)
22. AddItem(Item : Obj ect) : OleDbDataReader

17. New( )
: clsOrigenDeDatos
11. getDataReader(strSql : String)
8. iniciarT ransaccion( )
2. New( )
: clsSQL
3. New() 16. New( )
4. origen( )
12. New( )
13. Connection( )
14. CommandT ext( )
15. ExecuteReader( )
6. New()
: OleDbConecti on 9. beginT ransaction( )
7. open( )
5. connecti onString( )
: Ol eDbCommand
10. New()
: Ol eDbT ransacti on

En este diagrama observamos como la interfaz se comunica con el gestor

(en este caso el gestor de usuarios). Esta clase encapsula todo el
comportamiento de negocio y conoce las clases que le brindan soporte para
poder llevar a cabo, entre ellas las clases de persistencia o capa de datos
(clsSQL), estas clases sirven de interfaz a las clases de gestión (gestores) para
acceso a datos. De esta manera se busca separar la interfaz, de la capa de
negocios, y de la de acceso a datos.
De esta manera se observa como los gestores conocen a las clases de
acceso a datos y transforman clases de datos como OldbDataReader (provistas
por Microsoft), en estructuras de datos genéricas como ArrayList, para el uso
de la interfaz. Así el gestor no conoce de donde obtuvo su DataREader y de
ser necesario algún cambio en la forma de acceso a datos este se hará de
forma transparente en la clase correspondiente. Y de esta manera el interfaz
al no recibir objetos de acceso a datos, sino estructuras de datos ya
procesadas, se limita a mostrarlas por el dispositivo que corresponda
careciendo de reglas de negocio ni manejo de acceso a datos.
Se busca con este modelo de trabajo, reducir el costo de mantenimiento
de TecnoPez a largo plazo, para que sea adaptable al cambio que el entorno
pueda imponerle.
A continuación mostramos el diagrama de secuencia del mismo.
: : : c ls SQL : : OleDbConec tion : : OleDbCommand : : Array Lis t

: Us uarioSis
c ls Interfaz ... c ls Ges torD... c ls OrigenDeDatos OleDbTrans ac tion OleDbDataReader
1. c ons ultarUs uarios (nombre : String)

2. New ( )
3. N ew()
4. origen( )
5. c onnec tionString( )
6. New ()
7. open( )
8. inic iarTransac c ion( )
9. beginTrans ac tion( )
10. New()
11. getDataReader(s trSql : String)
12. New ( )
13. Connec tion( )
14. CommandTex t( )
15. Ex ec uteReader( )
16. New( )
17. New ( )
18. New( )
19. Read( )
20. Item(Item : String)
21. setearDatos ( )
22. AddItem(Item : Objec t)
23. res ultadoDeBus queda(Us uarios Sis : Array Lis t)

Modelo de seguridad
El modelo de seguridad planteado en el análisis esta basado en roles (ver

diagrama de clases de paquete Sistema, y diagrama de casos de uso del mismo
paquete).
Un rol es un conjunto de permisos (los cuales se definen a nivel de
Funcionalidades de TecnoPez), y ese rol puede estar asignado a un conjunto
de usuarios.
Los usuarios representan a uno o más actores, y deben llevar a cabo el
proceso de inicio de sesión antes de utilizar el producto.
El inicio de sesión consiste en validar la identidad del actor y asociar un
rol al mismo.
El rol, esta previamente asignado por un súper usuario, denominado
administrador que es el encargado de la asignación de nuevos usuarios, roles y
permisos.
Una vez que el actor inicio sesión, TecnoPez, mostrará las opciones del
menú de las cuales puede acceder y ocultará el resto de la funcionalidad al
usuario.
Cada vez que TecnoPez cargue una interfaz (un aspx.net, en nuestra
implementación), deberá verificar:
Que el usuario este logueado (es decir haya iniciado sesión y su sesión no
haya expirado, es decir no registrar movimientos por más de 30 minutos).
Que el usuario tenga un rol con permisos para acceder a esta interfaz.
Este modelo parece redundante pero en un entorno web, en donde el
usuario puede modificar la url de acceso a su gusto, el hecho de hacer
verificaciones extra no genera gran redundancia y aumenta notablemente la
seguridad en TecnoPez.
Por último, cada vez que un usuario intente acceder a una interfaz que
no este permitido deberá quedar asentado en algún sitio y este será
redireccionado a una pagina diseñada a tal fin de realizar la registracion
correspondiente. En caso de que el mismo usuario intente acceder dos veces a
una interfaz sin permiso de acceso, el sistema emitirá una alerta al
administrador vía correo electrónico.
En cuanto al inicio de sesión en la base de datos, este se realizará con el
usuario y password del sistema de TecnoPez, de esta manera se facilita la
realización de auditoria con las herramientas que brinde el motor de base de
datos. Y permite un mayor grado de seguridad a la hora de determinar
permisos a nivel de objetos en la base de datos para un determinado usuario.

Diagrama de Clases: Clases de Interfaz
A continuación se incorpora un diagrama de clases de los componentes y

la clase de interfaz encargada de registrar un estanque. Se omitió las
definiciones de algunas clases para reducir la complejidad del diagrama.
clsSQL
-objConexion : OleDbConnection
-objOrigen : clsOrigenDeDatos
-booConectado: Boolean
TecnoPez::Estanque TecnoPez::gestorDeEstanques -strMensaje : String
-objException : Exception
-objTransaccion : OleDbTransaction
+getMensaje() : String
+getError() : Exception
+estaConectado() : Boolean
+New()
+iniciarTransaccion() : Boolean
+confirmarTrans() : Boolean
+denegarTrans() : Boolean
+ejecutarSQL(entrada strSQL : String) : Integer
+getDataReader(entrada strSQL : String) : OleDbDataReader
TecnoPez::registrarEstanque #Finalize()
-objEncargados: gestorDeEstanques
#Label1 : Label
#Label2 : Label
#Label3 : Label Collections::ArrayList
#Label4 : Label
#Label5 : Label
#Label6 : Label
#txtUbicacion : TextBox
#txtCapacidad : TextBox TecnoPez::Global
#txtTamaño : TextBox -components : IContainer
#TxtDescripcion : TextBox
+New()
#txtFechaDeAlta : TextBox
-InitializeComponent( )
#cmbResponsables : DropDownList
+Application_Start(entrada sender: Object, entrada e : EventArgs)
#cmbRegistrar : Button
+Session_Start(entrada sender: Object, entrada e : EventArgs)
#CustomValidator1 : CustomValidator
+Application_BeginRequest(entrada sender: Object, entrada e : EventArgs)
#CompareValidator1 : CompareValidator
+Application_AuthenticateRequest( entrada sender: Object, entrada e : EventArgs)
#RangeValidator1 : RangeValidator
+Application_Error(entrada sender: Object, entrada e : EventArgs)
#RequiredFieldValidator1 : RequiredFieldValidator
+Session_End(entrada sender: Object, entrada e : EventArgs)
#RegularExpressionValidator1 : RegularExpressionValidator
+Application_End(entrada sender: Object, entrada e : EventArgs)
-designerPlaceholderDeclaration: Object
-InitializeComponent( )
-Page_Init(entrada sender: Object, entrada e : EventArgs) WebControls::WebControl
-Page_Load(entrada sender: Object, entrada e : EventArgs)
-cmbRegistrar_Click(entrada sender: Object, entrada e : EventArgs)
UI::TemplateControl
System::MarshalByRefObject
Web::HttpApplication
ComponentModel::Component
UI::Page
System::EventArgs
WebControls::CustomValidator
WebControls::CompareValidator
UI::Control
WebControls::RequiredFieldValidator
WebControls::CustomValidator
WebControls::BaseCompareValidator
WebControls::Button
WebControls::BaseValidator WebControls::DropDownList
WebControls::Label WebControls::ListControl
WebControls::RangeValidator WebControls::RegularExpressionValidator
WebControls::TextBox

Aquí se puede observar lo complejo que sería realizar un diagrama de

colaboración intentando demostrar el comportamiento de las clases. Por lo
que se realizará un descriptivo, con el mismo objetivo que los anteriores, para
establecer una metodología de desarrollo para la implementación.
Se utilizarán las clases de interfaz (en este caso RegistrarEstanque),
como páginas aspx, heredan de UI:Page, al heredar de esta clase (brindada
por el .net Framework), se obtiene una serie de eventos que serán
sobrecargados a medida que necesiten como por ejemplo la carga de la
página.
Se utilizarán los controles que brinda el paquete WebControls como por
ejemplo el TextBox, y serán validados por clases de validación que heredan de
BaseValidator, las cuales brindan funcionalidad que ya fue testeada por el
FrameWork por lo que aumentará la seguridad del software.
Como se explicó anteriormente, la clase de interfaz, tiene un gestor, con
el cual interactúa ofreciéndole datos o solicitándole información, mediante
estructuras de datos estándares del lenguaje de programación como es el
ArrayList (una lista, tipo vector que se encuentra en el paquete Collection).
La interfaz, entonces intercambia mensajes con el gestor el cuál conoce las
clases de la capa de persistencia y se encargara de obtener los datos
almacenarlos y llevar a cabo las reglas del negocio.
En cuanto al intercambio de mensajes de advertencia se realizará con el
siguiente esquema:
Por cada clase que debiera devolver algún tipo de advertencia o mensaje
de error, se deberá implementar una propiedad llamada Mensaje, la cual será
de tipo String y contendrá el mensaje en caso de producirse.
Los métodos de la clase que necesiten emitir advertencias o mensajes,
deberán devolver un true or false (valor booleano), en caso de no devolver
nada y colocar el mensaje en la propiedad correspondiente.
Si el método de la clase devolviese algún número, y fuera necesario
alertar a la otra clase, además de escribir el mensaje que corresponda,
deberá devolver un número negativo o en caso de tratarse de objetos un
nothing.
El objeto deberá brindar siempre la posibilidad de obtener el objeto
Exception si se producirá, para que las capas anteriores puedan tener
conocimiento del origen de los errores.
Si se respeta el modelo de intercambio de mensajes entre el equipo de
desarrollo será posible crear clases débilmente acopladas y fácilmente
depurables.

Aspectos de Implementación: Componentes y generación de

código.
La generación del código, se realizara de acuerdo a los paquetes
planteados en el análisis, creando al menos una biblioteca dll por cada
paquete de nivel inferior.
Es importante que se respete además de la estructura de paquetes, la
creación y asignación de cada clase en el namespaces TecnoPez.
Los namespaces en .net, permiten una forma fácil y ordenada de escribir
el código, evitando ambigüedades. Representando los paquetes en los cuales
se encuentra.
Se utilizara un cvs (software de control de versiones), para llevar el
control de versiones, el cual estará conectado a Internet para poder
intercambiar las últimas versiones del producto desde las distintas ubicaciones
de los desarrolladores.
Se deberá por cada clase codificada sobrecargar el método toString(),
ofreciendo información en formato de cadena significativa para la clase que
se está codificando.
También se utilizarán en la medida que sea posible los métodos
constructores, sin olvidar de implementar el destructor correspondiente.

Estándares de codificación
Las técnicas de codificación incorporan muchos aspectos del desarrollo
del software. Estas contribuyen a una mejor compresión del código fuente. En
esta fase se tienen en cuenta todos los tipos de código fuente, incluidos los
lenguajes de programación, de secuencias de comandos, de marcado o de
consulta.
Estos estándares fueron adaptados de documentación provista por el sitio
de Microsoft a fines de utilizarlos para la implementación de TecnoPez.
Nombres
El esquema de nombres es una de las ayudas más importantes para
entender el flujo lógico de una aplicación. Un nombre debe más bien expresar
el "qué" que el "cómo". Se debe evitar nombres que se refieran a la
implementación subyacente (sujeta a cambios), así se estará conservando un
grado de abstracción que lo simplificará todo. Por ejemplo, puede usar
obtenerSiguienteCobrador() en vez de getNextArrayElement().
Se pondrán nombres lo suficientemente largos para que sean elocuentes,

pero lo bastante cortos como para que no pequen de palabrería. Desde el
punto de vista de la programación, un nombre único sirve solamente para
diferenciar un elemento de otro. Los nombres expresivos funcionan como
ayuda para el lector, por eso, es lógico dar nombres que sean fáciles de
comprender.
Rutinas
• Evite nombres imprecisos que permitan interpretaciones
subjetivas, como por ejemplo AnalyzeThis() para una rutina, o
bien xxK8 para una variable. Tales nombres contribuyen más a la
ambigüedad que a la abstracción.
• En el acceso a objetos es redundante incluir nombres de clases en
el nombre de las propiedades de clases, como por ejemplo
Book.BookTitle. En su lugar, utilice Book.Title.
• Use el método verbo-sustantivo para dar nombre a las rutinas que

ejecuten alguna operación en un determinado objeto, como por
ejemplo CalculateInvoiceTotal().
• En lenguajes que permitan sobrecarga de funciones, todas las
sobrecargas deberían llevar a cabo una función similar.
Variables
• Añada calificadores de computación (Avg, Sum, Min, Max, Index)
después de un nombre de variable donde le resulte apropiado.
• Utilice pares complementarios en nombres de variables, como
min/max, begin/end, y open/close.
• Dado que la mayoría de nombres se construyen concatenando
varias palabras, emplee una mezcla de mayúsculas y minúsculas

para simplificar la lectura. Además, para ayudar a distinguir entre

variables y rutinas, utilice el método Pascal de mayúsculas y
minúsculas (CalculateInvoiceTotal) para los nombres de rutinas,
en el que la primera letra de cada palabra está en mayúscula.
Para las variables, ponga la primera letra de cada palabra en
mayúscula, exceptuando la primera (documentFormatType).
• Los nombres de variables booleanas deberían contener Is, lo que
implica valores del tipo Yes/No o True/False, como por ejemplo
estanqueIsListo.
• Evite usar términos del tipo Flag cuando ponga nombre a variables
de estado, que difieren de las variables booleanas en que aquéllas
deben tener más de dos valores posibles. En vez de documentFlag,
utilice un nombre más descriptivo, del tipo documentFormatType.
• Incluso para el caso de una variable de poco uso, que deba
aparecer sólo en unas cuantas líneas de código, emplee un nombre
descriptivo. Utilice nombres de variables de una sola letra, como i
o j sólo para índices cortos.
• No utilice números o cadenas literales, como por ejemplo For i =
1 To 7. En su lugar, emplee constantes con nombre, del tipo For i
= 1 To NUM_DAYS_IN_WEEK para que resulten fáciles de mantener y
comprender.
• Es recomendado que las variable booleanas contengan una
palabra que describa su estado: puedeEliminarse, esGrande,
tieneHijos, etc. Y siempre se debe referir al estado verdadero:
tieneCredito en cambio de noTieneCredito
Tablas
• Cuando ponga nombres a tablas, hágalo en plural. Por ejemplo,
use proveedores en lugar de proveedor.
• Cuando ponga nombre a las columnas de las tablas, no repita el
nombre de la tabla; por ejemplo, evite un campo llamado
empleado de una tabla llamada empleado.
• No incorpore el tipo de datos en el nombre de una columna. Para

reducir el esfuerzo que podría ser necesario posteriormente para
cambiar el tipo de datos.

Microsoft SQL Server

• No ponga prefijos sp a los procedimientos almacenados, ya que se
trata de un prefijo reservado para la identificación de
procedimientos almacenados de sistemas.
• No ponga prefijos fn_ a las funciones definidas por el usuario, ya
que se trata de un prefijo reservado para funciones integradas.
• No ponga prefijos xp_a los procedimientos almacenados
extendidos, ya que se trata de un prefijo reservado para la
identificación de procedimientos almacenados extendidos.
Otros aspectos:
Minimizar el uso de abreviaturas; pero si las emplea, use
coherentemente las que haya creado. Una abreviatura sólo debe tener un
significado y, del mismo modo, a cada palabra abreviada sólo debe
corresponder una abreviatura. Por ejemplo, si utiliza "min." para abreviar
"mínimo", hágalo siempre así, y no use también "min." para abreviar "minuto".
Cuando ponga nombre a las funciones, incluya una descripción del valor
que vaya a ser devuelto, como por ejemplo GetCurrentWindowName().
Los archivos y los nombres de carpetas, al igual que los nombres de
procedimientos, deben describir claramente su finalidad.
Evite las marcas tipográficas para identificar tipos de datos, como $ para
las cadenas, o % para los enteros.
Evite añadir comentarios al final de una línea de código, porque lo hacen
más difícil de leer. Sin embargo, los comentarios de final de línea sí son
apropiados al anotar declaraciones de variables. En este caso, alinee todos los
comentarios de final de línea en la misma posición de tabulación
Evite rodear un bloque de comentarios con un marco tipográfico. Puede
resultar agradable, pero es difícil de mantener.
Use frases completas cuando escriba comentarios. Los comentarios
deben aclarar el código, no añadirle ambigüedad.
Vaya comentando al mismo tiempo que programa, porque probablemente
no tenga tiempo de hacerlo más tarde. Por otro lado, aunque tuviera
oportunidad de revisar el código que ha escrito, lo que parece obvio hoy es
posible que seis semanas después no lo sea.
Haga comentarios en el código que esté formado por bucles o
bifurcaciones lógicas. Se trata en estos casos de áreas clave que ayudarán a
los lectores del código fuente.
Separe los comentarios de sus delimitadores mediante espacios. Si
respeta estas normas, los comentarios serán más claros y fáciles de localizar
si trabaja sin indicaciones de color.

Formato
El formato hace que la organización lógica del código sea más clara. Si
toma el tiempo de comprobar que el código fuente posee un formato
coherente y lógico, les resultará de gran utilidad a usted y a otros
programadores que tengan que descifrarlo.
Los siguientes puntos son técnicas de formato recomendadas.
• Establezca un tamaño estándar de sangría (por ejemplo, cuatro
espacios) y úselo siempre. Alinee las secciones de código mediante
la sangría predeterminada.
Aplique una sangría al código en todas las líneas de construcción lógica.
Si no aplica la sangría, el código resulta difícil de seguir, como ocurre en:
If ... Then
If ... Then
...
Else
End If
Else
...
End If
La sangría aplicada al código hace que éste sea más fácil de leer, como
por ejemplo en:
If ... Then
If ... Then
...
Else
...
End If
Else
...
End If
Cuando tenga que dividir una línea en varias, aclare que el código sigue
en la línea de más abajo mediante un operador de concatenación colocado al
final de cada línea, y no al principio.
Al escribir en HTML, establezca un formato estándar para las etiquetas y
los atributos; como por ejemplo, las etiquetas siempre en mayúscula y los
atributos en minúscula. Como alternativa, siga las convenciones de la
especificación XHTML para asegurarse de que los documentos HTML son
válidos. Aunque existe una tamaño razonable que debe tenerse en cuenta a la
hora de crear páginas Web, utilice valores de atributo entre comillas y
etiquetas de cierre, para una mejor mantenibilidad.
Cuando escriba instrucciones SQL utilice mayúsculas para las palabras
clave y mayúsculas y minúsculas para los elementos de la base de datos, como
tablas, columnas y vistas.
Coloque las cláusulas SQL principales en líneas separadas, de modo que
las instrucciones sean más fáciles de leer y editar. Por ejemplo:
SELECT FirstName, LastName
FROM Customers
WHERE State = 'WA'

• Divida las secciones de código grandes y complejas en otras más

pequeñas y comprensibles.
Estructura de un programa de Visual Basic .net

Un programa de Visual Basic consta de unidades de creación estándar.
El código de Visual Basic se almacena en módulos de proyecto. Los
proyectos se componen de archivos, que se compilan en aplicaciones. Al
iniciar un proyecto y abrir el editor de código, verá que ya hay código en el
lugar que le corresponde y en el orden correcto. Cualquier código que cree
debe seguir esta secuencia:
1. Instrucciones Option
2. Instrucciones Imports
3. Procedimiento Main
4. Instrucciones Class, Module y Namespace, si corresponde
Además, un programa puede contener instrucciones de compilación
condicional. Estas instrucciones se pueden ubicar en cualquier parte del
módulo. Muchos programadores prefieren ponerlas al final.
Si escribe instrucciones en un orden distinto, pueden producirse errores
de compilación.
Instrucciones Option
Las instrucciones Option establecen reglas de base para el código
subsiguiente, y de esta forma ayudan a prevenir errores de sintaxis y de
lógica. La instrucción Option Explicit asegura que todas las variables están
declaradas y escritas correctamente, lo que reducirá el posible tiempo que
deberá utilizarse posteriormente para depurar. La instrucción Option Strict
ayuda a prevenir errores de lógica y pérdidas de datos que puedan producirse
al trabajar entre variables de diferentes tipos. La instrucción Option
Compare especifica la forma en que se comparan las cadenas entre sí,
mediante su disposición de tipo Binary o Text.
En la implementación de TecnoPez, tanto Option Strict, como Option
Explicit deberán estar presentes en cada modulo, clase, etc. O habilitarse
desde las propiedades del proyecto.
Instrucciones Imports
Las instrucciones Imports le permiten poner nombre a clases y otros
tipos definidos en el espacio de nombres importado sin tener que calificarlos.
Procedimiento Main
El procedimiento Main es el "punto inicial" de la aplicación, el primer
procedimiento al cual se obtiene acceso al ejecutar el código. Main señala el
lugar que corresponde al código al cual debe obtenerse acceso en primer
lugar. En Main, se puede especificar el formulario se cargará primero al
iniciar el programa, se puede saber si se está ejecutando una copia de la
aplicación en el sistema, establecer un conjunto de variables para la

aplicación o abrir una base de datos que la aplicación requiera. Hay cuatro
variedades de Main:
• Sub Main()
• Sub Main(ByVal CmdArgs() As String)
• Function Main() As Integer
• Function Main(ByVal CmdArgs() As String) As Integer
Instrucciones Class, Module y Namespace

Las clases y los módulos forman la mayoría del código del archivo de
código fuente. Contienen la mayor parte del código que se escribe;
principalmente instrucciones Sub, Function, Method y Event, junto con
declaraciones de variable y otro código necesario para que funcione la
aplicación.
Instrucciones de compilación condicional
Las instrucciones de compilación condicional pueden aparecer en
cualquier lugar dentro del módulo. Están configuradas para ejecutarse si se
cumplen determinadas condiciones en tiempo de ejecución. También puede
utilizarlas para depurar la aplicación, ya que el código condicional se ejecuta
únicamente en modo de depuración.
Convenciones de nomenclatura de Visual Basic

Al poner nombre a un elemento en una aplicación de Visual Basic .NET,
el primer carácter del nombre debe ser un carácter alfabético, un dígito o un
subrayado. Las siguientes sugerencias se aplican también a la nomenclatura:
• Empiece cada palabra independiente de un nombre con una letra
mayúscula, como en FindLastRecord y RedrawMyForm.
• Empiece los nombres de método y de función con un verbo, como
en InitNameArray o CloseDialog.
• Empiece los nombres de clase y de propiedad con un nombre,
como en EmployeeName o CarAccessory.
• Empiece los nombres de interfaz con el prefijo "I", seguido de un
nombre o una frase nominal, como IComponent, o con un adjetivo
que describa el comportamiento de la interfaz, como
IPersistable. No utilice el subrayado, y utilice lo menos posible
las abreviaturas, ya que pueden causar confusiones.
• Empiece los nombres de controlador de eventos con un nombre
que describa el tipo de evento seguido por el sufijo
"EventHandler", como en "MouseEventHandler".
• En nombres de clases de argumento de evento, incluya el sufijo
"EventArgs".
• Si un evento tiene un concepto de "antes" o "después", utilice un
prefijo en tiempo presente o pasado, como en "ControlAdd" o
"ControlAdded".

• Para términos largos o utilizados con frecuencia, utilice

abreviaturas para mantener las longitudes de los nombres dentro
un límite razonable, por ejemplo, "HTML" en lugar de "Lenguaje de
marcado de hipertexto". En general, los nombres de variable con
más de 32 caracteres son difíciles de leer en una pantalla
configurada para una resolución baja. Además, asegúrese de que
sus abreviaturas sean coherentes a lo largo de toda la aplicación.
Si utiliza indistinta y aleatoriamente "HTML" y "Lenguaje de
marcado de hipertexto" en un mismo proyecto, provocará
confusión.
• Evite utilizar nombres que en un entorno interno sean iguales que
otros nombres de un entorno externo. Se producirán errores si se
obtiene acceso a la variable errónea. Si se produce un conflicto
entre una variable y la palabra clave del mismo nombre, debe
identificar la palabra clave poniéndole delante la biblioteca de
tipos adecuada. Por ejemplo, si tiene una variable denominada
Date, sólo puede utilizar la función intrínseca Date llamando a
System.Date.
Segmentar y combinar instrucciones en código

Cuando crea el código, a veces debe crear instrucciones largas que
requieren un desplazamiento horizontal por el Editor de código. Aunque esto
no afecta a la forma en que se ejecuta el código, dificulta la lectura del
código tal y como aparece en la pantalla. En estos casos, debe considerar la
posibilidad de segmentar la única instrucción larga en varias líneas.
En otras ocasiones, quizá desee consolidar las instrucciones en una sola
línea; por ejemplo, si tiene diversas instrucciones cortas y desea ahorrar
espacio. Esta característica puede ser también útil al organizar variables o
comandos dentro de un módulo.
Para segmentar una sola instrucción en diversas líneas
Utilice la secuencia de continuación de línea, que es un espacio seguido
de un subrayado ( _), en el punto en el cual desea segmentar la línea. En el
ejemplo siguiente, la instrucción se segmenta en cuatro líneas con secuencias
de continuación de línea al final de todas las líneas excepto la última:
Data1.RecordSource = _
"SELECT * FROM Titles, Publishers" _
& "WHERE Publishers.PubId = Titles.PubID" _
& "AND Publishers.State = 'CA'"
La utilización de Esta secuencia facilita la lectura del código, tanto en
pantalla como al imprimirlo.
Existen algunas restricciones respecto al uso de la secuencia de
continuación de línea en determinadas posiciones, como en medio de un
nombre de argumento. Puede segmentar una lista de argumentos con la
secuencia de continuación de línea, pero los nombres individuales de los
argumentos deben permanecer intactos.

Aunque el método recomendado consiste en colocar cada instrucción en

una línea separada, Visual Basic también permite colocar diversas
instrucciones en la misma línea.
Para colocar varias instrucciones en la misma línea
Separe las instrucciones con un signo de dos puntos (:), como en el
ejemplo siguiente:
Text1.Text = "Hello" : Red = 255 : Text1.BackColor = Red
Caracteres especiales en código
Algunas veces necesitará utilizar caracteres especiales en el código, es
decir, caracteres que no están en la lista alfanumérica estándar. Los
caracteres de puntuación y especiales del conjunto de caracteres de Visual
Basic .NET tienen varias finalidades, desde organizar el texto del programa
hasta definir las tareas que realiza el compilador o el programa compilado. No
especifican que se deba realizar una operación.
Paréntesis
Utilice paréntesis al definir un procedimiento, como Sub o Function.
Debe poner entre paréntesis todos los argumentos de los procedimientos.
También se utilizan los paréntesis para agrupar variables o argumentos de
forma lógica.
Separadores
Los separadores hacen lo que su nombre sugiere; separan secciones de
código. En Visual Basic, el signo de dos puntos (:) es el carácter separador.
Utilice separadores cuando desee colocar varias instrucciones en una única
línea en lugar de colocarlas en líneas separadas, para ahorrar espacio y
mejorar la legibilidad del código. El siguiente ejemplo muestra tres
instrucciones separadas por dos puntos (:):
a = 5: b = 10: c = 15
Concatenación
Utilice el operador "&" para la concatenación, es decir, para vincular
cadenas conjuntamente. No lo confunda con el operador +, que suma valores
numéricos. Si utiliza el operador "+" para concatenar puede que se produzcan
resultados incorrectos en el momento de operar en dos valores numéricos. El
código siguiente proporciona un ejemplo:
Var1 = "10.01"
Var2 = 11
Result = Var1 + Var2 ' Result = 21.01
Result = Var1 & Var2 ' Result = 10.0111
Operadores de acceso a miembros
Para tener acceso a un miembro de un tipo, utilice el operador punto (.)
o signo de exclamación (!) entre el nombre del tipo y el nombre del miembro.
El tipo puede ser una enumeración, estructura, interfaz o clase; el miembro
puede ser un campo, propiedad, evento o método.
Operador punto (.)
Use el operador . como operador de acceso de miembro para
propiedades, eventos, campos y métodos; como en el ejemplo siguiente:
Dim MyForm As New System.Windows.Forms.Form

MyForm.Text = "This is my form" ' Accesses Text member (property) of

Form class (on MyForm object).
MyForm.CenterToScreen() ' Accesses CenterToScreen member (method)
on MyForm.
Operador signo de exclamación (!)

Utilice el operador ! (sólo en una clase o interfaz) como operador de
acceso al diccionario. La clase o interfaz debe tener una propiedad
predeterminada que acepte un solo argumento String. El identificador
inmediatamente posterior al operador ! se convierte en el argumento de
cadena para la propiedad predeterminada, como en el ejemplo siguiente:
Public Class HasDefault ' Exposes a default property.
Default Public ReadOnly Property Index(ByVal S As String) As
Integer
Get
Return 1000 + CInt(S)
End Get
End Property ' Index
End Class ' HasDefault
' ...
Public Class TestHasDefault
Public Sub CompareAccess()
Dim HD As HasDefault = New HasDefault()
Dim IndexStr As String = "5"
MsgBox("Traditional access returns " & HD.Index(IndexStr) &
vbCrLf & _
"Default property access returns " & HD(IndexStr) &
vbCrLf & _
"Dictionary access returns " & HD!IndexStr)
End Sub
End Class ' TestHasDefault
Las tres líneas del resultado de MsgBox muestran el valor 1005. La

primera línea utiliza el acceso tradicional a la propiedad Index, la segunda
utiliza el hecho de que Index es la propiedad predeterminada de la clase
HasDefault y la tercera utiliza acceso de diccionario a la clase.
Observe que el segundo operando del operador ! debe ser un

identificador válido o una palabra clave. En consecuencia, el siguiente cambio
en la última línea de la llamada a MsgBox genera un error, porque "5" no es un
identificador ni una contraseña:
"Dictionary access returns " & HD!"5")
Comentarios en código
A medida que vaya leyendo ejemplos de código, encontrará a menudo el
símbolo de comentario ('). Este símbolo solicita al compilador de Visual Basic
que pase por alto el texto que aparece a continuación, es decir el
comentario. Los comentarios son notas cortas explicativas que se agregan al
código para aportar mayor información a las personas que lo lean.
Es una buena costumbre de programación iniciar todos los procesos y
funciones con un breve comentario que describa las características
funcionales del procedimiento (qué hace), para su propio beneficio y el de
cualquier otra persona que examine el código. Debería separar los detalles de

implementación (cómo lo hace el procedimiento) de los comentarios que

describen las características funcionales. Al incluir detalles de
implementación en la descripción, recuerde actualizarlos en el momento de
actualizar la función.
Los comentarios pueden ir a continuación de una instrucción en la misma
línea, o pueden ocupar una línea completa. Ambas opciones quedan
reflejadas en el código siguiente:
' This is a comment beginning at the left edge of the screen.
Text1.Text = "Hi!" ' This is an inline comment.
Si el comentario necesita más de una línea, utilice el símbolo de

comentario en cada línea:
' The text of this comment is too long to fit on a single line, so we
' break it into two lines. Some comments might need three or more
lines.
El siguiente esquema proporciona instrucciones generales sobre los tipos

de comentarios que deben enumerarse en una sección específica de código.
Son simplemente sugerencias; Visual Basic no tiene unas "reglas" obligatorias
para agregar comentarios. En TecnoPez se realizara en base a estas reglas.
Encabezado de sección Descripción del comentario
Finalidad Describe qué hace el procedimiento (no cómo lo hace).
Suposiciones Enumera cada variable externa, control, archivo abierto u otro
elemento al cual el procedimiento tenga acceso.
Efectos Enumera cada variable externa, control o archivo que esté
afectado, y el efecto que tienen (únicamente si no es evidente).
Entradas Especifica el propósito del argumento.
Valores devueltos Explica los valores devueltos por las funciones.
Recuerde los siguientes puntos:

• Cada declaración de variable importante debe incluir un
comentario en la misma línea que describa el uso de la variable
que se declara.
• Las variables, controles y procedimientos deben tener un nombre
lo suficientemente claro para asegurar que el uso de comentarios
en la misma línea sólo sea necesario para detalles de
implementación compleja.
• Después de la secuencia de continuación de línea no puede
escribirse un comentario en la misma línea.

Responsabilidad de los actores del sistema
Encargado de atención al cliente:

 Registrar visita
 Consultar cliente
 Modificar datos del cliente
 Dar de baja a cliente
 Registrar cliente
 Registrar especies
 Modificar especies
 Dar de baja especies
 Emitir listado de lagunas y especies
 Dar de baja laguna
 Modificar laguna
 Registra laguna
 Registrar tarifa
 Consultar tarifa
 Modificar tarifas
 Consultar registro de pesca
 Modificar registro de pesca
 Dar de baja a pesca registrada
 Registrar pesca
 Consultar visita de turista
 Registrar cobro
 Registrar resolución de reclamo
 Modificar resolución de reclamo
 Emitir informe de inconvenientes y reclamos
 Dar de baja al reclamo
 Modificar reclamo
 Consultar resolución de reclamos
 Registrar reclamos

 Consultar operarios a cargo de los lotes de producción

 Dar de alta a cuenta corriente
 Consultar cuentas corrientes
 Registrar cobro
Encargado de pedidos
 Consultar pedidos
 Emitir listado de pedidos a armar
 Registrar recepción de remitos
 Registrar envío de pedido
 Anular pedido
 Emitir remito
 Anular remito
 Registrar armado del pedido
 Consultar transportistas
 Modificar transportistas
 Dar de baja transportista
 Registrar transportista
 Registrar reclamo
Encargado de cobros
 Anular pedido
 Consultar cobros y deudores
 Emitir resúmenes de cuentas
 Inhabilitar cuenta corriente
 Registrar cobro
 Anular cobro
 Registrar venta

 Consultar venta
 Registrar crédito al cliente

Encargado de ventas
 Anular pedido
 Consultar existencia de productos
 Consultar existencia de productos a futuro
 Registrar pedido
 Registrar producto
 Modificar producto
 Dar de baja producto
 Consultar productos
Cliente
 Registrar reclamo por autogestión
 Consultar cuenta corriente por autogestión
Encargado de producción
 Registrar alimentación
 Consultar alimentos
 Modificar alimentos
 Registrar alimentos
 Dar de baja alimento
 Registrar parámetros de planificación de alimentación
 Dar de baja a parámetros de planificación de alimentación
 Modificar parámetros de planificación de alimentación
 Generar plan de alimentación
 Emitir informe de existencia de alimentación
 Registrar habilitación de lotes de peces en estanque
 Dar de baja a solución
 Registrar control de estanque
 Emitir plan de control de estanques

 Emitir informe de seguimientos de estanques

 Registrar tratamientos aplicados a enfermedades y resultados
 Alertar por desviaciones en condiciones de estanques
 Consultar base de conocimiento de enfermedades
 Dar de baja a enfermedad
 Modificar enfermedad
 Registrar enfermedad
 Dar de baja a parámetros de control
 Consultar y modificar parámetros de control
 Registrar parámetros de control de estanque
 Registrar estado de censores
 Modificar tratamiento de enfermedad
 Dar de baja a tratamiento de enfermedad
 Consultar enfermedades y tratamientos
 Registrar veterinario
 Modificar veterinario
 Dar de baja veterinario
 Registrar solución aplicada a estanque
 Consulta soluciones recomendadas a estanques
Encargado de compras
 Emitir listado de alimentos a comprar
 Registrar pedido a proveedor
 Consultar ofertas del proveedor
 Registrar ofertas del proveedor
 Registrar gastos
 Registrar proveedor
 Modificar datos del proveedor
 Dar de baja a proveedor
 Consultar proveedores
 Consultar pagos y ordenes de pago
 Modificar insumo

 Dar de baja insumo

 Consultar insumo
 Registrar insumo
 Anular pago
 Registrar pago
 Registrar recepción de pedido a proveedor
 Emitir orden de pago
 Anular orden de pago
 Registrar lote de ovas
Proveedor
 Registrar por autogestión proveedor
 Modificar por autogestión datos del proveedor
 Registrar por autogestión ofertas del proveedor
Encargado de faenamiento y envasado

 Registrar operario
 Modificar operario
 Dar de baja operario
 Consultar operario y disponibilidad
 Emitir listado de estanques a faenar
 Generar plan de faenamiento y envasado
 Registrar resultado de faenamiento y envasado
 Dar de baja tarea y equipos
 Modificar tareas y equipos
 Registrar tareas y equipos
 Consultar tareas y equipos
 Registrar asignaciones de tareas a operarios
 Emitir listado de asignación de tareas y equipos

Usuario
 Iniciar sesión
 Cerrar sesión
 Cambiar contraseña
Administrador
 Registrar usuario
 Dar de baja usuario
 Modificar usuario
 Registrar permisos
 Dar de baja permiso
 Registrar roles
 Modificar rol
 Dar de baja rol
 Registrar forma de pago
 Modificar forma de pago
 Dar de baja forma de pago

Modelo de datos: DER

El modelo de datos, para facilitar su interpretación fue dividido en
paquetes, siguiendo la lógica analizada en todo el proyecto.
DER: Paquete Sistema

Roles
IDRol integer <pk> RolesFuncionesTecnoPez
Descripcion varchar(30) IDRol integer <pk,fk1>
FK_ROLESFUN_REFERENCE_ROLES
Nombre varchar(30) IDFuncionTecnoPez integer <pk,fk2>
FK_ROLESFUN_REFERENCE_FUNCIONE
FuncionesT ecnopez
FK_USUARIOS_REFERENCE_ROLES
IDFuncionTecnoPez integer <pk>
Nombre varchar(30)
Usuarios
Empleados
IDUsuario integer <pk> (Atencion al cliente)
FK_USUARIOS_REFERENCE_EMPLEADO
IDEmpleado integer <fk1>
NombreUsuario varchar(20) IDEmpleado integer <pk>
Contraseña varchar(20) Apellido varchar(50)
IDRol integer <fk2> Nombre varchar(50)
IDT ipoDocumento integer
NumeroDocumento varchar(30)
Direccion varchar(100)
T elefono varchar(20)
CorreoElectronico varchar(50)

DER: Paquete de Atención al Cliente
Pegar aquí der…

DER: Producción
Pegar aquí der…

Estimación del tamaño del producto
El producto que se esta desarrollando tiene actualmente 158 casos de

uso, con la posibilidad de que se incremente o disminuya de acuerdo a las
sucesivas refinaciones en las siguientes etapas del proceso unificado de
desarrollo.
El desarrollo podrá finalizarse en aproximadamente 7 meses con cuatro
desarrolladores y suponiendo una jornada laboral de 8 horas diarias (se
excluyen los fines de semana).
Se estima que en aproximadamente 3 meses se estará en posibilidad de
presentar una primera versión implementando los casos de uso que fueron
considerados como mas importante y que dan soporte a los procesos del
negocio a los cuales se les aplicó reingeniería.
En función de los casos de uso detectados y analizados se considera que
en total son necesarias aproximadamente 6720 horas de mano de obra, a un
precio de aproximado de 10 pesos la hora, el presupuesto en recursos
humanos rondaría los 70.000 pesos.
Además se deben tener en cuenta las licencias de las herramientas con
las que se realizara la implementación ya sea tecnologías como Microsoft
sqlServer 2000, Microsoft Visual Basic .NET y censores para tomar mediciones.
La licencia de Microsoft sqlServer 2000 es de U$S 80 aproximadamente
por estación de trabajo, y las licencias de Microsoft Visual Basic .NET es de
U$S 100 aproximadamente. El precio de los censores variara de acuerdo a el
parámetro que se desea medir (temperatura, PH, etc.) y tecnología que
implementa el mismo.

Modelo de Analisis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelo de Analisis

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD TECNOLÓGICA Curso: 5k3

TecnoPez: Producto de Software para gestión

Ochoa, Tolosa, Verme, Felippa – Pagina 2

Modelo de seguridad 258

Ochoa, Tolosa, Verme, Felippa – Pagina 3

Ochoa, Tolosa, Verme, Felippa – Pagina 4

Producción Atención al Cl iente

Se observa un nuevo paquete Sistema, que encapsula aspectos mas

Ochoa, Tolosa, Verme, Felippa – Pagina 5

Descriptivos de Diagramas de Colaboración Genéricos

Los diagramas de colaboración correspondientes a las altas, bajas,

Ochoa, Tolosa, Verme, Felippa – Pagina 6

Ochoa, Tolosa, Verme, Felippa – Pagina 7

1. consultarCliente(razonSocial : , tipoDocumento : , nroDocumento : , descripcion...

2. consultarCliente(razonSocial : , tipoDocumento : , nroDocumento : , descripci on...

3. consultarCliente(razonSocial : , tipoDocumento : , nroDocumento : , descripcion...

4. consultarCliente(razonSocial : , tipoDocumento : , nroDocumento : , descripcion...

Ochoa, Tolosa, Verme, Felippa – Pagina 8

1. consultarCli ente(razonSoci al : , tipoDocumento : , nroDocumento : , descri pcion...

5. selecci onarCl iente( ) 7. darDeBajaCli ente( )

6. selecci onarCl iente( )

3. consultarCli ente(razonSocial : , tipoDocumento : , nroDocumento : , descri pcion...

4. consultarCli ente(razonSoci al : , tipoDocumento : , nroDocumento : , descri pcion...

10. darDeBaj aCliente( )

Ochoa, Tolosa, Verme, Felippa – Pagina 9

1. consultarCliente(razonSocial : , tipoDocumento : , nroDocumento : , descripcion...

2. consultarCliente(razonSocial : , tipoDocumento : , nroDocumento : , descripcion...

6. selecci onarCli ente( )

3. consultarCliente(razonSocial : , tipoDocumento : , nroDocumento : , descripcion...

4. consultarCliente(razonSocial : , tipoDocumento : , nroDocumento : , descripcion...

Ochoa, Tolosa, Verme, Felippa – Pagina 10

Análisis del Paquete: Atención al cliente.

Ochoa, Tolosa, Verme, Felippa – Pagina 11

Análisis del Paquete: Atención al turista

29- Registrar Cliente

28- Consultar Cliente

63- Consultar visitas de turistas

60- Dar de baja a pesca registrada

53- Dar de baja laguna

61- Modificar registro de pesca 52- Modificar laguna

88- Modificar Tarifas 86- Registrar Tarifas

51- Registar Laguna

62- Consultar Registro de Pesca

Ochoa, Tolosa, Verme, Felippa – Pagina 12

Atención al Turista: Descripciones y diagramas de colaboración

Ochoa, Tolosa, Verme, Felippa – Pagina 13

Nivel del Use Case: Negocio Sistema de información

Ochoa, Tolosa, Verme, Felippa – Pagina 14

10. registrarPesca(Especie, Cantidad, Laguna)

1. buscarVisitas(Nombre, Apellido) 6. consultarLagunas( )

11. registrarPesca(Especie, Cantidad, Laguna)

: Gestor de visitas y pesca

12. registrarPesca(Especie, Cantidad, Laguna)

13. registrarPesca(Especie, Cantidad, Laguna)

14. registrarPesca(Especie, Cantidad, Laguna)

El diagrama de colaboración comienza con el mensaje

Ochoa, Tolosa, Verme, Felippa – Pagina 15

Los mensajes de búsqueda devuelven los resultados de la búsqueda (si es

Ochoa, Tolosa, Verme, Felippa – Pagina 16

Nivel del Use Case: Negocio Sistema de información

Ochoa, Tolosa, Verme, Felippa – Pagina 17

Nivel del Use Case: Negocio Sistema de información

Ochoa, Tolosa, Verme, Felippa – Pagina 18