TALLER 01: EJERCICIOS DE MODELADO REQUERIMIENTOS PARTE I

Anlisis de sistemas

Presenta
David Camilo Snchez Mora
Camilo Andrs Frontado
Hctor Felipe Hurtado Acosta
Yojhan Leonardo Rodriguez Ascencio

Docente
Juan Carlos Guevara B.

Universidad Distrital Francisco Jos de Caldas

Tecnologa en Sistematizacin de datos
Facultad Tecnolgica
Bogot D.C Colombia - Noviembre 18 del 2015

Ejercicios
Ejercicio 01: Complete el siguiente proceso de colaboracin entre un cliente y
una empresa de venta por catlogo. El cliente lleva a cabo las siguientes
actividades (no necesariamente en este orden): pide un artculo, paga el artculo
y pregunta sobre el estado de su pedido (el cliente pregunta una vez realizado
el pedido cada 3 das si no ha recibido el encargo). En la compaa de ventas
existen 3 roles: encargado de pedidos, almacn y contabilidad. El primero
recibe los pedidos de artculos, y tranquiliza al cliente cuando ste pregunta por
el estado de su encargo, en almacn se prepara la entrega y se enva al
repartidor (una empresa externa) y el repartidor la entrega y recibe el pago. El
ltimo rol de la compaa es contabilidad que registra los envos y los pagos.
Complete el diagrama inferior, indicando la estructura de control, los mensajes
necesarios y las puertas.
Modelo de Procesos

 Modelo de Dominio

Glosario de trminos
Termino

Descripcin

Almacn

Es la clase encargada de preparar el envo y entregrselo al

repartidor

Articulo

Es la clase encargada de representar el artculo que ser

administrado y comprado por el cliente,

Cliente

Representa al cliente que solicitara un envi para la compra

de un artculo.

Contabilidad

Es la clase encargada de registrar los envos y los pagos.

Encargado Pedidos

Es el ente encargado que tomara el pedido del cliente y lo

tranquilizar.

Envo

Es la clase en la cual se le asigna un artculo para ser

repartido al cliente.

Pago

Es una clase que controla los pagos de los clientes y los

registra.

Pedido

Es la solicitud generada por el cliente a la hora de

seleccionar un articulo

Repartidor

Es el encargado de recibir el pago y de entregar el artculo a

su destino.

 Ejercicio 02: Gestin incidencias en una empresa de desarrollo de software.

Se pretende modelar el/los proceso(s) de una empresa de desarrollo de
software que se encargan de tramitar las incidencias de los clientes. Los
clientes cuando tienen un problema con el software se dirigen a su responsable
de cuentas, el responsable de cuentas tratar primero de resolver el problema y
de explicar una solucin al cliente si esto es posible. En caso contrario el
responsable de cuentas se pondr en contacto con el agente de soporte de
producto de primer nivel, el cual puede enviar la peticin a un agente de soporte
de producto de segundo nivel. El agente de soporte de segundo nivel puede
resolver el problema del cliente o bien si no est seguro puede preguntar al
equipo de desarrollo. En cualquier caso, al final del proceso el gestor de
cuentas debe explicar una posible solucin al cliente.
Modelo de Procesos

 Modelo de Dominio

Glosario de trminos
Termino

Descripcin

Agente Soporte

Son los primeros en ser comunicados si el responsable de

cuentas no lograr solucionar el error y a su vez emitir el fallo
al equipo de desarrollo en caso de que este agente no pueda
dar solucin a la incidencia.

Cliente

Representa al cliente que solicitara una incidencia por mal

funcionamiento del software.

Equipo Desarrollo

Es el equipo encargado del desarrollo de software y el cual,

si otros autores no han podido, solucionar el fallo
presentado.

Incidencia

Es el fallo o error que el cliente comunica a su agente de

soporte y que este intenta solucionar.

Peticin

Es la clase encargada de la comunicacin entre los agentes

de soporte.

Responsable Cuentas

Es el encargado de ofrecerle una solucin al cliente en caso

de tener alguna incidencia en su software.

Solucin

Es el software modificado solucionando la incidencia que el

cliente presentaba.

 Ejercicio 03: Gestin de reclamaciones compaa aseguradora de vehculos.

Se pretende modelar el proceso de gestin de reclamaciones en una compaa
aseguradora. Cuando se recibe una reclamacin, sta se registra en el sistema.
Despus del registro, la reclamacin se clasifica en uno de los dos siguientes
tipos: simple o compleja. Si la reclamacin queda clasificada como simple se
comprueba el seguro del cliente, para reclamaciones complejas se comprueba
independientemente el seguro y el dao en el vehculo. Despus de la
comprobacin o comprobaciones se genera una resolucin de la reclamacin, que
puede ser positiva o negativa. Si la resolucin es positiva se informa al garaje para
autorizar la reparacin y se planifica el pago al mismo. Para cualquier tipo de
resolucin (positiva o negativa) se enva una carta al cliente y el proceso termina.
Modelo de Procesos

 Modelo de Dominio

Glosario de trminos
Termino

Descripcin

Seguro

Esta clase representa el seguro que adquiri el usuario sobre

el vehculo

Carta

Es la clase que representa la carta de respuesta que genera

el rea de reclamos luego de la reparacin del carro,
especificando todos los detalles respecto al hecho.

Cliente

Es la clase que representa al cliente del sistema.

rea de reclamos

Representa el rea de reclamos de la empresa que ejecuta

la mayora de los trmites cuando se recibe una reclamacin.

Reclamacin

Esta clase contiene todos los detalles de la reclamacin

hecha por el cliente que se entrega al rea de reclamos

Empresa

Esta clase representa los datos de la empresa que maneja

todo lo relacionado la administracin de clientes y el seguro

Resolucin

Esta clase representa la respuesta de a la reclamacin del

usuario, Es la que autoriza o no la reparacin del vehculo.

Reparacin

Esta clase representa todos los detalles de la reparacin del

vehculo hecha por el garaje

Garaje

Representa el rea de la empresa que se encarga de hacer

todas las reparaciones del vehculo si tiene una autorizacin

Vehculo

Es la clase que representa el vehculo del usuario que ser

sometido a reparacin si la reclamacin es positiva

Ejercicio 04: El caso de estudio seleccionado es una versin ms general del

problema conocido como
Conference Review System distribuido en la conferencia OOPSLA de 1991. Una
solucin propuesta por J. Rumbaugh puede consultarse en la columna de anlisis
y diseo del Journal of Object Oriented Programming. El propsito del sistema es
dar soporte a los procesos de envo, evaluacin y seleccin de artculos, va Web
para una conferencia o congreso. Se desea crear un sistema basado en el Web
que permita gestionar las tareas asociadas a la celebracin de un congreso desde
que se crea la convocatoria hasta que se enva la lista de artculos aceptados y
rechazados. El sistema ha de ser usado por los siguientes tipos de usuarios:
El presidente de la conferencia que es el responsable de gestionar la misma,
entre sus atribuciones se encuentra:
Determinar las reas o tpicos de inters y fijar las diversas sesiones.
Elegir al comit de programa y registrarlo en el sistema.
Fijar las fechas importantes: inicio y finalizacin de envos, notificacin de
aceptacin o rechazo, envo de versiones definitivas.
Detectar conflictos de intereses en la revisin de artculos.
Hacer visible a los miembros del comit de programa la lista de artculos
enviados.
Asignar artculos a los miembros del comit de programa, de acuerdo a las
preferencias mostradas por stos.
Cambiar el rea de artculos enviados.
Decidir sobre el proceso de revisin de artculos.
Enviar las revisiones a los autores.
Los miembros del comit de programa son los encargados de revisar los
artculos. Las atribuciones son las siguientes:
Indicar preferencias por reas o temas.
Indicar inters o conflicto con los artculos enviados.
Descargarse artculos.
Enviar revisiones
Modificar revisiones, si estas se encuentran dentro del plazo permitido.
Los autores tienen como atribuciones u obligaciones:
Registrarse en la conferencia.
Registrar a los coautores de un artculo.
Enviar un artculo.
Modificar un envo antes de que finalice el plazo.
Un requisito adicional establece la existencia de un sistema de autentificacin que
permite que los distintos tipos de usuarios puedan acceder nicamente a la
funcionalidad y a la informacin que les concierne.

 Modelo de Procesos

 Modelo de Dominio

Glosario de trminos

Termino

Descripcin

rea

Esta clase describe el espacio fsico donde se encuentra un

articulo

Articulo

Esta clase describe el elemento que se est evaluando para

ser o no publicado

Autor

En esta clase se almacena la informacin de quien redacta el

articulo

Coautor

Esta clase describe los datos de autores apartes al primer

autor directo

Conferencia

Esta clase describe los datos de las conferencias que se dan

para hablar de artculos

Conflicto

Esta clase describe excepciones que se presentan a la hora

de evaluar correcciones de artculos

Comit

Esta clase presenta las reas especializadas encargadas de

la evaluacin de artculos

Fechas

Esta clase tiene los datos en los cuales se evala, presenta y

corrige los artculos

Inters

Esta clase representa los motivos que tiene el presidente

para enviar o no un articulo

Login

Es la clase donde se permite el acceso al usuario

Miembro de comit

En esta clase se encuentran almacenados los datos de los

miembros que evalan los artculos

Password

Es la que permite la validacin a la plataforma

Preferencia

Esta clase corresponde al inters de evaluacin de cada

articulo

Proceso

Esta clase contiene datos especficos del proceso que lleva a

cabo cada articulo

Presidente

Es la clase que corresponde al usuario presidente encargado

de la mayora de casos de uso en el sistema

Usuario

Es la clase padre de las sub-clases Presidente, miembro de

comit y autor y es la que acoge los atributos comunes entre
estos.

Ejercicio 05: Se desea informatizar la gestin de reservas de un hotel, los

requisitos informales pueden describirse de la siguiente forma:

Los clientes pueden efectuar reservar anticipadas. El hotel admite tantas

reservas como habitaciones libres tenga. Las reservas telefnicas tienen que
estar respaldadas por un nmero de tarjeta de crdito. Si en la fecha de
reserva no se presenta el cliente, se genera una factura que se enva a la
compaa de tarjetas de crdito.
Hay dos tipos de clientes: los individuales y los que pertenecen a empresas.
Para los clientes de empresa no es necesario garantizar las reservas mediante
una tarjeta de crdito.
Cuando un cliente llega al hotel su reserva es procesada, comprobndose la
misma con los detalles que proporciona el cliente.
Hay clientes que solicitan una habitacin en el mostrador del hotel.
Algunos clientes solicitan habitaciones para no fumadores.
Las habitaciones se pueden alquilar para dormir nicamente, con media
pensin o con pensin completa.
Cuando los clientes abandonan el hotel, un empleado comprueba los detalles
de ocupacin (llamadas telefnicas, servicio de bar, etc) y genera una factura
para el cliente.
Hay clientes, que pertenecen a empresas, que no abonan la factura en ese
momento. A final de mes se enva una factura nica a la empresa.
El sistema tendr tres tipos de usuarios: los empleados de mostrador o
recepcin, el gerente y un administrador. El gerente se encargar de gestionar
las cuentas de empresas: tipo de descuento por habitacin, apertura de cuenta
y cierre de cuenta. El administrador se encargar de efectuar un
mantenimiento sobre la informacin que se almacena en el sistema. Por ltimo
los empleados de mostrador se encargan de la gestin de clientes.

Modelo de Procesos

 Modelo de Dominio

 Glosario de trminos
Termino

Descripcin

Administrador

Es la clase que corresponde al usuario administrador

Cliente

Esta clase representa el usuario del sistema

Consumo

Esta clase representa todos los gastos del cliente durante la

reserva

Datos

Esta clase contiende los datos de la reserva hecha por un

usuario

Descuento

Esta clase representa el descuento a la factura que se hace

a los clientes empresariales.

Empleado

Esta clase representa al empleado que administra todos los

aspectos respecto al cliente y a las reservas del hotel

Factura

Esta clase representa todo el consumo del usuario dentro del

hotel as como el valor a pagar luego de finalizar la reserva

Gerente

Esta clase representa al gerente que administra las cuentas

empresariales

Habitacin

Esta clase representa la habitacin asignada al cliente en la

reserva

Mantenimiento

Esta clase pertenece a la labor hecha por el usuario

administrador

Pago

Esta clase representa el pago del cliente luego de que recibe

la factura de consumo

Reserva

Esta clase representa la reserva hecha por el cliente de

manera telefnica o presencial

Tarjeta crdito

Esta clase corresponde a los datos tomados de la tarjeta de

crdito cuando se hace uso de ella

Usuario

Es la clase padre de las sub-clases Cliente, Empleado,

Administrador y Gerente y es la que acoge los atributos
comunes entre estos.

Ejercicio 06: La compaa de metro de la ciudad de Valencia desea implantar una

tarjeta inteligente (smartcard) que facilite la adquisicin de billetes y el
desplazamiento de los viajeros por las distintas lneas de metro de la ciudad. La
tarjeta puede adquirirse en mquinas expendedoras situadas en las distintas
estaciones. Los viajeros indican el saldo con el cual quieren cargar la tarjeta al
adquirirla (20, 30, 50 euros), el pago se hace en la mquina expendedora en
efectivo (en cuyo caso no se devuelve ningn importe) o bien utilizando una tarjeta
de crdito que el sistema valida frente a la entidad emisora. En la tarjeta queda
grabada la fecha de adquisicin, la fecha de vencimiento (vlida durante 2 meses),
el importe y la forma de pago. Para acceder a la estacin se utiliza la tarjeta en los
tornos de entrada. Al llegar al destino se pasa nuevamente por un torno de salida
que dependiendo del recorrido efectuado descuenta del saldo la cantidad
correspondiente. En caso de no disponer de saldo el torno de salida no se abre y
el viajero tiene que efectuar una recarga. Los fines de semana existen
promociones o descuentos en los desplazamientos que tambin se aplican a los
viajeros con tarjeta .En la tarjeta se graban los distintos recorridos efectuados por
el viajero (hora de entrada, estacin origen, hora de salida, estacin destino y
fecha). La tarjeta puede recargarse tantas veces como se desee (no es necesario
que est agotada o sin saldo) e incluso pude devolverse en una mquina
expendedora para obtener el saldo actual. Si se adquiri en efectivo el viajero
obtiene el importe en efectivo, si se adquiri con tarjeta de crdito la devolucin se
efecta sobre la misma. Los inspectores de metro disponen de dispositivos
mviles que permiten leer el contenido de las tarjetas para evitar usos
fraudulentos.

 Modelo de Procesos

Modelo de Dominio

 Glosario de trminos
Termino

Descripcin

Descuento

Esta clase representa los descuentos aplicados a las tarjetas

de acuerdo a la fecha de su uso.

Maquina

Esta clase representa a la mquina que permite las recargas

de las tarjetas o la adquisicin de una nueva.

Pago

Est clase representa el medio de pago que escoge el

usuario para recargar la tarjeta

Paso

Esta clase contiene los datos de el paso generado por el

torniquete

Tarjeta

Esta clase representa a las tarjetas del sistema que adquiere

y usa el usuario dentro del sistema

Tarjeta crdito

Esta clase representa el medio de pago de tarjeta de crdito

escogido por el usuario al recargar la tarjeta

Torno

Es la clase que representa a la mquina que valida el pas

de los usuarios

Usuario

Esta clase representa al usuario del sistema

Ejercicio 07: Se desea modelar el funcionamiento de un aparcamiento pblico de

automviles. Cuando un conductor se acerca a la mquina situada en la entrada,
debe pulsar un botn para obtener el resguardo de aparcamiento, una cmara
graba la matrcula que se almacena en el resguardo junto a la hora de entrada.
Cuando el resguardo es retirado se abre la barrera de entrada la cual se cierra
unos instantes despus de detectar el paso del vehculo. Para salir del
aparcamiento los conductores primero abonan el importe asociado a la estancia
en un cajero automtico, ste graba la hora de pago en el resguardo de
aparcamiento, dejando un margen de 10 minutos para abandonar las
instalaciones. Para salir de una manera efectiva el conductor introduce en la
mquina situada en la salida el resguardo de aparcamiento, en ese momento el
sistema lee la matrcula del vehculo, comprueba la hora de pago y levanta la
barrera de salida, la cual se cierra unos instantes despus de detectar el paso del
vehculo. El aparcamiento funciona tambin para abonados, los cuales para entrar
y salir del aparcamiento deben introducir una tarjeta magntica. En la tarjeta se
graba la matrcula al entrar y se comprueba a la salida. Para facilitar el pago de los
conductores no abonados se desea implantar un sistema por telefona mvil que
mediante mensajes SMS permita pagar la estancia en el aparcamiento. Al entrar el
usuario recoge el ticket de entrada y para salir enva un mensaje SMS con el
nmero de ticket, el importe se carga en la factura de telfono. El sistema
informtico del aparcamiento recibe el mensaje SMS de confirmacin del pago.

Para salir el conductor introduce el ticket de entrada y pulsa un botn de la

mquina que indica pago telefnico, el sistema comprueba si el usuario ha
enviado el mensaje SMS, en cuyo caso abre la barrera de salida. En este caso se
aplican tambin los 10 minutos de margen para abandonar las instalaciones.

Modelo de procesos

Modelo de Domino

Glosario de Trminos
Trminos

Descripcin
Esta clase describe el sitio al cual el usuario va a ingresar

Parqueadero
Esta clase representa al usuario del parqueadero.
Conductor
SMS
Tarjeta
Pago

Esta clase describe el mensaje que el usuario enva al salir

del parqueadero para poder salir.
Es la clase describe los datos del vehiculo y del usuario que
entra al parqueadero
Es la clase en la cual se almacena el pago que hizo el
usuario luego de enviar el sms.
Esta clase representa la barrera de acceso del parqueadero

Sistema
Ticket

En esta clase se diligencia para los usuarios no abonados

que entran al parqueadero.

Ejercicio 08: Se desea construir un portal Web que permita a los usuarios
reservar y comprar billetes de avin. Cualquier usuario puede introducir una
ciudad origen, una ciudad destino y una fechas de viaje y el sistema responde con
un conjunto de vuelos (directos o con transbordos) que cumplen los criterios
introducidos por el usuario. A partir de la respuesta del sistema el usuario puede
seleccionar la compra de un vuelo (de ida o de ida y vuelta), esta seleccin se
aade a la cesta de la compra del usuario. La nica forma de pago admitida es
mediante tarjeta de crdito, para ello el usuario debe proporcionar su nombre
completo, el nmero y tipo de la tarjeta y la fecha de caducidad. Los usuarios
deben registrarse previamente proporcionando un login y password junto con los
datos de la tarjeta de crdito. Para que el(los) billete(s) puedan ser tramitados
debe tambin proporcionarse el nombre y apellidos de los viajeros. Una vez
formalizada la compra el sistema genera un nmero de ticket y el billete
electrnico que se remite posteriormente a la aerolnea correspondiente. Los
billetes pueden ser comprados en cualquier momento hasta 3 das antes de la
realizacin del viaje. El sistema tambin admite anulaciones, pero stas
nicamente pueden hacerse 15 das antes del vuelo. En este caso se cobra al
cliente el 6% de la operacin.. El sistema interactuar con un sistema global de
reservas de vuelos como Amadeus o Galileo, que ser el encargado de
proporcionar la disponibilidad de plazas y vuelos. En cualquier momento un
usuario registrado puede acceder a sus datos almacenados y eventualmente
modificarlos (login, password, tarjeta de crdito).

Proceso 1

Modelo de dominio 1

Proceso 2

Modelo de domino 2

Proceso 3

Modelo de dominio 3

Proceso 4

Modelo 4

Modelo conjunto

Glosario de Terminos

Trminos

Descripcin

ciudad

Esta clase representa a la Clase padre ciudad destino y

ciudad origen.

usuario

Est clase representa a la clase padre de viajero y cliente

destino

Esta clase representa la ciudad destino que el cliente

selecciona

origen

Esta clase representa la ciudad destino que el cliente

selecciona

cliente

Esta clase representa al usuario que se ha registrado en el

sistema.

viajero

Esta clase representa al usuario que viajara.

billete

Esta clase representa el los datos del viaje que se realizara

ticket

Esta clase representa la confirmacin a la compaa del viaje

comprado

Vuelo

Esta clase describe los atributos del vuelo que se realizara

Login

Esta clase describe el nombre del usuario registrado

Password

Esta clase valida la entrada del cliente a la interfaz de

compra

Modificacin

Esta clase describe los cambios que se han realizado a los

datos del cliente.

Datos

Esta clase describe los datos del cliente o del viajero.

fecha

Esta clase describe el momento en que se realizara el vuelo.

Ejercicio 09: A continuacin se describe el funcionamiento de una empresa de

confeccin que fabrica productos para grandes cadenas de distribucin. La
empresa subcontrata a otros fabricantes los procesos de manipulacin necesarios
para confeccionar sus productos, ya que sta nicamente compra el hilo (algodn)
o la materia prima. En sus instalaciones dispone de maquinaria para cortar los
patrones, el resto de los procesos de transformacin: tejedura, tintado,
estampado, etc. son subcontratados a otras empresas. La organizacin trabaja
bajo pedidos de grandes clientes, al principio de cada temporada los clientes
pactan los modelos y las cantidades de prendas que van a solicitar. Al inicio de la
temporada de ventas se reciben los pedidos y durante la misma se reciben a su
vez pedidos de reposicin. Los pedidos de grandes clientes deben ser enviados
directamente a las tiendas, con la particularidad de que tanto los pedidos iniciales
como los de reposicin tienen un plazo de entrega estipulado (a veces es a los 15
das de la recepcin y otras veces es al mes de la recepcin), por lo que las
prendas contenidas en un pedido deben estar fabricadas o en proceso de
terminacin su fabricacin. Los pedidos se reciben en formato electrnico (EDI,
electronic Data Interchange), cada pedido contiene una serie de centros de
entrega (direccin fsica de las tiendas donde se entregan los artculos) junto con
la lista de artculos que se recibirn en el centro. Las secretarias seleccionan
aquellos pedidos que deben servirse antes. Crean una nota de entrega (o packing
list) por pedido que contiene como se ha mencionado anteriormente la lista de
centros y artculos destinados a cada centro. El jefe de almacn recibe la nota de
entrega de un pedido y debe distribuir el pedido en cajas de entrega (dependiendo
de la cantidad solicitada por cada centro, a veces se utiliza una caja y otras veces
varias) y pasa esta informacin a los mozos de almacn. De acuerdo a la
disponibilidad de gnero las cajas se rellenan con las prendas disponibles,
producindose las siguientes situaciones:
a. Una caja se llena completamente.
b. Una caja no puede rellenarse completamente.
Las cajas son validadas por el jefe de almacn, en el sentido de que una caja
parcialmente llena puede enviarse si el jefe de almacn sabe que no va a llegar
ms gnero antes de que se tenga que enviar el pedido, o bien si la cantidad de
prendas que faltan es muy pequea comparado con el total del pedido. En el caso

de que se espere gnero la caja queda en espera de ser completada. Una vez
recibido gnero se intenta completar las cajas parcialmente llenas. El proceso de
espera se interrumpe si el pedido tiene que enviarse ya, en ese caso el jefe de
almacn decide si la caja se enva o no. Obviamente la nota de entrega puede ser
modificada en el almacn (se enva menos gnero del solicitado, incluso algunos
centros no se pueden servir) y se enva de vuelta a las secretarias. Las secretarias
para cada caja contenida en la nota de entrega generan un albarn que se enva
al almacn y all se sita en la caja correspondiente. Una vez que la nota de
entrega est procesada, se avisa a una empresa de transporte que recoge las
cajas y las entrega en los centros correspondientes.

Modelado de proceso

Modelo de dominio

Glosario de Trminos

Trminos

Descripcin

Trabajado

Esta clase representa a la Clase padre de los trabajadores

de la fabrica

Jefe

Est clase describe los atributos del trabajador jefe.

Secretaria

Esta clase representa la trabajadora que recibe los EDI

Albarn

Esta clase representa la orden de envi para la distribucin

de pedidos.

Patrones

Esta clase describe las caractersticas del pedido

Cliente

Esta clase representa la persona que realiza el pedido.

Cantidad

Esta clase representa la magnitud del pedido.

Pedido

Esta clase representa las caractersticas del pedido

EDI

Esta clase describe el mensaje que es enviado a la

secretaria con las caractersticas del pedido.

Caja

Esta clase representa la forma de almacenamiento del

pedido.

Transportadora

Esta clase representa la empresa que distribuye los pedidos

a los clientes.

Ejercicio 10. Considere el siguiente proceso para admitir estudiantes

internacionales en una universidad. Los estudiantes rellena un formulario en lnea
que incluye detalles personales, direccin de contacto, seleccin del programa que
quieren cursar y algunos detalles relativos a su formacin. Las solicitudes
presentadas va Web se almacenan en un sistema de informacin al que tienen
acceso todo el personal implicado en los procesos de admisin. Los estudiantes
no envan ningn documento electrnicamente, ellos tienen que imprimir y firmar
el formulario de solicitud y enviarlo por correo postal con los siguientes
documentos:
a. Certificacin de su expediente acadmico.
b. Resultados de su test oficial de conocimiento del lenguaje ingls.
c. Currculum Vitae.
La documentacin suele tardar 2 semanas en llegar al servicio de estudiantes
mediante el correo ordinario. Cuando los documentos se reciben fsicamente se
comprueban en el citado servicio. Esta operacin suele durar 10 minutos, cuando
se detecta que algn documento falta se enva un correo electrnico al estudiante
que debe enviar de nuevo los documentos que faltan o los que son incorrectos.
Esto sucede en el 20% de los casos. Con la informacin recibida el servicio de
estudiantes enva copias certificadas de los documentos a una agencia de
evaluacin externa. La agencia comprueba la documentacin y verifica que las
asignaturas cursadas se corresponden o son equivalentes a las asignaturas de la
universidad. La agencia requiere que la documentacin se enve fsicamente por
correo ordinario, y todos los documentos deben ser copias certificadas de los
originales. Esta restriccin no puede ser cambiada por la universidad. La agencia
enva a su vez de vuelta por correo ordinario los resultados de la evaluacin. Se
tarda una media de 2 semanas en enviar la documentacin a la agencia y en
recibir el resultado de la evaluacin. Alrededor de un 10% de las solicitudes se
rechazan despus de esta comprobacin. Las notificaciones de rechazo se envan
por correo electrnico a los estudiantes afectados. Una vez que se dispone de los
resultados de la agencia, en el servicio de estudiantes se comprueba los
resultados del test de conocimiento de ingls. Esto se hace introduciendo en un
sistema de informacin un cdigo de comprobacin que aparece en la parte
superior de la hoja de resultados del test de ingls. Si los resultados del test de
evaluacin del idioma ingls no son satisfactorios la solicitud se rechaza. La
comprobacin de los resultados del test dura unos 10 minutos. Alrededor del 10%
de las solicitudes son rechazadas en este trmite. Las notificaciones de rechazo
se envan por email. Una vez que todos los documentos de un estudiante han sido
validados, como se ha descrito anteriormente, las solicitudes son evaluadas por un
comit compuesto por 3 miembros de la universidad. Dado que el comit se rene
ocasionalmente, el proceso de evaluacin final de los candidatos desde que el
servicio de estudiantes enva la informacin (por correo interno) y recibe la
respuesta del comit dura de media 2 semanas. El comit toma la decisin
basndose en las notas del expediente y del CV. El comit dedica 10 minutos de
media a cada solicitud. Sobre el 50% de las solicitudes recibidas por el comit son
admitidas. Una vez tomada la decisin, la notifica al servicio de estudiante por
correo electrnico. Entonces, el servicio de estudiantes notifica la resolucin a los
estudiantes. El servicio de estudiantes tarda 2 das en enviar las notificaciones

(desde que sabe el resultado del comit). Las notificaciones a su vez son enviadas
por correo electrnico a los estudiantes, los estudiantes admitidos reciben adems
una carta por correo ordinario. Aproximadamente 800 solicitudes son procesadas
cada ao. Uno de los problemas detectados por la universidad es que los
estudiantes tienen que esperar demasiado tiempo para conocer el resultado de su
solicitud, en especial aquellos que son admitidos. Como normalmente los
estudiantes envan varias solicitudes a varias universidades, en algunas ocasiones
cuando reciben la respuesta de admisin han decidido enrolarse en otra
universidad.

Termino

Descripcin

Estudiante

Esta clase representa el estudiante que quiere ser admitido

Pgina web

Esta clase representa a la pgina web donde se registrara el

estudiante

Comite

Est clase representa a el comit que evaluara la peticin del

estudiante y evala respuesta

Sistema

Esta clase representa al servicio que valida si los papeles

fueron entregados completos y estn correctos

Ejercicio 11: Un nuevo cliente en la empresa para la cual trabajamos es dueo

del futuro hotel Estrellita de Mar y nos comenta su problema de no poder
encontrar un software en el mercado que cubra todas sus necesidades. Luego de
haber realizado un par de reuniones, y de realizada la propuesta, y aprobada por
el cliente, podemos identificar los siguientes requerimientos:
Ingresar las habitaciones, segn su tipo (simple, doble y matrimonial) y
comodidades (frigobar, TV, y DVD).
Consultar las habitaciones disponibles y poder reservar habitaciones en su hotel.
El hotel posee dos tipos de clientes: habituales y espordicos. Una reserva
almacena datos del cliente, de la habitacin reservada, la fecha de comienzo y el
nmero de das que ser ocupada la habitacin.
- El recepcionista del hotel debe poder hacer las siguientes operaciones:
Obtener un listado de las habitaciones disponible de acuerdo a su tipo
Preguntar por el precio de una habitacin de acuerdo a su tipo.
Preguntar por el descuento ofrecido a los clientes habituales.
Preguntar por el precio total para un cliente dado, especificando su nmero
de reserva, tipo de habitacin y nmero de noches.
Dibujar en pantalla la foto de una habitacin de acuerdo a su tipo.
Reservar una habitacin especificando el nmero de la pieza, reserva y
nombre del cliente.
Eliminar una reserva especificando el nmero de la habitacin.
El
administrador
puede
usar
el
programa
para:

Cambiar el precio de una habitacin de acuerdo a su tipo.

Cambiar el valor del descuento ofrecido a los clientes habituales.
Calcular las ganancias que tendrn en un mes especificado (considere que
todos los meses tienen treinta das).
El diseo a desarrollar debe facilitar la extensibilidad de nuevos tipos de
habitaciones o clientes y a su vez permitir agregar nuevas consultas.
Tambin, nuestro cliente, quiere realizar un portal en la web, en donde, los
visitantes puedan reservar una o las habitaciones que desee (si el mismo posee
tarjeta de crdito). Este debe registrarse al Portal, por el cual el sistema deber
reconocer el tipo de cliente.

Termino

Descripcin

Cliente

Esta clase representa el cliente que quiere reservar una

habitacin

Pgina web

Esta clase representa a la pgina web donde se registrara el

usuario y reservara la habitacin

Recepcionista

Est clase representa a la recepcionista que guiara al cliente

en el proceso de reservacin de la habitacin

Administrador

Esta clase representa al administrador quien tiene el acceso

para modificar los precios y descuentos

Sistema