Entrega1 Proyecto Uml

8/16/2019 Entrega1 Proyecto Uml

1/31

PROYECTO UML – RESERVAS DE VIAJES EN BUS

MARIO ANDRÉS CAÑÓN MUÑOZ

POLITÉCINO GRANCOLOMBIANOFACULTAD DE CIENCIAS BÁSICAS

TECNOLOGÍA EN DESARROLLO DE SOFTWAREBOGOTÁ

2016PROYECTO UML


2/31

2

MARIO ANDRÉS CAÑÓN MUÑOZ

PROYECTO DESARROLLADO EN EL MÓDULO DE UML DEL PROGRAMA DETECNOLOGÍA EN DESARROLLO DE SOFTWARE

DIEGO IVÁN OLIVEROS ACOSTATUTOR

POLITÉCNICO GRANCOLOMBIANOFACULTAD DE CIENCIAS BÁSICAS

TECNOLOGÍA EN DESARROLLO DE SOFTWAREBOGOTÁ

2016


3/31

3

AGRADECIMIENTOS

Al equipo de tutores que constantemente brindan su apoyo al desarrollo de cadamódulo, gracias por aportar parte de su experiencia en nuestro proceso deformación.

A la Facultad de ciencias básicas, a la institución en general y a todo el equipo queestá detrás del desarrollo y revisión del material de estudio y a todos aquellos quea diario invierten su esfuerzo en la gestión y mantenimiento de la plataforma.


4/31

4

CONTENIDO

Pág.

1.

INTRODUCCIÓN ........................................................................................................ 8

2. OBJETIVOS ............................................................................................................... 9

2.1 OBJETIVO GENERAL ............................................................................................. 9

2.2 OBJETIVOS ESPECÍFICOS ................................................................................... 9

3. MODELO FUNCIONAL ............................................................................................ 10

3.1 REFORMULACIÓN DEL PROBLEMA EN LENGUAJE INFORMÁTICO. ............... 10

3.2 IDENTIFICACIÓN DE ACTORES. ......................................................................... 11

3.3 REQUERIMIENTOS FUNCIONALES ..................................................................... 12

3.4 REQUERIMIENTOS NO FUNCIONALES .............................................................. 14

3.5 CASOS DE USO .................................................................................................... 15

3.6 DIAGRAMA INTEGRADO DE CASOS DE USO .................................................... 29

CONCLUSIONES ............................................................................................................ 30

BIBLIOGRAFÍA ................................................................................................................ 31


5/31

5

LISTA DE TABLAS

Pág

Tabla 1. Requerimientos funcionales – Autor: Andrés Cañón 12

Tabla 2. Requerimientos no funcionales – Autor: Andrés Cañón 14


6/31

6

LISTA DE GRÁFICAS

Pág

Gráfica 1. Diagrama integrado de casos de uso – Autor: Andrés Cañón 29


7/31

7

RESUMEN

El presente trabajo fue desarrollado dentro del marco del desarrollo del módulo deUML, de la carrera “Tecnología En Desarrollo De Software” del Politécnico

Grancolombiano. Dentro del alcance de la presente obra se encuentra el análisis ydiseño de una aplicación (Software) de reserva de viajes en bus con base alLenguaje Unificado De Modelado UML, incluyendo la elaboración del ModeloFuncional, Modelo Estructural y Modelo Dinámico.

PALABRAS CLAVE: UML, Lenguaje Unificado De Modelado, Software, Análisis yDiseño, Modelo.


8/31

8

1. INTRODUCCIÓN

UML es actualmente el sistema de facto para el diseño de aplicaciones de

software, la sigla significa Lenguaje Unificado De Modelado o Unified ModelingLanguage, nació formalmente durante la década de los 90’s como solución a lanecesidad de establecer un estándar para el desarrollo de proyectos de software,específicamente en su fase de diseño y consta de una serie de modelos, técnicasy diagramas que componen en sí la estructura general de un sistema, antessiquiera de empezar a escribir una sola línea de código. Este marco de trabajologró condensar en una sola unidad, lo que hasta ese momento eran disertacionesacerca de cómo debería orientarse una aplicación de software desde su etapa dediseño; el gran problema a finales del siglo pasado, era la falta de un lenguajegeneral, que fuera una guía normalizada para el desarrollo de este tipo deproyectos y UML llegó para marcar la pauta y ser el estándar que pondría el ordennecesario al diseño de software desde su estructura misma.

En el presente trabajo se encuentra plasmado un ejemplo completo de laaplicación de dicho estándar, desde la descripción del problema, pasando por elanálisis de requerimientos, levantamiento de casos de uso y definición de losdiferentes modelos y diagramas que lleven a la comprensión general de lasolución antes de la fase de desarrollo e implementación.

Cabe recalcar que en la actualidad no se contempla siquiera el desarrollo de unaaplicación software sin el apoyo de UML, de ahí la importancia de ejercicios comoestos, que permitan a los futuros Ingenieros de Software tener un acercamientoreal a las técnicas y buenas prácticas sugeridas por el que al día de hoy es elLenguaje Universal para el diseño y posterior desarrollo de productos de softwarede calidad, que cumplan con las demandas crecientes de un mundo en continuodesarrollo, que cada día depende más de unidades de software que solucionenproblemas reales y optimicen los procesos de las organizaciones. Desde unaaplicación de punto de venta, hasta grandes y robustas soluciones de software,

juegos, aplicaciones de productividad, entretenimiento, etc, todo nace con el

Lenguaje Unificado de Modelado, UML.


9/31

9

2. OBJETIVOS

2.1 OBJETIVO GENERAL

Aplicar el conjunto de reglas, procedimientos, modelos y diagramas definidos porel estándar UML en el desarrollo del ejercicio base definido por el proyecto delmódulo, todo esto como base para el diseño de una solución de softwaredesarrollable en el mundo real.

2.2 OBJETIVOS ESPECÍFICOS

Elaborar el modelo funcional de la aplicación: Reformulación del problema enlenguaje informático, identificación de actores, realización de la tabla derequerimientos funcionales, documento de requerimientos no funcionales, casosde uso, diagrama integrado de los casos de uso y escenarios de cada caso deuso.

Elaborar el modelo funcional de la aplicación: Identificar las clases en la definicióndel problema, elaborar la lista de sustantivos candidatos a clases y descartar losredundantes o que cumplen características de atributos. Una vez filtrados lossustantivos que son clases, se debe elaborar el modelo de clases, identificar lasclases persistentes, elaboración del diccionario de clases y el modelo entidad-

relación.

Elaborar el modelo funcional de la aplicación: Desarrollar los diagramas desecuencia, construir los diagramas de navegación para el portal web del caso yplasmar los bosquejos de cómo quedarían las interfaces gráficas de la aplicación.


10/31

10

3. MODELO FUNCIONAL

Elaborar el modelo funcional de la aplicación: Reformulación del problema en

lenguaje informático, identificación de actores, realización de la tabla derequerimientos funcionales, documento de requerimientos no funcionales, casosde uso, diagrama integrado de los casos de uso y escenarios de cada caso deuso.

3.1 REFORMULACIÓN DEL PROBLEMA EN LENGUAJE INFORMÁTICO.

Se requiere implementar un sistema de información para el proceso de reserva deasientos de un bus, el sistema debe permitir a un usuario realizar las siguientesacciones: Consultar sillas, reservar sillas, comprar boletos vía web sin lanecesidad de desplazarse físicamente a un punto de venta.

La ventana de inicio del sistema debe mostrar un mensaje de bienvenida ypermitir: Registrar usuarios nuevos, Iniciar sesión a usuarios registrados.

Un usuario que haya iniciado sesión en el sistema de manera exitosa podrá:Consultar rutas de buses, reservar sillas disponibles, comprar boletosdirectamente desde la aplicación.

El sistema debe permitir la ejecución de consultas por parte del usuario por lossiguientes criterios: Consultar por horario de salida del bus, Consultar por tarifa delpasaje, Consultar por estado del viaje.

Al realizar consultas por horario de salida del bus el sistema debe presentar unaventana con la información de horarios para todas las empresas de busesmostrando hora de salida, ciudad de origen y ciudad de destino.

Las consultas por tarifa deben mostrar el costo del pasaje para las diferentes rutas

disponibles, mostrando además del costo la ciudad de origen y la ciudad dedestino.

El sistema debe suministrar información de las rutas de buses, incluyendo estadode la ruta, disponibilidad de asientos, y en el caso de consultas el mismo día del


11/31

11

viaje se informará si la salida del bus se encuentra a tiempo. Se incluirá además elnúmero de paradas programadas para una ruta específica.

Al realizar búsquedas el sistema proporcionará la opción de buscar por los

siguientes criterios: fecha, horario del viaje, categoría del asiento, empresa a lacual está inscrita el bus y viajes directos sin escala en ciudades intermedias.

El sistema contará con un módulo de reservas el cual debe permitir que el clienterealice una reservación sobre un viaje específico, dicha reserva incluirá atributoscomo número de asientos reservados, fecha y hora del viaje, tarifa y en el caso deviajes entre países incluir información sobre los transbordos que componen la ruta.En el caso de reservar más de un asiento el usuario deberá registrar los númerosde identificación de las personas que lo acompañan en el viaje y que estarán bajosu responsabilidad, como conyugue o hijos.

El pago será aceptado a través de tarjeta de crédito válida.

El envío de los boletos se realizará en formato PDF a través del correo electrónicoregistrado por el cliente, quien podrá a la hora del abordaje presentar o bien eldocumento impreso o el PDF en su SmartPhone.

En cuanto al registro de usuarios, el sistema debe permitir a cada cliente editar suinformación básica o darse de baja del sistema siempre que no tenga reservas

activas en ese momento.

La aplicación debe permitir el registro de la siguiente información por cada viaje,pasajeros, paradas programadas, destino de cada pasajero con el fin de tenerclaridad sobre los pasajeros que se bajan antes del destino final, número demaletas por pasajero incluida fecha, hora y lugar de recibo y los mismos datospara la entrega con el DNI del pasajero que entrega y recibe la maleta. Comoatributos del viaje deben incluirse: listado de pasajeros con nombre, asiento,ciudad de origen y ciudad de destino, número total de pasajeros, código del viaje,placa del bus, nombre del conductor, nombre del ayudante.

3.2 IDENTIFICACIÓN DE ACTORES.

De acuerdo a los requerimientos especificados para la aplicación se identifican lossiguientes actores en el sistema:


12/31

12

Cliente: Será el usuario principal del módulo de reservas y compra deboletos, accederá a través del portal web para realizar acciones como elregistro de sus datos, inicio de sesión, consulta de viajes y rutas, reserva ycompra de boletos, editar su información personal o darse de baja del

sistema siempre y cuando no tenga reservas activas en ese momento. Agente: Habrá al menos un agente de viajes por parte de la agencia que

tendrá acceso al sistema para realizar acciones como consultas dereservas, impresión de listas de chequeo de pasajeros.

Administrador : Aunque las especificaciones iniciales no lo contemplandebe incluirse por lo menos un usuario administrador por parte de laagencia de viajes quien tendrá acceso para realizar acciones de tipoadministrativo sobre el sistema, creación de nuevos agentes, generación dereportes, edición y eliminación de usuarios en general.

Sistema: El sistema mismo tendrá un rol de actor dentro del flujo normal dela aplicación y por sí mismo iniciará la ejecución de ciertos casos de uso.

3.3 REQUERIMIENTOS FUNCIONALES

REQUERIMIENTOS FUNCIONALES

Código Nombre Detalle Prioridad

RF-001 Registrarusuario

El sistema permitirá el registro de usuariosnuevos en la base de datos, los usuarios

pueden ser clientes o agentes.

Alta

RF-002 Iniciarsesión

El sistema permitirá el inicio de sesión ausuarios previamente registrados.

Alta

RF-003 Editarusuario

El sistema contendrá un módulo para la ediciónde datos de usuarios registrados, de esta formalos clientes podrán actualizar sus datos.

Media

RF-004 Eliminarusuario

El sistema permitirá a un cliente registradodarse de baja de la base de datos, siempre quedicho usuario no tenga reservas activas en esemomento.

Media

RF-005 Registrar

ruta

El sistema permitirá a un agente autenticado

realizar el registro de rutas, dicho registrocontendrá la información referente a ciudad deorigen, ciudad de destino, tarifa, paradasprogramadas, estado, horas de salida y busesasignados a dicha ruta.

Media

RF-006 Editar ruta El sistema permitirá a un agente autenticadorealizar cambios en la información de rutas

Media


13/31

13

registradas en el RF-005.RF-007 Eliminar

rutaEl sistema permitirá a un agente autenticadoeliminar rutas registradas y que la agencia hayadecidido retirar del catálogo de servicios.

Media

RF-008 Consultarrutas El sistema permitirá a los usuarios autenticadosrealizar consultas sobre las rutas registradas. Alta

RF-009 Reservarasientos

El sistema permitirá a los usuarios registradosreservar uno o más asientos en un bus asignadoa un viaje específico y que cubra una rutadeterminada. En el caso de reservar más de 1(uno) asiento se deberá registrar los datos decada acompañante, los cuales quedaránasociados bajo responsabilidad del usuario querealiza la reserva. La reserva obligatoriamentedeberá contener la ciudad de origen y ciudad

de destino, pues cabe la posibilidad de que elpasajero se baje en un punto diferente al destinofinal del bus.

Alta

RF-010 Pagarboletos

El sistema ofrecerá una interfaz de pago contarjeta de crédito válida para que un usuarioautenticado pueda comprar los boletoscorrespondientes a la reserva realizada en elRF-009.

Alta

RF-011 Enviarboletos

El sistema realizará el envío del total de boletoscomprados por el usuario. El envío se realizaráen formato PDF a través del correo electrónico

registrado por el usuario en el RF-001 omodificado en el RF-003.

Alta

RF-012 Registrarequipaje

El sistema debe permitir realizar el registro delequipaje correspondiente al pasajero, dichoregistro contendrá fecha, hora, lugar y personaque entrega el equipaje a la agencia y losmismos datos al momento de la recepción delequipaje en el punto de destino.

Media

RF-013 Generarlista de

pasajeros

El sistema permitirá a un agente autenticadogenerar la lista de pasajeros correspondiente aun bus que cubre un viaje específico.

Media

RF-014 Registrarempresa El sistema permitirá a un agente autenticadoregistrar una empresa a la cual estaránasociados varios buses con su respectivainformación.

Media

RF-015 Editarempresa

El sistema permitirá a un agente autenticadoeditar la información de las empresasregistradas en el RF-014.

Media


14/31

14

RF-016 Eliminarempresa

El sistema permitirá a un agente autenticadoeliminar una empresa de transporte registradaen la base de datos.

Media

RF-017 Registrar

bus

El sistema permitirá a un agente autenticado

registrar un bus con su respectiva información:empresa, conductor, ayudante, placa, númerode sillas.

Media

RF-018 Editar bus El sistema permitirá a un agente autenticadoeditar la información de los buses registrados enel RF-017.

Media

RF-019 Eliminarbus

El sistema permitirá a un agente autenticadoeliminar un bus registrado en la base de datos.

Media

Tabla 1. Requer imientos funcion ales

3.4 REQUERIMIENTOS NO FUNCIONALES

REQUERIMIENTOS NO FUNCIONALES

Código Nombre Detalle

RNF-001 Accesoautentificado

El sistema podrá ser usado exclusivamente porusuarios debidamente autenticados.

RNF-002 Acceso web La aplicación debe estar alojada en un servidor web,que permita el ingreso desde cualquier conexión aInternet estándar.

RNF-003 Seguridad La información correspondiente a contraseñas deusuarios deberá estar encriptada usando MD5 ocualquier algoritmo de encriptación similar.

RNF-004 Lenguaje deprogramación

El sistema debe desarrollarse en un lenguaje deprogramación orientado a objetos.

RNF-005 Compatibilidad El sistema deberá ser compatible con los principalesnavegadores web: Chrome, Firefox, Opera, Safari, IE.

RNF-006 Acceso deadministrador

El sistema contará con un acceso de administradorque permitirá a un usuario especial asignado por laagencia ejecutar acciones administrativas sobre laaplicación: Gestión de usuarios, gestión de rutas,

empresas, buses, generar listas de pasajeros, etc.

Tabla 2. Requer imientos no funcion ales


15/31

15

3.5 CASOS DE USO

Para el desarrollo de los casos de uso se tomará como base la plantilla sugeridaen la lectura de la Unidad 2 del módulo de Ingeniería de software 1, “Lectura 2 -

Casos de uso. Una herramienta fundamental ok.pdf ”, que a su vez es unavariación de la plantilla propuesta por Alistair Cockburn y la cual puede consultarseen: http://alistair.cockburn.us/Basic+use+case+template1.

ID: CU-001 NOMBRE: Registrar usuarioObjetivo en contexto (Resumen): Realizar el registro de un usuario en el

sistema ingresando toda la informaciónpersonal del mismo.

Actores Participantes: Usuario.Pre-Condiciones: El usuario no debe estar registrado en

el sistema.Condiciones de éxito: El usuario es registrado en el sistema.Toda la información requerida para elregistro del usuario ha sido ingresada ala base de datos.

FLUJO NORMAL1. El usuario ingresa a la página principal del sistema.2. El usuario hace clic en el botón de registro.3. El sistema direcciona al usuario a la página de registro en la cual se solicita

toda la información al usuario.4. El usuario ingresa todos sus datos y da clic en el botón de enviar.

5. El sistema recibe la información y actualiza la base de datos.6. El sistema envía la información de registro vía e-mail al correo registrado por

el usuario.7. El sistema muestra un mensaje de éxito al usuario con un botón de aceptar.8. El usuario hace clic en el botón aceptar.9. El sistema direcciona al usuario a la página principal para que pueda iniciar

sesión con sus credenciales de autenticación registradas.EXTENSIONES

*.1.1 El sistema falla.*.1.2 El sistema direcciona al usuario a la página principal.*.1.3 El usuario reinicia el proceso de registro.*.2.1 El usuario abandona o actualiza la página sin finalizar el registro.*.2.1.1 El sistema pregunta al usuario si está seguro de cancelar la operación.*.2.2.2 El usuario cancela la operación.*.2.2.3 El sistema direcciona al usuario a la página principal.

SUB-VARIACIONES

1 http://alistair.cockburn.us/Basic+use+case+template Alistair Cockburn

http://alistair.cockburn.us/Basic+use+case+templatehttp://alistair.cockburn.us/Basic+use+case+templatehttp://alistair.cockburn.us/Basic+use+case+templatehttp://alistair.cockburn.us/Basic+use+case+templatehttp://alistair.cockburn.us/Basic+use+case+templatehttp://alistair.cockburn.us/Basic+use+case+templatehttp://alistair.cockburn.us/Basic+use+case+templatehttp://alistair.cockburn.us/Basic+use+case+template


16/31

16

6.1 El envío del correo falla por problemas en el servidor.6.2 El sistema intentará enviar el correo nuevamente.6.2.1 El envío del correo falla nuevamente después de 5 intentos.6.2.2 El sistema notifica al administrador.

6.2.3 El administrador valida el origen del error y envía la información de formamanual.6.3 El correo se envía exitosamente y el flujo continúa al paso 7.

ID: CU-002 NOMBRE: Iniciar sesiónObjetivo en contexto (Resumen): Permitir el inicio de sesión a usuarios

registrados del sistema. Actores Participantes: Usuario, agente, administradorPre-Condiciones: El usuario debe estar registrado en el

sistema.

Condiciones de éxito: El usuario inicia sesión en el sistema.FLUJO NORMAL

1. El usuario ingresa a la página principal del sistema.2. El usuario hace clic en el botón de inicio de sesión.3. El sistema direcciona al usuario a la página de inicio de sesión donde solicita

ingresar su usuario y contraseña.4. El usuario ingresa sus credenciales de autenticación.5. El sistema valida la información y si las credenciales son correctas permite el

inicio de sesión.6. El sistema muestra un mensaje al usuario donde le da la bienvenida al

sistema y le informa que ha iniciado sesión con éxito.EXTENSIONES

5.1 Las credenciales de autenticación son incorrectas, el sistema no permite elinicio de sesión.

SUB-VARIACIONES5.1.1 Las credenciales de autenticación son incorrectas.5.1.2 El sistema limpia los campos de usuario y clave.5.1.3 El usuario ingresa nuevamente sus credenciales y el flujo continúa en el

paso 6.

ID: CU-003 NOMBRE: Editar usuarioObjetivo en contexto (Resumen): Editar la información de un usuario del

sistema. Actores Participantes: Usuario, agente, administradorPre-Condiciones: El usuario debe estar registrado en el

sistema.Condiciones de éxito: Se actualiza la información del usuario


17/31

17

en el sistemaFLUJO NORMAL

1. El usuario inicia sesión en el sistema.2. El usuario ingresa al módulo de editar perfil.

3. El sistema muestra un formulario con la información actual permitiendo editarlos campos.4. El usuario realiza los cambios y da clic en el botón guardar.5. El sistema valida los campos.6. El sistema actualiza la información en la base de datos.7. El sistema muestra un mensaje al usuario en el que informa que los cambios

han sido guardados con éxito.EXTENSIONES

*.1.1 El usuario cancela la acción.*.1.1 El sistema direcciona al usuario a la página principal.

SUB-VARIACIONES5.1.1 El sistema detecta información errada en uno de los campos.5.1.2 El sistema muestra un mensaje informativo al usuario para que corrija lainformación.5.1.3 El usuario corrige los datos y nuevamente da clic en guardar.5.1.4 Si la información es correcta el flujo continúa en el paso 5.

ID: CU-004 NOMBRE: Eliminar usuarioObjetivo en contexto (Resumen): Eliminar un usuario del sistema.

Actores Participantes: Usuario, agente, administrador.

Pre-Condiciones: El usuario debe estar registrado en elsistema.Condiciones de éxito: Usuario eliminado, base de datos de

usuarios actualizada.FLUJO NORMAL

1. El usuario inicia sesión en el sistema.2. El usuario se dirige a la página de preferencias.3. El usuario hace clic en el botón eliminar cuenta.4. El sistema solicita la contraseña de acceso al usuario.5. El usuario ingresa la contraseña.6. El sistema muestra un mensaje de confirmación al usuario con un captcha.

7. El usuario confirma la acción.8. El sistema elimina al usuario de la base de datos.9. El sistema muestra un mensaje informando que el usuario ha sido eliminado

con éxito.EXTENSIONES

*.1.1 El usuario cancela la acción.*.1.1 El sistema direcciona al usuario a la página principal.


18/31

18

7.1 El usuario no confirma la acción.7.2 El sistema direcciona al usuario a la página principal.

SUB-VARIACIONES5.1.1 La contraseña del usuario es incorrecta.

5.1.2 El sistema solicita nuevamente la contraseña, esta vez con un captcha.5.1.3 El sistema valida la contraseña y el captcha y continúa el flujo en el paso 6.

ID: CU-005 NOMBRE: Registrar rutaObjetivo en contexto (Resumen): Realizar el registro de una nueva ruta

en el sistema. Actores Participantes: Agente, administrador.Pre-Condiciones: El usuario autenticado en el sistema

debe ser un Agente o un Administrador.La ruta no debe estar ya registrada en

el sistema.Condiciones de éxito: Ruta adicionada al catálogo de rutas.

FLUJO NORMAL1. El usuario inicia sesión en el sistema.2. El usuario ingresa al módulo de administración de rutas.3. El usuario da clic en el botón agregar ruta.4. El sistema solicita al usuario toda la información necesaria para el registro de

la nueva ruta.5. El usuario ingresa los datos.6. El sistema valida los datos.7. El sistema actualiza la información en la base de datos.8. El sistema muestra un mensaje de éxito al usuario y pregunta si desea

adicionar más rutas.9. El sistema direcciona al usuario a la página principal del módulo de rutas.

EXTENSIONES*.1.1 El usuario cancela la acción.*.1.1 El sistema direcciona al usuario a la página principal del módulo de rutas.

SUB-VARIACIONES6.1.1 Los datos no son correctos.6.1.2 El sistema muestra un mensaje informativo al usuario para que corrija los

datos incorrectos.

6.1.3 El usuario actualiza los datos y el flujo continúa en el paso 7.8.1 El usuario da clic en agregar una nueva ruta.8.2 El flujo continúa desde al paso 4.

ID: CU-006 NOMBRE: Editar rutaObjetivo en contexto (Resumen): Editar la información de una ruta


19/31

19

registrada en el sistema. Actores Participantes: Agente, administradorPre-Condiciones: La ruta debe estar registrada en el

sistema.

Condiciones de éxito: Se actualiza la información de la ruta enel sistemaFLUJO NORMAL

1. El usuario inicia sesión en el sistema.2. El usuario ingresa al módulo de administración de rutas.3. El usuario busca la ruta que desea modificar.4. El sistema muestra un formulario con la información actual de la ruta

permitiendo editar los campos.5. El usuario realiza los cambios y da clic en el botón guardar.6. El sistema valida los campos.7. El sistema actualiza la información en la base de datos.

8. El sistema muestra un mensaje al usuario en el que informa que los cambioshan sido guardados con éxito.

EXTENSIONES*.1.1 El usuario cancela la acción.*.1.1 El sistema direcciona al usuario a la página principal del módulo de rutas.


ID: CU-007 NOMBRE: Eliminar rutaObjetivo en contexto (Resumen): Eliminar una ruta del sistema.

Actores Participantes: Administrador.Pre-Condiciones: La ruta debe estar registrada en el

sistema. El usuario autenticado en elsistema debe ser un Administrador.

Condiciones de éxito: Ruta eliminada, base de datos de rutasactualizada.

FLUJO NORMAL1. El usuario inicia sesión en el sistema.2. El usuario se dirige a la página de administración de rutas.3. El usuario busca la ruta que desea eliminar.4. El usuario hace clic en el botón eliminar ruta.5. El sistema muestra un mensaje de confirmación al usuario.6. El usuario confirma la acción.


20/31

20

7. El sistema valida que la ruta esté libre de dependencias para poderla eliminar.8. El sistema elimina la ruta de la base de datos.9. El sistema muestra un mensaje informando que la ruta ha sido eliminada con

éxito.

EXTENSIONES*.1.1 El usuario cancela la acción.*.1.1 El sistema direcciona al usuario a la página principal del módulo de rutas.3.1 La ruta no existe.3.2 El sistema direcciona al usuario a la página principal del módulo de rutas.6.1 El usuario no confirma la acción.6.2 El sistema direcciona al usuario a la página principal del módulo de rutas.7.1 La ruta tiene dependencias activas, como reservaciones asociadas.7.2 El sistema informa al usuario que la ruta no se puede eliminar.7.3 El sistema direcciona al usuario a la página principal del módulo de rutas.

SUB-VARIACIONES

Ninguna.

ID: CU-008 NOMBRE: Consultar rutasObjetivo en contexto (Resumen): Permitir al usuario cliente realizar

consultas sobre las rutas activas en elsistema.

Actores Participantes: UsuarioPre-Condiciones: El usuario debe haber iniciado sesión

en el sistema.Condiciones de éxito: Acceso al módulo de búsqueda de

rutas.FLUJO NORMAL

1. El usuario inicia sesión en el sistema.2. El usuario ingresa al módulo de consulta de rutas.3. El sistema muestra el formulario de búsqueda al usuario.4. El usuario ingresa los criterios de búsqueda y da clic en buscar.5. El sistema muestra la información al usuario.

EXTENSIONES*.1.1 El sistema falla.*.1.2 El sistema muestra un mensaje informativo al usuario indicándole que debe

intentar realizar la búsqueda más tarde o comunicarse con el administrador delsistema si el problema persiste.*.1.3 El sistema direcciona al usuario a la página principal

SUB-VARIACIONESNinguna.


21/31

21

ID: CU-009 NOMBRE: Reservar asientoObjetivo en contexto (Resumen): Realizar la reserva de uno o más

asientos en un bus que cubre una rutaespecífica.

Actores Participantes: Usuario, sistema.Pre-Condiciones: El usuario debe estar autenticado en elsistema. La silla a reservar debe estardisponible.

Condiciones de éxito: Reserva realizada con éxito. El usuarioes direccionado al módulo de pagos.

FLUJO NORMAL1. El usuario inicia sesión en el sistema.2. El usuario ingresa al módulo de reservas.3. El usuario realiza la búsqueda sobre la ruta que desea y elige un horario de

salida.

4. El sistema carga la información del bus que cubre el viaje seleccionado por elusuario.

5. El sistema muestra una interfaz con las sillas disponibles para reserva.6. El usuario elige los asientos que desea reservar.7. El usuario da clic en el botón de reservar.8. El sistema muestra un mensaje informativo con el resumen de los asientos

seleccionados.9. El usuario confirma la reserva.10. El sistema registra la reserva y direcciona al usuario al módulo de pagos.

EXTENSIONES*.1.1 El sistema falla.

*.1.2 El sistema muestra un mensaje informativo al usuario indicándole que debeintentar realizar la reserva más tarde o comunicarse con el administrador delsistema si el problema persiste.*.1.3 El sistema direcciona al usuario a la página principal.*.2.1 El usuario cancela la acción o abandona el sistema sin concluir el proceso.*.2.2 El sistema deshace los cambios y direcciona al usuario a la páginasolicitada.9.1 El usuario no confirma la reserva.9.2 El sistema deshace los cambios.9.3 El sistema direcciona al usuario a la página principal del módulo de reservas.

SUB-VARIACIONES9.1 El usuario solicita hacer cambios sobre las sillas seleccionadas.9.2 El flujo retorna al paso 6 y continúa desde este punto.

ID: CU-010 NOMBRE: Pagar boletosObjetivo en contexto (Resumen): Permite al usuario realizar el pago de


22/31

22

una reserva. Actores Participantes: Usuario, sistema.Pre-Condiciones: El usuario debe estar autenticado en el

sistema. El usuario debe haber

realizado una reserva válida.Condiciones de éxito: Se ejecuta el pago de los asientosreservados. Se activa el CU-011 Enviarboletos.

FLUJO NORMAL1. El usuario inicia sesión e ingresa al módulo de pagos o bien ha sido

direccionado desde el CU-009 después de finalizar el proceso de reserva.2. El usuario selecciona la reserva pendiente para pago.3. El sistema muestra al usuario la información correspondiente al pago

pendiente.4. El usuario hace clic en pagar.

5. El sistema muestra al usuario el formulario de pago.6. El usuario registra la información requerida para el pago, incluida la

información del medio de pago.7. El sistema verifica que el medio de pago sea válido.8. El sistema solicita confirmación al usuario.9. El usuario confirma el pago.10. El sistema aplica el pago y activa el CU-011 Enviar boletos.

EXTENSIONES*.1.1 El sistema falla.*.1.2 El sistema muestra un mensaje informativo al usuario indicándole que debeintentar realizar el pago más tarde o comunicarse con el administrador del

sistema si el problema persiste.*.1.3 El sistema direcciona al usuario a la página principal.*.2.1 El usuario cancela la acción o abandona el sistema sin concluir el proceso.*.2.2 El sistema deshace los cambios y direcciona al usuario a la páginasolicitada.7.1 El medio de pago no es válido.7.2 El sistema cancela la operación y direcciona al usuario a la página principaldel módulo de pagos.9.1 El usuario no confirma el pago.9.2 El sistema cancela la operación y direcciona al usuario a la página principaldel módulo de pagos.


ID: CU-011 NOMBRE: Enviar boletosObjetivo en contexto (Resumen): Realizar el envío de los boletos


23/31

23

correspondientes al pago de unareserva en formato PDF.

Actores Participantes: SistemaPre-Condiciones: Pago exitoso de una reserva.

Condiciones de éxito: Los boletos en formato PDF sonenviados al correo electrónicoregistrado por el usuario.

FLUJO NORMAL1. El sistema valida un pago realizado.2. El sistema, en base a la información del pago, realiza el envío de los boletos

en formato PDF al correo electrónico registrado por el usuario.3. El sistema almacena los boletos en la base de datos a fin de disponerlos para

consultas en el futuro.EXTENSIONES

2.1 El sistema falla.

2.2 El sistema notifica al administrador sobre el fallo.SUB-VARIACIONES

Ninguna.

ID: CU-012 NOMBRE: Registrarequipaje

Objetivo en contexto (Resumen): Permitir el registro de equipajecorrespondiente a un usuario.

Actores Participantes: Usuario, agente

Pre-Condiciones: Pago exitoso de una reserva. Boletosgenerados en PDFCondiciones de éxito: Se realiza el registro del equipaje de un

pasajero.FLUJO NORMAL

1. El usuario o agente inicia sesión en el sistema.2. El usuario o agente ingresa al módulo de registro de equipaje.3. El usuario o agente selecciona el viaje pagado por el usuario.4. El sistema muestra el formulario para el registro de equipaje.5. El usuario o agente registra los datos del equipaje.6. El sistema imprime los datos del equipaje.

7. En el punto de destino el agente ingresa la información del usuario que retirael equipaje, validando la información del ticket impreso al momento de laentrega.

8. El sistema actualiza los datos del registro del equipaje con la información deentrega y devolución.

EXTENSIONES2.1 El sistema falla.


24/31

24

2.2 El sistema muestra un mensaje informativo al usuario indicándole que debeintentar realizar el registro del equipaje más tarde o comunicarse con eladministrador del sistema si el problema persiste.

SUB-VARIACIONES

Ninguna.

ID: CU-013 NOMBRE: Generar lista depasajeros

Objetivo en contexto (Resumen): Imprimir el listado de pasajeroscorrespondiente a un viaje – bus – ruta.

Actores Participantes: Agente, administradorPre-Condiciones: Agente o administrador autenticado en

el sistema.Condiciones de éxito: Lista de pasajeros generada.

FLUJO NORMAL1. El usuario inicia sesión.2. El usuario selecciona el viaje para el cual requiere generar la lista de

pasajeros.3. El sistema imprime la lista de pasajeros.4. El sistema direcciona al usuario a la página principal.

EXTENSIONES*.1 El sistema falla.*.2 El sistema muestra un mensaje informativo al usuario indicándole que debeintentar generar la lista de pasajeros más tarde o comunicarse con el

administrador del sistema si el problema persiste.SUB-VARIACIONESNinguna.

ID: CU-014 NOMBRE: Registrarempresa

Objetivo en contexto (Resumen): Realizar el registro de una nuevaempresa en el sistema.

Actores Participantes: Agente, administrador.Pre-Condiciones: El usuario autenticado en el sistema

debe ser un Agente o un Administrador.La empresa no debe estar ya registradaen el sistema.

Condiciones de éxito: Empresa registrada en el sistema.FLUJO NORMAL

1. El usuario inicia sesión en el sistema.


25/31

25

2. El usuario ingresa al módulo de administración de empresas.3. El usuario da clic en el botón agregar empresa.4. El sistema solicita al usuario toda la información necesaria para el registro de

la nueva empresa.

5. El usuario ingresa los datos.6. El sistema valida los datos.7. El sistema actualiza la información en la base de datos.8. El sistema muestra un mensaje de éxito al usuario y pregunta si desea

adicionar más empresas.9. El sistema direcciona al usuario a la página principal del módulo de

empresas.EXTENSIONES

*.1.1 El usuario cancela la acción.*.1.1 El sistema direcciona al usuario a la página principal del módulo deempresas.


datos incorrectos.6.1.6 El usuario actualiza los datos y el flujo continúa en el paso 7.8.1 El usuario da clic en agregar una nueva empresa.8.2 El flujo continúa desde al paso 4.

ID: CU-015 NOMBRE: Editar empresaObjetivo en contexto (Resumen): Editar la información de una empresa

registrada en el sistema. Actores Participantes: Agente, administradorPre-Condiciones: La empresa debe estar registrada en el

sistema.Condiciones de éxito: Se actualiza la información de la

empresa en el sistemaFLUJO NORMAL

1. El usuario inicia sesión en el sistema.2. El usuario ingresa al módulo de administración de empresas.3. El usuario busca la empresa que desea modificar.

4. El sistema muestra un formulario con la información actual de la empresapermitiendo editar los campos.5. El usuario realiza los cambios y da clic en el botón guardar.6. El sistema valida los campos.7. El sistema actualiza la información en la base de datos.8. El sistema muestra un mensaje al usuario en el que informa que los cambios

han sido guardados con éxito.


26/31

26

EXTENSIONES*.1.1 El usuario cancela la acción.*.1.1 El sistema direcciona al usuario a la página principal del módulo deempresas.


ID: CU-016 NOMBRE: Eliminar empresaObjetivo en contexto (Resumen): Eliminar una empresa del sistema.

Actores Participantes: Administrador.Pre-Condiciones: La empresa debe estar registrada en el


Condiciones de éxito: Empresa eliminada, base de datos deempresas actualizada.

FLUJO NORMAL1. El usuario inicia sesión en el sistema.2. El usuario se dirige a la página de administración de empresas.3. El usuario busca la empresa que desea eliminar.4. El usuario hace clic en el botón eliminar empresa.

5. El sistema muestra un mensaje de confirmación al usuario.6. El usuario confirma la acción.7. El sistema valida que la empresa esté libre de dependencias para poderla

eliminar.8. El sistema elimina la empresa de la base de datos.9. El sistema muestra un mensaje informando que la empresa ha sido eliminada

con éxito.EXTENSIONES

*.1.1 El usuario cancela la acción.*.1.1 El sistema direcciona al usuario a la página principal del módulo deempresas.

3.1 La empresa no existe.3.2 El sistema direcciona al usuario a la página principal del módulo de empresas.6.1 El usuario no confirma la acción.6.2 El sistema direcciona al usuario a la página principal del módulo de empresas.7.1 La empresa tiene dependencias activas, como buses o rutas asociadas.7.2 El sistema informa al usuario que la empresa no se puede eliminar.7.3 El sistema direcciona al usuario a la página principal del módulo de empresas.


27/31

27


ID: CU-017 NOMBRE: Registrar busObjetivo en contexto (Resumen): Realizar el registro de un nuevo bus en

el sistema. Actores Participantes: Agente, administrador.Pre-Condiciones: El usuario autenticado en el sistema

debe ser un Agente o un Administrador.El bus no debe estar registrado en elsistema.

Condiciones de éxito: Bus registrado en el sistema.FLUJO NORMAL

1. El usuario inicia sesión en el sistema.2. El usuario ingresa al módulo de administración de buses.3. El usuario da clic en el botón agregar bus.4. El sistema solicita al usuario toda la información necesaria para el registro del

nuevo bus.5. El usuario ingresa los datos.6. El sistema valida los datos.7. El sistema actualiza la información en la base de datos.8. El sistema muestra un mensaje de éxito al usuario y pregunta si desea

adicionar más buses.9. El sistema direcciona al usuario a la página principal del módulo de buses.

EXTENSIONES*.1.1 El usuario cancela la acción.*.1.1 El sistema direcciona al usuario a la página principal del módulo de buses.


datos incorrectos.6.1.9 El usuario actualiza los datos y el flujo continúa en el paso 7.8.1 El usuario da clic en agregar un nuevo bus.8.2 El flujo continúa desde al paso 4.

ID: CU-018 NOMBRE: Editar busObjetivo en contexto (Resumen): Editar la información de un bus

registrado en el sistema. Actores Participantes: Agente, administradorPre-Condiciones: El bus debe estar registrado en el

sistema.


28/31

28

Condiciones de éxito: Se actualiza la información del bus enel sistema

FLUJO NORMAL1. El usuario inicia sesión en el sistema.

2. El usuario ingresa al módulo de administración de buses.3. El usuario busca el bus que desea modificar.4. El sistema muestra un formulario con la información actual del bus permitiendo

editar los campos.5. El usuario realiza los cambios y da clic en el botón guardar.6. El sistema valida los campos.7. El sistema actualiza la información en la base de datos.8. El sistema muestra un mensaje al usuario en el que informa que los cambios

han sido guardados con éxito.EXTENSIONES

*.1.1 El usuario cancela la acción.

*.1.1 El sistema direcciona al usuario a la página principal del módulo de buses.SUB-VARIACIONES

6.1.1 El sistema detecta información errada en uno de los campos.6.1.2 El sistema muestra un mensaje informativo al usuario para que corrija lainformación.6.1.3 El usuario corrige los datos y nuevamente da clic en guardar.6.1.4 Si la información es correcta el flujo continúa en el paso 7.

ID: CU-019 NOMBRE: Eliminar bus

Objetivo en contexto (Resumen): Eliminar un bus del sistema. Actores Participantes: Administrador.Pre-Condiciones: El bus debe estar registrado en el


Condiciones de éxito: Empresa eliminada, base de datos debuses actualizada.

FLUJO NORMAL1. El usuario inicia sesión en el sistema.2. El usuario se dirige a la página de administración de buses.3. El usuario busca el bus que desea eliminar.

4. El usuario hace clic en el botón eliminar bus.5. El sistema muestra un mensaje de confirmación al usuario.6. El usuario confirma la acción.7. El sistema valida que el bus esté libre de dependencias para poderlo eliminar.8. El sistema elimina el bus de la base de datos.9. El sistema muestra un mensaje informando que el bus ha sido eliminado con

éxito.


29/31

29

EXTENSIONES*.1.1 El usuario cancela la acción.*.1.1 El sistema direcciona al usuario a la página principal del módulo de buses.3.1 El bus no existe.

3.2 El sistema direcciona al usuario a la página principal del módulo de buses.6.1 El usuario no confirma la acción.6.2 El sistema direcciona al usuario a la página principal del módulo de buses.7.1 El bus tiene dependencias activas, como viajes vigentes asociados.7.2 El sistema informa al usuario que el bus no se puede eliminar.7.3 El sistema direcciona al usuario a la página principal del módulo de buses.


3.6 DIAGRAMA INTEGRADO DE CASOS DE USO

Gráfic a 1. Diagram a integr ado d e casos de uso .


30/31

30

CONCLUSIONES

Después del análisis de la descripción del sistema requerido se identificaron 4actores, 19 requerimientos funcionales, 6 requerimientos no funcionales y 19

casos de uso, los cuales fueron ajustados en un diagrama integrado de casos deuso. Esta primer fase del trabajo finaliza con el modelo funcional de la aplicación,que se compone de los elementos mencionados anteriormente.


31/31

BIBLIOGRAFÍA

David Aycart Pérez, Marc Gibert Ginestà, Martín Hernández Matías, Jordi Mas

Hernández, Ingenieria del sortware en entornos SL con UML, Fundació per a laUniversitat Oberta de Catalunya, Febrero 2007.

Lectura 2 - Casos de uso. Una herramienta fundamental ok, PolitécnicoGrancolombiano, Ingeniería de software I. Bogotá, 2016.

Lectura 1 - El modelo de casos de uso ok, Politécnico Grancolombiano, UML.Bogotá, 2016.

http://alistair.cockburn.us/Basic+use+case+template Basic use case template,Humans and Technology Document TR.96.03a, April 26, 1996, October 26, 1998.
http://alistair.cockburn.us/Basic+use+case+templatehttp://alistair.cockburn.us/Basic+use+case+templatehttp://alistair.cockburn.us/Basic+use+case+template

Entrega1 Proyecto Uml

Documents

Transcript of Entrega1 Proyecto Uml