Compilado de Todos Los Casos Practicos, Simulacro y 1er Parcial Practico

Universidad Tecnológica Nacional – Facultades Regionales Córdoba y Villa María
Cátedra de Diseño de Sistemas de Información
Proyecto Prá ctico de Aplicació n

Nombre del Proyecto Práctico de Aplicación: Festival del Folklore
Objetivo del Proyecto Práctico de Aplicación (PPA):
El objetivo del proyecto es desarrollar el modelado de un software de administración de ventas para Festivales
Musicales, a partir de una descripción del negocio. Sólo se muestran algunas vistas de los procesos de requerimientos,
análisis y diseño del software, que se consideran prioritarias para destacar ciertos aspectos del producto.
Objetivos de la Asignatura con respecto al PPA:

 Analizar los sistemas de información mediante el paradigma de Orientación a Objetos.
 Realizar la construcción de un Modelo de Análisis como base para la construcción de una arquitectura robusta
del sistema.
 Manejar las herramientas de modelado que brinda UML para la construcción de Modelos de Solución (Análisis
y Diseño) a partir del Modelo de Requerimientos
 Identificar requerimientos no funcionales y su impacto en la arquitectura.
 Modelar la arquitectura del producto utilizando patrones arquitectónicos.
 Resolver situaciones problemáticas del diseño utilizando patrones de diseño.
 Diseñar artefactos de prueba que permitan validar los requerimientos definidos.
Contenidos de la Asignatura que se abordarán en el PPA:

 Modelado de Dominio.
 Modelado de la funcionalidad
 Diseño de Interfaces de Usuario
 Modelado del Comportamiento en el Análisis
 Modelado de la Estructura en el Análisis
 Mapeo de estructuras de clases a bases de datos relacionales.
 Diseño Arquitectónico – Patrones Arquitectónicos
 Modelo de Despliegue
 Modelo de Prueba
PPA_Festival de Folklore_Completo.docx, Versión 1.36

Autor: Judith Meles Página 1
Consigna asociada al Proyecto Práctico de Aplicación:
1- Establezca los requerimientos del proyecto: Requerimientos funcionales, reglas de negocio y requerimientos
no funcionales.
2- Construya Vista esencial de casos de uso, el listado de casos de uso del producto. Especifique los casos de uso
“Registrar venta de Entradas”, “Generar diagramación” y “Registrar Festival”. Construya los prototipos del
primer caso de uso.
3- Construya el modelo de dominio utilizando un diagrama de clases, especificando clases con sus atributos,
métodos y relaciones con su multiplicidad y navegabilidad.
4- Construya las realizaciones de análisis para los casos de uso “Registrar venta de Entradas”, “Generar
diagramación” y “Registrar Festival” utilizando diagramas de comunicación y de secuencia para la parte
dinámica, para los escenarios de curso normal y la vista de estructura con diagrama de clases.
5- Construya la máquina de estado para la clase “ButacaParaDiaFestival”
6- Identificar los requerimientos no funcionales y especificar la información solicitada, en función de la siguiente
tabla:
Requerimientos No Funcionales
Nº Nombre Descripción Categoría Subcategoría Significativo para Prioridad Explicación
la Arquitectura
7- Identificar patrones arquitectónicos relevantes y construir una representación gráfica de los mismos.
8- Describir las vistas arquitectónicas del proyecto: vista de la funcionalidad, de diseño y de despliegue.
9- Construir el diagrama de despliegue correspondiente.
10- Realizar la vista de la estructura y la vista de la dinámica de los patrones de diseño que usted crea aplicables
para resolver las siguientes problemáticas:
a. Resolver la forma de asegurar que exista una única cola de impresión por centro de venta, para enviar
las impresiones de las entradas vendidas.
b. Proponer una forma de resolver el comportamiento de la butaca, en función de su disponibilidad para
ser vendida en una noche de festival en particular, teniendo en cuenta que la butaca puede estar
vendida, habilitada para la venta, bloqueada momentáneamente para ser vendida, etc.
Resuelva la dinámica para el bloqueo de una butaca al momento de registrar una venta de entrada.
11- Realice el Mapeo de estructuras de clases a bases de datos relacionales y construya el diagrama de Entidad
Relación.
12- Construir los artefactos de prueba para el caso de uso nro. 1 Registrar venta de Entrada: grafo de caminos,
caminos posibles y 1 caso de prueba.
Criterios de Evaluación del PPA (Si aplica):No Aplica

Descripción del Dominio asociado al Proyecto Práctico de Aplicación
Anualmente la Dirección de Cultura de la Municipalidad de una localidad de la provincia, organiza uno o más festivales
de folklore. Por lo general los festivales tienen una duración de cinco noches, aunque esto puede variar de año en año.
En cada una de las noches actúan distintos grupos folklóricos con reconocimiento regional, provincial y nacional. Cada
festival se prepara con mucha anticipación y se realiza la diagramación para determinar qué grupos actúan en cada
noche y el orden en el que los mismos realizarán sus presentaciones, teniendo en cuenta que los horarios de
presentación de los grupos no pueden superponerse y que no pueden quedar espacios sin ninguna presentación entre
medio de dos grupos. Considerar que no puede incluirse la participación de un grupo más de una vez para un mismo
festival, en una misma noche.
En cada noche se define la hora de inicio de la misma, pero no se determina la hora de fin, ya que esta puede variar
según si las presentaciones se extienden más de lo previsto.
Los Festivales se realiza en un único Predio, que está dividido en sectores (A, B, C, etc.), que se identifican con colores
diferentes, y cada sector se compone de filas (1, 2, 3, etc.), cada fila, a su vez, está conformada por butacas, las cuales
están numeradas.
La venta de entradas se realiza en cinco centros de venta (Predio donde se realizará el festival, tres centros comerciales
de la ciudad capital y un centro comercial de la localidad donde se realiza el festival), cada uno de estos puede poseer
hasta 3 puntos de venta para el expendio de las entradas que se encuentran en funcionamiento simultáneamente. No
se debe permitir que se venda una misma entrada (una misma butaca de un festival en una misma fecha) en dos puntos
de venta diferentes. Todas las entradas de un centro de venta se envían a imprimir en una misma impresora fiscal.
Existen distintos tipos de entradas para el público (mayores, menores, jubilados, etc.). El precio de las entradas
depende del tipo de entrada y del sector donde se encuentre la butaca, además puede variar de una noche a otra,
dependiendo de los grupos musicales que actúan. Por ejemplo, una entrada para mayores en el sector A, que está
cerca del escenario, será más costosa que una para mayores en el sector E que está más alejado del mismo y a su vez
puede variar de noche en noche el precio de la entrada en la misma ubicación. Las butacas se venden para una noche
en particular así es que una misma butaca puede estar disponible, por ejemplo, para la noche 1 y 3, y ocupada para la
noche 2, 4 y 5.
También se habilita la venta anticipada de las entradas a un precio menor, un porcentaje de descuento que la Dirección
de Cultura determina, al igual que la fecha de vencimiento de ese beneficio, por ejemplo, venta anticipada con un
descuento del 10 % hasta un mes antes del día del festival para el que se sea comprar la entrada. La forma de venta
de entradas es únicamente de contado en efectivo. Si un cliente solicita la anulación de la entrada sólo se le reintegra
el 50% del monto abonado. Esto se puede hacer hasta 10 días antes del inicio del espectáculo (día del festival), para el
que se compró la entrada.
La entrada tiene un código de barras para evitar falsificaciones. Además, hay que tener en cuenta que la misma entrada
cumple la función de factura, por lo que debe tener los datos requeridos por la ley de facturación, y debe asegurarse
de que el número de factura sea único.
La Dirección de Cultura de la Municipalidad ha solicitado a su Área de Sistemas el desarrollo de un sistema de
información que le ayude con la administración de los festivales que organiza, la diagramación de la programación y
la venta de entradas y brinde información que ayude a la organización de próximos festivales. La Dirección de Cultura
de la Municipalidad tiene licencias para realizar la aplicación con una base de datos Oracle.
Debido a que en las horas pico se suele generar cola en los puntos de venta, es necesario que el sistema genere una
entrada en no más de 6 segundos.

Requerimientos del producto
Objetivo:
Dar soporte a la diagramación de festivales, a la venta y cobro de entradas para los mismos, brindando información
vinculada a la gestión.
Requerimientos Funcionales (Alcances):

 Administrar festivales
 Administrar grupos musicales
 Administrar puntos de venta
 Administrar centros de venta
 Gestionar la diagramación de la programación de los festivales
 Administrar tipos de entrada
 Administrar precios de entradas para el festival
 Administrar ubicaciones
 Gestionar venta de entradas
 Brindar información relacionada a la venta de entradas.
No contempla:
 Control de entradas al ingreso de cada noche del festival.
 Contratación y Pago a artistas y/o proveedores.

Reglas de Negocio
Reglas de Negocio
Nº Nombre Regla de Negocio – Descripción
1 Formas de Pago La única forma de pago aceptada es de contado efectivo.

Se deberá definir el porcentaje de devolución al realizarse una anulación de una entrada
Anulación de
2 cuando el Cliente lo requiera y la cantidad de días antes del inicio Día del Festival para el
Entradas
que corresponde la entrada en el cual el Cliente estará habilitado para anular la misma.
Se debe poder definir el porcentaje de descuento y fecha límite de venta anticipada de
3 Venta Anticipada
entradas.
El precio de la entrada depende del tipo de entrada, el sector y el día, y es determinado
4 Precio de Entrada
para cada festival.
Estados de la Debe poder determinarse la situación de una butaca para cada noche del festival,
5
Butaca distinguiendo si la misma está vendida o disponible.
Se debe determinar el orden en que se presentarán los grupos musicales en cada noche,
teniendo en cuenta que no se pueden superponer los horarios de las presentaciones y que
no pueden quedar espacios sin presentación entre dos grupos. Un grupo musical no puede
6 Diagramación
presentarse más de una vez en la misma noche del festival.
Para cada noche además se debe definir la hora de inicio pero no se define una hora de fin
de la noche.
Puede haber más de un festival vigente y habilitado para la venta de entradas al mismo
7 Festival Vigente
tiempo
Predio para el
8 Cada festival se realizará en un único predio.
festival
La estructura del predio donde se realiza el festival puede tener una configuración de filas
Estructura del y butacas variable, que se debe poder modificar para cada festival. Una vez que el festival
9
predio está programado y se inicia la venta de entradas, la estructura del predio no se puede
modificar para ese festival.

Especificación de los Casos de Uso esenciales
Vista Esencial de Casos de Uso del Sistema de Información
uc Casos de Uso Esenciales
8- Registrar
1- Registrar Venta Ubicaciones del
De Entradas Predio
EncargadoDeVenta ResponsableDeInfraestructura
2- Registrar «extend»
Grupo Musical
3- Generar
Diagramación
4- Generar Reporte De
Venta De Entradas
ResponsableDeFestival
5- Registrar
Festival
6- Generar Estadísitica de
Asistencia por Día de
Festival
7- Registrar
9- Habilitar Butacas Precios de
para Festival Entradas

Listado de Casos de Uso
Nro. de Caso de Uso Nombre del Caso de Uso
1 Registrar venta de entradas
2 Registrar grupo musical

3 Generar diagramación
4 Generar reporte de venta de entradas
5 Registrar festival
6 Generar estadística de asistencia por día de Festival
7 Registrar Precios de Entradas
8 Registrar Ubicaciones del Predio
9 Habilitar Butacas para Festival
10 Eliminar Grupo Musical
11 Modificar Grupo Musical
12 Consultar Grupo Musical
13 Eliminar Festival
14 Modificar Festival
15 Consultar Festival
16 Eliminar Ubicaciones del Predio
17 Modificar Ubicaciones del Predio
18 Consultar Ubicaciones del Predio
19 Eliminar Precios de Entradas
20 Modificar Precios de Entradas
21 Consultar Precios de Entradas
22 Eliminar Punto de Venta
23 Modificar Punto de Venta
24 Consultar Punto de Venta
25 Eliminar Diagramación
26 Modificar Diagramación
27 Consultar Diagramación
28 Eliminar Tipos de Entrada
29 Modificar Tipos de Entrada
30 Consultar Tipos de Entrada
31 Registrar Tipo de Entrada
32 Registrar Anulación de Venta de Entrada
33 Registrar Usuario
34 Consultar Usuario
35 Modificar Usuario

Nro. de Caso de Uso Nombre del Caso de Uso
36 Eliminar Usuario
37 Iniciar Sesión
38 Cerrar Sesión
39 Cambiar palabra clave
40 Registrar permisos para usuario
41 Modificar permisos para usuario
42 Registrar Grupo de Usuario
43 Eliminar Grupo de Usuario
44 Registrar Habilitación de venta
45 Consultar Grupo de Usuario
46 Modificar Grupo de Usuario
47 Validar Fin de Día de Festival
48 Validar Fin de Período de Anulación de Venta
49 Registrar Punto de Venta
50 Registrar Centro de Venta
51 Consultar Centro de Venta
52 Modificar Centro de Venta
53 Eliminar Centro de Venta

Descripción de Casos de Uso–
Trazo Fino o Completamente Descripto
Paquete: no aplica
Nombre del Use Case: Registrar Venta de Entradas ID: 01
Prioridad: Alta Media Baja
Categoría: Esencial Soporte Significativo para la Arquitectura: N/E
Complejidad: Simple Mediano Complejo Muy Complejo Extremadamente Complejo
Actor Principal: Encargado de Ventas (EV) Actor Secundario: no aplica

Tipo de Use Case: Concreto Abstracto
Objetivo: Registrar la venta de una o más entradas para una o más noches de un festival e imprimirlas.
Precondiciones: no aplica
Post- Condiciones Éxito:Entrada/s generada/s e impresa/s, disponibilidad de butacas actualizada.

Fracaso 1: No hay festivales vigentes.
Fracaso 2: No se corrige la selección de butacas.
Fracaso 3: No se confirma la generación de las entradas.
Fracaso 4: El RF decide cancelar la ejecución del caso de uso.
Fracaso 5: No se pudieron imprimir las entradas.
Curso Normal Alternativas
1. EV: selecciona opción Registrar Venta de Entradas
2. SI: muestra los festivales vigentes y solicita se seleccione 2.A. SI: NO hay festivales vigentes. Informa la
uno.(Ver RN 7. Festival Vigente) situación y se cancela el caso de uso.
3. EV: selecciona festival.
4. SI: muestra las fechas asociadas al festival seleccionado
y solicita que se seleccione una o más fechas.
5. EV: selecciona una o más fechas del festival.
6. SI: para cada fecha seleccionada, busca los sectores que 6.A.SI:NO encuentra sectores con ubicaciones
tienen ubicaciones disponibles y, por cada uno, disponibles para esa fecha, informa la situación y
muestra: letra y color del sector, números de filas y permite seleccionar otra fecha.
butacas disponibles. Solicita que se seleccionen las
ubicaciones y el tipo de entrada para cada una.
(Ver RNF 7. Colores en los sectores)
7. EV: selecciona las ubicaciones deseadas indicando el
tipo de entrada para cada una.

8. SI: bloquea temporalmente cada una de las butacas 8.A. SI: No pudo bloquear las butacas
indicadas para el festival y fecha seleccionados. seleccionadas, informa la situación y permite
(Ver RNF 6 Manejo de concurrencia) seleccionar otra ubicación.
9. SI: valida que la fecha actual sea mayor a la fecha de 9.A. SI: valida que la fecha actual sea menor o igual
vencimiento de venta anticipada. (Ver RN 3 Venta a la fecha de vencimiento de venta anticipada.
Anticipada) 9.A.1. SI: calcula el descuento correspondiente.
(Ver RN 3 Venta Anticipada)
10. SI: calcula y visualiza el subtotal por tipo de entrada y el
importe total de la venta.
11. SI: solicita confirmación para generar cada una de las
entradas.
(VER RN 4 Precio de Entrada)
12. EV: confirma la generación. 12.A.RF: no confirma la generación.
12.A.1. SI: libera el bloqueo de las butacas
seleccionadas y cancela el Caso de Uso.
(Ver RNF 6 Manejo de concurrencia)
13. SI: genera e imprime cada una de las entradas con la 13.A.SI: no pudo imprimir la/s entrada/S
siguiente información: 13.A.1 SI: informa la situación y solicita se
 nº entrada, verifique el problema.
 fecha y hora de venta, 13.A.2. EV: pudo resolver el problema.
 tipo de entrada, 13.A.2.A EV: NO pudo resolver el problema.
 precio, 13.A.2.A.1 SI: libera el bloqueo de las
 sector, butacas seleccionadas y cancela el caso de
 fila, uso
 Nº butaca, (Ver RNF 6 Manejo de concurrencia)
 fecha del Evento y 13.A.3. SI: imprime las entradas.
 n° de punto de venta.
 Centro de venta
(RNF 2: Código de Barras, RNF 3: Ley de Facturación y
RNF5 Generación de Entradas)
14. SI: actualiza la disponibilidad de cada una de las butacas
a VENDIDA.
(VER RN 5: Estados de la butaca y RNF 6 Manejo de
concurrencia )
15. Fin del Caso de Uso.
Observaciones:
1. RF puede cancelar la operación en cualquier momento seleccionado la opción correspondiente.

Reglas de Negocio Asociadas:

1- Formas de Pago
3- Venta Anticipada
4- Precio de Entrada
5- Estados de la Butaca
7- Festival Vigente
Requerimientos no Funcionales Asociados:
RNF1: Simultaneidad de puntos de venta
RNF 2: Código de Barras
RNF 3: Ley de Facturación
RNF5 : Generación de Entradas
RNF 6 Manejo de concurrencia
RNF 7. Colores en los sectores
Fuente(Reunión, entrevista, documento, etc) :Enunciado Referencia Fuente: Enunciado de Festival de Folklore
Asociaciones de Extensión: no aplica
Asociaciones de Inclusión: no aplica
Use Case donde se incluye: no aplica
Use Case al que extiende: no aplica
Use Case de Generalización: no aplica

Resumen Esencial o Trazo Medio

Nombre del Use Case: Registrar Venta de Entradas ID: 01
Complejidad: Simple (1) Mediano (3) Complejo (5) Muy Complejo (8) Extremadamente Complejo (13)
Actor Principal: Encargado de Ventas (EV) Actor Secundario: no aplica

Objetivo: Registrar la venta de una o más entradas para una o más noches de un festival e imprimirlas.
Flujo Básico (Curso Normal)
1. EV: seleccionar opción Registrar Venta de Entradas
2. SI: mostrar festivales vigentes
3. EV: seleccionar festival.
4. SI: mostrar fechas del festival seleccionado.
5. EV: seleccionar una fecha.
6. SI: para cada fecha seleccionada, buscar sectores con ubicaciones disponibles y mostrarlos.
7. EV: seleccionar las ubicaciones deseadas, indicar tipo de entrada para cada una.
8. SI: bloquear temporalmente cada una de las butacas indicadas.
9. SI: validar si aplica venta anticipada.
10. SI: calcular y visualizar subtotal por tipo de entrada y el importe total de la venta.
11. SI: solicitar confirmación para generar cada una de las entradas.
12. EV: confirmar la generación.
13. SI: generar e imprimir cada una de las entradas con la siguiente información:
nº entrada, fecha de venta, tipo de entrada, precio, sector, fila, nº butaca, fecha del Evento, punto de venta y
centro de venta
14. SI: actualizar la disponibilidad de cada una de las butacas a VENDIDA.
Flujos Alternativos
A1. No hay festivales vigentes
A2. No hay butacas disponibles para las fechas del festival ingresadas
A3. No hay butacas disponibles en los sectores elegidos.
A4. No se confirma la generación de las entradas.
Observaciones:

Paquete: no aplica
Nombre del Use Case: Generar Diagramación ID: 3
Categoría: Esencial Soporte Significativo para la Arquitectura: E/F
Actor Principal: Responsable de Festival (RF) Actor Secundario: no aplica

Objetivo: Generar la diagramación de las actuaciones que tendrán lugar en cada noche de un festival.
Post- Condiciones Éxito 1: Diagramación generada en forma completa
Éxito 2: Diagramación generada en forma incompleta
Fracaso 1: No hay festivales sin diagramar.
Fracaso 2: No confirma el registro de la diagramación.
Fracaso 3: El RF cancela la operación
1. RF: selecciona opción Generar Diagramación
2. SI: muestra los festivales que no tienen diagramación y 2.A. No hay festivales sin diagramar
solicita seleccionar uno 2.A.1. Se cancela el caso de uso
3. RF: selecciona el festival al que le desea generar la

diagramación
4. SI: muestra las fechas de realización del mismo y solicita
seleccionar un día para diagramar
5. RF: Para cada día que desee diagramar, lo selecciona
6. SI: muestra la fecha, el día, la hora de inicio de la
programación de esa noche del festival. Solicita seleccionar
los grupos de artistas que participarán y permite registrar
nuevos artistas
7. RF: No desea registrar Grupos Musicales 7.A.RF: Desea registrar un grupo musical que no
está registrado,
7.A.1. SI: Se llama al caso de uso 2. Registrar
Grupo Musical y se ejecuta con éxito.
7.A.1.A. SI: El caso de uso no se ejecuta con éxito.

7.A.1.A.1. SI: Informa la situación y permite

cancelar o continuar con la operación
8. RF: Selecciona los grupos que participarán
9. SI: Para cada grupo que participará, solicita ingresar el
número de orden de actuación, duración del espectáculo y
hora de inicio estimada
10. RF: Ingresa los datos solicitados
11. SI: solicita confirmar la diagramación e informa si la
diagramación está completa o incompleta
12. RF: Confirma el registro de la diagramación como completa 12.A. El EV confirma la diagramación como
incompleta.
12.A.1. El sistema registra la diagramación en
ese estado. Fin del caso de uso.
12.B. EV: No confirma la diagramación.

12.B.1. Se cancela el caso de uso
13. SI: verifica que se cumplan todas las restricciones 13.A. No se cumplen las restricciones planteadas
planteadas para la diagramación y se cumplen. (Ver RN 6 para la diagramación (Ver RN 6 Diagramación
Diagramación 13.A.1. SI: Muestra un mensaje informando la
situación y permite corregirlas o cancelar la
diagramación.
14. SI: registra la diagramación como completa
15. Fin del Caso de Uso
Observaciones:
1. RF puede cancelar la operación en cualquier momento seleccionado la opción correspondiente
RN 6 Diagramación
Fuente(Reunión, entrevista, documento, etc.) Referencia Fuente: Enunciado de Festival de
:Enunciado Folklore
Asociaciones de Extensión: 2. Registrar Grupo Musical

Nombre del Use Case: Generar Diagramación ID: 3
Actor Principal: Responsable de Festival (RF) Actor Secundario: no aplica

Objetivo: Generar la diagramación de las actuaciones que tendrán lugar en cada noche de un festival.
1. RF: selecciona opción Generar Diagramación
2. SI: muestra los festivales que no tienen diagramación y solicita seleccionar uno
3. RF: selecciona el festival al que le desea generar la diagramación
4. SI: muestra las fechas de realización del mismo y solicita seleccionar un día para diagramar
5. RF: Para cada día que desee diagramar, lo selecciona
6. SI: muestra la fecha, el día, la hora de inicio de la programación de esa noche del festival. Solicita seleccionar
los grupos de artistas que participarán.
7. RF: Selecciona los grupos que participarán
8. SI: Para cada grupo que participará, solicita ingresar el número de orden de actuación, duración del
espectáculo y hora de inicio estimada
9. RF: Ingresa los datos solicitados
10. SI: solicita confirmar la diagramación e informa si la diagramación está completa o incompleta
11. RF: Confirma el registro de la diagramación como completa
12. SI: verifica que se cumplan todas las restricciones planteadas para la diagramación y se cumplen.
13. SI: registra la diagramación como completa
Flujos Alternativos
A1. NO hay festivales sin diagramación
A2. Crear grupo musical que se desea incluir, llamando al CU Registrar grupa musical
A3. Guardar diagramación incompleta
A4. Hay superposición de grupos en la diagramación
A5. No se confirma registración de diagramación
Observaciones:
1. RF puede cancelar la operación en cualquier momento seleccionado la opción correspondiente

Paquete: no aplica
Nombre del Use Case: Registrar Festival ID: 05
Categoría: Esencial Soporte Significativo para la Arquitectura: N/E
Actor Principal: Responsable Festival (RF) Actor Secundario: no aplica

Objetivo: Registrar los datos de un festival y los días que durará.
Post- Condiciones Éxito:Festival registrado.
Fracaso 1: El RF no confirma la registración del festival.
Fracaso 2: El RF decide cancelar la ejecución del caso de uso.
1. RF: selecciona opción Registrar Festival
2. SI: solicita se ingresen los siguientes datos para el
festival: año de edición, fecha de inicio, nombre
3. RF: ingresa los datos
4. SI: valida que no haya registrado en el sistema un 4.A. SI: valida que no haya registrado en el sistema
festival con el mismo nombre y fecha de inicio, para el un festival con el mismo nombre y fecha de inicio,
año de edición ingresado y no hay. para el año de edición ingresado y hay un festival
registrado.
4.A.1: SI: informa la situación y permite reingresar
los datos.
5. SI: solicita se ingresen los demás datos para el festival:
descuento por venta anticipada y porcentaje de
devolución por anulación
7. SI: para cada día que integrará el festival se solicita se
ingrese: fecha, hora de presentación, fecha límite para
anulación de entrada y fecha de vencimiento de venta
anticipada
8. RF: ingresa los datos requeridos
9. SI: valida que no haya superposición de fechas para los 9.A. SI: valida que no haya superposición de fechas
días del festival ingresados y no hay. para los días del festival ingresados y hay.

9.A.1. SI: informa la situación y permite reingresar

fecha.
10. SI: solicita confirmación para registrar el festival con sus
días
11. RF: confirma la registración. 11.A.RF: no confirma la registración.
11.A.1 Se cancela el caso de uso.
12. SI: registra el festival como no vigente y registra cada
uno de los días del festival.
13. Fin del Caso de Uso.

Observaciones:
2- Anulación de Venta
3- Venta Anticipada
Fuente(Reunión, entrevista, documento, etc.) :Enunciado Referencia Fuente: Enunciado de Festival de Folklore




2. SI: solicita se ingresen los siguientes datos para el festival: año de edición, fecha de inicio, nombre
4. SI: valida que no haya registrado en el sistema un festival con el mismo nombre y fecha de inicio, para el año
de edición ingresado y no hay.
5. SI: solicita se ingresen los demás datos para el festival: descuento por venta anticipada y porcentaje de
devolución por anulación
7. SI: para cada día que integrará el festival se solicita se ingrese: fecha, hora de presentación, fecha límite para
anulación de entrada y fecha de vencimiento de venta anticipada
8. RF: ingresa los datos requeridos
9. SI: valida que no haya superposición de fechas para los días del festival ingresados y no hay.
10. SI: solicita confirmación para registrar el festival con sus días
11. RF: confirma la registración.
12. SI: registra el festival como no vigente y registra cada uno de los días del festival. Fin del caso de uso
Flujos Alternativos
A1. Existe festival registrado con los mismos datos.
A2. Existe superposición de fecha de días de festival.
A3. NO se confirma registración del festival.
Observaciones:



Flujo Existe festival registrado con los mismos datos.
2. SI: solicita se ingresen los siguientes datos para el festival: año de edición, fecha de inicio, nombre
4. SI: valida que no haya registrado en el sistema un festival con el mismo nombre y fecha de inicio, para el año
de edición ingresado y encuentra un festival registrado con esos datos de identificación
5. SI: informa que existe un festival registrado con esos datos. Se cancela el caso de uso
Flujos Alternativos
A1. Flujo básico – Registración de un festival con sus días de festival
A2. Existe superposición de fecha de días de festival.
A3. NO se confirma registración del festival.
Observaciones:

Modelo de Dominio

Realizaciones de Casos de Uso de Análisis

Vista dinámica con Diagrama de Comunicación para el escenario del curso normal del Caso de uso
1 Registrar Venta de Entrada
sd 1.RegistrarVentaDeEntrades-CN
78: finCU()
72: actualizarDisponibilidadDeButacaPorVenta()
70: imprimirEntrada() 6: *mostrarDatos()
65: buscarPuntoVentaYCentroVta()
5: *estaVigente()
63: calcularNroEntrada()
62: crearEntrada()
56: calcularMontoTotal() :Festival
51: calcularSubtotal()
48: obtenerFechaYHoraActual()
47: verificarVentaAnticipada()
74: venderButacas()
41: bloquearButaca()
60: tomarConfirmacionVenta() 32: buscarTiposDeEntrada() 52: obtenerPrecioEntradaParaDiaSectorYTipoDeEntrada()
61: tomarConfirmacionVenta()
49: validarFechaParaVtaAnticipada()
39: tomarSeleccionButacasYTipoDeEntrada() 40: tomarSeleccionDeButacaYTipoEntrada() 17: buscarSectoresDisponibles()
43: bloquearButacaParaDias()
15: tomarSeleccionFecha() 16: tomarFecha() 10: buscarFechasFestival()
2: habilitarVentana() 33: buscarTiposDeEntradaParaDias() 12: buscarFechas()
4: buscarFestivalesVigentes()
8: tomarSeleccionFestival() 9: tomarFestival() 18: buscarSectoresDisponiblesParaDias()
1: opcionVtaEntradas() 3: venderEntrada() 11: mostrarDiasFestival()
: 7: mostrarFestivalesVigentes()
EncargadoDeVenta : 14: mostrarFechas() : elegido :Festival
PantRegVentaEntradas 37: mostrarSectoresDisponibles() GestorRegVentaEntradas 64: *getNumero() 13: *getFecha()
38: pedirSeleccionButacasYTipoEntrada()
57: mostrarCantidadPorTipoDeEntradaYSubtotal() 19: *getSectoresDisponibles()
34: *getTiposDeEntrada()
58: mostrarMontoTotal() :Entrada
59: solicitarConfirmacion() 44: *bloquearButaca()
50: *verificarVtoFechaAnticipada()
69: *new() 53: *obtenerPrecioParaSectorYTipoDeEntrada()
67: getNombreCentroVenta()
75: *venderButacas()
66: getNumero()
71: *imprimir()
:Entrada
42: *esBloqueada() :ImpresorEntrada 55: *getMonto() 20: buscarButacasDisponibles()
54: *esSectorYTipo() 23: buscarDatosUbicacionButaca()
:PuntoVenta 73: *esVendida()
35: *getTipoEntrada()
68: getNombre()
36: getNombre()
:PrecioEntrada :DiaFestival
:Estado
21: *estaDisponible()
:CentroDeVenta :TipoEntrada
24: *getUbicacionCompleta()
30: getNumero() 45: *bloquear()

28: getColor() 31: getNumero()
27: getLetra() 26: getDatosSector() 29: getDatosFila() 76: *venderButaca()
25: getDatosSector()
:Sector :Fila :Butaca
46: setEstado()
77: setEstado()
22: esDisponible()
:Estado :
DisponibilidadButaca

Vista dinámica con Diagrama de Secuencia para el escenario del curso normal del Caso de uso 1
Registrar Venta de Entrada
sd 1.RegistrarVentaDeEntradas-CN
:
EncargadoDeVenta : : :Festival elegido : :Entrada : : :Estado :Butaca :Fila :Sector : : :Estado : : :
PantRegVentaEntradas GestorRegVentaEntradas Festival DiaFestival DisponibilidadButaca PrecioEntrada TipoEntrada PuntoVenta CentroDeVenta ImpresorEntrada
opcionVtaEntradas()
habilitarVentana()
venderEntrada()
buscarFestivalesVigentes()
*estaVigente()
*mostrarDatos()
mostrarFestivalesVigentes()
tomarSeleccionFestival()
tomarFestival()
buscarFechasFestival()
mostrarDiasFestival()
buscarFechas()
*getFecha()
mostrarFechas()
loop Para Cada Día de Festival

[mientras se seleccionen días de festival para venta]
tomarSeleccionFecha()
tomarFecha()
buscarSectoresDisponibles()
buscarSectoresDisponiblesParaDias()
mostrarSectoresDisponibles()
buscarButacasDisponibles()
*estaDisponible()
esDisponible()
buscarDatosUbicacionButaca()
loop Para cada butaca

getUbicacionCompleta()
getDatosSector() getDatosSector()
getNombre()
getColor()
buscarTiposDeEntrada()
buscarTiposDeEntradaParaDias()
getTiposDeEntrada()
*getTipoEntrada()
getNombre()
verificarVentaAnticipada()
obtenerFechaYHoraActual()
validarFechaParaVtaAnticipada()
verificarVtoFechaAnticipada()
mostrarSectoresDisponibles()
pedirSeleccionButacasYTipoEntrada()
tomarSeleccionButacasYTipoDeEntrada()
tomarSeleccionDeButacaYTipoEntrada()
bloquearButaca()
*esBloqueada()
bloquearButacaParaDias(DisponibilidadButaca[])
bloquearButaca(DisponibilidadButaca[])
*bloquear()
setEstado()
calcularSubtotal()
obtenerPrecioEntradaParaDiaSectorYTipoDeEntrada()
obtenerPrecioParaSectorYTipoDeEntrada()
loop Para cada precio

esSectorYTipo()
getMonto()
calcularMontoTotal()
mostrarCantidadPorTipoDeEntradaYSubtotal()
mostrarMontoTotal()
solicitarConfirmacion()
tomarConfirmacionVenta()
tomarConfirmacionVenta()
crearEntrada()
calcularNroEntrada()
*getNumero()
buscarPuntoVentaYCentroVta()
getNumero()
getNombreCentroVenta()
getNombre()
«constructor»
*new()
:Entrada
imprimirEntrada()
*imprimir(String)
actualizarDisponibilidadDeButacaPorVenta()
*esVendida()
venderButacas()
loop para cada dia con butaca vendidas

[mientras existan butacas seleccionadas para dia]
venderButacas()
loop para cada butaca seleccionada

[mientras existan butacas]
venderButaca()
setEstado()
finCU()

Vista de estructura de clases de análisis para la realización del caso de uso Registrar Venta de
Entrada

Vista dinámica con Diagrama de Comunicación

para el escenario del curso normal del Caso de uso 3 Generar Diagramación

Vista dinámica con Diagrama de Secuencia del escenario del curso normal Caso de uso 3 Generar
Diagramación

Vista de estructura de clases de Análisis para la realización del caso de uso Generación de
Programación
class Analisis - Vista Generar Diagramacion
«boundary» «control»
PantallaDiagramacion «entity»
GestorDiagramacion
Festival
comboFestival diagCompleta
comboGrupoMusical añoEdicion
duracion
grillaDiaFestival descuentoVentaAnticipada
horaInicio
lblDiasFestival diaFestival :DiaFestival
nroOrden
lblDuracion fechaInicio
lblFestival buscarArtistas() nombre
lblGrupoMusical buscarDatosDiaFestival() porcentajeDevolucionPorAnulacion
lblHoraInicio buscarDiasFestival() vigente
lblNroActuacion buscarFestivalSinDiagramar()
crearDiagramacion() actualizarEstadoButaca()
txtDuracion bloquearButacaParaDiaFestival()
txtHoraInicio finDeCasoUso()
buscarDatosDiaFestival()
txtNroActuacion nuevaDiagramacion()
buscarDias()
obtenerExportacionImp()
habilitarVentana() tomarConfirmacion() buscarFechas()
mostarDatosDiaFestival() tomarConfirmacionExportacion() buscarSectoresDisponibles()
opcionGenerarDiagramacion() contarAsistenciaPorDia()
tomarDatosActuación()
solicitarConfirmacion() contarAsistenciaTotal()
tomarDiaFestival()
solicitarDatosActuacion() crearDiaFestival()
tomarFestival()
solicitarSeleccionDiaFestival() crearDiagramacionParaDia()
tomarGrupo()
solicitarSeleccionFestival() tomarTipoExportacionSeleccionada() cuantosDiasDura()
solicitarSeleccionGrupoMusical() verificarRestricciones() estaVigente()
tomarConfirmacion() existeFestival()
tomarDiaFestival() getDiaFestival()
tomarDuracion() getFechaFinFestival()
tomarFestival() getPrecioEntrada()
tomarGrupoMusical() getTipoDeEntrada()
tomarHoraInicio() mostrarDatos()
tomarOrdenActuacion() mostrarDiasFestival()
new()
obtenerFechaVencimientoParaDia()
obtenerPrecioEntradaParaDiaSectorYTipoDeEntrada()
tieneDiagramacion()
validarFechaParaVtaAnticipada()
«entity»
Actuación «entity»
DiaFestival
duracionActuacion
grupoMusical :GrupoMusical completa
horaInicio diagramacion :Actuación
numeroOrden disponibilidadButaca :DisponibilidadButaca
fecha
getGrupoMusical() 0..*
new() fechaLimiteAnulacionEntrada
fechaVtoVtaAnticipada
horaPresentacion 1..*
precioEntrada :PrecioEntrada
1 actualizarEstadoButaca()
«entity» bloquearButaca()
GrupoMusical buscarButacasDisponibles()
cantIntegrantes buscarFilaYSectorDeButaca()
descripcion buscarSectores()
nombre calcularCantPublicoPorTipoEntrada()
calcularPorcentajeAsistencia()
getNombre() contarCantGrupoMusical()
contarCantidadPublico()
crearDiagramacion()
estaDiagramado()
getDatos()
getDiagramacion()
getFecha()
getFechaVencimientolAnticipada()
getPrecio()
getSectoresDisponibles()
getTiposDeEntrada()
new()
obtenerPrecioParaSectorYTipoDeEntrada()
verificarVtoFechaAnticipada()

Vista dinámica con Diagrama de Comunicación para el escenario del curso normal del Caso de uso
5 Registrar Festival

Vista dinámica con diagrama de Secuencia para el escenario del curso normal del Caso de uso 5
Registrar Festival

Vista dinámica con diagrama de Secuencia (con fragmentos sin asteriscos) para el escenario del
curso normal del Caso de uso 5 Registrar Festival

Vista dinámica con diagrama de Secuencia para el escenario del Caso de uso 5 Registrar Festival-
Existe Festival registrado con los datos identificatorios ingresados

Vista de la estructura de Análisis para el caso de uso Administración de Festival

Máquina de Estados para la Clase ButacaParaDiaFestival
stm Domain Objects

47- Validar Fin de Día de Festival
[y la fecha no está vencida]
/validarFecha()
1- Registrar Venta de Entradas
/bloquear()
44 - Registrar Habilitación de Venta
/new() Disponible Bloqueda
1- Registrar Venta de Entrada

[y la venta no se confirmó]
/desbloquear()
1- Registrar Venta de Entradas
47- Validar Fin de Día de Festival [y la venta se confirmó]
/validarFecha() /venderButaca()
EnFechaVencida
32- Registrar Anulación de Venta 48- Validar Fin de Período de

de Entrada Anulación de Venta de Entrada
/anularVenta() Vendida
[y no finalizó el periodo de
anulación de venta de entrada]
/validarFecha()
48 - Validar Fin de Período de Anulación de Venta de Entrada [y

finalizó el periodo de anulación de venta de entrada]
Ocupada /validarFecha()

Universidad Tecnológica Nacional – Facultad Regional Córdoba
Ejercicio: Modelado del Dominio del Problema
Consigna: Identificar y modelar abstracciones de un dominio de problema

tomando como punto de partida diferentes representaciones de la
realidad a modelar.
Objetivo: Que el alumno adquiera habilidades para identificar abstracciones
y modelarlas utilizando notación de UML para construir un
diagrama de clases.
Entradas: Conceptos teóricos sobre paradigma de objetos y UML.
Conceptos de modelado con Diagrama de Clases.
Diferentes representaciones de una realidad que serán tomadas
como base para el modelado.
Salida: Modelo de Dominio construido con un diagrama de clases.
Instrucciones: ▪ Organizarse en grupos para trabajar.

▪ Analizar todo el material disponible.
▪ Analizar la representación del dominio del problema que se le
entregó al grupo.
▪ Construir un diagrama de clases que represente el dominio del
problema presentado al grupo, especificando atributos y
métodos para las clases y multiplicidad y navegabilidad para las
relaciones.
▪ Dibujarlo en un papel afiche el modelo obtenido.
▪ Elegir un representante del grupo para presentar el resultado del
trabajo.
▪ Presentar el modelo obtenido al grupo clase.
▪ Debatir con el grupo clases respecto de los modelos obtenidos
Observaciones: n/a
Autor: Judith Meles / Cecilia Massano/ Florencia Bene – Versión 1.7

1
Descripción del dominio del problema en prosa
Se describe a continuación el funcionamiento de la playa de estacionamiento de la Facultad Regional

Córdoba de la UTN y del sistema de información que le da soporte. En este estacionamiento hay sectores
diferenciados por tipo de vehículo (motos/automóviles), con un valor de tarifa para cada tipo de vehículo.
En ninguno de los casos se asignan lugares específicos para los vehículos, las personas que ingresan al
estacionamiento deberán ubicar su vehículo en el lugar que se encuentre disponible.
Las tarifas están diferenciadas por tipo de vehículo. Si la persona tiene abono, puede tener hasta el valor
de dos estacionamientos como saldo negativo, que se descontarán de la siguiente vez que acredite dinero
en su cuenta. Las personas que así lo decidan pueden comprar un abono de estacionamiento, que hace
que el valor de cada estacionamiento sea más económico que si paga cada vez que ingresa a la playa. La
persona se dirige al Área de Administración de la Playa y entrega una cantidad de dinero que se acredita
en su cuenta. Si es la primera vez, debe registrar sus datos personales del propietario (apellido, nombre,
dni), y los datos del o los vehículos (marca, modelo, dominio), con los cuales desea ingresar a la playa de
estacionamiento. A partir de la segunda vez que necesite acreditar dinero informa su DNI y la cantidad de
dinero y se le cobra. El comprobante (ticket) que se entrega como constancia del cobro tiene los siguientes
datos: apellido y nombre del propietario, DNI, fecha y hora de la transacción, monto acreditado y monto
disponible en su cuenta, los números de dominio de todos los vehículos registrados de ese propietario y
un número único de identificación del comprobante.
La persona mientras tenga crédito puede ingresar a la playa con cualquiera de los vehículos registrados. Si
la persona tiene abono, puede tener hasta el valor de dos estacionamientos como saldo negativo, que se
descontarán de la siguiente vez que acredite dinero en su cuenta.
En cualquier momento puede agregar y/o cambiar los vehículos con los que ingresará a la playa de
estacionamiento.
El valor del estacionamiento es por el día completo, sin límite de tiempo ni inferior ni superior, es decir se
paga un ingreso diario, que es válido independientemente de la cantidad de ingresos que haga durante el
mismo día y del tiempo que permanezca en la playa.
Se puede ingresar a la playa por varios portones de ingreso, cuando se desea ingresar un vehículo en la
playa, personal de control de ingreso identifica el vehículo con el dominio, y emite un comprobante que
contiene: dominio del vehículo, apellido y nombre del dueño del vehículo, el valor del ingreso, la fecha de
ingreso y el saldo disponible. También se informa el número de ingreso del día. El primer ingreso del día se
cobra, descontando del saldo disponible. A partir del segundo ingreso en adelante, el monto debe figurar
en cero y se debe informar el número de ingreso, por ejemplo: “Segundo ingreso del día”. También se debe
identificar el nombre del portón de ingreso y el nombre del usuario que esté logueado.
Para las personas que desean ingresar a la playa de estacionamiento sin tener el abono de pago anticipado,
se les emite un comprobante con el monto cobrado, monto que se cobra en ese momento. Los datos del
comprobante en ese caso son: dominio del vehículo, monto, fecha de ingreso, número de vez que ingresa
a la playa de estacionamiento, usuario logueado, fecha y hora y portón por el que ingresa. Si el vehículo no
está registrado se guarda en el ingreso el dominio del vehículo y se informa como observación que no está
registrado.

2
Descripción del dominio del problema con viñetas
Se describe a continuación el funcionamiento de la playa de estacionamiento de una Facultad de una Universidad

pública y del sistema de información que le da soporte.
• Pueden estacionar distintos tipos de vehículos (motos/automóviles), cada uno con una tarifa de ingreso
diferente. Si tiene abono el precio es menor.
• Se puede ingresar a la playa de estacionamiento por varios portones de ingreso diferentes.
• No se asignan lugares específicos para los vehículos, las personas que ingresan al estacionamiento deberán
ubicar su vehículo en el lugar que se encuentre disponible.
• Los interesados pueden comprar un abono de estacionamiento, de pago anticipado que hace que el valor de
cada estacionamiento sea más económico que si paga cada vez que ingresa a la playa. Debe informar su DNI y
la cantidad de dinero que desea acreditar.
• Si es la primera vez, debe registrar sus datos personales (apellido, nombre, DNI), y los datos del o los vehículos
(marca, modelo, dominio), con los cuales desea ingresar a la playa de estacionamiento.
• Una vez registrado el propietario, cada vez que necesite acreditar dinero informa su DNI y la cantidad de dinero
y se le cobra entregándole un comprobante donde consta: apellido y nombre, DNI, fecha de la transacción,
monto acreditado y monto disponible en su cuenta.
• El comprobante (ticket) que se entrega como constancia del cobro tiene los siguientes datos: apellido y nombre
del propietario, DNI, fecha y hora de la transacción, monto acreditado y monto disponible en su cuenta, los
dominios de todos los vehículos registrados de ese propietario y un número único de identificación del
comprobante.
• Puede tener hasta dos ingresos sin crédito, es decir saldo negativo, que se descontarán de la siguiente vez que
acredite dinero en su cuenta.
• La persona mientras tenga crédito puede ingresar a la playa con cualquiera de los vehículos registrados.
• La persona puede en cualquier momento agregar y/o cambiar los vehículos con los que ingresará a la playa de
estacionamiento.
• El valor del estacionamiento es por el día completo, sin límite de tiempo ni inferior ni superior, es decir se paga
un ingreso diario, que es válido independientemente de la cantidad de ingresos que haga durante el mismo día
y del tiempo que permanezca en la playa.
• Al ingresar un vehículo con abono se le entrega a la persona un comprobante que contiene: dominio del
vehículo, apellido y nombre del dueño del vehículo, el valor del ingreso, la fecha de ingreso y el saldo disponible.
También se informa el número de ingreso del día. El portón por el que ingresa y el usuario logueado.
• El primer ingreso del día se cobra, descontando del saldo disponible. A partir del segundo ingreso del día en
adelante, el monto debe figurar en cero y se debe informar el número de ingreso, por ejemplo: “Segundo
ingreso del día”.
• A las personas que desean ingresar a la playa de estacionamiento sin tener el abono de pago anticipado, se les
cobra al momento del ingreso, registrando como observación dominio del vehículo, entregándoles un
comprobante con el monto cobrado, los datos del comprobante en ese caso son: dominio del vehículo, monto,
fecha de ingreso, número de vez que ingresa a la playa de estacionamiento, usuario logueado, fecha y hora y
portón por el que ingresa.
• Si el vehículo no está registrado se guarda en el ingreso el número de dominio del vehículo y se informa como
observación que no está registrado.
• Si la persona tiene abono, puede tener hasta el valor de dos estacionamientos como saldo negativo, que se
descontarán de la siguiente vez que acredite dinero en su cuenta.

3
Descripción del dominio del problema con formas de salida

diferenciados para los distintos tipos de vehículos (motos y automóviles). En ninguno de los casos se
asignan lugares específicos para los vehículos, las personas que ingresan al estacionamiento deberán
ubicar su vehículo en el lugar que se encuentre disponible. Las tarifas están diferenciadas por tipo de
vehículo y si tiene abono el precio es menor. Si la persona tiene abono, puede tener hasta el valor de dos
estacionamientos como saldo negativo, que se descontarán de la siguiente vez que acredite dinero en su
cuenta.
A continuación, se presentan algunas salidas que genera el sistema de información vinculadas a las
transacciones de ingreso a la playa de estacionamiento (Figuras 1, 2, 3 y 4), y a la transacción de carga de
dinero como abono (Figuras 5 y 6):
Figura 1: Figura 2: Figura 3:
Figura 4: Figura 5: Figura 6:

4
Descripción del dominio del problema con prototipos

diferenciados para los distintos tipos de vehículos (motos y automóviles). En ninguno de los casos se
asignan lugares específicos para los vehículos, las personas que ingresan al estacionamiento deberán
ubicar su vehículo en el lugar que se encuentre disponible. Las tarifas están diferenciadas por tipo de
vehículo y si tiene abono el precio en menor. Si la persona tiene abono, puede tener hasta el valor de dos
estacionamientos como saldo negativo, que se descontarán de la siguiente vez que acredite dinero en su
cuenta.
A continuación, se presentan algunos prototipos de interfaces del sistema de información:
Prototipo 1: Registrar Propietarios y sus Vehículos

5
Prototipo 2: Cobro de abono de estacionamiento

6
Prototipo 3: Registrar Ingreso a Establecimiento:

7
Descripción del dominio del problema definiendo el SI y los casos de uso esenciales

Córdoba de la UTN. En este estacionamiento hay un sector para motos y otro sector para automóviles. En
ninguno de los casos se asignan lugares específicos para los vehículos, las personas que ingresan al
estacionamiento deberán ubicar su vehículo en el lugar que se encuentre disponible.
A continuación, se presenta la definición del sistema de información que le da soporte a la playa de
estacionamiento en términos de objetivo, alcances y listado incompleto de casos de uso con una breve
descripción:
Objetivo:
Gestionar el cobro anticipado del estacionamiento de vehículos (abonos) en la playa de
estacionamiento, así como también el ingreso y egreso de vehículos con o sin abono.
Alcances:
 Administración de Propietarios.
 Administración de Vehículos.
 Gestión de cobro anticipado de estacionamientos (abonos).
 Gestión de Ingreso/Egreso de Vehículos a la playa.
 Administración de Portones de Ingreso a la Playa.
 Administración de Tarifas de Estacionamiento por Tipo de Vehículo.
 Administración de Usuarios y Permisos.

8
Listado de Casos de Uso esenciales:
Nro. Nombre del Caso de Uso Breve Descripción

1. Registrar Propietario Registrar el nombre, apellido y DNI de un propietario de uno o más
vehículos que desean comprar abono de estacionamiento anticipado.
2. Registrar Vehículo Registrar el tipo (automóvil o moto), dominio, marca y modelo de un
vehículo que va a ingresar al estacionamiento con abono anticipado.
3. Registrar Cobro de abono de Registrar el cobro de dinero por abono de estacionamiento a un
estacionamiento propietario registrado. Se emite un comprobante con DNI y nombre de
propietario, vehículos registrados con los cuales ingresar, fecha y hora
de cobro, monto cobrado, saldo actual, número de comprobante y
descripción.
4. Registrar Ingreso de Vehículo Registrar el ingreso de un vehículo a la playa de estacionamiento,
actualizando el saldo registrado, y validando que no se supere el
margen permitido de saldo negativo. Se emite un comprobante de
ingreso que informa monto cobrado, fecha y hora de ingreso, portón
por el que ingresa, nro. de ingreso del día (a partir del segundo ingreso)
y usuario logueado. A partir del segundo ingreso en el día no se debe
descontar el monto correspondiente.
Si el vehículo no está registrado se guarda en el ingreso el dominio del
vehículo y se informa como observación que no está registrado.
5. Registrar Egreso de Vehículo Registrar la salida de un vehículo de la playa de estacionamiento,
registrando la fecha y hora de salida.
6. Registrar Portón de Ingreso Registrar el nombre y la descripción de un portón de ingreso a la playa
de estacionamiento.
7. Registrar tarifa de Registrar una tarifa de estacionamiento para un vehículo en función
estacionamiento del tipo de vehículo y en función de si tiene o no abono (los ingresos
con abono tienen una tarifa menor).
8. Registrar Usuario Registrar el nombre de usuario, nombre, apellido y DNI de una persona
que utilizará el sistema.
9. Asignar Permiso a usuario Registrar la asignación de uno o más permisos a un usuario del sistema.
10. Registrar Permiso Registrar un permiso a una funcionalidad del sistema.
11. Registrar Tipo de Vehículo Registrar datos de un tipo de vehículo al que se la asigna una tarifa de
ingreso y la cantidad de ingresos con saldo negativo permitidos.

9
Modelo de Dominio Propuesto

class Modelo de Dominio
Propietario
apellido
dni
nombre AbonoPropietario
conocerAbono() fecha
conocerSaldoDisponible() 0..*hora
conocerVehiculo() montoCobrado
cuantosIngresosPeriodo() abono nroComprobante
getApellido() saldoActual
getDni() calcularSaldoActual()
getNombre() conocerIngreso()
obtenerVehiculosPropietario() usuario
setApellido()
ingreso 0..* 1
setDni()
setNombre() Ingreso Usuario
vehiculo codigoBarra apellido 1..*
1..*
fechaEgreso nombre permiso Permiso
Vehiculo fechaIngreso usuario nombreUsuario descripción
horaEgreso password nombre
dominio vehiculo 1
horaIngreso
conocerModelo() conocerPermisos()
0..1 monto
nroTicket
observacion
conocerPorton() tarifa
Tarifa
modelo 1 conocerTarifa()
conocerUsuario() 1 cantidadIngresosSinSaldo
Modelo esDeAbono
conocerVehiculo()
nombre determinarNroIngreso() fecha
montoIngreso
modelo 1..*
conocerTipoVehiculo()
portón 1
1..*
Portón tarifa
Marca descripción
nombre nombre TipoVehículo
conocerModelo() descricpión
tipoVehiculo
nombre
Referencias de colores:
Clases rosas: SOPORTE
Clases amarillas: TRANSACCIONES
Clase celeste: DEFINICIÓN DE NEGOCIO
Clases verdes: COSAS Y ROLES

10
Proyecto Prá ctico de Aplicació n

Nombre del Proyecto Práctico de Aplicación: Administración de Campos
El objetivo del proyecto es desarrollar el modelado de un software de administración de campos, a partir de una
descripción del dominio. Sólo se muestran algunas vistas de los procesos de requerimientos, análisis y diseño del
software, que se consideran prioritarias para destacar ciertos aspectos del producto que se construirá.
 Analizar los sistemas de información mediante el paradigma de Orientación a Objetos.

 Realizar la construcción de un Modelo de Análisis como base para la construcción de una arquitectura robusta
del sistema.
 Manejar las herramientas de modelado que brinda UML para la construcción de Modelos de Solución (Análisis
y Diseño) a partir del Modelo de Requerimientos
 Identificar requerimientos no funcionales y su impacto en la arquitectura.
 Modelar la arquitectura del producto utilizando patrones arquitectónicos.
 Resolver situaciones problemáticas del diseño con patrones de diseño.
 Mapear diagramas de clases a BDR.
 Analizar y modelar cambios en los requerimientos y su impacto en los modelos existentes.

 Modelado de Dominio.
 Diseño Arquitectónico – Patrones Arquitectónicos
 Patrones de Diseño
 Mapeo de estructuras de clases a bases de datos relacionales.
 Diseño de Interfaces de Usuario
 Requerimientos de Cambio.

1- Construya el modelo de dominio utilizando un diagrama de clases, especificando clases con sus atributos,
métodos y relaciones con su multiplicidad y navegabilidad.
2- Construya para el caso de uso “Registrar Laboreos en Lotes”:
a. Diagrama de Secuencia: Curso Normal.
b. El diagrama de clase de análisis asociado.
3- Construya para el caso de uso “Generar Reporte de Proyectos de Cultivo” las realizaciones de casos de uso de
análisis:
a. Diagrama de Comunicación: Escenario del Curso Normal.
b. El diagrama de clase de análisis asociado.
4- Identifique la aplicación de patrones GRASP.
Nombre del Documento: PPA_Administración de Campos.docx – Versión 1.40

Autor/es: Mónica Lovay/Judith Meles / Cecilia Massano / María Sol Zanel Página 1
5- Construya el diagrama de máquina de estado para la clase “Proyecto de Cultivo”.

6- Identificar al menos 7 requerimientos no funcionales y especificar la información solicitada, en función de la
siguiente tabla.
Nº Nombre Descripción Categoría Subcategoría Significativo para la Prioridad Explicación
Arquitectura
7- Identificar al menos 2 patrones arquitectónicos relevantes y construir una representación gráfica de los
mismos.
8- Construir las siguientes vistas arquitectónicas, definiendo para cada vista el punto de vista asociado:
Vista Arquitectónica de la funcionalidad.
Vista Arquitectónica de Diseño: Componentes e Interfaces
Vista Arquitectónica del Despliegue: Nodos y subsistemas principales
9- Realice la vista de la estructura (diagrama de clases de diseño) y la vista dinámica (diagrama de secuencia) de
los dos patrones que resuelvan las siguientes consideraciones. Incluir el pseudo-código o una explicación
textual que muestre la forma de ejecución del patrón:
a) Resuelva me diante l a aplicación del pat rón de dis eñ o adecuado las sigui entes
func ionalidades:
- Búsqueda de los campos que están habilitados
- Búsqueda de los lotes pertenecientes al campo seleccionado que tengan proyectos de cultivo
vigente
- Búsqueda de Proyectos de Cultivos Vigentes de cada Lote del Campo seleccionado
b) Resolver utilizan do el patr ón de diseño más conveniente l a siguie nte pro blem ática:
El reporte de proyectos podrá obtenerse en pantalla, archivo o impreso. Resuelva la forma de creación
del reporte teniendo en cuenta esta restricción, considerando la generación del encabezado, grilla de
proyectos (detalle) y pie de página del reporte.
NOTA: Modelar la dinámica sólo para la generación del reporte en forma impresa.
c) Resolver me diante la apli cac ión de u n patr ón de diseño, l a f orma de asegur ar que
exista una únic a c ola de impr esión en la Administrac ión C entr al de Agro S.R.L para
evitar pr obl emas al imprimir los reportes de c ultivo.
10- Diseñe las interfaces asociadas a los casos de uso descriptos a trazo fino.
11- Construir el Modelo de Datos relacional a partir del mapeo de las clases persistentes del modelo de clases,
utilizando como herramienta el DER (Diagrama de Entidad Relación).
12- Dado el requerimiento de cambio que se describe a continuación, realizar un análisis del impacto de cambio
en los modelos y luego
a. Modificar el modelo de dominio para incluir los cambios requeridos.
b. Identificar los casos de uso que se agregar y/o modifican como consecuencia del cambio solicitado
El cliente ha solicitado que el sistema:
 administre las restricciones de siembra relacionadas con los cultivos y la cantidad y frecuencia
de veces que un cultivo puede sembrarse en un mismo lote.
 informe de estas restricciones al momento de crear un proyecto de cultivo.
 genere un reporte de proyectos de cultivo que no cumplen con las restricciones de cultivo para
un período de tiempo.

Criterios de evaluación del PPA (Si aplica): no aplica

Agro SRL es una empresa que tiene varios campos ubicados en la zona de la provincia de Córdoba. La Administración
central de la empresa está localizada en uno de esos campos, donde deberá instalarse el servidor del sistema, y los
demás campos funcionarán como estaciones de trabajo remotas. Para establecer la comunicación entre el servidor y
las estaciones de trabajo de deberá realizar una red privada virtual (VPN). Se requiere para los puestos de trabajo en
los campos que cuenten únicamente con una conexión de internet y que la aplicación, desarrollada con tecnología
Web, pueda operar bajo cualquiera de los siguientes navegadores: Internet Explorer 11, Mozilla Firefox 51.0.1 y Google
Chrome v56.0 (y versiones superiores).
Cada uno de los campos de la empresa está compuesto por lotes que se identifican con un número de lote y cuya
superficie se expresa en hectáreas (has.). Cada lote tiene asignado un Tipo de Suelo. Los Tipos de Suelo se identifican
con números (desde el 1 al 5) y están definidos a nivel nacional (de acuerdo a los porcentajes de minerales, existencias
de lagunas, etc.). De acuerdo al tipo de suelo varían los cultivos que se pueden aplicar (Ej.: Suelo Tipo 1 apto para Soja,
Maní, Girasol). Cuando se decide sembrar un cultivo en un lote (comienza un nuevo proyecto de cultivo para ese lote)
deben realizarse una serie de laboreos en éste, antes y después de efectuar la siembra hasta el momento de la cosecha.
Tanto los laboreos como los momentos de laboreo y el orden en el que los momentos de laboreo se realizan, dependen
del cultivo (Ej.: para Soja los laboreos son Arar, Rastrillar, Sembrar, Escardillar, Cosechar). La división del campo en
lotes puede modificarse, es decir subdividir en más lotes un campo o unir lotes en uno sólo, esto último siempre que
tengan el mismo tipo de suelo.
Una de las necesidades que plantea la empresa respecto del software que se debe construir es que debe permitir
visualizar para cada cultivo cuales son los laboreos ideales que deben llevarse a cabo y el momento en que deben
realizarse. Para los cultivos que necesitan fumigaciones el sistema debe sugerir para cada posible plaga (langosta,
hongo) el agroquímico y la dosis a aplicar por hectárea.
Otro de los requerimientos planteados apunta a que se pueda saber para cada lote cuáles fueron los proyectos de
cultivo efectuados y los laboreos efectuados en cada uno.
Cuando se inicia un proyecto de cultivo en un lote se realizan una serie de laboreos (arar, rastrillar, rolar, fumigar,
dependiendo del cultivo), en ese momento el proyecto está en preparación. Luego se realiza la siembra del cultivo. Si
por alguna razón el cultivo no nace, puede sembrarse nuevamente o bien abandonarse (cancelarse) el proyecto de
cultivo. Luego de que el cultivo ha nacido, también deben efectuarse una serie de laboreos (fumigar, escardillar, etc.),
se dice que el proyecto está en la etapa de laboreo post siembra. Cuando el cultivo está maduro, se realiza la cosecha
del mismo con lo cual finaliza el proyecto. En cualquier momento, por alguna situación anormal (incendio, inundación,
piedra, sequía) el cultivo puede llegar a dañarse al punto de tener que cancelar el proyecto de cultivo.
Para todos los reportes e informes estadísticos que emitirá el sistema, se requiere que sean visualizados tanto en
formato de grilla como en formato gráfico, y que puedan ser exportarlos a Excel y PDF.
El sistema deberá contemplar que cada usuario acceda mediante una clave, la misma deberá contener como mínimo
6 caracteres alfanuméricos y deberá estar encriptada.
A los usuarios se les asignarán perfiles que determinarán a qué funcionalidades tendrá acceso y esto debe verificarse
en el momento del logueo.
Se deberá desarrollar un Módulo Mobile que permita enviar información de los proyectos de cultivos a dispositivos
móviles (tablets y teléfonos inteligentes) y también mediante los mismos actualizar el estado de las labores realizadas.
El Módulo Mobile deberá comunicarse con el Servidor Web de las Administración Central mediante el protocolo de
comunicación HTTP, como si fuera un sitio WEB. Además, el sistema deberá procesar diferentes tipos de datos de
rendimiento registrados con los Controles y Monitores del mercado actual (AGCO (Fieldstar), John Deere (Greenstar),
etc.) para producir informes de gestión y generar mapas de rendimiento. Para ello, deberá importar datos en distintos

tipos de formatos provenientes de los Monitores (dispositivos que se conectan a las cosechadoras), los cuales registran
entre otras cosas la humedad del suelo, el rendimiento, cantidad de combustible, etc.
Agro SRL ha requerido que la base de datos de la aplicación sea desarrollada en Oracle 12c debido a que cuentan con
licencias de ese motor de base de datos.
Glosario
Término Definición
Tipo de Laboreo Define cada uno de los trabajos que deben realizarse para poder obtener la cosecha
de un cultivo durante la vigencia de un proyecto de cultivo iniciado en un lote. Los
tipos de laboreos dependen del cultivo.
Momento de Laboreo Instante de tiempo en el que se recomienda realizar un tipo de laboreo. Los tipos de
laboreo pueden variar de momento y orden, de acuerdo al cultivo.
(Ej.: para Trigo escardillar a 1 mes de sembrado)
Proyecto de Cultivo Conjunto de actividades coordinadas y organizadas con fechas de inicio y fin
definidas cuyo propósito es la obtención de la cosecha de un determinado cultivo en
un lote determinado.

Especificación de los Requerimientos afectados al desarrollo del proyecto (Si aplica)

Definición del Producto afectado al desarrollo del proyecto
Objetivo del Producto
Administrar un conjunto de campos y los proyectos de cultivos que se realizan en cada uno de sus lotes, como así
también los laboreos que se realizan en el contexto de cada proyecto; brindando información vinculada a la gestión.
Requerimientos Funcionales (Alcances)

 Administración de Campos y Lotes
 Administración de Tipos de Suelo
 Administración de Cultivos
 Administración de Tipos y Momentos de Laboreo
 Administración de Plagas y tratamientos
 Administración de Agroquímicos
 Gestión de los Proyectos de Cultivo y Laboreos
 Administración de usuarios, perfiles y permisos de usuario
 Generación de estadísticas de rendimiento de cultivos
 Generación y Emisión de Reportes vinculados a campos, lotes y proyectos de cultivo
No contempla
 Gestión de compras de semillas y agroquímicos
Reglas de Negocio
Reglas de Negocio
Tratamiento de Una plaga se puede combatir con varios tratamientos. Cada tratamiento implica una dosis
1
Plagas específica de un agroquímico.
Cultivos para Tipos Los cultivos que pueden sembrarse en cada lote dependen del tipo de suelo que este
2
de Suelo tenga.
Tanto los laboreos como los momentos de laboreo y el orden en el que los momentos de
Laboreos para laboreo se realizan, dependen del cultivo (Ej.: para Soja los laboreos son Arar, Rastrillar,
3
Cultivo Sembrar, Escardillar, Cosechar).
Estados del Un proyecto de cultivo puede estar en un único estado en un momento determinado y sus
4
Proyecto cambios de estado dependen de los laboreos que se realizan en el lote.
Proyectos de
5 Un proyecto de cultivo está asociado a un único lote.
Cultivo

Reglas de Negocio
Un campo está compuesto por uno o más lotes. Los lotes pueden cambiar su configuración
Relación
6 uniéndose unos con otros o dividiéndose. Se debe controlar que la superficie del campo
Campo/Lote
sea la correcta al momento de la creación y/o modificación de los lotes que lo componen.
Lotes y tipos de
7 Un lote tiene un único tipo de suelo.
suelo

(Los casos de uso sombreados están especificados)
Nro. CU Nombre Objetivo
1. Registrar Laboreos en Lotes Registrar uno o más laboreos realizados para cada Lote
seleccionado de un campo.
2. Generar Reporte de Proyectos de Generar un reporte de los proyectos de cultivo en función
Cultivo de un conjunto de filtros aplicados
3. Modificar Laboreos en Lotes Modificar uno o más laboreos realizados a un lote
4. Consultar Laboreos en Lotes Consultar uno o más laboreos realizados para cada lote
5. Cancelar Laboreos en Lotes Registrar la cancelación de uno o más laboreos realizados
para cada lote seleccionado de un campo.
6. Registrar Usuario Registrar los datos de una persona que tendrá acceso al
sistema.
7. Iniciar Sesión Crear una sesión de trabajo para un usuario registrado en
el sistema y verificar los permisos de acceso a las
funcionalidades del software.
8. Cerrar Sesión Cerrar una sesión de trabajo iniciada por un usuario
registrado en el sistema.
9. Modificar Usuario Modificar los datos permitidos de un usuario.
10. Eliminar Usuario Eliminar un usuario y sus permisos asociados.
11. Consultar Usuario Brindar información sobre uno o más usuarios y sus
permisos asignados
12. Registrar Campo Registrar los datos de un campo y todos los lotes que este
contiene.
13. Modificar Campo Modificar los datos permitidos de un campo y/o de los
lotes que este contiene.
14. Consultar Campo Consultar los datos de uno o más campos y de todos los
lotes que este contiene.
15. Eliminar Campo Eliminar un campo y todos los lotes que este contiene.
16. Registrar Tipo de Suelo Registrar los datos asociados a un tipo de suelo.
17. Modificar Tipo de Suelo Modificar los datos permitidos de un tipo de suelo.
18. Consultar Tipo de Suelo Consultar los datos de uno o más tipos de suelo.
19. Eliminar Tipo de Suelo Eliminar de un tipo de suelo.


20. Registrar Estado Registrar las características de un estado.
21. Modificar Estado Modificar los datos permitidos de un estado.
22. Eliminar Estado Eliminar un estado registrado.
23. Consultar Estado Consultar información sobre uno o más estados
registrados.
24. Registrar Cultivo Registrar las características de un cultivo
25. Modificar Cultivo Modificar los datos permitidos de un cultivo.
26. Eliminar Cultivo Eliminar un cultivo registrado.
27. Consultar Cultivo Consultar los datos de uno o más cultivos.
28. Registrar Empleado Registrar los datos personales de un empleado.
29. Modificar Empleado Modificar los datos permitidos de un empleado.
30. Eliminar Empleado Eliminar un empleado registrado.
31. Consultar Empleado Consultar información sobre uno o más empleados
registrados.
32. Registrar Tipo de Laboreo Registrar los datos de un tipo de laboreo.
33. Modificar Tipo de Laboreo Modificar los datos permitidos de un tipo de laboreo
34. Eliminar Tipo de Laboreo Eliminar un tipo de laboreo registrado.
35. Consultar Tipo de Laboreo Brindar información sobre uno o más tipos de laboreo
36. Asignar Laboreos para Cultivo Realizar la asignación de laboreos y los momentos de
laboreo apropiados para un cultivo.
37. Consultar Asignación de Laboreos para Consultar las asignaciones de laboreos registradas para
Cultivo un cultivo.
38. Registrar Momento de Laboreo Registrar los datos de un momento de laboreo.
39. Modificar Momento de Laboreo Modificar los datos permitidos de un momento de
laboreo.
40. Eliminar Momento de Laboreo Eliminar un momento de laboreo registrado.
41. Consultar Momento de Laboreo Brindar información sobre uno o más momentos de
laboreo.
42. Registrar Plaga Registrar los datos de una plaga.
43. Modificar Plaga Modificar los datos permitidos de una plaga.
44. Consultar Plaga Consultar información sobre una o más plagas.
45. Eliminar Plaga Eliminar los datos de una plaga
46. Registrar Agroquímico Registrar los datos de un agroquímico para el tratamiento
de plagas.
47. Modificar Agroquímico Modificar los datos permitidos de un agroquímico.
48. Consultar Agroquímico Consultar información sobre uno o más agroquímicos.
49. Eliminar Agroquímico Eliminar los datos de un agroquímico.
50. Registrar Tratamiento para Plaga Registrar los datos de un tratamiento para plagas.
51. Modificar Tratamiento para Plaga Modificar los datos permitidos de un tratamiento para
plagas.
52. Consultar Tratamiento para Plaga Consultar información sobre uno o más tratamientos
para plagas.
53. Eliminar Tratamiento para Plaga Eliminar los datos de un tratamiento para plagas.
54. Registrar Permiso Registrar un permiso que se asociará a un usuario.
55. Modificar Permiso Modificar los datos permitidos de un permiso.


56. Eliminar Permiso Eliminar un permiso registrado.
57. Consultar Permiso Consultar información sobre uno o más permisos
registrados en el sistema.
58. Registrar Asignación de Permisos a Registrar la asignación de permisos a un usuario.
Usuario
59. Consultar Permisos de Usuario Consultar información sobre uno o más permisos
asignados a un usuario.
60. Eliminar Permisos de Usuario Realizar la eliminación lógica de los permisos de un
usuario.
61. Generar Reporte de Tratamientos Generar un informe de tratamientos disponibles para una
para Plagas o más plagas.
62. Generar Histórico de Proyectos de Generar un reporte que muestre para un período de
Cultivo por Campo/Lote tiempo, los proyectos de cultivo realizados para un
campo/lote
63. Registrar Rol Registrar un rol que se asociará a los usuarios del sistema.
64. Modificar Rol Modificar los datos permitidos de un rol.
65. Eliminar Rol Eliminar un rol registrado.
66. Consultar Rol Consultar información sobre uno o más roles registrados
en el sistema.
67. Registrar Proyecto de Cultivo Registrar los datos de un proyecto de cultivo que se
realizará en un lote de un campo.
68. Modificar Proyecto de Cultivo Modificar los datos permitidos de un proyecto de cultivo
que se realizará en un lote de un campo.
69. Consultar Proyecto de Cultivo Consultar los datos de uno o más proyectos de cultivo.
70. Cambiar Password Registrar un cambio de palabra clave realizado por un

usuario.
71. Cancelar Proyecto de Cultivo Registrar la situación de abandono de un proyecto de
cultivo.
72. Importar Archivo de Monitor Importar un archivo generado por un Monitor que
contiene datos de rendimiento.
73. Generar Estadística de Rendimiento Generar estadística comparativa que muestre para un
de Lotes período de tiempo, el rendimiento de los cultivos
cosechados en los campos/lotes.
74. Generar Reporte de Laboreos en Generar un reporte de laboreos realizados en uno o más
Proyectos proyectos de cultivo.

Diagramas de Casos de Uso – Vista esencial
uc CU Esenciales
67. Registrar
Proyecto de
12 Registrar 24. Registrar Cultivo
Campo Cultivo Este caso de
uso podría no
estar en la
vista esencial
16. Registrar
Tipo de Suelo 72. Importar
Archivo de
Monitor
1 Registrar
Laboreos en Administrador
un Lote 42. Registrar 36. Asignar
Plaga De Campos Laboreos para
Cultivo
50. Registrar 73. Generar

Tratatamiento Estadística de
para Plaga Rendimiento de
Lotes
2. Generar
74. Generar Reporte de
Encargado De 46. Registrar Reporte de Proyectos de
Laboreos Agroquímico Laboreos en Cultivo
Proyectos

Diagramas de Casos de Uso – Vista por alcances
Administración de Tipos y Momentos de Laboreo

uc Adm Tipos Momentos Laboreo
32. Registrar Tipo de 33.Modificar Tipo de 36. Asignar Laboreos

35. Consultar Tipo de Laboreo para Cultiv o
Laboreo
Laboreo
34. Eliminar Tipo de

Laboreo
Administrador De Campos
37.Consultar Asignación de
Laboreos para Cultiv o
40. Eliminar Momento de

Laboreo 39. Modificar
Momento de Laboreo
41. Consultar
38. Registrar Momento
Momento de Laboreo
de Laboreo

Administración de Cultivos Administración de Tipos de Suelo

uc Adm Cultiv os
uc Adm Tipos Suelo
24. Registrar Cultiv o

16. Registrar
Tipo de Suelo
25. Modificar Cultiv o 17. Modificar

Tipo de Suelo
Administrador De Campos
Administrador
26. Eliminar Cultiv o De Campos
18. Consultar
Tipo de Suelo
27. Consultar Cultiv o 19. Eliminar

Tipo de Suelo
Adminsitración de Plagas y Tratamientos
uc Adm Plagas Tratamientos
44. 43.Modificar 42. Registrar 53. Eliminar

Consultar Plaga Plaga Tratamiento
Plaga para Plaga
52. Consultar
45. Eliminar Tratamiento para
Plaga Plaga
Administrador 51. Modificar

46. Registrar De Campos Tratamiento
Agroquímico para Plaga
50. Registrar
Tratatamiento
47.Modificar 48.Consultar
Agroquímico 49. Eliminar para Plaga
Agroquímico Agroquímico

Gestión de Proyectos de Cultivo y Laboreo
uc Gestión Proy Cultivo Laboreos
3. Modificar
67. Registrar 69. Consultar 22.Eliminar Laboreos en
Proyecto de Proyecto de Estado Lotes
Cultivo Cultivo
1 Registrar
Laboreos en un
Lote
20. Registrar
68. Modificar Estado
Proyecto de
Cultivo Administrador Encargado De 5.Cancelar
De Campos Laboreos Laboreos en
21. Modificar Lotes
Estado
4. Consultar
Laboreos en
71. Cancelar Lotes
Proyecto de
Cultivo 23.
Consultar
72. Importar Estado
Archivo de
Monitor
Generación de Reportes
uc Reportes
73. Generar
Estadística de
62. Generar
Rendimiento de
61. Generar Reporte Histórico de
Lotes
de Tratamientos para Proyectos de Cultivo
Plagas por Campo/Lote
74. Generar
Administrador Reporte de
De Campos Laboreos en
Proyectos
2. Generar
Reporte de
Proyectos de
Cultivo

Administración de Usuarios y Permisos
uc Administracion Usuarios
29.Modificar 28. Registrar 31.

Empleado Empleado Consultar 11.
Empleado Consultar
30. Eliminar Usuario
66. 7. Iniciar
Consultar Empleado Sesión
Rol 55. Modificar
Permiso
65. Eliminar
Rol 8. Cerrar
9. Modificar Sesión
Usuario
63. Registrar
Rol
Administrador
de Sistema 70. Cambiar
Usuario Password
56. Eliminar 10. Eliminar
Permiso Usuario
57. Consultar
Permiso
6. Registrar 64. Modificar
Usuario Rol
58. Registrar Encargado De Administrador

Laboreos De Campos
Asignación de
Permisos a 60. Eliminar 54. Registrar
Usuario Permisos de Permiso
Usuario
59. Consultar
Permisos de
Usuario
Administración de Campos
object Adm de Campos
15 Eliminar
Campo
Administrador
De Campos
14 Consultar
13 Modificar Campo
Campo
12 Registrar
Campo

Especificación de Casos de Uso
Nombre del Caso de Uso: Registrar Laboreos en Lotes Nro. De Orden: 1
Actor Principal: Encargado de Laboreos (EL) Actor Secundario: No Aplica

Tipo de Caso de Uso: Concreto Abstracto
Objetivo: Registrar uno o más laboreos realizados para cada Lote seleccionado de un campo.
Precondiciones: usuario logueado
Post- Condiciones: Éxito: Laboreo/s realizado/s registrado/s.
Fracaso 1: No existe ningún proyecto de cultivo vigente para los lotes seleccionados.
Fracaso 2: El EL cancela el caso de uso.
Fracaso 3: El EL no confirma la registración del/los laboreo/s.
Fracaso 4: No existe ningún campo habilitado.
1. EL: Comienza cuando selecciona la opción Registrar
Laboreos en un Lote
2. Sistema: muestra el nombre de todos los campos 2.A. Sistema: no encuentra campos habilitados.
habilitados y solicita se seleccione uno. 2.A.1. Sistema: informa la situación
2.A.2. Sistema: se cancela el caso de uso.
3. EL: selecciona el campo para el cual quiere registrar el
laboreo.
4. Sistema: busca los lotes que corresponden a ese 4.A. Sistema: busca lotes que corresponden a ese
campo que tengan Proyecto de Cultivo vigente campo que tengan Proyecto de Cultivo vigente
(significa que no esté en estado final) y encuentra al (significa que no esté en estado final) y no encuentra
menos uno. De cada uno de ellos muestra el número ninguno.
de lote y la fecha de Inicio del proyecto vigente y 4.A.1. Sistema: muestra un mensaje informando la
solicita que se seleccionen los lotes para los que quiere situación
registrar laboreos. 4.A.2. Se cancela el caso de uso
5. EL: selecciona uno o más lotes.
6. Sistema: Para cada lote elegido muestra el nombre del
cultivo y los laboreos efectuados en ese lote,
correspondientes al proyecto vigente.
7. Sistema: busca y muestra los tipos de laboreo
aplicables al cultivo.
8. Sistema: Para cada laboreo que se desea registrar
solicita que seleccione alguno.
9. EL: selecciona un laboreo.
10. Sistema: solicita se ingrese la fecha y hora de
comienzo, fecha y hora de fin del laboreo.

Nombre del Caso de Uso: Registrar Laboreos en Lotes Nro. De Orden: 1
11. EL: ingresa la fecha y hora de comienzo, fecha y hora

de fin del laboreo.
12. Sistema: valida las fechas y horas de inicio y fin del 12.A. Sistema: Las fechas y/u horas no son correctas.
laboreo y son correctos. (ver observación 2) 12.A.1. Sistema: muestra un mensaje informando la
situación y solicita que se ingresen nuevamente.
12.A.2. EL: ingresa nuevamente los datos.
13. Sistema: muestra los empleados y solicita se seleccione
el empleado que efectuó el laboreo.
14. EL: selecciona el empleado.
15. Sistema: Para cada laboreo a registrar solicita
confirmación para efectuar el registro.
16. EL: confirma el registro. 16.A. EL: no confirma el registro.
16.A.1. Sistema: Se cancela el caso de uso.
17. Sistema: registra el laboreo realizado con los siguientes
datos: fecha comienzo, hora comienzo, fecha fin, hora
fin, empleado que lo efectuó, laboreo realizado.
18. Sistema: Valida el tipo de laboreo, y NO es siembra ni 18.A. Sistema: El tipo de laboreo es siembra.
cosecha. 18.A.1. Sistema: Actualiza el estado del proyecto de
cultivo a En Siembra.
18.B. Sistema: El tipo de laboreo es cosecha.

18.B.1. Sistema: Actualiza el estado del proyecto de
cultivo a Cosechado.
19. EL: Selecciona la opción para finalizar el registro de
laboreos.
20. Fin del caso de uso.
Observaciones:
1. El EL puede cancelar el caso de uso en cualquier momento eligiendo la opción para tal fin.
2. Valida fecha de inicio menor que la fecha de fin y que no sean mayores a la fecha del día.
Asociaciones de Extensión: No aplica
Asociaciones de Inclusión: No aplica
Asociaciones de Generalización: No aplica

Paquete: N/A
Nombre del Caso de uso: Registrar Laboreos en Lotes Nro. de Orden: 1
Actor Principal: Encargado de Laboreos (EL) Actor Secundario: no aplica
Tipo de Caso de uso: Concreto Abstracto

Objetivo: Registrar uno o más laboreos realizados para cada Lote seleccionado de un campo.
Flujo Básico
1. EL: selecciona la opción Registrar Laboreos en un Lote
2. Sistema: muestra el nombre de todos los campos habilitados y solicita se seleccione uno.
3. EL: selecciona el campo para el cual quiere registrar el laboreo
4. Sistema: busca los lotes que corresponden a ese campo que tengan Proyecto de Cultivo vigente (significa que
no esté en estado final) y encuentra al menos uno. De cada uno de ellos muestra el número de lote y la fecha
de Inicio del proyecto vigente y solicita que se seleccionen los lotes para los que quiere registrar laboreos.
5. EL: selecciona uno o más lotes.
6. Sistema: Para cada lote elegido muestra el nombre del cultivo y los laboreos efectuados en ese lote,
correspondientes al proyecto vigente.
7. Sistema: busca y muestra los tipos de laboreo aplicables al cultivo.
8. Sistema: Para cada laboreo que se desea registrar solicita que seleccione alguno.
9. EL: selecciona un laboreo.
10.Sistema: solicita se ingrese la fecha y hora de comienzo, fecha y hora de fin del laboreo.
11.EL: ingresa la fecha y hora de comienzo, fecha y hora de fin del laboreo.
12.Sistema: valida las fechas y horas de inicio y fin del laboreo y son correctos. (ver observación 2)
13.Sistema: muestra los empleados y solicita se seleccione el empleado que efectuó el laboreo.
14.EL: selecciona el empleado.
15.Sistema: Para cada laboreo a registrar solicita confirmación para efectuar el registro.
16.EL: confirma el registro.
17.Sistema: registra el laboreo realizado con los siguientes datos: fecha comienzo, hora comienzo, fecha fin, hora
fin, empleado que lo efectuó, laboreo realizado.
18.Sistema: Valida que el tipo de laboreo no sea siembra ni cosecha.
19.EL: Selecciona la opción para finalizar el registro de laboreos. Fin del caso de uso.
Flujos Alternativos
A1: No existe ningún proyecto de cultivo vigente para los lotes seleccionados.
A2: El actor decide cancelar el caso de uso.
A3: El actor no confirma registro de laboreos.
A4: El tipo de laboreo es siembra.
A5: El tipo de laboreo es cosecha.
A6: Las fechas y/u horas de inicio y fin de laboreo no son correctas.

Observaciones:
1. El actor puede cancelar el caso de uso en cualquier momento eligiendo la opción para tal fin.
2. Valida fecha de inicio menor que la fecha de fin y que no sean mayores a la fecha del día.
Nombre del Caso de Uso: Generar Reporte de Proyectos de Cultivo Nro. De Orden: 2
Actor Principal: Administrador de Proyectos (ADM) Actor Secundario: No Aplica

Objetivo: Generar un reporte de los proyectos de cultivo en función de un conjunto de filtros aplicados.
Precondiciones: usuario lo gueado .
Post- Condiciones: Éxito 1: Reporte de Proyectos generado e impreso.
Éxito 2: Reporte de Proyectos generado y visualizado en pantalla.
Éxito 3: Reporte de Proyectos generado y archivo guardado.
Éxito 4: Informe de Reporte de Proyectos sin datos encontrados para los filtros
seleccionados.
Fracaso 1: El ADM no confirma los filtros aplicados.
Fracaso 2: El ADM cancela la operación.
1. ADM: Comienza cuando selecciona la opción Generar
Reporte de Proyectos.
2. Sistema: Busca los campos habilitados, los muestra, y
solicita al usuario que seleccione los campos para los que
quiere generar el reporte.
3. ADM: Selecciona los campos para los que se quiere
generar el reporte (pueden seleccionarse todos los
campos).
4. Sistema: Busca los lotes asociados a los campos
seleccionados y los muestra, solicitando que se
seleccionen los lotes para los que se quiere generar el
reporte (pueden seleccionarse todos).
5. ADM: Selecciona los lotes para los que quiere generar el
reporte.
6. Sistema: Busca los cultivos y tipos de suelos existentes y
solicita que se seleccionen.
7. ADM: Selecciona los cultivos y tipos de suelo para los que
8. Sistema: Solicita el periodo para el cual se desea generar
el reporte.

9. ADM: Ingresa el período.

10. Sistema: Valida que se ingrese un período y que sea 10.A. Sistema: El período ingresado no es válido.
válido (la fecha desde sea menor que la fecha hasta) y lo 10.A.1. Sistema: Solicita se ingrese nuevamente el
es. período.
10.A.2. ADM: Ingresa el período.
10.B. Sistema: Verifica que no se ingresó período.

10.B.1. Sistema: Solicita que se ingrese el período.
10.B.2. ADM: Ingresa el período.
11. Sistema: Solicita confirmación de los filtros aplicados.
12. ADM: Confirma la generación del reporte con los filtros 12.A. ADM: No confirma la generación del reporte
aplicados. con los filtros aplicados.
12.A.1. Sistema: Se cancela el caso de uso.
13. Sistema: Busca en función de los filtros y el período 13.A. Sistema: No encuentra datos que cumplan
seleccionado la siguiente información: para cada lote del con el criterio.
campo muestra el tipo de suelo, los cultivos de los 13.A.1. Sistema: Genera el reporte sin datos e
proyectos de cultivo que se han aplicado en el periodo informa la situación.
solicitado, el estado de cada proyecto de cultivo, la fecha 13.A.2. Sistema: Fin del caso de uso.
de inicio y fin de cada proyecto de cultivo, y encuentra
datos que cumplan el criterio.
14. Sistema: Solicita se seleccione la forma de visualización
para el reporte.
15. ADM: selecciona la opción de visualización impresión en 15.A. ADM: Selecciona la opción de visualización
papel por pantalla.
15.A.1. Sistema: Muestra la información.
15.A.2 Fin del caso de uso.
15.B. ADM: Selecciona la opción de visualización

en archivo.
15.B.1. Sistema: solicita se ingrese el nombre para
el archivo y seleccione el lugar para almacenarlo.
15.B.2. ADM: Ingresa nombre de archivo y
selecciona el lugar para almacenarlo.
15.B.3 Sistema: genera el archivo.
15.B.4. Sistema: Fin del caso de uso.
16. Sistema: Imprime el Reporte de Proyectos.
17. Sistema: Fin de caso de uso.
Observación: El ADM puede cancelar la operación seleccionando la opción correspondiente en cualquier
momento.
Asociaciones de Extensión, Inclusión y Generalización: No aplican

Paquete: n/a
Nombre del Caso de Uso: Generar Reporte de Proyectos de Cultivo Nro. De Orden: 2
Actor Principal: Administrador de Proyectos (ADM) Actor Secundario: No Aplica

Objetivo: Generar un reporte de los proyectos de cultivo en función de un conjunto de filtros aplicados.
Flujo Básico
1. ADM: Comienza cuando selecciona la opción Generar Reporte de Proyectos.
2. Sistema: Busca los campos habilitados, los muestra, y solicita al usuario que seleccione los campos para los que
3. ADM: Selecciona los campos para los que se quiere generar el reporte (pueden seleccionarse todos los campos).
4. Sistema: Busca los lotes asociados a los campos seleccionados y los muestra, solicitando que se seleccionen los
lotes para los que se quiere generar el reporte (pueden seleccionarse todos).
5. ADM: Selecciona los lotes para los que quiere generar el reporte.
6. Sistema: Busca los cultivos y tipos de suelos existentes y solicita que se seleccionen.
7. ADM: Selecciona los cultivos y tipos de suelo para los que quiere generar el reporte.
8. Sistema: Solicita el periodo para el cual se desea generar el reporte.
9. ADM: Ingresa el período.
10.Sistema: Valida que se ingrese un período y que sea válido (la fecha desde sea menor que la fecha hasta) y lo es.
11.Sistema: Solicita confirmación de los filtros aplicados.
12.ADM: Confirma la generación del reporte con los filtros aplicados.
13.Sistema: Busca en función de los filtros y el período seleccionado la siguiente información: para cada lote del
campo muestra el tipo de suelo, los cultivos de los proyectos de cultivo que se han aplicado en el periodo
solicitado, el estado de cada proyecto de cultivo, la fecha de inicio y fin de cada proyecto de cultivo, y encuentra
datos que cumplan el criterio.
14.Sistema: Solicita se seleccione la forma de visualización para el reporte.
15.ADM: selecciona la opción de visualización impresión en papel
16.Sistema: Imprime el Reporte de Proyectos. Fin del Caso de Uso.
Flujos Alternativos
A1. El período ingresado no es válido.
A2. No se ingresó período.
A.3 El Actor no confirma la generación del reporte con los filtros aplicados.
A.4. No se encuentran datos que cumplan con el criterio de filtro aplicado.
A.5. Opción de visualización del reporte por pantalla.
A.6. Opción de visualización del reporte en archivo.
Observaciones:
1. El ADM puede cancelar la operación seleccionando la opción correspondiente en cualquier momento.

Nombre del Caso de Uso: Registrar Campo Nro. De Orden: 12

Actor Principal: Administrador de Campos (AC) Actor Secundario: No Aplica

Categoría: Esencial Soporte Significativo para la Arquitectura: Si No
Objetivo: Registrar los datos de un campo y todos los lotes que este contiene.
Precondiciones: Usuario logueado con perfil de administrador
Post- Condiciones: Éxito 1: Campo y al menos un lote registrados.
Fracaso 1: El AC selecciona la opción cancelar.
Fracaso 2: El AC no confirma los datos.
1. El caso de uso comienza cuando el AC selecciona la opción
“Registrar Campo”.
2. Sistema: Solicita se ingrese el nombre del Campo.
3. AC: Ingresa el nombre del Campo.
4. Sistema: Valida que el nombre del Campo no se repita para 4.A. Sistema: Valida que el nombre del Campo no se
otro Campo ya registrado, y no se repite. repita para otro Campo ya registrado, y se repite.
4.A.1. Sistema: Informa la situación y permite el
ingreso de otro nombre para el Campo.
5. Sistema: Solicita se ingrese la superficie del Campo (ver
observación 2).
6. AC: Ingresa la superficie del Campo.
7. Sistema: Para cada lote solicita el ingreso de los datos del
lote (ver observación 3).
8. AC. Ingresa el número de lote
9. Sistema: valida que el número de lote no se repita con otro 9.A. Sistema: valida que el número de lote no se
ingresado previamente para ese campo y no se repite. repita con otro ingresado previamente para ese
campo y se repite.
9.A.1 Sistema: Informa la situación y permite el
ingreso de otro número para el lote.
10. Sistema: solicita se ingrese la superficie del lote.
11. AC: ingresa la superficie del lote. (ver observación 2).
12. Sistema: solicita se seleccione el tipo de suelo del lote
13. AC: selecciona el tipo de suelo

14. Sistema: Muestra los datos de cada lote registrado para

ese Campo y solicita se informe fin de ingreso de lotes.
15. AC: informa fin de ingreso de lotes
16. Sistema: valida que la suma de todas las superficies de los 18.A. Sistema: valida que la sume de todas las
lotes coincida con la superficie total del campo y coincide superficies de los lotes coincida con la superficie total
del campo y NO coincide.
18.A.1. Sistema: informa la situación y permite se
corrija la superficie de los lotes.
17. Sistema: solicita confirmación para registrar campo
18. AC: confirma el registro del campo y sus lotes 20.A. AC: No confirma el registro del campo y sus
lotes.
20.A.1. Sistema: Cancela caso de uso
19. Sistema: Valida la existencia de los datos obligatorios y 21.A. Sistema: valida la existencia de datos
registra un nuevo Campo con los siguientes datos: requeridos y falta alguno.
a. Nombre (obligatorio). 21.A.1. Sistema: informa la situación y permite se
b. Superficie (obligatorio). ingresen los datos obligatorios faltantes.
c. Lote/s (obligatorio al menos uno).
i. Número (obligatorio)
ii. Superficie (obligatorio)
iii. Tipo de Suelo (obligatorio)
20. Fin del caso de uso.
Observaciones:
1. El AC puede cancelar la operación en cualquier momento.
2. La superficie está en hectáreas, no se aceptan nulos.
3. Se debe ingresar al menos un lote.
Requerimientos no Funcionales Asociados: No Aplica
6. Relación Campo/Lote
7. Lotes y tipos de suelo
Asociaciones de Inclusión: No Aplica
Asociaciones de Extensión: No Aplica
Use case donde se incluye: No Aplica
Use Case al que extiende: No Aplica
Use Case de Generalización: No Aplica

Paquete: n/a
Nombre del Caso de uso: Registrar Campo Nro. de Orden: 12
Actor Principal: Administrador de Campo (AC) Actor Secundario: no aplica

Objetivo: Registrar los datos de un campo y todos los lotes que este contiene.
Flujo Básico
1. AC: selecciona la opción “Registrar Campo”.
2. Sistema: Solicita se ingrese el nombre del Campo.
3. AC: Ingresa el nombre del Campo.
4. Sistema: Valida que el nombre del Campo no se repita para otro Campo ya registrado, y no se repite.
5. Sistema: Solicita se ingrese la superficie del Campo (ver observación 2).
6. AC: Ingresa la superficie del Campo.
7. Sistema: Para cada lote solicita el ingreso de los datos del lote (ver observación 3).
8. AC. Ingresa el número de lote
9. Sistema: valida que el número de lote no se repita con otro ingresado previamente para ese campo y no se
repite.
10. Sistema: solicita se ingrese la superficie del lote.
11. AC: ingresa la superficie del lote. (ver observación 2)
12. Sistema: solicita se seleccione el tipo de suelo del lote
13. AC: selecciona el tipo de suelo
14. Sistema: Muestra los datos de cada lote registrado para ese Campo y solicita se informe fin de ingreso de lotes.
15. AC: informa fin de ingreso de lotes
16. Sistema: valida que la suma de todas las superficies de los lotes coincida con la superficie total del campo y
coincide
17. Sistema: solicita confirmación para registrar campo
18. AC: confirma el registro del campo y sus lotes
19. Sistema: Valida la existencia de los datos obligatorios y registra un nuevo Campo con los siguientes datos:
1. Nombre y Superficie (obligatorios).
2. Lote/s (obligatorio al menos uno) con: Número, superficie y tipo de suelo obligatorios.
Fin del caso de uso.
Flujos Alternativos
A1: El nombre del Campo se repita para otro Campo ya registrado.
A2: El número de lote se repita con otro ingresado previamente para ese campo.
A3: La suma de las superficies de los lotes no coincide con la superficie total del campo.
A4: El AC no confirma la registración del campo y sus lotes.
A5: Faltan datos mínimos requeridos.

Observaciones:
1. El AC puede cancelar la operación en cualquier momento.
2. La superficie está en hectáreas, no se aceptan nulos.
3. Se debe ingresar al menos un lote.

Solución Propuesta
Modelo de Dominio:

Vista de Análisis: Registrar Laboreos en Lotes

class Modelo de Analisis Registrar Laboreos
«control»
«boundary» GestorLaboreos
PantAdmLaboreos
- empleados
- campoSeleccionado - laboreosARegistrar
- comboCampos - laboreosRealizados
- grillaLaboreosARegistrar - lotesCampo
- grillaLaboreosRealizados - lotesCampoElegidos
- lblCampos - tipoLaboreos
- lblCultivoElegido «entity»
+ buscarCampos() Empleado
- lblLaboreosARegistrar + buscarEmpleados()
- lblLaboreosRealizados - apellido
+ buscarInfoProyectoVigente()
- lblLotes + buscarLaboreosRealizados() - nombre
- listaLotes
+ buscarLotes() + getApellido()
- listaLotesElegidos
+ buscarTiposLaboreosParaCultivo() + getEmpleado()
+ habilitarVentana() + finCU() + getNombre()
+ mostrarCultivo() + nuevoLaboreo()
+ mostrarLaboreosPosibles() + tomarConfirmacion() 1
+ mostrarLaboreosRealizados() + tomarDuracionLaboreo()
+ mostrarLotesConProyectoCultivo() + tomarEmpleado()
+ opcionRegLaboreoLote() + tomarOpciónFinalizar()
+ pedirConfirmacionRegistracion() + tomarSeleccionCampo()
«entity»
+ pedirDuracionLaboreo() + tomarSeleccLaboreo()
Laboreo
+ pedirSeleccEmpleado() + validarTipoLaboreo()
+ pedirSeleccionCampo() - empleado: Empleado
+ pedirSeleccionLaboreo() - fechaFin
+ tomarConfirmacion() - fechaInicio
«entity» - horaFin
+ tomarFechaHoraFin()
+ tomarFechaHoraInicio() Campo - horaInicio
+ tomarSeleccionCampo() - habilitado - ordenLaboreo: OrdenDeLaboreo
+ tomarSeleccionEmpleado() - lote: Lote + conocerEmpleado()
+ tomarSelecciónFinalizar() - nombre + conocerOrdenLaboreo()
+ tomarSeleccionLotes() + mostrarLaboreo()
+ buscarLotes()
+ tomarSeleccLaboreo() + new()
+ buscarLotesProyCultivo()
+ validarFechas()
+ buscarProyectosDeCultivo()
+ buscarTipoDeSueloDeLote() 0..*
+ buscarTipoLaboreosParaCultivo()
+ calcularTotalHas()
«entity» + conocerLote()
Lote + crearLaboreosParaProyecto()
- numero + crearLote()
- proyectoCultivo: ProyectoDeCultivo + estaHabilitado()
- tamañoHas + existeNombre()
«entity»
- tipoSuelo: TipoSuelo + getNombre()
1..* ProyectoDeCultivo
+ mostrarCultivo()
+ buscarLaboreosParaCultivo() + new() - cultivo: Cultivo
+ buscarLaboreosRealizados() - estado: Estado
+ buscarProyectosDeCultivo() - fechaFin: Date
+ conocerProyectoDeCultivo() - fechaInicio: Date
+ conocerTipoSuelo() - laboreo: Laboreo
+ crearLaboreos() - observaciones: String
+ getDatosProyecto()
+ getNumero() + abortar()
+ getTipoDeSuelo() + buscarLaboreosPosibles()
+ mostrarCultivo() 0..* + buscarLaboreosRealizados()
+ mostrarFechaInicioProyVigente() + conocerCultivo()
+ new() + conocerEstado()
+ tieneProyectoCultivoVigente() «entity» + conocerLaboreo()
Estado + cosechar()
+ crearLaboreos()
1 - descripcion + esDeCultivo()
«entity» - final 1 + esDePeríodo()
TipoSuelo - nombre + estaVigente()
+ esFinal() + getCultivo()
- descripcion
+ getNombre() + getEstado()
- nombre
+ getFechaInicio()
- numero
+ getFechasProyecto()
+ getNombre() + laborear()
+ laborearLuegoDeSiembra()
1..* + mostrarCultivo()
+ new()
+ sembrar()
+ validarRestricciónDeCultivo()
«entity»
Cultivo
1 1
- nombre
- ordenLaboreo: OrdenDeLaboreo «entity»
- tipoSuelo: TipoSuelo OrdenDeLaboreo
+ buscarTiposLaboreo() - momentoLaboreo: MomentoLaboreo
+ conocerLaboreoParaCultivo() - orden
+ conocerOrdenLaboreo() 0..* - tipoLaboreo: TipoLaboreo
+ conocerRestriccionCultivo() «entity» + conocerMomentoLaboreo()
+ conocerTipoSuelo() MomentoLaboreo + conocerTipoLaboreo()
+ conocerTratamiento() + mostrarLaboreoParaCultivo()
+ cultivoSiguienteDefinido() - descricpcion
+ getNombre() - nombre 1
+ mostrarMomentoLaboreo() «entity»
TipoLaboreo
1
- descripcion
- nombre
+ mostrarTipoLaboreo()

Diagrama de Secuencia: Registrar Laboreo s en Lotes: Escenario del Curso Normal o Fluj o
Básico
sd 01 Registrar Laboreos en un Lote Curso Normal
:Encargado De
Laboreos : : :Campo seleccionado: :Lote : vigente: :Laboreo :Estado :Cultivo :Laboreo : : : :Empleado
opcionRegLaboreoLote() PantAdmLaboreos GestorLaboreos Campo ProyectoDeCultivo ProyectoDeCultivo OrdenDeLaboreo TipoLaboreo MomentoLaboreo
habilitarVentana()
nuevoLaboreo()
buscarCampos()
*estaHabilitado()
*getNombre()
pedirSeleccionCampo()
tomarSeleccionCampo()
tomarSeleccionCampo()
buscarLotes()
buscarLotesProyCultivo()
loop Lotes con Proyecto de Cultivo Vigente

[Mientras haya lotes]
tieneProyectoCultivoVigente()
*estaVigente()
esFinal()
getNumero()
mostrarFechaInicioProyVigente()
getFechaInicio()
mostrarLotesConProyectoCultivo()
tomarSeleccionLotes()
tomarSeleccionLotes()
buscarInfoProyectoVigente()
loop Para cada lote seleccionado mostrarCultivo()

[mientras haya lotes] mostrarCultivo()
mostrarCultivo()
getNombre()
mostrarCultivo()
buscarLaboreosRealizados()
buscarLaboreosRealizados() *buscarLaboreosRealizados()
buscarLaboreosRealizados()
*mostrarLaboreo()
mostrarLaboreoParaCultivo()
mostrarTipoLaboreo()
mostrarLaboreosRealizados()
buscarTiposLaboreosParaCultivo()
buscarTipoLaboreosParaCultivo()
*buscarLaboreosParaCultivo()
buscarLaboreosPosibles()
buscarTiposLaboreo() *mostrarLaboreoParaCultivo()
mostrarMomentoLaboreo()
mostrarTipoLaboreo()
mostrarLaboreosPosibles()
loop Para cada laboreo

[mientras haya laboreos para registrar]
pedirSeleccionLaboreo()
tomarSeleccLaboreo()
tomarSeleccLaboreo()
pedirDuracionLaboreo()
tomarFechaHoraInicio()
tomarFechaHoraFin()
validarFechas()
tomarDuracionLaboreo()
buscarEmpleados() *getEmpleado()
getApellido()
pedirSeleccEmpleado() getNombre()
tomarSeleccionEmpleado()
tomarEmpleado()
pedirConfirmacionRegistracion()
tomarConfirmacion()
tomarConfirmacion()
crearLaboreos()
crearLaboreosParaProyecto()
crearLaboreos()
crearLaboreos()
*new()
:Laboreo
validarTipoLaboreo()
tomarSelecciónFinalizar()
tomarOpciónFinalizar()
finCU()

Diagrama de Clases de Análisis para el caso de uso 02 Ge nerar Reporte de Proyectos de

Cultivo
«entity» «control» «boundary»

Cultivo GestorReporteProyectos PantallaReporteProyectos
- nombre - camposSeleccionados - gestor
- tipoSuelo: TipoSuelo - cultivosSeleccionados - girllaCampo
+ buscarTiposLaboreo() - fechaFin - grillaCultivo
+ conocerLaboreoParaCultivo() - fechaInicio - grillaLote
+ conocerOrdenLaboreo() - formaVisualización - grillaProyecto
+ conocerRestriccionCultivo() - lotesSeleccionados - grillaTipoSuelo
+ conocerTipoSuelo() - proyectosFiltrados - impresor
+ conocerTratamiento() - tiposDeSuelosSeleccionados - txtFechaFin
+ cultivoSiguienteDefinido() - txtFechaInicio
+ buscarCampos()
+ getNombre() + buscarCultivos() + mostrarLotes()
+ buscarLotesDeCampo() + habilitarVentana()
1 + buscarProyectos() + mostrarCampos()
+ buscarTiposDeSuelo() + mostrarCultivos()
1..* + mostrarTiposDeSuelo()
+ confirmar()
«entity» + finCU() + solicitarConfirmaciónDeFiltros()
«entity» TipoSuelo + imprimirReporte() + solicitarFormaDeVisualización()
ProyectoDeCultivo + tomarCampos() + solicitarPeríodo()
- descripcion
- cultivo: Cultivo + tomarCultivos() + tomarIngresoFechaFin()
- nombre
+ tomarFechas() + tomarIngresoFechaInicio()
- estado: Estado - numero
- fechaFin: Date + tomarFormaDeVisualización() + tomarSelecciónCampos()
+ getNombre() + tomarLotes() + tomarSelecciónCultivos()
- fechaInicio: Date
- observaciones: String + tomarSelecciónGenerarReporteProyectos() + tomarSelecciónFormaDeVisualización()
1 + tomarTiposDeSuelo() + tomarSelecciónGenerarReporteProyectos()
+ buscarLaboreosPosibles() + tomarSelecciónLotes()
+ buscarLaboreosRealizados() + tomarSelecciónOpciónConfirmación()
+ conocerCultivo() + tomarSelecciónTiposDeSuelo()
+ conocerEstado() + validarFechas()
+ conocerLaboreo()
+ crearLaboreos()
+ esDeCultivo()
+ esDePeríodo()
+ estaVigente()
+ getCultivo()
+ getEstado()
+ getFechaInicio() 0..*
+ getFechasProyecto() «entity»
«boundary»
+ mostrarCultivo() Campo
ImpresorReporteProyectos
+ new() «entity» - habilitado
+ validarRestricciónDeCultivo() Lote + imprimir()
- lote: Lote
+ new()
- numero - nombre
- proyectoCultivo: ProyectoDeCultivo + buscarLotes()
- tamañoHas + buscarLotesProyCultivo()
- tipoSuelo: TipoSuelo + buscarProyectosDeCultivo()
+ buscarLaboreosParaCultivo() + buscarTipoDeSueloDeLote()
+ buscarLaboreosRealizados() + buscarTipoLaboreosParaCultivo()
+ buscarProyectosDeCultivo() + calcularTotalHas()
1..* + conocerLote()
+ conocerProyectoDeCultivo()
+ conocerTipoSuelo() + crearLaboreosParaProyecto()
1 + crearLaboreos() + crearLote()
«entity» + getDatosProyecto() + estaHabilitado()
Estado + getNumero() + existeNombre()
+ getTipoDeSuelo() + getNombre()
- descripcion + mostrarCultivo()
+ mostrarCultivo()
- final + new()
+ mostrarFechaInicioProyVigente()
- nombre
+ new()
+ esFinal() + tieneProyectoCultivoVigente()
+ getNombre()

Página 28
Diagrama de Comunicación – Generar Reporte de Proyec tos de Cultivo- Escenario del
sd 2 Generar Reporte de Proyectos

49: tomarSelecciónFormaDeVisualización() 17: *getNombre()
53: finCU()
51: imprimirReporte()
:Cultivo
32: tomarSelecciónOpciónConfirmación()
34: buscarProyectos()
50: tomarFormaDeVisualización() 52: imprimir()
28: tomarIngresoFechaFin() 19: buscarTiposDeSuelo()
33: confirmar() 16: buscarCultivos() :
27: tomarIngresoFechaInicio() 10: buscarLotesDeCampo() ImpresorReporteProyectos
30: tomarFechas()
24: tomarSelecciónTiposDeSuelo() 4: buscarCampos()
29: validarFechas() 25: tomarTiposDeSuelo()
22: tomarSelecciónCultivos() 2: habilitarVentana() 23: tomarCultivos()

14: tomarSelecciónLotes() 15: tomarLotes()
8: tomarSelecciónCampos() 9: tomarCampos()
Autor/es: Mónica Lovay/Judith Meles / Cecilia Massano / María Sol Zanel

1: tomarSelecciónGenerarReporteProyectos() 3: tomarSelecciónGenerarReporteProyectos()
20: *getNombre()
: 7: mostrarCampos() : :TipoSuelo
:
Administrador 13: mostrarLotes() GestorReporteProyectos
PantallaReporteProyectos
De Campos 18: mostrarCultivos()
38: *buscarProyectosDeCultivo()
21: mostrarTiposDeSuelo()
35: *buscarTipoDeSueloDeLote()
26: solicitarPeríodo()
48: solicitarFormaDeVisualización() 11: *buscarLotes()
31: solicitarConfirmaciónDeFiltros()
6: *getNombre()
5: *estaHabilitado() 42: *getDatosProyecto()
Curs o Normal o Flujo Básico
39: *buscarProyectosDeCultivo()
36: *getTipoDeSuelo()
12: *getNumero() 37: getNombre()
:Campo :Lote :TipoSuelo
41: *esDeCultivo()
44: *getCultivo()
43: *getFechasProyecto()
46: *getEstado() 40: *esDePeríodo()
47: getNombre()
:Cultivo 45: getNombre() :
ProyectoDeCultivo :Estado
Vista de Modelo de Clases de Análisis Administración de Campo y Lote
class M odelo de Análisis Registrar Campo
PantAdmCampo
GestorCampo
- comboTiposSuelo: int
- grillaLote: int - nombreCampo: int
- lblNombreCampo: int - numeroLote: int
- lblNroLote: int - supCampo: int
- lblSuperficieCampo: int - supLotes: int
- lblSuperficieLote: int - tiposSuelo: int
- txtNombreCampo: int - tipoSueloElegido: int
- txtNroLote: int + buscarTiposSuelo()
- txtSupCampo: int + crearCampo()
- txtTipoSuelo: int + finCU()
+ confirmarFinLotes() + finIngresoLotes()
+ habilitarVentana() + nuevoCampo()
+ mostrarLotesIngresados() + tomarConfCreacion()
+ opcionRegCampo() + tomarNombreCampo()
+ pedirConfirmacCreacion() + tomarNroLote()
+ pedirDatosLote() + tomarSuperficieCampo()
+ pedirNombreCampo() + tomarSupLote()
+ pedirSelecTipoSuelo() + tomarTipoSueloElegido()
+ pedirSuperficieCampo() + validarConsistenciaSuperficies()
+ pedirSupLote() + validarDatosMinCampo()
+ tomarConfCreacion() + validarDatosMinLote()
+ tomarConfirmacFinIngresoLotes() + validarNombreCampo()
+ tomarNombreCampo() + validarNroLote()
+ tomarNroLote()
+ tomarSelecTipoSuelo()
+ tomarSuperficieCampo()
+ tomarSupLote()
+ visualizarTiposSuelo()
Campo
Lote - habilitado
- numero - lote: Lote
- nombre
- tamañoHas
TipoSuelo - tipoSuelo: TipoSuelo + buscarLotes()
+ buscarLaboreosRealizados() + buscarLotesProyCultivo()
- descripcion + buscarProyectosDeCultivo()
- nombre + buscarProyectosDeCultivo()
+ buscarTipoDeSueloDeLote()
- numero 1 + conocerProyectoDeCultivo()
1..* + calcularTotalHas()
+ conocerTipoSuelo()
+ getNombre() + conocerLote()
+ crearLaboreos()
+ crearLaboreosParaProyecto()
+ getDatosProyecto()
+ getNumero() + crearLote()
+ estaHabilitado()
+ getTipoDeSuelo()
+ existeNombre()
+ mostrarCultivo()
+ getNombre()
+ new()
+ mostrarCultivo()
+ tieneProyectoCultivoVigente()
+ new()

Diagrama de Comunicación del Flujo básico del caso de uso 12. Registrar Campo
sd Registrar Campo Flujo Básico
39: finCU() Consideraciones para el modelado

35: crearCampo() Los mensajes de validación de datos mínimos de
34: validarDatosMinLote() campo y lotes que están por separado también
31: tomarConfCreacion() 32: tomarConfCreacion() pueden ser uno solo (33 y 34).
33: validarDatosMinCampo()
27: tomarConfirmacFinIngresoLotes() Los mensajes de visualización de tipos de suelo y
28: finIngresoLotes() 29: validarConsistenciaSuperficies()
pedir selección también pueden ser uno solo (21 y
23: tomarSelecTipoSuelo()
24: tomarTipoSueloElegido() 17: validarNroLote() 22).
19: tomarSupLote()
20: tomarSupLote() 12: buscarTiposSuelo() La validación del numero de lote repetido la hace
15: tomarNroLote() 2: habilitarVentana() 16: tomarNroLote() 7: validarNombreCampo() sólo el gestor porque los objetos lote no existen
10: tomarSuperficieCampo() 11: tomarSuperficieCampo() todavia. (17)
5: tomarNombreCampo() 6: tomarNombreCampo()
1: opcionRegCampo() 3: nuevoCampo()
8: *existeNombre()
: 4: pedirNombreCampo() :
PantAdmCampo GestorCampo :Campo
: 9: pedirSuperficieCampo()
Administrador 14: pedirDatosLote()
De Campos 18: pedirSupLote() 13: *getNombre()
21: visualizarTiposSuelo()
22: pedirSelecTipoSuelo() :TipoSuelo
25: mostrarLotesIngresados()
26: confirmarFinLotes() 36: new()
30: pedirConfirmacCreacion()
38: *new()
37: crearLote()
:Campo :Lote

Máqu ina de Esta dos para la Clase Proyecto de Cultivo

stm ProyectoDeCultiv o
1 Registrar Laboreos en Lotes [y el

laboreo es siembra =NO] /laborear()
71 Registrar Proyecto de Cultivo 1 Registrar Laboreos en Lotes [y el laboreo es siempra = SI]

/sembrar()
/new()
EnPreparación
EnSiembra 1 Registrar Laboreos en Lotes [y se
requiere sembrar = SI] /sembrar()
75 Cancelar
Proyecto de
Cultivo /abortar() 1 Registrar Laboreos en Lotes [y se requiere sembrar =
75 Cancelar Proyecto de NO]
Cultivo /abortar() /laborearLuegoDeSiembra()
75 Cancelar Proyecto de Cultivo

/abortar() 1 Registrar Laboreos en Lotes [y se
Cancelado EnPostSiembra cosecha = NO]
/laborearLuegoDeSiembra()
1 Registrar Laboreos en Lotes [y se cosecha =

SI] /cosechar()
Cosechado

Proyecto Práctico de Aplicación

Nombre del Proyecto Práctico de Aplicación: Crustáceo Cascarudo
El Proyecto Práctico de Aplicación denominado Crustáceo Cascarudo, tiene el propósito de desarrollar la
especificación de un producto de software para dar soporte a los procesos de negocios vinculados a la
gestión de un restaurante de comida rápida.
Se destaca que las vistas que se desarrollan no están completas, ni son exhaustivas, se toma de cada uno
de los modelos, elementos referenciales con la intención de reflejar ciertos aspectos destacables del
producto de software que se está construyendo.

El Proyecto Práctico de Aplicación, tiene el propósito de reflejar cada una de las actividades de modelado
requeridas para el desarrollo y construcción de un producto de software en función del proceso, las
técnicas y las herramientas que se enseñan en la Cátedra Diseño de Sistemas de Información. Este PPA
representa una simplificación de un caso real, en el cual los estudiantes podrán desarrollar las habilidades
para aplicar los conocimientos adquiridos.

 Modelo de Requerimientos como punto de partida para el modelado de la solución.
 Modelado del Comportamiento en el Análisis
 Patrones de Principios generales para asignar responsabilidades (GRASP).
 Modelado de la Estructura en el Análisis
 Diseño Arquitectónico – Patrones Arquitectónicos
 Diseño de la Estructura del software.
 Diseño del Comportamiento del Software
 Mapeo de estructuras de clases a bases de datos relacionales – Patrones de Persistencia.
 Diseño de Interfaces de Usuario
 Patrones de diseño
Consigna asociad al Proyecto Práctico de Aplicación:

En el siguiente PPA se desarrolla:
1. Modelo de Requerimientos:
a. Objetivo, alcances y reglas de negocio.
b. Modelo de Casos de Uso del Sistema de Información (Listado de Casos de Uso, Vistas de
casos de uso, descripción de actores y descripción de algunos de los casos de usos.
c. Prototipos de Interfaz de Usuario.
d. Modelo de Dominio.
e. Especificación de Requerimientos No Funcionales.
PPA Crustáceo Cascarudo – V 1.6

Autor: Mickaela Crespo Página 1
2. Modelo de Análisis:
a. Realización de Análisis de los Casos de Uso, aplicando patrones GRASP
b. Máquina de Estados.
3. Modelo Arquitectónico
a. Especificación de RNF
b. Identificación y aplicación de Patrones Arquitectónicos Significativos.
c. Realización de vistas arquitectónicas.
4. Modelo de Diseño:
a. Realizaciones de Casos de Uso de Diseño, parte estructural con diagrama de clases y parte
dinámica con diagrama de secuencia, aplicando los patrones de diseño más convenientes.
i. Realizar el rediseño necesario para modelar una solución que resuelva de forma
flexible el cálculo de la tasa de reclamos a los pedidos realizados por los clientes de
acuerdo con el método seleccionado por el actor.
ii. Resolver el proceso de creación de los reportes de tasa de reclamo en sus
diferentes formas de visualización (Por Pantalla, PDF, Excel).
iii. Resolver de forma eficiente la obtención del número secuencial que corresponde
asignar al Pedido al momento de su creación.
iv. Resolver de forma flexible la búsqueda de pedidos que correspondan a los filtros
seleccionados por el usuario para la generación del reporte de tasa de reclamo.
v. Resolver de forma flexible la búsqueda de combos de productos, productos y sus
variantes para mostrar durante la creación de pedidos.
b. Mapeo de clases a BDR.
c. Diseño de Interfaces.
Criterios de evaluación del PPA (Si aplica):
Sobre los prácticos que la cátedra utilizará se evaluarán los siguientes aspectos, vinculados al cumplimiento
de los resultados de aprendizaje:
1. Trabajo acorde a las consignas presentadas
2. Que resuelva correctamente el problema que el proyecto presenta y cumpla los objetivos definidos
para éste
3. Validar la consistencia de cada uno de los modelos que se van desarrollando.
4. Respetar los aspectos formales de la presentación del práctico.
5. Cumplir con la fecha de entrega acordada
6. Integración del grupo en la realización del trabajo

Glosario
Glosario
Tecnología que utiliza un conjunto de protocolos y estándares que sirven para
Web Service
intercambiar datos entre aplicaciones.
Protocolo estándar que define cómo dos objetos en diferentes procesos pueden
SOAP
comunicarse por medio de intercambio de datos XML.
La Administración de Federal de Ingresos Públicos (AFIP) define distintos tipos de
Impuesto al Valor Agregado (IVA). Todos los productos tienen un tipo de IVA que
puede ser:
 IVA General del 27,5%
Tipo de IVA
 IVA General del 21%
 IVA Reducido del 10%
 IVA Superreducido del 4%
 Actividad exenta del 0%
La base imponible es el monto sobre el cual se calculan los impuestos. Este monto no
contempla ningún tipo de impuesto. Es equivalente al costo de fabricar o comprar un
Base Imponible producto al proveedor más el margen de ganancia.
Si se vende un producto al público a $121 con un IVA General del 21% entonces la
base imponible es de $100.
El C.A.E. (Código de Autorización Electrónico) es un número que otorga la AFIP al
autorizar la emisión de un comprobante por web service, aplicativo RECE o por el
CAE
servicio por clave fiscal "Comprobantes en línea" ("facturas electrónicas"). Sin CAE, la
factura no tiene validez fiscal.
AFIP Administración Federal de Ingresos Públicos
Rodrigo es el dueño del Crustáceo Cascarudo, un local de comida rápida al paso que vende comida
como hamburguesas o paninis a personas que pasan por su local, en un área muy transitada de la ciudad. El
Crustáceo Cascarudo se encuentra cerca de una zona de muchas oficinas, así que Rodrigo hizo un contrato
con las empresas que trabajan cerca para proveer el almuerzo a sus empleados.
Rodrigo vende en su local distintos tipos de sándwiches, hamburguesas y panchos, así como
también papas fritas o ensaladas. Cada uno de estos productos tiene un nombre especial, un precio y un
conjunto de ingredientes para su preparación. Además de esto, la mayoría de los productos tienen
variantes, esto quiere decir que para un determinado ingrediente puede haber más de una opción (como el
tipo de pan o el tipo de carne). La variante elegida para un ingrediente en un producto no altera su precio,
es necesario identificar cual es el ingrediente con variantes para un producto y poder enumerar todas las
variantes para ese ingrediente, algunos productos tienen ingredientes por defecto en las variantes. Un
ejemplo es la hamburguesa Cangreburger, que cuesta $1200 y se prepara con lechuga, tomate, pepinillos,
queso, mayonesa, kétchup, el ingrediente secreto y además tiene variantes en el tipo de pan (que puede
ser brioche, pan mollete o pan cristal kornisptiz) y el medallón (que puede ser de carne de vaca, cerdo,
pollo o pescado). En la cangreburger los ingredientes por defecto son el pan brioche y el medallón de carne
de vaca en caso de que el cliente no especifique la variante. No todas las variantes son mutuamente
excluyentes, puede ocurrir que para unas papas la variante sea el aderezo y se desee elegir mayonesa y

kétchup. Algunas variantes pueden hacer referencia a ingredientes Premium o ingredientes que
normalmente no son parte del producto, pero se pueden agregar. Estas variantes tienen un costo extra al
agregarlas independientemente del ingrediente elegido. Por ejemplo, agregar guacamole o mostaza de
Dijon a una cangreburger.
Los clientes del Crustáceo Cascarudo pueden comprar los productos de manera individual o en
combos. Rodrigo arma estos combos con sus productos más vendidos y sus combinaciones de productos
más pedidas. Los combos son armados al principio del mes y se pega el listado con imágenes
representativas en la puerta del negocio. Los combos generalmente llevan algún tipo de sándwich, un
acompañamiento y una bebida. Para cada sándwich y acompañamiento se puede pedir cualquiera de las
variantes del producto individual; para la bebida se ofrecen 3 variantes: Coca-Cola, Coca-Cola light y agua.
Cada combo tiene un precio particular y un nombre por el cual se lo puede identificar. Un ejemplo es el
Combo Crustáceo que cuesta $1600 e incluye una Cangreburger, unas Papas Marinas y una gaseosa a
elección.
Rodrigo atiende el mostrador tomando los pedidos de las personas que pasan por el frente de su
local. Desea poder registrar el pedido en un producto de software, incluyendo todas las variantes que el
cliente pida. Rodrigo debería poder agregar alguna observación en el pedido para registrar si el cliente no
desea alguno de los ingredientes.
Un cliente podría pedir un Combo Crustáceo donde la Cangreburger tenga pan brioche, un
medallón de pollo, Mostaza de Dijon (Ingrediente Premium no incluido en el combo) y sin pepinillos. Las
Papas Marinas del combo con Kétchup y la gaseosa una Coca-Cola Light. Además del Combo Crustáceo el
cliente puede pedir un Perro Marino (un tipo de pancho) con el ingrediente Premium Salsa Picante
Calamardo y como acompañamiento los Trocitos de Coral sin salsa tártara. Rodrigo tendría que poder
registrar los 3 ítems (El combo, el Perro Marino y los Trocitos de Coral) registrando los ingredientes extra de
cada uno y el precio de cada uno.
Según una regulación de AFIP es obligatorio aceptar tarjetas de débito como medio de cobro en
cualquier local comercial, razón por la cual Rodrigo ha decido utilizar la pasarela de pagos Mercado Pago. Si
el cliente quiere pagar con tarjetas de débito o crédito, Rodrigo les pide que escaneen con la aplicación de
Mercado Pago el código QR del local. Cuando los clientes hacen esto aparece en sus celulares el logo del
Crustáceo Cascarudo, el nombre del local y el monto a pagar. Los clientes eligen dentro de la aplicación de
Mercado Pago la tarjeta con la que desean pagar y confirman el pago. A Rodrigo le llega la confirmación de
Mercado Pago indicando que el proceso se completó de manera exitosa. Los clientes pagan su pedido una
vez que reciben su pedido.
En cuanto a los clientes empresariales, en cada empresa habrá un responsable de ingresar y/o
modificar los pedidos para toda la semana, los lunes; es por esto por lo que se acordó la necesidad de un
producto de software web.
El responsable de pedidos de cada empresa registrará los pedidos con todos los detalles y
requerimientos especiales y el día de entrega de cada pedido; que estarán disponibles para que Rodrigo
consulte. Se genera un pedido para cada día de la semana.
Rodrigo tiene un acuerdo con sus clientes empresariales en donde los pedidos pueden ser editados
hasta un día antes de su fecha de entrega o hasta que se facture el pedido; ya que cada responsable de
pedidos de cada empresa puede elegir el momento en el que se facture un pedido (opciones: al crear el
pedido o en cualquier momento posterior, hasta el día de entrega del pedido). Si el responsable de pedidos
de la empresa no lo factura hasta la fecha de entrega ese pedido se factura automáticamente. Por

ejemplo, un cliente empresarial puede pedir 5 combos Cangreburger para el lunes, 5 combos Cangreburger
para el martes y 4 combos Cangreburger para el miércoles, y puede editar el pedido del miércoles
agregando o quitando combos Cangreburger hasta el martes a las 23:59 horas.
Los clientes empresariales pagan todos los pedidos a fin de mes mediante una transferencia
bancaria, al recibir la notificación del banco de que ingresó una transferencia a la cuenta, el sistema con
esos datos actualizará los pagos de los pedidos del mes.
Todos los pedidos realizados en mostrador y los pedidos empresariales para ese día deberían
mostrarse en una Tablet con sistema operativo iOS que Rodrigo compró para la cocina. Es importante saber
si un pedido es al paso o empresarial para que el cocinero pueda saber la hora de entrega de cada uno. Al
mostrar el pedido en la Tablet se debería mostrar las especificidades del pedido junto con cualquier
observación que pueda tener. A medida que el cocinero, Bob, comienza la preparación de los pedidos, lo
indicará en el producto en su dispositivo mobile. Cuando Bob termina de preparar un pedido actualiza la
situación del producto en su dispositivo mobile, del mismo modo que cuando inició la preparación. Su
asistente, Patricia, los envuelve para llevar y los lleva al mostrador. Los pedidos al paso son entregados en
el momento y se los marca de esa manera, mientras que los pedidos empresariales son guardados en un
lugar aparte.
A las 12:30 el cadete sale con todos los pedidos empresariales y Rodrigo indica para cada empresa
que sus pedidos ya se enviaron. Cuando el cadete entrega el pedido debería poder informarlo, utilizando
una aplicación en su teléfono celular. También se debe dar soporte desde el producto la posibilidad de que
un cliente empresarial que tenga una queja o un problema con un pedido pueda registrarlo, y hacer
seguimiento de la evolución de su reclamo. La gestión del reclamo es independiente del pedido y no afecta
su evolución.
Según la nueva regulación de AFIP todas las facturas que hace el Crustáceo Cascarudo deben estar
homologadas en el sistema de AFIP. Para esto AFIP provee un web service de tipo SOAP al cual se debe
enviar la información de la fecha y la hora, tipo de factura, cliente, monto total de la factura, los ítems
vendidos y el detalle del monto de cada ítem vendido. AFIP procesa cada factura y devuelve un numero de
CAE identificador de cada factura.
Dado que Crustáceo Cascarudo está registrado ante la AFIP como responsable inscripto, puede
emitir facturas de tipo A y/o B. Las facturas de tipo A sólo pueden hacerse cuando el cliente está registrado
en el sistema y su condición tributaria es Responsable Inscripto. Las Factura B se hacen a clientes
registrados con condición tributaria de Monotributista o a consumidores finales no registrados en el
sistema.
Para los clientes cuya condición es “consumidor final” en el apartado de cliente se debe enviar
“CONSUMIDOR FINAL” a AFIP sin informar el CUIT. Mientras que si se hace una factura a un monotributista
o responsable inscripto debe enviarse el nombre o razón social y su CUIT.
Es necesario cumplir con las regulaciones de facturación que dicta AFIP. En el caso de las facturas
de tipo A, el IVA debe ser discriminado. Es decir que cada ítem de la factura debe mostrase en la impresión
sin el IVA. Y al pie de la factura debe mostrarse, en el orden indicado, la base imponible totalizada, el
monto a cobrar por cada tipo de IVA y el monto total de la factura. Por otro lado, para las facturas de tipo B
no es necesario discriminar el IVA. Esto quiere decir que los ítems deben mostrarse con precio después de
impuestos y al pie de la factura debe mostrarse el monto totalizado de la factura. Cuando se envía la
información a AFIP para homologar la factura se debe enviar respetando el formato por tipo de factura.

Solución Propuesta
Definición del Producto de Software:
Objetivo del Producto de Software:

Gestionar la venta, facturación y cobro de productos individuales y combos de comida rápida, generando
información relacionada a los pedidos, cobros y reclamos.
Alcances del producto de software:
 Administración de productos individuales y combos

 Administración de clientes
 Gestión de pedidos
 Gestión de facturación de pedidos
 Gestión de cobros mediante transferencias bancarias para Clientes Empresariales y con Mercado
Pago para Clientes al paso.
 Gestión de reclamos
 Administración de usuarios
 Generación de reportes de pedidos, facturación, cobros y reclamos.
No contempla:
 Gestion de empleados
Reglas de negocio
Nombre de la RN Descripción de la RN
Cambios a pedidos Los pedidos empresariales pueden cambiarse hasta un día antes de su fecha de entrega. El
empresariales día que deben ser entregados no pueden ser editados.
Facturación AFIP Tipos de facturas que la empresa genera son: Tipo A: para clientes responsables inscriptos;
Tipo B para monotributistas.
Reclamos Únicamente para clientes empresariales, se debe crear un reclamo por pedido.
La gestión de reclamos es independiente de la gestión del pedido.
Tipos de Clientes Clientes Empresariales y Clientes al paso.
Cumplimentación Los pedidos se preparan completos, todos los detalles de pedido juntos, no se hacen
de pedidos entregas parciales.
Relación Pedido Un pedido debe facturarse todo junto, no hay facturaciones parciales. No deben facturarse
Factura múltiples pedidos juntos.
Facturación de Todos los pedidos deben ser facturados antes de comenzar su preparación, sin
pedidos excepciones.
Los pedidos por mostrador son facturados por el cajero una vez que se registró en el
sistema y el cliente decide que no cambiará su orden.
Los pedidos empresariales pueden ser facturados en cualquier momento desde su creación
por el encargado de pedidos. Si el encargado no lo hiciera de forma manual, el día de la
entrega el software lo debe facturar de forma automática.

Preparación del En la cocina deben informar cuando el pedido está en preparación y cuando está listo para
pedido ser entregado al cliente al paso o al cadete para su distribución.
El cadete debe informar los pedidos que están en reparto y los que ya entregó al cliente
empresarial.
Cancelación de un Un pedido puede cancelarse antes de que empiece su preparación, si ya estuviera
pedido facturado, la cancelación del pedido implica además la anulación de la factura asociada.
Entrega a domicilio La entrega a domicilio de productos sólo aplica a pedidos de clientes empresariales.
El cadete debe informar a los clientes empresariales cuando su pedido va en camino y debe
informar al Crustáceo Cascarudo cuando ya ha sido entregado.
Cobros a Clientes Los clientes empresariales pagan con transferencia bancaria a fin de mes y los clientes al
paso pagan con Mercado Pago luego que se les ha entregado el pedido. Todos los pedidos
pagados deben marcarse como tales.

Vista de Casos de Uso Esenciales


A continuación, se muestra un listado incompleto de CU de la aplicación descripta:
Nro. Paquete Nombre del Caso de Uso Objetivo/ Descripción Actor

1. Gestión de Registrar pedidos de la Que un cliente empresarial registre uno o más Encargado de
pedidos semana pedidos para una semana determinada. pedidos del Cliente
2. Gestión de Generar reporte de tasa de Generar un reporte estadístico que muestre la Responsable de
Informes reclamos tasa de reclamos sobre pedidos de los clientes, Reportes
para un período de tiempo, en función de
criterios predefinidos.
3. Gestión de Generar estadísticas Generar estadísticas de ganancias brutas anuales Responsable de
Informes anuales de ganancias del año en curso y estimar los valores estimados Reportes
de ganancia bruta, extrapolados, para el año
próximo.
4. Administración Registrar cliente Registrar los datos de un cliente que será usuario Responsable de
de clientes de la aplicación. Clientes
5. Administración Modificar cliente Modificar los datos permitidos de un Cliente. Responsable de
de clientes Clientes
6. Administración Consultar cliente Consultar los datos de un Cliente. Responsable de
7. Administración Eliminar cliente Dar de baja un Cliente. Responsable de
8. Administración Iniciar sesión Iniciar una sesión en el sistema, validando los Usuario
de Usuarios permisos y accesos a las funcionalidades de la (Abstracto)
aplicación según su rol.
9. Administración Cerrar sesión Cerrar una sesión en el sistema cuando el Usuario
de Usuarios usuario así lo requiera. (Abstracto)
10. Administración Registrar producto Registrar los datos de un producto que se Responsable de
de Productos ofrecerá para la venta. Carta
11. Administración Modificar producto Modificar los datos permitidos de un producto Responsable de
de Productos que se ofrecerá para la venta. Carta
12. Administración Eliminar producto Dar de baja un producto. Responsable de
de Productos Carta
13. Administración Consultar producto Consultar los datos de un producto. Responsable de
de Productos Carta
14. Administración Registrar variante Registrar los datos de variantes para un producto Responsable de
de Productos que se ofrecerá para la venta. Carta
15. Administración Consultar variante Consultar los datos de variantes para un Responsable de
de Productos producto. Carta
16. Administración Modificar variante Modificar los datos permitidos de variantes para Responsable de
de Productos un producto. Carta
17. Administración Eliminar variante Dar de baja una variante de un producto. Responsable de
de Productos Carta
18. Gestión de Registrar pedido en Que el cajero registre un pedido de un cliente en Cajero
pedidos mostrador mostrador para ese momento de tiempo.
19. Gestión de Modificar pedido en Consultar los datos de un pedido realizado en Cajero
pedidos mostrador mostrador.
20. Gestión de Modificar pedidos de la Que un cliente empresarial modifique uno o más Encargado de
pedidos semana pedidos para una semana determinada. pedidos del Cliente

21. Gestión de Consultar pedidos de la Consultar uno o más pedidos realizados para un Encargado de
pedidos semana periodo determinado pedidos del Cliente
22. Gestión de Cancelar pedido Registrar la cancelación de un pedido Creador de Pedido
pedidos (Abstracto)
23. Gestión de Consultar pedido Consultar uno a más pedidos según criterios Encargado de
pedidos predefinidos. Pedidos
24. Gestión de Iniciar preparación de Registrar que se inicia la preparación de un Responsable de
pedidos Pedido pedido con todos los detalles de pedido que Cocina
contiene.
25. Gestión de Finalizar Pedido Actualizar el estado del pedido informando que Responsable de
pedidos está preparado Cocina
26. Gestión de Registrar entrega de pedido Registrar la entrega de un pedido a un cliente, Liberador de
pedidos actualizando el estado del pedido. Pedido (Abstracto)
27. Gestión de Generar hoja diaria de visita Generar hoja de visita diaria ordenada según Encargado de
pedidos para cadete dirección de los Clientes empresariales para Pedidos
optimizar la distribución de los pedidos.
28. Gestión de Iniciar reparto de pedidos Registrar el inicio del reparto de pedidos, Cadete
pedidos actualizando el estado de los pedidos y
Notificando por WhatsApp a los encargados de
pedidos de clientes cuyos pedidos estén
incluidos en la entrega para alertarlos de que
recibirán su pedido en las próximas horas.
29. Gestión de Consultar ruta Consultar en la hoja diaria de visitas la ruta para Cadete
pedidos la entrega de los pedidos a los clientes
empresariales
30. Gestión de Generar factura para Generar la factura para un pedido realizado por Encargado de
facturación y pedidos semanales un cliente empresarial, eligiendo el pedido que pedidos del Cliente
cobros desea facturar. AFIP (Secundario)
31. Gestión de Validar facturación de Validar si existen pedidos empresariales con Tiempo
facturación y pedido empresarial entrega el día de la fecha que no han sido
cobros facturados
32. Gestión de Generar factura automática Generar factura para pedidos de clientes AFIP (Secundario)
facturación y empresariales pendientes de facturación cuya
cobros fecha de entrega es la fecha del día.
33. Gestión de Generar factura Generar factura para pedidos de clientes al paso. Cajero
facturación y AFIP (Secundario)
cobros
34. Gestión de Procesar pago con Procesar los pagos, que los clientes Banco
facturación y transferencia bancaria empresariales realizan por transferencias
cobros bancarias cuando el banco envía la información.
35. Gestión de Registrar pago con Mercado Registrar el pago de un pedido que se efectivizó Creador de Pedido
facturación y Pago con la plataforma de mercado de pagos (Abstracto)
cobros Mercado Pago
(Secundario)
36. Gestión de Registrar tipo de reclamo Registrar los datos de los tipos de reclamos, Responsable de
Reclamos indicando si es un tipo de reclamo crítico o no lo Clientes
es.
37. Gestión de Consultar tipo de reclamo Consultar los datos de un tipo de reclamo Responsable de
Reclamos Clientes
38. Gestión de Modificar tipo de reclamo Modificar los datos permitidos de un tipo de Responsable de
Reclamos reclamo Clientes

39. Gestión de Eliminar tipo de reclamo Dar de baja un tipo de reclamo. Responsable de
Reclamos Clientes
40. Gestión de Registrar un reclamo Registrar un reclamo por un pedido indicando los Encargado de
Reclamos detalles del reclamo, la fecha y asociando el tipo pedidos del Cliente
de reclamo.
41. Gestión de Consultar reclamos propios Consultar la situación de uno o más reclamos Encargado de
Reclamos realizados, en función de criterios determinados. pedidos del Cliente
42. Gestión de Consultar reclamos Consultar la situación de uno o más reclamos Responsable de
Reclamos realizados, en función de criterios determinados. Clientes

Listado de Actores
Nombre del Actor Descripción Categoría Tipo
Cadete Empleado de la empresa responsable de llevar el pedido Persona Concreto
al cliente y notificar al misma de la entrega del pedido.
Encargado de pedidos Encargado de diagramar las hojas de ruta de los cadetes y Persona Concreto
de registrar los pagos de los pedidos de clientes
empresariales.
Encargado de pedidos Responsable de realizar los pedidos semanales del cliente Persona Concreto
del cliente y de registrar reclamos en caso de que los pedidos no
sean cumplidos de forma satisfactoria.
Responsable de carta Responsable de registrar, modificar y dar de baja los Persona Concreto
productos y los combos que ofrece el crustáceo
cascarudo.
Responsable de clientes Responsable de registrar y dar de baja a los clientes Persona Concreto
corporativos que deseen hacer pedidos al crustáceo
cascarudo. Responsable de ver los reclamos de los
clientes.
Responsable de cocina Responsable de preparar los pedidos y actualizar su Persona Concreto
estado de preparación en el software.
Responsable de reportes Responsable de la generación de los reportes necesarios Persona Concreto
para las decisiones empresariales.
Cajero Responsable de registrar los pedidos por mostrador y Persona Concreto
cobrarlos.

Descripción de Casos de Uso
Consideración: Este caso de uso se planteó en estos términos a los fines de ser utilizado para una instancia
de evaluación. La forma óptima de modelarlo sería con una llamada a otro caso de uso que resuelva la
facturación.
Nombre del Use Case: Registrar pedidos para la semana Número: 1
Categoría: Esencial Soporte Prioridad: Esencial Útil Deseable

Actor Principal: Encargado de pedidos del Cliente (EP) Actor Secundario:
Objetivo: que un cliente empresarial registre uno o más pedidos para una semana determinada.
Flujo Descripto: Registro de varios pedidos y facturación en el momento.
1. EP: Selecciona la opción para hacer los pedidos de la semana.
2. Sistema: Solicita que se seleccionen los días de la semana en los que se hará pedidos.
3. EP: Selecciona la opción “Toda la semana”.
4. Sistema: Busca y muestra todos los productos y combos disponibles para esa semana. Para cada producto
muestra su nombre, precio, las variantes con sus ingredientes posibles y para cada variante nombre y su costo
adicional si lo tuviera. Para los combos muestra su nombre, su precio, su foto representativa y los nombres de
los productos que incluye.
5. Sistema: Solicita que se seleccione los productos con sus variantes y/o combos a pedir.
6. EP: Para cada día de la semana selecciona los productos con sus variantes y/o combos a pedir junto con sus
cantidades por cada uno de los días.
7. Sistema: Solicita que se confirmen los pedidos.
8. EP: Confirma los pedidos.
9. Sistema: Para cada día de la semana registra un pedido con un numero secuencial único, fecha de creación y de
entrega correspondiente. Para cada uno de los pedidos registra los productos y combos elegidos junto con las
variantes elegidas de cada producto. El pedido se crea en estado “Realizado.
10. Sistema: Solicita que se seleccionen los pedidos a facturar.
11. EP: Selecciona al menos uno de los pedidos realizados.
12. Sistema: Revisa el estado tributario del cliente y es Responsable Inscripto.
13. Sistema: Envía una petición al Web Service de AFIP informando el número de CUIT, para generar una Factura A
y es exitosa.
14. Sistema: Registra la Factura A con su número, fecha y hora, el número de CAE y el total facturado, cambiando
el estado del pedido a Facturado. Fin del caso de Uso.
Flujos Alternativos
A1. El EP selecciona algunos días puntuales de la semana.
A2. El EP decide no facturar ningún pedido.
A4. El cliente es Monotributista.

A5. La petición al Web Service de AFIP falla.

A6. El EP selecciona la opción para generar un PDF con la factura generada.
Observaciones 1: Para generar una factura con el web service de AFIP es necesario enviar el monto total de la
factura, los detalles a facturar con su monto, el tipo de factura a generar y el CUIT del cliente. La autorización de la
AFIP está formada por el número de CAE y el número de factura.
Se presentan prototipos de las facturas de tipo A y B:

Nombre del Use Case: Generar reporte de tasa de reclamo Número: 2

Actor Principal: Responsable de Reclamos (RR) Actor Secundario:
Objetivo: generar un reporte estadístico que muestre la tasa de reclamos sobre pedidos de los clientes, para un
periodo de tiempo, en función de criterios predefinidos.
Flujo Descripto: Flujo básico.
1. RR: Selecciona la opción “Generar reporte de estadísticas de reclamos”
2. Sistema: Solicita se seleccione la fecha desde y fecha hasta para el informe.
3. RR: Selecciona fecha desde y hasta.
4. Sistema: Valida que el periodo seleccionado sea correcto. (Ver observación 1)
5. Sistema: Busca y muestra los clientes empresariales y solicita se seleccione uno o más.
6. RR: Selecciona todos los clientes.
7. Sistema: Solicita se seleccione el tipo de tasa de reclamos para el reporte. (Ver observación 2)
8. RR: Selecciona “Tasa de reclamos críticos”.
9. Sistema: Solicita se seleccione la forma de visualización. (Ver observación 3)
10. RR: Selecciona la opción “Por pantalla”.
11. Sistema: Solicita confirmación para generar el reporte.
12. RR: Confirma la generación del reporte.
13. Sistema: Para cada cliente seleccionado busca los pedidos en estado “Entregado” o “Cobrado” con fecha de
entrega en el periodo seleccionado y los cuenta. Para cada pedido busca si tiene o no un reclamo generado del
tipo “Crítico” y lo cuenta.
14. Sistema: Para cada cliente calcula la tasa de reclamos críticos.
15. Sistema: Calcula la cantidad total de reclamos críticos y cantidad total de pedidos (tasa de reclamos críticos
totalizada)
16. Sistema: Muestra por pantalla el reporte (ver Observación 4). Fin del Caso de uso
Flujos Alternativos
A1. El RR selecciona tasa de reclamos bruta

A2. El RR selecciona tasa de reclamos no críticos
A3. El RR elige exportar el reporte a PDF
A4. El RR elige exportar el reporte a Excel
A5. El RR no confirma la generación del reporte.
Observaciones:
Observación 1: Un periodo será correcto si la fecha hasta es mayor a la fecha desde, ambas con formato de fecha
válidas.

Observación 2: Los métodos para calcular la tasa de reclamos pueden ser:

A. Tasa de reclamos bruta:
B. Tasa de reclamos críticos:
C. Tasa de reclamos no críticos:
Observación 3: El reporte puede imprimirse por pantalla, exportarse a PDF o exportarse a Excel.
Observación 4: La estructura del reporte es la siguiente:

Encabezado: Incluye el período de tiempo para el cual se generó el informe
Cuerpo: Incluye una grilla con el detalle por cliente y el total:
Reclamos Tasa de reclamos

Cliente Pedidos
Críticos críticos
Empresa 1 1 1000 0,1%
Empresa 2 5 60 8,33%
Empresa 3 6 100 6%
TOTAL 12 1160 1,03%
Pie: Fecha de generación del reporte
Observación 5: El RR podrá cancelar el CU en cualquier momento.

Prototipo para el caso de uso : Generar reporte de tasa de reclamo

Modelo de Dominio

Máquina de Estado Clase: Pedido

Modelado de Análisis para la realización del Caso de Uso 1. Registrar pedidos para la semana
Vista estática

Modelado de Vista dinámica utilizando diagrama de secuencia – Escenario con registro de varios pedidos
y facturación en el momento

Modelado de Análisis para la realización del Caso de Uso 2. Generar reporte de tasa de reclamo
Vista estática

Modelado de Vista dinámica utilizando diagrama de secuencia – Escenario que usa la “Tasa de reclamos
críticos” y forma de visualización en pantalla

Proyecto Práctico de Aplicación

Nombre del Proyecto Práctico de Aplicación: Peaje
El Proyecto Práctico de Aplicación denominado Peaje, tiene el propósito de desarrollar la especificación de un

producto de software que dará soporte a los procesos de negocio principales de una empresa concesionada para el
cobro de peajes en ciertas rutas. Se desarrollan vistas de los modelos de Requerimientos, Análisis, Diseño, e
Implementación.
Es importante destacar que las vistas que se desarrollan no están completas, ni son exhaustivas, se toma de cada
uno de los modelos, elementos referenciales con la intención de reflejar ciertos aspectos destacables del producto
de software que se está construyendo.
El Proyecto Práctico de Aplicación, tiene el propósito de reflejar cada una de las actividades de modelado requeridas
para el desarrollo y construcción de un producto de software en función del proceso, las técnicas y las herramientas
que se enseñan en la Materia Diseño de Sistemas. Este PPA representa una simplificación de un caso real, en el cual
los estudiantes podrán desarrollar las habilidades para aplicar los conocimientos adquiridos.

 Diseño de la Estructura del software aplicando patrones de diseño.
 Diseño del Comportamiento del Software en función de la estructura rediseñada con los patrones de diseño.
 Mapeo de estructuras de clases a bases de datos relacionales – Patrones de Persistencia.
 Diseño de interacción humano-máquina
 Mapeo del Diseño aplicando patrones, a la implementación
 Incorporar pedidos de cambio al Modelo de Requerimientos.

b. Modelo de Casos de Uso del Sistema de Información (Listado de Casos de Uso, Diagramas de casos
de uso y descripción de un caso de uso a trazo medio).
c. Modelo de Dominio aplicando los patrones de Coad.
d. Especificación de Requerimientos No Funcionales.
a. Realice el diagrama de comunicación del flujo descripto en el caso de uso 4 Registrar cobros por
débito automático, aplicando los patrones GRASP para análisis.
PPA_Peaje.docx – Versión 1.22

Autor/es: Cecilia Massano / Florencia Bene Página 1
b. Realizar la máquina de estado de la clase Cuenta, especificando métodos, casos de uso y

condiciones de control.
c. Realice el diagrama de clases de análisis incluyendo las clases que son requeridas para dar soporte
consistente a los dos modelos construidos en los puntos anteriores. Incluir atributos y métodos de
las clases, y navegabilidad y multiplicidad en todas las relaciones.
a. Diseño Arquitectónico
i. Identificación y aplicación de Patrones Arquitectónicos Significativos.
ii. Realización de vistas arquitectónicas
1. Construir la vista arquitectónica de la funcionalidad. Justificar la elección de los
casos de uso que incluye en la vista.
2. Construir la vista arquitectónica del diseño. Modelar el diagrama de componentes
para visualizar los subsistemas, componentes e interfaces.
3. Construir la vista arquitectónica del despliegue – Nodos y componentes.
b. Rediseño aplicando parones de diseño
i. Rediseñar la estructura, utilizando el patrón de diseño que permita resolver de una
manera flexible el comportamiento de la cuenta, de acuerdo con como varía según la
situación en la que se encuentre.
1. Construir la vista dinámica, utilizando un diagrama de secuencia, del escenario en
el que una cuenta pasa a estar no cobrada.
2. Describir con pseudocódigo, código o descripción textual los métodos utilizados
en la implementación de la solución pedida.
ii. Rediseñar la estructura, utilizando el patrón de diseño que presente una solución que
permita receptar los lotes de cobros de las distintas tarjetas de crédito, asegurando que
será posible interpretar la información sin importar si el formato de los lotes de cobro es
diferente para cada administradora de tarjeta de créditos con la que trabaja el peaje.
Servicio de Visa: enviarLotePagos() - recibe una fecha de inicio y fin de liquidación
con formato mm/dd/aaaa y devuelve una matriz de objects con los nombres y
pagos de los clientes. En la posición 0 los nombres y en la 1 los montos.
Servicio de MasterCard: enviarPagos() – no recibe parámetros ya que siempre
devuelve los pagos de la última liquidación y devuelve un vector de String con los
nombres y pagos de los clientes.
Servicio de Amex: enviarPagosProcesados() – recibe por parámetro un booleano
para indicar si se quiere la última liquidación y devuelve un vector de objects con
los nombres y pagos de los clientes concatenados.
1. Construir la vista dinámica, utilizando un diagrama de secuencia, del escenario en
el que una cuenta pasa a estar no cobrada, parla tarjeta Visa.
2. Describir con pseudocódigo, código o descripción textual los métodos utilizados
en la implementación de la solución pedida.
4. Solicitud de cambio a requerimientos funcionales
Se solicita incluir los siguientes pedidos de cambio:
 En la página web en la que se pueden consultar los tarifas y descuentos, también se debe permitir a los
clientes consultar el gasto correspondiente al período de liquidación actual y a períodos de liquidación
anteriores. Para ello se debe asignar un usuario a cada cliente, con los permisos correspondientes.
 El sistema debe permitir la gestión de suplencias de cajeros en casillas de peajes. Cuando un cajero
suplente inicie su sesión, el sistema debe validar que no se trata del empleado asignado al turno, por lo
que debe solicitarle indicar si el motivo es una suplencia. En caso afirmativo registra el empleado
suplente, el turno asignado al empleado suplido, y la fecha y hora de inicio de suplencia. Al cerrar la
sesión registra como fecha de fin de suplencia la fecha de cierre de la sesión. Posteriormente, el
Responsable de Recursos Humanos deberá indicar el motivo de suplencia a todas las suplencias

realizadas, señalando también si es una suplencia con o sin descuento de sueldo para el empleado
suplido. El cajero podrá consultar sus propias suplencias.
Para ello deberá:

a. Enumerar los casos de uso que se deberán agregar y/o modificar.
b. Realizar los cambios correspondientes en la estructura de dominio a partir del diagrama de clases
provisto.
5. Realice el diseño de la interfaz gráfica propuesta para la interacción del caso de uso 15 Consultar tarifas
por categoría y ruta.
6. Construya el modelo de datos derivado de las clases contenidas en el modelo de dominio, utilizando un
Diagrama de Entidad Relación (DER).
Criterios de evaluación del PPA (Si aplica): n/a

Glosario:
 Sistema de nombres de dominio (DNS, por sus siglas en inglés, Domain Name System) es un sistema de
nomenclatura jerárquico para dispositivos conectados a redes como Internet. Este sistema asocia
direcciones ip con nombres de dominios. Su función más importante es "traducir" estos nombres con el
propósito de poder localizar y direccionar distintos equipos en Internet, para el caso particular mencionado
en este enunciado.
 Web service (servicio web): es una tecnología que utiliza un conjunto de protocolos y estándares que sirven
para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes
de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para
intercambiar datos en redes de computadoras como Internet.
 ATC: Administradora de Tarjeta de Crédito.
 HTTPS: Hypertext Transfer Protocol Secure (en español: Protocolo seguro de transferencia de hipertexto),
más conocido por sus siglas HTTPS, es un protocolo de aplicación basado en el protocolo HTTP, destinado
a la transferencia segura de datos de Hipertexto, es decir, es la versión segura de HTTP.

Una empresa de mantenimiento de caminos, concesionada para cobrar el peaje en algunas rutas que les fueron
asignadas; ha decidido incorporar un sistema que permita el cobro automático de peaje a los automovilistas que
circulen por las rutas que la empresa mantiene. El funcionamiento esperado del sistema consiste en que se instale
en las casillas de peaje un dispositivo electrónico inalámbrico que detecte la pasada de un vehículo, le permita el
acceso y le cobre el monto correspondiente. Para esto el vehículo debe tener pegado en el parabrisas una oblea
asociada a la cuenta de un cliente, dueño del vehículo. De esta forma el sistema comenzará a contarle cada pasada
a ser cobrada con tarjeta de crédito, únicamente mediante el servicio de débito automático. Un cliente puede contar
con varios vehículos, pero cada uno de ellos será asociado a una cuenta diferente.
El dispositivo inalámbrico se conecta vía Wifi a una PC asociada a una casilla de peaje. En esta PC se instala un
componente que permite la interpretación de la oblea leída por el dispositivo inalámbrico. El dispositivo no cuenta
con ningún software más que su driver (controlador) que permite la lectura de la oblea.
El cobro de cada pasada está definido en base a una tarifa básica, y según cómo está categorizado el vehículo a pasar
y la ruta por la que está pasando el vehículo, como se muestra en el cuadro tarifario continuación. Por ejemplo: para
los automóviles de la ruta E53 la tarifa es $20, mientras que para una motocicleta la tarifa es $12,5.
En la aplicación se debe mostrar una imagen representativa de cada categoría (debe ser de extensión png y no
ocupar más de 300 mb), y resalta la categoría base por cada ruta (categoría sobre la que se definen el resto de las
tarifas):

Las tarifas tienen un período de vigencia definido por la tarifa base, y es el mismo para todas las categorías.
Para promover la utilización del servicio de registro automático de pasadas se ha dispuesto un sistema de
promociones en función de la cantidad de pasadas en un período de cobro mensual:
• Hasta 9 pasadas se realiza un 10% de descuento por pasada
• Desde la pasada 10 a la 20 se realiza un 20% de descuento por pasada (a partir de la pasada 10)
• Desde las 21 pasadas, se realiza un 30% de descuento por pasada (a partir de la pasada 21)
Toda la gestión de casillas, categorías, rutas, tarifas y descuentos debe ser web, con excepción del componente de
las PCs asociadas a cada casilla de peaje, como se explicó anteriormente. Para ello se debe publicar vía DNS la
aplicación, para que tenga salida a Internet, es decir, salida fuera del dominio de la empresa de peaje. Para asegurar
la confidencialidad de la información se trabaja con el protocolo https, que encripta los paquetes que viajan desde
cada casilla de peaje hacia un servidor central de bases de datos. La empresa cuenta con servidores centralizados
para todas las casillas de peaje de todas las rutas. Se compró una base de datos Oracle 12c. También se cuenta con
un servidor de aplicaciones y un servidor web. Debido a que la empresa de peaje no deja de trabajar en ningún
momento, todos los servidores deben ser redundantes (es decir, cada servidor está duplicado), para asegurar el
funcionamiento de la aplicación 24 hs. y en horas y fechas pico. Para las fechas pico debe poder soportar la pasada
de vehículos en simultáneo por las 10 casillas de cada una de las rutas donde se encuentra un peaje de la empresa
(son 9 rutas en total). Además, debe trabajar eficientemente con este tráfico considerando que en un minuto
pueden pasar hasta 10 vehículos. Se considera que el sistema es eficiente si procesa una pasada en hasta 4 segundos.
El servicio de registro automático de pasadas funciona de la siguiente manera: Cada cierto período de tiempo se
generan las obleas y se les asigna un número único. Cuando una persona solicita el servicio, se lo registra como
cliente, se registra el vehículo y se asocia al vehículo una cuenta. También se vincula a la cuenta una de las obleas
disponibles, es decir que no ha sido asignada. El cliente debe presentar una tarjeta de crédito, que debe ser la misma
para todas las cuentas que posea, a la que se le debitará mensualmente el costo de todas las pasadas realizadas con
un vehículo vinculado a una cuenta, en un período, en función de lo explicado anteriormente. El cliente puede
solicitar un cambio de tarjeta de crédito asociada a todas las cuentas que tiene, cuando así lo requiera, por ejemplo,
por extravío, robo o vencimiento de la misma. Una vez que se le asignó una cuenta y oblea al cliente, se pega dicha
oblea en el parabrisas de su vehículo.
Debido que a veces la validación de datos de la tarjeta de crédito del cliente se demora, puede ocurrir que se le cree
la cuenta y luego sea dada de baja, porque exista algún inconveniente con su tarjeta de crédito. Si el cliente tuviera
más de una cuenta, todas las cuentas son dadas de baja.
El cliente puede perder la oblea del peaje, en tal caso puede solicitar una nueva y asociarla a la misma cuenta,
inhabilitándose la oblea previamente otorgada.

Una vez que la cuenta está en uso se comienzan a contabilizar los viajes para registrar el descuento correspondiente.
El sistema deberá tener actualizada la situación respecto a cuántas pasadas lleva el vehículo. Cuando el vehículo
pasa por la casilla de peaje, el dispositivo electrónico inalámbrico instalado del lado del conductor, muestra en su
visor el monto a debitar, asociando un color en función del descuento aplicable a cada vehículo en particular, según
el siguiente criterio:
 Si el monto a debitar es por menos de 10 pasadas el visor muestra la información en rojo.
 Si el monto a debitar es por 10 a 20 pasadas el visor muestra la información en azul.
 Si el monto a debitar es por más de 20 pasadas el visor muestra la información en verde.
Cuando llega el cierre del período de liquidación, se reinicia la situación de la cuenta para comenzar a contar
nuevamente la cantidad de pasadas y determinar así el estado de la cuenta asociado al descuento que corresponde
aplicar.
Luego del cierre del período, se debe informar a las diferentes administradoras de tarjeta de crédito (ATC), utilizando
una comunicación vía archivo ftp, cuál es el monto por cobrar con débito automático a cada cliente. Para esto se
generará un proceso de ejecución automática que asocie las pasadas de los clientes al período a liquidar, y las
resetee, realizando el cálculo de deuda de los clientes por tarjeta de crédito y generando los archivos
correspondientes. Está previsto que este proceso no demore más de 5 horas procesando un promedio de 20 pasadas
por cliente, con una gestión de 3000 clientes promedio por cada una de las rutas en donde se cuenta con casillas de
peaje. Este procesamiento debe aprovechar la existencia de los dos servidores de aplicaciones para distribuir la
carga.
Periódicamente cada tarjeta de crédito debe enviar el conjunto de cobros por débito automático, formando un lote
de cobros a informar mediante un web service. La administradora de una tarjeta de crédito siempre enviará el lote
de cobros correspondientes al período del mes anterior al actual (período vigente). En el momento en que una
administradora de tarjeta de crédito envía el lote de cobros, un web service del sistema de peaje obtendrá la
información y se validará que el monto de cada cobro coincida con el monto adeudado, registrándose el cobro
correspondiente. Si faltara algún cobro de un cliente, la cuenta se considera no cobrada, por lo que el servicio queda
suspendido para ese cliente hasta que regularice la situación, indicando el motivo por el que la cuenta pasa a estar
no cobrada (débito no ingresado, cliente no identificado, u otro motivo).
Ejemplo de un cliente con una de sus cuentas no cobradas:
Cuenta Pasada Tarifa Subtotal Tarjeta Galicia Visa

Cuenta
23.456 1 25 $ 50 Nro: 1111 4567 1234 8888
23.456 2 25 Cobro por Debito: $87,5
89.341 1 12,5 $ 37.5
89.341 2 12,5 Las 3 cuentas asociadas a la
89.341 3 12,5 Debito no ingresado Tarjeta:1111 4567 1234 8888
12.234 1 25 $25
Si se identifica que una cuenta de un cliente se encuentra más de dos veces no cobrada, se da de baja la cuenta. Se
ha requerido que el sistema genere un reporte que informe para cada cliente, cuánto tiempo pasa una cuenta no
cobrada y cuántas veces ha estado en esta situación.
Si la cuenta está no cobrada y luego del procesamiento del lote de cobros, se determina que se imputó todo el
monto correspondiente, la cuenta vuelve a estar en uso, debiendo mantener la cantidad de pasadas registradas
desde el último cierre del período de liquidación y por consecuencia su estado asociado y descuento aplicable.
Cabe aclarar que un cliente podrá solicitar la baja del servicio en cualquier momento, indicando el motivo (por ej:
tarjeta de crédito no habilitada, mudanza de cliente, inconformidad con servicio, servicio impago).
Se ha solicitado contar con información de la cuenta, manteniendo registro del histórico de situaciones por los que
va pasando la cuenta de un cliente particular a lo largo del tiempo.
Existe también la forma de cobro en efectivo. Para esto un automovilista debe acercarse a una casilla de peaje que
no tenga el sistema de cobro automático. En la casilla un empleado del peaje le recibirá el dinero y le entregará el
vuelto si correspondiera. En este caso se entrega un ticket al automovilista únicamente indicando la categoría del
vehículo y ruta, el monto abonado (sin descuento) y el empleado que realizó el cobro. No se registran los datos del
cliente ni del vehículo.
Existen casillas especiales donde se debe abonar el monto exacto. Esto implica que no se le entregará vuelto al
automovilista, en pos de agilizar el movimiento de vehículos.
Para establecer cuál es el empleado de peaje que recibe un pago, existen definidos turnos de atención. Cuando un
empleado comienza su turno de trabajo se deberá loguear en la aplicación, para ser identificado en cada cobro que
realice. El sistema contará con un módulo de gestión de usuarios y perfiles para toda la aplicación.
Para que los usuarios de peaje puedan consultar las tarifas y descuentos, se publicará una página web con toda esta
información.
Se han solicitado un ranking de clientes con mayor cantidad de pasadas, y un reporte que detalle la situación de
cada cuenta.

Solución Propuesta
Propósito del Sistema:
Objetivo: gestionar pasadas de usuarios de un peaje y el cobro correspondiente según la definición de tarifas y las
formas de pago vigentes, generando información resultante de la gestión.
Alcance: El sistema deberá contemplar los siguientes alcances:

 Administración de usuarios y roles.
 Administración de tarifas en función de categorías de vehículos y rutas.
 Administración de clientes y de sus vehículos.
 Administración de casillas de peaje.
 Gestión de pasadas de vehículos por las casillas el peaje.
 Gestión del cobro en efectivo y con tarjeta de crédito.
 Administración de empleados y turnos de atención.
 Generación de reportes resultantes de la gestión de peaje.
No Contempla:
 Gestión de pagos a empleados
 Gestión de reparación de rutas realizadas por la empresa de peaje
Reglas de Negocios
Nro. Nombre Descripción
1) Oblea con cobro por Para que un cliente puede utilizar el servicio de oblea, debe tenerla pegada en
débito automático el parabrisas del vehículo. Esta oblea debe estar asociada a la cuenta de un
cliente, dueño del vehículo. De esta forma el sistema comenzará a contarle
cada pasada a ser cobrada con tarjeta de crédito, únicamente mediante el
servicio de débito automático.
2) Cuentas de clientes Un cliente puede contar con varios vehículos, pero cada uno de ellos será
asociado a una cuenta diferente.
3) Tarifas de peaje El cobro de cada pasada está definido en base a una tarifa básica, y según cómo
está categorizado el vehículo a pasar y la ruta por la que pasa.
4) Sistema de Sistema de promociones en función de la cantidad de pasadas en un período
promociones de cobro mensual:
• Hasta 9 pasadas se realiza un 10% de descuento por pasada
• Desde la pasada 10 a la 20 se realiza un 20% de descuento por pasada (a partir
de la pasada 10)
• Desde las 21 pasadas, se realiza un 30% de descuento por pasada (a partir de
la pasada 21)
5) Tarjeta de crédito del El cliente debe presentar una tarjeta de crédito, que debe ser la misma para
cliente todas las cuentas que posea. En esta tarjeta de crédito se le debitará
mensualmente el costo de todas las pasadas realizadas con un vehículo
vinculado a una cuenta, en un período.
6) Cambio de tarjeta de El cliente puede solicitar un cambio de tarjeta de crédito asociada a todas las
crédito cuentas que tiene, cuando así lo requiera, por ejemplo, por extravío, robo o
vencimiento de esta.
7) Baja de cuenta del Debido que a veces la validación de datos de la tarjeta de crédito del cliente se
cliente por demora, puede ocurrir que se le cree la cuenta y luego sea dada de baja, porque
inconveniente con exista algún inconveniente con su tarjeta de crédito. Si existiera más de una
tarjeta de crédito cuenta, todas las cuentas son dadas de baja.


8) Pérdida de oblea A lo largo del tiempo el cliente puede perder la oblea del peaje. En tal caso
puede solicitar una nueva y asociarla a la misma cuenta, inhabilitándose la
oblea previamente otorgada.
9) Cierre de período Luego del cierre del período, se debe informar a las diferentes marcas de tarjeta
de crédito cuál es el monto a cobrar por débito automático a cada cliente.
10) Lote de cobros por Periódicamente cada tarjeta de crédito debe enviar el conjunto de cobros por
tarjeta de crédito débito automático, formando un lote de cobros a informar. La marca de una
tarjeta de crédito siempre enviará el lote de cobros correspondientes al
período del mes anterior al actual (período vigente). En el momento en que una
administradora de tarjeta de crédito envía el lote de cobros, se validará que el
monto de cada cobro coincida con el monto adeudado, registrándose el cobro
correspondiente.
11) Cuenta no cobrada y Si faltara algún cobro de un cliente cuando se realiza la validación de un lote de
suspensión del cobros, la cuenta se considera no cobrada, por lo que el servicio queda
servicio suspendido para ese cliente hasta que regularice la situación, indicando el
motivo por el que la cuenta pasa a estar no cobrada (débito no ingresado,
cliente no identificado, u otro motivo).
12) Situaciones de baja de Una cuenta de un cliente se da de baja cuando:
cuenta de cliente  Se identifica que se encuentra más de dos veces no cobrada.
 El cliente solicita la baja del servicio, indicando el motivo (por ej: tarjeta
de crédito no habilitada, mudanza de cliente, inconformidad con
servicio, servicio impago). Esto lo puede realizar en cualquier
momento.
13) Cobro en efectivo Existe la forma de cobro en efectivo del servicio de peaje. Un empleado recibe
el cobro y entrega el vuelto si correspondiera.
14) Ticket de cobro en El ticket de cobro en efectivo debe incluir los siguientes datos: categoría de
efectivo automóvil, monto abonado (sin descuento) y empleado que realizó el cobro.
No se registran los datos del cliente ni del vehículo.
15) Cobro exacto Existen casillas especiales donde se debe cobrar el monto exacto. Esto implica
que no se le entregará vuelto al automovilista.
16) Turnos de atención Para establecer cuál es el empleado de peaje que recibe un cobro, existen
definidos turnos de atención. Cuando un empleado comienza su turno de
trabajo, se deberá loguear en la aplicación, para ser identificado en cada cobro
que realice.
17) Categoría base Se define una categoría base por cada ruta sobre la que se establecen todas las
tarifas de peaje en un período de vigencia definido. El periodo de vigencia es
igual para todas las categorías base.

Diagrama de Casos de Uso – Vista de Casos de Uso Esenciales
uc Vista esencial de casos de uso
1 Registrar cierre de período

de liquidación
ResponsableDeLiquidaciones Cajero
ATC
68 Registrar cobro en
12 Registrar precios por efectivo
categoría
57 Generar reporte de
estado de cuentas 49 Registrar categoría 4 Registrar cobros por
débito automático
35 Registrar vehículo DispositivoInalámbricoDePeaje

7 Registrar oblea
5 Registrar cuenta
2 Registrar pasada por

peaje
23 Registrar cliente
ResponsableDeAtenciónAlPúblico

A continuación, se presenta un listado incompleto de casos de uso del sistema:
Actor Nro. Nombre del Caso de Uso Objetivo / Breve Descripción
Registrar el cierre de un período de liquidación, calculando
Responsable de la deuda de cada cuenta en función de las pasadas y
Registrar cierre de período
liquidaciones 1. descuentos aplicados, y reseteando las cuentas para que
de liquidación
(RL) comiencen a contarse las pasadas desde cero en el nuevo
período.
Dispositivo Registrar la pasada de una oblea vinculada a una cuenta,
inalámbrico de 2. Registrar pasada por peaje registrando la fecha y el monto a debitar, en función de los
peaje descuentos y categoría correspondiente a la cuenta.
Registrar el cobro de una deuda asociada a una cuenta de
un cliente, regularizando la situación de la cuenta, para que
RL 3. Registrar cobro de deuda
el cliente pueda pasar por las casillas con un dispositivo
inalámbrico.


Registrar los cobros realizados por los clientes que realizaron
Administradora
Registrar cobros por débito al menos una pasada por el peaje en el período, y que tienen
de tarjeta de 4.
automático una determinada marca de tarjeta de crédito, asociada para
crédito (ATC)
cobro con débito automático.
Responsable de
Dar de alta una cuenta a un cliente, asociándola a un
atención al 5. Registrar cuenta
vehículo del cliente, y asignándole una oblea.
público (RAP)
Cancelar una cuenta de un cliente indicando el motivo de la
RAP 6. Cancelar cuenta
cancelación.
Dar de alta una oblea habilitándola para ser asignada a una
RAP 7. Registrar oblea
cuenta.
RAP 8. Modificar oblea Actualizar los datos permitidos de una oblea.
RAP 9. Eliminar oblea Dar de baja una oblea, inhabilitándola para su uso.
Usuario 10. Consultar oblea Visualizar los datos permitidos de una oblea determinada.
Usuario 11. Consular cuenta Visualizar los datos permitidos de una cuenta determinada.
Registrar tarifas por Registrar las tarifas asociadas a cada categoría de vehículo y
RL 12.
categoría y ruta ruta.
RL Modificar las tarifas de una o más categorías de vehículos,
Actualizar tarifas por
13. registrando la fecha de actualización, la fecha de vigencia, y
categoría y ruta
la forma de actualización (por monto fijo o porcentaje).
RL Inhabilitar tarifa de Inhabilitar la tarifa de una categoría y ruta en particular,
14.
categoría y ruta para que no se registre más una pasada con esa tarifa.
Consultar tarifas por Visualizar las tarifas correspondientes a cada categoría y
Cliente 15.
categoría y ruta ruta.
Registrar los descuentos aplicables en función de la
RL 16. Registrar descuentos
cantidad de pasadas de una cuenta.
Actualizar los porcentajes de descuentos aplicables en
RL 17. Actualizar descuentos
función de la cantidad de pasadas de una cuenta.
Inhabilitar descuentos para que no sean más aplicables a
RL 18. Inhabilitar descuentos
partir del momento definido.
Cliente 19. Consultar descuentos Visualizar los descuentos vigentes.
Usuario 20. Iniciar sesión Iniciar una sesión validando los permisos de usuario.
Usuario 21. Cerrar sesión Cerrar la sesión de un usuario.
N/A Cerrar la sesión automáticamente luego del paso de un
22. Caducar sesión
tiempo sin actividad del usuario.
RAP 23. Registrar cliente Dar de alta un cliente y los datos de su tarjeta de crédito.
RAP Actualizar los datos permitidos de un cliente, incluyendo los
24. Modificar cliente
de su tarjeta de crédito.
RAP Visualizar los datos de un cliente, incluidos los de su tarjeta
25. Consultar cliente
de crédito.
RAP Dar de baja un cliente e inhabilitar su tarjeta de crédito para
26. Eliminar cliente
no realizar más débitos en liquidaciones posteriores.
Responsable de
recursos Registrar los turnos asignados a cada cajero para un
27. Registrar turnos de cajeros
humanos período, indicando la casilla correspondiente.
(RRHH)


RRHH Actualizar los turnos de cajeros para un período, pudiendo
28. Modificar turnos de cajeros modificar la casilla de peaje a la que cada cajero se encuentra
asignado.
RRHH Visualizar los turnos vigentes de cajeros asignados a las
29. Consultar turnos de cajeros
casillas de peaje.
RRHH Anular una asignación de turnos de un conjunto de cajeros a
30. Anular turnos de cajeros
las diferentes casillas de peaje.
RRHH 31. Registrar empleado Registrar los datos de un empleado y asignarle un cargo.
RRHH 32. Modificar empleado Actualizar los datos permitidos de un empleado.
RRHH 33. Consultar empleado Visualizar los datos de un empleado.
RRHH Dar de baja a un empleado para que no pueda asignársele
34.
Eliminar empleado un usuario ni un turno.
RAP Registrar los datos de un vehículo asociado a un cliente y su
35.
Registrar vehículo cuenta.
RAP 36. Modificar vehículo Actualizar los datos permitidos de un vehículo.
RAP 37. Consultar vehículo Visualizar los datos de un vehículo.
RAP Dar de baja un vehículo de un cliente asociado a una
38.
Eliminar vehículo cuenta.
RRHH 39. Registrar usuario Registrar los datos de un usuario y asociarlo a un empleado.
RRHH 40. Modificar usuario Actualizar los datos permitidos de un usuario.
RRHH Consultar usuario Visualizar los datos de un usuario, incluyendo su perfil y
41.
permisos asignados.
RRHH Eliminar usuario Dar de baja a un usuario para que no pueda iniciar sesión
42.
en el sistema.
RRHH Registrar perfil Registrar los datos de un perfil, incluyendo los permisos
43.
asociados.
RRHH Modificar perfil Actualizar los datos de un perfil, agregando o quitando
44.
permisos.
RRHH Consultar perfil Visualizar los datos de un perfil, incluyendo los permisos
45.
asociados.
RRHH 46. Eliminar perfil Dar de baja a un perfil.
RRHH 47. Asignar perfil a usuario asignar un perfil a un usuario determinado.
Usuario Modificar password Permitir a un usuario que modifique su password, validando
48. se cumplan los criterios establecidos para la configuración
de la misma.
RL Registrar los datos de una categoría para permitir la
49. Registrar categoría
definición de tarifas asociadas.
RL 50. Modificar categoría Actualizar los datos permitidos de una categoría.
RL 51. Consultar categoría Visualizar los datos de una categoría.
RL Dar de baja una categoría, inhabilitándola para la posterior
52. Eliminar categoría
definición de tarifas.
RL Registrar los datos de una ruta para permitir la definición de
53. Registrar ruta
tarifas asociadas.
RL 54. Modificar ruta Actualizar los datos permitidos de una ruta.
RL 55. Consultar ruta Visualizar los datos de una ruta.
RL Dar de baja una ruta, inhabilitándola para la posterior
56. Eliminar ruta
definición de tarifas.


RRHH 57. Registrar cargo Registrar los datos de un cargo a asignar a un empleado.
RRHH 58. Modificar cargo Actualizar los datos permitidos de un cargo.
RRHH 59. Consultar cargo Visualizar los datos de un cargo.
RRHH Dar de baja un cargo, para que no pueda ser asignado a un
60. Eliminar cargo
empleado.
RRHH Registrar los datos de una casilla de peaje para permitir la
61. Registrar casilla de peaje asignación de turnos a cajeros y habilitarla para el cobro de
peajes.
RRHH 62. Modificar casilla de peaje Actualizar los datos permitidos de una casilla de peaje.
RRHH 63. Consultar casilla de peaje Visualizar los datos de una casilla de peaje.
RRHH Dar de baja una casilla de peaje, inhabilitándola para ser
64. Eliminar casilla de peaje
asignada a un turno de un cajero.
RL Generar reporte de cuentas
65.
no cobradas Generar reporte de clientes con cuentas no cobradas.
RL Generar ranking de clientes
66. con mayor cantidad de Generar reporte con ranking de clientes con mayor cantidad
pasadas de pasadas en un período.
RL Generar reporte de estado Generar reporte detallando el estado de cada cuenta de
67.
de cuentas cada cliente para un momento dado.
Cajero (CAJ) Registrar el cobro en efectivo de una pasada por el peaje, ya
68. Registrar cobro en efectivo sea por cobro exacto o con vuelto, generando el ticket
correspondiente.
CAJ Registrar la anulación de un cobro realizado en efectivo de
69. Anular cobro en efectivo
una pasada por el peaje.
RL Generar un reporte permitiendo visualizar el historial de
Generar reporte histórico
70. estados por los que pasó una cuenta de Cliente en
de cuenta de Cliente
particular.

Descripción de Casos de Uso

Descripción del CU 4 Registrar cobros por débito automático
Nombre del Caso de uso: Registrar cobros por débito automático Nro. de Orden: 4
Actor Principal: Administradora de Tarjeta de Crédito (ATC) Actor Secundario: No Aplica.
Objetivo: Registrar los cobros vinculados a clientes que realizaron al menos una pasada por el peaje en el período, y
que tienen una determinada marca de tarjeta de crédito.
Flujo básico
1. ATC: Comienza cuando envía el lote de cobros de un período.
2. Sistema: Busca el período a liquidar (ver Observación 3), verifica que el archivo de lote de cobros enviado por la
ATC corresponde al período, y determina cuál es la marca de tarjeta de crédito para que la debe procesar los
cobros.
3. Sistema: Busca las cuentas de los clientes que tengan asignada la marca tarjeta de crédito de la ATC.
4. Sistema: Para cada cliente que tenga una tarjeta de crédito de la marca de la ATC, valida que la tarjeta de crédito
esté habilitada, y todas las cuentas tienen tarjeta de crédito habilitada.
5. Sistema: Para cada cuenta identificada, busca las pasadas pendientes de cobro para el periodo y valida si el monto
del lote de cobros coincide con la suma de todas las pasadas pendiente de cobro de cada cuenta y es así.
6. Sistema: Registra el cobro de cada cuenta, la fecha de pago, y vincula el cobro con todas las pasadas incluidas,
registrando las pasadas como pagadas.
7. Sistema: Informa a la ATC la finalización exitosa del procesamiento del lote de cobros. Fin del CU.
Alternativas
A1. Se detecta que se han enviado cobros asociados a tarjeta de crédito no habilitadas, por lo que informa esta
situación a la ATC y cancela el procesamiento de todo el lote de pago.
A2. La suma de las pasadas pendientes es mayor al informando en el lote, es decir que hay cuentas no cobradas.
A3. La suma de las pasadas pendientes es menor al monto informando en el lote.
A4. El proceso se corta, por lo que se anulan todas las transacciones de pago realizadas hasta el momento para ese
lote de cobros y se informa a la ATC que el procesamiento no fue exitoso.
Observaciones
Observaciones
1. Si no hay cuentas de clientes asociadas a la marca de tarjeta de crédito, la marca de tarjeta de crédito no envía
ningún lote de cobros, por lo que el caso de uso no se ejecuta para esa marca de tarjeta de crédito.
2. Si el proceso se corta por algún inconveniente se anulan todas las transacciones de pago para iniciar
nuevamente el proceso completo y se informa al servicio de débito automático que el procesamiento no fue
exitoso.
3. El período a liquidar es el período del mes anterior al mes en curso.

Nombre del Caso de uso: Registrar cobros por débito automático Nro. de Orden: 4
Actor Principal: Administradora de Tarjeta de Crédito (ATC) Actor Secundario: No Aplica.
Objetivo: Registrar los cobros vinculados a clientes que realizaron al menos una pasada por el peaje en el período, y
que tienen una determinada marca de tarjeta de crédito.
Flujo que describe procesamiento de lote con cuentas no cobradas
1. ATC: Comienza cuando envía el lote de cobros de un período.
2. Sistema: Busca el período a liquidar (ver Observación 3), verifica que el archivo de lote de cobros enviado por la
ATC corresponde al período, y determina cuál es la marca de tarjeta de crédito para la que debe procesar los
cobros.
3. Sistema: Busca las cuentas de los clientes que tengan asignada la marca tarjeta de crédito de la ATC.
4. Sistema: Para cada cliente que tenga una tarjeta de crédito de la marca de la ATC, valida que la tarjeta de crédito
esté habilitada, y todas las cuentas tienen tarjeta de crédito habilitada.
5. Sistema: Para cada cuenta identificada, busca las pasadas pendientes de cobro para el periodo y valida si el monto
del lote de cobros coincide con la suma de todas las pasadas pendiente de cobro de cada cuenta. Identifica que
para al menos una cuenta el monto de las pasadas es mayor al informado en el lote de cobros, por lo que:
 se registra la cuenta como no cobrada con el motivo débito no ingresado.
 se registra la fecha actual como fecha en la que cada cuenta identificada deja de estar en uso por pasar
a estar no cobrada.
6. Sistema: Registra el cobro de cada cuenta, la fecha de pago, y vincula el cobro con todas las pasadas incluidas,
registrando estas pasadas como pagadas (únicamente las efectivamente pagadas).
7. Sistema: Informa a la ATC la finalización exitosa del procesamiento del lote de cobros. Fin del CU.
Alternativas
A1. Se detecta que se han enviado cobros asociados a tarjeta de crédito no habilitadas, por lo que informa esta
situación a la ATC y cancela el procesamiento de todo el lote de cobros.
A2. La suma de las pasadas pendientes es igual al monto informando en el lote.
A3. La suma de las pasadas pendientes es menor al monto informando en el lote.
A4. El proceso se corta, por lo que se anulan todas las transacciones de pago realizadas hasta el momento para ese
lote de cobros y se informa a la ATC que el procesamiento no fue exitoso.
Observaciones
Observaciones
1. Si no hay cuentas de clientes asociadas a la marca de tarjeta de crédito, la marca de tarjeta de crédito no envía
ningún lote de cobros, por lo que el caso de uso no se ejecuta para esa marca de tarjeta de crédito.
2. Si el proceso se corta por algún inconveniente se anulan todas las transacciones de pago para iniciar
nuevamente el proceso completo y se informa al servicio de débito automático que el procesamiento no fue
exitoso.
3. El período a liquidar es el período del mes anterior al mes en curso.

Nombre del Caso de uso: Consultar tarifas por categoría y ruta Nro. de Orden: 15
Actor Principal: Cliente Actor Secundario: No Aplica.
Objetivo: Visualizar las tarifas correspondientes a cada categoría y ruta.
Flujo básico
1. Cliente: Comienza cuando selecciona la opción Consultar tarifas.
2. Sistema: Busca las tarifas vigentes para todas las categorías y rutas, y las muestra, incluyendo una imagen
representativa de cada categoría, resaltando aquellas tarifas de la categoría base.
3. Sistema: Informa el período de vigencia de las tarifas informadas, en función de la categoría base (Ver
Observación 1).
4. Sistema: Permite consultar tarifas de períodos anteriores, mostrando los últimos 5 períodos.
5. Cliente: No desea modificar los períodos anteriores que desea consultar. Fin del caso de uso
Alternativas
A1. No existen tarifas vigentes para el período actual.
A2. El Cliente desea visualizar tarifas de períodos anteriores.
A3. No es posible visualizar alguna imagen asociada a una categoría.
A4. El Cliente desea modificar el período de vigencia.
A5. El Cliente cancela la operación.
Observaciones
Observaciones
1. Existe una categoría marcada como categoría base para cada ruta (categoría sobre la que se definen el resto
de las tarifas). Todas las categorías base tienen el mismo periodo de vigencia.
2. El Cliente puede cancelar la operación en cualquier momento.

Modelo de Dominio

Realizaciones de casos de uso de análisis

Vista de Estructura del Caso de Uso 15 Consultar tarifas por categoría y ruta
class 15 Consultar tarifas por categoría y ruta

PantallaConsultarTarifa GestorConsultarTarifa
grillaTarifas tarifas
lblPeriodoVigencia periodoVigencia
btnCancelar periodosVigencia
comboPeriodos opcionConsultarTarifas()
btnAceptar obtenerFechaActual()
tomarOpcionConsultarTarifas() buscarTarifasVigentes()
mostrarGrillaTarifasVigentes() buscarPeriodosAnteriores()
habilitarPantalla() finCU()
mostrarPeriodoDeVigencia()
mostrarUltimosPeriodos()
«entity»
«entity» Ruta
Tarifa nombre
ruta 1 getNombre()
precioPorPasada
fechaFinVigencia
fechaInicioVigencia
«entity»
esTarifaVigente()
categoría CategoríaAutomovil
esTarifaDeRutaYCategoría()
mostrarDatos() nombre
esDeCategoriaBase() 1 base
obtenerPeriodoVigencia() urlImagen
esCategoríaBase()
getNombre()
getUrlImagen()
Vista Dinámica del Caso de Uso 15 Consultar tarifas por categoría y ruta

Realización de CU de Análisis - Vista de Estructura del Caso de Uso 4 Registrar cobros por
débito automático

Página 20
Realización de CU de Análisis - Vista Dinámica CU 4 Registrar cobros por débito automático
sd 4 Registrar cobros por débito automático - camino básico

Para validar la MarcaTarjetaCrédito se 26: finCU() :

puede hacer por el valor del puntero,
20: crearCobros() PasadaPeaje
como en esta solución, o por el nombre,
llegando al objeto MarcaTarjetaCrédito 16: validarCobros() 18: *estáPendienteDeCobro()
desde la TarjetaCrédito del cliente 12: validarHabilitaciónDeTC() 19: *getImportePasada()
8: buscarCuentasDeTC() 23: *actualizarComoCobrada()
4: validarPeriodo()
6: validarMarca() 13: *esTCHabilitada()
3: obtenerFechaActual()
21: *crearCobro()
1: nuevoLotePagosDA() 17: *sumarCobrosPendientes()
2: nuevoLoteCobrosDA() 9: *esCuentaDeTC()
25: lotePagosProcesadoExitosamente()
24: informarProcesamientoExitosoLotePagos()
:InterfazDA :Cuenta
:ATC :GestorDA
7: *esMarcaDeTC() 10: tieneEstaTC()
14: esTCHabilitada() 22: new()
5: *esPeríodoVigente()
: nuevoPago:
MarcaTarjetaCrédito Cobro
Autor/es: Cecilia Massano / Florencia Bene

:Cliente
11: *esMarcaTC()
: 15: *esTCHabilitada()
PeríodoLiquidación

:
TarjetaCrédito
– Flujo básico
Realización de CU de Análisis - Vista Dinámica CU 4 Registrar cobros por débito automático

Flujo que describe el procesamiento de lote con cuentas no cobradas
sd 4 Registrar cobros por débito automático - camino cuentas impagas
37: finCU() :
31: crearCobros() PasadaPeaje
Para validar la MarcaTarjetaCrédito se 23: buscarMotivo()
21: buscarEstadoNoCobrado() 18: *estáPendienteDeCobro()
puede hacer por el valor del puntero, 20: marcarCuentasComoNoCobrada() 19: *getImportePasada() :
como en esta solución, o por el nombre, 16: validarCobros()
12: validarHabilitaciónDeTC() 34: *actualizarComoCobrada() HistorialEstadoCuenta
llegando al objeto MarcaTarjetaCrédito
8: buscarCuentasDeTC()
desde la TarjetaCrédito del cliente 6: validarMarca()
4: validarPeriodo() 25: marcarNoCobrado() 27: *esEstadoActual()
3: obtenerFechaActual() 13: *esTCHabilitada()
32: *crearCobro()
2: nuevoLoteCobrosDA() 17: *sumarCobrosPendientes()
1: nuevoLoteCobrosDA() 26: buscarEstadoActual()
9: *esCuentaDeTC() 29: crearHistorial()
36: loteCobrosProcesadoExitosamente()
35: informarProcesamientoExitosoLoteCobros()
:ATC :InterfazDA :Cuenta 28: setFechaFinEstado()
:GestorDA
7: *esMarcaDeTC() 10: tieneEstaTC()
14: esTCHabilitada() último:
HistorialEstadoCuenta
24: *esMotivoDébitoNoIngresado()
5: *esPeríodoVigente()
:
33: new() 30: new()
MarcaTarjetaCrédito 22: *esNoCobrada()
:Cliente
11: *esMarcaTC()
: 15: *esTCHabilitada() nuevoHistorial:
:Motivo nuevoCobro:
PeríodoLiquidación
Cobro
:Estado HistorialEstadoCuenta
:
TarjetaCrédito


Máquina de Estado Clase Cuenta
2 Registrar pasada por peaje/3 Registrar cobro de cuenta [y es la

3 Registrar primer pasada o se reseteo la cuenta y tenia menos de 10 pasadas]
cobro de /reactivar() pasar()
deuda [se
2 Registrar pasada por MenosDe10Pasadas 1 Registrar cierre de período
reactiva la 3 Registrar cobro
peaje [y tiene menos de de liquidacion [y tiene menos
cuenta y de deuda [se
tenia entre 10 pasadas] /pasar() de 10 pasadas] /liquidar()
reactiva la cuenta
10 y 20 y tenia mas de 20
pasadas] pasadas]
/reactivar() /reactivar()
1 Registrar cierre
de período de 1 Registrar cierre
liquidación de período de
/liquidar() 2 Registrar pasada liquidación
por peaje [y llegó a /liquidar()
10 pasadas] /pasar()
2 Registrar
pasada por
peaje [y tiene 10A20Pasadas MásDe20Pasadas
entre 10 y 20
pasadas] 2 Registrar pasada por
/pasar() peaje [y pasó los 20
viajes] /pasar()

Universidad Tecnológica Nacional- Facultad Regional Córdoba y Facultad Regional Villa María
Guía de Ejercicios Prácticos: Modelado de Requerimientos
Guía de ejercicios prácticos:

“Modelado de requerimientos”
2023 - Guia de Ejercicios para Mod Requerimientos CS.docx, Versión 2.4 Página 1
Índice
Objetivos Generales ............................................................................................................................................................... 4
Consignas ................................................................................................................................................................................ 4
Caso de Estudio N°1: Video Club ............................................................................................................................................ 5
Caso de Estudio N°2: Secretaría de Turismo de la Nación .................................................................................................... 6
Caso de Estudio N°3: Editorial ................................................................................................................................................ 7
Caso de Estudio N° 4: Torneo de Municipalidad ................................................................................................................... 9
Caso de Estudio N° 5: Control de Acceso a Country ............................................................................................................ 10
Soluciones Propuestas: ......................................................................................................................................................... 11
Solución propuesta: Video Club ........................................................................................................................................... 12
Definición del Sistema....................................................................................................................................................... 12
Diagrama de CU- Vista esencial ........................................................................................................................................ 13
Descripción de Casos de Uso (trazo fino, medio y grueso) ............................................................................................ 14
Construcción de prototipos de interfaz de usuario ....................................................................................................... 20
Diagrama de clases............................................................................................................................................................ 21
Patrones Coad ...................................................................................................................................................................22
Solución Propuesta: Secretaría de turismo ........................................................................................................................ 23
Definición del Sistema...................................................................................................................................................... 23
Diagrama de Casos de Uso esenciales ............................................................................................................................ 24
Descripción de Casos de Uso (trazo fino, medio y grueso) ........................................................................................... 25
Construcción de prototipo de interfaz de usuario ......................................................................................................... 29
Diagrama de Clases .......................................................................................................................................................... 30
Patrones Coad ................................................................................................................................................................... 31
Solución Propuesta: Editorial .............................................................................................................................................. 32
Diagrama de Casos de Uso esenciales ............................................................................................................................ 33
Construcción de un prototipo de interfaz de usuario .................................................................................................... 38
6. Diagrama de clases ...................................................................................................................................................... 39
Patrones Coad .................................................................................................................................................................. 39
Solución Propuesta: Torneo de Municipalidad ................................................................................................................... 40
Diagrama de casos de uso esenciales .............................................................................................................................. 41

Diagrama de clases........................................................................................................................................................... 47
Patrones Coad .................................................................................................................................................................. 48
Solución Propuesta: Control de Acceso a countries .......................................................................................................... 49
Diagrama de casos de uso esenciales ............................................................................................................................. 50
Diagrama de clases........................................................................................................................................................... 54
Patrones Coad .................................................................................................................................................................. 55
Historial de Cambios ............................................................................................................................................................ 56
Objetivos Generales
Los ejercicios incluidos en la presente guía tienen por propósito:
→ Definir los sistemas de información que se van a construir en términos de sus requerimientos funcionales.
→ Facilitar a los alumnos la práctica sobre modelado de la estructura de sistemas de información, construyendo
un Modelo de Dominio, utilizando como herramienta el diagrama de clases.
→ Aplicar patrones en el modelado de objetos del dominio.
→ Identificar y modelar la esencia funcional de los sistemas de información de manera consistente con el
modelado de casos de uso.
→ Utilizar prototipos como herramienta de validación de los requerimientos.
Consignas
En cada uno de los casos de estudio que se plantean el alumno deberá:
1. Analizar la situación planteada y definir el sistema de información asociado en términos de objetivos, alcances
y reglas de negocio más relevantes.
2. Construir el Diagrama de Casos de Uso, vista esencial.
3. Describir un caso de uso a trazo fino, uno a trazo medio y uno a trazo grueso.
4. Construir prototipos de interfaz de usuario.
5. Construir el modelo de dominio, utilizando un diagrama de clases; identificando atributos, responsabilidades
y relaciones, indicando navegabilidad y multiplicidad.
6. Especificar los patrones Coad, utilizados para construir los modelos de dominio.
Caso de Estudio N°1: Video Club

Este video club se dedica al alquiler de películas y trabaja con un sistema de abonos. Existen dos tipos de
abonos: especiales (habilitan al socio a retirar cualquier tipo de películas incluido estrenos) y comunes (habilitan al socio
a retirar todas las películas excepto estrenos). Cada abono tiene como consecuencia un precio diferente. Todos los
abonos son por 25 películas que pueden alquilarse en el plazo máximo de un mes y medio.
Las películas pueden pagarse al momento de alquilarlas o al devolverlas, y dicho pago puede ser de contado o
de lo contrario, con abono (para los socios que lo posean). Se le entrega un ticket al socio en el momento del pago. En
el caso del abono, el socio se lleva el ticket en el momento de la compra de la chequera con los abonos, entregando
un abono por cada película que retira.
Es política del video que las personas deban registrarse como socios antes de alquilar la primera película.
Solamente se les requiere la presentación de una constancia de domicilio y una copia del documento de identidad.
Cuando se alquilan las películas, las mismas son registradas determinándose: fecha de alquiler, fecha en la que
las mismas deben estar devueltas. Los socios que tengan en su poder películas cuya fecha de devolución esté vencida
se encuentran inhabilitados para retirar nuevas, hasta tanto cumplimente la devolución de la película.
En el momento en que el Socio devuelve la película se controla si el alquiler ya está pagado, de lo contrario se
le cobra y se registra la devolución. En caso de demora en la devolución se le debe cobrar el recargo correspondiente.
Las películas están categorizadas de acuerdo a si son estrenos, clásicos, etc.; y su categoría determina el precio
del alquiler, la cantidad de días del préstamo y el precio de recargo por devolución fuera de término.
Las películas se clasifican por género. Los datos que se necesitan de las películas son: nombre, protagonista/s,
director, categoría, ubicación (lo cual permite localizarlas en las estanterías).
Pueden existir varios ejemplares por película, que se compran al mismo momento o no, es decir, si una película
es muy demandada puede que se pide una compra adicional posteriormente. El responsable del Video es el encargado
de realizar la administración periódica de las películas, que consiste entre otras cosas, en dar de baja películas rotas o
en mal estado y en re-categorizar las películas que dejan de ser estrenos.
El responsable del Video ha solicitado se diseñe el proceso de negocio que permita la reserva de películas por
parte de los socios (por teléfono o personalmente), contemplando como servicio adicional la entrega de películas a
domicilio. Para concretar la reserva se requiere fecha de la reserva, la película y el socio que realiza la reserva.
Caso de Estudio N°2: Secretaría de Turismo de la Nación

La Secretaría de Turismo de la Nación ha decidido implementar un Programa de Promoción de los lugares
turísticos de la República Argentina. El programa incluye varios medios de difusión entre los cuales se encuentra
INTERNET. El Secretario de Turismo ha determinado que independientemente del medio elegido (Internet, Oficinas
de Promoción, etc.), los interesados deberán poder acceder al menos a la siguiente información, para cada lugar
turístico:
 Ubicación (provincia, localidad, kilómetros de distancia desde el lugar seleccionado hasta capital de la
provincia)
 Tipos de alojamiento disponibles (hoteles, hospedajes, cabañas, moteles, etc.) y comodidades ofrecidas por
cada uno de los alojamientos en función del tipo, régimen alimentario (si es pensión completa, media pensión,
desayuno, todo incluido, etc.), tipos de habitaciones (doble, triple, etc.)
 Lugares de interés que se pueden visitar con sus características y precios asociados.
 Los precios pueden tener variaciones en función de la temporada.
 Excursiones: si el Lugar Turístico tiene programadas excursiones, informar duración de las mismas, lugares que
se visitan durante la excursión, precios, desde dónde se la puede tomar.
 Sitios para comer con sus características, precios demostrativos, tipo de comida y ubicación.
 Precios de cada lugar en las distintas temporadas (alta y baja) y estaciones del año en que se recomienda más
visitarla, por ejemplo: VALLE DE LA LUNA, visitarlo en otoño o invierno.
 Medios de Transporte que pueden utilizarse para llegar a cada lugar turístico y precios asociados.
 Estadísticas de lugares más visitados en cada localidad, lugar de origen de los turistas y excursiones más
demandadas. Para obtener esta información cada municipio debe comunicar a la Secretaría de Turismo al
finalizar cada temporada la información de los lugares turísticos más visitados y de las excursiones más
demandadas de cada lugar turístico. Respecto de los visitantes se requiere si son argentinos discriminar por
localidad, provincia y país; si son extranjeros discriminar sólo por país.
Además, se debe permitir a las personas interesadas realizar reservas, tanto vía Web como en las oficinas de
información turística, de hospedajes en cualquier tipo de alojamiento ubicadas en cualquier lugar turístico de los que
están registrados en el sistema. Las reservas deben ser confirmadas por cada lugar de alojamiento para hacerse
efectivas, y los turistas las podrán cancelar hasta tanto no hayan sido confirmadas.
Caso de Estudio N°3: Editorial
Se describe el funcionamiento de una Editorial dedicada a la publicación de obras literarias de diferentes

géneros con el objetivo principal de obtener un rédito de la publicación y venta de libros, actuando como nexo entre
los autores y las imprentas.
Existen dos situaciones que dan inicio a la publicación de un libro:
1. Personas (autores) que se presentan a publicar un libro por primera vez: Se anuncian en la recepción y es la
recepcionista la que le asigna un editor en función de la disponibilidad del momento. El editor recibe al autor
y en función del tema de que se trata dará una aceptación preliminar, puesto que puede ocurrir el libro no se
encuentre dentro del ámbito de incumbencia de la Editorial.
2. Autores que ya han publicado anteriormente en la editorial: en este caso la recepcionista lo deriva
directamente con el editor asignado anteriormente. Salvo excepciones como que el editor ya no trabaje más
en la empresa o no esté disponible. Si esto ocurre, la recepcionista le asigna al autor otro editor.
En ambos casos, si el editor recibe el libro informa la fecha en la cual dará una respuesta, en caso contrario, le
devuelve el libro y el autor se retira. El editor que se queda con el libro lo lee y realiza una evaluación (positiva o
negativa) que se comunica al autor.
Si la evaluación es positiva lo cita para comenzar los trámites de contratación y el arreglo económico, que puede
ser por un porcentaje en función de las ventas o un monto fijo “tipo sueldo”. En el contrato también figura si el libro
es una novela y existe la posibilidad de continuidad en la historia (tal es el caso de las sagas como “Harry Potter”).
Cada autor tiene un contrato para cada libro, ese contrato tiene un tipo de liquidación asociada que puede ser
sueldo o comisión. Para los sueldos el contrato contiene el monto y para las comisiones el porcentaje. Las comisiones
dependen de las ventas informadas para el período a liquidar.
Si el libro decide publicarse, se asigna un revisor y un encargado de diseño gráfico. Finalizadas ambas actividades
el libro se envía a imprenta. La Editorial trabaja con varias imprentas y es el editor el encargado de la selección y luego
envío del original del libro, indicando la cantidad de copias y las características de impresión deseables. Una vez que la
imprenta finalizó el trabajo, le envía a la Editorial los libros que están listos para ser comercializados.
En forma paralela a las actividades de revisión del libro, el editor debe encargarse de registrar la propiedad
intelectual para proteger los derechos de autor y, una vez concluido este trámite el número de registro se incluye en
el material a enviar a imprenta.
La editorial realiza un seguimiento de libros que recibe y debe mantener un historial de su evolución. Además de
los estados descriptos con anterioridad vale remarcar que en los casos en que la evaluación del editor no es
satisfactoria se devuelve el libro en forma definitiva. Como resultado del proceso de revisión el libro puede estar en
condiciones y se lo envía a imprenta o necesita correcciones, para lo cual se envía el ejemplar al autor. El autor corrige
el libro que debe ser revisado nuevamente, con lo cual vuelve a estar pendiente de revisión. Al recibir las copias del
libro de la imprenta, el libro queda listo para distribución y así finaliza su ciclo de seguimiento.
Mensualmente, el Responsable de Liquidaciones debe liquidar las comisiones o sueldos de los autores según
corresponda. Las comisiones se calculan en función de las ventas de libros, informadas por las librerías. Si existen
adelantos se descuentan de las liquidaciones conforme se haya pactado en el momento del otorgamiento de los
mismos.
Dado que el proceso de liquidación es complicado, primero se obtiene una pre-liquidación de control con un listado
que permite realizar correcciones, de ser necesario, y luego se obtiene la liquidación definitiva que imprime cada uno
de los comprobantes de pago para los autores. Se genera un comprobante por cada tipo de liquidación, es decir si un
autor tiene más de un libro con la editorial se liquidan por un lado todos los que cobra por sueldo y por otro todos los
que cobra por comisiones. En ambos casos, cada comprobante describe lo que se está liquidando y los conceptos de
descuentos, si correspondieran. Para cada comprobante se imprime un cheque diferente. Esto último se puede hacer
en el mismo momento de la impresión de los comprobantes o en otro momento posterior.
Caso de Estudio N° 4: Torneo de Municipalidad

La Secretaría de Deportes de la Municipalidad de Villa María necesita un sistema de Información para llevar a
cabo la gestión de torneos de atletismo.
Trimestralmente, se organizan torneos que abarcan diferentes disciplinas (carreras, salto en largo, jabalina,
etc.), en los que pueden participar competidores de diferente sexo y categoría (clasificación de acuerdo a la edad).
Estos torneos se organizan solamente para alumnos de las escuelas de la zona. Y los competidores necesariamente
tienen que pertenecer a una escuela, que es quien debe presentar las inscripciones.
Las escuelas que desean participar deben inscribir a sus alumnos en la Secretaría de Deportes ó a través de la
página WEB de la Municipalidad.
La Municipalidad genera inscripciones independientes para cada participante en cada una de las disciplinas que
desea competir, y el procedimiento para aceptarlas es el siguiente: en el momento que se recibe la inscripción,
personal de la Municipalidad debe validarla con la demás documentación de los participantes para corroborar que los
datos sean correctos, en especial la categoría en la que se inscribió, si esta evaluación es aprobada, la inscripción queda
pre-aprobada, desde ese momento tienen plazo hasta cinco horas antes del inicio de la competencia, para realizar el
examen médico reglamentario. Recién después de superadas ambas instancias el participante está en condiciones de
competir. La falta de cualquiera de las instancias anteriores invalida la inscripción para la competencia.
Finalizado el torneo, se registran los resultados obtenidos en cada disciplina. Es un requerimiento de la

Municipalidad conocer la cantidad de participantes inscriptos que cumplieron con todos los requisitos y cuáles no, y
luego de los que estaban en condiciones cuáles efectivamente compitieron.
La Municipalidad ha planteado la necesidad de conocer los mejores competidores en cada disciplina

discriminados por categoría y sexo, para luego convocarlos a Torneos Provinciales.
Caso de Estudio N° 5: Control de Acceso a Country

GSP es una importante consultora de software de esta ciudad, dedicada a la construcción de sistemas
enlatados orientados a satisfacer las necesidades del mercado.
En esta ocasión, su objetivo es el desarrollo de un sistema de información que satisfaga una necesidad esencial
de las empresas administradoras de countries: “el control de accesos”.
Dentro del country se encuentran lotes de cierta superficie que pueden tener propiedades edificadas, obras
en construcción o estar vacíos.
En la entrada del country se encuentra un guardia que será el encargado de registrar los accesos al country de
las diferentes personas: propietarios, familiares de los propietarios, obreros y visitantes.
En el caso de los propietarios y sus familiares, ellos poseen una tarjeta de acceso que les permite el ingreso.
Para los visitantes el guardia debe llamar por teléfono al propietario del lote donde debe entrar el visitante para que
el propietario autorice el ingreso del visitante. En este caso se deberá registrar los datos del visitante (nombre, apellido
y dni) y la fecha y hora de la autorización.
En el caso de los obreros su ingreso se controla teniendo en cuenta su período de trabajo: días de trabajo,
horario de ingreso supuesto, horario de salida supuesto, fecha de inicio y de fin de la obra donde trabajará.
Aclaraciones:
En cualquiera de los accesos al country, no se debe permitir que una persona pueda ingresar dos veces sin
haberse registrado la salida, y viceversa.
Los obreros no pueden ingresar al country en días y horarios que no hayan sido autorizados previamente por
los propietarios.
Soluciones Propuestas:
Las soluciones se presentan a nivel de Modelo de Requerimientos, con Diagrama de Casos de Uso (únicamente
para los casos de uso esenciales), descripción de algunos casos de uso como ejemplo, los prototipos de interfaces y
los diagramas de clases. Para el caso de los diagramas de clase se modela a nivel de Clases de Dominio, es decir la
primera versión de modelo que se realiza durante el workflow de requerimientos y que luego es refinada con el resto
de las clases, métodos y atributos que se incorporan durante los workflows de análisis y diseño.
En todos los casos de estudio se presenta una solución sugerida.
Se presentan dos formas alternativas de modelar los Diagramas de Clases, cada una expresa una forma
diferente que se puede utilizar para representar los atributos que referencian objetos de otras clases:
1. Se muestran las relaciones entre clases como atributos de referencia, asignando como tipo la clase que están
relacionando.
2. Se muestran las relaciones entre clases directamente asignándolas como “rol” en la relación correspondiente.
Solución propuesta: Video Club

Definición del Sistema
Objetivo:
Administrar información de películas y sus ejemplares para alquiler; el cobro por el alquiler de películas ya sea de
contado o con abonos. Brindar información resultante de la gestión.
Alcances (Requerimientos Funcionales):
→ Administración de películas y sus ejemplares.

→ Administración de Tipos de Abonos.
→ Administración de Socios.
→ Gestión de Alquileres de películas.
→ Gestión de Cobro de alquileres y abonos.
→ Gestión de Reservas.
→ Gestión de entrega de películas reservadas.
→ Generación y emisión de informes de:
o Películas más alquiladas.
o Ingresos por período de abonos, alquileres.
o Porcentaje de Reservas canceladas, anuladas y confirmadas.
Reglas de Negocio:

1. Tipos de Abonos Existen dos tipos de abonos:
• especiales (habilitan al socio a retirar cualquier tipo de películas incluido
estrenos).
• comunes (habilitan al socio a retirar todas las películas excepto estrenos).
Cada tipo de abono tiene como consecuencia un precio diferente.
2. Vigencia de los Abonos Todos los abonos son por 25 películas que pueden alquilarse en el plazo máximo de
un mes y medio.
3. Cobro del alquiler de Las películas pueden pagarse al momento de alquilarlas o al devolverlas, y dicho
películas pago puede ser de contado o de lo contrario, con abono (para los socios que lo
posean).
4. Inhabilitación de socios Los socios que tengan en su poder películas cuya fecha de devolución esté vencida
se encuentran inhabilitados para retirar nuevas, hasta tanto cumplimente la
devolución de la película.
5. Categorización de películas Las películas están categorizadas de acuerdo a si son estrenos, clásicos, etc.; y su
categoría determina el precio del alquiler, la cantidad de días del préstamo y el precio
de recargo por devolución fuera de término.
6. Ejemplares de películas Pueden existir varios ejemplares por película, que se compran al mismo momento o
no, es decir, si una película es muy demandada puede que se pide una compra
adicional posteriormente.
7. Administración de Periódicamente se controla el estado de los ejemplares de las películas, para dar de
Películas baja películas rotas o en mal estado y re-categorizar las películas que dejan de ser
estrenos.

8. Reservas Para registrar una reserva se requiere fecha de la reserva, la película y el socio que
realiza la reserva.
9. Política de registro de Es política del video que las personas deban registrarse como socios antes de alquilar
socios la primera película. Solamente se les requiere la presentación de una constancia de
domicilio y una copia del documento de identidad.
Diagrama de CU- Vista esencial

uc Use Case Vie w
Re gistrar
Socio
Re gistrar
Re se rv a
Emple ado de
Re gistrar
Vide o
Alquile r
Consultar
Pe lículas
Re gistrar «extend»
De v olución
«extend»
Re gistrar
Re gistrar Cobro
Ve nta de «extend»
Abono
Consultor de
Pe lículas
Ge ne rar re porte
de pe lículas más
alquiladas
Re gistrar e ntre ga Encargado de

de Pe lículas e n Vide o Ge ne rar re porte de
domicilio ingre sos por tipo de
ingre so
Ge ne rar Hoja Ge ne rar re porte

de re se rv as por
de Re corrido
e stado
Re gistrar Re gistrar
Re cate gorización Pe lícula
de Pe lícula
Re gistrar Tipo
de Abono
Descripción de Casos de Uso (trazo fino, medio y grueso)

Trazo fino: Registrar Alquiler
Nombre del Caso de Uso: Registrar Alquiler ID: 1
Categoría: Esencial Soporte Prioridad: Alta Media Baja
Actor Principal: Empleado de Video (EV) Actor Secundario: no aplica

Objetivo: Registrar el alquiler de uno o más ejemplares de películas a un socio.
Precondiciones: usuario logueado.
Post- Condiciones Éxito 1: Alquiler sin reserva previa, registrado y cobrado.
Éxito 2: Alquiler sin reserva previa, registrado.
Éxito 3: Alquiler con reserva previa registrado y cobrado.
Éxito 4: Alquiler con reserva previa registrado.
Fracaso 1: El EV no confirma el registro del alquiler.
Fracaso 2: No existen ejemplares disponibles de la película reservada y no se desea alquilar
otra.
Fracaso 3: No existen ejemplares disponibles de la película buscada y no se desea alquilar
otra.
Fracaso 4: El socio posee películas sin devolver, con fecha de devolución vencida.
Fracaso 5. El socio no está registrado.
Fracaso 6: No se pudo efectuar el cobro y el EV decide no continuar con el registro del
alquiler.
Fracaso 7: El EV cancela la ejecución del caso de uso.
1. EV: selecciona la opción “Alquilar Película”.
2. Sistema: solicita se ingrese nro. de socio.
3. EV: ingresa nro. de socio.
4. Sistema: valida existencia del socio y estado. El 4.A. El socio no está registrado.
socio existe y está en condiciones de alquilar 4.A.1. Sistema: informa la situación.
películas. (Observación 2) 4.A.2. Cancela el caso de uso.
4.B. Socio está inhabilitado para alquilar película.

4.B.1. Sistema: informa la situación.
4.B.2. Se cancela el caso de uso.
5. EV: Para cada película que desea alquilar, informa 5.A EV: informa que existe reserva previa.
que no existe reserva previa. 5.A.1. Sistema: solicita ingresar el número de reserva.
5.A.2. EV: ingresa el número de reserva.
5.A.3. Sistema: busca la reserva, la encuentra.
5.A.3.A: Sistema: la reserva no existe

5.A.3.A.1: Sistema: informa la situación y solicita ingresar otro
número de reserva.
5.A.3.A.2. EV: ingresa otro número de reserva.
5.A.3.A.2.A EV: No ingresa otro número de reserva.

5.A.3.A.2.A.1. Sistema: informa que se deberá registrar el
alquiler sin reserva asociada.
5.A.4. Sistema: muestra los datos de la reserva: fecha,

película y fecha de vigencia (Observación 3).
5.A.5. Sistema: para cada película reservada verifica la
disponibilidad de al menos un ejemplar; y existe al menos un
ejemplar.
5.A.5.A. No existen ejemplares disponibles de una película

reservada.
5.A.5.A.1. Sistema: muestra un mensaje informando la
situación y pregunta si se desea realizar el alquiler de otra
película.
5.A.5.A.2. EV: desea realizar el alquiler de otra película.
5.A.5.A.2.A. EV: No desea realizar el alquiler de otra película.
5.A.5.A.2.A.1. Se cancela el caso de uso.
5.A.6. Sistema: muestra el ejemplar de la película a alquilar,

categoría y calcula la fecha de devolución y el precio del
alquiler. También calcula el precio total del alquiler.
5.A.7. Sistema: permite modificar los ejemplares de películas
a alquilar.
5.A.8. EV: no desea modificar los ejemplares de las películas
a alquilar.
5.A.8.A. EV: desea modificar las películas a alquilar.
5.A.9. Sistema: solicita confirmar el registro del alquiler.
5.A.10. EV confirma el registro del alquiler.
5.A.10.A. EV: no confirma el registro del alquiler.

5.A.10.A.1. Se cancela el caso de uso.
5.A.11. EV: no desea registrar el cobro del alquiler.

5.A.11.A: EV desea registrar el cobro del alquiler.
5.A.11.A.1. Sistema: llama al caso de uso Registrar Cobro de
Alquiler; y éste se ejecuta con éxito.
5.A.11.A.1.A. El caso de uso no se ejecuta con éxito.

5.A.11.A.1.A.1. Sistema: muestra un mensaje informando la
situación y pregunta si desea continuar con el registro del
alquiler.
5.A.11.A.1.A.2: EV: desea continuar con el registro del alquiler.
5.A.11.A.1.A.2.A: EV decide no continuar con el registro del
alquiler.
5.A.11.A.1.A.2.A.1: Se cancela el caso de uso.
5.A.11.A.1.A.3: Sistema registra el alquiler y actualiza el estado
de la reserva a “Finalizada” y el estado del ejemplar a
“Alquilado”.
5.A.11.A.1.A.4: Fin del caso de uso.
6. Sistema: Para cada película a alquilar solicita
ingresar su código.
7. EV: ingresa el código de la película.
8. Sistema: busca la película y la encuentra, muestra 8.A. Sistema: busca la película y la encuentra, muestra el
el nombre de la película y todos los ejemplares con su nombre de la película y todos los ejemplares con su
disponibilidad y existe al menos un ejemplar disponibilidad y NO hay ejemplares disponibles.
disponible. Solicita seleccionar un ejemplar. 8.A.1. Sistema: informa la situación y pregunta si se desea
realizar el alquiler de otra película.
8.A.2. EV: desea registrar el alquiler de otra película.
8.A.2.A. EV no desea registrar el alquiler de otra película.
9. EV: selecciona un ejemplar.
10. Sistema: calcula según la categoría de la película
la fecha de devolución y el precio del alquiler.
11. Sistema permite quitar ejemplares de película de
los seleccionados para ser alquilados.
12. EV: no desea quitar un ejemplar de película. 12.A. EV: desea quitar algún ejemplar de película, lo
selecciona para quitar.
12.A.1. Sistema: solicita confirmación para quitar el o los
ejemplares seleccionados.
12.A.2. EV: confirma su eliminación.
12.A.2.A. EV: no confirma su eliminación.
13. Sistema: calcula y muestra el precio total del
alquiler y solicita se confirme el registro del alquiler.
14. EV: confirma el registro del alquiler. 14.A. EV: no confirma el registro del alquiler.
14.A.1. Se cancela el caso de uso.
15. Sistema: pregunta si desea registrar el cobro del
alquiler.
16. EV: no desea registrar el cobro del alquiler. 16.A. EV: desea registrar el cobro del alquiler.
16.A.1. Sistema: llama al caso de uso Registrar Cobro de
Alquiler; y éste se ejecuta con éxito.
16.A.1.A. El caso de uso no se ejecuta con éxito.
16.A.1.A.1. Sistema: muestra un mensaje informando la
situación y pregunta si desea continuar con el registro del
alquiler.
16.A.1.A.2. EV: desea continuar con el registro del alquiler.
16.A.1.A.2.A. EV: decide no continuar con el registro del
alquiler.
16.A.1.A.2.A.1. Se cancela el caso de uso.
17. Sistema: genera y muestra el número de alquiler
el alquiler, registra la película especificando: número,
socio, fecha de alquiler, fecha de devolución prevista,
monto del alquiler y estado del cobro y cada uno de
los ejemplares de película alquilado. Actualiza el
estado de cada ejemplar a “Alquilado”.
Observaciones:
1. El actor puede cancelar la ejecución del caso de uso en cualquier momento.
2. El socio para alquilar películas no puede tener alquileres vencidos pendientes de devolución.
3. En este caso de uso se muestran sólo las reservas para mostrador. No las de entrega a domicilio.
Asociaciones de Extensión: Registrar Cobro
Trazo medio: Registrar alquiler
Nombre del Caso de Uso: Registrar Alquiler ID: 1

Actor Principal: Empleado de Video (EV) Actor Secundario: no aplica

Objetivo: Registrar el alquiler de uno o más ejemplares de películas a un socio.
Flujo básico
1. EV: selecciona la opción “Alquilar Película”.
2. Sistema: solicita se ingrese Nro. de socio
3. EV: ingresa nro. de socio
4. Sistema: valida existencia del socio y estado. El socio existe y está en condiciones de alquilar películas.
(Observación 2) Muestra número de socio, nombre, apellido, dirección y teléfono del socio.
5. EV: Para cada película que desea alquilar, informa que no existe reserva previa.
6. Sistema: Para cada película a alquilar solicita ingresar su código.
7. EV: ingresa el código de la película.
8. Sistema: busca la película y la encuentra, muestra el nombre de la película y todos los ejemplares con su
disponibilidad y existe al menos un ejemplar disponible. Solicita seleccionar un ejemplar.
9. EV: selecciona un ejemplar.
10. Sistema: calcula según la categoría de la película la fecha de devolución y el precio del alquiler.
11. Sistema permite quitar ejemplares de película de los seleccionados para ser alquilados.
12. EV: no desea quitar un ejemplar de película.
13. Sistema: calcula y muestra el precio total del alquiler y solicita se confirme el registro del alquiler.
14. EV: confirma el registro del alquiler.
15. Sistema: pregunta si desea registrar el cobro del alquiler.
16. EV: no desea registrar el cobro del alquiler.
17. Sistema: genera y muestra el número de alquiler el alquiler, registra la película especificando: número, socio,
fecha de alquiler, fecha de devolución prevista, monto del alquiler y estado del cobro y cada uno de los ejemplares
de película alquilado. Actualiza el estado de cada ejemplar a “Alquilado”. Fin del Caso de uso
Alternativas
A1: El socio no está registrado.
A2: Socio inhabilitado para adquirir películas.
A3: El EV informa que existe una reserva previa para la película que quiere alquilar.
A4: Reserva inexistente.
A5: No existen ejemplares disponibles de la película que desea.
A6: EV desea registrar el cobro del alquiler y el caso de uso se ejecuta con éxito.
A7: El caso de uso registrar cobro de alquiler no se ejecuta con éxito.

A8: EV desea quitar algún ejemplar de película.
A9: EV cancela el Caso de uso.
Observaciones:
1. El actor puede cancelar la ejecución del caso de uso en cualquier momento.
2. El socio para alquilar películas no puede tener alquileres vencidos pendientes de devolución.
3. En este caso de uso se muestran sólo las reservas para mostrador. No las de entrega a domicilio.
Trazo grueso: Consultar películas

Nombre del Caso de Uso: Consultar Películas ID: 15
Actor Principal: Consultor de Películas (CC) Actor Secundario: no aplica
Objetivo: Mostrar información de las películas existentes en el video club.
Descripción: El caso de uso comienza cuando el CC selecciona la opción “Consultar Películas”. El sistema muestra
todas las películas disponibles organizadas por categorías y, además, visualiza el precio y los días de préstamo
según su categoría. El CC puede consultar información detallada de la película deseada; para cada una se muestra:
nombre, género, categoría, calificación, país de origen, duración, cantidad de ejemplares disponibles y el elenco.
El sistema permite aplicar filtros de búsquedas por: categoría, nombre, género, calificación y país de origen. El CC
puede aplicar uno o más filtros y el sistema muestra las películas que cumplen con ese criterio de búsqueda. Fin
del caso de uso.
Observaciones: El actor podrá cancelar la ejecución del caso de uso en cualquier momento.
Construcción de prototipos de interfaz de usuario

Caso de uso: Registrar Alquiler
Diagrama de clases
class Domain Model
Abon o
empleadoVendio fecha
fechaVto
1 numero TipoAbon o
Cobro tipoAbono
precio descricpion
Emple ado fechaCobro
conocerDetalleDeAbono() nombre
Cargo horaCobro 1
apellido empleadoCobro conocerEmpleadoVendio() precio
descripcion dni nroTicket detalleCobro conocerTipoAbono() conocerDetalleTipoA()
nombre cargo domicilio calcularTotal() estaCompleto()
fechaNac 1 0..1
getDescripcion() conocerDetalleCobro() estaVencido()
1 nombre
getNombre() imprimirTicket() abono
1 password 1 1..*
setDescripcion() empleado detalleAbono
setNombre() conocerCargo() empleadoAlquilo 0..*
De talle De Cobro detalleTipoAbono
validarPassword()
1
1..*
Alqu ile r cantidad
precio
empleadoReservo fechaAlquiler alquiler De talle TipoAbon o
HojaRe corrido fechaDevPrevista calcularTotalLinea()
0..1 conocerAbono() cantidad
fecha fechaDevReal 1..*
numero precio conocerAlquiler() conocerCategoria()
0..1 recargo
conocerDetalleHR() De talle De Abon o categoria
conocerRepartidor() Re se rva calcularMonto() alquiler
calcularRecargo() abono estado
domicilioEntrega 0..*
conocerEjemplar() conocerCategoria()
estado 0..* estaDevuelto() Socio
detalleHR reserva fechaPedido
estaDevueltoEjemplar() dni categoria
1..* fechaReserva
domicilio
conocerAlquiler() estado
De talle HojaRe corrido conocerPelicula()
1 fechaAsociacion
entregado fechaBaja
fechaNacimiento
conocerReserva() reserva
numero
Ele n co
pelicula abonosVigentes()
nombre 1..* conocerAbono()
personaje conocerAlquiler()
rol elenco
conocerRol() conocerReserva()
esPersonaje() cuantasReservasPeriodo()
Rol cuantosAlquileresPeriodo()
descripcion 1..* 1 imprimirCarnet()
ejemplar
nombe quePeliculasAlquilo()
Pe licu la reservasNoConfirmadas()
calificacion duracion 1
ejemplar
Calificacion nombre
1 tituloOriginal Eje mplar Estan te
descripcion 0..* Estan te ria
nombre conocerCalificacion() estado estante estante
genero capacidad 1 1
Ge n e ro conocerCategoria() fechaAlta capacidad
lugaresDisponibles
conocerEjemplar() fechaBaja 1 numero 1..* numero
descripcion 1 Cate goria
nombre conocerElenco() detCapacidadDisponible()
conocerEstante() hayLugaresDisponibles() descripcion
conocerPaisOrigen() hayLugaresDisponibles()
hayEjemplaresDisponibles() diasPrestamo
PaisDe O rige n nombre
mostrarUbicacionEjemplares()
nombre paisDeOrigen precio
recargo
getNombre() 1 categoria 1
setNombre()
Patrones Coad
Patrones Utilizados Clases

#12 Asociación – Otra Asociación Película – Género
Película – Categoría
Película - Calificación
Elenco – Rol
# 3 Participante – Transacción Empleado - Hoja Recorrido
Socio – Alquiler
Socio – Reserva
#6 Transacción – Detalle de Transacción Hoja Recorrido – Detalle Hoja Recorrido
Abono – Detalle Abono
#11 Ítem – Ítem Específico Película – Ejemplar
Tipo Abono - Abono
# 5 Ítem Específico–Transacción Ejemplar- Alquiler
#9 Ítem -Detalle de Transacción Reserva - DetalleHojaRecorrido
Alquiler – DetalleDeCobro
Abono - DetalleDeCobro
#7 Transacción –Transacción Subsiguiente Reserva-Alquiler
#15 Contenedor – Detalle Contenedor Tipo Abono – Detalle Tipo Abono
Solución Propuesta: Secretaría de turismo

Objetivo del SI:
Administrar información sobre lugares turísticos y sus excursiones, alojamientos y lugares de interés, gestionando
reservas de alojamiento. Emitir informes y estadísticas relacionadas a turistas y lugares de interés turístico.
Requerimientos Funcionales
 Administrar lugares turísticos y sus lugares de interés

 Administrar excursiones para lugares turísticos
 Administrar alojamientos para lugares turísticos
 Administrar lugares de comida
 Administrar medios de transporte
 Gestionar reservas de alojamientos
 Registración de información de turistas que visitan los lugares
 Registrar información de excursiones realizadas por turistas
 Generación de informes de:
o Excursiones más requeridas.
o Cantidad de turistas que visitan cada lugar turístico.
o Comparativo de turistas por año por lugar turístico
Reglas de Negocio:

1. Información de Visitantes Se registra de los visitantes si son argentinos, información sobre localidad
y provincia de procedencia; si son extranjeros sólo se registra el país de
procedencia.
2. Reserva de hospedajes Se puede registrar reservas para hospedajes en cualquier tipo de
alojamiento ubicadas en cualquier lugar turístico de los que están
registrados en el sistema.
3. Variación de Precios Los precios pueden tener variaciones en función de la temporada.
4. Cancelación de reservas Se puede cancelar una reserva siempre que aún no haya sido confirmada
por el alojamiento.
5. Confirmación de reservas Las reservas realizadas por el sitio web deben ser confirmadas por el
alojamiento correspondiente.
Diagrama de Casos de Uso esenciales

uc Use Case Model
Consultar
Excursión Consultar Lugar
Consultar Medio
de Transporte de Interés
«extend»
«extend» «extend» Registrar información de

turistas que visitan Lugares
Consultar Consultar
Turísticos
Alojamiento Consultar Lugar Restaurante
«extend» Turístico «extend»
Registrar información de
excursiones realizadas por
turistas
Usuario
Registrar Lugar
Turista Turístico
Generar Informe de
excursiones más
requeridas Encargado
Secretaría Turismo
Operador de Generar comparativo
Reserva de turistas entre
Cancelar
Reserva de lugares turisticos
Alojamiento
Registrar
Restaurante Registrar Generar estadísitcas de
Reserva de turistas que visitan cada
Generar comparativo de
Alojamiento lugar turistico
turistas por año en lugares
turísiticos
Registrar
Excursión
Responsable Registrar Medio de
Atención al Turista Transporte
Administrador del
Sistema
Registrar
Lugares de
Interes
Registrar
Alojamiento Registrar
Empresa de
Transporte

Trazo fino: Registrar reserva de alojamiento
Nombre del Caso de Uso: Registrar Reserva de Alojamiento ID: 8

Actor Principal: Operador de Reserva (OR) Actor Secundario: no aplica
Objetivo: Registrar una reserva en un alojamiento en un determinado lugar turístico (LT).
Precondiciones: usuario logueado
Post- Condiciones Éxito: reserva registrada.
Fracaso 1: No existen alojamientos en ese LT, para el tipo de alojamiento elegido.
Fracaso 2: El OR no confirma la reserva.
Fracaso 3: El OR cancela la ejecución del caso de uso.
Fracaso 4: El OR no ingresa los datos mínimos solicitados.
1. OR: elige la opción “Registrar Reserva de
Alojamiento”
2. Sistema: muestra los lugares turísticos y solicita se
seleccione uno.
3. OR: selecciona un lugar turístico.
4. Sistema: muestra los tipos de alojamientos
registrados para ese lugar turístico y solicita
seleccionar uno.
5. OR: selecciona un tipo de alojamiento.
6. Sistema: muestra todos los alojamientos disponibles 6.A. No existen alojamientos disponibles para el tipo
en el lugar turístico para el tipo de alojamiento de alojamiento elegido.
seleccionado. 6.A.1. El sistema muestra un mensaje informando la
situación.
7. OR: selecciona un alojamiento.
8. Sistema: muestra las comodidades ofrecidas y los
regímenes alimentarios disponibles en el alojamiento
elegido, y solicita seleccionar un régimen alimentario.
9. OR: selecciona un régimen alimentario.
10. Sistema: solicita ingresar la fecha de reserva y la
cantidad de días que se alojará el turista.
11. OR: ingresa la fecha de reserva y la cantidad de días.
12. Sistema: para cada habitación a reservar muestra

los tipos de habitaciones y solicita seleccionar uno.
13. OR: selecciona un tipo de habitación.
14. Sistema: muestra el precio de la habitación según el
régimen alimentario elegido y la temporada.
15. Sistema: solicita confirmar la habitación a reservar.
16. OR: confirma la habitación. 16.A. El OR no confirma la habitación.
16.A.1. Permite seleccionar otra habitación.
17. Sistema: agrega la habitación a la reserva
18. Sistema permite quitar una habitación de las
indicadas para incluir en la reserva.
19. OR: no desea quitar una habitación reservada. 19.A. OR: desea quitar una habitación reservada.
19.A.1. Sistema: solicita seleccionar la habitación.
19.A.2. OR: selecciona la habitación a quitar de la
reserva.
19.A.3. Sistema: solicita confirmar la eliminación de la
habitación.
19.A.4. OR: confirma la eliminación.
19.A.4.A. OR: no confirma la eliminación.
19.A.5. Sistema: quita la habitación de la reserva.
20. Sistema: calcula y muestra la fecha de retiro y el
costo total del alojamiento.
21. Sistema: solicita confirmar la reserva.
22. OR: confirma la reserva. 22.A. OR: no confirma la reserva.
23. Sistema: verifica que los datos mínimos requeridos 23.A. Falta ingresar datos requeridos.
para crear la reserva (lugar turístico, alojamiento, 23.A.1. Sistema: muestra un mensaje solicitando
régimen alimentario, fecha de reserva, cantidad de ingresar los mismos.
días, al menos una habitación) y han sido ingresados; y 23.A.2. OR: ingresa los datos solicitados.
es así. 23.A.2.A. OR: no ingresa los datos solicitados.
24. Sistema: registra la reserva al turista en estado “A 24.A. La reserva no se registró con éxito.
Confirmar”, informa que la reserva se registró con 24.A.1. Sistema: muestra un mensaje informando la
éxito y muestra el número de la misma. situación.
Requerimientos no Funcionales Asociados: no aplica

Trazo medio: Registrar reserva de alojamiento
Nombre del Caso de Uso: Registrar Reserva de Alojamiento ID: 8

Actor Principal: Operador de Reserva (OR) Actor Secundario: no aplica
Objetivo: Registrar una reserva en un alojamiento en un determinado lugar turístico (LT).
Flujo básico
1. OR: elige la opción “Registrar Reserva de Alojamiento”
2. Sistema: muestra los lugares turísticos y solicita se seleccione uno.
3. OR: selecciona un lugar turístico.
4. Sistema: muestra los tipos de alojamientos registrados para ese lugar turístico y solicita seleccionar uno.
5. OR: selecciona un tipo de alojamiento.
6. Sistema: muestra todos los alojamientos disponibles en el lugar turístico para el tipo de alojamiento
seleccionado.
7. OR: selecciona un alojamiento.
8. Sistema: muestra las comodidades ofrecidas y los regímenes alimentarios disponibles en el alojamiento
elegido, y solicita seleccionar un régimen alimentario.
9. OR: selecciona un régimen alimentario.
10. Sistema: solicita ingresar la fecha de reserva y la cantidad de días que se alojará el turista.
11. OR: ingresa la fecha de reserva y la cantidad de días.
12. Sistema: para cada habitación a reservar muestra los tipos de habitaciones y solicita seleccionar uno.
13. OR: selecciona un tipo de habitación.
14. Sistema: informa el precio de la habitación del alojamiento según régimen alimentario elegido y la
temporada.
15. Sistema: solicita confirmar la habitación a reservar.
16. OR: confirma la habitación.
17. Sistema: agrega la habitación a la reserva
18. Sistema permite quitar una habitación de las indicadas para incluir en la reserva.
19. OR: no desea quitar una habitación reservada.
20. Sistema: calcula y muestra la fecha de retiro y el costo total del alojamiento.
21. Sistema: solicita confirmar la reserva.
22. OR: confirma la reserva.
23. Sistema: verifica que los datos mínimos requeridos han sido ingresados: lugar turístico, alojamiento,
régimen alimentario, fecha de reserva, cantidad de días y al menos una habitación; y es así.
24. Sistema registra la reserva al turista en estado “A Confirmar”, informa que la reserva se registró con éxito
y muestra el número de la misma.
Alternativas
A1: OR no confirma la habitación
A2: OR desea quitar una habitación reservada
A3: OR no confirma la reserva
A4: Falta ingresar datos requeridos
A5: La reserva no se registró éxito
Trazo grueso: Cancelar reserva de alojamiento
Nombre del Caso de Uso: Cancelar Reserva de Alojamiento ID: 10

Complejidad: Simple Mediano Complejo Muy Complejo Extremadamente
Complejo
Actor Principal: Turista (TUR) Actor Secundario: no aplica
Objetivo: Registrar la cancelación de una reserva a confirmar de un cliente.
Descripción: El caso de uso comienza cuando el TUR selecciona la opción “Cancelar Reserva”. El sistema
muestra todas las reservas en estado “A Confirmar” y solicita seleccionar la que será cancelada. El TUR
selecciona la reserva e ingresa un motivo y, al confirmar la cancelación, el sistema la registra, actualizando
su estado. Fin del caso de uso.
Observaciones: El actor podrá cancelar la ejecución del caso de uso en cualquier momento mediante la
opción “Cancelar”.
Construcción de prototipo de interfaz de usuario

Caso de uso: Registrar reserva de alojamiento
Diagrama de Clases
class Domain M ode l
M e dioTr an spor te E m pr e saTr an spor te E poc aV isita

empresaTransporte Te m por ada
precio mailContacto mesFin
descricpion
P ais 1..* razonSocial mesInicio
conocerEmpresaTransporte() telContacto nombre
0..1 nombre
nombre 0..* webInstitucional 1
0..*
conocerProvincia() 0..1
medioTransporte
{mutuamente
provincia epocaVisita
excluyentes} Lu gar Tu r istic o
1..* descripcion
temporada TipoHabitac ion
pais kmDistanciaDesdeCapital
P r ovin c ia nombre caracteristicas
V isitan te
conocerAlojamiento() P r e c io nombre
esCapitalPais año visitante
nombre conocerEpocaDeVisita() montoReferencia 1
cantidad
conocerExcursion()
conocerLocalidad() finPeriodo 0..* conocerRegimenAlimentario()
conocerLugarDeInteres() 1..*
inicioPeriodo
esCapital() conocerMedioTransporte() 1..* conocerTemporada() precio
tipoHabitacion
conocerLocalidad() conocerVisitante()
conocerPais() excursionMasDemandada() 1..*
regimenAlimentario
localidad 1..* excursion
localidad 0..1
Loc alidad demanda precio
0..1 R e gim e n Alim e n tar io
0..* regimenAlimentario
esCapital
descripcion TipoAlojam ie n to
nombre
E xc u r sion nombre
conocerLugarTuristico() 1..* cantidadEstrellas
dondeParte 1..*
esCapital() caracteristicas
nombre regimenAlimentario tipoAlojamiento 1 nombre
0..1 1 calcularDuracionEstimada()
lugarInteres 0..* demanda conocerDemandaExcursion() Alojam ie n to habitacion Habitac ion
conocerDetalleExcursion() 1..*
conocerPrecio() domicilio numero
De m an daE xc u r sion
0..* nombre
conocerPrecio()
año 1
conocerTipoHabitacion()
localidad cantidadVisitantes estrellas
finPeriodo E str e lla TipoCom ida 1
0..* inicioPeriodo 1..*
cantidadEstrellas descrpcion habitacion
Lu gar In te r e s descripcion tipoComida nombre
detalleExcursion
caracteristicas lugarInteres precio De talle R e se r va
1
nombre
precio De talle E xc u r sion SitioP ar aCom e r estado
Cate gor iaR e stau r an te
1..* categoriaRestaurante precioHabitacion
conocerLocalidad() orden domicilio cantTenedores
tiempoEstimadoPermanencia nombre 1 nombre conocerHabitacion()
conocerLugarInteres() estaCancelada()
conocerCategoriaRestaurante()
conocerPrecio() detalleReserva 1..*
conocerTipoComida()
Tu r ista
localidad
apellido R e se r va
celular
pais mail fechaReserva
nombre reserva fechaVto
telefono numero
1
conocerLocalidad() conocerDetalleReserva()
conocerPais() conocerEstado()
conocerTurista()
estaCancelada()
estaVigente()
Patrones Coad

#12 Asociación – Otra Asociación Habitacion – TipoHabitación
SitioParaComer – TipoComida
SitioParaComer – CategoriaRestaurante
Alojamiento – Estrella
Alojamiento – TipoAlojamiento
#3 Participante – Transacción Turista - Reserva
#6 Transacción – Detalle de Transacción Excursión – DetalleExcursión
Reserva – DetalleReserva
#9 Ítem -Detalle de Transacción DetalleExcursion – LugarInteres
DetalleReserva - Habitacion
#4 Lugar – Transacción LugarTuristico – Excursión
#17 Todo-Parte Pais – Provincia
Provincia – Localidad
Alojamiento - Habitación
Solución Propuesta: Editorial

Objetivo del SI:
Administrar la publicación de obras de diferentes géneros y gestionar el vínculo contractual con los actores, incluyendo
los pagos correspondientes, brindando información resultante de la gestión.
Requerimientos Funcionales
 Administración de autores
 Administración de editores
 Administración de los trámites de contratación
 Gestión de la información sobre imprentas
 Registración y seguimiento del estado y evolución de los libros
 Gestión de la liquidación de sueldos
 Gestión de la liquidación de comisiones
o Diez autores más populares
o Libros aceptados vs rechazados
o Libros más vendidos y libros menos vendidos
Reglas de Negocio:

1. Asignación de Editores Si el autor no tiene editor asignado, o el que tiene asignado no está
disponible, se le asigna un editor en función de la disponibilidad del
momento.
2. Forma de contratación de Se puede contratar a los autores por un porcentaje en función de las
autores ventas o un monto fijo “tipo sueldo”.
3. Contratos Cada autor tiene un contrato para cada libro, ese contrato tiene un tipo
de liquidación asociada que puede ser sueldo o comisión.
Al renovarse un contrato asociado a un libro, se pueden cambiar las
condiciones de contratación, por ejemplo, el monto o el porcentaje de
comisión según corresponda.
4. Criterios para liquidaciones Al liquidar se consideran los siguientes criterios: para los sueldos el
contrato contiene el monto, y para las comisiones el porcentaje. Las
comisiones dependen de las ventas informadas para el período a
liquidar.
5. Adelantos para autores Si existen adelantos se descuentan los montos prestados de las
liquidaciones conforme se haya pactado en el momento del
otorgamiento de los mismos.
6. Liquidación por tipo de Se genera un comprobante por cada tipo de liquidación, es decir si un
liquidación autor tiene más de un libro con la editorial se liquidan por un lado todos
los que cobra por sueldo y por otro todos los que cobra por comisiones.
7. Cheques de pago de Para cada liquidación generada, se imprime un cheque diferente.
liquidaciones

8. Ventas en Librerías Las librerías deben informar la venta de libros discriminadas por cada
sucursal que posea. Por ejemplo:
Libro: Las venas abiertas de América Latina
Sucursal Nuevo Centro: $ 10.000
Sucursal Nueva Córdoba: $7.800
Libro: El libro de los abrazos
Sucursal Nuevo Centro: $ 20.000
Sucursal Nueva Córdoba: $9.800
9. Asignación de Imprenta Un libro se asigna a una imprenta y mientras la imprenta trabaje con la
editorial, no se cambia la asignación.
10. Vigencia de contratos No puede haber más de un contrato vigente al mismo tiempo, para el
mismo libro.
Diagrama de Casos de Uso esenciales
uc Modelo de casos de uso
Imprimir
Registrar listado de Generar
autor control «extend» preliquidaciones
Recepcionista Responsable de
Registrar Liquidación
Registrar
contrato libro
Asignar Editor Liquidar
comisiones
Asignar
Asignar encargado de
diseño Liquidar
Revisor sueldos
gráfico
Registrar
resultado de
revisión
Revisor Editor Registrar
resultado de
evaluación
Registrar ingreso
de ejemplares
desde la imprenta
Asignar
imprenta
Generar
Reporte de
Autores más
populares
Supervisor de
Editores
Generar
Reporte de
Libros más
vendidos

Trazo fino: Generar pre-liquidaciones de pagos para autores
Nombre del Caso de uso: Generar pre-liquidaciones de pagos para ID: 1

autores
Actor Principal: Responsable de Liquidaciones (RL) Actor Secundario: no aplica

Objetivo: obtener las pre-liquidaciones de los pagos mensuales correspondientes a cada autor que tenga
contratos vigentes.
Precondiciones: usuario logueado con permisos de Responsable de Liquidaciones.
Post- Condiciones Éxito 1: Pre-liquidaciones generadas.
Éxito 2: Pre-liquidaciones generadas y listado de control impreso.
Fracaso 1: Existe liquidación para el mes seleccionado y el RL no selecciona otro mes.
Fracaso 2: No hay contratos vigentes para los autores seleccionados.
1. RL: selecciona la opción Generar Pre-liquidaciones
de Pagos.
2. Sistema: Solicita se seleccione el mes que se va a
liquidar.
3. RL: selecciona el mes/año.
4. Sistema: valida que no existe liquidación generada 4.A. Sistema: valida que no exista liquidación generada y
para el mes/año y no existe. existe.
4.A.1. Sistema: informa la situación y solicita se seleccione
otro mes/año.
4.A.2. RL: selecciona otro mes/año.
4.A.2.A. RL: No selecciona otro mes/año.
4.A.2.A.1. Se cancela el caso de uso
5. Sistema: solicita se seleccionen criterios para la
liquidación (tipos de liquidación a incluir y autores a
incluir).
6. RL: selecciona criterios. 6.A. RL: No selecciona criterios
6.A.1 Sistema: toma todos los tipos de liquidaciones y
todos los autores.
7. Sistema: busca para los autores seleccionados los 7.A. Sistema: busca para los autores seleccionados los
contratos asociados que estén vigentes y encuentra contratos asociados que estén vigentes y NO encuentra
al menos uno. ninguno.
7.A.1. Sistema: informa la situación.

8. Sistema: para cada autor y contrato vigente 8.A. Sistema: para cada autor y contrato vigente de cada
determina el tipo de liquidación y es “Sueldo”, por lo libro determina el tipo de liquidación y es “Comisión”.
que determina el monto que corresponde liquidar en 8.A.1 Sistema: busca las ventas registradas para el libro en
función de lo especificado en el contrato. el período y el porcentaje de comisión acordado con el
autor.
8.B. Sistema: para cada autor y contrato vigente de cada

libro y determina el tipo de liquidación y es “Comisión” +
“Sueldo”
8.B.1 Sistema: determina el monto que corresponde
liquidar en función de lo especificado en el contrato.
8.B.2 Sistema: busca las ventas registradas para el libro en
el período y el porcentaje de comisión acordado con el
autor.
9. Sistema: busca conceptos de descuento y no 9.A. Sistema: busca conceptos de descuento y encuentra
encuentra. al menos uno.
10.A.1 Sistema: toma cada uno de los conceptos de
descuento y los montos asociados.
10. Sistema: Calcula el monto que corresponde
liquidar por cada contrato que tiene el autor.
11. Sistema: Agrupa para cada autor y tipo de
liquidación lo que corresponde liquidar en el mes.
12. Sistema: Genera una liquidación por autor y tipo
de liquidación, muestra el listado de control y solicita
confirmación para imprimir listado de control.
13. RL: no confirma impresión del listado de control. 13.A. RL: confirma impresión del listado de control.
13.A.1. Sistema: Para imprimir se llama al caso de uso
Imprimir Listado de Control.
13.A.2. Sistema: El caso se uso se ejecutó con éxito.
13.A.2.A Sistema: El caso se uso NO se ejecutó con éxito.
14.A.2.A.1. Sistema: Informa la situación.
Fin del caso de uso
Observaciones: no aplica
Asociaciones de Extensión: Imprimir listado de control
Trazo medio: Generar pre-liquidaciones de pagos para autores
Nombre del Caso de uso: Generar pre-liquidaciones de pagos para ID: 1

autores
Actor Principal: Responsable de Liquidaciones (RL) Actor Secundario: no aplica

Objetivo: obtener las pre-liquidaciones de los pagos mensuales correspondientes a cada autor que tenga
contratos vigentes.
Curso Básico
1. RL: selecciona la opción Generar Pre-liquidaciones de Pagos.
2. Sistema: Solicita se seleccione el mes/año correspondiente a la liquidación.
3. RL: selecciona el mes/año.
4. Sistema: valida que no existe liquidación generada para el mes/año y no existe.
5. Sistema: solicita se seleccionen criterios para la liquidación (tipos de liquidación a incluir y autores a incluir).
6. RL: selecciona criterios.
7. Sistema: busca para los autores seleccionados, los contratos asociados que estén vigentes y encuentra el
menos uno.
8. Sistema: para cada autor y contrato vigente determina el tipo de liquidación y es “Sueldo”.
9. Sistema: determina el monto que corresponde liquidar en función de lo especificado en el contrato.
10. Sistema: busca conceptos de descuento y no hay descuentos para realizar.
11. Sistema: Calcula el monto que corresponde liquidar por cada contrato que tiene el autor.
12. Sistema: Agrupa para cada autor y tipo de liquidación lo que corresponde liquidar en el mes.
13. Sistema: Genera una liquidación por autor y tipo de liquidación, muestra el listado de control y solicita
confirmación para imprimir listado de control.
14. RL: no confirma impresión del listado de control. Fin del caso de uso.
Alternativas
A1: Ya hay pre-liquidación generada para el mes/año ingresado.
A2: RL no selecciona criterios para la liquidación.
A3: No hay contratos asociados que estén vigentes para el período mes/año ingresado.
A4: Se determina el tipo de liquidación para cada autor y contrato vigente y es “Comisión”.
A5: Se determina el tipo de liquidación para cada autor y contrato vigente y es “Comisión” + “Sueldo”.
A6: Hay al menos un descuento aplicable, para el período mes/año a liquidar.
A7: RL confirma la impresión del listado de control, se llama al caso de uso Imprimir Listado de Control.
Trazo grueso: Asignar revisor
Nombre del Caso de Uso: Asignar revisor ID: 2

Actor Principal: Editor Actor Secundario: no aplica
Objetivo: Asignar un revisor a un libro con evaluación positiva.
Descripción: El caso de uso comienza cuando el Editor selecciona la opción “Asignar revisor”. El sistema muestra
los libros cuya evaluación sea positiva y sus correspondientes autores y solicita seleccionar cual será asignado. El
Editor selecciona el libro al cual desea asignarle un revisor. El sistema muestra los revisores disponibles y solicita
seleccionar un revisor. El Editor selecciona el revisor deseado y confirma la selección. El sistema registra la
selección. Fin del caso de uso.
Observaciones: El actor podrá cancelar la ejecución del caso de uso en cualquier momento mediante la opción
“Cancelar”.
Construcción de un prototipo de interfaz de usuario

Caso de Uso: Generar pre liquidación
6. Diagrama de clases
class Modelo de dominio
1
Empleado Contrato 1
Los métodos de TipoLiquidacion
apellido 1 fechaCreacion tipoLiquidacion
seteo y el Rol
dni editor fechaVencimiento descripcion
constructor, descripcion fechaBaja montoSueldo nombre
1 rol Libreria
especificados en la nombre nombre porcentajeComision mostrarNombre()
clase Genero, son ImpresiónLibro cuit
estáActivo() buscarConceptoDto()
nombre 1
aplicables a todas cantCopias calcularMontoALiquidar()
las clases característicasImpresión impresión calcularMontoDtoPeriodo() conocerSucursal()
fechaEnvío 0..1 cuantosLibrosVendio()
imprenta fechaFinalización
conocerDescuento()
Imprenta conocerEditor() obtenerSucursales()
conocerImprenta()
domicilio conocerImprenta()
1 libroRelacionado
nombre 0..* 0..* conocerTipoLiquidacion() sucursal
estaVigente()
Genero
Libro contrato mostrarMontoSueldo() 1..*
descripcion añoPublicacion mostrarTipoLiquidacion()
nombre Sucursal
1 esTomoUnico descuento
genero
getDescripcion() nombre domicilio
getNombre() nombreOriginal 1 numeroSucursal
new() conocerVenta()
historial conocerContrato() venta
setDescripcion() Venta
conocerEstado() cuantosLibrosVendio()
setNombe() conocerGenero() cantidadLibrosVendidos 0..*
conocerImprenta() fechaFin
responsableEstado 1..* conocerLibroRelacionado() fechaInicio Concepto
obtenerContratoVigente() monto
HistoriaEstadoLibro obtenerHistorialEstados() descripcion
conocerContrato() nombre
descripcion obtenerTipoLiqDelContrato() 0..* 0..*
fechaFin 1..* 1 venta
1
fechaInicio Descuento
ConceptoLiquidado
conocerEmpleado() fechaOtorgamiento concepto
conocerEstado() liquidado descuento monto tipoLiquidacion
monto calcularMontoConcepto()
0..*
conocerConceptoDescuento() conocerConcepto()
Liquidacion
estaLiquidado() conocerDescuento()
conocerVenta() esPreLiquidación
estado conceptoDescuento 1 fechaCreacion
mesAñoLiquidado
ConceptoDescuento nroCheque
detalleLiquidacion nroLiquidacion
1 descripcion DetalleLiquidacion
nombre calcularMontoLiquidacion()
orden
Estado conocerAutor()
calcularMontoDetalleLiq() conocerDetalleLiquidacion()
descripcion libro
concerConceptoLiquidado() 1..* conocerTipoLiquidacion()
nombre
conocerLibro() crearDetalleLiquidacion()
crearConceptoLiquidado() new()
new()
autor
libro
Autor 1
domicilio
mail
nombre
telefono
buscarConceptosDto()
buscarContratosVigentes()
buscarMontoALiquidar()
buscarTipoLiquidacion()
calcularMontoALiquidarPorContrato()
conocerLibro()
cuantosLibrosPorEstado()
cuantosLibrosPublicados()
ingresosObtenidosPorLibro()
mostrarNombre()
Patrones Coad
#12 Asociación – Otra Asociación Liquidación - TipoLiquidacion
#3 Participante – Transacción Contrato – Editor
Liquidacion - Autor
#6 Transacción – Detalle de Transacción Liquidacion - DetalleLiquidacion
#9 Ítem -Detalle de Transacción DetalleLiquidacion – Libro
#14 Contenedor – Contenido Librería - Sucursal
Solución Propuesta: Torneo de Municipalidad

Objetivo del SI:
Gestionar la información sobre los torneos de atletismo organizados por la secretaría de deportes de la Municipalidad
de Villa María, administrando la información sobre las diferentes disciplinas, los competidores y las categorías.
Resolviendo, además, el procedimiento de inscripción de los alumnos a los diferentes torneos.
Requerimientos funcionales (Alcances)
→ Administrar Torneos y sus sedes

→ Administrar disciplinas y categorías para las competencias
→ Administrar competidores
→ Administrar escuelas
→ Gestionar inscripciones
→ Administrar exámenes médicos
→ Gestionar resultados de competencias
→ Generar informes de:
o Cantidad de inscriptos que cumplieron los requisitos y compitieron.
o Mejores competidores por categoría, disciplina, sexo.
o Escuelas que más premios obtienen.
o Comparativos de resultados obtenidos en las competencias.
Reglas de Negocio:
1. Organización de torneos Los torneos se organizan por disciplinas (carreras, salto en largo, jabalina,
etc.), en los que pueden participar competidores de diferente sexo y
categoría (clasificados de acuerdo a la edad)
2. Participantes de torneos Los torneos se organizan solamente para alumnos de las escuelas de la
zona.
3. Pertinencia de los competidores Los competidores necesariamente tienen que pertenecer a una escuela,
que es quien debe presentar las inscripciones.
4. Inscripción de participantes Las escuelas que desean participar, deben inscribir a sus alumnos.
5. Creación de inscripciones Se generan inscripciones independientes para cada participante en cada
una de las disciplinas que desea competir,
6. Estados de la inscripción Se evalúa si los datos de la inscripción son correctos, si esta evaluación es
aprobada, la inscripción queda pre-aprobada, desde ese momento tienen
plazo hasta cinco horas antes del inicio de la competencia, para realizar el
examen médico reglamentario, recién después de superadas ambas
instancias el participante está en condiciones de competir.
Diagrama de casos de uso esenciales

uc Use Case Vista Esencial
Registrar
Registrar Competencia
Categoría
Generar Informe de
inscriptos que
compitieron
Evaluador de
Inscripciones
Registrar Registrar
Registrar Sede
Disicplina Administrador de Evaluación de
Torneo inscripción
Generar Comparativo Generar Informe de

Generar Reporte de de resultados de
mejores
Escuelas más Registrar competencias competidores
premiadas Torneo
Registrar Registrar
Resultado de resultado de
competencia examen médico
Registrar
inscripción de Responsable de
Aspirantes Competencia
Generar Listado de
Responsable de mejores
Inscripciones competidores
Responsable de Generar Reporte de

Secretaría de Registrar
Escuela resultados de
Deportes competencia

Trazo fino: Registrar aspirante
Nombre del Caso de Uso: Registrar inscripción de aspirantes ID: 1

Actor Principal: Responsable de Inscripciones (RI) Actor Secundario: no aplica
Objetivo: Registrar a uno o más aspirantes de un colegio en una o más competencias, dentro de la categoría
correspondiente.
Precondiciones: usuario logueado con permisos de Responsable de Inscripciones.
Post- Condiciones Éxito: Se inscribió a o los aspirantes en la competencia.
Fracaso 1: El RI no encuentra la Escuela a la que pertenece el aspirante.
Fracaso 2: El RI no corrige los datos incorrectos del/los aspirante/s.
Fracaso 3: El RI decide cancelar el caso de uso.
1. RI: selecciona la opción Registrar aspirante.
2. Sistema: muestra un listado con las Entidades
Educativas registradas de la zona y solicita selección de
una.
3. RI: selecciona la Escuela. 3.A. RI no encuentra la Escuela buscada.
4. Sistema: solicita se ingresen datos personales del
aspirante (nombre, apellido, dirección, fecha de
nacimiento, sexo, DNI).
5. RI: ingresa los datos personales del aspirante.
6. Sistema: muestra los datos del aspirante recién
ingresado y solicita se informe si desea ingresar otros
aspirantes.
7. RI: no desea ingresar otro aspirante. 7.A- RI: desea ingresar otro aspirante.
7.A.1. RI selecciona la opción correspondiente.
7.A.2.Sistema: habilita el ingreso de datos personales
del aspirante.
7.A.3. RI ingresa los datos personales del aspirante.
7.A.4. Sistema: muestra datos del aspirante.
8. Sistema: Para cada aspirante ingresado, solicita se
seleccione las competencias a inscribirlo.
9. RI: Para cada aspirante, selecciona la/s competencia/s.
10. Sistema: solicita se seleccione la categoría para cada

competencia de cada aspirante, proponiendo una
categoría según la edad y el sexo del aspirante.
11. RI: no desea modificar la categoría propuesta por el 11.A. RI: desea modificar la categoría propuesta por el
sistema. sistema.
11.A.1. RI: selecciona la categoría correspondiente para
cada competencia de cada aspirante.
12. Sistema: solicita confirmación para registrar la
inscripción de los aspirantes.
13. RI: confirma la operación.
14. Sistema: valida que todos los aspirantes ingresados 14.A. Sistema valida que todos los aspirantes
estén vinculados al menos a una competencia en una ingresados estén vinculados al menos a una
categoría dada, y lo están. competencia en una categoría dada, y no lo están.
14.A.1. Sistema: informa la situación.
14.A.2. RI vincula a los aspirantes al menos a una
competencia en una categoría.
14.A.2.A. RI: no corrige los datos ingresados.
14.A.2.A.1. Sistema: cancela el caso de uso.
15. Sistema: registra la/s inscripción/es del/los
aspirante/s a las competiciones especificas del torneo
vigente.
Fin del caso de uso
Observaciones: En cualquier momento el actor puede cancelar el caso de uso seleccionando la opción definida
para tal fin.
Fuente: no aplica Referencia Fuente: no aplica
Trazo medio: Registrar aspirante
Nombre del Caso de Uso: Registrar inscripción de aspirantes ID: 1

Actor Principal: Responsable de Inscripciones (RI) Actor Secundario: no aplica
Objetivo: Registrar a uno o más aspirantes de un colegio en una o más competencias, dentro de la categoría
correspondiente.
Flujo Básico
1. RI: selecciona la opción Registrar aspirante.
2. Sistema: muestra un listado con las Escuelas registradas de la zona y solicita selección de una.
3. RI: selecciona la Escuela.
4. Sistema: solicita se ingresen datos personales del aspirante (nombre, apellido, dirección, fecha de nacimiento,
sexo, DNI).
5. RI: ingresa los datos personales del aspirante.
6. Sistema: muestra los datos del aspirante recién ingresado y solicita se informe si desea ingresar otros aspirantes.
7. RI: no desea ingresar otro aspirante.
8. Sistema: Para cada aspirante ingresado, solicita se seleccione las competencias a inscribirlo.
9. RI: Para cada aspirante, selecciona la/s competencia/s.
10. Sistema: solicita se seleccione la categoría para cada competencia de cada aspirante, proponiendo una
categoría según la edad y el sexo del aspirante.
11. RI: no desea modificar la categoría propuesta por el sistema.
12. Sistema: solicita confirmación para registrar la inscripción de los aspirantes.
13. RI: confirma la operación.
14. Sistema: valida que todos los aspirantes ingresados estén vinculados al menos a una competencia en una
categoría dada, y lo están.
15. Sistema: registra la/s inscripción/es del/los aspirante/s a las competiciones especificas del torneo vigente.
Fin del caso de uso
Alternativas
A1: RI no encuentra la Escuela buscada.
A2: RI desea ingresar otro aspirante.
A3: RI desea modificar la categoría propuesta por el sistema.
A4: Sistema valida que todos los aspirantes ingresados estén vinculados al menos a una categoría dada y no lo
están.
Observaciones: En cualquier momento el actor puede cancelar el caso de uso seleccionando la opción definida para
tal fin.
Trazo grueso: Registrar resultado de competencia
Nombre del Caso de Uso: Registrar Resultado de competencia ID: 2

Actor Principal: Responsable de Actor Secundario: no aplica
Competencia
Objetivo: Registrar los resultados de cada competidor en una categoría de una competencia determinada.
Descripción: El caso de uso comienza cuando el Responsable de competencia (RC) desea registrar los
resultados de una competencia. El sistema solicita se seleccione la competencia y la categoría a considerar.
El RC las selecciona, y registra para cada aspirante inscripto que haya aprobado el examen físico el resultado
en la competencia (si compitió o no, la posición en la que resultó, el tiempo cronometrado y faltas si las
hubiera). El caso de uso finaliza cuando el RC confirma el registro de los resultados.

Caso de Uso: Registrar aspirante
Diagrama de clases
Patrones Coad
#12 Asociación – Otra Asociación Inscripcion-EstadoInscripcion
Competencia-Disciplina
Competencia-Categoria
# 3 Participante – Transacción Competidor-Inscripcion
# 4 Lugar-Transacción Sede- Competencia
#6 Transacción – Detalle de Transacción Torneo-Competencia
#16 Grupo-Miembro Escuela-Competidor
Solución Propuesta: Control de Acceso a countries

Objetivo del SI:
Gestionar la información de los lotes, propiedades y obras de un country. Además, administrar el proceso de ingreso
y egreso de personas (propietarios, familia de los propietarios, obreros, visitantes) del country, gestionando las
tarjetas de acceso.
Requerimientos funcionales
 Administración de lotes, propiedades y obras en construcción.

 Administración de obreros asignados a obras y su horario laboral.
 Administración de propietarios y de su familia.
 Administración de visitantes autorizados por propietarios.
 Generación y emisión de tarjetas de acceso.
 Registración de entrada y salida de todas las personas al country.
o Accesos por cada tipo de persona.
o Momentos de día que ingresa más gente.
o Personal (obreros) asignados a una obra en particular.
o Nómina de Propiedades y Obras de un Propietario.
o Cantidad de Visitas por período de tiempo para cada propiedad.
o Administración de inicio y fin de obras.
OBSERVACIÓN: Cuando se menciona a la “familia” del propietario se hace referencia a aquellas personas que viven
con él.
Reglas de Negocio:

1. Personas que pueden ingresar Podrán ingresar al country las siguientes personas: propietarios,
familiares de los propietarios, obreros y visitantes.
2. Tarjetas de acceso Únicamente los propietarios y sus familiares poseen una tarjeta de
acceso que les permite el ingreso.
3. Ingreso de visitantes Para que los visitantes puedan ingresar, el guardia debe llamar por
teléfono al propietario del lote donde debe entrar el visitante para que
el propietario autorice el ingreso del visitante.
4. Ingreso de obreros Se controla el ingreso de los obreros, teniendo en cuenta su período de
trabajo (días de trabajo, horario de ingreso supuesto, horario de salida
supuesto, fecha de inicio y de fin de la obra donde trabajará).
Los obreros no pueden ingresar al country en días y horarios que no
hayan sido autorizados previamente por los propietarios.
5. Control de ingresos/egresos En cualquiera de los accesos al country, no se debe permitir que una
persona pueda ingresar dos veces sin haberse registrado la salida, y
viceversa.
Diagrama de casos de uso esenciales

uc Use Case M ode l
Consultar Re gistrar Re gistrar Lote

Ingre sos de ingre so de
Pe rsonas pe rsona Re gistrar
Propie dad
Re gistrar
Guardia
«extend»
Re gistrar
Egre so de
Pe rsona Administrador
Emple ado de Re gistrar Ge ne rar Informe de
de l Country
Control de Propie tario Ingre sos por tipo de
Acce so Pe rsonas
Ge ne rar
Re gistrar Tarje ta de «extend»
Autorización Acce so Ge ne rar
para Ingre so de Re gistrar Informe de
Pe rsona Familiar Ingre sos por
Ge ne rar Re porte de Horarios
Obre ros y sus
asignacione s a Obras
Ge ne rar Ge ne rar Informe de
Re porte de Visitas a
Re gistrar Propie dade s Propie dade s e n un
Re gistrar
Obra
Obre ro Pe ríodo
Re gistrar Fin
de Obra
Encargado de
Obras
Re gistrar
Turno de
Trabajo de
Obre ro

Trazo fino: Registrar egreso de persona
Nombre del Caso de Uso: Registrar Egreso de Persona ID: 4

Actor Principal: Empleado del Control de Accesos (EC) Actor Secundario: no aplica
Objetivo: Registrar la salida de una o más personas que han ingresado previamente al country.
Precondiciones: usuario logueado con permisos de Empleado de Control de Accesos
Post- Condiciones Éxito: Egresos de las personas registrados correctamente.
Fracaso 1: El EC no desea corregir la fecha y hora de egreso.
Fracaso 2: No hay ingresos sin egreso registrado.
Fracaso 3: El EC no confirma la operación.
Fracaso 4: El EC decide cancelar el caso de uso.
1. EC: selecciona la opción Registrar egreso
de persona
2. Sistema: solicita se ingrese fecha y hora de

egreso, proponiendo la fecha y hora
actual.
3. EC: no modifica la fecha y hora propuesta. 3.A EC: modifica la fecha y hora propuesta.
3.A.1- Sistema: valida que la fecha y hora sea válida, y lo es.
3.A.1.A- Sistema: valida que la fecha y hora sea válida, y no
lo es. (Ver Observación 2)
3.A.1.A.1- Sistema: informa la situación y solicita se corrija la
fecha y hora.
3.A.1.A.2- EC: corrige la fecha y hora.
3.A.1.A.2.A- EC no corrige la fecha y hora.
3.A.1.A.2.A.1- Sistema cancela el caso de uso.
4. Sistema: busca los ingresos sin egreso 4.A- Sistema: busca ingresos sin egreso registrado y no
registrado y muestra los datos de las encuentra ninguno.
personas (Propietarios, Familiares, 4.A.1- Sistema informa la situación y cancela el caso de uso.
Obreros y visitantes) que ingresaron y
solicita se seleccione quienes egresan del
country.
5. EC: selecciona las personas que desean 5.A- EC: no encuentra todas las personas que ingresaron.
salir. 5.A.1. EC: Encuentra al menos una persona, selecciona la/s
persona/s que encuentra.
5.A.1.A EC: NO encuentra ninguna persona.
5.A.1.A.1. EC: Registra observación informando la
situación.
5.A.1.A.2. Sistema: cancela el caso de uso.
5.A.2. Registra observación informando la situación.
5.A.3 Se cancela el caso de uso.
6. Sistema: solicita confirmación para
registrar el egreso de las personas
seleccionadas.
7. EC confirma la operación. 7.A- EC no confirma la operación.
7.A.1- Sistema: cancela el caso de uso.
8. Sistema: registra la salida del country de
cada persona seleccionada, indicando
fecha y hora de salida.
Fin del caso de uso
Observaciones:
1. En cualquier momento el actor puede cancelar el caso de uso.
2. La fecha y hora de salida no debe ser mayor a la fecha y hora actual.

Trazo medio: Registrar egreso de persona
Nombre del Caso de Uso: Registrar Egreso de Persona ID: 4

Complejidad: Simple Mediano Complejo Muy Complejo Extremadamente
Complejo
Actor Principal: Empleado de Control de Acceso Actor Secundario: no aplica
(EC)
Objetivo: Registrar la salida de una o más personas que han ingresado previamente al country.
Flujo Básico
1. EC: selecciona la opción Registrar egreso de persona
2. Sistema: solicita se ingrese fecha y hora de egreso, proponiendo la fecha y hora actual.
3. EC no modifica la fecha y hora propuesta.
4. Sistema: busca los ingresos sin egreso registrado y muestra los datos de las personas (Propietarios,
Familiares, Obreros y visitantes) que ingresaron y solicita se seleccione quienes egresan del country.
5. EC: selecciona las personas que desean salir.
6. Sistema: solicita confirmación para registrar el egreso de las personas seleccionadas.
7. EC confirma la operación.
8. Sistema: registra la salida del country de cada persona seleccionada, indicando fecha y hora de salida.
Fin del caso de uso
Alternativas
A1: EC modifica la fecha y hora propuesta
A2: El sistema busca ingresos sin egreso registrado y no encuentra ninguno.
A3: EC no encuentra todas las personas que ingresaron.
A4: EC no confirma la operación.
Observaciones:
1. En cualquier momento el RC puede cancelar el caso de uso.
2. La fecha y hora de salida no debe ser mayor a la fecha y hora actual.
Trazo grueso: Registrar turno de trabajo de obrero
Nombre del Caso de Uso: Registrar Turno de Trabajo de Obrero ID: 12

Actor Principal: Encargado de Obras (EO) Actor Secundario: no aplica
Objetivo: Registrar horarios y días de trabajo de un obrero en una obra que está en ejecución dentro del
country.
Descripción: El caso de uso comienza cuando el Encargado de Obras del Country (EO) desea registrar el
turno de trabajo a un obrero. El sistema muestra las obras iniciadas, y el EO selecciona una obra. El sistema
muestra una lista de los obreros registrados, y el EO selecciona el obrero en cuestión, asignándole un horario
de entrada, horario de salida y días de la semana de trabajo. El caso de uso finaliza cuando el EO confirma la
registración del turno de trabajo al obrero elegido.

Caso de Uso: Registrar egreso de persona
Diagrama de clases
class Modelo de dominio
Lote
TarjetaDeAcceso
Métodos de seteo y Familiar
numero
estaHabilitada
constructor se apellido superficie
fechaOtorgamiento
especifican en dni ubicacion
fechaVencimiento
nombre
todas las clases numero conocerObra()
como están en la conocerAcceso() tarjeta conocerPropiedad()
1 deshabilitar()
clase Familiar conocerParentesco() 1..* cuantasObras()
estaHabilitada()
conocerTarjeta() cuantasPropiedades()
habilitar()
getApellido() tieneObra()
getDni() 1 tienePropiedad()
getNombre()
tarjeta 0..*
new() familiar
setAcceso() 0..*
lote
propiedad
parentesco setApellido() Propietario
0..*
setDni() obra
Paretesco 1 apellido
setNombre() Propiedad
descricpion dni Obra
setParentesco()
nombre caracteristicas
nombre setTarjetaAcceso() fechaFinReal
superficieEdificada
aQuienAutorizo() fechaInicio
acceso cantidadLotes() conocerAutorizacion() fechaPrevistaFin
cantidadPropiedades() tieneAccesos()
calcularDuracionEstimada()
conocerAcceso() tieneAutorizaciones()
conocerAutorizacion()
acceso conocerAutorizacion() propiedad
finalizarObra()
conocerFamiliar()
tieneAccesos()
conocerLote() autorizacion
tieneAutorizaciones()
conocerTarjetaAcceso() 0..*
autorizacion 1
cuantasAutorizaciones()
tieneObras() Autorizacion
0..*
0..*
estado
Visitante
fecha visitante
hora apellido obra
0..* 0..* 1 dni
acceso autorizarIngreso()
Acceso nombre
conocerAcceso()
fechaIngreso conocerVisitante()
fechaSalida
horaIngreso 0..*
horaSalida Obrero
0..*
conocerTurnoTrabajo() apellido PeriodoTrabajo
cuantoTiempoEstuvo() dni
periodosDeTrabajo
diasDeTrabajo
obtenerGuardiaQueTrabajo() acceso nombre fechaFin
calcularTiempoTrabajadoObra() 0..* fechaInicio
turnoTrabajo
conocerAcceso() horaEntrada
conocerPeriodoTrabajo() horaSalida
estaTrabajando() calcularDuracionTurno()
conocerObra()
1
estaVigente()
TurnoDeTrabajo Guardia
fechaFin apellido
fechaInicio guardia dni
horaFin domicilio
1
horaInicio fechaBaja
conocerGuardia() fechaIngreso
legajo
nombre
Patrones Coad
# 3 Participante – Transacción Guardia – Acceso
Obrero – Acceso
Propietario – Acceso
Familiar - Acceso
Propietario – Autorización
Guardia – Autorización
Visitante – Autorización
#7 Transacción- Transacción Subsiguiente Acceso - Autorización
# 4 Lugar – Transacción Propiedad – Autorización
Obra – Autorización
# 14 Contenedor – Contenido Lote – Propiedad
Lote – Obra
Historial de Cambios
Versión Fecha Descripción Autor

2.0 20/04/2015 Se replantean globalmente todos los ejercicios y se cambia Judith Meles
el ejercicio de telecentro por el de Lavado de Vehículos y el Florencia Bene
de Venta de CD por el de Taller de Autos. Candelaria Fey
Se quitan las historias de cambio de cada caso de uso para
manejarlas desde un sólo lugar.
2.1 18/04/2016 Se reemplazan algunos ejercicios, se mejora la redacción y Judith Meles
el formato, se agregan las reglas de negocio. Giuliana Belli
2.2 29/04/2016 Video Club: se agregan datos de socio al CU. Se quita la Cecilia Massano
consulta por elenco y se agrega patrón 15.
Secretaría de turismo: Se quitan CU de soporte y sesión de
la vista de CU. Se agrega el concepto del tipo de habitación
en el enunciado, se realizan correcciones de redacción y se
agregan RN de reserva.
Se indican los flujos básicos de trazos medios.
Se quitan precondiciones de trazo grueso.
Se corrige diagrama de clases de Editorial agregando la
impresión.
2.3 29/04/2016 Se corrige el diagrama de clases del Control de Accesos del Judith Meles
Country
2.4 10/04/2017 Se corrige consistencia de plantilla de trazo medio y grueso Judith Meles
Universidad Tecnológica Nacional- FRC /FRVM
Guía de Ejercicios Prácticos Complementarios sobre Diseño de

Arquitectura de Software
Consignas de Trabajo para los EPC:

1. Identificar los requerimientos no funcionales y analizar su significancia para la arquitectura.
2. Identificar los patrones arquitectónicos relevantes y construir una representación gráfica de los mismos.
3. Construir las siguientes vistas arquitectónicas, definiendo para cada vista el punto de vista asociado:
a. Vista Arquitectónica de la funcionalidad.
b. Vista Arquitectónica de Diseño: Componentes e Interfaces.
c. Vista Arquitectónica del Despliegue: Hardware
d. Vista Arquitectónica del Despliegue: Distribución de software en hardware.
2023 DSI Guía de EPC sobre Diseño de Arquitectura de Software.docx – Versión 1.2
Página 1 de 30
Dominio: Bus turístico

El servicio de bus turístico de Buenos Aires permite el recorrido de los barrios más emblemáticos de la ciudad. Su
recorrido comienza en el corazón del centro porteño, a pocos metros de Plaza de Mayo, con vistas panorámicas que
permiten apreciar lugares históricos, espacios culturales y barrios únicos.
Los buses pasan cada 20 o 30 minutos, dependiendo el recorrido. El servicio trabaja con el formato Hop On/Hop Off.
La empresa ha requerido un sistema web y mobile para que le permita gestionar los viajes de los buses a través de los
distintos recorridos y la venta de tickets a los pasajeros.
Recorridos
La página web mostrará los recorridos con la siguiente información y en el siguiente formato
Cada recorrido posee una duración aproximada en la que el bus realiza el circuito completo. Las paradas del recorrido
respetan el orden establecido y pueden ser compartidas entre distintos recorridos, en distinto orden.
La hora de inicio define la hora de salida del primer bus de la primera parada del recorrido, mientras que la hora de
finalización establece el horario de llegada aproximado del último bus a la última parada del recorrido.
Al seleccionar una parada de un recorrido, la página web presentará información general, una foto representativa y los
atractivos cercanos que el turista podrá visitar.
Los atractivos cercanos buscan que el turista posea información de sitios que puede visitar luego de una caminata corta
desde la parada en cuestión. Al seleccionar algún atractivo, se mostrará su nombre y calificación (en estrellas). Distintas
paradas pueden contar con los mismos atractivos cercanos.
Buses
La empresa cuenta con una flota de buses que realizan los recorridos. Los buses se registrarán en el sistema
para poder asociarlos los viajes que realizan.
Los buses estarán equipados con dos dispositivos móviles, que serán utilizados por el guía y el chofer. Estos dispositivos
contarán con un módulo del sistema instalado y con conectividad 4G/LTE, lo cual permitirá brindar distinta información
en tiempo real. La aplicación será compatible con sistemas Android 5.5 o superior.
Página 2 de 30
Viajes
Un viaje es la ejecución de un recorrido por un bus, conducido por un chofer y acompañado por un guía, en una fecha
determinada. Semanalmente el Encargado de Operaciones de la empresa define el bus, el chofer y guía, y el horario de
inicio programado para cada viaje.
Son los choferes quienes indicarán -a través de una aplicación móvil instalada en uno de los dispositivos existentes en el
bus- el inicio y el fin de cada viaje. El inicio del viaje se produce cuando el bus se encuentra en la primera parada del
recorrido, el fin del viaje resulta cuando el bus arriba a la última parada.
Diariamente el Gerente de Operaciones genera un reporte sobre los viajes que incluye la duración en minutos, la
demora de inicio del viaje respecto a la hora programada, y el promedio diario de ambos valores.
Tickets
Los tickets se podrán adquirir:
1. En las boleterías existentes en distintos puntos de la ciudad. El vendedor utilizará el sitio web, y la venta podrá
realizarse en efectivo o con alguna de las tarjetas de débito o crédito aceptadas (Visa, American Express o
Mastercard). Para las operatorias de débito o crédito, la autorización se obtendrá utilizando el servicio provisto por
una terminal POSNet, la cual trabajará con tecnología web.
2. A través de la página web. En este caso, sólo se acepta pago con tarjeta de crédito. Para soportar esta operatoria
el sistema deberá conectarse con el WebService de BTPagos.
Una vez registrado el pago, cualquiera sea la forma, se generan los tickets, en papel para el caso de boletería o digitales
para venta web. En cualquier caso, se envía un email al cliente con los tickets generados. Cada ticket contará con un
número único y un código QR, que será requerido al subir al bus.
Los precios vigentes para cada tipo de ticket se presentan en la siguiente tabla
Ascenso y descenso de pasajeros

Al subir al bus, los pasajeros deberán escanear su ticket en papel o digital en el lector de código QR, el cual estará
conectado al dispositivo móvil asignado al guía. Este dispositivo utilizará tecnología web para enviar la información del
ascenso. De esta manera el guía visualizará los datos del ticket, podrá validar su vigencia y determinar la ocupación del
bus (aspecto crítico debido a que no se permite que pasajeros viajen de pie en ningún momento). La información de
cada lectura deberá enviarse al servidor en un tiempo no mayor a 3 segundos.
Página 3 de 30
Por otra parte, al descender del bus los pasajeros deberán repetir la operatoria de escanear su ticket, actualizando de
esta manera la información de la ocupación del bus.
Seguimiento online
El sitio web contará con una página para visualizar la localización de los buses en los distintos recorridos y el nivel de
ocupación de estos. Para ello el dispositivo móvil asignado al chofer contará con GPS integrado, lo que permitirá enviar
información en tiempo real, que será reflejada en la página utilizando el web service de Google Maps. Este mapa
mostrará los recorridos con su color; la ocupación de los buses se visualiza al seleccionar un bus en particular.
Administración
El sistema contará con un módulo de administración, que permitirá contar con información unificada referida
a los recorridos y paradas, viajes, ocupación de los buses y ventas de tickets. Este mismo módulo permitirá la
gestión de los recorridos, buses y personal, los tipos y precios de tickets.
Gestión de usuarios
El módulo de gestión de usuarios permitirá asignar un usuario y contraseña a los distintos interesados. Se
deberá, además, gestionar permisos en función del rol del usuario.
Estadísticas e informes
El módulo de estadísticas e informes proveerá información acerca de los viajes realizados, ocupación de los buses,
ventas realizadas por diferentes medios y formas de cobro, entre otros.
Página 4 de 30
Funcionalidad – Casos de Uso

Se presenta a continuación un listado de algunos casos de uso identificados con el actor correspondiente con una breve
descripción de su propósito u objetivo.
Caso de uso Objetivo o Breve Descripción Actor

1. Registrar recorrido Registrar un recorrido con sus paradas. Coordinador de Servicios
2. Modificar recorrido Modificar datos permitidos de un recorrido. Coordinador de Servicios
3. Consultar recorrido Consultar los recorridos existentes. Coordinador de Servicios
4. Registrar baja de recorrido Registrar la baja de un recorrido. Coordinador de Servicios
5. Registrar parada Registrar una parada con sus atractivos cercanos. Coordinador de Servicios
6. Modificar parada Modificar datos permitidos de una parada. Coordinador de Servicios
7. Consultar parada Consultar las paradas existentes. Coordinador de Servicios
8. Registrar baja de parada Registrar la baja de una parada. Coordinador de Servicios
Registrar un atractivo que pueda ser visitado desde
9. Registrar atractivo Coordinador de Servicios
una parada.
10. Modificar atractivo Modificar datos permitidos de un atractivo. Coordinador de Servicios
11. Consultar atractivo Consultar los atractivos registrados. Coordinador de Servicios
12. Registrar baja de atractivo Registrar la baja de un atractivo. Coordinador de Servicios
13. Registrar chofer Registrar un chofer con sus datos personales. Encargado de Personal
14. Modificar chofer Modificar datos personales permitidos de un chofer. Encargado de Personal
15. Consultar chofer Consultar los datos de los choferes. Encargado de Personal
16. Registrar baja de chofer Registrar la baja de un chofer. Encargado de Personal
17. Registrar guía Registrar un guía con sus datos personales. Encargado de Personal
18. Modificar guía Modificar los datos personales permitidos de un guía. Encargado de Personal
19. Consultar guía Consultar los datos de los guías. Encargado de Personal
20. Registrar baja de guía Registrar la baja de un guía. Encargado de Personal
21. Registrar bus Registrar un bus turístico. Coordinador de Servicios
22. Modificar bus Modificar datos permitidos de un bus. Coordinador de Servicios
23. Consultar bus Consultar los buses registrados. Coordinador de Servicios
24. Registrar baja de bus Registrar la baja de un bus. Coordinador de Servicios
25. Registrar tipo de ticket Registrar un tipo de ticket. Responsable de Ventas
26. Modificar tipo de ticket Modificar datos de un tipo de ticket. Responsable de Ventas
27. Consultar tipo de ticket Consultar los tipos de ticket registrados. Responsable de Ventas
28. Registrar baja de tipo de
Registrar la baja de un tipo de ticket. Responsable de Ventas
ticket
29. Registrar precio de ticket Registrar un precio para un tipo de ticket. Responsable de Ventas
Registrar un viaje de un bus por un recorrido, en una
30. Registrar viaje Coordinador de Servicios
fecha/hora, con la asignación del chofer y el guía.
31. Modificar viaje Modificar datos permitidos de un viaje no iniciado. Coordinador de Servicios
32. Consultar viaje Consultar los viajes registrados. Coordinador de Servicios
Registrar el inicio de un viaje por un bus en un
33. Registrar inicio de viaje Chofer
recorrido, en una fecha/hora.
34. Registrar fin de viaje Registrar el fin de la ejecución de un viaje. Chofer
Registrar la venta en boletería de uno o más tickets, Vendedor
35. Registrar venta de tickets
según tipo de ticket, en efectivo o con tarjeta Autorizador PosNet
en boletería
(solicitando la autorización usando un POSNet). (secundario)
Página 5 de 30
Caso de uso Objetivo o Breve Descripción Actor

Enviar uno o más tickets al cliente que los adquirió a la Gestor de Envío de Emails
36. Enviar entradas por email
dirección de email informado. (secundario)
37. Registrar venta de tickets Registrar la venta web y el cobro realizado por Interesado
web BTPagos, por uno o más tickets, según tipo de ticket. BTPagos (secundario)
Registrar el ascenso de un pasajero a un bus en un
38. Registrar ascenso de determinado viaje; permitiendo al guía visualizar los Pasajero
pasajero datos del ticket, validar su vigencia y también Guía (secundario)
determinar la ocupación del bus.
39. Registrar descenso de
Registrar el descenso de un pasajero de un bus. Pasajero
pasajero
40. Consultar localización de Presentar información sobre la geolocalización de los
Interesado
buses buses que se encuentran realizando viajes.
Consultar los viajes en curso, con información de
41. Consultar viajes en curso Coordinador de Servicios
ocupación.
Consultar información sobre los volúmenes de venta
42. Consultar venta de tickets Responsable de Ventas
de tickets por diferentes medios.
Brindar información sobre los recorridos vigentes en la
43. Consultar recorridos web Interesado
página web de la empresa.
Generar un reporte sobre los viajes que incluye la
duración en minutos, la demora de inicio del viaje
44. Generar reporte de viajes Coordinador de Servicios
respecto a la hora programada, y el promedio diario de
ambos valores
Generar un reporte sobre las ventas de tickets en un
45. Generar reporte de ventas período, discriminando tipo de ticket, medio de venta Responsable de Ventas
y forma de cobro.
Iniciar una sesión del sistema con la validación del
46. Iniciar sesión Usuario
usuario correspondiente.
47. Cerrar sesión Cerrar la sesión del usuario. Usuario
Página 6 de 30
En el siguiente cuadro se presentan los requerimientos no funcionales del dominio.
SPA: Significativo para la arquitectura
Característica
N° Nombre Descripción SPA Justificación
ISO 25000
El lenguaje de programación a utilizar

debe ser Web. Aplicando el patrón
La aplicación será
Layered se realiza la separación en capas
desarrollada con tecnología
que permite independizar el desarrollo
Web, a excepción de la
Arquitectura web requerido a la capa de interfaz de
1 funcionalidad de registro de Compatibilidad SI
Web usuario. El patrón cliente-servidor N-Tier
ejecución de viaje y
se aplica para distribuir
ascenso/descenso de
independientemente esta capa web en
pasajeros del bus.
los niveles de cliente y servidores que
sean requeridos.
Los buses estarán

La aplicación debe desarrollarse para
equipados con dos
ejecutarse sobre dispositivos móviles,
Dispositivos dispositivos móviles, que
2 Compatibilidad SI por lo que debe desarrollarse con un
móviles contarán con un módulo del
lenguaje de programación que soporte
sistema instalado y
desarrollo mobile.
conectividad 4G/LTE.
El desarrollo debe contemplar las

La aplicación debe ser
Sistema restricciones y facilidades de las
desarrollada para los
3 Operativo Compatibilidad SI versiones requeridas del sistema
sistemas operativos Android
Mobile Android sobre el cual correrá la
5.5 o superior.
aplicación.
Desarrollar un componente que provea

La venta de tickets en la interfaz con el servicio suministrado
boletería con tarjeta por POSNet y maneje el protocolo
Cobro en requiere comunicación vía correspondiente, utilizando tecnología
4 Compatibilidad SI web.
boletería PosNet para autorizar las
transacciones Establecer una interfaz de hardware con
correspondientes. el dispositivo provisto por la empresa
POSNet.
El sistema debe
Desarrollar un componente que
comunicarse con el Web
Comunicación consuma el Web Service publicado por
5 Service de BTPagos para la Compatibilidad SI
con BTPagos BTPagos, para la obtención de la
gestión de los cobros a
información del cobro de los tickets.
través de la página web.
Página 7 de 30
Característica
N° Nombre Descripción SPA Justificación
ISO 25000
Los tickets generados serán

enviados por email a los
clientes a través de la Construcción de un componente que
Envío de email solución de gestión de mails permita la generación y comunicación
6 Compatibilidad SI
de notificación adquirida a Google, con la solución de envío de mails a
mediante una API específica través de la API de Gmail.
para el lenguaje de
programación .NET.
La lectura del código QR del

La lectura de un código QR se resuelve
ticket, en el ascenso y
con un intérprete resuelto en el lenguaje
Lector de descenso del pasajero, debe
7 Compatibilidad NO de programación web, por lo que no se
código QR ser procesada para validar
requiere ningún desarrollo particular
la vigencia y determinar la
para resolverlo.
ocupación del bus.
La información de cada Implica el desarrollo de algoritmos

Tiempo
ascenso o descenso deberá eficientes de comunicación entre el
máximo de Eficiencia de
8 enviarse al servidor en un SI lector QR y el servidor web que
actualización desempeño
tiempo no mayor a 3 permitan cumplir con la performance
de lectura
segundos. requerida.
El dispositivo móvil
asignado al chofer contará Debe desarrollarse una interface que
con GPS integrado, lo que resuelva la comunicación con el por el
Dispositivo
permitirá enviar dispositivo localizador, interprete las
9 localizador en Compatibilidad SI
información en tiempo real coordenadas y sea responsable del
buses
sobre la ubicación del bus, procesamiento de la información
para realizar el seguimiento enviada.
geo-satelital de éstos.
El sistema web deberá

comunicarse con Google Se debe generar un módulo para
Seguimiento Maps para resolver la comunicarse con el web service de
10 Compatibilidad SI
online funcionalidad de Google Maps para posicionar las
visualización de la ubicación coordenadas en un mapa.
de los buses.
Página 8 de 30
Caso de Estudio: Publicidad Multipunto

Descripción del Dominio
Una empresa que opera en la ciudad de Córdoba se dedica a la comercialización de publicidad Multi-Punto. Es decir, posee
en diferentes ubicaciones del país puntos de emisión, que son pantallas con conexión a internet que reproducen tandas
publicitarias.
Con el fin de simplificar el dominio planteado, asumimos que en una ubicación geográfica particular (local comercial,
gimnasio, farmacia, etc.) solo puede haber un único punto de emisión. Se necesita conocer la dirección, razón social, nombre,
teléfono de la persona de contacto y rubro asociado al lugar en donde se encuentra instalado el punto de emisión.
La empresa necesita un software construido con tecnología web que permita la gestión de la programación y reproducción
de las publicidades en los diferentes puntos de emisión y la gestión del cobro del servicio de publicación.
Para la implementación de este software la empresa posee un sólo equipo (hardware) que será utilizado como servidor, con
Ubuntu Linux Server 12.04 LTS open source.
Los puntos de emisión deben tener un nombre, una descripción y un precio por segundo de publicidad. Los clientes que
deseen publicar en los puntos de emisión de la empresa deben contratar un servicio de publicación, donde se acuerda la
cantidad de veces que será reproducida una publicidad durante un periodo definido de tiempo, para un punto de emisión
determinado. El servicio contratado puede ser de tipo periódico o por única vez. Si el cliente acepta el precio del servicio, el
administrador le asignará un usuario con el cual operar el sistema. Entre otras cosas el cliente como usuario, podrá subir
sus publicidades. Las publicidades deben tener nombre, descripción, código autogenerado que la identifique, duración y la
fecha de creación. Los formatos de publicidad permitidos son .flv (Flash Video), .AVI o .MPG.
El administrador es el responsable de crear las tandas publicitarias, para lo cual agrupará las publicidades cargadas por los
clientes según algún criterio (rubro, público dirigido, marca; y teniendo en cuenta el punto de emisión donde se reproducirá).
En cada tanda publicitaria se debe indicar el orden de reproducción para cada publicidad. De esta manera las publicidades
serán reproducidas secuencialmente según el orden indicado en la tanda publicitaria.
Una vez creadas las tandas publicitarias, el administrador periódicamente se encargará de generar las programaciones de
las tandas publicitarias para cada punto de emisión. En cada programación indica la fecha Inicio, fecha de fin, el conjunto de
tandas publicitarias, el orden en que éstas se reproducirán, un nombre descriptivo de la programación y una fecha de
creación. Cabe aclarar que las diferentes programaciones de un punto de emisión no pueden superponerse, es decir un
punto de emisión en un momento de tiempo sólo tiene una programación vigente. Aun así, es posible generar varias
programaciones para un mismo punto de emisión respetando esta restricción.
Cada punto de emisión debe tener instalado un módulo que resuelva la forma de comunicarse con la aplicación central para
descargar actualizaciones de las programaciones y otro módulo que se encargue de reproducirlas en la secuencia indicada
por la programación asignada al punto de emisión. La conexión a internet que utilice el punto de emisión debe ser banda
ancha de al menos 3Mbps.
Una vez instalado el punto de emisión en el local donde se ubicará, se le da de alta en el sistema como habilitado para poder
asignarle programaciones. A partir de esto, si el punto de emisión posee internet deberá conectarse al servidor y descargar
las programaciones que debe emitir. Si por algún motivo no posee conexión a internet, deberá verificar el estado de esta
cada 5 minutos. Una vez completa la descarga, el punto de emisión comenzará a reproducir secuencialmente las
publicidades.
Página 9 de 30
Cada hora, al mismo tiempo que en pantalla del punto de emisión se reproducen las publicidades, el software del dispositivo
debe sincronizarse con el servidor central para descargar actualizaciones en el caso de que existan. El momento de
sincronización puede durar varios minutos. También puede ocurrir que, al intentar la sincronización, el punto de emisión no
pueda conectarse al servidor por problemas en la conexión, en este caso mientras continúa reproduciendo la programación
actual, verificará cada 5 minutos el estado de la conexión para poder iniciar la sincronización.
Puede suceder que el punto de emisión sea apagado cuando termine el día o cuando el dueño del local lo decida. Cuando
se encienda, deberá reproducir la última programación que tenía descargada. Es posible deshabilitar un punto de emisión
durante un período de tiempo, por ejemplo, si está roto o si el local donde se ubica el punto de emisión entra en periodo
vacacional. Mientras el punto de emisión se encuentre deshabilitado no se le podrá asignar programaciones. Una vez que se
lo habilite, deberá conectarse para descargar la nueva programación, siempre y cuando el administrador le haya asignado
una programación. Existen casos en los cuales se le debe dar la baja al punto de emisión y dejarlo en desuso, esto ocurre
cuando el local donde está ubicado se cierra, decide quitar el punto de emisión, o no se rompe el dispositivo y no se puede
reparar.
Para que un cliente se asegure que sus publicidades se reproduzcan en los puntos de emisión es necesario generar un reporte
que contenga la hora de inicio de reproducción, el nombre de la publicidad y el id del punto de emisión que la reprodujo,
para esto, cada punto de emisión debe enviar al servidor una notificación al reproducir una publicidad. El servidor recibirá
todas las notificaciones de cada punto de emisión y las ordenará según el orden de llegada y el punto de emisión. El formato
del reporte tiene que ser Excel (xls o xlsx) o pdf.
El sistema además debe gestionar los pagos de los clientes, que pueden ser abonados en efectivo o a través de los medios
de pago permitidos por Cuenta Digital. Si el pago es en efectivo, el área de administración se encarga de generar el
comprobante de pago y registrar el cobro. En los demás casos se utiliza el web service de CuentaDigital. Cuenta Digital es un
sitio web que permite tercerizar las operaciones de cobro de servicios y productos ofreciendo múltiples medios de pagos a
los clientes, automatizando el proceso de cobro. Para utilizar este servicio, es necesario contar con una interfaz que se pueda
comunicar con el web service de cuenta digital, con el fin de permitir la generación de cupones de pago con un código de
barras para utilizar en cualquiera de los medios permitidos por CuentaDigital y actualizar el estado de los pagos una vez que
se registre el mismo en Cuenta Digital.
El administrador del sistema debe poder consultar en cada momento si un servicio contratado está pendiente de pago, si ya
se efectuó el pago o si se encuentra vencido. Además de poder visualizar los comprobantes de pago de los servicios
contratados para cada cliente.
El cliente tiene acceso a su estado de cuenta al igual que la administración. Cada vez que se consulte el estado de cuenta
para un determinado período el sistema mostrará un listado con todos los cupones de pago por cliente. Cuando un cupón
de pago se encuentra vencido se debe visualizar en color rojo para denotar el incumplimiento, si se efectuó el pago debe
figurar en color verde, y si aún no ha vencido en color negro.
Al ser un sistema web es necesario administrar los usuarios junto a sus permisos y mantener el control de la sesión, con un
time-out de 10 minutos. El protocolo de transmisión de información a utilizar para la plataforma web será HTTP, y HTTPS
según corresponda (en función de la sensibilidad de la información).
Para evitar costos de licenciamiento el cliente solicita que los lenguajes utilizados para el desarrollo del software sean Open
Source, y la base de datos que se utilizará para la persistencia debe ser My SQL Community Server 5.5.24, además debe ser
compatible con Explorer 7, Mozilla y Chrome 18.
Página 10 de 30
Ejemplo de una programación:
Punto de emisión: Gimnasio VitalFem
Programación Mujeres Otoño (19/04/16 al 20/05/16)

• 01. Corto Ossira Otoño
01. Tanda Ropa Femenina • 02. Wanama Nueva Temporada Abril
• 01. Botas Cuero 100% argentino

02.Tanda Batistella • 02. Zapatos Fiesta
• 03. Publicidad carteras y cintos 50 % descuento.
• 01. Makeup Dior tonalidades otoño 2013

03.Tanda Perfumeria • 02. Julieraque descuentos abril
Glosario
Término Significado
Punto de Monitor o pantalla LCD conectada a la red que puede reproducir videos e imágenes en un formato
Emisión especificado; con una ubicación geográfica conocida.
Publicidad Un archivo digital multimedia (video o imagen animada), susceptible de ser publicado en un punto de
emisión, que integra una tanda publicitaria.
Tanda Agrupación arbitraria de publicidades ordenadas que pueden asignarse a una o varias programaciones.
Publicitaria
Web service Servicio web: es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para
intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de
programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para
intercambiar datos en redes de ordenadores como Internet
Página 11 de 30
Definición del Producto

Objetivo
Gestionar la programación y reproducción de tandas publicitarias en diferentes puntos de emisión de Clientes, así como la
gestión y cobro de servicios de publicación. Obtener información resultante de la gestión.
Alcances
El sistema comprenderá el desarrollo de las siguientes áreas de funcionalidad:
❖ Administrar Clientes
❖ Administrar Usuarios y Permisos
❖ Administrar Puntos de Emisión
❖ Gestionar Programación por Punto de Emisión
❖ Gestionar Contenidos Multimedia
❖ Gestionar Pagos de los clientes
❖ Gestionar cuentas corrientes de los clientes
❖ Generar reportes relacionados con publicidades emitidas en los puntos de emisión
❖ Generar reportes del estado actual de los puntos de emisión
No contempla
❖ Gestión de la contratación de ubicaciones en Puntos de Emisión.
Reglas de negocio
Reglas de Negocio
En una ubicación geográfica particular (local comercial, gimnasio, farmacia, etc.) sólo
1 Puntos de emisión únicos
puede haber un único punto de emisión.
El período de programación no debe superponerse ni total ni parcialmente. Por ejemplo:

Validación Periodo
2 si la programación tiene definida una fecha de inicio 10/03/2016 y una fecha de fin
Programación
20/03/2016, se superpone con el período: 13/03/2016 hasta 22/03/2016.
3 Tipos de servicio El servicio contratado puede ser de tipo periódico o por única vez.
4 Programación vigente Un punto de emisión en un momento de tiempo sólo tiene una programación vigente.
Punto de emisión Mientras el punto de emisión se encuentre deshabilitado, no se le podrá asignar

5
deshabilitado programaciones.
Las formas de pago pueden ser en efectivo o a través de los medios de pago
6 Formas de pago
permitidos por Cuenta Digital.
Página 12 de 30
Listado de CU
Nº CU Nombre del Caso de Uso Objetivo
1 Registrar punto de emisión. Registrar los datos de un punto de emisión y su ubicación.
2 Modificar punto de emisión. Modificar los datos de un punto de emisión.
3 Consultar punto de emisión. Visualizar los datos de un punto de emisión.
Registrar Baja de punto de Dar de baja un punto emisión que no tenga asignada una programación.
4
emisión.
Registrar los datos de una ubicación en donde se instalará un punto de

5 Registrar Ubicación.
emisión con su localidad y provincia.
6 Modificar Ubicación. Modificar los datos permitidos de una ubicación.
7 Consultar Ubicación. Visualizar los datos de una ubicación.
Eliminar una ubicación cuando no esté siendo referenciada desde un

8 Eliminar Ubicación.
punto de emisión.
9 Cargar Publicidad. Cargar un archivo multimedia (video, foto, etc.).
10 Registrar Tanda Publicitaria. Registrar los datos de una tanda publicitaria y sus publicidades asociadas.
Modificar los datos permitidos de una tanda publicitaria y actualizar los

11 Actualizar Tanda Publicitaria.
Puntos de Emisión que la estén reproduciendo.
12 Consultar Tanda Publicitaria. Visualizar los datos de una tanda publicitaria.
Registrar la fecha de baja de una tanda publicitaria cuando no esté siendo

13 Anular Tanda Publicitaria.
utilizada en ninguna programación.
Generar Programación de Tandas Generar la programación de tandas publicitarias para un punto de

14
Publicitarias. emisión en base a los servicios contratados para un determinado periodo.
Modificar Programación de Modificar los datos permitidos de una programación.

15
Tandas Publicitarias.
Consultar Programación de Visualizar los datos de una programación.

16
Tandas Publicitarias.
Anular Programación de Tandas Anular una programación cuando no se encuentre asignada a un punto
17
Publicitarias. de emisión.
18 Registrar Estado. Registrar las características de un estado.
19 Modificar Estado. Modificar los datos permitidos de un estado.
20 Consultar Estado. Consultar información sobre uno o más estados registrados.
21 Eliminar Estado. Eliminar de un estado registrado.
Página 13 de 30
Registrar los datos de un cliente que podrá contratar un servicio de

22 Registrar Cliente.
publicación.
23 Modificar Cliente. Modificar los datos permitidos de un cliente.
24 Consultar Cliente. Visualizar los datos de un cliente.
Generar Orden de Pago en Generar un ticket de pago para cobrarse en efectivo en la administración.
25
Efectivo.
Generar Orden de Pago en Generar un ticket de pago para ser cobrado por cualquiera de los medios
26
CuentaDigital. permitidos por cuenta digital.
Registrar el cobro de una Orden de Pago por un cliente por medio del
27 Registrar Cobro.
pago directo en la empresa.
Registrar los datos de un servicio de publicación para un determinado

28 Registrar Servicio de Publicación.
cliente durante un periodo y para ciertos puntos de emisión.
29 Modificar Servicio de Publicación. Modificar los datos de un servicio.
30 Consultar Servicio de Publicación. Visualizar los datos de un servicio determinado.
31 Anular Servicio de Publicación. Anular un servicio de los existentes.
Habilitar el inicio de sesión de un usuario en el sistema, validando sus

32 Iniciar Sesión.
permisos.
Cerrar la sesión de un usuario en el sistema cuando el usuario así lo

33 Cerrar Sesión.
indique
Cerrar la sesión de un usuario por el paso del tiempo con el sistema

34 Caducar Sesión.
inactivo
35 Registrar Usuario. Registrar los datos de un usuario del sistema.
36 Modificar Usuario. Actualizar los datos de un usuario del sistema
37 Consultar Usuario. Visualizar los datos de un usuario del sistema
38 Eliminar Usuario. Eliminar los datos de un usuario del sistema
Actualizar Asignación de Permisos Registrar la actualización de los permisos asignados a cada usuario
39
a Usuario.
Notificar Reproducción de Enviar al servidor principal una notificación al comenzar a reproducir una
40
publicidad. publicidad en un punto de emisión.
Verificar periódicamente si el punto de emisión se encuentra en

Controlar Disponibilidad de Punto
41 reproducción y actualizar el estado actual del punto de emisión si no se
de Emisión.
encuentra disponible.
Página 14 de 30
Descargar una nueva programación desde un punto de emisión cuando

42 Actualizar Programación.
exista una programación más actual.
Reproducir las publicidades en el punto de emisión según el orden

43 Reproducir Programación. indicado en la programación actual descargada y el periodo de
reproducción de esa programación.
Generar Reporte de Estado de Generar un reporte que indique el estado actual de diferentes puntos de
44
Punto de Emisión. emisión.
Generar Reporte de Estado de Generar un listado de los pagos y su estado para un cliente determinado
45
cuenta de un cliente. en un periodo específico de tiempo.
Generar Reporte de Generar un listado de las notificaciones de reproducción hechas por los
46 Reproducción de publicidades en puntos de emisión para las publicidades de un determinado cliente.
punto de emisión.
Listar las publicidades cargadas Generar un listado de todas las publicidades con sus datos que han sido
47
por un cliente. cargadas en el sistema por un cliente en particular.
Establecer un punto de emisión como deshabilitado para la asignación de

48 Deshabilitar Punto de Emisión.
programaciones.
Establecer un punto de emisión como habilitado para la asignación de

49 Habilitar Punto de Emisión.
programaciones.
50 Eliminar Cliente Eliminar los datos de un cliente que no tenga servicios vigentes.
Procesar Cobros efectuados a Registrar la información de los cobros que se realizaron a través de
51
través de cuenta digital. cuenta digital.
Página 15 de 30
Caso de Estudio: App Mobile para Reclamos

Una empresa dedicada al desarrollo de software quiere construir un producto destinado a Municipios y Empresas de
Servicios Públicos que les permita recibir información organizada y en tiempo real de eventos reportados por sus clientes
(reclamos, trámites, quejas, denuncias y/o consultas, comunicaciones), gestionarlos y comunicar su resolución. De cara al
cliente brinda la posibilidad de generar eventos a todas las entidades adheridas y conocer en línea el estado de los mismos,
a través de una única aplicación, disponible en dispositivos móviles y a través de su versión web. A partir de la carga del
evento la organización a la que va dirigido lo gestiona y, una vez resuelto, el aplicativo comunica la solución y finalización al
cliente, quien también puede monitorear desde la aplicación el estado de sus eventos cargados.
La aplicación permitirá al cliente interactuar con las organizaciones adheridas enviando avisos de una manera muy simple:
Una vez descargada la aplicación, frente a un evento, el cliente podrá tomar una fotografía con su celular, geo-referenciar
1
el mismo, seleccionar el tipo de evento y describir el motivo de su reporte. Para aquellos que no posean un Smartphone, se
puede ingresar desde la PC a la versión web.
La solución se ofrecerá como servicio “Saas” (Software as a Service) y Tecnología Cloud (la nube). La empresa u organismo
público que contrata el producto recibirá información organizada y en tiempo real de los eventos que desea gestionar,
pudiendo configurar cuáles son los tipos de eventos que gestiona y que datos solicitarle al cliente para cada uno de ellos. A
su vez el sistema le permite configurar de manera simple y rápida el proceso interno de resolución por cada tipo de evento
y una vez resuelto, la aplicación se encargará de informar la resolución al cliente.
Cualquier organización pública o privada podrá acceder ya que no requiere inversión previa. Gracias a la tecnología Cloud (la
nube) tampoco demanda equipos especiales para su funcionamiento.
El aplicativo se integrará con redes sociales y contará con un módulo de notificaciones push a través del cual es posible enviar
mensajes masivos a la comunidad de usuarios o delimitados por zona según el objetivo de la comunicación, informando la
resolución de eventos o cualquier otro mensaje que se considere relevante para el público seleccionado.
El sistema deberá ser compatible con plataforma web HTML 5 y sistemas IOS (versión 8 o superior), Android (versión 6 o
superior), Windows Phone (versión 10). En la nube, la empresa que desarrolla el software utilizará servidores distintos para
la BD, la capa de Aplicaciones y la capa Web.
Luego de que uno de los socios de la consultora (que es quién tiene la idea de negocio) bajó estos lineamientos, al equipo
de trabajo le surgieron las siguientes preguntas:
¿Cómo carga un evento un cliente o usuario? Para comenzar a utilizarlo sólo es necesario descargar la aplicación y registrarse
como usuario, con una dirección de e-mail y una contraseña de al menos 6 caracteres. Para aquellos usuarios que no posean
Smartphone, existe la posibilidad de poder registrar los eventos ingresando al sitio web de la aplicación mediante una PC,
también a través de un usuario registrado. Si el cliente ya se registró como usuario y olvidó su contraseña, el sistema debe
permitirle recuperarla.
Página 16 de 30
Al instalar la aplicación, el usuario debe aceptar el acuerdo de usuario que define las condiciones del servicio y política de
privacidad, permitiendo al sistema acceder a su ubicación por medio del GPS, conocer su IP, gestionar el uso de WIFI e
intercambio de archivos (recibir y enviar datos). Un usuario puede darse de baja en cualquier momento que lo desee.
Frente a un evento, puede tomar una fotografía con su celular (opcional y no mayor a 3 Gb), georreferenciarla, seleccionar
un tipo de evento y describir el motivo del reporte, como se muestra a continuación:
Log in y carga de Captura de imagen

Georreferenciación Reporte del Evento
datos con una foto
Al momento de la carga de datos, el sistema solicitará ingresar primero la organización o entidad a la que se le desea enviar
el evento y a partir de allí se mostrará la pantalla de carga, en donde el Tipo de Evento será definido por cada organización,
pudiendo agregarse nuevos Tipos de eventos una vez que el aplicativo ya se encuentra en uso.
¿Cómo se entera la organización a la que va destinado el evento? Las organizaciones adheridas a esta comunidad accederán
a la aplicación en la nube, a través de un portal web que deberá funcionar en los navegadores web Internet Explorer Versión
11.0 y Google Chrome 52.
Los colaboradores del área de Atención de Incidencias de la organización a la que está destinado el evento recibirán una
notificación (por mail y un alerta visual y sonoro si están logueados en la aplicación) indicando que se ha generado un nuevo
evento. Desde el área de Atención de incidencias se revisa el evento, determina si corresponde una acción y si este es el caso
se asigna a un Resolutor; caso contrario se desestima indicando el motivo.
¿Cómo se gestiona la resolución del evento?

Los Resolutores que se encuentren en la vía pública contarán con un Smartphone en el cual instalarán una aplicación (distinta
a la de los clientes) a través de la cual podrán recibir los eventos que les son asignados. El Resolutor recibirá una notificación
sonora y podrá visualizar el evento en la pantalla, con información detallada para acudir a la dirección desde donde se reporta
el mismo. Es importante destacar que los eventos estarán geo-referenciados, por lo cual el Resolutor tendrá la ubicación
precisa del reclamo. Una vez en el lugar registrará el trabajo realizado mediante evidencias digitales como fotos y videos,
que servirán para respaldar la resolución del evento. Finalizada la tarea del resolutor, la aplicación notificará al área de
Atención de Incidencias, para que el personal valide los trabajos cargados y proceda registrar el cierre del evento. Al cerrar
Página 17 de 30
el evento, el sistema enviará automáticamente un e-mail informando la resolución al cliente que generó el evento y enviará
una notificación a su Smartphone.
Esquema simplificado de la gestión del evento
Los colaboradores del Área de Atención de Incidencias podrán visualizar los eventos a través del mapa de reclamos. Allí
podrán visualizarse todos los eventos georreferenciados, los cuales pueden filtrarse por diferentes criterios como: fecha,
estado, tipo de evento, área geográfica específica. La ubicación del evento se visualizará a través de Google Maps, tal como
se muestra a continuación:
¿La organización puede emitir notificaciones acerca de un evento de manera “proactiva”? El aplicativo permitirá comunicar
a grupos de clientes sobre el estado o resolución de un evento generado desde la organización, como se muestra a
continuación:
Página 18 de 30
El sistema permitirá dibujar zonas dentro del mapa, agrupando reclamos a partir de una lógica determinada y enviar
notificaciones push a los dispositivos móviles de los clientes. También existirá la posibilidad de publicar información sobre
los eventos gestionados en las redes sociales (Facebook y Twitter).
Otra de las alternativas es que el mismo cliente realice el seguimiento de los eventos reportados, pudiendo realizar filtros
por organización a la que van dirigidos, por número de evento o por estado.
El aplicativo podrá adaptarse a la imagen corporativa de cada organización (logo y colores).
Glosario:
Geolocalización: La georreferenciación es la técnica de posicionamiento espacial de una entidad en una localización

geográfica única y bien definida en un sistema de coordenadas y datum específicos.
Saas (Software como un Servicio): es un modelo de distribución de software donde el soporte lógico y los datos que maneja
se alojan en servidores de una compañía de tecnologías de información y comunicación (TIC), a los que se accede
vía Internet desde un cliente. La empresa proveedora TIC se ocupa del servicio de mantenimiento, de la operación diaria y
del soporte del software usado por el cliente. Regularmente el software puede ser consultado en cualquier computador, se
encuentre presente en la empresa o no. Se deduce que la información, el procesamiento, los insumos, y los resultados de
la lógica de negocio del software, están hospedados en la compañía de TIC.
Tecnología Cloud: es tipo de implementación donde se ofrece servicio de procesamiento y almacenamiento, en servidores
alojados en forma remota, a los que se accede través de una red, que usualmente es Internet.
Notificaciones push: La tecnología Push es una forma de comunicación en la que una aplicación servidora envía un mensaje
a un cliente-consumidor. Es decir, es un mensaje que un servidor envía a una persona alertándolo de que tiene una
información nueva. Lo que caracteriza esta tecnología es que es siempre el servidor el que inicia esta comunicación, aunque
el cliente no tenga interés en saber si hay algo nuevo. Lo comunica siempre.
Página 19 de 30
Lo que más destaca de las notificaciones push es su inmediatez, ya que no hace falta estar ejecutando la aplicación para que
nos llegue. Aunque la tengamos apagada o en segundo plano, cada vez que el servidor reciba una información nueva nos
avisará de su existencia, es decir, las notificaciones push despiertan al móvil esté o no ejecutando la aplicación.
Listado de casos de Uso

Nro. Paquete Nombre del Caso de Uso Objetivo
1 Seguimiento Registrar evento Registrar los datos de un evento por parte de un cliente de
Móvil de Eventos una organización adherida al servicio.
2 Seguimiento Modificar evento Modificar los datos permitidos de un evento por parte de
Móvil de Eventos un cliente de una organización adherida al servicio.
3 Seguimiento Consultar evento Consultar los datos de un evento por parte de un cliente de
Móvil de Eventos una organización adherida al servicio.
4 Seguimiento Eliminar evento Eliminar un evento por parte del cliente que lo solicitó
Móvil de Eventos siempre que aún no haya sido asignado para su resolución.
5 Administración de Registrar usuario móvil Registrar un usuario del sistema para hacer uso del
usuarios móviles aplicativo móvil
6 Administración de Modificar usuario móvil Modificar los datos permitidos de un usuario del sistema
usuarios móviles que hace uso del aplicativo móvil
7 Administración de Consultar usuario móvil Consultar los datos de un usuario del sistema que hace uso
usuarios móviles del aplicativo móvil
8 Administración de Eliminar usuario móvil Dar de baja un usuario del sistema que hace uso del
usuarios móviles aplicativo móvil
9 Administración de Asignar perfil usuario Asignar datos del perfil al usuario móvil
usuarios móviles móvil
10 Administración de Recuperar contraseña Informar a un usuario móvil su contraseña.
usuarios móviles
11 Gestión de Registrar organización Registrar los datos de una organización adherida al
organizaciones servicio.
adheridas
12 Gestión de Modificar organización Modificar los datos permitidos de una organización
organizaciones adherida al servicio.
adheridas
13 Gestión de Consultar organización Consultar los datos de una organización adherida al
organizaciones servicio.
adheridas
14 Gestión de Eliminar organización Dar de baja una organización que no desea estar más
organizaciones adherida al servicio.
adheridas
15 Gestión de Registrar tipo de evento Registrar un tipo de evento para una determinada
organizaciones organización, indicando los datos que se solicitarán al
adheridas cliente.
16 Gestión de Consultar tipo de evento Consultar los datos de un tipo de evento para una
organizaciones determinada organización.
adheridas
17 Gestión de Eliminar tipo de evento Dar de baja un tipo de evento para una organización.
organizaciones
adheridas
Página 20 de 30

18 Gestión de Modificar tipo de evento Modificar los datos permitidos de un tipo de evento para
organizaciones una organización
adheridas
19 Gestión de Registrar usuario web Registrar un usuario web para un colaborador de la
usuarios de la organización.
organización
20 Gestión de Modificar usuario web Modificar los datos permitidos de un usuario web.
usuarios de la
organización
21 Gestión de Consultar usuario web Visualizar los datos de un usuario web.
usuarios de la
organización
22 Gestión de Eliminar usuario web Dar de baja un usuario web
usuarios de la
organización
23 Gestión de Registrar perfil Registrar un perfil de usuario organizacional.
usuarios de la
organización
24 Gestión de Modificar perfil Modificar los datos permitidos de un perfil de usuario
usuarios de la organizacional.
organización
25 Gestión de Consultar perfil Visualizar los datos de un perfil de usuario organizacional.
usuarios de la
organización
26 Gestión de Eliminar perfil Dar de baja un perfil de usuario organizacional.
usuarios de la
organización
27 Gestión de Asignar perfiles a usuario Registrar la asignación de uno o más perfiles a un usuario
usuarios de la organizacional de la organización.
organización
28 Gestión de Iniciar sesión Iniciar una sesión de trabajo en el sistema ingresando un
usuarios de la nombre de usuario y una contraseña y validando los
organización permisos para ese usuario.
29 Gestión de Cerrar sesión Cerrar una sesión de trabajo en el sistema cuando el
usuario de la usuario así lo requiera
organización
30 Gestión de Caducar sesión Cerrar una sesión de trabajo porque ha transcurrido el
usuario de la tiempo definido de inactividad
organización
31 Gestión de Visualizar mapa de Visualizar en el mapa eventos generados para la
eventos eventos organización, aplicando filtros de estado, fechas, tipos de
eventos y ubicación.
32 Gestión de Asignar resolutor a Asignar un evento en estado Pendiente de Asignación a un
eventos evento Resolutor de la organización.
33 Gestión de Desestimar evento Desestimar un evento al que no le corresponden acciones
eventos para su resolución, informando el motivo.
Página 21 de 30

34 Gestión de Registrar trabajo realizado Registrar el trabajo realizado para resolver un evento por
eventos parte del Resolutor, adjuntando fotos y/o videos si así se
requiere.
35 Gestión de Registrar cierre de evento Registrar el cierre de un evento resuelto, con la opción de
eventos publicarlo en redes sociales.
36 Seguimiento móvil Realizar seguimiento de Consultar los datos de un evento, los trabajos realizados y
de eventos evento la fecha y hora de cada acción.
38 Gestión de Enviar notificaciones a Enviar notificaciones a los dispositivos móviles de grupos
eventos clientes en forma masiva de clientes sobre un evento generado desde la
organización.
39 Gestión de Enviar notificación a Enviar notificación al dispositivo móvil de un cliente sobre
eventos cliente acerca de la el estado o resolución de un evento.
resolución de un evento
40 Gestión de Enviar notificación a Enviar notificación a los colaboradores de la organización
eventos colaborador ante evento ante un evento nuevo generado por el cliente.
nuevo
41 Gestión de Enviar notificación a Enviar notificación al dispositivo móvil de un cliente sobre
eventos resolutor el estado o resolución de un evento.
42 Gestión de Configurar imagen de Configurar logo y colores del aplicativo para la
organizaciones aplicativo para organización.
adheridas organización
43 Gestión de Generar evento masivo Crear un evento masivo desde la organización que se
eventos comunicará luego a un grupo de clientes.
44 Gestión de Anular evento masivo Registrar anulación de un evento masivo desde la
eventos organización.
Nota: El listado de casos de uso no es exhaustivo, se incluye a los fines de una mejor comprensión de la funcionalidad del
producto.
Página 22 de 30
A continuación, se describen en términos generales las responsabilidades de los roles de usuario que se vincularán con el
software:
Cliente Administrador de Colaborador de Área de

Resolutor
Persona que va a utilizar la Aplicación Reclamos Atención de Incidentes
Está familiarizado con el uso de
aplicación para registrar un Persona de la consultora que (Colaborador AAI) Smartphone.
evento. va a configurar y personalizar Colaborador de la
el aplicativo para cada una de organización que va a Debe utilizar la aplicación (distinta
Está familiarizado con el uso de la del cliente) mientras está
las organizaciones adheridas. gestionar los eventos
de Smartphone y puede trabajando en la vía pública, por
instalar la aplicación. Debe estar familiarizado con reportados por los clientes,
utilizando la versión web de la eso necesita recibir los eventos que
el uso de aplicaciones WEB.
Su expectativa es que la aplicación. se le asignan con notificaciones
organización responsable sonoras.
resuelva el evento lo antes Debe interactuar con el
sistema para asignar los Necesita visualizar la geo posición
posible y lo mantenga del evento para poder localizarlo y
informado. eventos a los resolutores y
validar los trabajos realizados necesita minimizar la cantidad de
para dar cierre al evento. interacciones con el celular al
momento de registrar los trabajos
También generará eventos realizados.
masivos y los notificará a un
grupo de clientes.
Debe estar familiarizado con
el uso de aplicaciones WEB.
Página 23 de 30
Caso de Estudio: App Fanáticos de Fútbol (APP FF)

Aplicación Oficial para un Club de Fútbol: Aplicación Fanáticos del Fútbol (APP FF)
Un importante club desea contar con una plataforma de comunicación que le permita aumentar el número de socios y
acercar sus socios/hinchas a la institución.
Los principales roles de usuario para la aplicación se muestran a continuación:
Hincha Usuario de App FF (Fanáticos del Fútbol)

Rol de Usuario que quiere utilizar la aplicación desde su Socio y/o Hincha del Club que descarga la aplicación para
Smartphone para asociarse al Club, para lo cual deberá acceder a las noticias y beneficios que está la brinda, desde su
subir documentación personal y eventualmente pagar Smartphone.
su solicitud de adhesión. Si está asociado al Club podrá acceder a mayores beneficios en
También recibirá mails con información del estado de su los sorteos y a descuentos en comercios adheridos.
solicitud de adhesión y con el comprobante de cobro en
caso de que la solicitud de adhesión haya sido aprobada.
Página 24 de 30
Responsable de Socios
Administrador de Redes Sociales
Rol de Usuario responsable de la Administrador del Club (Community Manager)
evaluación de las Solicitudes de Rol de usuario responsable de Rol de usuario responsable de
Adhesión de los Hinchas que desean administrar los campeonatos en los administrar los beneficios que el club
convertirse en socios. También de la que el Club va a participar, como así ofrece a través de la aplicación y de
administración de los socios. también de los clubes con los que administrar los comercios adheridos en
jugará. los que obtienen beneficios dichos
Debe enviar las notificaciones con los usuarios y la administración de los
resultados de las evaluaciones y el sorteos.
comprobante de cobro para que el También será responsable de la
hincha pueda completar su trámite de publicación de las noticias del club y de
asociación al club. los eventos del minuto a minuto de los
partidos que esté jugando el club.
La intención es que el usuario de la aplicación Fanáticos del Fútbol (APP FF) pueda acceder a todas las noticias del club por
esa aplicación antes que por otros medios, seguir en vivo los eventos de los partidos y disfrutar de cientos de beneficios
exclusivos, como accesos a entrenamientos, sorteos de entradas preferenciales a partidos, fotos con el plantel, camisetas
firmadas por los ídolos, descuentos especiales en comercios adheridos, entre otros beneficios exclusivos, sólo disponibles
para quienes integren la comunidad virtual del club.
Los usuarios de la APP FF podrán visualizar un catálogo de beneficios de descuentos que el club ofrece. Estos beneficios
pueden ser 2x1 o un porcentaje de descuento en algún comercio con el cual el club tenga convenio. Por ejemplo: 20% o 30%
de descuento en indumentaria deportiva, o bien, 2x1 en entradas para un recital que se realiza en la cancha del club. Cabe
destacar que algunos beneficios son accesibles para todos los usuarios de la APP FF y otros únicamente para aquellos que
son socios del club, por consiguiente, es necesario que se indique en cada beneficio para quienes está dirigido, es decir si es
para cualquier usuario de la APP FF o sólo para los usuarios de la APP FF que además son socios.
Con esta herramienta de comunicación el usuario de la APP FF podrá seguir a su club desde su Smartphone en cualquier
lugar del mundo en el que se esté y vivir desde adentro toda la pasión por su Club y por el fútbol. También, podrá en la
misma aplicación, asociarse al club.
El hincha podrá asociarse al club completando un formulario de solicitud de adhesión al club, con una serie de datos y
adjuntando una foto carnet 4x4 y una fotocopia de su documento de identidad. El Responsable de Socios revisará los datos
proporcionados y las imágenes adjuntas. Si detecta alguna anomalía, rechazará la solicitud o la devolverá al usuario para
solicitarle que adjunte alguna información o corrija algún dato. El Responsable de Socios ha manifestado su necesidad de
Página 25 de 30
mantener información de cada cambio de estado realizado a la solicitud, y de notificarlo a los involucrados, que según sea
el caso serán el hincha y/o el Responsable de Socios.
Si todos los datos de la Solicitud son correctos, se generará un comprobante con el costo de asociación que el hincha, futuro
socio deberá pagar, para poder completar su trámite de asociación. El hincha tendrá 72hs para abonar el comprobante de
inscripción generado, por cualquiera de los medios habilitados.
Las modalidades de pago disponibles para los hinchas serán dos: una en línea (on line) (significa que puede pagar desde su
dispositivo) y la otra fuera de línea (off line) (significa que el pago se hace en una entidad que luego deriva la información
por algún medio al Club). Para el caso de cobro fuera de línea, diariamente las entidades que trabajan con esa modalidad
envían la información de los cobros realizados. Una vez transcurrido ese tiempo, si no se informó el cobro, el comprobante
de pago y la solicitud para asociarse quedan anuladas.
El responsable de la gestión de las noticias, los beneficios y los sorteos, es el Administrador de Redes Sociales (Community
Manager). También será responsable de la publicación de los eventos de cada partido (inicio/fin de primer/segundo tiempo,
goles, tarjetas amarillas/rojas, cambios, etc.) en tiempo real.
La administración de los campeonatos y clubes contra los que jugará el club, los diferentes partidos, será realizada por el
Administrador del Club.
El club ha informado que cuenta con un servidor que podrá utilizarse en forma dedicada para la base de datos y otro donde
se instalarán la capa de aplicación y la capa web.
Listado de Casos de uso
Este listado si bien no está completo, describe parte de la funcionalidad que será suficiente para comprender el alcance de
la aplicación.
Nro Nombre del Caso de Uso Objetivo Actor
Registrar los datos de un campeonato de fútbol en el que el Administrador del

1. Registrar campeonato
club va a participar. Club
Modificar los datos permitidos de un campeonato de fútbol Administrador del

2. Modificar campeonato
en el que el club va a participar. Club
Consultar los datos de uno o más campeonatos de fútbol en Administrador del

3. Consultar campeonato
los que el club participó o va a participar Club
Borrar los datos de un campeonato. Administrador del

4. Eliminar campeonato
Club
Publicar para los usuarios de APP FF noticias relacionadas al Administrador de

5. Publicar noticias
club y enviar notificaciones a sus dispositivos móviles. Redes Sociales
Mostrar la lista de noticias disponibles en un momento Administrador de

6. Visualizar lista de noticias
determinado. Redes Sociales
Página 26 de 30
7. Consultar noticias Consultar los detalles de una noticia publicada. Usuario APP FF
Registrar el inicio de una sesión en la aplicación por parte de Usuario

8. Iniciar sesión
un usuario registrado, validando su password y permisos.
9. Cerrar sesión Cerrar una sesión en la aplicación. Usuario
Registrar el cambio de palabra clave por parte de un usuario Usuario

10. Cambiar password
de la aplicación.
Registrar los datos de un club de fútbol contra el que Administrador del

11. Registrar club
nuestro club jugará en algún campeonato. Club
Modificar los datos permitidos de un club con el que va a Administrador del

12. Modificar club
competir nuestro club. Club
Consultar los datos de uno o más clubes registrados en la Administrador del

13. Consultar club
aplicación. Club
Borrar los datos de un club. Administrador del

14. Eliminar club
Club
Registrar el pedido de asociación de un hincha al club, Hincha

Registrar solicitud de
15. permitiendo adjuntar la documentación requerida (foto y
asociación a club
fotocopia del documento de identidad)
Validar los datos ingresados por un usuario para asociarse al Responsable de

Evaluar solicitud de club, registrando el resultado de la validación que puede ser Socios
16. asociación positiva.
Enviar emails al Hincha y/o al Responsable de Socios, ante Responsable de

un cambio de estado de la Solicitud de Adhesión. Socios
Notificar actualización de
17. solicitud Servidor de
Correo (Actor
Secundario)
Generar y enviar al socio el comprobante con el costo de Responsable de

asociación para ser pagado. Socios
Enviar comprobante de
18. inscripción Servidor de
Correo (Actor
Secundario)
Anular Solicitud de Controlar solicitudes cuyo cobro no se ha registrado y Tiempo

19. Asociación anular el comprobante de cobro y la solicitud de asociación.
Página 27 de 30
Diagramar fixture de Registrar cada uno de los partidos en los que el club jugará Administrador del
20. campeonato en un campeonato ya registrado en el sistema. Club
Registrar los datos de un sorteo que se realizará entre los Administrador de

21. Registrar Sorteo
usuarios de la APP FF que decidan inscribirse para participar. Redes Sociales
Modificar los datos permitidos de un sorteo que se Administrador de

22. Modificar Sorteo realizará, antes de llegada la fecha de sustanciación, es decir Redes Sociales
de hacer efectivo el sorteo.
Consultar los datos de uno o más sorteos según criterios Administrador de

23. Consultar Sorteo
predefinidos. Redes Sociales
Cancelar un sorteo para impedir su realización, debe ser Administrador de

24. Cancelar Sorteo
antes de la fecha de sustanciación. Redes Sociales
Registrar inscripción a Registrar la inscripción de un usuario de APP FF para que Usuario APP FF
25. sorteo pueda participar de un sorteo vigente.
Calcular ganadores de Obtener ganadores de un sorteo en particular, eligiendo de Tiempo

26. sorteo los usuarios de la APP FF que se inscribieron.
Importar en tiempo real la información de los sucesos de un Servidor Data

27. Importar minuto a minuto
partido jugado. Factory
Visualizar información de Visualizar los eventos importados relacionados a un partido Usuario APP FF
28. sucesos de un partido en el que el club está jugando en ese momento.
Registrar los datos de un beneficio que se ofrecerá a un Administrador de

usuario de la APP FF, ingresando las características del Redes Sociales
beneficio, el comercio adherido si aplica, si el beneficio es
29. Registrar beneficio para todos los usuarios de la APP FF o sólo para los socios
del club o si el beneficio es diferenciado, por ejemplo 10 %
para usuarios APP FF y 20 % para usuarios de la APP FF que
además son socios del club.
Modificar los datos permitidos de un beneficio que se Administrador de

30. Modificar beneficio
ofrecerá a un usuario de la APP FF. Redes Sociales
Consultar los datos de uno o más beneficios en función de Administrador de

31. Consultar Beneficio
criterios predeterminados. Redes Sociales
Anular un beneficio dejando constancia de la fecha de Administrador de

32. Anular Beneficio
anulación y el motivo. Redes Sociales
Poner a disposición uno o más beneficios registrados para Administrador de

33. Publicar beneficios los usuarios de la APP FF y enviar notificaciones a sus Redes Sociales
dispositivos móviles.
Página 28 de 30
Registrar Comercio Registrar los datos de un comercio adherido que estará Administrador de
34. Adherido vinculado con algún beneficio que ofrecerá la APP FF. Redes Sociales
Modificar Comercio Modificar los datos permitidos de un comercio adherido. Administrador de

35. Adherido Redes Sociales
Consultar Comercio Consultar los datos de uno o más comercios adheridos en Administrador de
36. Adherido función de criterios predeterminados. Redes Sociales
Eliminar Comercio Borrar los datos de un comercio adherido. Administrador de

37. Adherido Redes Sociales
Registrar una noticia relacionada con el club, que luego Administrador de

38. Registrar Noticia de Club podrá ser publicada para que los usuarios de APP FF puedan Redes Sociales
verla.
Dejar constancia de la entrega de un premio o beneficio al Administrador de

Registrar Entrega de
39. usuario de la APP FF que salió beneficiado, registrando sus Redes Sociales
Premios y/o beneficios
datos y la fecha de entrega.
Proceso responsable de la actualización de cada uno de los Administrador del

Procesar comprobantes de
40. cobros de solicitudes de adhesión realizados por los hinchas Club
cobro
en entidades de cobro fuera de línea (Rapipago / Pago Fácil)
Registrar Confirmación de Registrar confirmación de cobro de inscripción a través de

41. Cobro Inscripción sistemas de pago on line. (Mercado de Pago)
Mercado de Pago
Registrar cobro de solicitud Informar el cobro de la solicitud de adhesión al club. Hincha

42. de adhesión
Modificar Socio Actualizar datos permitidos de un socio registrado en el club Responsable de

43. Socios
Consultar Socio Consultar los datos de uno o más socios en función de Responsable de
44. criterios predeterminados. Socios
Enviar notificaciones a Generar e enviar notificaciones sobre las noticias del club,
usuarios de la APP FF sorteos, beneficios y también sobre los eventos minuto a
45. Tiempo
minuto de los partidos que juega el club a los usuarios de la
APPFF.
Página 29 de 30
Tabla de Contenidos
Contenido
Guía de Ejercicios Prácticos Complementarios sobre Diseño de Arquitectura de Software __________________ 1
Consignas de Trabajo para los EPC: ___________________________________________________________ 1
Dominio: Bus turístico _____________________________________________________________________ 2
Caso de Estudio: Publicidad Multipunto ________________________________________________________ 9
Caso de Estudio: App Mobile para Reclamos ___________________________________________________ 16
Caso de Estudio: App Fanáticos de Fútbol (APP FF) ______________________________________________ 24
Página 30 de 30
Universidad Tecnológica Nacional - Facultad Regional Córdoba
Autores: J. Meles – C. Massano – L. Covaro - G. Boiero- E. Jeinson- F Bene
Aspectos de Diseño a resolver con los patrones de GAMMA
Complejo de Cines:
Un complejo de cines que está integrado por varios cines ubicados principalmente en los centros comerciales
de la ciudad, cada cine cuenta con una cantidad de salas, que son las que exhiben las distintas funciones
cinematográficas. La programación de las salas se renueva en forma semanal, existiendo la posibilidad de
que algunas salas queden sin uso. Cabe mencionar que no todas las salas tienen la misma capacidad
(cantidad de butacas).
La programación es la que determina que películas van a proyectarse y los horarios para cada función de
cada sala, para todos los cines. Esta programación se realiza en forma centralizada, desde la administración
del Complejo, tomándose como base la información de las películas próximas a estrenar, que envía el INCAA
(Instituto Nacional de Cines y Artes Audiovisuales). La programación implica el diseño de las funciones y sus
horarios en forma anticipada, debiendo el responsable de la misma, habilitar cada función en el momento
que desee permitir la reserva y/o venta de entradas para la misma.
Cada cine del complejo cuenta con una cartelera electrónica que proyecta las funciones vigentes
mostrando: película, calificación, horario, estado de la función en cada momento. Esta cartelera la actualiza
el sistema conforme el paso del tiempo y la venta de las entradas.
El complejo vende entradas en mostrador para las funciones que están exhibiéndose en ese momento o para
funciones posteriores.
La entrada que se le entrega al cliente representa el comprobante de venta, debiendo contener como datos:
nro. de venta, fecha de venta, número de función, sala en la que se proyecta la película, el nombre de la
película, fecha y hora de la función, el precio y el tipo de entrada (si es mayor, menor, jubilado). Es importante
destacar que la entrada es válida únicamente para la fecha, hora y función indicadas en la misma, si bien no
es frecuente se pueden atender devoluciones de entradas vendidas.
Los tipos de entradas y los días y horarios de proyección son los que determinan el precio de la entrada. Las
funciones admiten ciertos tipos de entradas y otros no, dependiendo de factores como: horarios, calificación
de las películas, etc. Por ejemplo: si una película está calificada como para mayores de 16 años, para esa
función no se pueden vender entradas de TIPO = MENOR.
Cada función tiene asociado un tipo de función, que determina si la función es un pre-estreno, uno estreno,
una función normal.
Además la dirección del complejo suele implementar promociones para publicitarse, las mismas son variables
en el tiempo, ejemplo de algunas promociones: Dos entradas al precio de una, entradas a un precio más
económico, entradas gratis a cambio de cupones, que pueden aplicarse a una película en particular o a uno
o más tipos de función. En cualquier caso las promociones no son acumulables (no aplica más de una a la
vez).
La dirección del Complejo ha decidido incorporar nuevos servicios que beneficien a sus clientes, siendo estos
los que se mencionan a continuación y para los que se deberán diseñar los procesos de negocio
correspondientes.
Reserva de entradas telefónicamente y a través de la Red Internet, las cuales solo pueden retirarse por medio
de máquinas expendedoras. Cabe aclarar que el servicio de información y reserva telefónico está
centralizado en la Administración del Complejo. Al momento de crearse la reserva se calcula la vigencia de
la siguiente forma: dos horas antes de la hora de la función de la primera función reservada, es decir que si
hay reservas para funciones de diferentes días, se toma como referencia la fecha de la función más cercana.
Consulta de películas vía Web.
2023 Guía de Consignas para Identificación de Patrones de Diseño de GAMMA.docx |1

Venta automática de entradas reservadas, utilizando máquinas expendedoras especialmente destinadas a

tal efecto, siendo la única forma de pago la tarjeta de crédito. La venta por este medio no permite selección
parcial de las reservas realizadas. Se toma la totalidad de los lugares reservados.
Es importante destacar que la película se proyecta a la hora estipulada en la función, independientemente
de la existencia de público en la sala.

class Domain Objects
«entity» «entity» «entity» «entity»

RubroPremio TipoPremio PaisDeOrigen Genero
descripcion descripcion idioma descripcion Los métodos de seteo están
nombre nombre nombre «entity»
nombre 1..* especificados en la clase
Comentario
getDescricpion() 1 «entity» "RubroPremio".
1
getNombre() 1 rubroPremio Pelicula autor En el resto de las clases se
tipoPremio género descripcion especifican algunos métodos
setDescricpion() paisDeOrigen 0..*
añoEstreno fechaIngreso
setNombre() relevantes del dominio.
disponible comentario
«entity» Esté modelo se refinará
0..* duracion
Premio premio sucesivamente.
fechaIngreso calificacion
«entity» nombre «entity»
fechaPremio
Personaje Calificacion
gano tituloOriginal
animado 1 1 descripcion
estaDisponible()
apellido estaEnCartel() nombre
personaje premiado 0..1
nombre mostrarFuncHabilitadas()
sexo 0..1 elenco
pelicula «entity»
«entity» Sala
1..*
«entity» Elenco
rol capacidad
Rol 1
nombreEnPelicula sala numero
descripcion 1..* estaDisponible() sala
pelicula
nombre
1 1..*
«entity» «entity»
Funcion funcion Cine
diaSemana 0..* direccion
duracion fechaInauguracion
fechaHabilitacion nombre
0..*
horaInicio buscarDisponibilidadSalasParaPeriodo()
numero «entity»
buscarPreciosEntrada()
Programacion
programacion
calcularDisponibilidad() mostrarCine()
capacidadSala() estado obtenerInfoHorariosFuncion()
controlarHoraFuncion() funcion fechaFinProgramacion
estaEnLaFuncion() fechaInicioProgramacion 1
estasIniciada() fechaProgramacion cine
1..*
hayLugar() horaProgramacion
permiteVenta() estáCompleta()
estaEnPeriodoVigencia()
1 funcion 1 estaIniciadaFuncion()
estaVigente()
«Pre-condition» mostrarProgramacion() «entity»
{validar que cada
objeto precio que «entity» Promocion
está asociado a un Recurso cantEntradasInvolucradas
objeto función no
repita la sesion apellido descripcion
1
combinación de dni fechaFin
TipoEntrada / «entity» domicilio fechaInicio
TipoFunción, es Sesion montoFijo
decir no debe legajo
nombre nombre
haber más de un fechaFin
precio para el sesion palabraClave pelicula
fechaInicio
mismo Tipo de 0..* permisos porcentajeDto
Entrada y Tipo de
horaFin
tipoFuncion
Función} horaInicio conocerPermisos()
1 conocerPelicula()
conocerCine() conocerSesion()
getNombre() conocerTipoFuncion()
1 mostrarCine()
estaVigente()
anuló mostrarRecursoActivo()
obtenerRecursoSesion() promocion existeNombre()
existeParaPelicula()
1 0..1
existeParaTipoFuncion()
1 1
«entity» creó
Entrada
precio
fechaFuncion
fechaVenta 1..*
0..*
horaFuncion «entity» tipoFuncion 0..*
horaVenta Precio
precio precio 0..*
pelicula 1 horarioFunción
fechaFin tipoFuncion «entity»
precioCobrado
sala fechaInicio TipoFuncion «entity»
1
monto anuló HorarioFuncion
ticketNro creó descripcion
estaAnulada() estaVigente() nombre diaDeSemana
tenesEstosTipos() «entity»
duracionIntervaloFunc
canceló Reserva
duracionPublicidad
fechaCancelacion esTrasnoche
fechaReserva horaPrimeraFuncion
tipoEntrada fechaVigencia horaUltimaFuncion
1 horaReserva
mostrarHorarioFuncion()
horaVigencia
«entity» numero
cupon 0..1 TipoEntrada numeroDni
descripcion tipoDocumento
«entity» nombre determinarVigencia()
Cupon vigente estaVencida()
cantCuotas estaVigente()
1
codigoAutorizacion tipoEntrada existeReserva() estado
fechaGeneracion mostarFuncion()
mostrarDatos() estado
monto «entity» «entity»
numero DetalleReserva Estado
cantidad 1..* 1 1
detalleReserva ambito
fechaCancelacion descripcion
marcaTarjeta horaCancelacion
1 nombre
estaVigente() esAmbitoDetalleReserva()
«entity» mostrarDatos() esAmbitoReserva()
MarcaTarjeta mostrarFuncion()
domicilio tenesEstaFuncion()
medioAutorizacion estado 1 1 1
1
nombre
telefono estado estado
estado

1. Resolver cómo la cola de impresión de la Interfaz de Impresión deberá gestionar la reimpresión de

la/s entrada/s cuando ocurra algún problema a la hora de imprimir éstas. Deberá restaurarse todos
los datos de la entrada a reimprimirse.
Nota: modelar sólo la dinámica para reimprimir la última entrada.
2. Considerar una manera de recorrer las funciones de una programación cuando se realiza la consulta
de la misma.
3. Resolver cómo se realizará la actualización de los cambios en la programación vigente del complejo
cuando se esté consultando la misma en tiempo real. Considerar las distintas páginas Web que las
publican (en particular las que no pertenecen al complejo) y la cartelera electrónica de cada cine.
4. Establecer un proceso de creación de los diferentes medios para la publicación de la programación
vigente de cada cine y de sus funciones. Los medios de publicación a considerar son la cartelera
electrónica y las páginas Web asociadas.
Nota: modelar sólo la dinámica para la publicación de la programación en la cartelera.
5. Considerar la manera de tener un acceso controlado a los servicios que brinda el subsistema de
reservas, en lo que se refiere a la generación, anulación y cancelación de reservas.
Nota: modelar sólo la dinámica de Anulación de Reservas.
6. Resolver cómo debe comportarse la función de acuerdo al momento en que se encuentre la
misma.
Nota: modelar la dinámica implicada en el contexto del C-U “Registrar Venta de Entradas”.

Gestión de Avisos Clasificados:
En una localidad del interior de la provincia de Córdoba funciona desde hace más de 25 años un importante
semanario llamado “Tribuna”. Dicho semanario sale a la calle los días sábados, cubriendo las noticias y sucesos
de la localidad y región. A continuación se describirá la gestión de clasificados. La recepción de clasificados
puede ser vía telefónica, personalmente en las distintas receptorías de la localidad y región o, solamente para
algunas empresas que hace bastante tiempo publicitan en el semanario, se hacen recepciones vía e-mail.
Los avisos que se publican en la sección “Clasificados”, están a su vez diferenciados en distintas categorías y
a su vez cada categoría puede o no tener sub categorías. Por ejemplo, la categoría “Profesionales” se
subdivide en Oncología, Abogacía, Odontología, etc.la de “empleos y ocupaciones” en pedidos y ofrecidos,
pero la categoría de “Servicios” no tiene ninguna sub categoría. El orden de las categorías en la edición
impresa tienen un orden establecido, pero, eventualmente éste orden puede alterarse. El aviso puede ser de
texto plano o puede tener alguna imagen (en ese caso, el cliente debe enviar el diseño del aviso) y, por
política del Semanario, no en todas las categorías y sub categorías se puede publicar cualquier tipo, por
ejemplo en la categoría. El precio del aviso varía según el tamaño, el tipo, el formato y la cantidad de sábados
que aparecerá publicado, y esto está previamente definido. Los formatos están predefinidos, tienen un
nombre distintivo y definen qué fuente tendrá el aviso y el tamaño, cuál será el espaciado (anterior, posterior,
interlineado), cantidad de palabras en mayúscula, y otros efectos como cursiva, negrita y subrayado.

class M ode lo de Dominio
Receptoria
nombre
numero
ubicacion
receptoria 1
Estado
descripcion
nombre Aviso
esVencido() estado diseño
estado
1 fechaDePrimerSabado
fechaDeRecepcion
fechaDeVencimiento
DiseñoAdjunto
precio
descripcion diseñoAdjunto receptoria
nombre texto
0..1
urlArchivo buscarFormato()
PrecioAviso
calcularPrecio()
conocerDiseñoAdjunto() cantColumnas
conocerEstado() cantLineas
precioAviso
conocerPrecioAviso() categoria
conocerPromocion() fechaVigenciaDesde
conocerReceptoria() 1 formato
estaVencido() monto
getParametroOrdenamiento() subCategoria
aviso
getTexto() tipoAviso
aviso
verificarTipoAviso() buscarFormato()
verificarVencimiento() conocerCategoria()
Categoria
0..* 0..* conocerFormato()
aviso conocerSubcategoria()
componentes categoria
conocerTipoAviso()
descripcion subcategoria
esTipoDeAvisoDiseño()
nombre
numOrden 0..1
Subcategoria 0..1
subcategoria aviso
tipoAviso descripcion
ubicacion nombre
agregar(IComponenteAviso) tipoAdmisible
buscarAvisos() ubicacion
buscarDatosAvisos() agregar(IComponenteAviso)
subcategoria
buscarFormartoAvisos() buscarAvisos()
buscarSubcategorias() buscarDatosAvisos()
conocerAviso() 0..* buscarFormartoAvisos()
conocerSubcategoria() conocerAviso()
conocerTipoAviso() conocerTipoAviso()
eliminar(IComponenteAviso) eliminar(IComponenteAviso)
getNombre() getNumero() Espaciado
getNumeroOrden() getNumeroOrden()
listarSubcategoria() espaciadoAnterior
mostrarSubcategoria() espaciadoPosterior
obtenerHijo() obtenerHijo()
ordenarAvisos() interlineado
ordenarAvisos()
tieneSubcategoria() verificarTipoAviso() mostrarEspaciado()
verificarTipoAviso() verificarVencimiento()
verificarVencimiento()
formato 1
espaciado
tipoAviso 1..* 1
Fuente
TipoAviso Formato
tipoAviso descripcion
descripcion cantPalabrasMayuscula nombre
nombre efecto mostrarFuente()
1..* fuente
espaciado
esDiseño() tipoAviso Efecto fuente 1
1 nombre
descripcion efecto
tamañoFuente
nombre 0..*
buscarEspaciados()
buscarFuente()
conocerEfecto()
conocerEspaciado()
conocerFuente()
mostrarFormato()

7. Considerar la forma de trabajar de manera consistente la estructura de organización de los avisos.

Modelar la vista dinámica de la búsqueda de avisos que no estén vencidos.
8. Resolver el proceso de creación de los distintos tipos de avisos en el momento de generar la
visualización de la plantilla. Los tipos de avisos posibles son Aviso de Texto Plano o Aviso con Diseño.
Modelar la dinámica para la creación de Aviso de Texto Plano.
Estación de Servicios
Una Estación de Servicio de una conocida marca, ubicada en el centro de la ciudad, se dedica a la venta
de combustibles (gasoil, nafta común, nafta súper y nafta ultra) y lubricantes. Los clientes que llegan a la
estación de servicio con la intención de cargar combustible deben esperar a que un encargado de playa lo
atienda, solicitarle el combustible deseado y aguardar a que se realice el expendio en uno de los cinco
surtidores disponibles. Una vez realizado el expendio de combustible, el cliente se dirige a la caja, en donde
el cajero se informa de las ventas realizadas en la playa (los expendios que se realizan se van agregando a
una lista de pendientes para cobrar) y le cobra al cliente en función del surtidor en el que éste le informe que
se realizó el expendio. Otros servicios que brinda la Estación de Servicio a sus Clientes son las distintas formas
de lavado de vehículos y el cambio de aceite y filtros. Para la realización de los servicios se aceptan reservas
previas.
Los tipos de lavado que se ofrecen son: lavado de carrocería, lavado de motor y lavado de interiores. Cuando
un cliente desea realizar a su vehículo algún tipo de lavado (puede ser uno o varios), debe dirigirse al sector
“Lavadero”, donde el encargado de lavados le recibe el auto y le informa a que hora puede venir a retirarlo.
Cada cinco lavados de motor o carrocería indistintamente, se regala al cliente un cambio de aceite. El
cambio de aceite de los vehículos se realiza en el sector correspondiente; el cliente debe dirigirse allí para
dejar su vehículo. El pago de todos los servicios anteriormente mencionados puede realizarse con efectivo,
ticket de combustible, tarjeta de crédito o tarjeta de débito. La Caja está centralizada para todos los servicios,
existiendo un único puesto de cobro. Con respecto a la venta de combustibles, cuando es en efectivo, puede
darse la situación que el encargado de playa sea quien cobra y al final del día le rinda al cajero. En caso de
pagarse en Caja, la emisión del ticket debe tomar un tiempo máximo de 5 segundos.
Semanalmente, se reabastece de combustible a la Estación de Servicio por medio de camiones que los
proveen. Cada vez que sucede esto se deben deshabilitar todos los surtidores para realizar la carga en el
tanque subterráneo correspondiente. Cada tanque corresponde a un único combustible y abastece a cada
uno de los expendedores de los diferentes surtidores de la playa. Cuando el tanque contiene una cantidad
de combustible tal que no puede seguir expendiéndose combustible, es necesario deshabilitar todos los
expendedores asociados a ese tanque. El tanque tiene que tener una cantidad mínima de litros que al menos
logre cubrir la carga completa de un vehículo grande por surtidor, considerando que todos los surtidores están
expendiendo combustible en el mismo momento. Cada surtidor tiene cuatro expendedores de combustibles
distintos, es importante aclarar que no se puede realizar expendios simultáneos en un mismo surtidor, pero los
cinco surtidores pueden realizar expendios en un mismo momento. En el visor que contiene el surtidor, se
informa el precio del combustible que se está vendiendo, la cantidad de litros y el precio total de la venta.
Todas las instalaciones deben cumplir con las normativas ambientales y legales establecidas por los
organismos de control locales. Se ha solicitado que las pantallas se visualicen en tonos azules coincidentes
con los colores del logo de la marca de la estación de servicio, además se debe incluir el logo de la marca
en las pantallas.
La cadena de estaciones de servicios ha adquirido los productos de Oracle para gestionar las bases de datos,
por lo que se ha solicitado utilizar estos productos para definir las bases de datos de la estación de servicios.

Cabe aclarar que el sistema a desarrollar es para una estación de servicios en particular y no se requiere
establecer conexiones mediante el sistema con otras estaciones de servicio de la misma cadena.
FormaPago Cliente
Cupón
nombre Cobro nombre
MarcaTarjeta númeroT arjeta
descripción fecha DNI
1 1 fechaVencimiento
formaPago : FormaPago nombre teléfono
marcaTarjeta : MarcaT arjeta
mostrarDatos() habilitada 1 reservas : Reserva
cupón : Cupón cliente : Cliente
númeroT icket 0..1
detalle : DetalleCobro actualizarVigenciaPrestacionPorVehiculo()
conocerMarcaTarjeta()
Cargo conocerHistorialUsosServicios()
cajero : Recurso
nombre conocerReservas()
descripción Modelo Vehículo conocerReservasVigentes()
conocerCupón()
nombre año 0..* contarPrestacionesVigentesParaPromoción()
conocerFormaPago()
1 conocerRecurso() descripción patente contarPrestacionesVigentesPorVehiculo()
1 tipoVehículo : T ipoVehículo
mostrarDetalle() marca : Marca
modelo : Modelo
conocerMarca() combustible : Combustible
Recurso 1 Marca prestaciones : PrestaciónServicio
1 0..*
nombre nombre T ipoVehículo
domicilio descripción conocerCombustible() nombre Reserva
DNI 1 conocerModelo() descripción fechaAlta
legajo conocerPrestacionPorServicio()
fechaReserva
teléfono PrestaciónServicio conocerT ipoVehículo()
horaReserva
cargo : Cargo fecha servicio : Servicio
1..* 1 0..*
hora estado : Estado
conocerCargo() servicio : Servicio usoServicio : PrestaciónServicio
0..*
...
vigenteParaPromoción
1 recurso : Recurso conocerEstado()
kilometraje conocerServicio()
0..1
estado : Estado conocerUsoServicio()
vehículo
Servicio
1 1
conocerEstado() nombre Relación con
conocerRecurso() descripción Promoción Combustible: Precio
conocerServicio() precioActual : Precio por Litro
nombre
1..* servicioT ienePromoción() promociones : Promoción Relación con servicio:
0..* fechaAlta
0..1 insumosNecesarios : Insumo fechaInicioVigencia precio único
DetalleCobro fechaFinVigencia
consumo : Consumo calcularPrecio() descripción
insumo : InsumoVendido conocerPrecioActual() cantidadPuntos
PrestaciónServicio : PrestaciónServicio conocerPromocionesVigentes() servicioPromocionado : Servicio
importe existenPromociones()
Precio
conocerConsumo()
precio
conocerPrestaciónServicio()
fecha
calcularImporte()
conocerInsumo() 1 tipoVehículo : T ipoVehículo
0..*
new() Insumo 1
Estado 1 conocerT ipoVehículo()
nombre Ámbito
nombre
descripción 1..* nombre 1
descripción 1
precio descripción
mutuamente ámbito : Ámbito
excluyentes 1
mostrarDatos() 1 getNombre() HistorialPrecio
1
1 fechaAlta
motivo
0..1
T anque precio : Precio
InsumoVendido
1 capacidad
cantidad litrosActuales crearPrecio()
estado : Estado 1
estado : Estado 0..*
insumo : Insumo combustible : Combustible
número
estáPendienteCobro() cantidadLitrosMínima
... 1
0..1
Combustible
Consumo actualizarLitrosActuales()
nombre
fechaInicio conocerCombustible()
octanaje
horaInicio conocerEstado()
0..1 precioActual : Precio
fechaFin
Surtidor historialPrecio : HistorialPrecio
horaFin
número 1
litrosConsumidos Expendedor
fechaAlta conocerHistorialPrecios()
combustible : Combustible número
ubicación conocerPrecio()
estado : Estado fechaAlta
recurso : Recurso estado : Estado Recarga
posiciónEnSurtidor
expendedores : Expendedor estado : Estado fecha
conocerCombustible() fechaBaja consumos : Consumo litrosRecargados
0..* tanque : T anque
conocerEstado() tanque : T anque 1
conocerRecurso() conocerEstado()
estaPendienteCobro() conocerExpendedores() conocerCombustible() conocerCombustible()
mostrarTotalDeConsumo() descontarLitrosDescargados() conocerConsumos() conocerT anque()
conocerEstado()
conocerT anque()
0..*

9. Resolver el comportamiento que debería asumir el expendedor en función de las actividades que
puede realizar en distintos momentos.
10. Se pretende optimizar la utilización de la memoria, por lo que se requiere resolver el problema de no
crear instancias innecesarias de los estados, si ya existe en memoria una instancia del mismo estado.
11. Resolver como se realizará el cálculo de los importes parciales en el momento de registrar el cobro,
considerando que los cobros parciales se calculan al registrarse el cobro de los consumos pendientes
de cobro, las prestaciones de servicio y los insumos comprados por un cliente. Mostrar la dinámica del
cálculo de un cobro parcial de una prestación de servicio.
12. Considerar para el momento de la obtención de reportes de consumo de combustible, la manera de
obtener los consumos que es necesario incluir en el reporte.
13. Solucionar el problema de cómo deshabilitar a los expendedores abastecidos por un tanque cuando
el mismo no tiene la cantidad de combustible suficiente para abastecerlos.
Tours
Una agencia de turismo se dedica a armar tours por Europa donde el traslado durante el tour y los hoteles en
cada ciudad visitada. Además se incluyen algunas excursiones para cada ciudad incluida en un tour. La
agencia tiene definidos tours de una duración fija, a partir de los cuales se organizan viajes con diferentes
fechas de salida.
Un tour tiene previamente definidos un conjunto de hoteles que se pueden ocupar en cada ciudad. En el
momento de definir un viaje se decide cuál de los hoteles disponibles será ocupado y en qué habitación se
ubicará a cada pasajero. Para esto se tiene en cuenta si los pasajeros vienen en grupos de amigos y/o
familiares, y qué capacidad de habitación solicitaron.
Para realizar un viaje se arman grupos de pasajeros a los cuales se les asigna un colectivo y un chofer. En el
momento en que se diagrama un viaje de un tour se debe asignar un guía que acompañe a los pasajeros en
cada ciudad a visitar. La diagramación de un viaje incluye además la asignación de guías locales.

class ModeloDeAnálisis
Pasaj ero HabitaciónContratada
«entity»
Grupo - dni - cantidadCamasDosPlazas
- domicilio - cantidadCamasUnaPlaza
- asignado pasajeros habitación
- nombre - capacidad
- fechaCreación 1..* - teléfono 1..*
+ esDeFechaDeTour()
+ getDatosGrupo() + getCapacidad()
+ contarHabitaciones()
+ ocuparHabitaciones() + ocupar()
+ getDatosPasajero()
+ ocuparHabitaciones()
0..*
ciudadDeHabitación
habitaciónAsignada
ocupaciónDeHabitaciones
«entity» 1 0..1
Tour
- fechaRegreso DetalleTour HabitaciónHotel
- fechaSalida
- fechaLlegada - cantidadCamasDosPlazas
detalles - cantidadCamasUnaPlaza
+ buscarHotelesDeViaje()
1..* + getFecha() - capacidad
+ esMayorQueFechaActual()
+ getDatos() + getFechaLlegada()
+ getHotel() + estáLibre()
+ mostrarFechasdeLlegadaViaje()
+ ocuparHabitacionesDeHotel() + getCapacidad()
+ mostrarGrupos()
+ ocupar()
+ ocuparHabitaciones()
+ tienePasajeros()
1..*
0..* definiciónTour hotelReservado
tour 1 habitaciones
«entity» 0..1
1
DefiniciónTour
«entity»
«entity» Hotel
- duraciónDías
DetalleDefiniciónTour
- nombre
- descripción
- tour - cantidadDías - nombre
detalles - orden
+ buscarFechasDisponsibles() 1..* + buscarHabitacionesLibresParaFechas()
+ buscarHotel() + getCantidadDías() + getHabitaciones()
+ getFechasDisponiblesConPasajeros() + getCiudad() + getNombre()
+ getNombre() + getHotel() + ocuparHabitaciones()
+ mostrarFechasLlegada()
+ mostrarGrupoDePasajeros() 0..*
ciudad hoteles
+ ocuparHabitaciónPorPasajeros()
1
«boundary»
«entity»
PantallaAsignaciónHabitaciones
Ciudad
«control» - botonAceptar: Botón
- nombre
GestorAsignaciónHabitaciones - botonCancelar: Botón
- comboFechas: Combo
- fechaActual + getNombre()
- comboHabitación: Combo
- tours: DefiniciónTour - comboTour: Combo
- tourSeleccionado: DefiniciónTour - etiquetasDíasHospedaje: Etiqueta[]
- etiquetasGrupo: Etiqueta[]
+ asignarHabitación() - etiquetasHabitacionesLibres: Etiqueta[]
+ buscarFechasConPasajero() - etiquetasHotel: Etiqueta[]
+ buscarHotelesContratados() - grillaPasajeros: Grilla
+ buscarToursDisponibles() - solapasCiudad: Solapa
+ finCU()
+ mostrarDetalleTour() + solicitarConfirmación()
+ nuevaAsignaciónDeHabitaciones() + solicitarSelecciónHabitación()
+ tomarFecha() + solicitarSelecciónTour()
+ tomarHabitaciones() + tomarOpciónAsignaciónDeHabitaciones()
+ tomarTour() + tomarSelecciónConfirmación()
+ validarCapacidad() + tomarSelecciónFecha()
+ tomarSelecciónHabitaciónContratada()
+ tomarSelecciónHabitaciónHotel()
+ tomarSelecciónTour()

14. Considerar la manera de tener un acceso controlado a los servicios que brinda el subsistema de
hotelería, en lo que se refiere a la diagramación de los tours y posterior contratación de los mismos.
Modelar la vista dinámica del acceso a la diagramación de los tours.
15. Resolver la forma en que al habilitarse las pantallas de diagramación, modificación y consulta de la
asignación de habitaciones se muestran los componentes de la pantalla, considerando que los
componentes son los mismos para todas las pantallas pero se muestran habilitados o deshabilitados
según permitan o no la edición los datos. Mostrar la vista dinámica de la pantalla de diagramación
de la asignación de habitaciones.
Transporte Urbano de Pasajeros
El sistema de transporte público de la Municipalidad de Córdoba está integrado por colectivos, trolebuses,
taxis y remises. Para cumplir con el objetivo de trasladar los pasajeros de un punto a otro dentro de la
ciudad, se han establecido corredores que conectan determinados sectores de la ciudad. Cada corredor
cuenta con distintos recorridos que se asignan a una Línea de Colectivos o Trolebús determinada, de la
empresa. Cada recorrido, cuenta con paradas identificadas como “zona”. Las paradas pueden ser
utilizadas por distintas líneas y empresas.
Cada unidad de transporte está dotada con una máquina “Canceladora” que permite registrar el pago del
viaje. Cada vez que un usuario sube a un colectivo según el medio de pago que utilice ocurre lo siguiente:
Al final del turno, el chofer emite un comprobante desde la máquina canceladora en el que figura un
resumen de las transacciones realizadas por tipo y le permite saber cuántos cospeles debe rendir a la
empresa.

16. Definir una estructura flexible que permita manejar de manera sencilla la organización de corredores,
recorridos y paradas del sistema de transporte público masivo.
17. Resolver la administración de un Cierre de Turno generado para el caso que sea necesario restaurar el
Informe de cierre si ocurre un problema de impresión al momento de su emisión.

Líneas Aéreas
Una línea área desea implementar una página web en la cual sus potenciales pasajeros podrían consultar la
disponibilidad de vuelos a los diferentes destinos que ofrece la compañía. Para cada uno de estos destinos
(ciudad origen – ciudad destino) se determina una vigencia ya que en determinadas épocas del año pueden
o no ofrecerse, y esto es tenido en cuenta a la hora de diagramar los vuelos.
Además la página debe ofrecer un seguimiento de los vuelos, para lo cual el sistema que las soporte debe
registrar en cada momento la situación en la que se encuentra cada vuelo, ya que los mismos una vez
programados pueden concretarse, demorarse o cancelarse. Si para un vuelo programado ha llegado el
momento de embarque, el sistema debe informarlo para permitir registrar si el embarque se ha concretado o
no. Si esto fue posible, el sistema informará que se está embarcando o de lo contrario informará que el mismo
se encuentra demorado.

18. Al cancelarse un vuelo el sistema deberá notificar automáticamente esta situación a los distintos
interesados (cartelera de publicación de vuelos o pantalla de consulta del Sitio WEB de la aerolínea).
Para ello tendrá que diseñarse un esquema de notificación que sea genérico y flexible para permitir
informar en tiempo real y simultáneamente a los distintos interesados. A su vez, este esquema tendrá
que proporcionar la información referente a la cancelación (fecha, motivo, descripción y responsable)
para los interesados que lo requieran.
Medidores de Agua Potable
Una empresa privada se dedica a prestar el servicio de agua potable a diferentes ciudades del interior de la
provincia de Córdoba. Para realizar la facturación un grupo de empleados responsables de medición debe
recorrer la ciudad correspondiente controlando los medidores de agua.
Cada ciudad está divida en zonas, para cada zona se asigna un empleado responsable de tomar las lecturas.
Para tomar las lecturas cada responsable de medición cuenta con un captor y una impresora para generar
la factura asociada a un medidor. En la casa central de la empresa se deben actualizar los datos de los
captores, tomando de una base de datos centralizada la información correspondiente a cada zona:
propiedades incluidas en una zona, última lectura de cada propiedad, datos del medidor de cada
propiedad, ruta de lectura de la zona y número de orden de lectura de cada propiedad. Con esta
información cada responsable de medición debe seguir la ruta indicada y realizar las mediciones
correspondientes.
Al comprarse los medidores se guardan en un depósito, hasta ser asignados a una propiedad, en ese
momento se les asigna un número de medidor y se pega una etiqueta con éste número para que el
responsable de medición lo identifique con facilidad.
Cada propiedad cuenta con un único medidor. Cuando un responsable de medición llega a una propiedad,
controla el medidor y registra en el captor la lectura. Una vez tomada una lectura el responsable de medición
genera la factura correspondiente. Al registrar la lectura en el captor calcula el consumo actual desde la
última lectura tomada.
19. Hallar la forma de recuperar las propiedades correspondientes a la zona asignada a un captor
mostrando para las mismas el número de medidor asociado.

Asignación de Aulas
La Universidad Nacional de Córdoba posee en la ciudad universitaria baterías de aulas comunes que son
asignadas a las distintas facultades que no cuentan con infraestructura propia suficiente para todas sus
materias. Esa asignación se realiza a principio de año previendo el funcionamiento de materias anuales y
cuatrimestrales. Cada facultad debe hacer una solicitud detallando la carrera, la materia, la cantidad de
alumnos estratificados en rangos (ej.: 1-20, 21-30, 31-40, etc.), si el dictado es teórico o práctico, qué butacas
necesita (auditorio o sillas móviles para formarse en grupos), el nombre del docente a cargo y docente/s
dictantes. Si hay algún problema de movilidad y acceso para docentes o alumnos. Además debe explicitarse
los días y horarios de cursado ordinarios y si el docente hará uso de medios de proyección ya que el aula debe
poder oscurecerse. Las materias que se dictan más de una vez a la semana, deben detallar todos los días y
horarios en que se dictan.
Para exámenes y parciales se deben completar nuevas solicitudes, ya que en general los requerimientos
cambian.
Una vez vencido el plazo de presentación de solicitudes para materias anuales y cuatrimestrales, un
administrativo de la Secretaría General de la Universidad, busca las aulas más adecuadas para tratar de
satisfacer las necesidades de cada uno y realiza las asignaciones de acuerdo a los calendarios académicos
autorizados por cada facultad. Algunas materias no consiguen aulas totalmente adecuadas a lo que
solicitaron. En este caso, el administrativo consulta al solicitante si puede resignar alguna de las restricciones
(salvo la de la capacidad requerida). Si es así, realiza la asignación de todos modos.
Por determinados eventos declarados como de Interés de la Universidad, se puede suspender la asignación
de algún aula, y tratar de reasignar otro espacio para no entorpecer el normal funcionamiento de las clases
durante estos eventos que son Congresos, Conferencias y otras actividades organizadas por las mismas
facultades. Los espacios se consiguen únicamente con la condición de que la solicitud esté autorizada por el
Decano de la facultad.

20. Diseñar el comportamiento variable del método asignar() de la solicitud en función de la situación en
la que la misma se encuentre
Importador de Insumos de computación
Arg-Computers es una empresa que se dedica a la importación y venta de insumos de computación en

distintas ciudades del país. Las ventas se realizan exclusivamente a mayoristas de la zona de cada sucursal.
La mecánica de la importación se da a partir de pedidos a proveedores que se realizan cuando el stock de
los productos se encuentra cercano al nivel mínimo.
Se realiza el pedido al proveedor respectivo (proveedor oficial de cada marca de productos, por ejemplo
Hewlett Packard o Samsung). El proveedor envía un acuse de recibo (generalmente vía e-mail) para informar
que el pedido ha sido correctamente recibido.
El proveedor analiza el pedido y luego envía un detalle de los productos que posee en ese momento para
poder cumplimentarlo (por lo cual el pedido realizado puede estar total o parcialmente confirmado de envío);
los restantes productos del pedido son enviados en el lapso de 15 días. Finalmente al momento de la recepción
de los productos enviados, se registra la cumplimentación total o parcial del pedido.
La venta a los distribuidores se inicia cuando éstos realizan solicitudes de reabastecimiento desde la página
web de la empresa, donde también pueden consultar el nivel de stock de cada producto y la fecha de

reposición de aquellos que están en falta. Las ventas concluyen cuando Arg-Computers entrega la totalidad
de los productos correspondientes a las solicitudes de reabastecimiento.
21. Diseñar la generación del número único de solicitud de reabastecimiento.

Nota: Limitar la dinámica para sólo mostrar ese código en la pantalla.
Elecciones
Un partido político decidió encargar un sistema que registre los resultados electorales para poder tener un
contralor de los datos oficiales. La estructura geográfica considerada en una elección es la siguiente: El país
está divido en diferentes provincias, cada provincia está organizada en departamentos que están

compuestas por localidades. Cuando una localidad tiene una gran cantidad de habitantes es dividida en
diferentes circuitos que y cada circuito contiene un conjunto de establecimientos (escuelas, facultades, etc.)
en donde se encuentran ubicadas las mesas donde se realiza la elección. Las mesas están numeradas
unívocamente y se clasifican en femeninas, masculinas, extranjeras y militares. Los circuitos se identifican con
un nombre de circuito o seccional y un número. Hay que tener en cuenta que en un mismo establecimiento
pueden existir mesas femeninas y masculinas. Para cada mesa se debe determinar a partir de qué apellido y
hasta que apellido se incluye.
Cuando se convoca una elección, el juzgado electoral que es autoridad en cada distrito (provincia), fija una
fecha - siempre en día domingo - y se declara qué cargos se renovará.
Dependiendo del distrito del que se trate, se eligen distintos cargos y existen distintos cargos, según lo
establezca la Constitución de cada provincia. Al momento de registrar los resultados, se solicita que estos
puedan registrarse por mesa, o por grupos de mesas. Una vez cargado, ese resultado tiene carácter de
provisorio. Hay supervisores de carga, que controlan los resultados cargados por los data entry y los confirman
o los anulan. Cuando se anula un resultado, la mesa o el conjunto de mesas involucradas vuelven a aparecer
como “no escrutadas” y se les puede volver a cargar un resultado.
22. Definir una estructura flexible que permita manejar de manera sencilla la jerarquía de la estructura
geográfica.
23. Diseñar el comportamiento variable de la mesa dependiendo de la situación en que la misma se
encuentre.

Campeonato Náutico
Un club a las orillas del lago San Roque organiza campeonatos náuticos durante todo el año. Cada
campeonato es de un único tipo de embarcación y consiste en una o más regatas. Una regata es una carrera
entre un conjunto de veleros, tablas de windsurf, motos náuticas u otras embarcaciones, que tiene una ruta
predefinida.
Cada campeonato define un conjunto de restricciones que deben cumplir los participantes y las
embarcaciones para poder participar, como ser un rango de peso y tamaño, una forma de tracción
determinada (a vela, con motor, a remo) y ciertas medidas de seguridad definidas (barandas, salvavidas para
todos los miembros de un equipo). Los campeonatos tienen un máximo permitido de participantes.
Los campeonatos pueden ser por equipo o individuales, donde cada miembro del equipo puede formar parte
de una única embarcación en un mismo campeonato. Al inscribirse a un campeonato, si la participación es
por equipo, se debe definir un capitán del equipo y un nombre de equipo. En caso de ser un campeonato
por equipo está definido un rango permitido de cantidad de participantes y cada participante puede
pertenecer a un único equipo.
Al realizarse una regata se registra la hora de inicio de la misma, y al finalizar se registran las horas de llegada
de cada uno de los equipos o participantes individuales. Luego se generan los reportes donde se informan las
posiciones de los distintos participantes en cada regata, y los resultados finales en cada campeonato.

Campeonato
fechaInicio : Date Premio Proveedor
fechaFin : Date descripción nombre
+proveedor
cantidadMaximaPorEquipo posición dirección
cantidadMínimaPorEquipo 1 teléfono
cantidadMáximaInscriptos +premio 1..*conocerProveedor()
esPorEquipo
montoInscripción
nombre
Regata
Ruta
calcularMetrosTotales() fechaInicio : Date
cantidadVueltas : Integer
calcularDuración() fechaFin
nombre : String
determinarGanador() horaInicioPlanificada : Time +ruta
determinarPosición() +regatas horaInicioReal
conocerTipoEmbarcación() cantidadVueltasRuta 1 getNombre()
1..* getTramos()
conocerRestricciones()
seRealizó(fechaActual : Date) : Boolean getEquipoGanador()
validarUnicidadDeParticipantes() seRealizó() +tramoRegata
validarInscripciónParticipanteACampeonato() getFechaInicio() *
getNombre() : String getHoraInicio() TramoRegata
getRegatas() : Regata[] getRuta() nroOrden
getTipoEmbarcación() : TipoEmbarcacion mostrarDatos() metros
mostrarDatos()
getMontoInscripcion() getNúmero() : Double
+restricciones +posiciones getBoyaInicio() : Boya
1 0..* getBoyaFin() : Boya
+tipoEmbarcación 1..*
calcularDistancia()
1 PosiciónRegata
Restricción getDatosTramo()
horaLlegada +boyaInicio
TipoEmbarcación descripción fechaLlegada
cantidad +boyaFin
nombre : String posición 1
descripción : String esUnMáximo 1
Boya
getEquipoEnPosición()
getNombre() : String getDescripcion() getParticipanteEnPosición() númeroBoya : Double
+campeonato
setNombre() conocerInscripción() anguloDeGiro
getDescripción() calcularTiempoTotal() latitud
setDescripción() getDetalles() longitud
1 getNúmeroBoya()
Inscripción +inscripción Equipo
+TipoEmbarcación
fecha 1 nombre
número
conocerParticipantes()
getParticipantesDeEquipo() +equipo conocerParticipante()
esDeParticipante() +capitan
new() +Sesión +Sesión
Embarcación +participante
crearComprobante() 1 1 1
nombre getNumero() [mutuamente excluyente] 1..*
dominio Participante
+Embarcación conocerComprobante() nombre Sesión
titular cancelar()
alto +participante apellido fechaInicio
1 confirmarParaRegata() dni horaInicio +Sesión
ancho finalizar() 1
largo teléfono fechaFin
aprobarExamenMédico() dirección horaFin
peso rechazarExamenMédico()
reintegrarInscripción() getDNI() : Double 1
esDelTipo() validarAnulación()
cumpleConRestricciones() esDNI() : Boolean
validarParticipación() 1
mostrarDatos()
+estado +comprobanteCobro +Sesión
1 1
Estado ComprobanteCobro +Usuario
nombre número Usuario
descripcion monto nombre
fechaPago contraseña
getNombre()
getDescripcion() new()
getDatos()
24. Resolver el problema de lógica para buscar los participantes o los equipos aptos para ser inscriptos en
un campeonato determinado, teniendo en cuenta cómo se realizará la búsqueda si el campeonato
es en equipo o es para participantes individuales.
NOTA: en el Diagrama de Secuencia enfocar el modelado en detalle sólo para la búsqueda de los
participantes aptos para ser inscriptos.
25. Resolver la forma de recorrer y recuperar los campeonatos que aún no se han corrido y mostrar las
regatas, rutas y tipo de embarcación asociados.

Sistema de Órdenes de Trabajo de Cortes de Servicio
Una empresa de servicios de la Ciudad de Córdoba realiza el corte del servicio a los clientes morosos (cuando
registran 3 facturas impagas) a través de contratistas. Para la gestión de los cortes de servicio necesita un
sistema que permita disminuir los costos, a través de las siguientes acciones:
• Optimizar el trabajo de los inspectores
• Optimizar el uso de materiales
• Realizar el seguimiento del trabajo de la contratista
Diariamente el Administrativo de Gestión de Cortes (AGC) de la empresa asigna a cada contratista las
órdenes de trabajo de corte de servicio a ejecutar (una orden de trabajo por cada cliente y cada asignación
es de una orden de trabajo) y se las entrega impresas. Con la información suministrada (número de orden,
fecha de generación, datos del cliente, dirección en donde efectuar el corte y tipo de corte a realizar.
Las cuadrillas de la contratista ejecutan el corte. Al final del día cada contratista devuelve las órdenes de
trabajo de corte impresas con información de campo del corte realizado, pudiendo ocurrir que existan
órdenes de trabajo asignadas que no se informen porque aún se encuentran pendientes.
Para las órdenes de trabajo de Reconexión también se necesita registrar su ejecución y la información de
campo asociada a la misma. Es importante destacar que es necesario mantener la relación entre una Orden
de Trabajo de corte y las Órdenes de Trabajo posteriores que la misma tiene asociadas.


26. Resolver el problema de creación de reportes tanto en pantalla, impreso o exportado a un archivo. El
reporte tendrá dos secciones: el encabezado (contendrá los filtros ingresados y la fecha de
generación) y el cuerpo (compuesto por los datos del informe).
NOTA: en el Diag. de Secuencia enfocar el modelado en detalle sólo para la generación del reporte
en forma impresa.
27. Diseñar el procedimiento de búsqueda de las órdenes de trabajo que cumplan con los filtros elegidos
para generar el reporte de tiempos de ejecución de las OT.
Stock de Productos Lácteos

Una DISTRIBUIDORA MAYORISTA representa en forma exclusiva a una empresa láctea, La Lactosa S.A.,
comercializando sus distintos productos a empresas minoristas. La Lactosa S.A. fabrica productos de distintas
marcas, con distintos precios, tiene una marca principal, una marca para los productos de bajas calorías y
una segunda marca más económica.
Esta DISTRIBUIDORA posee un único proveedor (La Lactosa S.A.) que le provee los distintos productos. Es el
Encargado de Depósito el responsable de determinar las necesidades de compra y de generar las órdenes
de compras., a partir del control del stock mínimo/punto de reposición de los productos lácteos. Al momento
de generar la orden de compra, se deja indicado en el producto, la cantidad comprada, para evitar que se
incluya el mismo producto en varias órdenes de compra, sin ser necesario. Las órdenes de compra deben
generarse una para cada marca.
Con las órdenes de compras recibidas la empresa representada envía los productos, pudiendo suceder que
las órdenes de compra se cumplimenten en varias entregas. Los productos que conforman una entrega se
acompañan por un remito.
Los productos tienen un NOMBRE, una definición, y pueden tener una o varias FORMAS DE PRESENTACION, uno
o varios TAMAÑOS, un TIPO DE PRODUCTO y en algunos casos SABOR (EJ: Yogurt SER Descremado Bebible de
Vainilla de 500 CC, botella de plástico). El Encargado de Depósito controla periódicamente el stock por
producto, como así también la cantidad de productos registrados a pérdidas por mal estado y vencimiento.

28. Resolver la forma en la que se manejarán las variaciones de comportamiento de la Orden de Compra,
en función del momento en que se encuentre.
29. Definir cómo se puede resolver la forma de establecer la relación entre la forma de presentación y el
tamaño que puede tener cada uno de los productos.
Contact Center
Se trata de una empresa cuyo objetivo es proporcionar un “centro de atención multimedia como único punto
de contacto”, entre Clientes y consumidores. Contact Center ofrece diferente tipos de servicios tales como:
Atención al Consumidor, Mesa de Ayuda, Telecobranzas, Telemarketing, Televentas, Estudios de Mercados y
Encuestas.
A continuación se describe la operatoria de “Atención al Consumidor”; cada Cliente de Contact Center tiene
una línea telefónica gratuita (0800) a través de la cual, los consumidores pueden realizar consultas o solicitar
información de un producto. Cuando el Representante de Atención al Consumidor atiende una consulta, la
registra en el sistema ingresando los siguientes datos: tipo de consulta, criticidad, producto, nombre, apellido,
domicilio y teléfono del consumidor, descripción detallada de la consulta. El Representante de Atención al
Consumidor analiza el requerimiento y valida en la ayuda en línea la solución; en caso de poder solucionarlo
comunica las acciones a realizarse al consumidor y las registra en el sistema, cerrando la consulta como
resuelta. Si no puede resolver la consulta, la deriva al Grupo de Soporte de Producto (integrado por personal
del Cliente) comunicando al consumidor: número de consulta, tiempo estimado en el que se comunicará
telefónicamente la solución, el cual va a depender del tipo de consulta.
Con el fin de evaluar la calidad de atención y efectividad de las soluciones, Contact Center mantiene el
detalle de todas las acciones realizadas asociadas a una consulta por cada uno de los recursos involucrados,
desde su generación hasta su cierre. Asimismo, diariamente realiza el monitoreo de las llamadas de los
Representante de Atención al Consumidor, el cual se sintetiza en Informes semanales que son enviados al
Cliente. Periódicamente, también envía a cada Cliente un Reporte de Consultas de Consumidores, en el que

se detalla los tipos de consultas realizadas, tiempo de resolución, soluciones brindadas, porcentajes de
llamadas solucionadas por los Representantes de Atención al Consumidor y de llamadas derivadas al Grupo
de Soporte de Producto.
class Modelo de Analisis
«control»
«boundary» GestorReporteConsulta «boundary»
PantGenReporteConsultas ImpresorReporte
- cliente
- bottonFormaVisualizacion - clienteElegido + imprimir()
- comboCriticidad - consulta
- comboNivelResolucion - criticidad
- comboTipoConsulta - criticidadElegida
- fechaFinPeriodo - fechaFin «entity»
- fechaInicioPeriodo - fechaInicio FormaVisualizacion
- lblCliente - formaVisualizacion
- lblCriticidad - formaVisualizacionElegida - nombre
- lblFechaDesde - nivelResolucion
+ getNombre()
- lblFormaVisualizacion - nivelResolucionElegido
- lblNivelResolucion - tipoConsulta
- lblPeriodo - tipoConsultaElegido
- lblProducto «entity»
+ buscarClientesSAC() «entity»
- lblTipoConsulta ServicioContratado
+ buscarConsultas() Producto
- listaCliente
+ buscarCriticidad() - descripcion - fechaFin
+ habilitarVentana() + buscarNivelResolucion() - nombre - fechaInicio
+ mostrarClientes() + buscarTipoConsulta()
+ mostrarReportePreliminar() + buscarVisualizacion() + getNombre() + conocerProducto()
-servicioContratado + conocerTipoServicio()
+ opcionGenerarReporteConsulta() + finCU()
+ pedirConfGeneracion() + generarReporte() + estaVigente()
+ pedirConfirmacionImpresion() + nuevoReporte() + mostrarNombreProducto()
1..*
+ pedirFormaVisualizacion() + tomarConfGeneracion() «entity» + tieneSACContrado()
+ pedirPeriodoReporte() + tomarConfirmacionImpresion() Cliente
+ pedirSeleccionCliente() + tomarFormaVisualizacion() - cuit
+ pedirSeleccionParametros() + tomarPeriodoReporte() - domicilio -tipoServicio
+ tomarConfGeneracion() + tomarSeleccionCliente() - razonSocial
+ tomarConfirmacionImpresion() + tomarSeleccionCliente() 1
+ tomarFormaVisualizacion() + tomarSeleccionParametros() + conocerServicioContratado()
«entity»
+ tomarSeleccionCliente() + tomarSeleccionPeriodo() + getCliente()
TipoServicio
+ tomarSeleccionCriticidad() + mostrarSACVigente()
+ tomarSeleccionNivResolucion() - descricpion
+ tomarSeleccionPeriodo() - nombre
+ tomarSeleccionProducto()
+ getNombre()
+ tomarSeleccionTipoConsulta() «entity» «entity»
TipoConsulta NivelResolucion «entity»
Criticidad
- descripcion - descripcion
- nombre - nombre - descripcion
- orden - nombre
+ getDescripcion()
+ getNombre() + getNombre() + getNombre()
+ setDescripcion() 1 1 1
«entity» + setNombre() -criticidad
Estado 1
-nivelResolucion
- descripcion -tipoConsulta
- nombre
-estadoInicial
1 -producto
-estado «entity»
Consulta 1
«entity» - apellidoConsumidor
«entity» Actuacion - descricpion
Recurso - direccionConsumidor
- descripcion
- fechaIngreso - fechaCreacion
- fechaFin
- legajo -recurso - nombreConsumidor
1 - fechaInicio
- nombre - nroConsulta
- horaFin -actuacion
- telefonoConsumidor
+ getNombre() - horaInicio
- tiempoEstimadoResolucion + buscarActuaciones()
-accion 1..* + cerrar()
+ conocerAccion()
+ conocerActuacion()
«entity» + conocerEstadoActual()
+ conocerCriticidad()
Accion + conocerEstadoInicial()
1 + conocerNivelResolucion()
+ conocerRecurso()
- descripcion + conocerTipoConsulta()
+ mostrarDatosActuacion()
- nombre + demorar()
+ derivarGrupoSoporte()
+ getNombre() + derivarRep()
+ guardarConsulta()
+ informarCliente()
+ new()
+ resolver()
+ retomar()
+ sonTusParametros()

30. Resolver la necesidad de las búsquedas de las consultas de los consumidores en función de los filtros
elegidos para generar el reporte.
31. Definir el proceso de creación de las diferentes formas de visualización del Reporte de Consultas de
Consumidores.
Administradora de Tambo
En el sureste de la provincia de Córdoba existe un tambo que requiere un sistema para administrar las vacas
destinadas a la producción lechera.
El Propietario describió el dominio y precisó que la gestión de cada vacuno comienza cuando se registra el
nacimiento de la ternera, considerándose que está en crianza hasta que alcance los 200Kgs; luego entra en
la etapa de vaquillona.
Cuando la vaquillona esté preñada (en servicio) por primera vez pasa a considerársela vaca. Después del
parto la misma está disponible para su ordeñe.
Cabe aclarar que es posible comprar animales cuando sean terneras, vaquillonas o vacas preñadas.
La vaca podrá ser ordeñada hasta que no tenga más leche, en esta situación se considera a la misma “seca”;
esto puede ser por razones naturales o luego de alguna enfermedad. La vaca podrá volver a tener leche
luego de un nuevo parto, en caso de que tenga algún impedimento directamente se procede a su venta.
La producción lechera se desarrolla todos los días por la mañana, y según la descripción efectuada por el
Responsable de Tambo es necesario dejar registro de la cantidad de litros ordeñados de cada vaca, grasa,
proteínas y/o células somáticas de la leche. Además, durante este proceso se indica cuando la vaca está
seca, el encargado de ordeñe y el contenedor de la leche extraída.

32. Resolver el comportamiento que puede asumir el Vacuno en función al momento en el que el animal
se encuentre.
33. Considerar la manera de tener un acceso controlado a los servicios que brindan las clases
relacionadas a la producción lechera, en lo que se refiere a la registración, modificación, consulta, de
la producción lechera.

Auditorías Internas ISO
Una empresa del mercado necesita un software para gestionar las auditorias internas que se exigen para la
certificación de las normas de Calidad ISO 9001:2000. A continuación se describe la operatoria de dicha
empresa en lo concerniente a las auditorias internas:
Una vez al año, el Responsable de Gestión de la Calidad (RGC) crea el Programa Anual de Auditoria. Dicho
programa contiene el detalle de las auditorias a realizar en el año, la fecha prevista para cada auditoria, el
proceso sobre el cual se realizará y el dueño del proceso a auditar.
Durante la etapa de ejecución de la auditoria el auditor responsable elabora un informe que contiene la
siguiente información: destinatarios del informe, proceso auditado, fecha de auditoria, objetivo, alcances,
participantes y hallazgos de la auditoria. Los hallazgos se clasifican en No Conformidades, Observaciones y
Oportunidades de Mejora. Una vez que el dueño del proceso auditado recibe el informe con el detalle de los
hallazgos, diseña y establece una propuesta de mejora para cada uno de ellos, definiendo las acciones
necesarias para resolver los hallazgos e indicando si se trata de acciones correctivas o preventivas. El
seguimiento de las acciones descriptas en la propuesta de mejora, se realiza de manera conjunta entre los
auditores y el dueño del proceso. Una vez cumplidas las acciones, las mismas son cerradas por el auditor
responsable.
Es importante para realizar el seguimiento de las auditorias mantener información de los tiempos en los que la
auditoría permanece en cada estado. Uno de los informes necesarios es el reporte de Acciones Vencidas, el
cual muestra los tiempos promedio de retraso en el cumplimiento de las acciones que presenta cada
auditoria, en un programa anual determinado.
Una vez ejecutada la auditoria el auditor responsable elabora el informe final de la auditoria, el cual incluye
los hallazgos y las acciones implementadas, con el seguimiento correspondiente.

34. Resolver como el sistema va a calcular el promedio de retraso considerando la totalidad de los días
calendario y cómo en la totalidad de los días hábiles.
35. Resolver la necesidad de recorrer las acciones asociadas a un hallazgo, al momento de generar el
reporte de acciones vencidas.

Restauración de Cuadros
La empresa se dedica a la conservación y restauración de cuadros, proceso que consiste en evitar el deterioro
de objetos artísticos y devolverles su estado original.
Cuando ingresa un cuadro para ser restaurado se confecciona la solicitud de restauración, definiendo: fecha,
número, organización solicitante, fecha estimada de finalización y el cuadro, para el cual se registra: número,
nombre, autor y año de creación. Al crearse la solicitud estará pendiente de determinar composición.
El proceso de restauración comienza examinando el cuadro con el fin de identificar los materiales de cada
componente. Una vez finalizado el o los análisis específicos, los restauradores determinan el tratamiento que
será aplicado al componente para restaurar la alteración reconocida.
El tratamiento de cada componente analizado implica realizar una actividad que depende del tipo de
componente (a modo ejemplo: el laminado sólo se efectúa sobre la capa pictórica). Existen distintas técnicas
para realizar cada actividad, pero para efectuar la actividad asignada a un tratamiento sólo se requiere la
aplicación de una sola. Además una técnica se utiliza en más de una actividad; por ejemplo: la actividad de
limpieza puede ejecutarse mediante cualquiera de la siguientes técnicas: lavado, blanqueado, etc.; y la
desacidificación puede producirse mediante el lavado.
Cabe aclarar que un componente del cuadro puede tener más de un tratamiento. A veces es necesario
esperar un tiempo de reposo antes de aplicar el segundo tratamiento. Para cada tratamiento se debe
especificar la fecha a realizarse, el componente involucrado, la actividad a realizar y la técnica a emplear.
Será necesario que el sistema deje registrado en la solicitud de restauración cada vez que la pintura esté con
tratamiento asignado y cuando se encuentre en un período de reposo.
La solicitud de restauración estará finalizada recién cuando se finalicen todos los tratamientos asignados a los
componentes de la pintura o se cumpla el período de reposo.

36. Resolver la forma de controlar la asignación del número de tratamiento generado para una solicitud
de restauración, de manera que el mismo no se repita.
Corte de Servicio
Una empresa encargada de brindar el servicio de agua potable a la ciudad de Corrientes necesita un
software que le permita gestionar los cortes de servicio que realiza cuando necesita hacer una reparación o
realizar una nueva obra.
Para proveer el servicio de agua la empresa abastece a sus clientes a través de una red compuesta de la
siguiente manera: sistema (planta potabilizadora) – subsistema (estación elevadora) – cañerías maestras – red
de distribución (de la cual se conectan cada una de las conexiones domiciliarias). Cada parte de esta
estructura abastece a zonas específicas de la ciudad. Por ejemplo, una planta abastece a la región norte de
la ciudad, una estación elevadora a un conjunto de barrios (dentro de los provistos por el sistema que
corresponde), una cañería maestra a un conjunto de manzanas y la red de distribución a un subconjunto de
éstas.
Nota: Para simplificar el dominio consideraremos que una manzana es abastecida en su totalidad por una
única red de distribución. Es decir, no se considerará la alternativa que un lado de la manzana sea abastecido
por una red y otro lado de la misma manzana por otra red.

Cuando la empresa decide realizar un corte de servicio (porque debe realizarse una reparación o una obra
de mantenimiento o ampliación de la red) el software deberá informar, en función del lugar de la red donde
se realice el corte, cuál es la zona afectada por el mismo. Esta información es de utilidad al área de Relaciones
Públicas para informar a la población acerca del corte y al área de Atención al Cliente para informar a los
clientes que consulten y no generar trámites ante reclamos por falta de servicio en la zona afectada mientras
dure el corte.
El corte puede ser Programado o No Programado. En caso de ser Programado deberá registrarse al momento
de la planificación la fecha y hora de inicio, motivo del corte, zonas afectadas y fecha y hora de fin prevista.
Para los cortes Programados cuando se inicia efectivamente el corte debe registrarse fecha y hora real de
inicio y capataz a cargo y luego de su ejecución la fecha y hora real de fin. En el caso de los cortes No
Programados se informa al momento de la ejecución la fecha y hora real de inicio, motivo del corte, zonas
afectadas, capataz a cargo y fecha y hora de fin prevista y luego de su ejecución la fecha y hora real de fin.
En el caso de los Cortes No Programados, cuando la duración real de los mismos es superior a 24 horas la
empresa debe descontar de la factura un importe proporcional a las horas en que duró la suspensión del
servicio.
El Ente Regulador exige a la empresa que comunique mensualmente los cortes de servicios realizados,
informando si han sido Programados o No Programados, la duración y el motivo que originó el mismo. En caso
que el motivo implique una reparación es necesario además informar el reclamo que le dio origen (tipo y
número de reclamo, contacto, dirección, fecha del reclamo, fecha de resolución)


37. Definir una estructura flexible que permita manejar de manera sencilla y uniforme la estructura de la
red de distribución de agua potable. Modelar la vista dinámica de la búsqueda de las zonas afectadas
por un corte de servicio luego de haber seleccionado los componentes afectados.
38. Resolver de manera controlada el acceso a los servicios que brinda el subsistema de Gestión de
Empleados, en lo que se refiere la consulta de cargos, turnos de trabajo y horarios de capataces y
operarios de cuadrillas. Modelar la vista dinámica de la consulta sobre los capataces disponibles para
ser responsables del corte.
Simulador de Compras
Existe una entidad bancaria que emite a sus clientes una o más tarjetas de crédito, es decir, distintas marcas
tales como Visa, MasterCard, etc. Luego de un análisis crediticio se le otorga al cliente una o más de estas
marcas de tarjetas de crédito.
Cada tarjeta de crédito posee diferentes planes de pago con sus respectivos costos financieros para realizar
compras.
Los planes de pago de cada tarjeta son variables, indican la cantidad de cuotas en que puede dividirse el
monto de la compra y el porcentaje sobre los ingresos que admite.
Los Comercios adheridos, es decir, aquellos comercios que reciben las tarjetas de crédito de la entidad
financiera como forma de pago, pueden recibir todas o algunas de las tarjetas, como así también pueden
aceptar todos o algunos de los planes.
La entidad financiera antes de autorizar una compra verifica el estado del cliente (*) y luego el límite, según
el plan que se haya escogido, como así también las compras que ya se han registrado.
A medida que se efectúan las compras se generan cada una de las cuotas, este proceso se realiza
diariamente. Los resúmenes son mensuales e incluyen las cuotas cuyo mes de vencimiento coincida con el
del resumen generado. Los resúmenes se generan el primer día hábil de cada mes y el vencimiento de los
mismos corresponde al sexto día hábil de cada mes.
La entidad desea disponer de un medio web que permite a sus clientes efectuar simulación de compras para
poder determinar si se autorizará o no una compra en las condiciones (tarjeta y plan) que desea.
(*) El Cliente puede estar habilitado o no para realizar compras y esto aplica para cualquiera de las tarjetas
de crédito que posea, este estado se asigna cuando se controla el nivel de pago de los resúmenes de cada
cliente.

class DiagClase s-Analisis
CompraRealizada Comercio «entity»
«entity»
Plan
- comercio :Comercio - nroComercio PlanAceptado
- cuotas :Cuota - planesRecibidos :PlanAceptado 1..* -
- cantidadDeCuotas
fechaVigencia
- fecha - razonSocial - codigo
1 - plan :Plan
- importeTotal - descuentosEspeciales :DescuentoEspecial
+ getNroComercio() 1 - fechaDeVigencia
- plan :Plan
+ obtenerPlanesRecibidos()
- nombre
+ esMayorAFechaYPlan()
- porcentajeDeInteres
+ esTuPlan()
+ esTuPlan() 1..* 1 - porcentajeDeLimite
+ getFecha() + getNombre()
«entity»
+ poseeDescuento() + getNombre()
TarjetaEmitida
+ getPorcentajeDeLimite()
- códigoSeguridad + getPorcentajeDeLímite()
1..* - compras :CompraRealizada + obtenerDescuentosEspeciales()
- fechaVencimiento
1..*
«entity» - habilitada :boolean
Cuota - nroTarjeta
- cantidadTotalCuotas :int - resúmenes :Resumen
- fechaEmisión - tarjeta :TarjetaDeCrédito «entity»
- últimoResumen :Resumen TarjetaDeCrédito
- importeCuota
- importeInterés + calcularImporteParcialCuotasSinResumen() - descripción
- mesVencimiento + crearIterador() 1 - nombre
- nroCuota + estáHabilitada() - planes :Plan
+ esTuPlan() + mostrarPlanes() + getNombre()
+ obtenerCuotasEnResumenNoVencidoDePlan()
1..*
+ getPlanes()
+ obtenerCuotasSiguienteAlUltimoResumen()
+ obtenerLímiteDePlan()
+ obtenerCuotasSinResumenDePlan()
+ obtenerLímiteDePlan()
«entity» 1..*
Resumen
- cuotas :Cuota 1 «entity»
- fechaEmision 0..* Usuario
- fechaVencimiento
- contraseña
- importeBonificacion 1
- nombre «entity»
- pagado «entity»
+ obtenerCliente() Cliente Estado
+ estaPagado()
+ estáPagado() 1 - apellido
- nombre
+ existeCuotaDePlan() - dni
1 + getNombre()
+ getFechaDeVencimiento() - estado :Estado
+ getPlan() - ingresosDeclarados
+ obtenerCuotaDeMes() - nombre
+ setCuotas() - tarjetas :TarjetaEmitida
+ setImporteBonificacion() «entity» + getEstado()
+ sumarImporteEInteres() Sesión + getIngresosDeclarados()
+ getNombre()
- fecha
+ getTarjetasHabilitadas()
- hora
- usuario :Usuario + obtenerCuotasDeÚltimoResumenNoVencidoDeTCYPlan()
+ obtenerLímiteDePlanDeTarjeta()
+ obtenerCliente() + obtenerPlanDeTarjeta()
PantallaSimularCompra GestorSimularCompra
- cancelar :botton - clienteLogueado :Cliente
- cliente :etiqueta - importeCuotasDePlanProximosResumenes
- comercio :TextBox - importeCuotasDePlanUltimoResumen
- confirmar :botton - importeDeCompra
- importe :TextBox - importeParcial
- planes :ListBox - planSeleccionado :Plan
- saldoDisponible :TextBox - saldoDisponible
- tarjetasDeCredito :ListBox - tarjetaSeleccionada :TarjetaEmitida
+ guardarParámetrosYResultadosSimulación() + buscarPlanesDeTarjeta()
+ habilitarIngresoDeComercio() + buscarTarjetasDeCliente()
+ habilitarOpciónSimulaciónAnterior() + calcularImporteParcial()
+ habilitarPantalla() + calcularSaldoDisponible()
+ informarResultadosDeSimulación() + confirmar()
+ mostrarDatosSimulaciónAnterior() + finCU()
+ opciónSimularCompra() + obtenenerIngresosDeCliente()
+ solicitarConfirmación() + obtenerCliente()
+ solicitarIngresoImporteCompra() + obtenerCuotasDeÚltimoResumenNoVencido()
+ solicitarSeleccionDePlan() + obtenerCuotasSinResumenDeTCyPlan()
+ solicitarSeleccionPlan() + obtenerLímiteDePlan()
+ solicitarSeleccionTC() + simularCompra()
+ tomarConfirmación() + solicitarSelecciónPlan()
+ tomarIngresoMontoCompra() + tomarIngresoMontoCompra()
+ tomarOpciónSimulaciónAnterior() + tomarOpciónSimAnterior()
+ tomarSelecciónPlan() + tomarPlan()
+ tomarSelecciónTC() + tomarTC()
+ verificarDatosRequeridos()
+ verificarEstadoCliente()
+ verificarResultadoDeSaldoDeCompra()

39. Se desea obtener la simulación de una compra previamente realizada sin la necesidad de volver a
ejecutar el proceso de simulación. De esta manera un usuario logueado podría acceder nuevamente
al resultado de una simulación que realizó en un instante anterior sin necesidad de cargar nuevamente
todos los parámetros.
40. Se desea acceder a las compras realizadas, que corresponden a la tarjeta del cliente seleccionada,
recorriendo las mismas secuencialmente para obtener aquellas que corresponden al plan y superan
la fecha del último resumen.
Liga de Fútbol
Se trata de una Liga Regional de Fútbol, organización que depende de la Asociación Cordobesa de Fútbol,
y que todos los años organiza campeonatos en los que participan clubes de la región.
La LIGA organiza los campeonatos basándose en dos sistemas, los campeonatos todos contra todos, o los
campeonatos con eliminatorias. El primero consiste en organizar partidos para que todos los equipos se
enfrenten una vez. Generalmente se realizan dos campeonatos de este tipo en el año (Clausura en el primer
semestre, Apertura en el segundo semestre), es importante aclarar que la liga no organiza campeonatos en
forma simultánea.
Cuando se organizan campeonatos con eliminatorias (para copas de verano por ejemplo), se juegan
octogonales, cuartos de final, semifinales y finales. Estas son las denominadas rondas. En cada ronda los
equipos que pierden quedan eliminados, y los ganadores (el primero y segundo de cada grupo) pasan a la
ronda siguiente. Es decir, quienes ganan los octogonales luego juegan los cuartos de final y así sucesivamente.
En estos sistemas de campeonato cada equipo que gana o empata obtiene un puntaje. Al final de
campeonato gana el que más puntaje tiene. La cantidad de puntos que se le va a otorgar a cada partido
ganado o empatado puede variar en cada campeonato. La diferencia en los sistemas de campeonato es
que para los de “Eliminatoria” sólo se asigna puntaje por partido ganado porque en caso de empates, el
partido se alarga hasta que se obtiene una definición, es decir, hasta que alguno de los dos equipos gana.
Según la cantidad de equipos que jueguen los campeonatos se definirá la cantidad de partidos. En el caso
de un campeonato todos contra todos, se juega una cantidad de fechas igual a la cantidad de equipos
menos uno. Se juega una cantidad de partidos igual a la multiplicación de la cantidad de fechas por la
cantidad de clubes divida en dos. En el caso de un campeonato por eliminatorias se organizan tantos partidos
como sean necesarios para finalizar con dos equipos jugando la final. La cantidad de equipos para este
sistema debe ser múltiplo de 4.
Los clubes que desean participar deben inscribirse en la LIGA con un mes de anticipación al comienzo del
campeonato. Luego de realizada la inscripción cada club debe presentar la lista de los jugadores con los que
intervendrá en el campeonato, un examen médico para cada uno, y los datos de la cancha habilitada para
los partidos en que participe como local.
Cuando la Liga realiza la diagramación de un campeonato, de acuerdo al número de clubes inscriptos,
determina la cantidad de jornadas o “fechas” a realizarse, y para cada una se definen los partidos a jugarse,
donde para cada partido se indica la cancha en que se realizará, los árbitros que intervendrán y el rol de
cada uno en ese partido (árbitro principal, juez de línea, etc.).
La información de la diagramación del campeonato, conocida también como fixture, debe ser comunicada
a los interesados en conocerla, para la cual se ha acordado que se le enviará en un formato que le sea útil a
diarios y revistas y además se ha decido incorporar los servicios de mensajes a celulares y de envío de mails
que contengan esta información, para lo cual el sistema deberá resolver la generación de archivos con los
formatos requeridos.
Luego de culminada cada fecha, deben registrarse los resultados de cada partido:

Goles convertidos, indicando para cada gol el jugador que lo realizó, tiempo de juego transcurrido, y si fue a
favor o en contra).
Amonestaciones efectuadas, indicando para cada una el tipo (tarjeta amarilla, tarjeta roja), el jugador y el
tiempo de juego transcurrido.
Las amonestaciones se realizan debido a faltas que convierten los jugadores durante el juego. Si el árbitro
amonesta con una tarjeta roja el jugador debe retirarse del campo de juego (es expulsado) y se le aplica una
sanción que consiste en inhabilitarlo para jugar durante una cantidad “x” de partidos. Luego de cumplida la
sanción el jugador puede continuar jugando los partidos restantes.
Además se desea emitir una lista de goleadores (jugadores que convirtieron más goles) para premiar al
goleador de cada campeonato. Para todos los reportes y estadísticas se ha requerido que los mismos se
muestren tanto en formato de cuadros como en formato gráfico.

class Domain Model
Cancha
TipoCampeonato SistemaCampeonato
domicilio
mesInicioSugerido caracteristicas nombre
nombre nombre
valorPartidoEmpatado
esTuMesJuego() valorPartidoGanado 1
getMesInicioJuego()
getNombre() getNombre() ExamenMedico
Inscripcion
1 descricpcion
1 cancha: Cancha fecha
club: Club resultado
detalleInscripcion: DetalleInscripcion 0..1
Campeonato fechaInscripcion
DetalleInscripcion
estadoActual: Estado conocerCanchaLocal()
estadoAnterior: Estado conocerClub() actuacionJugador: ActuacionJugador
0..* 1..*
fechaCampeonato: FechaCampeonato conocerDetalleInscripcion() examenMedico: ExamenMedico
fechaDeFin mostrarJugadores() jugador: Jugador
fechaDeInicio mostrarNombreClub() situacion: HistorialJugador
fechaVtoPresExamen 0..* conocerActuacionJugador()
inscripcion: Inscripcion conocerExamenMedico()
puntosPartidoEmpatado conocerHistorialJugador()
puntosPartidoGanado HistorialJugador conocerJugador()
sistemaCampeonato: SistemaCampeonato
tipoCampeonato: TipoCampeonato descricpion 0..*
estado: Estado 0..*
calcularDuracionCampeonato() fecha
calcularGoleadorCampeonato() Estado
estado conocerEstado()
calcularGoleadorFecha()
anterior ambito
calcularTablaPosicion()
conocerEstadoActual() descripcion 1
0..1 nombre
conocerEstadoAnterior()
conocerFechaCampeonato() esAmbitoCampeonato() 1
conocerInscripcion() estado 1
Actual
esVigente() 1
cuantasFechas() getAmbito() Club
cuantosPartidosPorFecha() getDescricpion() domicilio Jugador
determinarPuntajeAsignar() getNombre() inscripcion: Inscripcion apellido
esMesInicioJuego() setAmbito() nombre detalleInscripcion: DetalleInscripcion
estaVigente() setDescripcion() dni
mostrarCampeonato() setNombre() buscarJugadores()
fechaNac
mostrarFechasPendientes() buscarUltimaInscripcion()
mostrarNombre() 1 1 0..* nombre
canchaDeCampeonato()
mostrarPartidosPendientes() estaInscriptoCampenato() ActuacionJugador conocerDetalleInscripcion()
mostrarPartidosPorFecha() listarJugadoresInscriptos() estaInscripto()
mostrarPuntosPartidoEmpatado() mostrarNombre() calificacion
mostrarActuacionJuego()
mostrarPuntosPartidoGanado() gol: Gol
mostrarSituacion()
mostrarSistemaCampeonato() 0..1 0..1 partido: Partido
presentoExamen()
new() sancion: Sancion
local tiempoJugado
visitante titular
conocerGol()
0..* conocerPartido()
Partido esTitular()
0..* actuacionJugador: ActuacionJugador
FechaCampeonato asignacion: Asignacion
estado: Estado
estado: Estado fecha
fechaComienzo ganadorPartidoLocal: Partido
numero ganadorPartidoVisitante: Partido
partido: Partido hora 0..*
actualizarJugado() local: Club
calcularPuntajeObtenidoFecha() nombre Gol 0..*
puntajeObtenidoLocal 1
conocerPartido() enContra Sancion
cuantosPartido() puntajeObtenidoVisitante
tiempoJuego
dondeSeJuegaPartido() visitante: Club cantidadPartidosExpulsado
mostrarPartidosPendientes() conocerJugador() tiempoJuego
conocerAsignacion()
esGolEnContra() tipoSancion: TipoSancion
1..* conocerCanchaJuego()
conocerClubLocal() conocerTipoSancion()
Arbitro conocerClubVisitante()
Asignacion conocerGanadorPartidoLocal() 0..1
apellido conocerGanadorPartidoVisitante()
arbitro: Arbitro
dni
rol: Rol conocerGol() ganadorPartidoLocal
0..1
fechaNac 0..* conocerInfoJugador()
nombre 1 conocerArbitro() ganadorPartidoVisitante
conocerSansion()
conocerRol() cuantasSansiones() 1
mostrarNombre()
cuantosGoles()
estaJugado() TipoSancion
estaPteJuego() Estas relaciones descricpion
Rol autorreferenciales son
1 ganadorPartido() mutuamente excluyentes con las nombre
nombre mostrarNombreLocal() de Club, luego de jugados los
mostrarNombreVisitante() partidos (en el caso del Sistema
mostrarNombre() de Campeonato por
partidoJugado() eliminatorias) se reemplazan
queArbitrosIntervinien() estas relaciones con las de Club.
Los atributos puntajeObtenidoLocal y
puntajeObtenidoVisitante son utilizados para
queJugadoresSansionados()
asignar los puntos que le corresponde a cada registrarDesempeñoJugador()
club luego de jugado el partico.En la clase registrarGoles()
campeonato se define el puntaje que se asignará registrarPuntajeObtenido()
a cada partido ganado y empatado.

41. Resolver la forma en que el sistema deberá determinar la cantidad de fechas y partidos que deberán
jugarse para un campeonato en función del sistema de campeonato elegido para ese campeonato.
Modelar la dinámica para un campeonato cuyo sistema es “todos contra todos”
Seguimiento de Defectos
Una empresa se dedica al desarrollo y mantenimiento de software a medida para distintos clientes. Los
productos de software que se construyen son basados en Windows. En este último tiempo la empresa ha
tenido un crecimiento importante de la cartera de clientes y por consecuencia de la cantidad de productos
que desarrolla y debe mantener, la empresa ha decidido desarrollar un producto que le ayude a la
administración y seguimiento de los defectos identificados en los productos de software que desarrollan.
Es importante destacar que la empresa no realiza adaptaciones del producto puntuales para un cliente en
particular, si no que mantiene una única versión del producto. Esta versión del producto está compuesta por
módulos y cada módulo por un conjunto de funcionalidades (asociadas a una opción de menú en algún
punto del sistema). Las versiones del producto pueden variar en los módulos que contiene y dentro de cada
módulo en las funcionalidades disponibles. También puede pasar que dos versiones distintas de un producto
contengan el mismo módulo o la misma funcionalidad dentro de un módulo pero con versiones diferentes, es
por eso que se debe mantener información de las características y/o cambios asociados a cada versión tanto
del producto como de los módulos y funcionalidades que contienen.
Puede pasar que haya instaladas versiones diferentes de los productos en clientes diferentes, es por eso que
al momento de instalar un producto se registra que versión del mismo es la que se está instalando en cada
cliente. Si bien es cierto que cada producto tiene una única versión vigente en un momento de tiempo, puede
pasar que en un cliente se haya instalado una versión y luego el producto se modificó y a este cliente no se
le actualizó la versión.
Debido a lo explicado la empresa ha decidido desarrollar un proceso de seguimiento de defectos que se
adapte a sus necesidades. Con esto se pretende establecer un mecanismo, respaldado por un producto de
software, que permita gestionar los defectos encontrados y como consecuencia tratar de reducir la cantidad
de defectos que son detectados por los usuarios finales.
En caso que el usuario final detecte un defecto, podrá él mismo, informar acerca de su existencia por medio
de una página Web, a la que tendrá acceso utilizando una identificación de usuario y una palabra clave. La
disponibilidad debería ser permanente durante el horario de trabajo de la empresa, como así también durante
el horario de trabajo de sus clientes, los cuales están radicados en Argentina y en varios países de América
Latina.
El mismo sistema debería permitir registrar los defectos de todos los productos de software que están en
desarrollo y productos de software ya instalados en los distintos clientes.
Puede ocurrir que los clientes reporten los defectos mediante un archivo Excel, o mediante una aplicación
diferente. En estos casos el sistema deberá ser capaz de importar archivos Excel o un xml obtenido de otras
aplicaciones. Estos archivos deben ser leídos para registrar en el sistema los defectos detectados por el cliente.
La importación de estos archivos no debe demorar más de 30 segundos para 250 registros. Hay que tener en
cuenta que la forma de importar estos archivos es diferente, ya que requiere realizar una lectura al archivo
correspondiente según el formato del mismo.

class Domain Obj ects
Estado «entity» «entity» «entity»
TipoActuacion TipoDefecto
Prioridad Severidad
- descripcion - descripcion
- nombre - nombre: int - descripcion - descripcion
- nombre - nombre
- nombre
+ esTipoActuación() : void + esEstado() : void + esPrioridad() : void
+ getDescripcion() + getNombre() : void + esTipoDefecto() : void
+ getNombre() : void 0..1
+ getNombre() : void
1
+ setDescripcion() «entity» «entity»

1
Defecto Adjunto
«entity»
- actuacion: Actuacion - nombre
Actuacion
- adjunto: Adjunto 0..* - ubicacion
- descripción - descripcion
- estado: Estado - funcionalidad: VersionFuncionalidad
- fecha - prioridad: Prioridad
- hora - severidad: Severidad
- tipoActuación: TipoActuacion - tipoDefecto: TipoDefecto «entity» «entity»
- usuario: Usuario 1..* Funcionalidad Modulo
+ asignar() - descripción
+ concocerUsuario() + conocerActuacion() - descripción
«entity» - nombre - nombre
+ conocerEstado() Rol + conocerAdjunto() - versionModulo: VersionModulo
+ conocerTipoActuacion() + conocerFuncionalidad() - versionFuncionalidad: VersionFuncionalidad
+ new() - nombre + conocerPrioridad() + conocerVersionFuncionalidad() : void + esMódulo() : void
+ conocerSeveridad() + esFuncionalidad() : void + getFuncionalidad() : void
+ getNombre() + conocerTipoDefecto()
1 + getNombre() : void + getNombre() : void
+ setNombre() + corregir()
1
«entity» + crearActuación()
Usuario + new()
+ registrarResultado()
- apellido
+ verificar()
- nombre
- nombreUsuario
1..*
- password «entity»
- permisos: Permiso Personal «entity» 1 1..* «entity»
- rol: Rol Asignacion VersionModulo
- asignacion: Asignacion «entity»
+ conocerPermisos() - fecha VersionFuncionalidad - descripcion
1..*
+ conocerRol() : void + buscarAsignaciones() - numero
- versionProducto: VersionProducto - descripcion 1..*
+ esTuNombre() + conocerAsignacion() - versionFuncionalidad: VersionFuncionalidad
1 - vigencia - numero
+ esUsuario()
+ getUsuario() + estaVigente() + conocerFuncionalidadIntegran()
1..*
«entity»
1..* ReferenteCliente 1
«entity»
Permiso
VersionProducto Producto
- descripcion
1..* - descripción - descripcion
- nombre
«entity» - modulos: VersionModulo - nombre
Instalacion - número - version: VersionProducto
1..*
«entity» - fechaInstalacion - responsable: Personal
+ buscarVersionesHabilitada()
Cliente 1..* - responsableInstalacion: Personal 1
+ conocerModulosIntegran() : void + esProducto()
- domicilio - versionProducto: VersionProducto + conocerResponsableVersion() + getFuncionalidad()
- instalacion: Instalacion + estaHabilitada() + getModulo()
- razonSocial + conocerResponsableInstalacion() + getNombre()
+ conocerVersionProducto() + esVersion()
- referente: ReferenteCliente + getNumero() + getVersión()
42. Resolver la forma en que se comportará el sistema al momento de realizar importación de los archivos
de defectos, según se trate de un archivo Excel o de un XML. Modelar la vista dinámica de la
importación de un archivo Excel.
43. Resolver la manera en que se manejará uniformemente la estructura del producto de software, sus
módulos y sus funcionalidades. Mostrar la vista dinámica del acceso al producto, sus módulos y
funcionalidades al momento de importar un archivo de defectos.

Taller de reparación de autos
Un taller de la ciudad se encarga de la reparación integral de vehículos de marcas nacionales e importadas.

Las reparaciones integrales implican todo tipo de roturas, desperfectos y actividades de mantenimiento
mecánicas, eléctricas y electrónicas del automotor, quedando excluida la parte de chapa y pintura.
A continuación se describe en términos generales la operatoria del taller para que puedan determinarse los
requerimientos funcionales del sistema que se va a construir:
Cuando el Cliente se presenta en el taller por primera vez se registran sus datos personales. Del mismo modo
se registran los datos del vehículo. Puede pasar que un cliente tenga más de un vehículo o que lo cambie por
otro, en ese caso los datos del vehículo quedan desvinculados del cliente.
Cada vez que un cliente se presenta en el taller con algún vehículo que necesita alguna reparación o
mantenimiento, lo recibe el Encargado del Taller y valida si los datos del cliente y del vehículo están ya
registrados, en cuyo caso procede a generar una Orden de Trabajo en estado “Pendiente de Presupuesto”,
de lo contrario primero registra los datos.
En la Orden de Trabajo constan todas las cosas que el cliente identifica que el vehículo necesita (cosas que
no funcionan, ruidos, o mantenimiento necesario). También se registra el kilometraje del auto y el nivel de
combustible (aproximado si el vehículo no tiene medidor digital). De esta forma se realiza el ingreso del
vehículo a reparación. Dado que el taller tiene varios encargados que trabajan en diferentes turnos es
importante registrar quién fue el responsable de la registración de la orden de trabajo.
Una vez generada esa Orden de Trabajo, el vehículo queda en espera hasta tanto se pueda comenzar a
trabajar con él. En el momento que se empieza a trabajar con el vehículo lo primero que se realiza es un
diagnóstico para determinar cuáles son las reparaciones y/o actividades de mantenimiento necesarias para
completar el trabajo, los repuestos necesarios según la marca, modelo y variación del modelo, y se determina
el tiempo de demora aproximado que se registra en la orden de trabajo para informárselo al cliente. Desde
la Orden de trabajo se obtiene la información necesaria para generar el presupuesto ya que la orden de
trabajo contiene el detalle del trabajo que se considera que debe realizarse y los valores estimados tanto para
las actividades como para los repuestos. Cuando se genera el presupuesto la Orden de Trabajo pasa al
estado “Presupuestada”.
Si el cliente tiene registrado su mail y ha aceptado recibir notificaciones por esta vía el sistema le envía un
mail al cliente con el presupuesto estimado y el tiempo de demora aproximado. De lo contrario se lo ubica
por teléfono y se le comunica la información. El cliente puede aceptar o rechazar el Presupuesto de la Orden
de Trabajo. Si acepta el Presupuesto puede hacerlo en forma total o parcial, es decir aceptar algunos ítems
de la Orden de Trabajo y cancelar otros.
Cuando el Cliente confirma por algún medio (telefónicamente o por mail) el presupuesto presentado, la
Orden de Trabajo se considera “Aceptada”. Se puede comenzar el trabajo de reparación o mantenimiento
según corresponda del vehículo. El Responsable del Taller designa entonces al o los mecánicos que van a
trabajar en el vehículo, en ese momento la Orden de Trabajo pasa a estar “Abierta”.
Conforme cada uno de los mecánicos va realizando el trabajo que le fue asignado, registra el detalle de las
actividades realizadas, los repuestos y/o insumos utilizados (si correspondiera), asignando el estado
“Terminado” a los detalles de OT correspondientes. Una vez terminados los trabajos que fueran autorizados
por el cliente y que pudieron realizarse (se consiguieron repuestos por ejemplo), el Encargado del Taller valida
los montos sugeridos o los modifica si es necesario, determinando el valor real del trabajo, con lo cual la Orden
de Trabajo estará “Valorizada”. Luego el Encargado de Taller cierra la orden de trabajo, comunicándole al
cliente (telefónicamente o por mail, al igual que antes) que el vehículo está listo para que lo retire. Al momento
que el Cliente se presenta a retirar el auto se le entrega el mismo y se registra la orden de trabajo como
cobrada.
El cliente puede cancelar la Orden de Trabajo completa o alguno de sus detalles, siempre que ésta no haya
sido abierta todavía.

class Domain M odel
Vehiculo
Cliente - activo: boolean Modelo
VariacionModelo
- apellido - añoPatentamiento - descripcion
- cliente: Cliente - caracteristicasEquipamiento
- barrio: Barrio 0..1 - nombre
- color 1 - motorizacion
- calle - variacionModelo: VariacionModelo
- dominio - nombre
- celular
- fechaAlta - potencia 0..*
+ concocerVariacionesModelo() : void
- departamento
- email - variacionModelo: VariacionModelo + getNombre()
+ getNombre()
- nombre + mostrarModeloVehiculoCompleto() 0..*
1..* + conocerCliente()
- notificaViaMail: boolean
+ conocerOrdenTrabajo() 1..*
- numero
+ conocerVariacionModelo()
- piso
+ getDominio()
- telefono
+ mostrarDatosVehiculo() Marca
- vehiculo: Vehiculo
+ mostrarNombreCliente()
+ tiempoUltimaReparacion() - descripcion
+ conocerBarrio()
- modelo: Modelo
+ conocerVehiculo()
- nombre
+ getNombre()
0..*
+ conocerModelo()
1
OrdenTrabajo + getNombre()
Barrio - cantidadCombustible
- descripcion - descripcionTrabajoRequerido
- nombre - detalleOrdenTrabajo: DetalleOrdenTrabajo
Estado
- estado: Estado
- fechaCierre - ambito: Ambito
- fechaCreacion - descripcion: char
- horaCierre - nombre: char
- horaCreacion
+ getNombre()
- kmRecorridos
1 + new()
- notificadoPresupuesto: boolean
- notificadoTrabajoTerminado: boolean
- registro: Empleado 1
Empleado
- apellido + abrir()
- nombre + actualizarDetTerminValorizados()
- turno: TurnoTrabajo + actualizarEstado(Valorizada)
+ actualizarOTPtesTransferidas() Los métodos de seteo y
+ conocerTurnoTrabajo() + buscarDetalleOTTerminado() el constructor se
+ getNombre() + buscarDetallesCerrados() especifican para está
1 1 + buscarDetallesPendientes() clase unicamente,
+ calcularCostoTotal() aunque van en todas las
+ calcularCostoTotal() clases
+ calcularTiempoEstimado()
+ calcularTiempoResoluciónOT()
regi stro + cancelar()
1..* + cerrar()
+ cobrar()
TurnoTrabajo + conocerDetalleOrdenTrabajo()
- descripcion + conocerEstado()
- horaFin + crearDetalleOT()
- horaInicio + getDetallesActuados()
- nombre + getDetallesActuados()
+ getFecha() Repuesto
+ getFecha() - descripcion
+ getNombreEncargado() - nombre
+ getNumero() - precioReferencia
+ mostrarDatosOTSeleccionada() - variacionModelo: VariacionModelo
+ new()
+ notificar() + conocerVariacionModelo()
asi gnado
+ presupuestar() + getDatos()
+ registrarRespPresup() + getDescripcion()
+ setCostoHoraReal() + getNombre()
+ setEstado() Actividad + getPrecioReferencia()
+ tenesOTAbiertasConDetalleTerminado() + new()
- costoHora + setDescripcion()
+ valorizar() - descricpion
+ verTrabajosAutorizadosPorCliente() + setNombre()
- duracionEstimada + setPrecioReferencia()
- nombre
1
1..* + getDatos()
DetalleOrdenTrabajo 1
- actividad: Actividad
- asignado: Empleado
- autorizadoPorCliente: boolean
- costoHoraPresupuestado
- costoHoraReal
- duracionReal RepuestoRequerido
- estado: Estado - cantPresupuestada
- repuestoRequerido: RepuestoRequerido - cantRequerida
- tiempoEstimadoReparacion - precioPresupuestado
- tiempoRealReparacion - precioReal
- repuesto: Repuesto
+ abrir()
- utilizado: boolean
+ actualizarEstado(Valorizado) 0..*
+ asignarPrecioRealDeRepuesto() + conocerRepuesto()
+ buscarRepuestosUtilizados() + getDatos()
+ calcularCostoActividad() + setPrecioReal()
+ calcularMontoActividad() + seUtilizo()
+ cancelar()
+ cerrar()
+ conocerActividad()
+ conocerEmpleadoAsignado()
+ conocerEstado()
+ conocerRepuestoUtilizado()
+ estaPendiente()
+ estaTerminado()
+ getDetallesActuados()
+ new()
+ setValorHoraReal()
+ terminar()
+ transferir()
+ valorizar()
44. Resuelva la siguiente situación utilizando el patrón de diseño que corresponda: cómo debe
comportarse la Orden de Trabajo y el Detalle de Orden de Trabajo de acuerdo al momento en que se
encuentre cada uno.

Estaciones Agro-Meteorológica
Las estaciones meteorológicas rurales son un dispositivo que monitorea en forma continua los datos climáticos
que intervienen en el desarrollo de enfermedades en los cultivos (roya, hongos, oídios, gramíneas, orugas,
etc.).
Estos dispositivos tienen sensores que permiten registrar valores de distintas variables climáticas: temperatura,
humedad del aire, luminosidad, lluvias, hoja mojada, humedad del suelo, etc. Cada variable climática tiene
una unidad de medida única y una frecuencia de medición. Los sensores sólo pueden medir un determinado
rango permitido de acuerdo a la precisión del mismo.
Los sensores (pluviómetro, velocidad y dirección del viento, medidor de temperatura y humedad relativa, etc.)
se utilizan para obtener las mediciones de las variables climáticas que utilizará el método predictivo de un tipo
de pronóstico. Cada tipo de pronóstico predice una única enfermedad y es específico para un cultivo. Las
enfermedades detectadas por los pronósticos tienen diferentes grados de contagios, que definen el tipo de
severidad de la infección (leve, moderada o severa). El grado de contagio es determinado por el pronóstico
comparando los valores de las mediciones efectuadas a las variables climáticas y los valores de los parámetros
propios de cada grado de contagio de la enfermedad.
Cabe aclarar que cada parámetro tiene un valor o un rango de valores acerca de una única variable
climática. A la hora de generarse el pronóstico de acuerdo al tipo de evaluación (por valor o por parámetro)
del parámetro de un grado de contagio establece cómo debe evaluarse el mismo para determinar la
presencia de esa severidad de la enfermedad. Por lo tanto, el grado de contagio de una enfermedad se
determina por alcanzarse valores específicos o por estar comprendida en un determinado rango de valores
para los parámetros del pronóstico. Cabe aclarar, que cuando no se alcancen algunos de los valores de las
variables climáticas para un parámetro no existirá contagio de la enfermedad.
Las estaciones meteorológicas se instalan en distintas ubicaciones de una manera estratégica para poder
captar información con mayor precisión. Los pronósticos generados pueden ser almacenados para poder
consultar y comparar resultados a lo largo del tiempo y, de esta manera, poder sacar conclusiones más
exactas sobre la infecciones en los cultivos.

class Diag Clase Analisis CU Pronosticar Enfermedades de Cultivo
«boundary»
«entity» TipoSeveridad PantallaPronosticarEnfermedades
Parametro - nombre - comboTipoPronosticos
UnidadMedida VariableClimatica - descripcion + getNombre() - lblTipoPronosticos
+unidadMedida
- frecuenciaMedicion +variableClimatica - rangoDesde - lblUbicaciones
- nombre +tipoSeveridad 1
- nombre - rangoHasta - listaUbicaciones
- tipoUnidadMedida 1 1 - tipoEvaluacion
+ conocerUnidadMedida() +parametro + confirmarGeneraciónPronóstico()
+ getNombre() - valor + habilitarVentana()
+ getNombre() «entity»
+ compararValores() 1..* + mostrarResultadoPronóstico()
1 GradoContagioEnfermedad
+ conocerVblesClimaticas() + pedirImpresionPromostico()
«entity» + getTipoValuacion() + conocerTipoSeveridad() + pedirSelecciónCultivo()
+variableClimatica Medicion
TipoSensor + conocerVblesClimaticas() + pedirSelecciónTipoPronóstico()
- fecha +gradoContagioEnfermedad 1 + evaluarGradoContagio() + pedirSeleccionUbicaciones()
- nombre + seleccionarCultivo()
- hora 1..*
+gradoContagio
+ esParaVbleClimatica() 0..* - valor + seleccionarOpcionPronosticarEnfermedad()
1 + seleccionarPronóstico()
+ getFechaYHora()
+tipoSensor + seleccionarUbicación()
+medicion + getValor() «entity» + solicitarConfirmación()
TipoPronostico + tomarSelecciónImpresión()
«entity»
- descripcion
Pronostico +tipoPronostico - nombre
Sensor - fechaGeneracion
1 + conocerVbleClimatica()
- codigo - horaGeneracion + determinarSeveridad() «control»
- posicion - resultado + getDescripcion() GestorGeneracionPronostico
+ mideVbleClimatica() + new() + getNombre()
+ obtenerMedicionVbleClimatica() - cultivo
0..* - tipoPronosticoElegido
1..* +pronostico - ubicaciones
+cultivo
+sensor +enfermedad 1 + buscarMedicionesDeVbleClimatica()
«entity» + confirmarPronostico()
EstacionMetereologica 1
Cultivo + determinarVbleClimática()
Enfermedad
- codigo + evaluarPronostico()
- descripcion - nombre - nombre + finCU()
+ mideVlbeClimatica() + determinarSeveridad() + imprimirPronostico()
+ determinarVbleClimatica() + listarCultivos()
+ obtenerMedicionVlbeClimatica()
0..* + getNombre() + listarPronosticosParaCultivo()
+ listarTiposPronostico() + listarUbicaciones()
+ nuevoPronostico()
+estacionMetereologica
+ registrarPronostico()
Ubicacion
+ tomarCultivo()
- descripcion + tomarSeleccionPronostico()
- referencia + tomarUbicaciones()
+ getNombre() + validarEstacionesEnUbicaciones()
+ mideVbleClimatica() + verificarSensoresParaVbleClimatica()
+ obtenerMedicionesVbleClimatica()
+ poseeEstacionInstalada()
+ registrarPronostico()
45. Diseñar el procedimiento que permita recuperar los nombres y la descripción de los Tipos de Pronósticos
que aplican a un determinado cultivo.
46. Diseñar el algoritmo que utiliza la fórmula de predicción de cada Grado de Contagio de un Tipo de
Pronóstico para determinar la existencia y severidad de la enfermedad bajo estudio. Este algoritmo es
diferente para cada grado de contagio que posee el tipo de pronóstico, ya que determina la
existencia y severidad de la enfermedad.

Soluciones:
COMPLEJO DE 1. Resolver cómo la cola de impresión de la Interfaz de Impresión

deberá gestionar la reimpresión de la/s entrada/s cuando ocurra
CINES algún problema a la hora de imprimir éstas. Deberá restaurarse todos
los datos de la entrada a reimprimirse.
Nota: modelar sólo la dinámica para reimprimir la última entrada.
MEMENTO
2. Considerar una manera de recorrer las funciones de una

programación cuando se realiza la consulta de la misma.
ITERATOR
3. Resolver cómo se realizará la actualización de los cambios en la

programación vigente del complejo cuando se esté consultando la
misma en tiempo real. Considerar las distintas páginas Web que las
publican (en particular las que no pertenecen al complejo) y la
cartelera electrónica de cada cine.
OBSERVER
4. Establecer un proceso de creación de los diferentes medios para la

publicación de la programación vigente de cada cine y de sus
funciones. Los medios de publicación a considerar son la cartelera
electrónica y las páginas Web asociadas.
Nota: modelar sólo la dinámica para la publicación de la
programación en la cartelera.
BUILDER
5. Considerar la manera de tener un acceso controlado a los servicios

que brinda el subsistema de reservas, en lo que se refiere a la
generación, anulación y cancelación de reservas.
Nota: modelar sólo la dinámica de Anulación de Reservas.
FACHADA
6. Resolver cómo debe comportarse la función de acuerdo al

momento en que se encuentre la misma.
Nota: modelar la dinámica implicada en el contexto del C-U
“Registrar Venta de Entradas”.
STATE

Gestión de 7. Considerar la forma de trabajar de manera consistente la estructura

de organización de los avisos. Modelar la vista dinámica de la
Avisos búsqueda de avisos que no estén vencidos.
Clasificados COMPOSITE
8. Resolver el proceso de creación de los distintos tipos de avisos en el

momento de generar la visualización de la plantilla. Los tipos de
avisos posibles son Aviso de Texto Plano o Aviso con Diseño. Modelar
la dinámica para la creación de Aviso de Texto Plano.
BUILDER
Estación de 9. Resolver el comportamiento que debería asumir el expendedor en

función de las actividades que puede realizar en distintos momentos.
Servicios
STATE
10. Se pretende optimizar la utilización de la memoria, por lo que se

requiere resolver el problema de no crear instancias innecesarias de
los estados, si ya existe en memoria una instancia del mismo estado.
SINGLETON
11. Resolver como se realizará el cálculo de los importes parciales en el

momento de registrar el cobro, considerando que los cobros
parciales se calculan al registrarse el cobro de los consumos
pendientes de cobro, las prestaciones de servicio y los insumos
comprados por un cliente. Mostrar la dinámica del cálculo de un
cobro parcial de una prestación de servicio.
STRATEGY
12. Considerar para el momento de la obtención de reportes de

consumo de combustible, la manera de obtener los consumos que es
necesario incluir en el reporte.
ITERATOR
13. Solucionar el problema de cómo deshabilitar a los expendedores
abastecidos por un tanque cuando el mismo no tiene la cantidad de
combustible suficiente para abastecerlos.
OBSERVER

Tours 14. Considerar la manera de tener un acceso controlado a los servicios

que brinda el subsistema de hotelería, en lo que se refiere a la
diagramación de los tours y posterior contratación de los mismos.
Modelar la vista dinámica del acceso a la diagramación de los tours.
FACHADA
15. Resolver la forma en que al habilitarse las pantallas de diagramación,
modificación y consulta de la asignación de habitaciones se
muestran los componentes de la pantalla, considerando que los
componentes son los mismos para todas las pantallas pero se
muestran habilitados o deshabilitados según permitan o no la edición
los datos. Mostrar la vista dinámica de la pantalla de diagramación
de la asignación de habitaciones.
TEMPLATE METHOD (STRATEGY)
Transporte 16. Definir una estructura flexible que permita manejar de manera
sencilla la organización de corredores, recorridos y paradas del
Urbano de sistema de transporte público masivo.
Pasajeros COMPOSITE
17. Resolver la administración de un Cierre de Turno generado para el
caso que sea necesario restaurar el Informe de cierre si ocurre un
problema de impresión al momento de su emisión.
MEMENTO
Líneas Aéreas 18. Al cancelarse un vuelo el sistema deberá notificar automáticamente

esta situación a los distintos interesados (cartelera de publicación de
vuelos o pantalla de consulta del Sitio WEB de la aerolínea). Para ello
tendrá que diseñarse un esquema de notificación que sea genérico
y flexible para permitir informar en tiempo real y simultáneamente a
los distintos interesados. A su vez, este esquema tendrá que
proporcionar la información referente a la cancelación (fecha,
motivo, descripción y responsable) para los interesados que lo
requieran.
OBSERVER
Medidores de 19. Hallar la forma de recuperar las propiedades correspondientes a la

zona asignada a un captor mostrando para las mismas el número de
Agua Potable medidor asociado.
ITERATOR

Asignación de 20. Diseñar el comportamiento variable del método asignar() de la

solicitud en función de la situación en la que la misma se encuentre
Aulas
STATE
Importador de 21. Diseñar la generación del número único de solicitud de

reabastecimiento.
Insumos de Nota: Limitar la dinámica para sólo mostrar ese código en la pantalla.
computación SINGLETON
Elecciones 22. Definir una estructura flexible que permita manejar de manera
sencilla la jerarquía de la estructura geográfica.
COMPOSITE
23. Diseñar el comportamiento variable de la mesa dependiendo de la

situación en que la misma se encuentre.
STATE
Campeonato 24. Resolver el problema de lógica para buscar los participantes o los
equipos aptos para ser inscriptos en un campeonato determinado,
Náutico teniendo en cuenta cómo se realizará la búsqueda si el campeonato
es en equipo o es para participantes individuales.
NOTA: en el Diagrama de Secuencia enfocar el modelado en detalle
sólo para la búsqueda de los participantes aptos para ser inscriptos.
STRATEGY
25. Resolver la forma de recorrer y recuperar los campeonatos que aún

no se han corrido y mostrar las regatas, rutas y tipo de embarcación
asociados.
ITERATOR
26. Resolver el problema de creación de reportes tanto en pantalla,

impreso o exportado a un archivo. El reporte tendrá dos secciones: el

Sistema de encabezado (contendrá los filtros ingresados y la fecha de

generación) y el cuerpo (compuesto por los datos del informe).
Órdenes de NOTA: en el Diag. de Secuencia enfocar el modelado en detalle sólo
para la generación del reporte en forma impresa.
Trabajo de
BUILDER
Cortes de
Servicio
27. Diseñar el procedimiento de búsqueda de las órdenes de trabajo
que cumplan con los filtros elegidos para generar el reporte de
tiempos de ejecución de las OT.
ITERATOR
Stock de 28. Resolver la forma en la que se manejarán las variaciones de

comportamiento de la Orden de Compra, en función del momento en
Productos que se encuentre.
Lácteos STATE
29. Definir cómo se puede resolver la forma de establecer la relación
entre la forma de presentación y el tamaño que puede tener cada
uno de los productos.
BRIGDE
Contact 30. Resolver la necesidad de las búsquedas de las consultas de los
consumidores en función de los filtros elegidos para generar el
Center reporte.
ITERATOR
31. Definir el proceso de creación de las diferentes formas de
visualización del Reporte de Consultas de Consumidores.
BUILDER con FACTORY METHOD

Administradora 32. Resolver el comportamiento que puede asumir el Vacuno en función
al momento en el que el animal se encuentre.
de Tambo
STATE
33. Considerar la manera de tener un acceso controlado a los servicios
que brindan las clases relacionadas a la producción lechera, en lo
que se refiere a la registración, modificación, consulta, de la
producción lechera.
FACHADA

Auditorías 34. Resolver como el sistema va a calcular el promedio de retraso

considerando la totalidad de los días calendario y cómo en la
Internas ISO totalidad de los días hábiles.
STRATEGY
35. Resolver la necesidad de recorrer las acciones asociadas a un

hallazgo, al momento de generar el reporte de acciones vencidas.
ITERATOR
Restauración 36. Resolver la forma de controlar la asignación del número de

tratamiento generado para una solicitud de restauración, de manera
de Cuadros que el mismo no se repita.
SINGLETON
Corte de 37. Definir una estructura flexible que permita manejar de manera
sencilla y uniforme la estructura de la red de distribución de agua
Servicio potable. Modelar la vista dinámica de la búsqueda de las zonas
afectadas por un corte de servicio luego de haber seleccionado los
componentes afectados.
COMPOSITE
38. Resolver de manera controlada el acceso a los servicios que brinda
el subsistema de Gestión de Empleados, en lo que se refiere la
consulta de cargos, turnos de trabajo y horarios de capataces y
operarios de cuadrillas. Modelar la vista dinámica de la consulta
sobre los capataces disponibles para ser responsables del corte.
FACHADA
Simulador de 39. Se desea obtener la simulación de una compra previamente
realizada sin la necesidad de volver a ejecutar el proceso de
Compras simulación. De esta manera un usuario logueado podría acceder
nuevamente al resultado de una simulación que realizó en un
instante anterior sin necesidad de cargar nuevamente todos los
parámetros.
MEMENTO
40. Se desea acceder a las compras realizadas, que corresponden a la
tarjeta del cliente seleccionada, recorriendo las mismas
secuencialmente para obtener aquellas que corresponden al plan y
superan la fecha del último resumen.
ITERATOR

Liga de Fútbol 41. Resolver la forma en que el sistema deberá determinar la cantidad
de fechas y partidos que deberán jugarse para un campeonato en
función del sistema de campeonato elegido para ese campeonato.
Modelar la dinámica para un campeonato cuyo sistema es “todos
contra todos”
STRATEGY
Seguimiento 42. Resolver la forma en que se comportará el sistema al momento de
realizar importación de los archivos de defectos, según se trate de un
de Defectos archivo Excel o de un XML. Modelar la vista dinámica de la
importación de un archivo Excel.
STRATEGY
43. Resolver la manera en que se manejará uniformemente la estructura
del producto de software, sus módulos y sus funcionalidades. Mostrar
la vista dinámica del acceso al producto, sus módulos y
funcionalidades al momento de importar un archivo de defectos.
COMPOSITE
Taller de 44. Resuelva la siguiente situación utilizando el patrón de diseño que
corresponda: cómo debe comportarse la Orden de Trabajo y el
reparación de Detalle de Orden de Trabajo de acuerdo al momento en que se
encuentre cada uno.
autos
STATE
Estaciones 45. Diseñar el procedimiento que permita recuperar los nombres y la

descripción de los Tipos de Pronósticos que aplican a un
Agro- determinado cultivo.
Meteorológica ITERATOR
46. Diseñar el algoritmo que utiliza la fórmula de predicción de cada
Grado de Contagio de un Tipo de Pronóstico para determinar la
existencia y severidad de la enfermedad bajo estudio. Este algoritmo
es diferente para cada grado de contagio que posee el tipo de
pronóstico, ya que determina la existencia y severidad de la
enfermedad.
STRATEGY

TEMA: Evolución del Software – Cambios de Requerimientos
Consigna:
Para c ada uno de los siguientes c asos de estudio se requiere que se implemente el cambio
de requerimientos y en función de la situación planteada:
1. Enumere los casos de uso que se deberán agregar y/o modificar como consecuencia de la incorporación de
los cambios requeridos.
2. Realice los cambios correspondientes en el Modelo de Dominio (Diagrama de Clases)
Contact Center
Se trata de una empresa cuyo objetivo es proporcionar un “centro de atención multimedia como único punto de
contacto”, entre Clientes y consumidores. Contact Center ofrece diferente tipos de servicios tales como: Atención
al Consumidor, Mesa de Ayuda (Resolución de los problemas referidos a Tecnologías de Información), Tele
cobranzas (Gestión de cobranzas telefónicas a clientes morosos), Telemarketing (Promoción del portafolio de
productos y/o servicios para realizar ventas o suministrar información de productos nuevos o existentes), Tele
ventas (Venta y postventa de productos a través de llamadas telefónicas salientes o atendiendo llamadas
específicas), Estudios de Mercados y Encuestas (Para conocer el posicionamiento de los Clientes en el sector o en
la industria, la aceptación de sus productos, y el posicionamiento de la marca).
A continuación, se describe la operatoria de “Atención al Consumidor”; la cartera de Clientes de Contact Center en
este servicio incluye a empresas que fabrican o comercializan productos de limpieza, de consumo masivo (tales
como jabones líquidos, en polvo o en pastillas, anti manchas, suavizantes de ropa, etc.).
Contact Center cuenta con personal especialmente entrenado que brinda de manera oportuna respuestas
correctas a las consultas realizadas por los consumidores, homogenizando el mensaje de comunicación y el
tratamiento de la consulta.
Cada Cliente de Contact Center tiene una línea telefónica gratuita (0800) a través de la cual, los consumidores
pueden realizar consultas o solicitar información de un producto; es decir que cuando una persona se comunica
telefónicamente, la llamada ingresa a la central telefónica de Contact Center y dependiendo del número entrante
se deriva automáticamente a la célula de Representantes de Atención al Consumidor, capacitados para la atención
de consultas de ese producto específico (componentes o ingredientes utilizados, dosis recomendadas, formas de
uso, manera de eliminar manchas, etc.)
Cuando el Representante de Atención al Consumidor atiende una consulta, la registra en el sistema ingresando los
siguientes datos: tipo de consulta, criticidad, producto, nombre, apellido, domicilio y teléfono del consumidor,
descripción detallada de la consulta. El Representante de Atención al Consumidor analiza el requerimiento y valida
en la ayuda en línea la solución; en caso de poder solucionarlo comunica las acciones a realizarse al consumidor y
las registra en el sistema, cerrando la consulta como resuelta. Si no puede resolver la consulta, la deriva al Grupo
de Soporte de Producto (integrado por personal del Cliente) comunicando al consumidor: número de consulta,
tiempo estimado en el que se comunicará telefónicamente la solución, el cual va a depender del tipo de consulta.
Si existe algún problema técnico y no es posible derivar la consulta a alguno de los grupos resolutores
(Representantes de Atención al Consumidor o Grupo de Soporte de Producto), se le debe asignar el estado
Demorado (para evitar que siga sumando el tiempo de solución). Es relevante destacar, que una vez solucionado
el problema, el recurso que demoró la consulta (independientemente del grupo al que pertenezca), debe volverlo
al estado que tenía antes de demorarlo, para luego poder derivarlo.
Cuando un Analista de Soporte de Producto -que pertenece al Grupo de Soporte de Producto- recibe una consulta,
analiza si puede solucionarla. Si puede solucionarla responde la consulta registrando las acciones a implementarse;
si no conoce cómo solucionar esta consulta específica, describe un mensaje comentando esta situación y reenvía
en ambos casos, la consulta a los Representantes de Atención al Consumidor, para que se contacten
telefónicamente con el consumidor.
Con el fin de evaluar la calidad de atención y efectividad de las soluciones, Contact Center mantiene el detalle de
todas las acciones realizadas asociadas a una consulta por cada uno de los recursos involucrados, desde su
generación hasta su cierre. Asimismo, diariamente realiza el monitoreo de las llamadas de los Representante de
Atención al Consumidor, el cual se sintetiza en Informes semanales que son enviados al Cliente. Periódicamente,
también envía a cada Cliente un Reporte de Consultas de Consumidores, en el que se detalla los tipos de consultas
1
realizadas, tiempo de resolución, soluciones brindadas, porcentajes de llamadas solucionadas por los
Representantes de Atención al Consumidor y de llamadas derivadas al Grupo de Soporte de Producto.
Pedido de Cambio
Se necesita incorporar al software la funcionalidad relacionada con la registración y

posterior consu lta de respuestas y/o información predefinida que ay u darán a los
empleados del Contact Center con las respuestas que deben dar a las personas que se
comunican. Esta información y/o respuestas predefinidas dependen del tipo de con sulta y
del produ cto y el serv icio contratado por el cliente.
Vista del Modelo de Dominio

«entity»
Accion
«entity» descripcion
Estado nombre
descripcion estadoInicial conocerTipoRespuesta()
nombre 1 getNombre()
estado 1
accion 1
«entity»
Recurso «entity» «entity»
Actuacion TipoConsulta
fechaIngreso
legajo recurso descripcion descripcion «entity»
nombre fechaFin nombre
1 Producto
getNombre() fechaInicio
horaFin conocerTipoRespuesta() descripcion
getDescripcion()
horaInicio nombre
tiempoEstimadoResolucion getNombre()
setDescripcion() getNombre()
«entity» conocerAccion() setNombre()
NivelResolucion conocerEstadoActual() 1
descripcion conocerEstadoInicial()
conocerRecurso() 1
nombre
orden mostrarDatosActuacion()
tipoConsulta
getNombre()
actuacion 1..*
1 producto
«entity»
«entity» ServicioContratado
Consulta
fechaFin
apellidoConsumidor fechaInicio
nivelResolucion descricpion
direccionConsumidor concocerTipoRespuesta()
fechaCreacion conocerProducto()
nombreConsumidor conocerTipoServicio()
«entity» nroConsulta estaVigente()
Criticidad telefonoConsumidor consulta mostrarNombreProducto() servicioContratado
criticidad
tieneSACContrado()
descripcion buscarActuaciones()
nombre cerrar() 1..*
1 0..*
getNombre() conocerActuacion()
conocerCriticidad()
conocerNivelResolucion() tipoServicio
«entity»
conocerTipoConsulta() Cliente
demorar() 1
derivarGrupoSoporte() «entity» cuit
derivarRep() TipoServicio domicilio
guardarConsulta() razonSocial
informarCliente() descricpion
nombre conocerServicioContratado()
new() getCliente()
resolver() getNombre() mostrarSACVigente()
retomar()
sonTusParametros()
2
Importador de Insumos de computación

Arg-Computers es un a empresa que se dedica a la importación y venta de insumos de
computación en distintas ciu dades del país. Las ventas se realizan exclusivamen te a
mayoristas de la zona de cada sucursal.
La mecánica de la importación se da a partir de pedidos a prov eedores que se realizan
cuando el stock de los produ ctos se encuentra cercano al n ivel mínimo.
Se realiza el pedido al proveedor respectivo (proveedor oficial de cada marca de
productos, por ejemplo, Hewlett Packard o Samsung). El proveedor envía un acu se de recibo
(generalmente vía e - mail) para informar que el pedido ha sido correctamente recibido.
El proveedor analiza el pedido y luego envía un detalle de los productos que posee en ese
momento para poder cumplimentarlo (por lo cual el pedido realizado puede estar total o
parcialmente con firmado de envío); los restantes productos del pedido son envia dos en el
lapso de 15 días (parte del convenio entre Arg -Computers y sus proveedores). Finalmente, al
momento de la recepción de los productos enviados, se registra la cumplimentación total o
parcial del pedido.
Un pedido realizado a los proveedores puede cancelarse en cualquier momento, sólo si no
se ha recibido n inguna entrega del mismo (es decir, no existe cumplimentación total o parcial
del pedido). Es necesario contar con información de todos los estados por los que transcurre
el pedido y sus tiempos de permanencia asociados.
La venta a los distribuidores se in icia cuando éstos realizan solicitudes de
reabastecimiento desde la página web de la empresa, donde también pueden consu ltar el
nivel de stock de cada producto y la fecha de reposición de aquello s que están en falta. Los
precios de venta a los distribuidores dependen de la categoría a la que están asociados, la
cual a su vez depende del nivel de compras que realicen a la empresa. Estas ventas concluyen
cuando Arg-Computers entrega la totalidad de los produ ctos correspondientes a las
solicitudes de reabastecimiento. La modalidad de entrega puede ser total o parcial, lo que
implica en el primer caso que la solicitud de reabastecimiento se cumplimenta en una única
entrega. En el caso de la entrega par cial la solicitud de rea bastecimiento se cumplimenta en
diferentes entregas conforme se tenga disponibilidad de los mismos, en este ú ltimo caso se
incrementa el costo de envío, dado que es más de uno. Esto es elección del Distribuidor en
función de la urg encia que tenga para recibir los produ ctos.
Cabe aclarar que Arg -Computers vende tanto los productos que importa como equ ipos
completos que arma a partir de los mismos. Estos equ ipos armados son vendidos a un precio
más bajo que si se compraran los product os que los conforman por separado. En este caso
los equ ipos armados se consideran como otro producto diferente.
Pedido de Cambio
Se solicitó que el stock se administre por sucursal para mejorar el tiempo de

las entregas a los mayoristas de cada región d el país. Por lo tanto, cada
distribuidor dependerá de una única sucursal y la disponibilidad de productos
a la hora de concretar una solicitud estará dada por el stock de esa sucursal.
3
Diagrama de Clases de análisis
4
Agencia de Turismo
Una agencia de turismo se dedica a armar tours por Europa donde el traslado durante el tour y los hoteles en cada
ciudad visitada. Además, se incluyen algunas excursiones para cada ciudad incluida en un tour. La agencia tiene
definidos tours de una duración fija, a partir de los cuales se organizan viajes con diferentes fechas de salida.
Un tour tiene previamente definidos un conjunto de hoteles que se pueden ocupar en cada ciudad. En el momento de
definir un viaje se decide cuál de los hoteles disponibles será ocupado y en qué habitación se ubicará a cada pasajero.
Para esto se tiene en cuenta si los pasajeros vienen en grupos de amigos y/o familiares, y qué capacidad de habitación
solicitaron (una pareja con un hijo solicita una habitación triple, dos amigos solicitan una habitación doble con camas
separadas, etc.). Cabe aclarar que en el caso de que un pasajero solicite una habitación simple, ésta tiene un costo
extra.
Para realizar un viaje se arman grupos de pasajeros a los cuales se les asigna un colectivo y un chofer. Puede ocurrir
que se cambie de chofer y/o de colectivo en alguna ciudad del viaje.
En el momento en que se diagrama un viaje de un tour se debe asignar un guía que acompañe a los pasajeros en cada
ciudad a visitar.
La diagramación de un viaje incluye además la asignación de guías locales (además del guía que acompaña a los
pasajeros durante el viaje) en algunas excursiones de las distintas ciudades visitadas. Algunas excursiones requieren
de recursos especiales como ser auriculares para escuchar a los guías o vestimenta particular. Puede ocurrir que ciertas
excursiones no se puedan realizar si no se dan las condiciones necesarias (buen tiempo, disponibilidad de lugares
ajenos a la agencia de turismo, entre otros).
Pedido de Cambio:
Se ha solicitado implementar un cambio para contemplar la definición de los

restaurantes con los cuales se podrá brindar el servicio de media pensión. Se pide que el
sistema permita establecer en la definición del tour para cada día, en cada ciudad; si la
media pensión corresponde a almuerzo o cena y en qué restaurantes es posible comer.
Autores: Covaro – Massano - Meles 5

Diagrama de Clases de Análisis
class Domain Model

pasajerosAcompañantes
0..* «entity»
HabitaciónContratada
«entity»
Pasajero - cantidadCamasDosPlazas
«entity» - cantidadCamasUnaPlaza
- dni habitación - capacidad
Grupo - domicilio
pasajeros - esReferente 1..* + esDeFechaDeTour(): void
- asignado
1..* - nombre + getCapacidad(): void
- fechaCreación
- teléfono + ocupar(): void
+ getDatosGrupo(): void - tieneAcompañantes: int
+ ocuparHabitaciones(): void ciudadDeHabitación 0..*
+ contarHabitaciones(): void
0..* + getDatosPasajeroReferente(): void
+ ocuparHabitaciones(): void ocupaciónDeHabitaciones
habitaciónAsignada
grupos + tieneAcompañantes(): void
0..1
1 «entity»
«entity» HabitaciónHotel
Tour «entity»
DetalleTour - cantidadCamasDosPlazas
- fechaRegreso - cantidadCamasUnaPlaza
- fechaSalida - fechaLlegada - capacidad
detalles
+ buscarHotelesDeViaje(): void + getFecha(): void + estáLibre(): void
1..* + getFechaLlegada(): void
+ esMayorQueFechaActual(): void + getCapacidad(): void
+ getDatos(): void + getHotel(): String + ocupar(): void
+ mostrarFechasdeLlegadaViaje(): void + ocuparHabitacionesDeHotel(): void
+ mostrarGrupos(): void 1..*
+ ocuparHabitaciones(): void
+ tienePasajeros(): void hotelReservado habitaciones
detalleDefiniciónTour
0..*
0..1
1 «entity»
«entity» Hotel
DetalleDefiniciónTour - descripción
definiciónTour tour
- cantidadDías - nombre
- orden + buscarHabitacionesLibresParaFechas(): void
+ getCantidadDías(): void + getHabitaciones(): void
+ getCiudad(): void + getNombre(): String
+ getHotel(): void + ocuparHabitaciones(): void
detalles ciudad 0..*
1 1..*
1 hoteles
«entity»
DefiniciónTour «entity»
Ciudad
- duraciónDías
- nombre - nombre
- tour + getNombre(): void
+ buscarFechasDisponsibles(): void
+ buscarHotel(): void
+ getFechasDisponiblesConPasajeros(): void
+ getNombre(): void
+ mostrarFechasLlegada(): void
+ mostrarGrupoDePasajeros(): void
+ ocuparHabitaciónPorPasajeros(): void

Software para la Gestión de Evaluaciones de Desempeño

Una reconocida empresa de la ciudad de Córdoba necesita un software que le permita administrar las evaluaciones
de desempeño que anualmente se le realizan a su personal. A continuación, se describe la operatoria de negocio para
la cual se espera que el software satisfaga los requerimientos.
Anualmente el Gerente de RRHH define la plantilla de evaluación a utilizar, pudiendo decidir continuar utilizando la
vigente de años anteriores o bien definir nuevas. Esta plantilla contiene la información de cada una de las
competencias a evaluar (por ejemplo, Trabajo en Equipo, Proactividad, Gestión del Capital Humano), las cuales
pueden ser variables por puesto (por ejemplo, Jefe, Gerente, Analista) y pueden o no dividirse en Sub-competencias.
Para cada competencia de menor nivel se definirán comportamientos posibles, cada uno de los cuales tendrá asociado
un grado (valoración cualitativa) que se corresponderá con una valoración numérica para esa competencia.
A continuación, se muestra un ejemplo:

Competencia: Trabajo en Equipo
Comportamientos Grado Valoración
Numérica
- Coopera y colabora con personas dentro o fuera de su área, buscando inducir el mismo A 100%
comportamiento en los demás.
- Acepta todas las opiniones incluso las contrarias a la propia. Expone con respeto la suya.
- Ante una situación de divergencia, invita a transformar la disputa en una oportunidad de
aprendizaje.
- Coopera y colabora con personas dentro o fuera de su área. B 75%
- Intercambia opiniones e información con todas las personas con las que interactúa.
- Ante una situación de divergencia, mantiene el dominio de sí mismo y hace preguntas
orientadas a compartir hechos, datos, intereses y expectativas sobre las que la otra persona
basa su razonamiento.
- A solicitud, coopera y colabora con personas dentro o fuera de su área. C 45%
- Selecciona con quién intercambia opiniones e información y ante una situación de divergencia
le cuesta escuchar a la otra persona y controlar sus emociones, buscando hacer prevalecer su
postura.
- Aunque se lo soliciten no coopera ni colabora con personas dentro o fuera de su área. D 15%
- Ante una situación de divergencia no escucha a los demás, reacciona emocionalmente y no
mide el impacto negativo que sus palabras y/o actitud causan en el trabajo del equipo.
A su vez, cada competencia de menor nivel definida asumirá un peso dentro de la evaluación final, el cual también
puede ser variable en función del puesto y de las competencias que la plantilla tiene asociadas para el mismo.
Una vez definidas las plantillas y llegado el momento de realizar las evaluaciones de desempeño, el Responsable del
Área de Desarrollo de RRHH genera las evaluaciones para todo el personal, informando el período a evaluar y el plazo
de tiempo asignado para realizar las evaluaciones. En función de esta información el sistema deberá generar las
evaluaciones de desempeño para todos los empleados, teniendo en cuenta que tanto el evaluado como los
evaluadores deben tener una antigüedad mínima requerida en el puesto, para el Período de Evaluación que se está
evaluando (caso contrario no puede realizarse la evaluación)
Para cada evaluación se asociará la siguiente información:
• Datos del Evaluado (cada uno de los empleados a los que se realizará la evaluación de desempeño): legajo,
apellido y nombre y puesto en el que se lo evalúa (por ejemplo, Analista o Jefe), sector en el que se lo evalúa,
antigüedad en el puesto, fecha de ingreso a la empresa)
• Datos del Evaluador (superior inmediato del evaluado en el período en el que se lo evalúa): legajo, apellido y
nombre y puesto.
• Competencias y Sub-competencias a Evaluar y comportamientos posibles asociados a cada una de ellas

Una vez generadas las evaluaciones, las mismas deberán ser realizadas por cada evaluador antes de su vencimiento.
Esto implica que el mismo deberá completar en el sistema los resultados de cada evaluación a su cargo (grado para
cada comportamiento en cada competencia y las secciones de comentarios). Con esta información el sistema deberá
calcular la Evaluación Final, que surge de multiplicar las calificaciones numéricas asociadas a los valores seleccionados
por el peso de incidencia de la competencia a la que dicho valor corresponde.
Pedido de Cambio
Adicionalmente a la funcionalidad solicitada, se requiere ampliar las funcionalidades para la

Gestión del Desarrollo del Personal. Para esto se solicita que al momento de definir un
Puesto de Trabajo puedan especificarse los conocimientos y competencias requeridas u
opcionales. Esto permitirá facilitar las tareas de selección de personal y mejorar la Gestión
de las Evaluaciones de Desempeño.
La nueva información a registrar asociada al puesto de trabajo se detalla a continuación:
a) Conocimientos Generales y Específicos requeridos para el puesto y el nivel requerido de
cada uno de ellos.
b) Competencias requeridas para el puesto y el nivel requerido para cada una.

class Modelo Analisis
«boundary»
«control»
PantRegResultadoEvaluacion
GestorRegResultadoEvaluacion
- comentarioFinal
- comentarioFinal
- evaluacionFinal
- listadoCompetencias - competenciaSeleccionada
- comportamientoSeleccionada
- listadoEvaluaciones
- estadoPteCargaResultado
- observaciones
- estadoRegNvoResultado
- opcionCancelar
- evaluacionesPtes
- opcionConfirmar
- evaluacionFinal
+ confirmarResultados() - evaluacionSeleccionada
+ confirmarResultadosFinal() - evaluado
+ habilitarVentana() - evaluador
+ ingresarComentarioFinal() - observaciones
+ ingresarObservaciones()
+ buscarEstadoRegResultado()
+ mostrarEvaluacionFinal()
+ opcionRegResultadoEvaluacion() + buscarEvaluacionesPtes()
+ buscarEvaluacionesPtesEvaluador()
+ pedirSeleccionCompetencia()
+ calcularEvaluacionFinal()
+ pedirSeleccionComportamiento()
+ pedirSeleccionEvaluacion() + finCU()
+ mostrarCompetenciasAEvaluar()
+ seleccionarCompetencia()
+ mostrarComportamientosAsociados()
+ seleccionarComportamiento()
+ mostrarDatosEvaluacion()
+ seleccionarEvaluacion()
+ nuevoResultadoEvaluacion()
+ solicitarConfirmacion()
+ solicitarConfirmacionFinal() + obtenerEvaluador()
+ registrarEvaluador()
+ solicitarIngresoComentarioFinalEv()
+ registrarResultados()
+ solicitarIngresoObservaciones()
+ tomarComentarioFinal()
+ tomarConfirmacion()
+ tomarConfirmacionFinal()
+ tomarIngresoObservaciones()
+ tomarSeleccionCompetencia()
+ tomarSeleccionComportamiento()
«entity»
+ tomarSeleccionEvaluacion()
PlanillaEvaluacion
+ validarCumplimientoObjetivos()
- descripcion
- fechaAlta
- nombre
- vigenciaDesde
- vigenciaHasta
+ conocerDetallePlantillaEvaluacion()
+ conocerPuesto()
+ mostrarCompetencias() «entity» «entity»
+ mostrarComportamientoCompetencias() «entity»
Estado Sesion
+ mostrarSubcompetencias() Evaluacion
- descripcion - fecha
1 - fecha
- nombre - hora
- periodoAEvaluar
-detallePlantEvaluac -plantillaEvaluacion
- valorEvaluacionFinal + esEstadoRegResultado() + conocerUsuario()
1..* - vencimiento + esPteCargaResultados() + obtenerEmpleado()
-detallePE «entity» + getNombre()
+ buscarEstadoActual()
DetallePlanillaEvaluacion + conocerAprobador()
1
- ponderacion + conocerEvaluado()
0..* + conocerEvaluador()
+ conocerCompetencia() + conocerHistorialEvaluacion() -usuario
+ conocerComportamientoPlantilla() + conocerPlantillaEvaluacion() «entity»
+ conocerResultado() -historialEvaluacion HistorialEvaluacion
+ getValoracionNumerica()
+ esDeEvaluador() «entity»
+ mostrarCompetencias() - fecha
+ estaPteCargaResultado() Usuario
+ mostrarComportamiento() - hora
+ mostrarComportamientoAsociado() + getPeriodoEvaluar() 1..* - observaciones - contraseña
+ mostrarSubcompetencias() + getVencimiento() - nombre
+ mostrarCompetenciasAEvaluar() + conocerEmpleado()
1 + mostrarComportamientoCompetencia() + conocerEstado() + obtenerEmpleado()
-competencia
1 + mostrarDatosEvaluacion() + esEstadoActual() 1
+ mostrarDatosEvaluado() + new()
«entity» + mostrarDatosEvPtes() -usuario
Competencia + mostrarPuestoEvaluado()
+ mostrarSubcompetencias()
- descripcion
+ registrarResultadosEvaluacion()
- nombre
+ setEstado() -evaluador
+ getDescripcion()
+ getNombre() -empleado
+ mostrarDatosCompetencia() -detallePlantillaEvaluacion
1
«entity»
-comportamientoPlantilla Empleado
1..* 1
- apellido
-resultado - fechaIngreso
«entity» 0..* -ocupacionPuesto
ComportamientoPlantilla 1 -aprobador - legajo
«entity» 1 - nombre
- valoracionNumerica Resultado «entity»
+ conocerLugarFisico()
+ conocerComportamiento() - comentarios OcupacionPuesto
+ conocerModalidadContratacion()
+ getValoracionNumerica() - fechaOcupacion -ocupacionPuesto + conocerOcupacionPuesto()
+ mostrarComportamiento() + new() + conocerTurno()
+ conocerPuesto() + conocerUsuario()
-comportamiento 1 + conocerSector() + getApellido()
+ getFechaOcupacion() -empleado + getLegajo()
«entity» + mostrarPuestoEvaluado()
Comportamiento + getNombre()
1 + mostrarDatosLaborales()
- descripcion + mostrarLugarFisico()
- grado + mostrarTurno()
-lugarFisico
+ getDescripcion()
+ getGrado() -sector «entity»
+ setDescripcion() 1 LugarFisico 1
+ setGrado() «entity» - descripcion
Sector - nombre -modalidadContratacion
-puesto
- telefono
-puesto - descripcion
- nombre + getNombre() 1
1..* 1 -turno
«entity»
«entity» 1
ModalidadContratacion
Puesto
«entity»
- descripcion
- descricpion Turno
- nombre
- nombre
- descripcion
- vigenciaDesde
- horaEntrada
- vigenciaHasta
- horaSalida
+ getNombre() - nombre
+ getNombre()

Avisos Clasificados
En una localidad del interior de la provincia de Córdoba funciona desde hace más de 25 años un importante
semanario llamado “Tribuna”. Dicho semanario sale a la calle los días sábados, cubriendo las noticias y
sucesos de la localidad y región. El semanario está dividido en distintas secciones: Deportes, Regionales,
Sociales, etc. Como es un semanario local y no se cuenta con una gran infraestructura y maquinaria, se
imprime de a partes, comenzando con esta tarea los días miércoles, por lo que hay secciones que deben
estar preparadas para éste día.
A continuación, se describirá la gestión de clasificados. La recepción de clasificados puede ser vía telefónica,
personalmente en las distintas receptorías de la localidad y región o, solamente para algunas empresas que
hace bastante tiempo publicitan en el semanario, se hacen recepciones vía e-mail.
Las publicidades pueden aparecer en la sección clasificados o en otra sección del semanario, como por
ejemplo, una importante casa de venta de ropa deportiva puede elegir que su publicidad aparezca en la
sección deportes. Los avisos que se publican en la sección “Clasificados”, están a su vez diferenciados en
distintas categorías y a su vez cada categoría puede o no tener sub categorías. Por ejemplo, la categoría
“Profesionales” se subdivide en Oncología, Abogacía, Odontología, etc.la de “empleos y ocupaciones” en
pedidos y ofrecidos, pero la categoría de “Servicios” no tiene ninguna sub categoría. El orden de las
categorías en la edición impresa tiene un orden establecido, pero, eventualmente éste orden puede
alterarse. El aviso puede ser de texto plano o puede tener alguna imagen (en ese caso, el cliente debe enviar
el diseño del aviso) y, por política del Semanario, no en todas las categorías y sub categorías se puede publicar
cualquier tipo, por ejemplo, en la categoría “Empleos” no se admiten los avisos con el logo del
comercio/empresa/organización que solicita. El precio del aviso varía según el tamaño, el tipo, el formato y
la cantidad de sábados que aparecerá publicado, y esto está previamente definido. Los formatos están
predefinidos, tienen un nombre distintivo y definen qué fuente tendrá el aviso y el tamaño, cuál será el
espaciado (anterior, posterior, interlineado), cantidad de palabras en mayúscula, y otros efectos como
cursiva, negrita y subrayado. No todas las combinaciones de espaciado, fuente, tamaño y efectos son
posibles, debido a que hay fuentes que no admiten efectos o que dificultan la diagramación de la hoja con
determinados interlineados. El mínimo es de dos líneas, con la primer palabra en mayúscula publicado dos
sábados consecutivos. De allí existe muchas variantes, por ejemplo igual que el anterior pero con la primer
palabra en mayúscula y negrita, o todo el aviso en negrita con tres líneas y publicado tres sábados
consecutivos, etc. Un aviso como máximo puede publicarse 15 sábados consecutivos. Si algún cliente desea
extender éste plazo, deberá presentarse nuevamente en la fecha correspondiente y volver a solicitarlo como
si fuera un nuevo aviso. En el caso de los avisos con imagen o diseño, pueden ocupar una o dos columnas y
en caso de que el aviso exceda éste tamaño, se considera como publicidad y se cobra como tal. Cada aviso
tiene una fecha de vencimiento, que es publicada junto al aviso en cada edición. La fecha de vencimiento se
calcula a partir de la cantidad de sábados por los que fue solicitado el aviso, y corresponde a la fecha del
último sábado que el avisó aparecerá publicado.
Cuando el receptor del aviso registra un nuevo aviso, debe registrar todas las características del aviso,
incluido el texto, la fecha de recepción y fecha de vencimiento, forma de pago (tarjeta de débito, tarjeta de
crédito o efectivo), y se imprime el ticket correspondiente.
El director de Tribuna está interesado en implementar un sistema para la gestión de los clasificados para
poder llegar sin problemas a la impresión del día miércoles, cumpliendo con el funcionamiento descripto
anteriormente.

Pedido de Cambio
Se ha solicitado implementar un cambio debido a que el dueño pretende implementar un

sistema de promociones. Pueden existir promociones para: la categoría a la que pertenece el
aviso, o según la receptoría a la que el cliente se dirige. Dichas promociones consisten en un
porcentaje de descuento sobre el precio del aviso. Cabe aclarar que sólo se podrá aplicar una
única promoción a la vez (las promociones no son acumulables).
a) Enumerar los casos de uso que se deberán agregar y/o modificar
b) Realizar los cambios correspondientes en el diagrama de clases

Propuestas de Solución:
Contact Center
Modelo de Dominio con cambio de requerimientos

class Modelo con Cambio REQS
Actuacion Accion
descripcion descripcion
«entity» estadoInicial fechaFin nombre
Estado fechaInicio accion
1 horaFin conocerTipoRespuesta()
descripcion 1 getNombre()
nombre estado horaInicio
tiempoEstimadoResolucion
1
conocerAccion()
conocerEstadoActual()
conocerEstadoInicial()
conocerRecurso() «entity»
«entity» TipoConsulta
mostrarDatosActuacion()
Recurso tipoRespuesta
recurso descripcion «entity»
1 TipoRespuesta
fechaIngreso nombre
legajo actuacion 1..*
conocerTipoRespuesta() 0..1 descripcion
nombre nombre
getDescripcion()
getNombre() getNombre() valida
setDescripcion() tipoRespuesta
esValida()
setNombre() 0..*
getDescripcion()
«entity» getNombre()
NivelResolucion 1 setDescripcion()
setNombre()
descripcion tipoConsulta
nombre 0..*
orden tipoRespuesta
getNombre() nivelResolucion «entity»
Consulta
1
apellidoConsumidor
descricpion «entity»
direccionConsumidor Producto
fechaCreacion descripcion
nombreConsumidor nombre
nroConsulta «entity» producto
telefonoConsumidor ServicioContratado getNombre()
1
buscarActuaciones() fechaFin
cerrar() consulta fechaInicio
«entity»
Criticidad criticidad conocerActuacion() concocerTipoRespuesta()
conocerCriticidad() «entity»
0..* conocerProducto() tipoServicio
descripcion conocerNivelResolucion() TipoServicio
1 conocerTipoServicio()
nombre conocerTipoConsulta() descricpion
estaVigente() 1
getNombre() demorar() mostrarNombreProducto() nombre
derivarGrupoSoporte() tieneSACContrado()
derivarRep() getNombre()
guardarConsulta()
informarCliente() 1..*
new() «entity»
resolver() Cliente
retomar()
sonTusParametros() cuit
domicilio servicioContratado
razonSocial
conocerServicioContratado()
getCliente()
mostrarSACVigente()
Casos de uso que se agregan: Casos de uso que se modifican:
Registrar Tipo de Respuesta Registrar servicio contratado

Modificar Tipo de Respuesta Modificar servicio contratado
Eliminar Tipo de Respuesta Consultar servicio contratado
Consultar Tipo de Respuesta Eliminar servicio contratado
Registrar consulta
Brindar información de consultas

Importador de Insumos de Computación
Cambios en el Modelo de Casos de Uso
Casos de Uso Nuevos

Registrar Sucursal
Modificar Sucursal
Buscar Sucursal
Consultar Sucursal
Eliminar Sucursal
Casos de Uso Modificados
Registrar Solicitud de Reabastecimiento
Registrar Distribuidor
Registrar Remito de Proveedor
Cambios en la Estructura del Modelo Análisis

Sistemas de Órdenes de Trabajo de Cortes de Servicio
Cambios en los Casos de Uso
Casos de Uso Nuevos

Registrar Tipo de Tarea, Modificar Tipo de Tarea, Consultar Tipo de Tarea y Eliminar
Tipo de Tarea
Casos de Uso Modificados
Registrar Resultado de OT de Corte
Registrar Resultado de Inspección
Registrar Resultado de Reconexión
Registrar Tipo de Orden de Trabajo, Modificar Tipo de Orden de Trabajo, Consultar
Tipo de Orden de Trabajo y Eliminar Tipo de Orden de Trabajo
Cambios en la Estructura

Agencia de Turismo
Funcionalidad
Casos de uso que se agregan:
Registrar restaurante
Modificar restaurante
Consultar restaurante
Eliminar restaurante
Buscar restaurante (opcional)
Diagramar Media Pensión de Tour
Modificar Diagramación de Media Pensión de Tour
Consultar Diagramación de Media Pensión de Tour
Casos de uso que se modifican:

Diagramar Tour (nota: si se modifica este caso de uso no se agregaría el caso de uso Diagramar Media Pensión de
Tour)
Modificar Diagramación de Tour (nota: si se modifica este caso de uso no se agregaría el caso de uso Modificar
Diagramación de Media Pensión de Tour)
Consultar Diagramación de Tour (nota: si se modifica este caso de uso no se agregaría el caso de uso Consultar
Diagramación de Media Pensión de Tour)
Estructura

Cambio de Requerimiento de Evaluación de Desempeño
Funcionalidad
Casos de Uso que se agregan: Registrar Conocimiento
Registrar Conocimiento Modificar Tipo de Conocimiento
Modificar Conocimiento Eliminar Tipo de Conocimiento
Eliminar Conocimiento Consultar Tipo de Conocimiento
Consultar Conocimiento
Registrar Competencia Casos de uso que se modifican:
Modificar Competencia Registrar Puesto de Trabajo
Eliminar Competencia Modificar Puesto de Trabajo
Consultar Competencia Consultar Puesto de Trabajo
Estructura
class Cambio Rqs
PlanillaEvaluacion
descripcion
fechaAlta Competencia
nombre descripcion
vigenciaDesde nombre
vigenciaHasta
getDescripcion()
conocerPuesto() getNombre()
mostrarCompetencias() mostrarDatosCompetencia()
mostrarComportamientoCompetencias()
mostrarSubcompetencias() 1
puesto 1..* competencia

Puesto
descricpion
OcupacionPuesto nombre
fechaOcupacion vigenciaDesde
vigenciaHasta
conocerPuesto() puesto
conocerCompetenciaPuesto()
conocerSector()
getFechaOcupacion() 1 conocerConocimientoPuesto()
mostrarPuestoEvaluado() getNombre()
mostrarCompetenciasRequeridas()
mostrarConocimientosRequeridos()
conocimientoPuesto 0..* competenciaPuesto 0..*

sector ConocimientoPuesto
CompetenciaPuesto
1 requerido requerido
Sector conocerConocimiento() conocerCompetencia()
nombre conocerNivel() conocerNivel()
descripcion
nivel
nivel 1
Nivel
conocimiento 1 nombre
1 descripcion
tipoConocimiento
Conocimiento
TipoConocimiento
nombre
nombre 1 descripcion
descripcion conocerTipoConocimiento()

Avisos Clasificados
Casos de Uso que se agregan:
Registrar promoción
Modificar promoción
Anular promoción
Consultar promoción
Casos de uso que se modifican:
Registrar Aviso
Modificar Aviso
Registrar Cobro de Aviso
class Cambio de Re que rimie nto
Se agrega el puntero a «entity»

"Promocion" y un método Aviso
calcular precio, que en estado
caso de tener fechaDePrimerSabado
promociones, aplica el fechaDeRecepcion
descuento fechaDeVencimiento
«entity» correspondiente al precio texto
Receptoria registrado buscarFormato()
nombre receptoria calcularPrecio()
numero 1 conocerDiseñoAdjunto()
ubicacion conocerEstado()
receptoria 0..* conocerPrecioAviso()
conocerPromocion()
promocion conocerReceptoria()
Promocion estaVencido()
porcentajeDto getParametroOrdenamiento()
vigenteDesde 0..1 getTexto()
vigenteHasta
0..* verificarTipoAviso()
verificarVencimiento()
conocerCategoria()
conocerReceptoria() aviso
categoria
«entity» precioAviso 1
Categoria «entity»
descripcion PrecioAviso
nombre cantColumnas
0..*
numOrden cantLineas
ubicacion fechaVigenciaDesde
buscarAvisos() monto
categoria
buscarDatosAvisos() buscarFormato()
buscarFormartoAvisos() 0..1 conocerCategoria()
buscarSubcategorias() conocerFormato()
conocerAviso() conocerSubcategoria()
conocerSubcategoria() conocerTipoAviso()
conocerTipoAviso() esTipoDeAvisoDiseño()
getNombre()
getNumeroOrden()
listarSubcategoria()
ordenarAvisos()
tieneSubcategoria()
verificarTipoAviso()

Guía de Casos Prácticos sobre Modelado con

Diagrama de Máquina de Estados
Edición y compilación: Judith Meles

Contenido
Agua Puntos Fijos ........................................................................................................................................ 3
Consigna: ................................................................................................................................................... 3
Presentación del caso: ............................................................................................................................ 3
Solución propuesta .............................................................................................................................. 8
Auditoría Médica de Órdenes ................................................................................................................... 10
Consigna: ................................................................................................................................................. 10
Presentación del caso: .......................................................................................................................... 10
Congreso de Informática y Tecnología ................................................................................................... 14
Consigna: ................................................................................................................................................. 14
Cadena de Pastelería ................................................................................................................................ 19
Consigna: ................................................................................................................................................. 19
Sistema de Compras y Proveedores ...................................................................................................... 24
Consigna: ................................................................................................................................................. 24
Cupones de Descuentos ........................................................................................................................... 29
Consigna: ................................................................................................................................................. 29
2023 Guía de Ejercicios sobre Máquina de Estados.docx – Versión 1.5

Página 2
Agua Puntos Fijos

Autor: Laura Covaro
Consigna:
1. Modele los estados de la clase “Medición”, utilizando un diagrama de máquina de estados.

Especifique asociado a las transiciones los casos de uso, los métodos y las condiciones de
control, cuando aplique.
2. Construya la vista de análisis que incluye las clases necesarias para dar soporte a la máquina de
estados definida en el punto anterior.
Presentación del caso:
Una empresa privada se dedica a prestar el servicio de agua potable a una ciudad del interior de la
provincia de Córdoba. Una de sus obligaciones como prestador de servicio es asegurar que la provisión
del servicio se realice bajo los parámetros de presión y caudal establecidos contractualmente y regulados
por el Organismo de Control.
Para determinar las condiciones de presión y caudal con las que se está suministrando el servicio, el
Organismo de Control ha definido un conjunto de puntos dentro del radio servido por la Concesionaria,
denominados Puntos Fijos. Un Punto Fijo es un punto de la red de agua potable que se toma como
referencia para medir la presión y el caudal del suministro. Tiene una dirección (calle, altura, barrio)
asociada.
En cada Punto Fijo se toman permanentemente mediciones de presión y caudal, las cuales deben
encontrarse dentro de un rango de valores válidos, de acuerdo a lo que establece el contrato de
concesión. A su vez, la empresa tiene sus propios Puntos Fijos definidos, a fin de realizar un control más
minucioso sobre la provisión del servicio, siendo importante discriminar cuáles son los definidos por el
Organismo de Control y cuáles no.
Las mediciones de presión y caudal son monitoreadas permanentemente por el Área de Gestión
Hidráulica de la empresa para asegurar que los valores se mantienen dentro de los rangos definidos
como válidos. Además, las mediciones realizadas deben ser informadas mensualmente al Organismo de
Control.
Para medir la presión de los distintos Puntos Fijos distribuidos en la ciudad, existen componentes
electrónicos, llamados data logers, instalados de manera permanente en los Puntos Fijos, los cuales
capturan los datos de las mediciones (presión y caudal) y los convierten a datos digitales en formatos de
texto plano. Dependiendo la marca del data loger variará el formato del archivo generado. Actualmente
las mediciones son realizadas cada 5 minutos, pero esa periodicidad puede variarse.
La empresa necesita un sistema que permita gestionar las mediciones de cada Punto Fijo, debiendo poder
importarse las mismas tal como son informadas por los distintos data loger, sin aplicar ningún tipo de
operación de sumarización o promedio al momento de almacenar la información y sin importar la marca
del data loger ni el formato del archivo plano que dicho data loger genera. Para esto es necesario que el
sistema se conecte a los data loger instalados en cada Punto Fijo y capture las mediciones registradas
en los archivos que los mismos generan. Los datos de las mediciones se enviarán al software a través
de un módem GSM.
Está previsto que cada 1 hora se realice la importación de los datos de los distintos archivos planos
generados por los data loger (en el cual se van adicionando las nuevas mediciones) pero este lapso de
tiempo puede ser variable (no pudiendo nunca ser superior a 2 horas). El sistema deberá permitir
importar los datos de hasta 50 Puntos Fijos en simultáneo y la importación de cada archivo no debe

Página 3
demorar más de 10 segundos para 12 mediciones (ya que las mediciones se toman cada 5 minutos y la
importación de las mismas se hace cada hora)
Al momento de importar cada una de las mediciones de un determinado Punto Fijo, desde el archivo plano,
puede ocurrir que la misma se realice en forma exitosa o que por algún inconveniente la importación de
una medición no pueda realizarse. Cuando la importación se realiza en forma exitosa el sistema deberá
borrar del archivo plano las mediciones importadas. En caso de que la importación de alguna medición
sea errónea (por no importarse todos los datos correctamente o porque la medición fue registrada de
manera incompleta por el data loger) se vuelve a intentar realizar la misma y luego de 2 intentos fallidos
se la identifica como errónea y se continúa con las siguientes mediciones del archivo.
El software a construir deberá permitir al Área de Gestión Hidráulica de la empresa la gestión de las
mediciones diarias de cada Punto Fijo, pudiendo visualizar las mediciones en forma de distintas vistas, a
fin de detectar los valores que queden fuera de los parámetros definidos. Estas vistas deberán mostrar
tanto las mediciones diarias para un día de particular como la tendencia de varios días consecutivos. Las
vistas posibles para la visualización de los resultados deberán ser las siguientes:
• Tabla de resultados: Mostrará cada una de las mediciones realizadas en una grilla, indicando momento
de la medición y presión o caudal (ya que hay Punto Fijos que miden presión y otros que miden caudal).
Deberán resaltarse en la tabla los valores que se encuentran fuera de los rangos considerados como
aceptables.
El resultado de la ejecución del reporte deberá poder imprimirse o exportarse a un archivo Excel.
• Gráficos: Mostrarán cada una de las mediciones realizadas en un gráfico de líneas que permita
observar tendencias de las mediciones a lo largo del tiempo. Deberán resaltarse los valores que se
encuentran fuera de los rangos considerados como aceptables.
El resultado de la ejecución del reporte deberá poder imprimirse o exportarse a un archivo Excel.
Se necesita que se visualicen en una misma pantalla los gráficos de 2 puntos fijos, para facilitar su
seguimiento.
• Comparativa: Deberá poder realizarse la comparación de las mediciones diarias de distintos puntos
fijos.
Además, deberán existir reportes mensuales en donde se visualicen valores máximos, mínimos y
promedios.
Deberá contemplarse la posibilidad que la aplicación sea accedida desde una PC que se encuentre fuera
de la empresa (ya que el control se realiza las 24 horas todos los días del año) sin que se requiera realizar
ninguna instalación especial para acceder al software. Lo mismo vale para cuando el acceso se hace
desde dentro de la empresa. Para ello se pensó en utilizar una página Web para visualizar las mediciones,
a la que se tendrá acceso utilizando una identificación de usuario y una palabra clave de al menos 8
caracteres. El navegador a utilizar deberá ser Internet Explorer 7 o superior, ya que es el navegador
utilizado en la empresa definido por política.
Por otra parte se requiere que el sistema emita alertas cuando los valores de las mediciones de los
Puntos Fijos estén fuera de los rangos establecidos o cuando se detecten caídas abruptas en la medición
de la presión o el caudal, aun cuando los valores se encuentren dentro de los rangos válidos. Las alertas
deberán enviarse utilizando diferentes medios: mail y mensajes de texto a celular. Los alertas deberán
proveer información del Punto Fijo, la medición que se encuentra fuera de rango y la fecha y hora de dicha
medición.
Una vez finalizado el análisis de las mediciones, el Operador de Gestión Hidráulica debe registrar el
análisis realizado sobre las mismas. Como resultado de ese análisis las mediciones pueden encontrarse
dentro del rango definido como aceptable, en los límites (consideradas como Observaciones) o fuera del
rango (consideradas como No Conformidades si el Punto Fijo es de los definidos por el Ente de Control y
como Observaciones si es un Punto Fijo definido por la empresa).
Si la medición se encuentra dentro de los valores aceptables se actualiza el estado de esta a Aceptada.
Si en cambio el valor de esta se encuentra en los límites o fuera del rango, la misma deberá ser tratada

Página 4
como Observación o No Conformidad, respectivamente. El Analista de Gestión Hidráulica será el

encargado de generar Acciones Preventivas para las mediciones en estado Con Observaciones y Acciones
Correctivas para las mediciones en estado No Conforme, actualizando el estado de la medición una vez
generada la acción. El Supervisor del Área de Gestión Hidráulica es quien realizará el seguimiento de
dichas acciones y el sector de Auditoría y Control el que realiza el cierre de dicha acción una vez que la
misma ha sido cumplimentada.
En el informe que se envía al Ente de Control se deberá mostrar el historial de estados de las mediciones
identificadas como No Conformidades (ya que son incumplimientos a lo establecido en el contrato), desde
su registro inicial y hasta el cierre de la Acción Correctiva.
El sistema debe mantener la gestión de los usuarios y permisos de estos en la aplicación.
Glosario
Radio Servido: Es el área geográfica a la cual provee el servicio la empresa concesionaria del servicio
de agua potable
Data Loger: Dispositivo que se instala en los Puntos Fijos para medir presión y caudal.
Organismo de Control: Ente regulador de servicios públicos que controla el cumplimiento del Contrato
de Concesión por parte de la empresa concesionaria.
Registrar un Punto Fijo de la red de distribución de agua

1 Registrar Punto Fijo
potable, con su dirección asociada
Modificar los datos de un Punto Fijo definido en la red de
2 Modificar Punto Fijo
distribución
Consultar los datos de uno o varios Puntos Fijos definidos en la
3 Consultar Punto Fijo
red de distribución
Eliminar los datos de un Punto Fijo definido en la red de
4 Eliminar Punto Fijo
distribución
5 Registrar Data Loger Registrar un Data Loger
6 Modificar Data Loger Modificar los datos de un Data Loger
7 Consultar Data Loger Consultar los datos de uno o varios Data Loger
8 Eliminar Data Loger Eliminar los datos de un Data Loger
Registrar una nueva marca de Data Loger y sus características
9 Registrar marca de Data Loger
asociadas
10 Modificar marca de Data Loger Modificar los datos de una marca de Data Loger
11 Consultar marca de Data Loger Consultar los datos de una o varias marcas de Data Loger
12 Eliminar marca de Data Loger Eliminar los datos de una marca de Data Loger
Registrar rangos de mediciones Registrar los rangos aceptables de presión y caudal
13
aceptables
Modificar rangos de mediciones Modificar los rangos aceptables de presión y caudal
14
aceptables
Consultar rangos de Consultar los rangos aceptables de presión y caudal
15
mediciones aceptables
Eliminar rangos de mediciones Eliminar los rangos aceptables de presión y caudal
16
aceptables
Obtener los datos de las mediciones de un Punto Fijo,
17 Importar datos de mediciones
registradas por el Data Loger en un archivo plano.

Página 5
Emitir reporte con tabla de Emitir un reporte de cada una de las mediciones realizadas en
18
resultados para un Punto Fijo una grilla, indicando momento de la medición y presión o caudal
Generar reporte de evolución Visualizar las mediciones de un Punto Fijo en un gráfico de
19 de mediciones para un Punto líneas que permita observar tendencias a lo largo del tiempo.
Fijo
Mostrar comparativa de las Mostrar la comparación de las mediciones diarias de distintos
20 mediciones de un conjunto de Puntos Fijos seleccionados por el usuario
Puntos Fijos
Generar un reporte en donde visualicen valores máximos,
Emitir reporte mensual de
21 mínimos y promedios para un determinado conjunto de Puntos
mediciones
Fijos en un determinado período de tiempo.
Enviar alerta por medición Emitir alerta para mediciones fuera de los rangos establecidos
22
fuera de rango o cuando se detecten caídas abruptas en la medición.
Registrar el análisis de cada medición de un Punto Fijo en un
23 Registrar análisis de medición determinado período de tiempo, actualizando el estado de las
mismas.
Modificar el análisis asociado a una medición registrado
24 Modificar análisis de medición
siempre que aún no se haya generado la acción asociada.
Eliminar el análisis asociado a una medición siempre que aún
25 Eliminar análisis de medición
no se haya generado la acción asociada.
Consultar los análisis asociados a las mediciones de un Punto
26 Consultar análisis de medición
Fijo.
Generar una acción correctiva o preventiva asociada a una
27 Generar acción medición que se encuentre en los estados “Con Observaciones”
o “No Conformidad”
Modificar una acción generada siempre y cuando la misma no se
28 Modificar acción
encuentre en estado “Cerrada”.
Eliminar una acción generada siempre y cuando la misma no se
29 Eliminar acción
encuentre en estado “Cerrada” ni tenga seguimientos asociados.
30 Consultar acción Consultar una o más acciones generadas.
Registrar seguimiento de Registrar el seguimiento de las acciones generadas, asociadas
31
acciones a mediciones con valores no aceptables.
Modificar los seguimientos registrados para una acción
Modificar seguimiento de
32 generada siempre y cuando la misma no se encuentre en estado
acciones
“Cerrada”.
Eliminar los seguimientos registrados para una acción generada
Modificar seguimiento de
33 siempre y cuando la misma no se encuentre en estado
acciones
“Cerrada”.
Consultar seguimiento de Consultar los seguimientos registrados para una acción
34
acciones generada.
35 Registrar cierre acción Registrar cierre de acción correctiva o preventiva.
Generar informe de las mediciones identificadas como No
Emitir informe de mediciones
36 Conformidades, desde su registro inicial y hasta el cierre de la
No Conformes
Acción Correctiva
37 Registrar Empleado Registrar un empleado en el sistema
38 Modificar Empleado Actualizar los datos de un empleado
39 Consultar Empleado Visualizar los datos de un empleado

Página 6
40 Eliminar Empleado Eliminar los datos de un empleado del sistema

Registrar asignación de Data Registrar la asignación de un Data Loger disponible a un Punto
41
Loger en Punto Fijo Fijo.
42 Iniciar Sesión Habilitar el inicio de sesión de un usuario en el sistema
Cerrar la sesión de un usuario en el sistema cuando el usuario
43 Cerrar Sesión
así lo indique
Cerrar la sesión de un usuario por el paso del tiempo con el
44 Caducar Sesión
sistema inactivo
45 Registrar Usuario Registrar un usuario del sistema
46 Modificar Usuario Actualizar los datos de un usuario del sistema
47 Consultar Usuario Visualizar los datos de un usuario del sistema
48 Eliminar Usuario Eliminar los datos de un usuario del sistema
Actualizar Asignación de Registrar la actualización de los permisos asignados a cada
49
Permisos a Usuario usuario
50 Registrar Cargo de Empleado Registrar un cargo en el sistema
51 Modificar Cargo de Empleado Actualizar los datos de un cargo
52 Consultar Cargo de Empleado Visualizar los datos de un cargo
53 Eliminar Cargo de Empleado Eliminar los datos de un cargo del sistema
Nota: Tener en cuenta que el listado de casos de uso no está completo.

Página 7
Solución propuesta
Diagrama de Máquina de Estados: Clase Medición
stm DTE Medición

17. Importar datos de 17. Importar datos de
mediciones [y no se pudo mediciones [no se pudo
importar la medición] importar la medición y es el
17. Importar datos de /registrarMedicion() primer intento fallido]
mediciones [y se pudo /registrarMedicion()
importar la medición]
/registrarMedicion() 17. Importar datos de
mediciones [y se pudo
importar la medición] ImportadaConError
Registrada /registrarMedicion()
23. Registrar análisis de

medición [la medición está en
los límites del rango o está 17. Importar datos de
fuera del rango pero es un PF mediciones [no se pudo
definido por la empresa] importar la medición y es
23. Registrar análisis de 23. Registrar Análisis de
/registrarAnalisisMedicion() el segundo intento fallido]
medición [la medición está Medición [la medición está
/registrarMedicion()
fuera de los límites del dentro de los valores
rango y es un PF definido aceptables]
por la empresa] /registrarAnalisisMedicion()
/registrarAnalisisMedicion()
ConObservaciones NoConforme
27. Generar Erronea

27. Generar acción
Acción /crearAccion()
/crearAccion()
ConAccionCorrectivaGenerada Aceptada
ConAccionPreventivaGenerada
35. Registrar cierre

de acción
35. Registrar cierre /cerrarAccion()
de acción
/cerrarAccion()
ConAccionFiinalizada

Página 8
Estructura de soporte de la Máquina de Estado para la clase Medición
Se muestra una vista

incompleta de las clases,
sólo haciendo foco en lo
requerido para dar
soporte a la máquina de
estados.

Página 9
Auditoría Médica de Órdenes

Autor: Gerardo Boiero
Consigna:
1. Modele los estados de la clase “OrdenMedica”, utilizando un diagrama de máquina de estados.

Especifique asociado a las transiciones los casos de uso, los métodos y las condiciones de control,
cuando aplique.
estados construida.
El área de Auditoría Médica de una importante Obra Social tiene por objetivo realizar las autorizaciones
de las órdenes médicas y de las prácticas médicas prescriptas en ellas. Las prácticas médicas están
definidas en el nomenclador de los planes asistenciales que pueden tener los afiliados.
La Obra Social quiere establecer un nuevo proceso de autorizaciones de las órdenes médicas que permita
agilizar los trámites al afiliado. De acuerdo a la complejidad de las prácticas médicas solicitadas en la
orden, la autorización puede ser efectuada: por Auditoría On-Line (vía Internet), por Auditoría Interna en
las instalaciones de la obra social o por un Comité Médico designado para analizar el caso.
Según lo definido anteriormente, la relación entre la complejidad de las prácticas médicas y los niveles
de autorización son:
• Práctica Simple: corresponde a consultas médicas, prácticas odontológicas simples, estudios de
rutinas, etc. La autorización debe ser realizada por Auditoría On Line.
• Práctica Semi-compleja: corresponden a estudios o consultas a especialistas, ecografía, etc. La
autorización debe ser realizada por un Auditor Interno, que es una persona designada por la Obra
Social para analizar la situación del afiliado.
• Práctica Compleja: implican prácticas médicas tales como tratamientos oncológicos, trasplantes, etc.
La autorización es efectuada por un Comité Médico que analiza el caso del afiliado.
El proceso a seguir para realizar la autorización de una orden médica se describe a continuación:
Antes de atenderse el afiliado, debe presentar su carnet y la orden médica con las prácticas solicitadas
por el médico prescriptor. El Responsable del Centro Médico (RMC) solicita la autorización de la orden
médica ingresando al Sitio Web de la Obra Social. En dicha solicitud ingresa el número de afiliado, plan
asistencial, matrícula del médico, diagnóstico presuntivo o definitivo, las prácticas y/o estudios
solicitados, número de orden médica y la fecha de prescripción. Al confirmar la solicitud, se envía la
misma para que sea procesada por el módulo de auditoría on line. Como respuesta se obtiene el resultado
de la evaluación de la orden médica. Si está autorizada la orden médica se muestra la fecha de validez
(30 días corridos) y el código de autorización que asegure la legitimidad de la operación. En cambio, si
está rechazada, se notifica el motivo por el cual se rechazó la misma. Por ejemplo, una solicitud puede
ser rechazada, cuando se envía a autorizar una práctica que no puede ser realizada porque el paciente
requiere un determinado tiempo mínimo de asociación (carencia).
Las solicitudes de autorización deben enviarse encriptadas al servidor mediante el algoritmo RSA, al igual
que las respuestas.
Cuando se envía una solicitud de autorización de orden médica se verifica la validez de los datos del
médico prescriptor por medio de un web service del Ministerio de Salud de la Nación para evitar órdenes
adulteradas, médicos inhabilitados, y cualquier otra irregularidad.

Página 10
El resultado de la auditoría debe obtenerse en menos de 10 seg. Al excederse ese tiempo se debe informar
al usuario de la demora, para que éste tenga una sensación de control sobre la aplicación. Cabe aclarar
que la autorización es realizada por orden médica. Por lo tanto, si una práctica no fue autorizada queda
rechazada la orden.
El sitio web debe ser soportado por el navegador Microsoft Internet Explorar 6.0 o superior con una
resolución de pantalla de 1024 x 768. Los fondos y textos de la interfaz deben seguir la gama de colores
azules institucionales, cuya degrades se mantenga dentro de los 256 colores.
El módulo encargado de la Auditoría On-Line debe verificar la validez y completitud de los datos
ingresados por el RMC en el formulario de solicitud de autorización. Si existiese un error, la solicitud es
devuelta para que el RMC realice la corrección y pueda enviarla nuevamente para su autorización; o bien,
anularla. Una vez anulada, no podrá solicitarse una autorización para la orden médica. Si la orden llega a
ser devuelta más de 2 veces se rechaza automáticamente. Esta aplicación web debe tener una capacidad
de atención de 100 solicitudes simultáneas.
Puede ocurrir que determinadas prácticas de la orden médica, en función de su complejidad, requieran
aprobación de Auditoría Interna o de un Comité Médico. En ambos casos, la respuesta de la evaluación
indica que está derivada para la revisión del afiliado. Cuando el usuario se presenta en la Obra Social para
la evaluación del Auditor Interno o el Comité Médico, éstos autorizan o rechazan la orden médica. El
afiliado tiene 7 días hábiles para realizarse la revisión en la Obra Social; de lo contrario, se invalidará
automáticamente la orden.
Para evitar fraudes en la realización efectiva de las órdenes médicas la autorización de las órdenes tienen
una fecha de validez. Superada la misma existe un tiempo de prórroga de 20 días corridos para que el
afiliado pueda solicitar una reautorización en la oficina de la Obra Social, en caso contrario, se invalidará.
La reautorización se puede realizar por única vez, extendiendo la validez por 10 días corridos.
Se debe contar con el registro de las situaciones por las cuales atravesó una solicitud de orden médica
en el tiempo y, cuando corresponda, el código de la autorización. Por otro lado, la base de datos debe
tener habilitada la función de log para dejar pistas de auditoría de las operaciones realizadas sobre los
datos. Los accesos a la base de datos deben realizarse únicamente con procedimientos almacenados.
El Centro de Cómputos de la Obra Social requirió el uso de tres servidores: un servidor que gestione la
base de datos, otro que contenga toda la lógica de la aplicación, y un tercer servidor para alojar el servidor
web (apache). Los componentes de presentación de las funcionalidades para administración y auditorías
internas deben ser instalados en las computadoras de los usuarios, ya que se ejecutan localmente.
Caso de Uso Objetivo

1 Solicitar Autorización de Orden Médica On Line Registrar una orden médica y notificar el
resultado de la autorización on line.
2 Autorizar orden médica por auditor Registrar la autorización de una orden médica
efectuada por el Auditor Médico.
3 Autorizar orden médica on line Auditar la orden médica y autorizarla, derivarla

o rechazarla.
4 Validar Matrícula Profesional Comprobar la validez de la matrícula del
profesional médico, estableciendo la
comunicación con el Ministerio de Salud de la
Nación para obtener esta información
5 Registrar Centro Médico Registrar los datos de un centro médico
6 Modificar Centro Médico Actualizar los datos de un centro médico
7 Consultar Centro Médico Visualizar los datos de un centro médico
8 Eliminar Centro Médico Dar de baja un centro médico

Página 11
Caso de Uso Objetivo

9 Buscar Orden Médica Aplicar un conjunto de filtros para obtener
como resultado los datos de las prestaciones
que cumplan con los filtros aplicados
10 Autorizar Orden Médica por Comité Médico Registrar la autorización de una orden médica
que debe efectuarse un afiliado en un centro de
salud, cuando se trata de una prestación
compleja que debe realizar un comité médico
11 Anular Orden Médica Anular la orden médica por parte del centro
médico.
12 Verificar Autorizaciones Caducas Verificar si se ha llegado a la fecha en que
caduca la autorización de la orden médica
13 Registrar ejecución de orden médica Registrar la presentación de una orden médica
una vez cumplimentada la práctica
14 Registrar reautorización de orden médica Registrar la reautorización de una orden médica
que había sido caducada
15 Registrar Médico Registrar los datos de un médico para la obra
social
16 Modificar Médico Actualizar los datos de un médico para la obra
social
17 Consultar Médico Visualizar los datos de un médico para la obra
social
18 Eliminar Médico Dar de baja un médico para la obra social
19 Iniciar sesión de usuario Habilitar el ingreso del usuario al sistema.
23 Buscar Afiliado Aplicar un conjunto de filtros para obtener
como resultado los datos de los afiliados que
cumplan con los filtros aplicados
24 Buscar Médico Aplicar un conjunto de filtros para obtener
como resultado los datos de los médicos que
cumplan con los filtros aplicados
25 Verificar Autorizaciones Fuera de Prórroga Verificar si se ha llegado a la fecha en que se
debe invalidar la autorización debido a que
queda fuera del período de prórroga permitido

Página 12
Solución Propuesta
Máquina de Estados de la clase: Orden Médica
Estructura de soporte para la Orden Médica

Página 13
Congreso de Informática y Tecnología

Autores: Mónica Lovay y Sol Zanel
Consigna:
1. Modele los estados de la clase “TrabajoDeInvestigacion”, utilizando un diagrama de máquina de

estados. Especifique asociado a las transiciones los casos de uso, los métodos y las condiciones
de control, cuando aplique.
2. Construya la vista de análisis que incluye las clases necesarias para dar soporte a la máquina
de estados construida.
La SAAII (Sociedad Argentina de Apoyo a la Investigación en Informática) organiza anualmente el

Congreso de Informática y Tecnología (CIT). Cada año se realiza una nueva edición del mismo en la cual
se organizan varios simposios que están abocados a diferentes áreas de investigación. Entre los mismos,
pueden mencionarse, el Simposio de Tecnología, el Simposio de Inteligencia Artificial, el Simposio de
Ingeniería de Software, etc. Cada año la SAAII elige una Facultad de una Universidad diferente como sede.
Para el próximo Congreso se han decido algunos cambios para su funcionamiento que implican realizar
cambios al sistema de información que le da soporte. A continuación, se explican las características a
las que se les deberá dar soporte:
• Cada edición del CIT se definir un grupo de chairs (organizadores) para cada simposio, que estarán
encargados de la organización del simposio.
• Para poder ser Chair un docente debe investigador y pertenecer a un grupo de investigación de
una facultad, correspondiente a una universidad. Por ejemplo: el chair N°1 del Simposio de
Ingeniería de Software es Luis Sánchez, perteneciente al grupo de investigación LABSOFT,
Facultad Regional San Francisco, de la Universidad Tecnológica Nacional.
• Cada simposio debe contar con evaluadores, los cuales son también docentes investigadores que
tendrán a su cargo la evaluación de los trabajos presentados. Tanto en los grupos de evaluadores
como en los grupos de chairs de cada simposio, los integrantes (evaluadores y chairs) tienen
asignado un número de orden. Este número es utilizado en el orden de aparición de sus nombres
en las publicidades del congreso.
• Cada simposio define la fecha límite para la recepción de trabajos.
• Los trabajos que pueden presentarse en este congreso pueden ser individuales o grupales. En
este último caso, los autores de un trabajo pueden ser docentes pertenecientes a facultades y/o
universidades diferentes. Cada autor pertenece a un único grupo de investigación.
• El envío de los trabajos debe realizarse por los autores a través de una página web en la cual debe
seleccionarse el simposio en el que se desea presentar el trabajo y luego para cada autor del
mismo se debe especificar: orden de aparición, apellido y nombre, grupo de investigación, facultad
y universidad.
• Respecto del trabajo de investigación se debe registrar: el título, un resumen del mismo (el cual
no debe superar las 150 palabras) y una lista de por lo menos cinco palabras claves. El trabajo de
investigación debe estar en formato pdf. En este momento, se registra la recepción del mismo y
se asigna un número de orden y el estado pendiente de asignación de evaluador.
• Pasada la fecha límite de recepción de los trabajos, los chairs deben asignar tres evaluadores a
cada uno de los trabajos. Estos evaluadores se seleccionan aleatoriamente entre los evaluadores
designados para cada simposio. En ese momento, el trabajo queda en estado pendiente de primera
evaluación.

Página 14
• Cada evaluador debe revisar los trabajos que le fueron asignados y registrar para cada uno el
resultado de su evaluación. Para ello, el evaluador asigna un puntaje (que es un valor entero entre
1 y 5, donde 1 significa “insuficiente” y 5 significa “excelente”) y un comentario a cada uno de los
aspectos que deben evaluarse, los cuales se encuentran predefinidos (contenido técnico, lenguaje
y estilo, pertenencia al simposio, novedad y contribuciones, etc.). Por ejemplo: el Evaluador XX
asigna al Trabajo N° 23 un puntaje de 5 en el aspecto contenido técnico, un 3 en lenguaje y estilo,
un 4 en pertenencia al simposio, y un 5 en novedad y contribuciones. Además de estos puntajes,
el evaluador debe indicar su decisión global acerca del trabajo, la cual puede ser: aceptado o
rechazado.
• Cuando el trabajo ha sido evaluado por al menos uno de los evaluadores pero todavía no ha sido
evaluado por los tres, se considera que se encuentra en el estado en evaluación inicial, pasando
al estado pendiente de evaluación por chairs, cuando efectivamente los tres evaluadores lo hayan
revisado.
• Luego, los chairs deben analizar para cada trabajo estas evaluaciones y en función de las mismas
tomar una decisión final, la cual puede ser que el trabajo sea aceptado, aceptado sujeto a
correcciones o rechazado. En el último caso, ya no existen posibilidades de reformularlo para
volver a presentarlo.
• Si el trabajo es aceptado sujeto a correcciones, los autores tendrán una única instancia y una
determinada cantidad de días (dependiendo del simposio) para realizar las correcciones
solicitadas y volver a presentarlo. Si transcurrido este tiempo los autores no envían una versión
corregida del trabajo, el mismo se considera anulado. Si por el contrario, es enviada la versión
corregida, los chairs serán los encargados de revisar estos trabajos para cotejar que se hayan
efectuado las correcciones solicitadas. Como resultado de este análisis puede resultar que el
trabajo sea rechazado o que sea aceptado.
• Una vez concluido el congreso, todos los trabajos que fueron aceptados son publicados en los
proceedings (actas) pertenecientes a cada simposio, asignando a cada trabajo su correspondiente
ISSN.
• Los autores pueden retirar por razones particulares y personales sus trabajos del congreso, sólo
si los mismos todavía no han sido aceptados.
• Es necesario conocer para cada trabajo, el tiempo de permanencia en cada uno de los estados
transitados.
Listado incompleto de CU de la aplicación descripta:
N° Nombre del Caso de Uso Objetivo del Caso de Uso

1 Registrar Edición de Congreso Registrar los datos de una nueva edición del congreso.
3 Consultar Edición de Congreso Consultar la información de una edición del congreso.
5 Registrar Investigador Registrar los datos de un docente investigador.
6 Modificar Investigador Modificar los datos de un docente investigador.
7 Consultar Investigador Consultar los datos de un docente investigador.
8 Eliminar Investigador Dar de baja a un docente investigador.
9 Registrar recepción de trabajo Registrar la recepción de un trabajo para un determinado
simposio.
10 Registrar Facultad Registrar los datos de una facultad.
11 Modificar Facultad Modificar los datos de una facultad.
12 Consultar Facultad Consultar los datos de una facultad.
13 Eliminar Facultad Dar de baja a una facultad.
14 Registrar Universidad Registrar los datos de una universidad.
15 Modificar Universidad Modificar los datos de una universidad.

Página 15
N° Nombre del Caso de Uso Objetivo del Caso de Uso

16 Consultar Universidad Consultar los datos de una universidad.
18 Asignar evaluadores a Registrar la asignación de tres evaluadores a cada uno de los
trabajos trabajos recibidos para cada simposio.
19 Registrar evaluación realizada Registrar la evaluación efectuada a uno o más trabajos por un
por evaluador evaluador asignado.
20 Registrar resultado de Registrar el resultado de la evaluación de la versión inicial o
evaluación corregida de uno o más trabajos.
21 Registrar Grupo de Registrar los datos de un grupo de investigación.
Investigación
22 Modificar Grupo de Modificar los datos de un grupo de investigación.
Investigación
24 Consultar Grupo de Dar de baja a un grupo de investigación.
Investigación
25 Retirar trabajo Registrar el retiro voluntario de un trabajo presentado en un
simposio.
26 Registrar recepción de trabajo Registrar la recepción de la versión corregida de un trabajo.
corregido
27 Asignar chairs a simposio Registrar para cada simposio la asignación de los docentes
investigadores que se desempeñarán como chairs.
28 Asignar evaluadores a Registrar para cada simposio la asignación de los docentes
simposio investigadores que se desempeñarán como evaluadores.
29 Registrar publicación de Registrar la publicación de todos los trabajos aceptados en cada
trabajos simposio con su correspondiente ISSN.
30 Anular trabajos Registrar la anulación de aquellos trabajos que se encuentran
aceptados sujetos a correcciones para los cuales no se ha
recibido la versión corregida, transcurrido el lapso de
presentación definido por el simposio.

Página 16
SOLUCIÓN PROPUESTA
1. Máquina de estados para la clase “TrabajoDeInvestigación”.
stm DTE_TrabajoDeInvestigación
09 Registrar
recepción de trabajo PendienteDeAsignación
/new() DeEvaluador
18 Asignar evaluadores a
trabajos /asignarEvaluador()
25 Retirar trabajo
/retirar()
PendienteDe
PrimeraEvaluación
25 Retirar trabajo
19 Registrar evaluación realizada por
/retirar()
evaluador /evaluar() [y es la primera
evaluación]
25 Retirar trabajo
19 Registrar evaluación realizada /retirar() Retirado
EnEvaluaciónInicial
por evaluador /evaluar() [y no es la
última evaluación]
19 Registrar evaluación realizada por 25 Retirar trabajo

evaluador /evaluar() [y es la última /retirar()
evaluación]
20 Registrar resultado de PendienteEvaluación
evaluación /evaluarChairs() [y PorChairs 25 Retirar trabajo
se rechazó] 25 Retirar trabajo /retirar()
Rechazado /retirar()
20 Registrar resultado
de evaluación
/evaluarChairs() [y se 20 Registrar resultado de
aceptó sujeto a evaluación /evaluarChairs() [y
correcciones] se aceptó]
20 Registrar resultado AceptadoSujeto

de evaluación ACorrecciones Aceptado
/evaluarCorrección() [y
se rechazó]
26 Registrar recepción de
trabajo corregido
/recibirCorrección() [y se
30 Anular Trabajos recibió corrección] 29 Registrar
/anular() [y no se 20 Registrar resultado publicación de
recibió corrección] de evaluación trabajos /publicar()
/evaluarCorrección() [y
PendienteDe se aceptó]
Anulado SegundaEvaluación Publicado

Página 17
Estructura de soporte para el Trabajo de Investigación:

Página 18
Cadena de Pastelería
Consigna:
1. Modele los estados de la clase “Pedido”, utilizando un diagrama de máquina de estados.

cuando aplique.
estados construida.
Una importante cadena de pastelería se dedica a fabricar tortas, turrones y dulces de altísima calidad y a
enviarlos a cualquier lugar del mundo. Esta cadena desea contar con una plataforma que le permita
mejorar la comunicación con sus clientes e incrementar la cantidad de pedidos de sus productos a nivel
mundial.
Esta plataforma virtual estará disponible tanto para la web como para smartphones Android. El cliente
podrá acceder a todas las noticias, novedades de la cadena, visualizar videos publicitarios, y disfrutar de
cientos de beneficios exclusivos que están disponibles sólo para quienes se suscriban a estos contenidos
virtuales.
Con esta herramienta de comunicación, el cliente podrá realizar sus pedidos de compras y saber en qué
situación se encuentran desde cualquier lugar del mundo. El cliente puede consultar el catálogo de
productos de la cadena, y agregar los productos con sus cantidades al carro de compras. Una vez
seleccionados todos los productos deseados, el cliente debe proceder a crear el pedido indicando el
nombre del destinatario y la ciudad de entrega. Si el destino elegido está dentro del país o de países
limítrofes (Brasil, Chile, Paraguay, Bolivia o Uruguay) se calcula automáticamente el monto total del
pedido incluidos los gastos de envío y los impuestos, y se espera la confirmación del pedido. En cambio,
si el destino es otro, el pedido debe ser analizado por un encargado de ventas de la cadena para calcular
el costo del envío, ya que es un destino no frecuente. Una vez evaluado, de igual manera, se informará el
monto total del pedido y se esperará la confirmación. Si el cliente no está conforme con cualquier aspecto
del pedido, puede cancelarlo.
Recién cuando el cliente confirma, se realiza el cobro del pedido a través de entidades de cobro online
(Mercado Pago, PayPal, Visa, Mastercard) que disponen de un web service para tal fin. A fin de simplificar
la solución asumiremos la representación de un web service único, independientemente de la entidad.
Una vez que se concreta el cobro, se procede a preparar el pedido con todos los productos solicitados. Si
la entidad rechaza el cobro, se da por extinguido el pedido; de igual manera, si no se realiza el cobro luego
de 2 intentos de autorización.
Después de preparado el pedido, debe ser inspeccionado por el personal de control de calidad para
asegurarse que los productos sean correctos, no estén vencidos ni dañados y estén correctamente
embalados. Si cumple los criterios de calidad, el pedido queda listo para ser despachado. El despacho
comienza cuando se envía a la empresa de correo que corresponde a ese destino. En caso de que no
cumpliere con los criterios de calidad establecidos, retorna nuevamente a preparación para que se lo
prepare y embale correctamente.

Página 19
Esta cadena trabaja con empresas de correo contratadas para cada destino. Estas empresas envían los
pedidos a sus centros de distribución y, luego, se los entregan a uno o más repartidores para que ellos
realicen el reparto del pedido al destinatario final. Una vez entregado, se da por finalizado el pedido. Si el
repartidor no puede entregar el pedido porque el destino es incorrecto o el destinatario no está en su
domicilio, lo informan a la cadena para que se comunique con el cliente. El cliente podrá decidir si se
cancela el pedido o corrige/cambia el domicilio de entrega para que sea nuevamente despachado.
Las empresas de correo informan la situación de envío del pedido diariamente a través de archivos con
diferentes formatos y tipos (XML, CSV o TXT). Cada vez que ocurre un cambio en el estado del pedido es
enviado un email al cliente y al destinatario si desean ser notificados sobre la situación del mismo.
Como la plataforma maneja dinero, es necesario que el esquema de seguridad de los usuarios cuente con
una clave de acceso de 8 caracteres a 16 caracteres alfanuméricos, y que se utilice un protocolo de
transferencia de datos seguro -conocido como HTTPS. El sistema debe soportar 1.500 accesos y
operaciones en simultáneo.
La aplicación deberá ser desarrollada en HTML5 y en Android para los teléfonos móviles. La aplicación
Android será un cliente liviano que no requiera programaciones complejas, y permitirá consultar las
publicaciones, consultar el catálogo y crear pedidos de igual manera que la aplicación web. La empresa
ya dispone de una licencia de Oracle 11g para utilizar como motor de base de datos, que además ya posee
configurado un esquema de auditoría que permite registrar toda operación (creación, actualización y
borrado) que se realicen sobre los datos.
Glosario:
• Carro de compras: es un complemento del catálogo web que facilita la selección de los
productos (y sus cantidades) a incluir en el pedido.
Nro Nombre del Caso de Uso Objetivo / Descripción breve

Registrar el contenido (noticia, novedad, beneficios, videos) de la
1 Publicar contenido
cadena a publicar para los clientes.
2 Consultar contenido Visualizar los datos e imágenes/videos de las publicaciones.
Cancelar publicación de Registrar la cancelación de una publicación a un cliente.
3
contenido
4 Registrar producto Registrar los datos de un producto de la cadena.
5 Modificar producto Cambiar los datos de un producto de la cadena.
6 Eliminar producto Dar de baja los datos de un producto de la cadena.
7 Consultar producto Visualizar los datos de un producto de la cadena.
Registrar catálogo de Registrar los datos del catálogo de productos y definir los
8
productos productos que contiene.
Modificar catálogo de Editar los datos del catálogo de productos y modificar la
9
productos definición de los productos que contiene.
Consultar catálogo de Buscar y visualizar los productos disponibles en el catálogo
10
productos vigente
Agregar producto a carro de Registrar la incorporación de un producto a la lista de productos
11
compras seleccionados del cliente con la cantidad deseada.

Página 20
Nro Nombre del Caso de Uso Objetivo / Descripción breve

Quitar producto de carro de Eliminar un producto de la lista seleccionada por el cliente.
12
compras
Registrar el pedido del cliente con los productos incorporados al
13 Crear pedido carro de compra, junto al cálculo del monto total (si el destino no
requiere análisis).
Visualizar los datos específicos del pedido, su situación actual y
14 Consultar pedido
el historial de estados.
Registrar la cancelación del pedido del cliente, generándose la
15 Cancelar pedido
devolución del cobro si el mismo ya fue cobrado.
Registrar la confirmación del pedido realizado por el cliente para
16 Confirmar pedido
iniciar el proceso de cobranza online.
Registrar autorización online Solicitar la autorización de cobro a las entidades de cobranza
17
de cobro online y, si es autorizado, registrar el cobro realizado.
Solicitar la anulación de un cobro realizado en la entidad de
18 Registrar devolución de cobro
cobranza online.
Registrar el resultado del análisis del destino del pedido con sus
19 Registrar análisis de destino
correspondientes costos de envío e impuestos.
Permitir el ingreso del usuario al sistema y registrar la sesión del
20 Iniciar sesión
usuario.
Registrar el cambio de la contraseña actual por una nueva
21 Cambiar contraseña
contraseña.
Registrar resultado de Registrar el resultado (aprobado o rechazado) de la inspección
22
inspección a pedido realizada sobre la preparación del pedido.
Registrar preparación de Registrar el comienzo de la preparación del pedido de un cliente.
23
pedido
Registrar finalización de Registrar la finalización de la preparación del pedido de un
24
preparación de pedido cliente.
Procesar automáticamente los archivos de seguimiento enviados
25 Actualizar estado de despacho por la/s empresa/s de correo y actualizar la situación de envío de
cada de pedido.
Enviar notificación a Generar el contenido del email de acuerdo al tipo de
26
interesado notificación/contenido y enviarlo al correo del interesado
Registrar el envío del pedido a la empresa de correo que lo
27 Registrar despacho de pedido
enviará al destino.
Registra los datos de un destino y de la empresa de correo que
28 Registrar destino
reparte.
Editar los datos de un destino y de la empresa de correo que
29 Modificar destino
reparte.
30 Eliminar destino Dar de baja un destino.
Visualizar los datos de un destino y de la empresa de correo que
31 Consultar destino
reparte.
Registrar adhesión a Registrar la adhesión del cliente a determinados contenidos que
32
recepción de publicaciones son publicados.
Cancelar adhesión de Registrar la cancelación de la adhesión realizada por un cliente a
33
recepción de publicaciones un tipo de contenido.

Página 21
Solución Propuesta
1. Máquina de Estado: Clase Pedido

stm StateMachine
13. Crear pedido [Destino frecuente =NO] /new()
EnAnálisisDestino
19. Registrar análisis de 13. Crear pedido [Destino
destino frecuente =SI] /new()
/analizarDestino()
EsperandoAceptación
16. Confirmar pedido
/confirmar()
Confirmado 17. Registrar autorización online

17. Registrar autorización online de de cobro [cant. intentos <= 2]
cobro [trx rechazada o cant veces > 2] /autorizarCobro()
/autorizarCobro()
CobroRechazado 17. Registrar autorización online de cobro [trx

CobroRealizado
aceptada]
/autorizarCobro()
23. Registrar preparación de
pedido /preparar()
EnPreparaciónPedido
24. Registrar finalización

22. Registrar resultado de
de preparación de pedido
inspección [no cumple]
/finalizarPreparacion()
/inspeccionar()
EnControlDeCalidad 15. Cancelar
pedido /cancelar()
22. Registrar resultado de inspección [cumple]

/inspeccionar()
PendienteDeDespacho
27. Registrar despacho de pedido

/despachar()
EnDespacho /despachar()
NoEntregado
25. Actualizar estado de

25. Actualizar estado de despacho despacho
15. Cancelar
[SeEntregó] /repartir() [NoFueEntregado] /repartir()
pedido /cancelar()
Finalizado
Cancelado

Página 22
stm EnDespacho

/despachar()
EntregadoACorreo
25. Actualizar estado de despacho

/enviarACentroDist()
25. Actualizar estado de despacho
EnDistribución /iniciarReparto() EnReparto
Estructura de soporte de la Maq. de Estado

class Logical View
Pedido
- estado :Estado
+ new()
+ analizarDestino() :void
+ confirmar() :void
+ autorizarCobro() :void
+ inspeccionar() :void Estado
+ registrarCobro() :void
+ despachar() :void - nombre
1
+ finalizarPreparacion() :void
+ devolver() :void
+ repartir() :void A fines de simplificar la solución, se
+ cancelar() :void
muestran sólo los atributos y
+ finalizar() :void
+ preparar() :void métodos utilizados por la maq. de
+ iniciarReparto() :void estado.
+ enviarACentroDist() :void
NOTA: Con esta estructura básica ya se resuelve la solución, porque no hay un requerimiento de llevar
un historial de estado.

Página 23
Sistema de Compras y Proveedores

Autor: Elizabeth Jeinson
Consigna:
1. Modele los estados de la clase “PedidoDeCompra”, utilizando un diagrama de máquina de estados.

cuando aplique.
estados construida.
Una Cooperativa de Obras y Servicios públicos del interior de la Provincia de Córdoba desea desarrollar
un sistema para administrar las compras y los proveedores de la organización. El sistema en cuestión
deberá dar soporte a los circuitos de compras definidos en la organización y que funcionan de la siguiente
manera: cada área dentro de la Cooperativa realiza un presupuesto anual en el que tienen contemplados
todos los gastos para uso interno y para obras que realizarán. El sistema de compras debe controlar que
las compras se mantengan dentro del presupuesto estipulado por área y que se siga todo el circuito de
aprobaciones necesarias para liberar una orden de compra.
Cada área tiene asignado un centro de costos y puede manejar uno o varios presupuestos. Por ejemplo,
el área de operaciones administra el mantenimiento de la red de agua potable con un centro de costo
específico y un presupuesto dado y a su vez administra una obra de cloacas con un centro de costo
diferenciado y a la que se le ha asignado un presupuesto por separado.
El procedimiento de compras estipula que de acuerdo con el monto de la compra cuál es el circuito de
aprobación y los requisitos:
Tipo de Compra Rango Aprobación Nivel

Directa $ 1 a $500 Jefe Evaluación de Primer
Nivel
Directa $501 a $1000 Jefe y Gerente del área Evaluación de Segundo
Nivel
Compulsa de precios (al $1001 a $ Jefe y Gerente del área Evaluación de Segundo
menos tres presupuestos 5000 Nivel
Licitación pública o Más de $5001 Jefe, Gerente del área y Evaluación de Tercer
privada Gerente General Nivel
El sistema tiene un Ranking donde los proveedores están ponderados por actuaciones anteriores. Cuando
son nuevos proveedores o se trata de una compulsa de precios o licitación, la ponderación se realiza de
acuerdo con la oferta. Algunos proveedores envían a la cooperativa en forma periódica sus ofertas y lista
de precios en formato digital. El sistema deberá importar esos datos y tenerlos en cuenta como referencia
de precios.
Cualquier persona del área o proyecto puede hacer un pedido de compra. Cuando lo carga al sistema,
éste toma como valor, el último valor de compra. Si no existe en el sistema, se puede valorizar en forma
manual haciendo referencia de la fuente del precio indicado. También puede sugerir proveedor y agregar
alguna observación o justificación. Se adjuntan al pedido los requisitos y luego de creado el pedido de
compra, se deriva al jefe (primer nivel) para su autorización y se indica la prioridad de la compra con la
siguiente escala: urgente, alta, mediana y baja.

Página 24
Un pedido de compra puede estar formado por varios ítems de productos y/o servicios, no obstante, al
aprobarlo y o rechazarlo, se lo hace en forma completa; no hay manejo independiente de los ítems que
integran un pedido de compra.
Cada nivel de aprobación en el circuito puede aprobar, pedir cambios o rechazar. Si rechaza este rechazo
es definitivo por lo que cierra el pedido de compra. Si se solicitan cambios, que pueden ser por falta de
cumplimiento de alguno o varios de los requisitos necesarios para la aprobación. Una vez que el
solicitante corrige lo que se le pidió, puede seguir el circuito de aprobaciones en el mismo punto donde
se interrumpió. El solicitante puede cancelar el pedido de compra, que no haya sido rechazado, en
cualquier momento antes de que el proveedor haya enviado los productos o haya prestado el servicio
Se solicita que el sistema envíe un mail al solicitante notificando cuando hay rechazos, cuando está
emitida la orden de compra y cuando se puede cerrar el pedido de compra. El sistema deberá también
ordenar los pedidos por prioridad dentro de un rango de fechas determinado para que los niveles
gerenciales puedan realizar las aprobaciones de acuerdo con las necesidades de la organización y
permitir aprobaciones en lote.
Una vez que está aprobado en el nivel requerido, se emite la orden de compra al mejor proveedor. El
monto de la compra se descuenta del presupuesto del centro de costo en forma provisoria.
Cuando la mercadería es enviada por el proveedor o se ha provisto el servicio, se completa un Informe
de Satisfacción indicando un puntaje que asigna el solicitante respecto de la adquisición para nutrir el
Ranking de Proveedores de la Cooperativa y de esta manera se cierra el incidente del pedido de compra.
Además, se descuenta la compra del presupuesto en forma definitiva.
El sistema de compras debe relacionarse con el sistema contable para que se realicen todos los asientos
correspondientes a los movimientos contables y también con el sistema de Planificación del que obtiene
los montos de los presupuestos anuales. El sistema debe ser multimoneda ya que hay algunas compras
que deben hacerse en moneda extranjera.
Nro. Nombre del Caso de Uso Objetivo

1. Registrar proveedor Registrar los datos de un proveedor.
2. Modificar proveedor Actualizar los datos de un proveedor.
3. Consultar proveedor Mostrar los datos de un proveedor.
4. Eliminar proveedor Dar de baja un proveedor.
5. Registrar tipo de compra Registrar un tipo de compra utilizado en la cooperativa.
6. Modificar tipo de compra Actualizar un tipo de compra utilizado en la cooperativa.
7. Consultar tipo de compra Mostrar un tipo de compra utilizado en la cooperativa.
8. Eliminar tipo de compra Dar de baja un tipo de compra utilizado en la cooperativa.
9. Actualizar ponderación Actualizar el puntaje asignado a un proveedor en el ranking de
proveedor proveedores.
10. Registrar pedido de compra Registrar un nuevo pedido de compra.
11. Modificar pedido de compra Actualizar datos en un pedido de compra existente.
12. Derivar a evaluación pedido Derivar un pedido de compra creado para que sea evaluado por
de compra el primer nivel de autorización.
13. Cancelar pedido de compra Registrar la cancelación de un pedido de compra.
14. Controlar límite de compra Verificar si el pedido de compra sobrepasa el límite establecido
por el presupuesto del área.
15. Evaluar pedido de compra Evaluar si un pedido de compra puede ser aprobado o
rechazado.

Página 25
Nro. Nombre del Caso de Uso Objetivo

16. Emitir orden de compra Generar e imprimir una orden de compra a un proveedor
seleccionado de acuerdo a uno o más pedidos de compra
aprobado/s.
17. Modificar orden de compra Actualizar una orden de compra existente.
18. Cancelar orden de compra Cancelar una orden de compra existente.
19. Generar Ranking de Obtener un reporte de Ranking de Proveedores de la Cooperativa
Proveedores en función de criterios predefinidos y para un período de tiempo
especificado.
20. Registrar conformidad de Registrar satisfacción de compra, indicando un puntaje que asigna
compra el solicitante respecto de la adquisición, para luego cerrar el
incidente del pedido de compra.
21. Registrar ítem de escala de Registrar un ítem correspondiente la escala de prioridades.
prioridades
22. Modificar ítem de escala de Actualizar un ítem correspondiente la escala de prioridades.
prioridades
23. Consultar ítem de escala de Mostrar un ítem correspondiente la escala de prioridades.
prioridades
24. Eliminar ítem de escala de Dar de baja un ítem correspondiente la escala de prioridades.
prioridades
24. Importar lista de precios Importar archivo con precios de ítems enviados por un
proveedor.
Nota: Tener en cuenta que el listado de casos de uso no está completo.

Página 26
Solución Propuesta
1. Máquina de Estado: Clase Pedido de Compra

Página 27
Estructura de soporte de la Máquina. de Estado

«entity»
PedidoDeCompra
fechaCreacion «entity»
numero Estado Se muestra una vista incompleta
aprobadoPrimerNivel() descripcion de las clases, sólo haciendo foco
aprobadoSegundoNivel() nombre
aprobadoTercerNivel() actual en lo requerido para dar soporte
getDescripcion()
cambioRealizado() 1
getNombre() a la máquina de estados.
cancelar() anterior
cerrar() new() En el dominio se aclara que el
0..1 setDescricpion()
crearDetallePedidoCompra()
setNombre() estado el para el pedido en
derivar()
emitirOrdenCpra() forma completa, por eso no se
new() requiere estado para cada detalle
pedirCambios()
rechazar() de Pedido de Compra.
El puntero anterior es
1..*
principalmente, para manejar la
detallePedidoCompra historia del estado
«entity» “EnCorreccion”
DetallePedidoCompra

Página 28
Cupones de Descuentos
Consigna:
1. Modele los estados de la clase “CuponDeDescuento”, utilizando un diagrama de máquina de

estados. Especifique asociado a las transiciones los casos de uso, los métodos y las condiciones
de control, cuando aplique.
2. Construya la vista de análisis que incluye las clases necesarias para dar soporte a la máquina
de estados construida.
Una empresa desea implementar un portal web a nivel nacional para permitir a quienes se suscriban al
mismo, obtener grandes beneficios al adquirir productos y/o servicios de diferentes rubros:
gastronómico, fotografía, deporte, gimnasio, spa, etc. con precios bonificados. Esos beneficios se
materializan adquiriendo cupones de descuentos que pueden ser canjeados por productos o servicios en
los comercios adheridos. La empresa también actúa como comercio adherido, ofreciendo productos que
se entregan en sus sucursales distribuidas a lo largo del país. Cada cupón contendrá un código QR que al
ser leído dirigirá a una página de confirmación provista por este portal web para validar si el cupón es
original, evitando posibles falsificaciones. Los comercios adheridos que ofrecen productos y/o servicios
deberán tener un dispositivo (Smart pone, PC o similar) que tenga instalada una aplicación lectora de
código QR, por ejemplo, QuickMark Reader.
Los comercios adheridos que deseen publicar sus ofertas a través del portal web, deben registrarse en
el sistema como empresa publicante, podrán registrar ofertas que serán comunicadas vía e-mail a los
usuarios suscriptos. Las ofertas se emiten para una o más ciudades, tienen una fecha de fin de vigencia,
un rubro, un importe (precio final), un cupo mínimo (que representa la cantidad de suscriptos que se
requiere hayan adquirido la oferta para que este sea válida), una fecha y hora de cierre, y una descripción
de las condiciones referentes a la prestación de la misma. Al registrar una oferta, el comerciante debe
elegir una imagen que sea representativa de la oferta; el sistema debe manejar un banco de imágenes de
alta definición en formato .png libres de derecho de autor sin restricción de tamaño (organizadas por
rubro) para que al momento de publicar la oferta el comerciante elija la que lo represente mejor o,
adicionalmente cargue una nueva imagen. A continuación, se muestra un ejemplo de oferta del comercio
“Foto Express” para la ciudad de Córdoba:

Página 29
CÓRDOBA – Fotografía - Oferta de hoy: 21/05/2014
Finaliza en
DíasHoras
Pagá $45 en vez de $124,50 por la

impresión digital de 50 fotos en 13x18 en
Foto Express.
Finaliza
Cupo mínimo:
100
compradores
en
Finaliza en
Condiciones: Cupón de descuento válido del 01/06/2014 al
31/08/2014. No acumulable con otras promociones. Se
puede adquirir hasta 2 ofertas por suscriptor.
Para que los comercios adheridos puedan promocionar sus ofertas, el sistema expone una API (Interfaz
de programación de aplicaciones que proporciona un conjunto de funciones de uso general que definen
cómo invocar un servicio, es una interfaz de comunicación entre componentes software) que permite a
los comercios adheridos incrustar en sus páginas un componente visualizador de las ofertas disponibles,
ese componente obtendrá las ofertas actuales -a través de un webservice desarrollado por la empresa-
y redirigirá al portal web en el caso que se desee adquirir un cupón.
Para suscribirse en el portal web y comenzar a recibir las novedades de ofertas diarias, el usuario debe
completar sus datos personales, la ciudad donde vive y los rubros de interés (gastronómico, fotografía,
deporte, gimnasio, spa, etc.) sobre los cuales le gustaría recibir ofertas. Cuando se registra una oferta el
sistema las agrupa según su rubro y ciudad, luego genera las novedades diarias combinándolas. Las
ofertas permanecen disponibles como novedad hasta que se cumple la fecha de cierre. Todos los días se
envían una o más ofertas al e-mail del Suscriptor. Si éste desea adquirir algún producto/servicio ofertado
debe loguearse en el portal web, si aún no posee usuario puede completar el formulario de registración.
Para efectuar una compra debe dirigirse a la opción Comprar, indicar la cantidad a adquirir, la tarjeta de
crédito (marca de tarjeta, número, fecha de vencimiento y código verificador (cvc)con la cual realizará el
pago, y confirmar que acepta las condiciones de compra del producto/servicio ofertado. El sistema
generará un cupón de descuento como pendiente hasta cumplirse la fecha de cierre de la oferta adquirida.
Por ejemplo, para la oferta anterior, el suscriptor puede realizar la compra de la oferta de las 50 fotos
impresas pagando tan sólo $45. Si lo desea, el suscriptor puede adquirir 2 ofertas pagando $90 que podrá
canjear por 100 fotos impresas.
Dado que se trata de una metodología de compra colectiva, recién se concreta la compra de la oferta del
producto/servicio cuando se cumple la fecha y hora de cierre establecida y se ha alcanzado el cupo
mínimo. Si no se alcanza este cupo se cancelarán todos los cupones de descuento generados. Al
concretarse la compra se enviará un mail informando que el cupón ya fue cobrado y está disponible para
usar; si por alguna razón el cobro no puede concretarse, se le notificará mediante mail al comprador para
que regularice la situación y el cupón permanecerá en espera de que se concrete el cobro o hasta
cumplirse un periodo de 48hs hábiles, en cuyo caso será cancelado.
Cuando el Suscriptor quiera hacer uso de los cupones de descuento, deberá imprimirlos y canjearlos en
el comercio adherido que lo ofreció. Así, el comerciante recibirá el cupón y podrá validar el código a través
de la página web. Una vez validado el cupón y registrado como usado, no podrá ser usado nuevamente.
Si el Comercio Adherido es la misma empresa, el producto que se adquiere deberá ser retirado en
cualquiera de las sucursales habilitadas para tal fin. Una vez retirado de la sucursal se marcará el cupón
como entregado. En caso de que el producto retirado presente defectos o fallas el usuario podrá
reclamarlo dentro de los 5 días hábiles posteriores a su retiro, si pasa ese periodo el cupón se

Página 30
considerará usado. En caso de reclamar un cupón, el usuario deberá devolver el producto en el mismo
lugar donde lo retiró, la empresa decidirá si rechaza el reclamo (según las condiciones en que se devuelve
el producto), o lo acepta. En caso de aceptar el reclamo puede proceder de dos maneras: generando un
cambio de producto, si se contara con stock disponible, o en caso contrario, realizando el reembolso del
importe del cupón de descuento. La empresa sólo recibe reclamos por productos que ella misma
comercializa, en caso contrario los clientes deben dirigirse al comercio adherido que publicó la oferta.
El usuario podrá logueándose en el portal web, consultar todos sus cupones y visualizar el historial de
estados por los que pasó cada cupón de descuento.
Durante la noche a las 04:00 AM, el sistema verificará la fecha de vencimiento de todos los cupones
disponibles, si alguno vence dentro de las 48hs, enviará un mail alertando a cada dueño del cupón sobre
esta situación y marcará todos los cupones próximos a vencer con color rojo (código RGB: #FF0000).
Aquellos para los que se haya cumplido la fecha de vencimiento y no hayan sido usados serán marcados
con color gris (código RGB: #585858).
El portal web también brinda la posibilidad de manejar una cuenta de créditos a cada usuario, de forma
tal que, a la hora de comprar una oferta, permita descontar el costo de esa cuenta. El usuario podrá cargar
saldo en su cuenta a través de su tarjeta de crédito o medios de pago en efectivo como RapiPago o
PagoFácil. El saldo de la cuenta también se puede incrementar con los rembolsos por cupones devueltos.
A fin de simplificar la solución, se considera que las devoluciones de cupones se pueden hacer
únicamente con reembolsos que se acreditarán a la cuenta del cliente.
Para conseguir más suscriptores, el portal web deberá permitir que los usuarios registrados
recomienden ofertas a personas no registradas actualmente, enviándoles un link exclusivo generado para
cada oferta. El sistema debe hacerle seguimiento a ese link de manera que si el nuevo usuario hace click
en el link dentro de las siguientes 72 horas, se registra en el sitio web y realiza una compra de una oferta,
se le depositará en la cuenta del usuario que lo recomendó $10 de crédito, que se acumularán en la cuenta.
La empresa dispuso que la base de datos a utilizar debe ser MySQL 5.6 y se instale en un servidor
dedicado. Además, el banco de imágenes también se instalará en otro servidor dedicado.
Adicionalmente el sistema debe permitir a los comerciantes generar un reporte de la cantidad de cupones
comprados y usados por cada oferta publicada, además de los montos totales ganados por cada oferta.
Para el usuario suscriptor debe permitir visualizar un reporte del importe ahorrado anual, además de los
movimientos de créditos en su cuenta.
Nro Nombre del Caso de Uso Objetivo / Breve Descripción
Registra una oferta con todos sus datos y la foto representativa
1 Registrar Oferta.
incluyéndola en el listado de publicación.
Visualizar todos los datos de la oferta con el contador de tiempo
2 Consultar Oferta.
restante.
Cancelar la oferta y todos sus cupones pendientes por no llegar
3 Cancelar Oferta.
a la cantidad mínima de suscriptores.
Recomendar ofertas a través del envío de un link de
4 Recomendar Oferta. recomendación. Se llama al caso de uso de realizar seguimiento
al link de recomendación.
Procesar el cierre de las ofertas de productos/servicios
5 Ejecutar Cierre de Ofertas. llamando a los casos de uso de cobro de todos los cupones
asociados en caso de haber alcanzado el cupo mínimo.
6 Registrar Comercio Adherido Registrar los datos de un comercio adherido al portal web.
7 Modificar Comercio Adherido Modificar los datos de un comercio adherido al portal web.
8 Consultar Comercio Adherido Visualizar los datos de un comercio adherido al portal web.
Eliminar un comercio adherido siempre que no tenga ofertas
9 Eliminar Comercio Adherido
publicadas.

Página 31

Adquirir una oferta a través de un cupón de descuento con una
10 Adquirir Cupón de Descuento
forma de cobro.
Consultar Cupón de Consultar los datos de un cupón de descuento con su historial de
11
Descuento. estado.
12 Imprimir Cupón de Descuento. Imprimir un cupón de descuento y su código QR.
Validar Código de Cupón de Validar que el código QR de un cupón de descuento corresponda
13
Descuento. a un cupón válido.
Registrar la fecha de uso de un cupón de descuento de forma
14 Registrar Uso de Cupón.
que no pueda ser utilizado nuevamente.
Validar Vencimientos Validar diariamente el vencimiento de los cupones de descuento.
15
Cupones.
Validar periodo de 48hs para regularizar situación de cobro de
16 Validar Periodo de Cobro.
cupones de descuento.
Registrar Cobro con Tarjeta Registrar el cobro de un cupón de descuento con tarjeta de
17
de Crédito. crédito.
Registrar cobro con créditos de la cuenta, debitando el importe
18 Registrar Cobro con créditos.
del producto/servicio.
Enviar mail al recibir un rechazo en el cobro del importe de un
19 Enviar aviso de cobro fallido.
cupón.
Registrar ingreso de créditos Acreditar el ingreso de un importe a una cuenta de créditos.
20
a cuenta.
Registrar Cobro a través de Registrar el cobro a través de medios de pago en efectivo como
21
medios de pago en efectivo. RapiPago o PagoFácil.
Reclamar Cupón de Registrar el reclamo de un suscriptor por un producto adquirido
22
Descuento. con un cupón de descuento.
Generar una novedad agrupando ciertas ofertas según su rubro
23 Generar novedad de ofertas.
y ciudad, que luego serán enviadas a los suscriptores.
Enviar los e-mails de novedad a los suscriptores según el tópico
24 Enviar e-mail de novedad.
y rubro.
Suscribir interesado para recibir ofertas según un rubro y
25 Registrar suscriptor.
ciudad.
Iniciar sesión habilitando los permisos predefinidos para cada
26 Iniciar Sesión.
usuario.
27 Registrar comercio adherido. Registrar los datos obligatorios de un comercio.
Registrar entrega de producto Registrar la entrega de un producto comercializado por la
28
importado. empresa.
Reembolsar Importe de Realizar la devolución del importe del cupón reclamado, con
29
Cupón. créditos en la cuenta del usuario que reclama.
Validar Periodo de Reclamo Validar si el cupón de descuento puede ser reclamado y
30
de Cupón. marcarlo como usado en caso de que se cumpla el periodo.
Solicitar el cambio de un producto entregado por medio de un
31 Solicitar Cambio Producto.
cupón de descuento.
Registrar la resolución del reclamo de un cupón de pago,
Registrar Resolución de
32 indicando si se rechaza, se reembolsa o se solicita el cambio del
Reclamo de Producto.
producto.
Generar Reporte de Cupones Listar todos los cupones usados para una oferta.
33
usados por oferta.

Página 32

Generar Reporte de Ahorro Generar un reporte que muestre el total de ahorro obtenido por
34
Anual. el uso de los cupones de descuento en un periodo anual.
Generar Reporte de cobros Generar un reporte de las ganancias obtenidas por cada oferta
35
por ofertas. para un comercio adherido.
Generar Reporte de Generar un reporte de todos los ingresos y egresos de una
36
Movimientos de Cuenta. cuenta para un suscriptor.
Obtener la información de las ofertas vigentes para que sea
37 Obtener Ofertas Vigentes. expuesto por la API en los sitios webs de los comercios que
deseen mostrarlas.
Al enviarse una recomendación, se realiza seguimiento al link
Realizar Seguimiento de Link
38 enviado para saber a través de un número de transacción si se
de recomendación.
efectuó una compra por medio del link.

Página 33
Solución Propuesta
1. Máquina de Estado: Clase Cupón de Descuento
stm Statecharts
10 Adquirir Cupon de Descuento /new()

5 Ejecutar Cierre de
Ofertas 5 Ejecutar Cierre de Ofertas /cancelarCupón() [y
Pendiente Cancelado
/validarCierre() [y no no se alcanzó el cupo minimo.]
es fecha de cierre]
17 Registrar Cobro con Tarjeta de Crédito
18Registrar Cobro con Créditos /cobrar() [y 16 Validar Periodo de 16 Validar Periodo de
no se autoriza] Cobro /validarCobro() [y Cobro /validarCobro()
17 Registrar Cobro con Tarjeta de Crédito se cumplen 48hs] [y no se cumplen 48hs]
18 Registrar Cobro con Créditos /cobrar() [y
19 Enviar Aviso de Cobro
se autoriza ]
Cobro Fallido /avisarCobroFallido()
Rechazado EnEsperaCobro
15 Validar
Vencimiento Cupon 17 Registrar Cobro con Tarjeta de Crédito
/validarVto() [y 18Registrar Cobro con Créditos /cobrar() [y
faltan mas de 48hs] se autoriza]
Usado
Disponible
Reembolsado
14 Registar Uso
Cupón /usarCupon()
30 Validar Periodo de Reclamo 32 Registar Resolución de Reclamo de
15 Validar
de Cupón /permiteReclamo() [y Producto /reembolsar() [aceptar y no hay
Vencimiento Cupon 28 Registrar Entrega se cumplio periodo] stock]
/validarVto() [y faltan 14 Registrar
en Sucursal ConReclamoRechazado
48hs] Uso Cupón
/entregar()
/usarCupon() 22 Reclamar Reclamado
Proximo a Entregado Cupón de 32 Registrar Resolución de
Vencer 28 Registrar Entrega Descuento Reclamo de Producto
en Sucursal /reclamar() /rechazarReclamo() [y se rechaza]
15 Validar Vencimiento Cupon /entregar()
/efecturarVto() [y hoy es fecha de 28 Registar Entrega 32 Registrar Resolución de Reclamo de
30 Validar Periodo Reclamo Producto /cambiar() [aceptar y hay stock]
vto] en Sucursal
/permiteReclamo() [y no se
Vencido /entregar()
cumple periodo]
PendienteCambio
Estructura de clases que soporta la máquina de estados.

Página 34
Caso de Estudio: Pizzería de Venta en Mostrador

U n a pizzería de la ciudad ofrece a sus clientes una amplia variedad de pizzas de fabricación propia,
que vende en mostrador. El dueño de la pizzería ha solicitado la construcción de un sistema
informático que ayude a la comercialización de sus productos. Se describe a continuación las
características del negocio a las que se deberá dar soporte:
• Administración de las pizzas para la venta:
o Las pizzas que venden son de dos tipos: a la piedra y de molde.
o Las pizzas pueden tener varios tamaños (4, 8, 10 y 12 porciones).
o Existen variedades de pizza en función de los ingredientes que se utilizan para
prepararlas, de las que sólo se requiere la descripción para informar a los clientes que
ingredientes tiene una pizza en particular.
o El precio de las pizzas depende de la variedad, el tipo y el tamaño.
• Gestión de pedidos de los clientes y su facturación y cobro.
o Se registran los pedidos que los clientes realizan en el mostrador, informando, el
nombre del cliente (para llamarlo cuando el pedido esté listo), la fecha y hora de
creación, la cantidad de pizzas de cada variedad, tipo y tamaño. Por ejemplo: 2 pizzas
de molde de 8 porciones de jamón y morrones y 1 pizza a la piedra de 4 porciones de
palmitos). El pedido tiene un total para cada ítem y un total del pedido.
o Un pedido puede modificarse (agregando o quitando ítems del pedido, modificando la
cantidad en algún ítem), mientras esté pendiente de preparación.
o Cuando el maestro pizzero va a iniciar la preparación del pedido debe informarlo
actualizando el estado, también debe informar que el pedido está preparado para que
se lo pueda entregar al cliente y facturarlo.
o Un pedido pueden cancelarse inclusive hasta cuando esté finalizado de preparar, es
decir justo antes de que sea entregado al cliente. La cancelación del pedido implica
cancelar todos los ítems del pedido.
o Cuando el pedido está preparado se genera una factura para su cobro y se entrega la o
las pizzas al cliente.
o En el momento de la entrega se registra la hora de entrega y se cierra el pedido. Cuando
el cliente paga se actualizada el estado de la factura a cobrada.
o Es necesario poder anular la factura en caso de que así se requiera.
• Generación y emisión de reportes de:
o Variedades y tipos de pizzas más pedidas por los clientes.
o Ingresos (recaudaciones) por períodos de tiempo.
o Pedidos (cantidad y monto) por día de la semana.
1
Se pide:
1. Definir el sistema de información utilizando: objetivo, alcances y reglas de negocio.
2. Construir el Modelo de Dominio utilizando un diagrama de clases, especificando atributos y
métodos para las clases y navegabilidad y multiplicidad para las relaciones.
3. Construir la vista esencial de la funcionalidad, utilizando un diagrama de casos de uso,
describiendo el objetivo de cada caso de uso identificado.
2
Solución propuesta:
Objetivo:
Administrar los pedidos de venta de pizza y el cobro de estos, brindar información
resultante de la gestión.
Alcances o Requerimientos Globales:
• Administrar pizzas con sus precios

• Administrar variedades, tamaños, y tipos de pizzas
• Gestionar pedidos de pizzas
• Gestionar la facturación de los pedidos y el cobro
• Generar reportes relacionas con la venta de pizzas.
Reglas de Negocio
Reglas de Negocio para el Sistema de Pizzería de Venta en Mostrador

Precio de las pizzas El precio de las pizzas depende de la variedad, el tipo y el tamaño.
Creación del Pedido. Se registran los pedidos que los clientes realizan en el mostrador, informando,
el nombre del cliente (para llamarlo cuando el pedido esté listo), la fecha y
hora de creación, la cantidad de pizzas de cada variedad, tipo y tamaño. Por
ejemplo: 2 pizzas de molde de 8 porciones de jamón y morrones y 1 pizza a la
piedra de 4 porciones de palmitos).
Modificación de un Un pedido puede modificarse (agregando o quitando ítems del pedido,
pedido modificando la cantidad en algún ítem), mientras esté pendiente de
preparación.
Cancelación de un Un pedido pueden cancelarse inclusive hasta cuando esté finalizado de
pedido preparar, es decir justo antes de que sea entregado al cliente. La cancelación
del pedido implica cancelar todos los ítems del pedido.
Cierre y Facturación En el momento de la entrega se registra la hora de entrega y se cierra el pedido.
del Pedido. Cuando el pedido está preparado se genera una factura para su cobro y se
entrega la o las pizzas al cliente.
Cobro Cuando el cliente paga se actualizada el estado de la factura a cobrada.
Anulación de Factura Se debe poder anular la factura en caso de que así se requiera.
3
Modelo de Dominio
4
Diagrama de Casos de Uso: Vista Esencial
uc Primary Use Cases
4 Registrar
Tamaño
10 Registrar 7 Generar reporte de
Pedido ingresos por período
Administrador
2 Registrar
Pizza
1 Generar
Factura
ventas por día de la
semana 3 Registrar
EmpleadoPizzería Variedad de
Pizza
pizzas más
demandadas
5
Máquina de estados del Pedido
Máquina de estados del Detalle de Pedido
6
Universidad Tecnológica Nacional – Facultad Regional Córdoba / Facultad Regional Villa María
Caso de Estudio: Software para gestión de requerimientos en una empresa de Software.

Una empresa dedicada a ser productos de software a medida ha decidido construir un producto que
permita administrar las solicitudes de requerimientos que los clientes realizan.
El producto será construido con tecnología web responsive, dado que la intención es que los clientes
ingresen las solicitudes de requerimientos ellos mismos.
Las solicitudes de requerimientos (SR) pueden ser de diferentes tipos, según sea:
• Desarrollo de un nuevo producto de software.
• Agregado/modificación de características a un producto de software existente.
• Defectos asociados a un producto de software para el que la empresa tiene contrato de
mantenimiento vigente.’
La primera versión del producto deberá dar soporte a la gestión de los requerimientos, desde que se
crean hasta que se les da un cierre por el motivo que fuere.
Seguidamente se describe el funcionamiento esperado para el sistema:
• Las SR las crea el cliente ingresando los siguientes datos: Cliente (si no está registrado como
cliente, primero deberá registrarse); producto de software asociado (si existe), tipo de SR
(selección de uno de los indicados anteriormente) y una descripción de lo que necesita. Al crearse
la solicitud se le asigna un número y se registra la fecha y hora de creación.
• La SR creada por el cliente queda pendiente de análisis por parte de un Analista de
Requerimientos de la empresa que será el responsable de evaluar la pertinencia y factibilidad de
lo requerido. Del análisis de factibilidad realizado, puede resultar que la SR sea desestimada, o
derivada para que sea preparada una propuesta que responda a lo pedido por el Cliente.
• Para derivarla, el Analista de Requerimientos deberá asignarle una prioridad.
• Luego, un Consultor asignado toma la SR y prepara un Propuesta de Servicios y se la envía al
cliente para su consideración
• El Cliente recibe la propuesta de servicio asociada a la SR y pueda aceptarla o rechazarla.
• Si el Cliente acepta la propuesta, la SR queda en estado pendiente de inicio del proyecto. Dado
que la empresa necesita un tiempo para armar el equipo de desarrollo realizará el trabajo.
• Para realizar el trabajo, se inicia un proyecto de desarrollo, que pasará por diferentes etapas
(Requerimientos, Análisis & Diseño, Implementación, Prueba y Despliegue); el proyecto de
desarrollo termina con la aceptación del despliegue por parte del Cliente.
• Con la aceptación del despliegue por parte del cliente se cierra la SR que dio origen al proyecto
de desarrollo de software.
• Independientemente de las razones y los aspectos contractuales, un Cliente puede cancelar la SR
en cualquier momento anterior a la aceptación del despliegue del producto de software.
1|Página
Universidad Tecnológica Nacional – Facultad Regional Córdoba / Facultad Regional Villa María
• También debe contemplarse la situación de interrupción del trabajo en cualquiera de las etapas
en las que personal de la empresa esté dedicando tiempo a una SR, para que el tiempo no sea
computado como esfuerzo asociado. Cuando se retoma el trabajo, la SR vuelve al estado en el
que estaba al momento de la interrupción; a partir de ahí seguirá con la evolución
correspondiente a ese estado.
• Es necesario poder informar a los clientes del estado de la solicitud de requerimientos en todo
momento y del avance del proyecto de desarrollo asociado a la SR.
• También es necesario poder informar cuánto tiempo permanece una solicitud en cada estado y
quién es el responsable de cada intervención (cambio de estado).
Nota: el caso se ha simplificado para fines académicos.
2|Página
Ejercicio Prá ctico Complementario

Nombre del Ejercicio Práctico Complementario (EPC): Líneas Aéreas
Objetivo del EPC:
El objetivo del ejercicio es desarrollar modelos específicos de un software que permite consulta, reserva y
cancelación de vuelos de una línea aérea, a partir de una descripción del negocio.
La particularidad de este ejercicio es que su alcance está planteado en términos de cubrir los contenidos que se
evalúan en los exámenes parciales de la asignatura y por lo tanto está diseñado de manera similar a la que se
presentan las consignas en dichas instancias de evaluación.
Objetivos de la Asignatura con respecto al ECP:

 Realizar la construcción de un Modelo de Análisis como base para la construcción de una arquitectura
robusta del sistema.
 Manejar las herramientas de modelado que brinda UML para la construcción de Modelos de Solución
(Análisis y Diseño) a partir del Modelo de Requerimientos
 Resolver situaciones problemáticas del diseño utilizando patrones de diseño.
Contenidos de la Asignatura que se abordarán en el EPC:

 Modelado del Comportamiento en el Diseño
 Modelado de la Estructura en el Diseño
 Patrones de diseño
Consigna asociada al EPC:
1. Construya la realización de caso de uso de análisis del escenario del curso normal del caso de uso planteado.
2. Construya la vista Realice el diagrama de clases de análisis incluyendo las clases del diagrama de
comunicación del punto anterior. Incluir atributos y métodos de las clases, navegabilidad y multiplicidad en
todas las relaciones.
3. Respecto de la Clase “VUELO”:
a. Construir el DTE, indicando: estados, transiciones, métodos asociados a las transiciones y
condiciones de control si aplica.
b. Listar los casos de uso asociados a las transiciones.
4. Realice la vista de la estructura (diagrama de clases de diseño) y la vista dinámica (diagrama de secuencia)
implementando el patrón de diseño que resuelva la siguiente consideración. Incluir el pseudo-código o una
explicación textual que muestre el funcionamiento de la solución construida (20 pts.):
 Al cancelarse un vuelo el sistema deberá notificar automáticamente esta situación a los distintos
interesados (cartelera de publicación de vuelos o pantalla de consulta del Sitio WEB de la
aerolínea). Para ello tendrá que diseñarse un esquema de notificación que sea genérico y flexible
para permitir informar en tiempo real y simultáneamente a los distintos interesados. A su vez, este
esquema tendrá que proporcionar la información referente a la cancelación (nro. de vuelo, estado,
fecha y hora) para los interesados que lo requieran.
EPC_LíneasAereas– Versión 1.34

Autor/es: Laura Alarcón – Gerardo Boiero- Judith Meles Página 1
Criterios de evaluación del EPC (Si aplica): no aplica

Descripción del Dominio asociado al Ejercicio Práctico Complementario
Una línea área desea incorporar un sistema de información accesible por web, para brindar a sus potenciales
pasajeros la posibilidad de consultar la disponibilidad de vuelos a los diferentes destinos que ofrece la compañía y
eventualmente reservar lugares en uno o más vuelos.
La definición de los vuelos que ofrece la empresa se diagrama determinando el número de vuelo, el o los días de la
semana y el horario de partida, la duración, el aeropuerto de origen y el aeropuerto de destino y las tarifas de los
pasajes. Estas tarifas dependen del destino, del tipo de clase que se desee (básica, turista, negocio reducida,
negocio, primera clase) y del tipo de aeronave.
Cabe destacar que las ciudades pueden tener más de un Aeropuerto, por lo tanto los vuelos están diagramados
para un aeropuerto específico. Tanto las ciudades como los aeropuertos tienen un código que los identifica, por
ejemplo: Buenos Aires, código BUE; Aeropuerto Jorge Newbery, código (AEP).
La disponibilidad depende de las reservas que cada vuelvo posea, entendiendo que las ventas de los pasajes se
concretan siempre a partir de las reservas. Las reservas pertenecen a un pasajero, poseen una fecha y hora de
vencimiento y también el detalle del tipo de clase solicitada.
La capacidad de las aeronaves está limitada por el tipo de clase que admitan (algunas solo tienen clase turista y
otras una combinatoria por ejemplo.)
La aerolínea permite realizar vuelos de distintos tipos: solo ida (origen-destino) ó ida y vuelta (origen-destino-
origen). Las consultas en la web deben solicitar que se indique el tipo de vuelo y además si el pasajero desea un
horario específico o es flexible. La flexibilidad de horarios permitirá que el sistema busque todos aquellos vuelos
disponibles en una fecha durante las 24 horas de esa fecha.
Además el sistema debe ofrecer un seguimiento de los vuelos, ya que los mismos una vez programados pueden
concretarse, demorarse o cancelarse. Si para un vuelo programado ha llegado el momento de embarque, el sistema
debe informarlo para permitir registrar si el embarque se ha concretado o no. Si esto fue posible, el sistema
informará que se está embarcando o de lo contrario informará que el mismo se encuentra demorado. El sistema
debe permitir reprogramar un vuelo programado o un vuelo demorado.
Cuando un vuelo por diferentes motivos no pueda concretarse, el mismo debe registrarse como cancelado. Esta
situación es posible para aquellos vuelos que se encuentren en estado no final. Se debe registrar el empleado
responsable de cada cambio de estado que se realice al vuelo, como así también el día y la hora en que se realizó
el cambio de estado. Para el caso de las cancelaciones se debe indicar el motivo de cancelación.
Una vez que todos los pasajeros han embarcado se cierra el vuelo, no pudiendo subir más pasajeros al mismo.
Luego, el vuelo se considera en ejecución, a partir de que el avión despega. Cuando el avión alcanza la altura de
viaje, el vuelo asume el estado “EnAire” hasta que se encuentra en la zona previa al aterrizaje y, finalmente,
aterrizado. Dado que es necesario informar la situación por la que pasa cada vuelo en todo momento y a través del
tiempo, debemos mantener dicha información en el sistema.
Finalmente el vuelo se considera finalizado cuando todos los pasajeros se encuentran en zona de retiro de equipaje.
Consideraciones sobre el dominio:

Para simplificar el problema, no se tienen en cuenta en el modelado:
 Las escalas intermedias entre los destinos disponibles.
 La variación en las tarifas de las reservas de los pasajes en función de:
o la fecha de compra (que es más económica la tarifa si se compra con mayor anticipación).
o la reserva de vuelos habilitando la modificación de fechas y horarios (en ocasiones las aerolíneas
permiten este tipo de reservas con un costo extra).
o Si se trata de un tipo de vuelo sólo ida o un vuelo ida y vuelta (en este último caso serían en realidad
dos reservas, una de un vuelo de ida y otra en el vuelo de vuelta).

Objetivo del Producto

Gestión de reservas y seguimiento de vuelos de una aerolínea, administrando la definición de vuelos,
aeropuertos vinculados en los itinerarios y aeronaves; brindando información vinculada a la gestión.
Requerimientos Funcionales (Alcances)
 Administración de Aeropuertos
 Administración de Aeronaves
 Administración de Definiciones de Vuelos
 Administración de Países, Provincias y Ciudades
 Gestión de Vuelos
 Gestión de Reservas
 Generación y Emisión de Reportes vinculados a vuelos, reservas y tarifas
No contempla
 Gestión de ventas y cobros de vuelos reservados
 Variación de tarifas por compra anticipada, tipo de vuelo (sólo ida o ida y vuelta) y con posibilidad de cambio
de fecha y horario
Reglas de Negocio
Reglas de Negocio
1 Escalas Intermedias No se consideran vuelos con escalas en destinos intermedios.
2 Itinerario de Vuelo Los vuelos tienen un único aeropuerto de origen y un único aeropuerto de destino.
La definición de los vuelos se diagrama determinando el número de vuelo, el o los días

3 Definición de vuelos de la semana y el horario de partida, la duración, aeropuerto de origen y destino y las
tarifas de los pasajes.
Las tarifas de los vuelos dependen del destino, del tipo de clase que se desee (básica,
turista, negocio reducida, negocio, primera clase) y del tipo de aeronave. No se
4 Tarifas de vuelo
consideran variaciones por fecha de compra anticipada, tipo de vuelo (sólo ida o ida y
vuelta) ni reserva con posibilidad de cambio de horario y fecha.
Un vuelo puede encontrarse en varios estados a través del tiempo, pero en un único
5 Estados del vuelo estado en un momento de tiempo particular. Se necesita informar la situación por la
que pasa cada vuelo en todo momento y a través del tiempo.
6 Reservas de Vuelo Las reservas tienen fecha y hora de vencimiento.
Un vuelo puede ser cancelado en cualquier momento, hasta tanto no aterrice. Una
7 Cancelación del Vuelo
vez aterrizado no se puede cancelar.
Las ventas de los pasajes se concretan siempre a partir de las reservas. Es decir, no se
8 Ventas de pasajes
puede vender un pasaje directamente, primero se reserva, luego se vende.

Nombre del Use Case: Consultar disponibilidad de vuelos ID: 1

Actor Principal: Pasajero Actor Secundario: no aplica

Objetivo: Obtener información de los vuelos disponibles según los criterios especificados.
Precondiciones: No aplica.
Post- Condiciones Éxito 1: Vuelos obtenidos.
Fracaso 1: El Actor no confirma la búsqueda de vuelos.
Fracaso 2: No existen vuelos disponibles según los criterios especificados.
1- Pasajero: El caso de uso comienza cuando selecciona la opción
“Consultar disponibilidad de vuelos”
2- Sistema: requiere que se indique el Tipo de Vuelo a consultar.
3- Pasajero: selecciona un Tipo de Vuelo.
4- Sistema: requiere que se indique el País de Origen y el de Destino.
5- Pasajero: selecciona un País de Origen y uno de Destino.
6- Sistema: obtiene las Provincias de los Países seleccionados y
requiere la selección de una Provincia de Origen y una de Destino.
7- Pasajero: selecciona una Provincia de Origen y una de Destino.
8- Sistema: muestra Ciudades asociadas a las Provincias seleccionadas,
y requiere la selección de una Ciudad de Origen y una de Destino.
9- Pasajero: selecciona una Ciudad de Origen y una de Destino.
10- Sistema: solicita que se indique si admite flexibilidad en horarios
habilitando el ingreso de una fecha.
11- Pasajero: indica que es flexible en horarios y como previamente 11.A. Pasajero: indica que no es flexible en horarios.
indicó el tipo de vuelo “Sólo Ida”, indica una fecha. 11.A.1. Sistema: verifica que el tipo de vuelo
seleccionado es “Solo Ida”, requiere que se indique la
Fecha y Horario de Salida.
11.A.1.A. Sistema: verifica que el tipo de vuelo
seleccionado es “Ida y vuelta”, requiere que se
indique la Fecha y Horario de Salida (Ida), y la Fecha
y Horario de Regreso (Vuelta)
11.A.2. Pasajero: ingresa los horarios solicitados.
11.B. Pasajero: indica que es flexible en horarios y como

previamente indicó el tipo de vuelo “Ida y vuelta”, indica
una fecha de ida y una de vuelta.
12- Sistema: solicita que se indique la Cantidad de Pasajeros por Tipo de
Clase.
13- Pasajero: indica la Cantidad de Pasajeros por cada Tipo de Clase.
14- Sistema: permite confirmar la búsqueda.
15- Pasajero: confirma la búsqueda. 15.A. Pasajero: no confirma la búsqueda.
15.A.1. Sistema: cancela el caso de uso.

Autor/es: Laura Alarcón – Gerardo Boiero Página 4
16- Sistema: verifica que los datos requeridos hayan sido completados 16.A. Sistema: el sistema verifica que los datos
y así es. requeridos hayan sido completados y no es así.
16.A.1. Sistema: informa los datos requeridos faltantes.
16.A.2. Pasajero: completa los datos requeridos y
confirma la búsqueda.
17- Sistema: Verifica si se seleccionó flexibilidad, y es así, y realiza las 17.A. Sistema: Verifica si se seleccionó flexibilidad, y se
búsquedas sobre los siguientes horarios para la fecha indicada: seleccionó horarios requeridos, y determina sobre qué
 HorarioDesde = 0:00 horarios debe realizar la búsqueda para las fechas
 HorarioHasta = 23:59 indicadas:
 HorarioDesde = horario indicado
 HorarioHasta = horario indicado
18- Sistema: verifica que se indicó “Solo Ida”, busca los vuelos que 18.A. Sistema: verifica que se indicó “Ida y Vuelta”,
correspondan: 18.A.1. Sistema: busca los vuelos de Ida que
 A la ciudad de origen y destino indicadas, correspondan:
 A la fecha indicada,  A la ciudad de origen y destino indicadas,
 Al horario: HorarioDesde y HorarioHasta determinado  A la fecha indicada de salida (Ida)
 Y que posean butacas para la cantidad de pasajeros y tipo  Al horario: HorarioDesde y HorarioHasta
de clase indicados, verificando las reservas vigentes y la determinado de salida (Ida)
capacidad de la aeronave asignada al vuelo.  Y que posean butacas para la cantidad de
pasajeros y tipo de clase indicados, verificando las
reservas vigentes y la capacidad de la aeronave
asignada al vuelo.
18.A.2. Sistema: busca los vuelos de Vuelta que
correspondan:
 A la ciudad de origen y destino indicadas (ver
Observación 1),
 A la fecha indicada de regreso (Vuelta)
 Al horario: HorarioDesde y HorarioHasta
determinado de regreso (Vuelta)
 Y que posean butacas para la cantidad de
pasajeros y tipo de clase indicados, verificando las
reservas vigentes y la capacidad de la aeronave
asignada al vuelo.
19- Sistema: encuentra vuelos disponibles y muestra para cada uno: 19.A. Sistema: no encuentra vuelos disponibles.
 Horario de salida 19.A.1. Sistema: informa la situación.
 Aeropuerto de salida 19.A.2. Se cancela el caso de uso.
 Horario de llegada
 Aeropuerto de llegada
 Número de Vuelo
 Duración
 Importe Total
20- Fin del caso de uso.
Observaciones:
1. Cuando se selecciona vuelos Ida y Vuelta debe tenerse en cuenta: si se ha seleccionado Córdoba (Origen) – Buenos Aires
(Destino), la búsqueda para el vuelo de Ida se efectúa por Origen y Destino como se indicó; pero para la búsqueda de
vuelos de Vuelta se tiene en cuenta para el Origen, el destino indicado anteriormente, y para el Destino, el origen
indicado anteriormente, es decir, Buenos Aires (Origen) – Córdoba (Destino) para el vuelo de Vuelta.
2. El Pasajero puede cancelar el caso de uso en cualquier momento.

Nombre del Caso de uso: Consultar disponibilidad de vuelos Nro. de Orden: 1
Actor Principal: Pasajero Actor Secundario: no aplica

Objetivo: Obtener información de los vuelos disponibles según los criterios especificados.
Flujo Básico
1. Pasajero: selecciona la opción “Consultar disponibilidad de vuelos”.
2. Sistema: requiere que se indique el Tipo de Vuelo (Ida y Vuelta o Solo Ida) a consultar.
3. Pasajero: selecciona un Tipo de Vuelo = SOLO IDA.
4. Sistema: requiere que se indique el País de Origen y el de Destino.
5. Pasajero: selecciona un País de Origen y uno de Destino.
6. Sistema: obtiene las Provincias de los Países seleccionados y requiere la selección de una Provincia de Origen y una de
Destino.
7. Pasajero: selecciona una Provincia de Origen y una de Destino.
8. Sistema: muestra Ciudades asociadas a las Provincias seleccionadas, y requiere la selección de una Ciudad de Origen y una
de Destino.
9. Pasajero: selecciona una Ciudad de Origen y una de Destino.
10. Sistema: solicita que se indique si admite flexibilidad en horarios habilitando el ingreso de una fecha.
11. Pasajero: indica que es flexible en horarios y como previamente indicó el tipo de vuelo “Sólo Ida”, indica una fecha.
12. Sistema: solicita que se indique la cantidad de pasajeros por Tipo de Clase.
13. Pasajero: indica la cantidad de pasajeros por cada Tipo de Clase.
14. Sistema: permite confirmar la búsqueda.
15. Pasajero: confirma la búsqueda.
16. Sistema: verifica que los datos requeridos hayan sido completados y así es.
17. Sistema: Verifica si se seleccionó flexibilidad, y es así, y realiza las búsquedas sobre los siguientes horarios para la fecha
indicada:
 Horario Desde = 0:00
 Horario Hasta = 23:59
18. Sistema: verifica que se indicó “Solo Ida”, busca los vuelos que correspondan:
 A la ciudad de origen y destino indicadas,
 A la fecha indicada,
 Al horario: Horario Desde y Horario Hasta determinado
 Y que posean butacas para la cantidad de pasajeros y tipo de clase indicados, verificando las reservas vigentes y la
capacidad de la aeronave asignada al vuelo.
19. Sistema: encuentra vuelos disponibles y muestra para cada uno:
 Horario de salida
 Aeropuerto de salida
 Horario de llegada
 Aeropuerto de llegada
 Número de Vuelo
 Duración
 Importe Total
Fin del caso de uso

Flujos Alternativos
A1: Pasajero selecciona Tipo de Viaje= IDA y VUELTA
A2: Pasajero selecciona horarios NO flexibles
A3: Pasajero no confirma la búsqueda
A4: Faltan datos obligatorios para hacer la consulta
A5: No se encuentran vuelos que cumplan con el criterio de búsqueda
A6: Pasajero decide cancelar el caso de uso
Observaciones:
1. Cuando se selecciona vuelos Ida y Vuelta debe tenerse en cuenta: si se ha seleccionado Córdoba (Origen) – Buenos Aires
(Destino), la búsqueda para el vuelo de Ida se efectúa por Origen y Destino como se indicó; pero para la búsqueda de
vuelos de Vuelta se tiene en cuenta para el Origen, el destino indicado anteriormente, y para el Destino, el origen indicado
anteriormente, es decir, Buenos Aires (Origen) – Córdoba (Destino) para el vuelo de Vuelta.
2. El Pasajero puede cancelar el caso de uso en cualquier momento.

Nombre del Use Case: Cancelar Vuelo ID: 2

Actor Principal: Encargado de Navegación (EN) Actor Secundario: no aplica

Objetivo: Registrar la cancelación de un vuelo.
Precondiciones: El usuario posee los permisos para acceder a esta funcionalidad.
Post- Condiciones Éxito 1: vuelo cancelado.
Fracaso 1: El Encargado de Navegación (EN) no confirma la cancelación del vuelo.
Fracaso 2: No existen vuelos factibles de ser cancelados.
Fracaso 3: El Encargado de Navegación (EN) decide cancelar la ejecución del caso de uso.
1- EN: El caso de uso comienza cuando selecciona la opción “Cancelar
Vuelo”.
2- Sistema: muestra todos los vuelos posibles de cancelar (número vuelo, 2.A. Sistema: No existen vuelos posibles de cancelar.
origen, destino y horario) que se encuentren demorados, 2.A.1. Se cancela el caso de uso.
programados, en embarque y reprogramados.
3- EN: selecciona un Vuelo.
4- Sistema: requiere seleccionar un motivo de cancelación.
5- EN: seleccionar un motivo de la cancelación.
6- Sistema: solicita ingresar una descripción sobre la cancelación.
7- EN: ingresa la descripción de la cancelación.
8- Sistema: solicita confirmar la cancelación del vuelo.
9- EN: confirma la cancelación del vuelo. 9.A. EN: No confirma la cancelación del vuelo.
10- Sistema: registra el motivo, descripción, fecha, hora y usuario
responsable de la cancelación del vuelo. Además, actualiza el estado
del vuelo a Cancelado y notifica a los interesados (ver Observación 1.).
11- Fin del caso de uso.
Observaciones:
1. Los “interesados” son las pantallas informativas que están instaladas en el aeropuerto y la pantalla de la consulta de
disponibilidad de vuelos del sitio web, que muestra el estado de los vuelos.
2. El Encargado de Navegación (EN) decide cancelar la ejecución del caso de uso.
Fuente: no aplica Referencia Fuente: no aplica

Nombre del Caso de uso: Cancelar Vuelo Nro. de Orden: 2

Objetivo: Registrar la cancelación de un vuelo.
Flujo Básico
1. EN: selecciona la opción “Cancelar Vuelo”.
2. Sistema: muestra todos los vuelos posibles de cancelar (número vuelo, origen, destino y horario) que se encuentren
demorados, programados, en embarque, reprogramados y/o en ejecución.
3. EN: selecciona un Vuelo
4. Sistema: requiere seleccionar un motivo de cancelación
5. EN: seleccionar un motivo de la cancelación
6. Sistema: solicita ingresar una descripción sobre la cancelación
7. EN: ingresa la descripción de la cancelación
8. Sistema: solicita confirmar la cancelación del vuelo
9. EN: confirma la cancelación del vuelo
10. Sistema: registra el motivo, descripción, fecha, hora y usuario responsable de la cancelación del vuelo. Además, actualiza
el estado del vuelo a Cancelado y notifica a los interesados (ver Observación 1.). Fin del caso de uso
Flujos Alternativos
A1: No existen vuelos posibles de cancelar.
A2: No confirma la cancelación del vuelo.
A3: El EN decide cancelar la ejecución del caso de uso.
Observaciones:
disponibilidad de vuelos del sitio web, que muestra el estado de los vuelos.

Nombre del Caso de uso: Actualizar situación de Vuelo Nro. de Orden: 3

Objetivo: registrar la actualización de estado de uno o más vuelos de la aerolínea.
Flujo escenario que informa que el aterrizaje de un vuelo.
1. EN: selecciona la opción “Actualizar situación de Vuelo”.
2. Sistema: busca y muestra las opciones de actualización de estado de vuelos (vuelos en estado no final) y solicita se
seleccione que estado de vuelo quiere actualizar.
3. EN: selecciona opción Aterrizar Vuelo
4. Sistema: busca todos los vuelos en condiciones de aterrizar, es decir, vuelos que están “en zona” y muestra de cada uno de
los vuelos (número de vuelo y fecha y hora de partida programada). Solicita se seleccione el o los vuelos a los que desea
actualizarles el estado.
5. EN: selecciona un vuelo para aterrizar.
6. Sistema: solicita confirmación para marcar el vuelo como aterrizado.
7. EN: confirma la actualización del estado del vuelo
8. Sistema: registra fecha y hora y usuario responsable de la actualización del vuelo, actualizando el estado del vuelo a
aterrizado y notifica a los interesados (ver Observación 1.). Fin del caso de uso
Flujos Alternativos
A1: No existen vuelos en el estado buscado.
A2: Selecciona todos los vuelos para actualizar.
A3: Selecciona varios vuelos para actualizar.
A4: Escenario que informa el despegue de un vuelo, para vuelos en estado cerrado.
A5: Escenario que informa que el vuelo está en aire, para vuelos en estado en despegue.
A6: Escenario que informa que el vuelo está en zona, para vuelos en estado en aire.
A7: Escenario que informar que el vuelo está demorado, para vuelos en estado programado o reprogramado.
A8: Escenario que informar que el vuelo está embarcando, para vuelos en estado demorado, programado o reprogramado.
A9: Escenario que informar que el vuelo está cerrado, para vuelos en estado en embarque.
A11: Escenario que informar que el vuelo está finalizado, para vuelos en estado aterrizado.
A12: El EN decide cancelar la ejecución del caso de uso.
Observaciones:
disponibilidad de vuelos del sitio web, que muestra el estado de los vuelos. Muestra para cada vuelo (número de vuelo,
fecha y hora de partida programada y fecha y hora de aterrizaje).

Modelo de Dominio

Realización de Análisis para el caso de uso Consultar Disponibilidad de Vuelos – Curso Normal con diagrama de
comunicación

Vista de Clases de Análisis asociado a la realización del caso de uso Consultar

Disponibilidad de Vuelos

Realización de análisis para el CU Cancelar Vuelo – Curso Normal con diagrama de comunicación

Realización de análisis para el CU Cancelar Vuelo – Curso Normal con diagrama de secuencia

Vista de Clases de Análisis para el CU Cancelar Vuelo

Realización de análisis para el CU Actualizar Situación de Vuelo – Escenario aterrizar

vuelo, con diagrama de secuencia

Vista de Clases de Análisis para el CU Actualizar Situación de Vuelo

Máquina de Estados de la Clase VUELO
Máquina de Estados del Estado Compuesto EnEjecución

Universidad Tecnológica Nacional – Facultad Regional Córdoba y Facultad Regional Villa María
Proyecto Práctico de Aplicácion

Nombre del Proyecto Práctico de Aplicación: Frigorífico
El Proyecto Práctico de Aplicación Frigorífico, tiene el propósito de desarrollar la especificación de un producto
de software que dará soporte a los procesos de negocio principales de un Frigorífico.

El Proyecto Práctico de Aplicación, tiene el propósito de reflejar cada una de las actividades de modelado
requeridas para el desarrollo y construcción de un producto de software en función del proceso, las técnicas y las
herramientas que se enseñan en la Materia Diseño de Sistemas. Este PPA representa una simplificación de un
caso real, en el cual los estudiantes podrán desarrollar las habilidades para aplicar los conocimientos adquiridos.

 Diseño de la Estructura del software.
 Diseño del Comportamiento del Software
 Mapeo de estructuras de clases a bases de datos relacionales.
 Diseño de Interfaces de Usuario

b. Modelo de Casos de Uso del Sistema de Información (Listado de Casos de Uso, Diagrama de
Paquetes, Diagramas de casos de uso, descripción de actores y descripciones de algunos de los
casos de usos a trazo medio.
c. Modelo de Dominio aplicando los patrones Coad.
a. Realización de Análisis de los Casos de Uso la parte dinámica con diagrama de comunicación y/o
secuencia, aplicando patrones GRASP) y la parte estática con diagrama de clases.
b. Máquina de Estados con diagrama de máquina de estados.
3. Modelo Arquitectónico
a. Especificación de RNF
b. Identificación y aplicación de Patrones Arquitectónicos Significativos.
c. Realización de vistas arquitectónicas.
a. Realizaciones de Casos de Uso de Diseño, parte estructural con diagrama de clases y parte
dinámica con diagrama de secuencia, aplicando los patrones de diseño más convenientes.
PPA_Frigorífico.docx – V 1.28
Autor: Giuliana Belli Página 1
i. Realizar el rediseño necesario para crear una solución que resuelva una forma de
flexibilizar el modelo permitiendo realizar notificaciones a los clientes vía email y sms al
momento en que sus pedidos son incluidos en un plan de entrega.
ii. Realizar el rediseño necesario para modelar una solución que resuelva en forma flexible
el cálculo por efectividad de las entregas de pedidos a los clientes de acuerdo con el
método seleccionado por el actor.
iii. Rediseñar la estructura de forma de optimizar el manejo del comportamiento variable
del remito y los cortes vacunos que lo componen, según la situación en la que se
encuentre.
iv. Resolver el proceso de creación del Plan de Entrega en sus diferentes formas de
visualización (impreso, PDF, o en formato Excel).
b. Prototipos de Diseño de Interfaces de usuario.
Glosario
Término Definición
Servicio Nacional de Sanidad y Calidad Agroalimentaria: organismo descentralizado,
dependiente del Ministerio de Agricultura, Ganadería y Pesca de la Nación, encargado
de ejecutar las políticas nacionales en materia de sanidad y calidad animal y vegetal e
SENASA
inocuidad de los alimentos de su competencia, así como de verificar el cumplimiento
de la normativa vigente, relacionada con la Agricultura, Ganadería y Pesca de la
Nación.
CUIG Clave única de identificación ganadera
Proceso mediante el cual se divide una res en diferentes cortes vacunos y se separa la
Despostar
merma.
Merma Huesos, grasa y desperdicios de una res que se desechan y no se comercializan.
Apropiarse [la autoridad competente] de una mercancía por estar prohibida, no
Decomisar
cumplir estándares de salubridad o porque se comercia con ella de manera ilegal.
Es una técnica de programación que permite adaptar la apariencia de las páginas web
al dispositivo (tablets, pc, smartphone, etc.) que se esté utilizando para visualizarla. Se
Web Responsive
pretende que, con un solo diseño web, tengamos una visualización adecuada en
cualquier dispositivo.
Un Frigorífico de la provincia de Córdoba se dedica a la comercialización de cortes vacunos envasados al vacío,

proveyendo a los clientes el producto y la logística de entrega. La empresa necesita implementar un sistema
informático de tecnología web, para optimizar sus procesos y mejorar el control del negocio. Se ha determinado
la necesidad de que el sistema sea desarrollado con tecnología responsive web desing, lo que significa que al ser
utilizado en dispositivos de hardware diferentes tales como tablets, computadoras y celulares, la visualización de
las interfaces sea la adecuada.
Además, como el cliente ha adquirido ya licencias de la base de datos Oracle, el desarrollo deberá utilizar la base
de datos Oracle 12c.
Otra solicitud del cliente está vinculada a los navegadores; el sistema deberá ser compatible con Mozilla FireFox
versión 49.0.2 en adelante y para Google Chrome versión 49.0.2623.112, en adelante.
Se describe a continuación y en términos generales el funcionamiento de algunos de los procesos de negocio,
que serán a los que el sistema de información a construir dará soporte.
Tratamiento del animal:

Periódicamente ingresan al frigorífico los camiones con el ganado vacuno proveniente de los campos,
cada animal está identificado de acuerdo con el sistema Nacional de Identificación de Ganado Bovino
con una clave denominada CUIG (Clave única de identificación Ganadera), que define el SENASA (Servicio
Nacional de Sanidad y Calidad Agroalimentaria). Ésta es una clave de 5 dígitos formada por 2 letras y 3
números que debe solicitar cada establecimiento propietario de animales. Por ejemplo: “JC432”.
Al llegar al frigorífico, se descargan los animales en un corral interno y se los registra con su clave CUIG,
su peso y su categoría.
El animal tiene una etiqueta de plástico adherida a su oreja izquierda con su peso y CUIG. Dicha etiqueta
se utiliza para agilizar el proceso de registro de entrada de los animales. El sistema deberá comunicarse con un
dispositivo lector especial denominado lector baqueano, que captura los datos de cada animal en su ingreso.
Además, cada vaca tendrá diferente categoría en función de su alimentación, método de crianza, edad, etc.
Posteriormente, esta categoría determinará la calidad de la carne que se obtenga y permitirá obtener
estadísticas del rendimiento de la carne en función de la categoría de animal.
Finalmente, los animales son sacrificados. La faena de los bovinos tiene un minucioso procedimiento
orientado a evitar la contaminación de la carne. Una vez realizada la faena se realiza el desposte, el cual consiste
en dividir la res resultante de la faena en cortes vacunos. Cada corte resultante de cada animal se pesa y empaca
al vacío etiquetándolo con su peso, CUIG de su animal de origen, tipo de corte (lomo, falda, marucha, cuadril,
etc.), fecha de envasado, fecha de comercialización (fecha límite hasta la cual se puede vender un corte a un
cliente) y fecha de vencimiento (fecha límite para consumir el corte). Por definición del negocio, los clientes sólo
podrán recibir mercadería que tengan fecha de comercialización mayor a la actual.
Además, el frigorífico tiene un acuerdo por medio del cual todos los cortes vacunos para los que expiró la
fecha de comercialización, pero aún no han vencido, son donados al banco de alimentos y ya no es posible
incluirlos en remitos. Por consecuencia es necesario realizar controles diarios de las fechas asociadas a los cortes
vacunos y determinar el estado a asignar a cada corte vacuno según corresponda.
Almacenamiento de cortes vacunos:

En cuanto un corte ha sido envasado y etiquetado se lo guarda dentro de las cámaras frigoríficas,
para enfriarlos hasta tanto sean incluidos en alguna entrega a un cliente.
El frigorífico posee múltiples cámaras para almacenar los cortes, que están identificadas con números.
Las cámaras poseen estantes también numerados y divididos en secciones que se asignan a un tipo de corte
específico.
Cuando un carnicero guarda cortes dentro de la cámara deberá etiquetar el estante con la fecha de
envasado del corte.
Por ejemplo, dentro la cámara número 1 se guardarán los tipos de corte: lomo, vacío y matambre. Esta
cámara está formada por 5 estantes identificados con los números del 1 al 5. Los estantes dedicados a un tipo de
corte específico están divididos en 3 secciones.
En el ejemplo de la imagen, el carnicero despostó un animal con CUIG SF542 el 15 de enero y guardó
dentro del estante número 1, los cortes lomo, vacío y matambre que obtuvo, en sus correspondientes secciones
y etiquetando el estante con la fecha de envasado de los cortes. Es importante aclarar que un carnicero sólo
podrá utilizar un estante si este posee todas sus secciones libres para mantener la consistencia de fechas.
CÁMARA FRIGORÍFICA N°1: Lomo, vacío y matambre

LOMO VACÍO MATAMBRE
10 kg lomo 5 kg vacío 2 kg matambre
1 CUIG SF542-035 CUIG SF542-001 CUIG SF542-025
15/01/2017
20 kg lomo 30 kg vacío
2 CUIG ER852-101 CUIG ER852-116
Sección libre 14/01/2017
5 kg vacío
3 Sección libre
CUIG GH654-067
Sección libre 13/01/2017
4 Sección libre Sección libre Sección libre Estante libre
5 Sección libre Sección libre Sección libre Estante libre
Se muestra el proceso gráficamente:

Guardado de los
Asignación de un Liberación de
Entrada de una Desposte de la cortes en las
corte a una secciones y
vaca al frigorífico vaca cámaras, estantes
entrega estantes
y secciones
Gestión de clientes:
Cuando un cliente va a realizar un pedido por primera vez se registrarán sus datos: nombre, apellido,
CUIT, domicilio, teléfono, mail y puntos de entrega que posea.
Se llama punto de entrega a cada carnicería, boca de expendio o centro de distribución que un cliente
tenga. Para cada punto de entrega, se indicará nombre, domicilio, localidad y barrio. Utilizando Google Maps y la
dirección de cada punto de entrega, se calcularán sus coordenadas geo-referenciales.
Gestión de pedidos y remitos:

Para realizar un pedido el cliente deberá indicar el punto de entrega donde desea recibirlo y los kilos de
cada tipo de corte que desea recibir. Además de registrar estos datos, el sistema deberá asignar un
número de pedido, el cual será secuencial y correlativo, la fecha en que se realizó el pedido, el cliente que lo
solicitó y el estado que se le asigna al momento de crearlo: pendiente de preparación. Si el cliente tiene facturas
sin abonar de más de dos meses no se le permitirá generar un nuevo pedido hasta que no regularice su pago.
La empresa tiene una política de entrega de los pedidos dentro de las próximas 48 horas de realizado el
mismo, por lo que no se contemplan pedidos planificados para una fecha específica, al contrario, los pedidos se
entregan lo más rápido posible. Los pedidos pueden cancelarse hasta tanto no se haya generado un remito para
cumplimentarlo. Los pedidos, sin embargo, no pueden modificarse y se cumplimentar de forma completa en un
único envío. Al momento de enviar los cortes vacunos que cumplimentan el pedido, se genera un remito. La
aceptación total del remito cumplimenta el pedido; la aceptación parcial del remito deja el pedido en
cumplimentado parcial; y los cortes que no se acepten, si el cliente aún los necesita se incluirán en otro pedido.
El responsable de pedidos accederá al sistema y consultará aquellos pedidos que estén pendientes de
preparación, es decir aquellos que aún no tengan un remito asociado. Tomará aquel que tenga fecha de pedido
más antigua y comenzará a prepararlo. Debido a que el corte vacuno tiene un peso ya determinado no siempre
es posible cubrir de manera exacta la cantidad de kilos solicitada de cada corte.
Por ello para la preparación del pedido se trata de incluir los cortes vacunos con fecha de
comercialización más cercana y redondeando el peso en forma aproximada. Para este proceso el sistema deberá
mostrar los cortes vacunos disponibles para cubrir con el pedido con un semáforo que indicará qué tan
conveniente es cada corte para completar con el pedido de acuerdo con la fecha de comercialización:
→ Verde: Dentro de los próximos 5 días
→ Amarillo: Dentro de los próximos 10 días
→ Rojo: Dentro de los próximos 15 días
Al finalizar este proceso se emite un remito que incluye la fecha de preparación, un número de remito y
el detalle de cada uno de los cortes vacunos incluidos, asociados a cada detalle de pedido para un cliente y un
punto de entrega en particular. Este remito quedará pendiente hasta tanto sea incluido en un plan de entrega.
Deberá ser posible imprimir el remito por triplicado: uno para el chofer, uno para el receptor y uno para el
frigorífico. También debe ser posible exportar el mismo a PDF o Excel, y enviarlo por email con formato HTML. El
remito deberá ser el siguiente formato:
REMITO
FRIGORÍFICO N° 00001-00001
CÓRDOBA Fecha: 01/03/2022
Cliente: Juan Gomez

Punto de entrega: Av. Andes 422 – La Carnicería de Juan
Remitimos a usted la siguiente mercadería:
KILOS TIPO CORTE CORTE P.KILO IMPORTE Conforme
1,3 Matambre SF542-025 $100 $130 SI NO
2,5 Matambre SF541-031 $100 $250 SI NO
1,0 Matambre SF547-065 $100 $100 SI NO
2 Marucha JV321-027 $50 $100 SI NO
TOTAL $600
Recibí conforme:
………………………………………….. ……..………………………………..
Firma Aclaración
Observaciones en caso de rechazo:
_________________________________________________________
Los remitos pueden modificarse o cancelarse hasta antes de ser incluidos en un plan de entrega. Si se los cancela,
cada uno de los cortes vacunos que integraban el remito vuelven al estado creado, es decir disponible para su
inclusión en otro remito. La modificación del remito implica que se agreguen cortes vacunos o se quiten cortes
vacunos del remito, actualizando el estado de cada corte vacuno según corresponda.
Se muestra a continuación el proceso descripto:
Actualización del
Registro de un Aceptación/Rechazo
Generación de un estado del remito,
pedido de un cliente total o parcial de un
remito para un DISTRIBUCIÓN del pedido y de los
para un punto de remito que contiene
pedido cortes vacunos (si
entrega los cortes vacunos
corresponde)
Logística de distribución:
El frigorífico organiza la logística de distribución creando recorridos tipo indicando los puntos de
entrega que se deberán visitar, el orden y la duración estimada total del recorrido. Cada vez que un
cliente agrega un punto de entrega es necesario agregarlo a algún recorrido, para que sea posible realizar la
distribución de los productos que el cliente pida. Además, para realizar la distribución, la empresa cuenta con
una flota de camiones con diferentes capacidades en kilos. Para organizar los recorridos genéricos se tiene en
cuenta que los puntos de entrega que se van a incluir en un recorrido deben estar ubicados en la misma
localidad.
Periódicamente se organizan planes de entrega indicando para cada uno, el camión que lo realizará, el
recorrido que se hará, la fecha de salida y los remitos que deberían incluirse. Cuando se finaliza el armado del
plan de entrega, se notificará la fecha y hora planificada de salida del camión mediante un mensaje de texto y
email a todos los clientes que posean algún punto de entrega en el plan.
Además, los camiones cuentan con un módulo de seguimiento satelital (GPS) que permitirán por medio del
sistema web monitorear su recorrido en todo momento y se generarán alertas cuando el camión realiza paradas
fuera de los puntos de entrega o se desvía del camino.
También, se ha pedido que los choferes, puedan disponer de una aplicación mobile que les permita:
• consultar por medio de Google Maps el recorrido que deben realizar, mostrando en el mapa cada uno de
los puntos de entrega en los que deben descargar la mercadería
• registrar el inicio del recorrido.
• registrar el fin del recorrido.
Estos datos brindarán información para estimar la duración de los recorridos y para notificar vía SMS a los
clientes cuando un pedido sea incluido en un plan de entrega próximo a ser enviado.
Para todo esto, tanto el sistema web como la aplicación mobile deben establecer una interfaz con google
maps para resolver la funcionalidad de seguimiento satelital (en el caso del sistema web) y para resolver la
visualización de un recorrido y sus puntos de entrega (en el caso de la aplicación mobile).
Hasta antes que el camión salga con la mercadería y su correspondiente plan de entrega, es posible
modificar un plan de entrega o cancelarlo. La cancelación del plan de entrega deja todos los remitos que estaban
incluidos en estado pendiente. La modificación del plan de entrega puede quitar algunos remitos e incluir otros,
con las actualizaciones de estado correspondientes a cada remito.
Cuando un camión llega a un punto de entrega y un cliente recibe su pedido se le entrega también el
remito físico. En este punto el cliente constatará los cortes recibidos contra el remito y podrán ocurrir 3
situaciones:
1. Los cortes recibidos coinciden con el remito
2. Los cortes recibidos coinciden parcialmente con el remito
3. Los cortes recibidos no coinciden con el remito
Luego el cliente podrá firmar el remito indicando que está conforme con lo recibido en su totalidad o
parcialmente (Situaciones 1 y 2). En el caso de que no esté no conforme no firmará el remito (Situación 3) y el
chofer podrá escribir en el espacio de “Observaciones” el motivo del rechazo. Por ejemplo: Se recibió menos de
lo solicitado, no se recibió el corte pedido, la carne se considera en mal estado, etc.
Cuando el chofer finalice su recorrido, los remitos serán llevados nuevamente al frigorífico donde el
administrador, se encargará de actualizar su estado en el sistema, según corresponda. La actualización de los
remitos implicará la actualización de los pedidos asociados y eventualmente de los cortes vacunos; esto último
en caso de que el cliente los haya devuelto.
En el caso de que un remito haya sido rechazado el responsable de administración podrá generar un
descuento para dicho cliente para su próxima compra. Los descuentos deberán estar tipificados por porcentajes.
Por ejemplo: Descuento del 10%, Descuento del 20%, Descuento del 50%, etc. Al generar el cupón de descuento
se le enviará un mail al cliente indicando que dispone de un cupón de descuento para su próxima compra. El
mismo tendrá fecha de vencimiento pasados 31 días desde su generación.
Por razones de salud pública tanto el frigorífico como los camiones de reparto tienen inspecciones que
constatan la documentación sanitaria y el estado de los cortes vacunos. Si alguna autoridad considera que se
incumple alguna de las normas establecidas para el almacenamiento y traslado de la carne, puede decomisar la
carga y en el sistema debe quedar registrada la razón del decomiso. Los remitos afectados quedarán en estado
Decomisado.
Se presenta el proceso y el momento en que se puede aplicar el descuento:

Creación de plan de
entrega con un
Ejecución de un Recepción de Aceptación/Rechazo Generación
recorrido, un
plan de entrega mercadería del remito descuento
camión y un
conjunto de remitos
Facturación
Cuando el administrador recibe los remitos físicos, registrará si han sido aceptados, rechazados o
aceptados parcialmente en el sistema. Para aquellos que se encuentren aceptados o aceptados
parcialmente el administrador podrá generar una factura para el cliente y punto de entrega que corresponda
incluyendo aquellos cortes que fueron aceptados. La factura deberá tener: número, fecha, CUIT y nombre del
frigorífico, nombre y apellido del cliente y punto de entrega, los kilos de cada corte, precio por kilo y precio total.
Al generar la factura, se calcularán los vencimientos, generalmente se tendrán hasta 3 vencimientos desde la
fecha de emisión de la factura y cada uno con un porcentaje de aumento. En caso de que el cliente disponga de
uno o más cupones de descuento que aún no ha utilizado se aplicará sobre el total de la factura aquel que tenga
la fecha más antigua y se registrará que ha sido utilizado. También se indicará con una leyenda en la factura qué
descuento se ha aplicado sobre el total.
Luego de la facturación el remito pasará a estado Facturado.
Las facturas serán enviadas a los clientes por email. Para poder procesar el envío, el sistema deberá
comunicarse con un servidor de correo externo.
Podrá suceder que una factura se genere de manera incorrecta en cuyo caso podrá ser anulada,
registrando la fecha de anulación, el motivo y el empleado que realizó dicha anulación.
Gráficamente:
Recepción de remitos y
Generación de factura para un Anulación de la factura, de ser
actualización de estado de
cliente necesario
remito y pedido
El sistema deberá mantener información sobre los empleados que usan el sistema. Se deberá asignar
a cada uno un legajo y se guardará su nombre y apellido, CUIL y dirección. Cada empleado tendrá un
usuario y una contraseña de entre 8 y 16 caracteres y que incluya letras y números. Se solicitará al usuario que
renueve la misma cada 30 días por motivos de seguridad. Cada usuario podrá tener uno o más perfiles asignados
con diferentes permisos.
Por otro lado, el sistema deberá ser desplegado de manera que sea seguro y resguarde los datos ante
acceso indebidos o malintencionados.
Reportes
Se solicitará que el sistema pueda generar informes y estadísticas sobre:
• Rendimiento de los cortes vacunos, que se determina a partir de la cantidad de kilos de cada
corte vacuno obtenidos a partir de una res.
• Listado de clientes que más pedidos hacen.
• Efectividad de entregas es el porcentaje de pedidos entregados y aceptados por los clientes sobre el
total de pedidos realizados por los clientes.
Todos los reportes deberán visualizar la información tanto en listados como en gráficos (barra, torta,
dispersión, etc.) y se debe permitir la exportación de los reportes y estadísticas a formato Excel (xls o xlsx) y a
PDF.
Solución Propuesta
Propósito del Sistema
Objetivo:
Administrar los procesos de faena de ganado vacuno, almacenamiento de cortes vacunos y gestión de pedidos y
entregas de un Frigorífico de la Ciudad de Córdoba brindando información vinculada a la gestión realizada.
Alcance: El sistema deberá contemplar los siguientes alcances:

 Administración clientes y puntos de entrega
 Administración de empleados y usuarios
 Administración de las cámaras para almacenamiento
 Administración de camiones
 Gestión de pedidos y remitos
 Gestión de descuentos
 Gestión de la facturación de los pedidos
 Gestión de recorridos y planes de entrega
 Gestión del almacenamiento de los cortes vacunos
 Gestión de usuarios y empleados
 Generación y emisión de estadísticas e informes vinculados cortes vacunos, pedidos y entregas.
No Contempla:
 Gestión de Devoluciones
 Gestión de Cobro por venta.
Reglas de Negocio
Nro. Nombre de la RN Descripción de la Regla de Negocio (RN)
1 Identificación del Cada animal está identificado con un código único llamado CUIG, de acuerdo
ganado con el Sistema Nacional de Identificación de Ganado Bovino que define el
SENASA. Este es una clave de cinco dígitos: dos letras y tres números.
2 Puntos de entrega Un cliente podrá poseer uno o más puntos de entrega. Un punto de entrega
será cualquier domicilio donde el Cliente pueda recibir mercadería. Cuando
realice un pedido deberá indicar para cuál de sus puntos de entrega se solicita el
mismo.
3 Remito Un remito es un documento que comprueba el traslado de mercaderías. Se
deben imprimir tres copias de este para entregar una a cada interesado: cliente,
frigorífico y chofer que transporta la mercadería.
4 Descuentos En el caso de que un remito sea rechazado total, se le ofrecerá al cliente un
cupón de descuento para su próxima compra con fecha de caducidad en los
próximos 31 días.
5 Recepción de Por definición del negocio, los clientes solo podrán recibir mercadería que
mercadería en el tengan fecha de comercialización menor a la actual.
cliente
6 Donaciones Todos los cortes vacunos para los que expiró la fecha de comercialización, pero
aún no han vencido, son donados al banco de alimentos y ya no es posible

incluirlos en remitos.
7 Etiquetado de Se debe etiquetar el estante donde se guarda un corte con la fecha de envasado
estantes con fecha del corte.
de envasado Sólo se podrá utilizar un estante si este posee todas sus secciones libres, para
mantener la consistencia de fechas.
8 Estantes y Los estantes están divididos en secciones asignadas a un corte específico.
secciones En una sección puede haber un único tipo de corte vacuno.
9 Datos del cliente Cuando un cliente va a realizar un pedido por primera vez se registrarán sus
datos: nombre, apellido, CUIT, domicilio, teléfono, mail y puntos de entrega que
posea.
10 Datos de puntos de Para cada punto de entrega, se indicará nombre, domicilio, localidad y barrio.
entrega
11 Registro de pedido Para realizar un pedido el cliente deberá indicar el punto de entrega donde
desea recibirlo y los kilos de cada corte que desea recibir. Se debe guardar un
número de pedido único, secuencial y correlativo, la fecha en que se realizó el
pedido, el cliente que lo solicitó y el estado correspondiente. Si el cliente no ha
abonado las facturas con antigüedad mayor a 2 meses, el cliente no podrá
efectuar un nuevo pedido hasta que no regularice el pago.
12 Política de entrega La empresa tiene una política de entrega de los pedidos dentro de las próximas
en 48 hs 48 horas de realizado este, por lo que no se contemplan pedidos planificados
para una fecha específica, al contrario, los pedidos se entregan lo más rápido
posible.
13 Peso aproximado La preparación del pedido tiene en cuenta los cortes vacunos con fecha de
de pedidos comercialización más cercana y el peso, buscando redondear el peso lo más
cercano al peso solicitado en el pedido, pero teniendo en cuenta que no
siempre es exacto.
14 Datos del remito Los datos del remito son: la fecha de preparación, número de remito y detalle
de cada uno de los cortes vacunos incluidos, asociados a cada detalle de pedido
para un cliente y un punto de entrega.
15 Recorrido Existen recorridos tipo donde se indican los puntos de entrega que se deberán
visitar, el orden y la duración estimada total del recorrido. Cada vez que un
cliente agrega un punto de entrega es necesario agregarlo a algún recorrido,
para que sea posible realizar la distribución de los productos que el cliente pida.
16 Planes de Entrega Periódicamente se organizan planes de entrega indicando para cada uno, el
camión que lo realizará, el recorrido que se hará, la fecha de salida y los remitos
que deberían incluirse. Cuando se finaliza el armado del plan de entrega, se
notificará la fecha y hora planificada de salida del camión mediante un mensaje
de texto y email a todos los clientes que posean algún punto de entrega en el
plan.
17 Modificación y Hasta antes que el camión salga con la mercadería y su correspondiente plan de
cancelación de un entrega, es posible modificar un plan de entrega o cancelarlo. La cancelación del
plan de entrega plan de entrega deja todos los remitos que estaban incluidos en estado
pendiente. La modificación del plan de entrega puede quitar algunos remitos e
incluir otros, con las actualizaciones de estado correspondientes a cada remito.
18 Recepción de Podrán ocurrir 3 situaciones cuando un cliente recibe un pedido:
cortes vacunos 1. Los cortes vacunos recibidos coinciden con el remito
2. Los cortes vacunos recibidos coinciden parcialmente con el remito
3. Los cortes vacunos recibidos no coinciden con el remito

19 Factura La factura deberá tener: número, fecha, CUIT y nombre del frigorífico, nombre y
apellido del cliente y punto de entrega, los kilos de cada corte, precio por kilo,
precio total, vencimientos porcentaje de aumento por vencimiento, descuentos
aplicados.
20 Anulación de Si una factura se genera de manera incorrecta puede ser anulada, registrando la
facturas fecha de anulación, el motivo y el empleado que realizó dicha anulación.
21 Usuarios y Cada empleado tiene legajo, nombre y apellido, CUIT y dirección. Además, si va
empleados a trabajar con el sistema de información, tendrá un usuario y una contraseña
22 Usuarios y perfiles Cada usuario podrá tener uno o más perfiles asignados con diferentes permisos.
23 Cumplimentación Los pedidos tienen asociado un remito al momento de su preparación para
de Pedidos enviar los cortes vacunos al cliente. No se realizan envíos parciales, se manda el
pedido con todos sus detalles en un mismo momento.
24 Cálculo de Efectividad de entregas es el porcentaje de pedidos entregados y aceptados por
efectividad en la los clientes sobre el total de pedidos realizados por los clientes.
entrega de pedidos
25 Cálculo de El rendimiento de los cortes vacunos que se determina a partir de la cantidad de
rendimiento de kilos de cada corte vacuno obtenidos a partir de una res.
cortes vacunos
26 Recorridos para la Para organizar la definición de los recorridos se tiene en cuenta que los puntos
entrega de entrega que se van a incluir en un recorrido deben estar ubicados en la
misma localidad.
Aclaración: Las reglas de negocio relacionadas a los estados y transiciones permitidas entre los estados para los
objetos de la clases Pedido, Corte Vacuno, Remito y Plan de Entrega no están especificadas, porque se espera que
los estudiantes las analicen e identifiquen cuando construyan las máquinas de estado correspondientes.
Listado de Actores
Nombre del Actor Descripción Categoría Tipo

Encargado del área de administración que consultará
Responsable de
reportes y registrará decomisos en el caso de que Persona Concreto
Administración (RA)
ocurran.
Responsable de Pedidos Encargo del registro de pedidos de clientes y la
Persona Concreto
(RP) generación de los remitos asociados.
Responsable de
Encargado de la generación de facturas. Persona Concreto
Facturación (RF)
Responsable de Empleado encargado de planificar las entregas que se
Persona Concreto
Distribución (RD) realizarán y los recorridos.
Empleado encargado de la distribución de los cortes
Chofer (CH) Persona Concreto
vacunos a los diferentes puntos de entrega.
Empleado encargado de ingresar a los animales al
Carnicero (CA) Persona Concreto
frigorífico y del proceso de desposte.
Empleado que utilizará el producto a través de un
Usuario (U) Persona Abstracto
aplicativo móvil o a través de la aplicación web.
Parametrizador de Encargado de la configuración de parámetros del
Persona Concreto
Sistema (PS) sistema.
Vista de casos de uso esenciales
Listado de casos de uso

N° Nombre del Caso de Uso Objetivo / Breve Descripción Actor
Gestión de clientes
1 Registrar Cliente Registrar los datos de un cliente. RP
2 Modificar Cliente Actualizar los datos permitidos de un cliente registrado. RP
3 Consultar Cliente Visualizar datos de uno o más clientes. RP
Dar de baja un cliente registrado del sistema, validando que no
4 Eliminar Cliente RP
tenga transacciones asociadas.
Registrar los datos un punto de entrega de un cliente y calcular
5 Registrar Punto de Entrega RP
sus coordenadas georreferenciales utilizando Google Maps
6 Modificar Punto de Entrega Actualizar los datos permitidos de un punto de entrega. RP
7 Consultar Punto de Entrega Visualizar datos de un punto de entrega. RP
Dar de baja un punto de entrega registrado en el sistema,
8 Eliminar Punto de Entrega RP
validando que no tenga transacciones asociadas.
Gestión de localidades
9 Registrar localidad Registrar los datos de una localidad. PS
10 Modificar localidad Actualizar los datos de una localidad. PS
11 Eliminar localidad Dar de baja una localidad. PS
Consultar los datos de una localidad, validando que no tenga
12 Consultar localidad PS
transacciones asociadas.
13 Registrar barrio Registrar los datos de un barrio. PS
14 Modificar barrio Actualizar los datos de un barrio. PS
Dar de baja un barrio, validando que no tenga transacciones
15 Eliminar barrio PS
asociadas.
16 Consultar barrio Visualizar los datos de un barrio PS
Gestión de Pedidos y Facturación
Registrar un pedido de un cliente para un punto de entrega
17 Registrar pedido RP
indicando los kilos solicitados de cada corte.
18 Consultar pedido Visualizar los datos de un pedido. RP
19 Cancelar pedido Registrar la cancelación de un pedido realizado por un cliente. RP
Generar una nueva factura para los pedidos realizados por todos
Generar facturación de
20 clientes durante un mes determinado, siempre que no hayan RF
pedidos del mes
sido facturados previamente.
Generar una nueva factura para todos los pedidos realizados por
Generar factura para un un cliente para un periodo de tiempo determinado. Debe
21 RF
cliente generar una factura con los pedidos de todos los puntos de
entrega del cliente.
Anular una factura para un Registrar la anulación de una factura determinada, registrando
22 RF
cliente motivo de anulación y responsable de la anulación.
88 Actualizar estado de factura Modificar el estado de una factura determinada. RF
Registrar un nuevo vencimiento con número de vencimiento,

porcentaje de aumento, cantidad de días a partir del cual
Registrar un nuevo
23 empieza aplicarse el porcentaje de aumento. Este vencimiento RF
vencimiento
será asignado a las facturas posteriormente generadas, mientras
no sea dado de baja.
24 Modificar vencimiento Actualizar los datos de un vencimiento existente. RF

25 Consultar vencimiento Visualizar los datos de un vencimiento. RF
Registrar un vencimiento como no vigente, esto implica que las
facturas que ya tienen dicho vencimiento asociado quedarán
26 Dar de baja un vencimiento RF
como están, pero las próximas facturas no podrán estar
asociadas a un vencimiento dado de baja.
Consultar factura para un Visualizar los datos de una factura perteneciente a un cliente
90 RF
cliente determinado.
Realizar el envío por email de una factura ya generada a un
91 Enviar factura por email RF
cliente.
Gestión de recorridos y camiones
Registrar un recorrido asociado a un conjunto de puntos de
27 Registrar recorrido RD
entrega.
Actualizar los datos permitidos de un recorrido registrado en el
28 Actualizar recorrido RD
sistema.
29 Consultar recorrido Visualizar datos de un recorrido. RD
Eliminar un recorrido registrado en el sistema, validando que no
30 Eliminar recorrido RD
tenga transacciones asociadas.
Registrar el inicio de un viaje para un plan de entrega, asignando
31 Iniciar Viaje el valor de la fecha y hora de salida del plan de entrega CH
correspondiente.
Consultar mapa de Visualizar en un mapa los puntos de entrega del recorrido que
32 CH
recorrido tiene un plan de entrega asignado a un chofer determinado.
Registrar el fin de un viaje para un plan de entrega, , asignando la
33 Finalizar viaje CH
fecha y hora de fin del plan de entrega correspondiente.
Registrar los datos correspondientes a un camión para ser
34 Registrar camión RD
asignado a planes de entrega.
35 Modificar Camión Modificar los datos permitidos de un camión, RD
36 Consultar Camión Consultar los datos de uno o más camiones. RD
Eliminar los datos de un camión, validando que no tenga
37 Eliminar Camión RD
Consultar seguimiento geo- Consultar el mapa de visualización de los camiones que se
38 RA
satelital encuentran en viaje, mostrando la posición real de cada uno.
Gestión de Entrega
Generar un remito asignando los cortes vacunos necesarios para
39 Generar Remito cumplir con un pedido pendiente de preparación de un cliente RP
cambiando el estado de los cortes a “Incluido en Remito”.
Actualizar los datos permitidos de un remito, lo que implica que
el mismo está en estado pendiente. Se pueden quitar cortes
40 Modificar Remito RP
vacunos y/o agregar cortes vacunos, actualizando el estado de
los mismos según corresponda.
Cancelar un remito asociado a un pedido y para cada corte
41 Cancelar Remito vacuno que estaba incluido, cambiar su estado de “Incluido en RP
Remito” a “Creado”.
92 Consultar Remito Visualizar los datos de un remito. RP
Registrar la planificación de la entrega de pedidos a un conjunto

42 Generar Plan de Entrega RD
de puntos de entrega.
Actualizar los datos de un Plan de Entrega mientras no haya
iniciado el viaje de reparto. Esto implica quitar y/o agregar
43 Modificar Plan de Entrega RD
remitos actualizando los estados de los mismos según
corresponda.
Cancelar un plan de entrega registrado, mientras el mismo no
44 Cancelar Plan de Entrega haya iniciado el viaje de reparto actualizando el estado de los RD
remitos a pendiente.
Registrar a partir de un remito incluido en un plan de entrega, la
aceptación o rechazo de sus cortes vacunos cambiando el estado
45 Registrar entrega realizada RD
de los cortes a "RecibidoPorElCliente", "Creado" o
“ParaDonación” según corresponda.
46 Consultar Plan de Entrega Visualizar los datos de un plan de entrega. RD
Registrar motivo de
47 Registrar un motivo de rechazo. PS
rechazo
Modificar motivo de
48 Actualizar los datos de un motivo de rechazo. PS
rechazo
Consultar motivo de
49 Visualizar los datos de un motivo de rechazo. PS
rechazo
50 Eliminar motivo de rechazo Deshabilitar un motivo de rechazo. PS
51 Registrar tipo de descuento Registrar un tipo de descuento con sus datos. PS
Modificar tipo de
52 Actualizar los datos de un tipo de descuento. PS
descuento
Consultar tipo de
53 Visualizar los datos de un tipo de descuento. PS
descuento
54 Eliminar tipo de descuento Deshabilitar un tipo de descuento. PS
Generar un cupón de descuento aplicable en pedidos futuros
Generar cupón de para un cliente que haya rechazado un remito por
93 PS
descuento disconformidad, ya sea en forma total o parcial. Al crearse el
cupón, este se envía por mail al cliente.
94 Registrar donación Registrar la donación de un conjunto de cortes vacunos. RD
Gestión de animales
55 Consultar Corte Vacuno Visualizar datos de un corte vacuno. PS
Dar de baja un corte vacuno, validando que no tenga
56 Eliminar Corte Vacuno PS
Registrar Tipo de Corte
57 Registrar un nuevo tipo de corte vacuno con sus datos. PS
Vacuno
Modificar Tipo de Corte
58 Actualizar los datos de un tipo de corte vacuno. PS
Vacuno
Consultar Tipo de Corte
59 Visualizar los datos de un tipo de corte vacuno. PS
Vacuno
Eliminar Tipo de Corte Dar de baja un tipo de corte determinado, validando que no
60 PS
Vacuno tenga transacciones asociadas.
61 Verificar fechas de Corte Controlar automáticamente las fechas de cada corte vacuno -
Vacuno disponible para determinar si alguno debe enviarse a donación o

está vencido actualizando el estado de ser así.
Registrar decomiso de Registrar uno o muchos cortes vacunos en mal estado o
62 RA
mercadería golpeados, dejándolos inhabilitados para su comercialización.
Registrar para un animal todos los cortes vacunos generados,
Registrar desposte de
63 indicando para cada corte el CUIG del animal y el tipo de corte y CA
animal
asignándolo a un estante y sección de una cámara.
Registrar el ingreso ganadero al frigorífico registrando el animal
64 Registrar ingreso de animal CA
con su peso, CUIG y categoría.
Registrar categoría de
65 Registrar los datos de una categoría de un animal. PS
animal
Modificar categoría de
66 Actualizar los datos de una categoría de un animal. PS
animal
Eliminar categoría de Dar de baja una categoría de un animal, validando que no tenga
67 PS
animal transacciones asociadas.
Consultar categoría de
68 Visualizar los datos de una categoría de un animal. PS
animal
Registrar una nueva cámara ingresando el nombre y número de
la misma, indicando la cantidad de estantes de dicha cámara y
69 Registrar Cámara CA
para cada estante sus datos: número y cantidad de secciones y
asignándole a cada sección un tipo de corte.
Registra la asignación de la fecha de desposte de los cortes
70 Asignar fecha a estante CA
vacunos a guardar en un estante.
Modificar los datos de una cámara existente, permitiendo
71 Modificar Cámara cambiar su nombre y número y también todos los datos de los CA
estantes y secciones.
Visualizar los datos de una cámara, mostrando nombre y número
72 Consultar Cámara de una cámara, la cantidad de estantes con sus datos y la CA
cantidad de secciones por estante con sus datos.
Eliminar una cámara determinada del sistema, eliminando
73 Eliminar Cámara también las secciones y los estantes asociados, y validando que CA
no tenga transacciones asociadas.
Actualizar estantes y
74 Registrar la asignación o vaciado de un estante y sección. CA
secciones
Registrar el inicio de sesión de un usuario que accede al sistema
75 Iniciar Sesión con un nombre de usuario y contraseña, validando la contraseña U
y los permisos asignados a ese usuario.
Registrar el cierre de la sesión de un usuario logueado en el
76 Cerrar Sesión U
sistema.
77 Registrar Usuario Registrar un usuario con todos sus datos. U
78 Modificar Usuario Actualizar los datos permitidos de un usuario. U

79 Consultar Usuario Visualizar los datos de un usuario. U
80 Eliminar Usuario Eliminar los datos de un usuario registrado en el sistema, U
validando que no tenga transacciones asociadas.

81 Registrar empleado Registrar los datos de un empleado. PS
82 Modificar empleado Actualizar los datos de un empleado. PS
Dar de baja un empleado, validando que no tenga transacciones
83 Eliminar empleado PS
asociadas.
84 Consultar empleado Visualizar los datos de un empleado. PS
Informes y Estadísticas
Generar informe de Generar informe de Efectividad de pedidos por cliente y

85 RA
efectividad de pedidos localidad.
Generar informe de cortes Generar informe de kilos generados por corte vacuno por
86 RA
vacunos categoría de animales.
Generar informes de
87 Generar un listado de clientes que más pedidos realizan. RA
clientes
Generar estadísticas de Generar una estadística de los pedidos realizados por los clientes
89 RA
pedidos en un período de tiempo
Diagrama de paquetes de casos de uso
Gestión de clientes
uc Gestión de clientes
8 Eliminar
punto de 7 Consultar
entrega punto de
entrega
4 Eliminar 6 Modificar
cliente punto de
entrega
Responsable de
Pedidos
3 Consultar
cliente
5 Registrar
punto de
entrega
2 Modificar «include»
cliente 1 Registrar
cliente
Gestión de localidades
uc Gestión de localidades
10 M odificar
localidad
11 Eliminar
localidad
9 Registrar
localidad
12 Consultar
localidad
16 Consultar Parametrizador
barrio de Sistema
13 Registrar
barrio
15 Eliminar 14 M odificar
barrio barrio
Gestión de Pedidos y Facturación

uc Gestión de pedidos y Facturación
18 Consultar
pedido
19 Cancelar
17 Registrar pedido
pedido
26 Dar de baja
20 Generar un
Responsable de
facturación vencimiento
Pedidos
de pedidos
del mes
25 Consultar
vencimiento
21 Generar
factura para Responsable de 24 Modificar
un cliente facturación vencimiento
88 Actualizar
estado de 23 Registrar
factura un nuevo
22 Anular una vencimiento
90 Consultar 91 Enviar
factura para factura por
un cliente factura para un
cliente email
Gestión de recorridos y camiones

uc Gestión de recorridos y camiones
27 Registrar 28 Actualizar 29 Consultar 30 Eliminar 31 Iniciar viaje

recorrido recorrido recorrido recorrido
32 Consultar
mapa de
recorrido
38 Consultar
seguimiento
geo-satelital
Chofer 33 Finalizar
Responsable de viaje
distribución
34 Registrar
Responsable de camión
Administración
35 Modificar
camión
36 Consultar
37 Eliminar camión
camión
Gestión de Entregas
uc Gestión de Entrega
42 Generar
41 Cancelar
plan de
remito 43 Modificar
40 Modificar entrega
remito plan de
92 Consultar entrega
remito
44 Cancelar
plan de
entrega
39 Generar
remito
45 Registrar
Responsable de
entrega
distribución
Responsable de realizada
Pedidos
54 Eliminar tipo
de descuento 46 Consultar
94 Registrar plan de
donación entrega
53 Consultar
tipo de
descuento Parametrizador de 47 Registrar
Sistema motivo de
rechazo
52 Modificar
tipo de
descuento
48 Modificar
motivo de
51 Registrar rechazo
tipo de 49 Consultar
descuento 50 Eliminar motivo de
motivo de 93 Generar cupón rechazo
rechazo de descuento
Gestión de animales
uc Gestión de usuarios
77 Registrar 78 Modificar 79 Consultar

usuario usuario usuario
76 Cerrar
sesión
80 Eliminar
usuario
75 Iniciar
sesión
Usuario
81 Registrar
empleado
Parametrizador de
Sistema
82 Modificar
84 Consultar
empleado
empleado
83 Eliminar
empleado
Informes y estadísticas
uc Informes y estadísticas
86 Generar 87 Generar
informe de informe de
cortes vacunos clientes
85 Generar
informe de
efectividad
Responsable de
Administración
89. Generar
estadísticas de
pedidos
Descripción de casos de uso

Nombre del Caso de uso: Registrar Pedido Nro. de orden: 17
Actor Principal: Responsable de Pedidos (RP) Actor Secundario: no aplica

Objetivo: Registrar un pedido de un cliente para un punto de entrega indicando los kilos solicitados de cada tipo
de corte vacuno.
Flujo Generación del Pedido para Cliente que no tiene facturas pendientes
1. RP: El caso de uso inicia cuando se selecciona la opción “Registrar Pedido”.
2. Sistema: El sistema busca y muestra el nombre de todos los clientes existentes y solicita que se seleccione el
cliente que está solicitando un nuevo pedido.
3. RP: Selecciona el cliente para el cual registrará un nuevo pedido.
4. Sistema: Busca y muestra para el cliente seleccionado, todos los puntos de entrega registrados. Muestra el
nombre y la dirección de cada punto de entrega y solicita que se seleccione el punto de entrega para el cual
se quiere registrar un pedido.
5. RP: Selecciona el punto de entrega para el cual registrará un nuevo pedido.
6. Sistema: Busca y muestra el nombre de todos los tipos de corte vacuno existentes. Solicita que se
seleccionen los tipos de corte vacuno a incluir en el pedido y que para cada tipo de corte vacuno se indique la
cantidad de kilos pedidos por el cliente.
7. RP: Selecciona los tipos de corte vacuno a incluir en el pedido y para cada tipo de corte vacuno indica la
cantidad de kilos.
8. Sistema: Para realizar un nuevo pedido el cliente no debe tener facturas pendientes de pago de antigüedad
mayor a 2 meses, por lo que el sistema busca las facturas del cliente que se encuentren en estado “Pendiente
de Pago” y valida si las mismas tienen fecha de facturación mayor a los últimos 2 meses y comprueba el
estado de estas e informa si el cliente tiene facturas pendientes de pagar.
9. Sistema: El sistema informa que el cliente no tiene facturas pendientes de pago.
10.Sistema: Solicita confirmación para la generación del pedido.
11.RP: Confirma la generación del pedido.
12.Sistema:
a. Genera un numero secuencial para asignarle al pedido.
b. Crea el pedido para el cliente y el punto de entrega seleccionado con el número de pedido generado, los
datos de los cortes y los kilos ingresados por el usuario, el estado “Pendiente” y el usuario que realizo el
pedido.
Flujos Alternativos
A1: No existen clientes registrados.
A2: No existen puntos de entrega registrados para el cliente seleccionado.
A3: No selecciona un punto de entrega.
A4: No selecciona cortes vacunos a incluir en el pedido.
A5: El cliente tiene facturas con antigüedad mayor a 2 meses, pendientes de pagar.
A6: No confirma la generación del pedido.
Observaciones: Observación 1: El RP puede cancelar el caso de uso en cualquier momento.
Nombre del Caso de uso: Generar remito Nro. de orden: 39

Actor Principal: Responsable de Pedidos (RP) Actor Secundario: no aplica

Objetivo: Generar un remito asignando los cortes vacunos necesarios para cumplir con un pedido pendiente de
preparación de un cliente cambiando el estado de los cortes a “Incluido en Remito”.
Flujo Generación de remito por pedido e impresión en papel
1. RP: El caso de uso inicia cuando se selecciona la opción “Generar remito por pedido”
2. Sistema: Busca todos los pedidos que aún no poseen un remito, muestra los datos de los pedidos (número de
pedido, nombre del cliente (razón social, teléfono, email), nombre del punto entrega y dirección del punto de
entrega) ordenados por fecha ascendente. Solicita seleccionar el pedido para el cual se desea generar un
remito.
3. RP: Selecciona un pedido.
4. Sistema: Busca para el pedido seleccionado y muestra los nombres de los tipos de cortes vacunos solicitados
y los kilos.
5. Sistema: Busca y muestra los cortes vacunos candidatos para cumplir con el pedido, es decir: aquellos cortes
vacunos que tengan un tipo de corte igual al tipo de corte de los detalles del pedido, que estén en estado
creado, y que tengan fecha de comercialización más próxima. (Ver observación 2)
6. Sistema: Solicita se seleccione por cada tipo de corte pedido por el cliente, el o los cortes vacunos para
cumplir con el pedido.
7. RP: Para cada tipo de corte vacuno pedido por el cliente selecciona uno o más cortes.
8. Sistema: Por cada corte que se seleccione, calcula y muestra la suma de kilos acumulados para dicho tipo de
corte.
9. Sistema: Por cada corte vacuno seleccionado, muestra la ubicación de este: sección, estante y cámara donde
se encuentra dicho corte.
10.Sistema: Por cada tipo de corte, valida que la sumatoria de kilos de los cortes vacunos seleccionados es igual
o mayor a los kilos de dicho tipo de corte indicados en el pedido. Y sí se cumple dicha confirmación.
Solicita confirmación para generar el remito.
11.RP: Confirma la generación del remito
12.Sistema: Crea un remito en estado pendiente con los siguientes datos: nro. de remito (buscando el último
nro de remito y sumando 1, fecha y hora de creación, el empleado que está usando el sistema y los cortes
vacunos seleccionados. Actualiza el estado de los cortes vacunos a incluidos en remito. Llama al CU 74
Actualizar estantes y secciones y se actualizaron los estantes y secciones exitosamente.
13.Sistema: Solicita seleccione si desea imprimir el remito, visualizar en pantalla o exportarlo a Excel o pdf.
14.RP: Selecciona la opción de imprimir el remito.
15.Sistema: Imprime el remito con los siguientes datos: nro. de remito, fecha y hora de creación, nombre del
cliente, nombre y dirección del punto de entrega, por cada tipo de corte: nombre, cantidad de kilos, precio
por kilo, importe total (cantidad de kilos * precio por kilo) y por último el importe total del remito. Fin del
caso de uso.
Flujos Alternativos
A1: El RP no confirma la generación del remito

A2: El RP cancela la operación
A3: El RP selecciona visualizar remito por pantalla.
A4: EL RP selecciona enviar remito por email.
A5: EL RP selecciona exportar remito a Excel.
A6: EL RP selecciona exportar remito a PDF.
A7: El CU 74 Actualizar estantes y secciones no finaliza correctamente.
Observaciones:
Observación 1: El usuario podrá cancelar el CU en cualquier momento.
Observación 2: Los cortes disponibles para incluir en el remito se visualizarán junto con un semáforo cuyos
colores dependerán de qué tan conveniente sea el corte para cubrir el pedido:
Semáforo por fecha de comercialización:
→ Rojo: Dentro de los próximos 5 días
→ Amarillo: Dentro de los próximos 10 días
→ Verde: Dentro de los próximos 15 días
Nombre del Caso de uso: Generar Plan de Entrega Nro. de orden: 42

Actor Principal: Responsable de Distribución (RD) Actor Secundario: no aplica

Objetivo: Registrar la planificación de la entrega de pedidos a un conjunto de puntos de entrega, basados en
remitos generados.
Flujo: Generación de Plan de Entrega en PDF
1. RD: El caso de uso inicia cuando se selecciona la opción “Planificar entregas”.
2. Sistema: busca los remitos en estado “Pendiente” y los muestra ordenados por fecha. Para cada remito
muestra la fecha, el número, el cliente, el punto de entrega, y el total de kilos envasados por remito. Solicita
que el usuario seleccione los remitos a incluir en el plan de entrega.
3. RD: Selecciona todos los remitos para ser incluidos en el plan de entrega.
4. Sistema: busca y muestra los recorridos que incluyen al menos uno de los puntos de entrega con remitos
pendientes y solicita seleccionar uno.
5. RD: Selecciona un recorrido.
6. Sistema: resalta y marca los remitos cuyos puntos de entrega están en el recorrido seleccionado y sumariza
los kilos de cortes vacunos de estos remitos.
7. Sistema: solicita indicar fecha y hora planificada de salida para el plan.
8. RD: Selecciona fecha y hora de salida.
9. Sistema: busca los camiones disponibles y operativos. (Ver observación 3). Para cada uno muestra capacidad
y dominio (reflejado en la chapa y patente) y solicita seleccionar uno.
10.RD: Selecciona un camión.
11.Sistema: Solicita confirmar la planificación de la entrega.
12.RD: confirma la planificación de la entrega.
13.Sistema:
a) Genera un numero secuencial para asignarle al plan de entrega.
b) Crea el plan de entrega en estado “Creado”, con el número generado, con la fecha y hora asignada
indicando los remitos a incluir, el camión que realizará la entrega y el recorrido que se hará.
c) Cambia el estado de los remitos incluidos a “Para Entregar” y de los cortes vacunos a “En Plan De Entrega”.
Notifica mediante email y mensaje de texto a todos los clientes que posean algún remito en el plan. (Ver
observación 2).
d) Solicita seleccionar forma de visualización
14. RD: selecciona la forma de visualización archivo PDF.
15. Sistema: Genera un plan de entrega en formato archivo pdf (Ver observación 4). Fin del caso de uso.
Flujos Alternativos
A1: No hay remitos en estado “Pendiente”.
A2: No se selecciona ningún remito a ser incluido en el plan de entrega.
A3: Se seleccionan algunos remitos a ser incluidos en el plan de entrega y otros no.
A4: No encuentra recorridos que incluyan el/los puntos de entrega de los pedidos pendientes.
A5: No confirma la generación del plan de entrega.

A6. El RD selecciona la opción para generar el plan de entrega impreso
A7. El RD selecciona la opción para generar el plan de entrega en excel
Observaciones:
Observación 1: El RD puede cancelar el caso de uso en cualquier momento.
Observación 2: La notificación debe incluir un mensaje informativo, la fecha y hora planificada de salida del
camión y el dominio del camión.
Observación 3: El sistema busca todos los camiones registrados que estén operativos y disponibles, es decir que:
• no estén asignados a algún plan de entrega que esté sin iniciar (sin fecha salida) y que tenga
fecha planificada = fecha ingresada por el usuario
• no estén asignados a algún plan de entrega que esté en curso (sin fecha de fin) y que tenga
fecha de salida = fecha ingresada por el usuario.
Observación 4: El plan de entrega está compuesto por un Encabezado, con la fecha y hora de salida y nombre del
recorrido. En el cuerpo están referenciados los remitos: fecha y número de remito, nombre del cliente y nombre
del punto de entrega. En el pie figura la fecha de emisión del plan de Entrega y un texto para registrar una firma.
Nombre del Caso de uso: Registrar entrega realizada Nro. de orden: 45

Actor Principal: Responsable de Distribución (RD) Actor Secundario: no aplica
Objetivo: Registrar a partir de un remito incluido en un plan de entrega, la aceptación o rechazo de sus cortes
vacunos cambiando el estado de los cortes a "RecibidoPorElCliente", "Creado" o “ParaDonación” según
corresponda.
Flujo Registración de entrega con el rechazo del remito completo
1. RA: El caso de uso inicia cuando se selecciona la opción “Registrar entrega realizada”
2. Sistema: Solicita seleccione fecha desde y hasta.
3. RA: Selecciona fecha desde y una fecha hasta.
4. Sistema: Busca para cada cliente y punto de entrega los remitos en estado “Para entregar” cuyos planes de
entrega se encuentren finalizados, es decir, que posean fecha y hora de fin y cuya fecha se encuentre dentro
del periodo seleccionado. Para cada remito muestra: nro. del remito, fecha, nombre del cliente y nombre del
punto de entrega.
5. Sistema: Solicita seleccionar uno o más remitos.
6. RA: Selecciona un remito.
7. Sistema: Muestra del remito seleccionado: fecha, número, cliente, punto de entrega y nombre de los cortes
vacunos incluidos con sus pesos. Solicita indicar si se acepta el remito completamente, rechaza o si se
aceptan sólo algunos cortes.
8. RA: Selecciona Rechazar el remito completo. Es decir, rechaza todos los cortes vacunos incluidos en el
remito.
9. Sistema: Busca y muestra los motivos de rechazo posibles y solicita se seleccione uno.
10.RA: Selecciona un motivo de rechazo.
11.Sistema: Busca y muestra los tipos de descuentos posibles y solicita se seleccione uno.
12.RA: Selecciona un descuento.
13.Sistema: Solicita confirmación.
14.RA: Confirma la operación.
15.Sistema:
a. Cambia el estado del remito a Rechazado.
b. Valida que la fecha de comercialización de los cortes vacunos rechazados no esté vencida y no lo está.
Actualiza el estado de cada corte vacuno rechazado a Creado.
c. Asigna el motivo de rechazo seleccionado al remito.
d. Genera un nuevo Cupón de descuento con el tipo de descuento seleccionado asociado al cliente del remito.
Flujos Alternativos
A1: El RA cancela la operación.
A2: El RA acepta el remito.
A3: El RA acepta parcialmente el remito.
A4: La fecha de comercialización de uno o más cortes rechazados se encuentra vencida. Se actualiza el estado de
dichos cortes a: “Para donación”.
A5: El RA selecciona más de un remito.
Observaciones:
Observación 1: Un periodo será correcto si la fecha hasta es mayor a la fecha desde, y ambas con formato de
fecha válido.
Nombre del Caso de uso: Generar informe de efectividad Nro. de orden: 85

Actor Principal: Responsable de Administración (RA) Actor Secundario: no aplica
Objetivo: Generar informe de Efectividad de pedidos por cliente y localidad
Flujo: Generación de informe de efectividad con método por pedidos recibidos impreso en papel
1. RA: El caso de uso inicia cuando se selecciona la opción “Generar informe de efectividad”
2. Sistema: El sistema solicita se seleccione la fecha desde y fecha hasta para el informe.
3. RA: Selecciona fecha desde y hasta.
4. Sistema: Valida que el periodo seleccionado sea correcto. (Ver observación 1)
5. Sistema: Busca todas las localidades existentes y solicita se seleccionen una o más localidades.
6. RA: Selecciona todas las localidades.
7. Sistema: Solicita se seleccione el método de cálculo de efectividad.
8. RA: Selecciona método por pedidos recibidos. (Ver observación 2)
10. RA: Confirma la generación del reporte.
11.Sistema: Busca para cada cliente que tenga algún punto de entrega en alguna de las localidades
seleccionadas todos los pedidos que haya solicitado cuya fecha de pedido se encuentre dentro del periodo
seleccionado.
12.Sistema: Busca para cada cliente que tenga algún punto de entrega en alguna de las localidades
seleccionadas todos los pedidos cuya fecha de pedido se encuentre dentro del periodo seleccionado y que
tengan un remito aceptado por el cliente.
13.Sistema: Calcula y muestra por cliente y por localidad el porcentaje de efectividad: total de pedidos
aceptados por el cliente / total de pedidos realizados.
14. Sistema: Muestra dos gráficos con efectividad por localidad y efectividad por cliente y consulta por la
impresión del informe.
15. RA: Sí desea imprimir el informe.
16. Sistema: Imprime el informe. Fin del Caso de uso.
Flujos Alternativos
A1: El RA no selecciona ninguna localidad
A2. El RA selecciona algunas localidades
A3: El RA cancela la operación
A4: El RA selecciona exportar a Excel el reporte
A5: El RA selecciona exportar a PDF el reporte
A6: El RA selecciona método de cálculo de efectividad por pedidos cumplidos parcialmente
A7: El RA selecciona método de cálculo de efectividad por pedidos no realizados
A8: El RA selecciona visualizar por pantalla el informe.

Observaciones:
Observación 1: Un periodo será correcto si la fecha hasta es mayor a la fecha desde, ambas con formato de fecha
válidas.
Observación 2: Los métodos de cálculo de efectividad podrán ser:
A. Por pedidos recibidos: Se calcula como:
𝑃𝑒𝑑𝑖𝑑𝑜𝑠 𝑟𝑒𝑐𝑖𝑏𝑖𝑑𝑜𝑠
𝐸=
𝑇𝑜𝑡𝑎𝑙 𝑑𝑒 𝑝𝑒𝑑𝑖𝑑𝑜𝑠 𝑟𝑒𝑎𝑙𝑖𝑧𝑎𝑑𝑜𝑠
B. Por pedidos cumplidos parcialmente: Se calcula como:
𝑃𝑒𝑑𝑖𝑑𝑜𝑠 𝑟𝑒𝑐𝑖𝑏𝑖𝑑𝑜𝑠 + 𝑃𝑒𝑑𝑖𝑑𝑜𝑠 𝑟𝑒𝑐𝑖𝑏𝑖𝑑𝑜𝑠 𝑝𝑎𝑟𝑐𝑖𝑎𝑙𝑚𝑒𝑛𝑡𝑒
𝐸=
C. Por pedidos no realizados: Se calcula como:
𝑃𝑒𝑑𝑖𝑑𝑜𝑠 𝑟𝑒𝑐ℎ𝑎𝑧𝑎𝑑𝑜𝑠
𝐸=
Nombre del Caso de uso: Generar informe de cortes Nro. de orden: 86

Actor Principal: Responsable de Administración (RA) Actor Secundario: no aplica

Objetivo: Generar un informe que muestre los kilos y los montos de cada tipo de corte vacuno generado y
entregado por categoría de animal.
Flujo Generar informe de cortes con visualización en PDF
1. RA: El caso de uso inicia cuando se selecciona la opción “Generar informe sobre cortes”
2. Sistema: El sistema solicita se seleccione la fecha desde y fecha hasta para el informe.
3. RA: Selecciona fecha desde y hasta.
4. Sistema: Valida que el período seleccionado sea correcto. (Ver observación 1)
5. Sistema: Busca todas las categorías de animales existentes y solicita se seleccionen una o más. (Ver Obs. 3)
6. RA: Selecciona todas las categorías de animales
7. Sistema: Busca y muestra todos los tipos de cortes existentes y solicita se seleccionen uno o más.
8. RA: Selecciona más de un tipo de corte.
10.RA: Confirma la generación del reporte.
11.Sistema: Busca todos los remitos que se encuentren dentro del periodo seleccionado en estado “Facturado”,
que posean algún corte vacuno de los seleccionados y de las categorías seleccionadas, de ser así suma su
peso.
12.Sistema: Busca las facturas asociadas a los remitos filtrados y calcula el total facturado por tipo de corte.
13. Sistema: Genera y muestra un gráfico de barras para los kilos vendidos por corte y categoría y otro para el
dinero recibido por corte y categoría.
14.Sistema: Solicita seleccionar tipo de visualización.
15. RA: Selecciona generar como PDF.
16.Sistema: Publica el informe. Fin del caso de uso.
Flujos Alternativos
A1: El RA cancela la operación
A2: No existen cortes o categorías
A3: El RA desea imprimir el informe.
A4: El RA desea exportar a Excel el informe.
A5: El RA selecciona visualizar por pantalla el informe.
Observaciones:
Observación 1: Un periodo será correcto si la fecha hasta es mayor a la fecha desde, y ambas con formato de
fechas valido.
Observación 3: Ejemplos de categorías de animales: terneros hasta 140 kg, terneros de más de 140 kg y novillos.
vaquillonas
Modelo de Dominio
Vista de clases de análisis para la realización del CU 17 Registrar Pedido
Realización de Análisis del CU 17 Registrar Pedido – Con diagrama de comunicación
Realización de Análisis del CU 17 Registrar Pedido – Con diagrama de secuencia
Vista de clases de análisis para la realización del CU 39 Generar remito
Realización de Análisis del Caso de Uso 39 Generar Remito con Diagrama de Comunicación
Realización de Análisis del Caso de Uso 39 Generar Remito con Diagrama de Secuencia
Vista de clases de análisis para la realización del CU 42 Generar plan de entrega
Realización de Análisis del 42 Generar plan de entrega – Con diagrama de comunicación
Realización de Análisis del 42 Generar plan de entrega – Con diagrama de secuencia
Vista de clases de análisis para la realización del CU 45 Registrar entrega realizada
Realización de Análisis de CU 45 Registrar entrega realizada con diagrama de secuencia
Realización de Análisis de CU 45 Registrar entrega realizada con diagrama de comunicación
Vista de clases de análisis para la realización del CU 85 Generar informe de efectividad
Realización de Análisis de CU 85 Generar informe de efectividad con diagrama de secuencia
Vista de clases de análisis para la realización del CU 86 Generar informe de cortes
Realización de Análisis de CU 86 Generar informe de cortes con diagrama de secuencia
Máquina de estado del Corte Vacuno
Máquina de estado del Remito
Universidad Tecnológica Nacional
Facultad Regional Córdoba
Ejercicio práctico tipo parcial 1
Ing. en Sistemas de Información
Se pide al Estudiante que lea y analice atentamente la situación planteada y en base a

ello:
1. Construya la máquina de estados de la clase OrdenReubicacion, utilizando un diagrama

de máquina de estados. Especifique asociado a las transiciones los métodos y cuando
corresponda las condiciones control. (25 puntos)
2. Modele la realización de caso de uso de análisis para el escenario del caso de uso
descripto, para ello:
a. Construya la vista de estática con un diagrama de clases que incluya las clases
necesarias para dar soporte al escenario descripto y a la máquina de estados
construida en el punto 1. (35 puntos)
b. Modele el escenario descripto en el caso de uso, utilizando un diagrama de
secuencia. Aplique los patrones GRASP de Análisis. (40 puntos)
Dominio: La Estrella de la Muerte
Glosario:
• Droides: Robots que poseen inteligencia artificial. El imperio utiliza estos robots para todas las operaciones que
pueden ser peligrosas para otros soldados. También para dar soporte en operaciones militares complicadas.
• DS-MK: Nombre clave que utiliza el imperio de manera oficial para referirse al proyecto de construcción de la
estación espacial de gran tamaño conocida por los soldados del imperio como “Estrella de la Muerte”
• Unidad Militar: Es un elemento organizacional dentro de las fuerzas armadas bajo el mando de un líder o jefe. La
unidad militar básica es un escuadrón que está compuesto por entre 7 y 15 soldados.
• Tipo de Unidad Militar: El tipo de una Unidad Militar se refiere al lugar que la Unidad Militar ocupa en la jerarquía.
Estos tipos pueden ser: escuadrón, pelotón, compañía, batallón, brigada, división o cuerpo armado.
Son tiempos de guerra civil en la galaxia. Un grupo armado clandestino llamado “Alianza Rebelde” ha atacado
diversas bases de operaciones del Imperio Galáctico. El Emperador Palpatine ha ordenado a su comandante en jefe de
las fuerzas armadas, Darth Vader, que se encargue de los rebeldes para traer paz y estabilidad a la galaxia. Darth Vader
ha comisionado una estación espacial de gran tamaño para transportar tropas más rápida y cómodamente a lo largo
de la galaxia, esta estación espacial también estará armada para permitir tomar acciones defensivas y ofensivas contra
la Alianza Rebelde. Esta estación espacial es conocida con el nombre clave DS-MK, pero los soldados del imperio la
llaman “Death Star” o “Estrella de la Muerte”. La Estrella de la Muerte puede transportar entre 1 y 1.5 millones de
personas (Entre las cuales se encuentran soldados de diversos rangos, médicos, cocineros, etc.). Se necesita un
software especializado que controle todos los aspectos de la estación, desde los accesos a las distintas áreas hasta las
raciones y suministros que se encuentran en la misma.
La armada imperial tiene su propia organización militar avanzada ya que deben patrullar y proteger toda la
galaxia. Dentro de la Estrella de la Muerte se maneja una jerarquía similar a la que suele manejar el resto de la armada
imperial. La unidad más pequeña es un Escuadrón compuesto por entre 7 y 15 soldados (llamados Stormtroopers) y
liderado por un teniente. Estas unidades militares son de una especialidad dada (Infantería, Artillería, Unidades
Especiales, Paracaidistas, Pilotos, etc.) y todos los miembros del escuadrón tienen el mismo entrenamiento y
habilidades de combate. Además de esto, cada Escuadrón cuenta con al menos un soldado con entrenamiento como
médico de campo, (cumple su función de médico sólo durante una misión) y un soldado con entrenamiento de cocina
de campo, (cumple su función de cocinero sólo durante una misión). A su vez un grupo de 4 o 5 escuadrones componen
un Pelotón que es liderado por un comandante. Todos los escuadrones de un pelotón son de la misma habilidad. Un
grupo de 2 a 4 pelotones componen una Compañía que es liderada por un capitán. Los pelotones dentro de una
compañía pueden tener distintas especialidades para lograr misiones más completas. De esta forma, si se debe realizar
un ataque a gran escala se puede utilizar diversas habilidades de combate. Además, se puede planificar misiones
pequeñas que requieran de distintos escuadrones para complementar habilidades. Un grupo de 2 a 5 compañías
forman un Batallón que es liderado por un comodoro. Un grupo de 2 a 6 batallones forman una brigada que es liderada
por un Vicealmirante. Un grupo de 4 a 5 brigadas forman una división que es liderada por un Almirante. Finalmente,
un grupo de 2 a 7 divisiones forman un cuerpo armado, que es liderado por un Gran Almirante. Debería haber al menos
2 cuerpos armados completos en la Estrella de la Muerte en todo momento. Toda esta estructura se encuentra al
mando de Darth Vader, que ocupa el cargo de Comandante en Jefe de las Fuerzas Imperiales. Darth Vader responde
solo ante la autoridad del Comandante Supremo, Darth Sidious.
Cada una de estas unidades militares posee un número identificatorio que se combina con una letra que indica
su jerarquía. Entonces un Cuerpo Armado puede tener el numero identificatorio “CP-1”. La cantidad de dígitos de este
número no tiene restricción ya que puede haber miles de unidades militares a lo largo de la Galaxia. Además de esto,
cada unidad militar tiene un emblema identificatorio único elegido por su líder (Un Gran Almirante en el caso de un
Cuerpo Armado) que permite a otras unidades una rápida identificación en caso de encontrarse. Este emblema debe
ir acompañado siempre del símbolo imperial oficial para su tipo de unidad. Estos símbolos se ilustran en la tabla, son
iguales para todas las unidades del mismo tipo.
Para cualquier individuo que se encuentre habitando la estación espacial, es importante conocer su nombre
completo, su planeta de origen, su raza, su fecha de nacimiento y su fecha de ingreso al ejército. En caso de los solados
debe conocerse también su código de identificación único dentro del ejército (Un código alfanumérico generado
automáticamente al enlistarse) y su rango. Darth Vader ha especificado que es muy importante mantener un registro
de los cambios de rango de cada soldado ya que algunas de las misiones planeadas sólo pueden ser asignadas a
soldados y/o líderes con mayor experiencia.
Las tropas duermen en habitaciones conjuntas por Escuadrón. Cada habitación tendrá una pantalla sobre la
puerta que indicará toda la información del escuadrón que duerme en la habitación. Esto es el emblema de ese
escuadrón, su número de identificación y los números de identificación de todas las unidades militares superiores a
las que pertenece dicho escuadrón (pelotón, compañía, brigada, etc.). Cada teniente duerme junto a su escuadrón,
pero el resto de los oficiales de alto rango duerme en habitaciones separadas por rango junto a otros oficiales de alto
rango de su propia unidad militar. La estrella de la muerte cuenta con diversas Secciones Habitacionales identificadas
Ciclo lectivo 2023 Turnos: Todos Hoja: 2 de 9

por colores. A lo largo de los pasillos de las secciones habitacionales hay luces LED que cambian de color según el color
de la sección. Cada sección está asignada a un cuerpo armado y no puede haber soldados asignados a otro cuerpo
durmiendo en la sección. Darth Vader puede cambiar como están delimitados los módulos habitacionales, creando
algún módulo nuevo, eliminando un módulo o reasignado las divisiones. Las luces LED que marcan las distintas
secciones deben cambiar de color según el color asignado por Darth Vader. Todas las habitaciones son iguales ya que
se desea tener gran flexibilidad a la hora de transportar las tropas.
Por esta razón el Imperio permite que se creen nuevas unidades militares de cualquier tipo correspondientes
a una unidad de orden superior ya existente. También está permitido mover una unidad militar para que pertenezca a
cualquier otra. Por ejemplo, el pelotón P-501 era parte de la Compañía C-1103, pero luego de la Guerra de los Clones
fue movido a la Compañía C-609 encargada del patrullaje de los sistemas exteriores. Esta flexibilidad es la que permite
que el Imperio responda de forma rápida y eficiente a las diversas necesidades de los ciudadanos del imperio.
Para mover unidades militares de una base militar a otra se utiliza una Orden de Reubicación. Esta Orden de
Reubicación puede ser iniciada por un oficial con rango de comandante o superior. Un oficial no puede generar
Órdenes de Reubicación para una unidad militar que sea superior a él en la jerarquía, es decir que un comandante no
puede generar una Orden de Reubicación para un Batallón. El oficial debe indicar que unidad militar desea reubicar,
que oficial se hará cargo ahora de la unidad militar (Indicando su nombre, rango y el número identificatorio de la
unidad militar que encabeza), el lugar o base al cual se reubicará a la unidad militar, el motivo por el que se reubica a
esa unidad y una fecha óptima para que las tropas ocupen su nuevo puesto. Para que una Orden de Reubicación sea
ejecutada, debe ser aprobada por al menos un oficial de rango superior al que generó la orden. Este oficial puede
aceptar o rechazar la Orden de Reubicación. Las únicas excepciones son las órdenes generadas por Darth Vader o un
Gran Almirante, esas órdenes están aprobadas desde su creación. Una vez que la Orden ha sido aprobada, la misma
debe ser comunicada a las tropas afectadas para que puedan prepararse para el movimiento, esta comunicación debe
incluir el motivo de la Reubicación, la base a donde han sido asignados y la fecha de salida de la base actual. Si la Orden
no es comunicada a las tropas, entonces no es posible ejecutar la salida de la base origen. Si la comunicación no se
realiza antes de la fecha de vencimiento de la Orden, entonces la misma se considera como vencida y no puede
ejecutarse. En ese caso debe comunicarse al oficial que la creó mediante un correo electrónico. Una vez comunicada
la orden y llegada la fecha de salida, las tropas salen de su base actual camino a la nueva base. En este punto se
considera que la Orden está en proceso. Cuando las tropas llegan a la nueva base militar y han sido acomodadas en
sus habitaciones se considera que la Orden fue ejecutada. Darth Vader desea obtener estadísticas respecto al
cumplimiento de las órdenes, es por eso por lo que es de extrema importancia diferencias las ordenes que se
Ejecutaron satisfactoriamente (Es decir, las que cumplieron con todas las fechas óptimas) y las que se Ejecutaron
insatisfactoriamente (Es decir, las ordenes en las que las tropas llegaron luego de la fecha optima de llegada). Para
simplificar la mejora del proceso de ejecución de órdenes, Darth Vader ha pedido que se registren todas las fechas de
actividad de una Orden. Finalmente, una Orden de Reubicación puede ser cancelada por el oficial que la creó si todavía
no ha sido aprobada.
Darth Vader quiere que el software de la Estrella de la Muerte pueda manejar el hospedaje de todo aquel que
habite la estación espacial, la gestión de expediciones y misiones militares que salgan de la misma y la gestión de los
suministros necesarios para mantener a todos los habitantes de la Estrella de la Muerte.

Definición del Producto de Software a construir:
Objetivo del Producto de Software:
Gestionar el hospedaje del personal militar de la Estrella de la Muerte, las expediciones militares y los
suministros necesarios para su mantención, generando información relacionada a las expediciones y el consumo de
suministros militares.
Alcances del producto de software:
• Administración de unidades militares y personal auxiliar (Médicos, cocineros, etc.)

• Administración de droides
• Gestión de soldados con sus rangos militares a lo largo de su carrera militar.
Reglas de Negocio para el Producto de Software Gestión de personal militar de La Estrella de La

Muerte
Creación de la Orden de Un oficial con rango de comandante o superior puede crear una Orden de Reubicación para
Reubicación una unidad militar inferior a su rango en la jerarquía. Debe indicar las unidades militares a
reubicar, el oficial que estará a cargo de las unidades a mover, la nueva base de la unidad
militar, el motivo de la Reubicación y la fecha óptima de ejecución de la orden.
Aprobación de una Para que una orden sea ejecutada, debe ser aprobada por al menos un oficial de rango
orden de Reubicación superior al que generó la orden. La orden puede ser aceptada o rechazada. Si la orden se
rechaza se debe comunicar la situación al oficial que la creó.
Excepción en la Las órdenes de reubicación creadas por Darth Vader o un Gran Almirante no necesitan ser
creación de órdenes de aprobadas. Están aprobadas desde su creación.
reubicación
Comunicación de una Una vez que la Orden ha sido aprobada, la misma debe ser comunicada a las tropas afectadas
orden de reubicación para que puedan prepararse para el movimiento, esta comunicación debe incluir el motivo
de la Reubicación, la base a donde han sido asignados y la fecha de salida de la base actual.
Vencimiento de Si la aprobación y comunicación no se realiza antes de la fecha de vencimiento de la orden
órdenes de reubicación de reubicación, entonces la misma se considera como vencida y no puede ejecutarse. En ese
caso debe comunicarse al oficial que la creó mediante un correo electrónico.
Salida de la base actual Una vez comunicada la orden de reubicación y llegada la fecha de salida, las tropas salen de
su base militar actual camino a la nueva base militar. En este punto se considera que la orden
reubicación está En Proceso.
Finalización de una Cuando las tropas llegan a la nueva base militar y han sido acomodadas en sus habitaciones
Orden de Reubicación se considera que la orden de reubicación fue ejecutada. Una orden de reubicación puede ser
ejecutada satisfactoriamente si se cumplió con la fecha optima de ejecución o ejecutada
insatisfactoriamente si no se cumplió con la fecha óptima de ejecución.
Cancelación de una El oficial que creó la Orden de Reubicación puede cancelarla hasta antes de que haya sido
Orden de Reubicación. aprobada.
Rangos Militares de los Darth Vader ha especificado que es muy importante mantener un registro de los cambios de
soldados rango de cada soldado ya que algunas de las misiones planeadas sólo pueden ser asignadas
a soldados y/o líderes con mayor experiencia.

Nombre del Use Case: Registrar Orden de Reubicación Número: 30

Actor Principal: Oficial Actor Secundario:
Objetivo: Crear una orden de reubicación de una unidad militar desde una base de origen a una base destino.
Flujo Descripto: Oficial de rango Gran Almirante registra una orden de reubicación
1. Oficial: Selecciona la opción para registrar una orden de reubicación.
2. Sistema: Valida el rango del oficial logueado y es de Gran Almirante. (Ver Observación 1)
3. Sistema: Busca y muestra todas las bases registradas en el sistema. Solicita que se seleccione de que base es la
unidad militar por reubicar.
4. Oficial: Selecciona una base militar.
5. Sistema: Busca y muestra todas las unidades militares asignadas a esa base militar. Para cada unidad militar
muestra su número identificatorio, el nombre y apellido del soldado líder y el número identificatorio de su
unidad militar contenedora si la hubiera. Solicita que se seleccione una unidad militar.
6. Oficial: Selecciona una unidad militar.
7. Sistema: Solicita que se seleccione la base militar de destino de las tropas de la unidad militar.
8. Oficial: Selecciona una base militar de destino.
9. Sistema: Busca y muestra todos los líderes de unidades militares de la base militar de destino seleccionada.
Para cada soldado muestra su nombre, apellido y número identificatorio de la unidad militar que lidera.
Solicita que se seleccione el nuevo líder a guardar en la orden de reubicación.
10. Oficial: Selecciona el nuevo líder de la unidad militar.
11. Sistema: Solicita que se ingrese un motivo de reubicación y una fecha óptima de ejecución de la orden de
reubicación, confirmando la creación de la orden de reubicación.
12. Oficial: Ingresa un motivo de reubicación y una fecha óptima de ejecución, confirmando la registración de la
orden de reubicación.
13. Sistema: Solicita se confirme la creación de la orden de reubicación.
14. Oficial: confirmando la registración de la orden de reubicación.
15. Sistema: Registra la orden de reubicación en estado aprobada indicando la unidad militar que se traslada, la
base de origen, la base de destino, el nuevo oficial a cargo de la unidad militar, el motivo de la reubicación, la
fecha óptima de ejecución, la fecha de registro de la orden, el responsable de registrarla y genera un número
de identificación automático. Fin del caso de uso.
Flujos Alternativos
A1. El usuario es un oficial de rango inferior a comandante
A2. El usuario es un oficial de rango de comandante o superior e inferior a Gran Almirante
A3. Se selecciona visualizar la orden de reubicación por pantalla
A4. Se selecciona imprimir la orden de reubicación
A5. Se selecciona visualizar la orden de reubicación mediante el tablero holográfico
Observación 1: Un oficial solo puede crear una orden de reubicación si su rango es de comandante o Superior. Si el rango del
oficial es de Gran Almirante o superior la Orden creada se aprueba de manera automática. Un oficial con rango menor a Gran
Almirante solo puede reubicar tropas de Unidades Militares bajo su comando, mientras que los Grandes Almirantes o rango
superior pueden reubicar tropas de toda la galaxia.

Cátedra de Diseño de Descripción del
Sistemas de Información Caso de
PRIMER PARCIAL Estudio
Dominio: Seguimiento de Entrenamientos

Se desea crear un sitio web y una aplicación móvil que permita a corredores, atletas u otro tipo de deportistas
rastrear y registrar sus actividades de ejercicio físico, específicamente correr, caminar o andar en bici. Los
deportistas pueden crear una cuenta gratuita y usar la aplicación para registrar sus rutas de carrera,
distancia, ritmo y tiempo. La aplicación también ofrece información detallada sobre las calorías quemadas,
la elevación del suelo y el clima durante la actividad.
Al crear una cuenta se debe registrar nombre, apellido, email e indicar tu fecha de nacimiento, altura, peso,
sexo y país de origen.
Configuración de Meta de Entrenamiento
La aplicación permite a los deportistas crear metas de entrenamiento personalizadas. Al definir una meta de
entrenamiento, se pueden seleccionar diferentes parámetros como el tipo de actividad (carrera, ciclismo,
caminata), el tipo de objetivo, es decir si se mide por duración, distancia o frecuencia semanal de los
entrenamientos. También se especifica el período en días durante el cual se desea alcanzar la meta de
entrenamiento y la fecha de inicio para comenzar a medirla que puede ser distinta del momento de la
creación.
Por ejemplo, una meta de entrenamiento de distancia podría ser “correr 50 kilómetros en un mes a partir
del 1 de julio de 2023”, y una meta de entrenamiento de frecuencia semanal sería “caminar 3 veces por
semana durante un mes a partir de hoy”. Al cumplirse la fecha de inicio de la meta de entrenamiento, la
aplicación enviará notificaciones para ayudar al deportista a mantener el rumbo hacia su objetivo. Es decir,
si creo una meta hoy con fecha de inicio para el 1 de julio 2023, sólo a partir de ese día comenzará a validarse
el avance de la meta de entrenamiento.
Entrenamientos y Rutas
Una vez creada una meta de entrenamiento, la forma de cumplimentarla es a través de los entrenamientos
que se realizan a lo largo del periodo estipulado. Es importante destacar que sólo puede existir una meta de
entrenamiento por tipo a la vez. Si el deportista desea crear una meta de entrenamiento cuyo periodo y tipo
coincide con otra ya existente, el sistema solicitará que cancele la preexistente antes de crear una nueva; de
forma que sea simple determinar a qué meta de entrenamiento corresponde cada entrenamiento realizado.
Mientras no se superpongan periodos por cada tipo de actividad, el sistema permite al corredor que registre
todas las metas de entrenamiento a futuro que desee.
Cuando el deportista inicia un entrenamiento la aplicación utiliza la señal del GPS para determinar la
ubicación actual y registrar la distancia (en Km) recorrida a medida que se mueve. Se registrará además la
fecha y hora de inicio y fin del ejercicio de forma de poder calcular la duración del entrenamiento. La
aplicación también puede proporcionar información adicional sobre la velocidad, el ritmo y la elevación del
suelo durante la ejecución de la actividad. Una vez finalizado el entrenamiento, la ruta recorrida queda
marcada y es posible visualizarla al consultar el listado de entrenamientos. Cuando se registra un
entrenamiento, la aplicación validará si corresponde o no asociarlo a alguna meta de entrenamiento. Es
decir, el deportista puede registrar entrenamientos de diferentes de tipos de actividades, pero para el avance

Cátedra de Diseño de Fecha: 20/05/2023

Sistemas de Información
PRIMER PARCIAL
de la meta de entrenamiento sólo se consideran aquellos que corresponden al tipo de actividad de la meta
de entrenamiento cuyo periodo esté vigente.
El cumplimiento de una meta de entrenamiento depende entonces de dos factores, el avance del tiempo y
los entrenamientos registrados en el periodo definido. Por esa razón para medir el avance de una meta, el
sistema debe controlar con cada entrenamiento realizado si se alcanza el objetivo definido. Por ejemplo,
para una meta de correr por distancia, cada vez que el deportista finaliza una carrera se debe sumar la
distancia actual a las distancias de las actividades anteriores para determinar si son iguales o mayores a la
distancia objetivo. Pero también puede suceder que avancen los días y no se registre ningún entrenamiento.
En este caso el control del avance se realizará una vez por día de manera automática validando que la fecha
actual no sea igual a la fecha de inicio más el periodo en días configurado para la meta. En ambos casos, se
enviará una notificación al usuario cuando se produzca un cambio en el avance de la meta de entrenamiento.
Según el tipo de objetivo de la meta habrá diferentes formas de calcular su avance. Cuando el tipo de objetivo
es de distancia deberán sumarse las distancias recorridas en cada entrenamiento; Si es de tipo duración,
deberá calcularse la duración total de todos los entrenamientos asociados a la meta; Si es de tipo frecuencia,
se deberán contar la cantidad de entrenamientos semanales. En cualquier caso, si los entrenamientos
realizados cumplen el valor objetivo configurado para la meta de entrenamiento en el periodo definido
entonces la meta de entrenamiento se alcanzó.
Reportes y Estadísticas
La aplicación elabora diferentes reportes y estadísticas que permiten al deportista hacer un seguimiento de
su progreso y desempeño de cada entrenamiento.
Se requiere generar un resumen de indicadores de entrenamiento que muestre detalles como la distancia
recorrida, el tiempo empleado, la velocidad y la elevación del suelo, en un periodo de tiempo.
El sistema muestra además estadísticas detalladas sobre el progreso del deportista a lo largo de un mes,
incluyendo la situación de cada meta de entrenamiento que es alcanzada y el tiempo que permanece en
progreso hasta que se alcanza.

Cátedra de Diseño de Fecha: 20/05/2023

PRIMER PARCIAL

Cátedra Diseño de
Universidad Tecnológica Nacional Descripción del
Facultad Regional Córdoba Sistemas de Información
Caso de Estudio
PRIMER PARCIAL
Dominio: PlateUp – Kits de Comida
PlateUp es un servicio de entrega de recetas junto con los ingredientes necesarios pre-porcionados para
prepararlas, para lograr que cocinar en casa sea más fácil y práctico. Los clientes pueden armar su propio
plan alimentario según sus preferencias dietarias y escoger de una variedad de recetas, y recibir las recetas
con sus ingredientes directamente en la puerta de su casa semanalmente. La compañía tiene como
objetivo hacer que cocinar en casa sea más conveniente, económico y agradable para sus clientes.
Las recetas de PlateUp son desarrolladas por un equipo de chefs profesionales y están diseñadas para
ser rápidas y fáciles de preparar.
Cada receta tiene asociada un nombre, una descripción, una categoría dietaria, tiempo de preparación,
tiempo total de cocción y dificultad (fácil, medio, difícil). Una receta puede corresponder a más de una
categoría dietaria a la vez. Por ejemplo, “Milanesas con puré” corresponde con la categoría dietaria “Carne
y vegetales” y también a “Rápida y simple”. Además, cada receta tiene una serie de pasos para realizarse.
Las recetas están hechas de forma tal que una receta equivale a una porción para una persona.
Cada receta lleva una serie de ingredientes. Un ingrediente puede estar en distintas recetas. De acuerdo
con la receta, el ingrediente estará presente en diferentes proporciones. Los ingredientes podrán
trabajarse en distintas unidades de medida (como gramos, litros o unidades) de acuerdo con el tipo de
ingrediente que se maneje.
PlateUp funciona con un servicio de suscripción semanal, mediante el cual los clientes reciben una vez a
la semana un kit de comida con todas las recetas y sus ingredientes pre-porcionados. Para poder acceder
al servicio de suscripción de PlateUp, los clientes deben registrarse indicando todos sus datos: nombre,
apellido, DNI, dirección de envío, correo electrónico y teléfono celular.
PlateUp no tiene planes alimentarios definidos por defecto, por lo cual cada cliente –una vez registrado–
diseña su propio plan alimentario de acuerdo con sus necesidades y preferencias. Cada plan alimentario
tiene fecha de creación y de cierre, un nombre, un código identificatorio, una o varias categorías dietarias
seleccionadas por el cliente (carne y vegetales, vegetariana, apta para consumo familiar, saludable, rápida
y simple, marina, etc.), la cantidad de personas destinatarias del plan alimentario, y la cantidad de recetas
semanales que se enviarán. Por ejemplo, se puede definir un plan alimentario llamado “Semanales de
Pollo”, que tenga las categorías dietarias carne y vegetales y rápida y simple, para 3 personas y con 3
recetas, seleccionando recetas como “Pollo a la plancha con vegetales”, “Pollo teriyaki”, y “Pollo
Cacciatore”. El cliente recibirá entonces un kit de comida con los ingredientes pre-porcionados suficientes
para hacer tres porciones de cada una de las tres recetas.
La única forma de acceder al servicio es suscribiéndose. Un cliente puede tener asociada una única
suscripción. Para determinar el costo de esta suscripción se asocia una tarifa de servicio, que representa
el precio base que se paga por suscribirse. Esta tarifa es modificable en el tiempo por lo que tiene una
vigencia, y es igual para todos los planes alimentarios. A este precio se le suma un cálculo que varía para
cada plan alimentario de acuerdo con la cantidad de personas y la cantidad de recetas, y se determina en
función de eso el precio por persona y el precio total a pagar por el plan alimentario que suscribe el cliente.
Un cliente puede tener activos varios planes alimentarios, y a cada plan alimentario se le asocian los kits
Ciclo lectivo: 2023 Págin a |1
Cátedra Diseño de Fecha: 20/05/2023

PRIMER PARCIAL Nota:__________
de comida que el cliente desea recibir. El precio final que pagará un cliente en una suscripción al servicio
de PlateUp se compondrá de la tarifa base (por suscripción) y un monto adicional por cada plan alimentario
activo que tenga.
Cuando el cliente se registra, se le solicita que diseñe su plan alimentario, para lo cual se le pide que
personalice todas las opciones de éste (cantidad de personas, preferencias alimenticias, cantidad de
recetas por semana). En este punto se le muestra el catálogo de recetas disponible para que conforme su
plan alimentario. A la hora de elegir las recetas, al cliente se le recomendarán de manera prioritaria las
recetas de la o las categorías dietarias que haya escogido inicialmente, pero tendrá acceso a todas las
recetas disponibles. Esto implica que seleccionar una o más categorías dietarias no tiene un costo extra.
Una vez conformado el plan alimentario, este se registra con estado Inactivo. Los planes alimentarios
inactivos permanecen registrados un máximo de dos semanas luego de su creación, tiempo en el que el
cliente debe activar su plan alimentario pagando su suscripción mediante medios electrónicos (tarjeta de
crédito, débito o Mercado Pago). Registrado el pago, se coloca al plan alimentario en estado Activo, y se
define que, a partir de esa fecha, cada siete días, se le cobrará el monto correspondiente a su suscripción.
A partir de un periodo de tiempo, y de acuerdo con el comportamiento de los clientes en lo referente a

la recepción de los kits de comida, se les ofrecerán descuentos y promociones en su suscripción, pudiendo
recibir kits de comida gratis o descuentos en alguno de sus planes alimentarios. Para poder analizar a
quienes otorgar esos beneficios se necesita mantener información de los estados por los que pasó cada kit
de comida y determinar un patrón de comportamiento de los clientes.
El kit de comida que se enviará al domicilio registrado por el cliente consiste en todas las recetas y todos
los ingredientes pre-porcionados necesarios para realizar dichas recetas. Se envía un kit de comida por
plan alimentario activo que tenga el cliente. Los kits de comida se preparan semanalmente una vez que se
activa el plan alimentario al que están asociados.
Las recetas escogidas por un cliente para su plan alimentario pueden cambiar en el tiempo en tanto y
en cuanto el plan alimentario esté activo, por lo que es importante tener registro de qué recetas se envían
al cliente en una semana determinada.
PlateUp prepara kits de comida de lunes a viernes, para luego despacharlos por la tarde del viernes. Los
clientes recibirán sus kits entre sábado y domingo dependiendo de donde sea el domicilio consignado para
la entrega.
Si no se desea recibir un kit de comida en una semana en particular, el cliente tiene la opción de pausar
uno o varios de sus planes alimentarios. Pausar un plan alimentario implica que esa semana el cliente no
recibirá el kit de comida asociado a él. La pausa es temporal y se activará el plan alimentario nuevamente
de forma automática.
Se desea que el software genere estadísticas para facilitar la toma de decisiones, respecto de las recetas
más solicitadas, y del porcentaje de kits que se entregaron exitosamente con respecto a los que no. Esta
información debe estar disponible en formato PDF o Excel.
Ciclo lectivo: 2023 Págin a |2

Compilado de Todos Los Casos Practicos, Simulacro y 1er Parcial Practico

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Compilado de Todos Los Casos Practicos, Simulacro y 1er Parcial Practico

Cargado por

Copyright:

Formatos disponibles

Universidad Tecnológica Nacional – Facultades Regionales Córdoba y Villa María

Cátedra de Diseño de Sistemas de Información

Proyecto Prá ctico de Aplicació n

Objetivos de la Asignatura con respecto al PPA:

Contenidos de la Asignatura que se abordarán en el PPA:

PPA_Festival de Folklore_Completo.docx, Versión 1.36

Consigna asociada al Proyecto Práctico de Aplicación:

Criterios de Evaluación del PPA (Si aplica):No Aplica

PPA_Festival de Folklore_Completo.docx, Versión 1.36

Descripción del Dominio asociado al Proyecto Práctico de Aplicación

PPA_Festival de Folklore_Completo.docx, Versión 1.36

Requerimientos del producto

Requerimientos Funcionales (Alcances):

PPA_Festival de Folklore_Completo.docx, Versión 1.36

Nº Nombre Regla de Negocio – Descripción

1 Formas de Pago La única forma de pago aceptada es de contado efectivo.

PPA_Festival de Folklore_Completo.docx, Versión 1.36

Especificación de los Casos de Uso esenciales

Vista Esencial de Casos de Uso del Sistema de Información

uc Casos de Uso Esenciales

PPA_Festival de Folklore_Completo.docx, Versión 1.36

Listado de Casos de Uso

Nro. de Caso de Uso Nombre del Caso de Uso

1 Registrar venta de entradas

2 Registrar grupo musical

PPA_Festival de Folklore_Completo.docx, Versión 1.36

Nro. de Caso de Uso Nombre del Caso de Uso

PPA_Festival de Folklore_Completo.docx, Versión 1.36

Descripción de Casos de Uso–

Trazo Fino o Completamente Descripto

Actor Principal: Encargado de Ventas (EV) Actor Secundario: no aplica

Post- Condiciones Éxito:Entrada/s generada/s e impresa/s, disponibilidad de butacas actualizada.

PPA_Festival de Folklore_Completo.docx, Versión 1.36

PPA_Festival de Folklore_Completo.docx, Versión 1.36

Reglas de Negocio Asociadas:

PPA_Festival de Folklore_Completo.docx, Versión 1.36

Resumen Esencial o Trazo Medio

Prioridad: Alta Media Baja

Actor Principal: Encargado de Ventas (EV) Actor Secundario: no aplica

Tipo de Use Case: Concreto Abstracto

PPA_Festival de Folklore_Completo.docx, Versión 1.36

Trazo Fino o Completamente Descripto

Actor Principal: Responsable de Festival (RF) Actor Secundario: no aplica

3. RF: selecciona el festival al que le desea generar la

PPA_Festival de Folklore_Completo.docx, Versión 1.36

7.A.1.A.1. SI: Informa la situación y permite

12.B. EV: No confirma la diagramación.

PPA_Festival de Folklore_Completo.docx, Versión 1.36

Resumen Esencial o Trazo Medio

Nombre del Use Case: Generar Diagramación ID: 3

Prioridad: Alta Media Baja

Actor Principal: Responsable de Festival (RF) Actor Secundario: no aplica

Tipo de Use Case: Concreto Abstracto

PPA_Festival de Folklore_Completo.docx, Versión 1.36

Trazo Fino o Completamente Descripto

Actor Principal: Responsable Festival (RF) Actor Secundario: no aplica

PPA_Festival de Folklore_Completo.docx, Versión 1.36

9.A.1. SI: informa la situación y permite reingresar

13. Fin del Caso de Uso.

PPA_Festival de Folklore_Completo.docx, Versión 1.36

Resumen Esencial o Trazo Medio

Nombre del Use Case: Registrar Festival ID: 05

Actor Principal: Responsable Festival (RF) Actor Secundario: no aplica

Flujo Básico (Curso Normal)