Taller 01 Ejercicios de Modelado Requerimientos V4

TALLER 01: EJERCICIOS DE MODELADO – REQUERIMIENTOS PARTE I

Análisis de sistemas

Presenta

David Camilo Sánchez Mora

Camilo Andrés Frontado

Héctor Felipe Hurtado Acosta

Yojhan Leonardo Rodriguez Ascencio

Docente

Juan Carlos Guevara B.

Universidad Distrital Francisco José de Caldas

Tecnología en Sistematización de datos

Facultad Tecnológica

Bogotá D.C Colombia - Noviembre 18 del 2015

Ejercicios

Ejercicio 01: Complete el siguiente proceso de colaboración entre un cliente y una empresa de venta por catálogo. El cliente lleva a cabo las siguientes actividades (no necesariamente en este orden): pide un artículo, paga el artículo y pregunta sobre el estado de su pedido (el cliente pregunta una vez realizado el pedido cada 3 días si no ha recibido el encargo). En la compañía de ventas existen 3 roles: encargado de pedidos, almacén y contabilidad. El primero recibe los pedidos de artículos, y tranquiliza al cliente cuando éste pregunta por el estado de su encargo, en almacén se prepara la entrega y se envía al repartidor (una empresa externa) y el repartidor la entrega y recibe el pago. El último rol de la compañía es contabilidad que registra los envíos 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 términos

Termino Descripción

Almacén Es la clase encargada de preparar el envío y entregárselo al repartidor

Articulo Es la clase encargada de representar el artículo que será administrado y comprado por el cliente,

Cliente Representa al cliente que solicitara un envió para la compra de un artículo.

Contabilidad Es la clase encargada de registrar los envíos y los pagos.

Encargado Pedidos Es el ente encargado que tomara el pedido del cliente y lo tranquilizará.

Envío Es la clase en la cual se le asigna un artículo 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 artículo a su destino.

Ejercicio 02: Gestión 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 solución 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 petición 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 solución al cliente. Modelo de Procesos

Modelo de Dominio



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 solución 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.

Petición Es la clase encargada de la comunicación entre los agentes de soporte.

Responsable Cuentas Es el encargado de ofrecerle una solución al cliente en caso de tener alguna incidencia en su software.

Solución Es el software modificado solucionando la incidencia que el cliente presentaba.

Ejercicio 03: Gestión de reclamaciones compañía aseguradora de vehículos. Se pretende modelar el proceso de gestión de reclamaciones en una compañía aseguradora. Cuando se recibe una reclamación, ésta se registra en el sistema. Después del registro, la reclamación se clasifica en uno de los dos siguientes tipos: simple o compleja. Si la reclamación queda clasificada como simple se comprueba el seguro del cliente, para reclamaciones complejas se comprueba independientemente el seguro y el daño en el vehículo. Después de la comprobación o comprobaciones se genera una resolución de la reclamación, que puede ser positiva o negativa. Si la resolución es positiva se informa al garaje para autorizar la reparación y se planifica el pago al mismo. Para cualquier tipo de resolución (positiva o negativa) se envía una carta al cliente y el proceso termina. Modelo de Procesos

Modelo de Dominio



Seguro Esta clase representa el seguro que adquirió el usuario sobre el vehículo

Carta Es la clase que representa la carta de respuesta que genera el área de reclamos luego de la reparación 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 mayoría de los trámites cuando se recibe una reclamación.

Reclamación Esta clase contiene todos los detalles de la reclamación 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 administración de clientes y el seguro

Resolución Esta clase representa la respuesta de a la reclamación del usuario, Es la que autoriza o no la reparación del vehículo.

Reparación Esta clase representa todos los detalles de la reparación del vehículo hecha por el garaje

Garaje Representa el área de la empresa que se encarga de hacer todas las reparaciones del vehículo si tiene una autorización

Vehículo Es la clase que representa el vehículo del usuario que será sometido a reparación si la reclamación es positiva

Ejercicio 04: El caso de estudio seleccionado es una versión más general del problema conocido como

“Conference Review System” distribuido en la conferencia OOPSLA de 1991. Una solución propuesta por J. Rumbaugh puede consultarse en la columna de análisis y diseño del Journal of Object Oriented Programming. El propósito del sistema es dar soporte a los procesos de envío, evaluación y selección de artículos, vía Web para una conferencia o congreso. Se desea crear un sistema basado en el Web que permita gestionar las tareas asociadas a la celebración de un congreso desde que se crea la convocatoria hasta que se envía la lista de artículos 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 tópicos de interés y fijar las diversas sesiones. Elegir al comité de programa y registrarlo en el sistema. Fijar las fechas importantes: inicio y finalización de envíos, notificación de

aceptación o rechazo, envío de versiones definitivas. Detectar conflictos de intereses en la revisión de artículos. Hacer visible a los miembros del comité de programa la lista de artículos

enviados. Asignar artículos a los miembros del comité de programa, de acuerdo a las

preferencias mostradas por éstos. Cambiar el área de artículos enviados. Decidir sobre el proceso de revisión de artículos. Enviar las revisiones a los autores.

Los miembros del comité de programa son los encargados de revisar los artículos. Las atribuciones son las siguientes: Indicar preferencias por áreas o temas. Indicar interés o conflicto con los artículos enviados. Descargarse artículos. 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 co‐autores de un artículo. Enviar un artículo. Modificar un envío antes de que finalice el plazo.

Un requisito adicional establece la existencia de un sistema de autentificación que permite que los distintos tipos de usuarios puedan acceder únicamente a la funcionalidad y a la información que les concierne.

Modelo de Procesos

Modelo de Dominio


Ejercicio 05: Se desea informatizar la gestión de reservas de un hotel, los requisitos informales pueden describirse de la siguiente forma:


Área Esta clase describe el espacio físico 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 información 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 artículos

Conflicto Esta clase describe excepciones que se presentan a la hora de evaluar correcciones de artículos

Comité Esta clase presenta las áreas especializadas encargadas de la evaluación de artículos

Fechas Esta clase tiene los datos en los cuales se evalúa, presenta y corrige los artículos

Interés 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 evalúan los artículos

Password Es la que permite la validación a la plataforma

Preferencia Esta clase corresponde al interés de evaluación de cada articulo

Proceso Esta clase contiene datos específicos del proceso que lleva a cabo cada articulo

Presidente Es la clase que corresponde al usuario presidente encargado de la mayoría 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.

Los clientes pueden efectuar reservar anticipadas. El hotel admite tantas reservas como habitaciones libres tenga. Las reservas telefónicas tienen que estar respaldadas por un número de tarjeta de crédito. Si en la fecha de reserva no se presenta el cliente, se genera una factura que se envía a la compañía de tarjetas de crédito.

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 crédito.

Cuando un cliente llega al hotel su reserva es procesada, comprobándose la misma con los detalles que proporciona el cliente.

Hay clientes que solicitan una habitación en el mostrador del hotel. Algunos clientes solicitan habitaciones para no fumadores. Las habitaciones se pueden alquilar para dormir únicamente, con media

pensión o con pensión completa. Cuando los clientes abandonan el hotel, un empleado comprueba los detalles

de ocupación (llamadas telefónicas, 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 envía una factura única a la empresa.

El sistema tendrá tres tipos de usuarios: los empleados de mostrador o recepción, el gerente y un administrador. El gerente se encargará de gestionar las cuentas de empresas: tipo de descuento por habitación, apertura de cuenta y cierre de cuenta. El administrador se encargará de efectuar un mantenimiento sobre la información que se almacena en el sistema. Por último los empleados de mostrador se encargan de la gestión de clientes.

Modelo de Procesos

Modelo de Dominio



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

Habitación Esta clase representa la habitación 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 telefónica o presencial

Tarjeta crédito Esta clase corresponde a los datos tomados de la tarjeta de crédito 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 compañía de metro de la ciudad de Valencia desea implantar una

tarjeta inteligente (smart‐card) que facilite la adquisición de billetes y el desplazamiento de los viajeros por las distintas líneas de metro de la ciudad. La tarjeta puede adquirirse en máquinas 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 máquina expendedora en efectivo (en cuyo caso no se devuelve ningún importe) o bien utilizando una tarjeta de crédito que el sistema valida frente a la entidad emisora. En la tarjeta queda grabada la fecha de adquisición, la fecha de vencimiento (válida durante 2 meses), el importe y la forma de pago. Para acceder a la estación 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 también se aplican a los viajeros con tarjeta .En la tarjeta se graban los distintos recorridos efectuados por el viajero (hora de entrada, estación origen, hora de salida, estación 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 máquina expendedora para obtener el saldo actual. Si se adquirió en efectivo el viajero obtiene el importe en efectivo, si se adquirió con tarjeta de crédito la devolución se efectúa sobre la misma. Los inspectores de metro disponen de dispositivos móviles que permiten leer el contenido de las tarjetas para evitar usos fraudulentos.

Modelo de Procesos

Modelo de Dominio


Ejercicio 07: Se desea modelar el funcionamiento de un aparcamiento público de automóviles. Cuando un conductor se acerca a la máquina situada en la entrada, debe pulsar un botón para obtener el resguardo de aparcamiento, una cámara graba la matrícula 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 después de detectar el paso del vehículo. Para salir del aparcamiento los conductores primero abonan el importe asociado a la estancia en un cajero automático, é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 máquina situada en la salida el resguardo de aparcamiento, en ese momento el sistema lee la matrícula del vehículo, comprueba la hora de pago y levanta la barrera de salida, la cual se cierra unos instantes después de detectar el paso del vehículo. El aparcamiento funciona también para abonados, los cuales para entrar y salir del aparcamiento deben introducir una tarjeta magnética. En la tarjeta se graba la matrícula al entrar y se comprueba a la salida. Para facilitar el pago de los conductores no abonados se desea implantar un sistema por telefonía móvil que mediante mensajes SMS permita pagar la estancia en el aparcamiento. Al entrar el usuario recoge el ticket de entrada y para salir envía un mensaje SMS con el número de ticket, el importe se carga en la factura de teléfono. El sistema informático del aparcamiento recibe el mensaje SMS de confirmación del pago.


Descuento Esta clase representa los descuentos aplicados a las tarjetas de acuerdo a la fecha de su uso.

Maquina Esta clase representa a la máquina que permite las recargas de las tarjetas o la adquisición 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 crédito Esta clase representa el medio de pago de tarjeta de crédito escogido por el usuario al recargar la tarjeta

Torno Es la clase que representa a la máquina que valida el pasó de los usuarios

Usuario Esta clase representa al usuario del sistema

Para salir el conductor introduce el ticket de entrada y pulsa un botón de la máquina que indica pago telefónico, el sistema comprueba si el usuario ha enviado el mensaje SMS, en cuyo caso abre la barrera de salida. En este caso se aplican también los 10 minutos de margen para abandonar las instalaciones.

Modelo de procesos

Modelo de Domino

Glosario de Términos

Ejercicio 08: Se desea construir un portal Web que permita a los usuarios reservar y comprar billetes de avión. 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 selección se añade a la cesta de la compra del usuario. La única forma de pago admitida es mediante tarjeta de crédito, para ello el usuario debe proporcionar su nombre completo, el número 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 crédito. Para que el(los) billete(s) puedan ser tramitados debe también proporcionarse el nombre y apellidos de los viajeros. Una vez formalizada la compra el sistema genera un número de ticket y el billete electrónico que se remite posteriormente a la aerolínea correspondiente. Los billetes pueden ser comprados en cualquier momento hasta 3 días antes de la realización del viaje. El sistema también admite anulaciones, pero éstas únicamente pueden hacerse 15 días antes del vuelo. En este caso se cobra al cliente el 6% de la operación.. 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 crédito).

Términos Descripción

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

Conductor Esta clase representa al usuario del parqueadero.

SMS Esta clase describe el mensaje que el usuario envía al salir

del parqueadero para poder salir.

Tarjeta Es la clase describe los datos del vehiculo y del usuario que

entra al parqueadero

Pago Es la clase en la cual se almacena el pago que hizo el

usuario luego de enviar el sms.

Sistema Esta clase representa la barrera de acceso del parqueadero

Ticket En esta clase se diligencia para los usuarios no abonados

que entran al parqueadero.

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


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

Ejercicio 09: A continuación se describe el funcionamiento de una empresa de confección que fabrica productos para grandes cadenas de distribución. La empresa subcontrata a otros fabricantes los procesos de manipulación necesarios para confeccionar sus productos, ya que ésta únicamente compra el hilo (algodón) o la materia prima. En sus instalaciones dispone de maquinaria para cortar los patrones, el resto de los procesos de transformación: tejeduría, tintado, estampado, etc. son subcontratados a otras empresas. La organización 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 reposición. Los pedidos de grandes clientes deben ser enviados directamente a las tiendas, con la particularidad de que tanto los pedidos iniciales como los de reposición tienen un plazo de entrega estipulado (a veces es a los 15 días de la recepción y otras veces es al mes de la recepción), por lo que las prendas contenidas en un pedido deben estar fabricadas o en proceso de terminación su fabricación. Los pedidos se reciben en formato electrónico (EDI, electronic Data Interchange), cada pedido contiene una serie de centros de entrega (dirección física de las tiendas donde se entregan los artículos) junto con la lista de artículos que se recibirán 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 artículos destinados a cada centro. El jefe de almacén 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 información a los mozos de almacén. De acuerdo a la disponibilidad de género las cajas se rellenan con las prendas disponibles, produciéndose las siguientes situaciones: a. Una caja se llena completamente. b. Una caja no puede rellenarse completamente. Las cajas son validadas por el jefe de almacén, en el sentido de que una caja parcialmente llena puede enviarse si el jefe de almacén sabe que no va a llegar más género antes de que se tenga que enviar el pedido, o bien si la cantidad de prendas que faltan es muy pequeña comparado con el total del pedido. En el caso

ticket Esta clase representa la confirmación a la compañía 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

Modificación 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.

de que se espere género la caja queda en espera de ser completada. Una vez recibido género 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 almacén decide si la caja se envía o no. Obviamente la nota de entrega puede ser modificada en el almacén (se envía menos género del solicitado, incluso algunos centros no se pueden servir) y se envía de vuelta a las secretarias. Las secretarias para cada caja contenida en la nota de entrega generan un albarán que se envía al almacén y allí se sitúa 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 Términos


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

Albarán Esta clase representa la orden de envió para la distribución de pedidos.

Patrones Esta clase describe las características 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 características del pedido

EDI Esta clase describe el mensaje que es enviado a la secretaria con las características 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 línea que incluye detalles personales, dirección de contacto, selección del programa que quieren cursar y algunos detalles relativos a su formación. Las solicitudes presentadas vía Web se almacenan en un sistema de información al que tienen acceso todo el personal implicado en los procesos de admisión. Los estudiantes no envían ningún documento electrónicamente, ellos tienen que imprimir y firmar el formulario de solicitud y enviarlo por correo postal con los siguientes documentos: a. Certificación de su expediente académico. b. Resultados de su test oficial de conocimiento del lenguaje inglés. c. Currículum Vitae. La documentación suele tardar 2 semanas en llegar al servicio de estudiantes mediante el correo ordinario. Cuando los documentos se reciben físicamente se comprueban en el citado servicio. Esta operación suele durar 10 minutos, cuando se detecta que algún documento falta se envía un correo electrónico 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 información recibida el servicio de estudiantes envía copias certificadas de los documentos a una agencia de evaluación externa. La agencia comprueba la documentación y verifica que las asignaturas cursadas se corresponden o son equivalentes a las asignaturas de la universidad. La agencia requiere que la documentación se envíe físicamente por correo ordinario, y todos los documentos deben ser copias certificadas de los originales. Esta restricción no puede ser cambiada por la universidad. La agencia envía a su vez de vuelta por correo ordinario los resultados de la evaluación. Se tarda una media de 2 semanas en enviar la documentación a la agencia y en recibir el resultado de la evaluación. Alrededor de un 10% de las solicitudes se rechazan después de esta comprobación. Las notificaciones de rechazo se envían por correo electrónico 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 inglés. Esto se hace introduciendo en un sistema de información un código de comprobación que aparece en la parte superior de la hoja de resultados del test de inglés. Si los resultados del test de evaluación del idioma inglés no son satisfactorios la solicitud se rechaza. La comprobación de los resultados del test dura unos 10 minutos. Alrededor del 10% de las solicitudes son rechazadas en este trámite. Las notificaciones de rechazo se envían 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 reúne ocasionalmente, el proceso de evaluación final de los candidatos desde que el servicio de estudiantes envía la información (por correo interno) y recibe la respuesta del comité dura de media 2 semanas. El comité toma la decisión basándose 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 decisión, la notifica al servicio de estudiante por correo electrónico. Entonces, el servicio de estudiantes notifica la resolución a los estudiantes. El servicio de estudiantes tarda 2 días en enviar las notificaciones

(desde que sabe el resultado del comité). Las notificaciones a su vez son enviadas por correo electrónico a los estudiantes, los estudiantes admitidos reciben además una carta por correo ordinario. Aproximadamente 800 solicitudes son procesadas cada año. 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 envían varias solicitudes a varias universidades, en algunas ocasiones cuando reciben la respuesta de admisión han decidido enrolarse en otra universidad.


Estudiante Esta clase representa el estudiante que quiere ser admitido

Página web Esta clase representa a la página web donde se registrara el estudiante

Comite Está clase representa a el comité que evaluara la petición del estudiante y evalúa respuesta

Sistema Esta clase representa al servicio que valida si los papeles fueron entregados completos y están correctos

Ejercicio 11: Un nuevo cliente en la empresa para la cual trabajamos es dueño 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, según 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 esporádicos. Una reserva almacena datos del cliente, de la habitación reservada, la fecha de comienzo y el número de días que será ocupada la habitación. - 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 habitación 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 número de reserva, tipo de habitación y número de noches.

Dibujar en pantalla la foto de una habitación de acuerdo a su tipo.

Reservar una habitación especificando el número de la pieza, reserva y nombre del cliente.

Eliminar una reserva especificando el número de la habitación. - El administrador puede usar el programa para:

Cambiar el precio de una habitación de acuerdo a su tipo.

Cambiar el valor del descuento ofrecido a los clientes habituales.

Calcular las ganancias que tendrán en un mes especificado (considere que todos los meses tienen treinta días).

El diseño a desarrollar debe facilitar la extensibilidad de nuevos tipos de habitaciones o clientes y a su vez permitir agregar nuevas consultas. También, 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 crédito). Este debe registrarse al Portal, por el cual el sistema deberá reconocer el tipo de cliente.


Cliente Esta clase representa el cliente que quiere reservar una habitación

Página web Esta clase representa a la página web donde se registrara el usuario y reservara la habitación

Recepcionista Está clase representa a la recepcionista que guiara al cliente en el proceso de reservación de la habitación

Administrador Esta clase representa al administrador quien tiene el acceso para modificar los precios y descuentos

Sistema

Documents

Taller 01 Ejercicios de Modelado Requerimientos V4