5ta Clase UML-01

5/13/2018 5ta Clase UML-01 - slidepdf.com

http://slidepdf.com/reader/full/5ta-clase-uml-01 1/41

09/03/20121

Ingeniería del Software Ing. Santos Gabriel Blas

UNIVERSIDAD PRIVADA SAN

PEDRO

FACULTAD DE INGENIERIA

CURSO

INGENIERIA DEL SOFTWARE

”CASOS DE USO - PRACTICAS”

DOCENTE: ING. SANTOS GABRIEL BLAS



Préstamo de Libros – Caso de uso



Préstamo de Libros - Escenarios

Ejemplos:

Escenario 1: José se lleva prestado el tercer ejemplar de“Guerra y Paz” que hay en la biblioteca. No tiene ningún otrolibro en préstamo

Escenario 2: Mónica intenta llevarse prestado el primer

ejemplar de “Corín Tellado”, pero no puede porque ya tienetres libros en préstamo, que es el máximo.

Todos los escenarios de un caso de uso deben tener encomún intentos de hacer esencialmente “lo mismo” (en estecaso llevarse un libro en préstamo)

Los escenarios pueden y deben posteriormentedocumentarse mediante diagramas de interacción o deactividad.



Relación entre casos de uso - <Include> (Incluye)

Se puede incluir una relación entre dos casos de uso de

tipo <include>(incluye) si se desea especificarcomportamiento común entre dos o mas casos de uso



Relación entre casos de uso - <Include> (Incluye)



Préstamo de Libros - <Include>



Relación entre casos de uso - <Extended> (extiende)

Se puede incluir una relación entre dos casos de uso de

tipo <extend>(extiende) si se desea especificar diferentesvariantes del mismo caso de uso.Dicho de otra forma, la relación <extended> implica que elcomportamiento de un caso de uso es diferentedependiendo de ciertas circunstancias.



Relación entre casos de uso - <Extended> (extiende)



Generalizaciones

En un diagrama de casos de usotambién pueden mostrarsegeneralizaciones (relaciones deherencia) para mostrar que diferenteselementos están relacionados como

tipos de otros.

Son aplicables a actores o casos deuso, pero para estos últimos lasemántica es muy similar a lasrelaciones <extend>



Generalizaciones



Generalizaciones

La especializaciónes la presencia deunas característicasespecíficas de unsubconjunto deelementos de un

determinadoconjunto



Generalizaciones



Limites del Sistema Es útil dibujar los limites del sistema cuando se pretende

hacer un diagrama de casos de uso para mostrar partedel sistema.



Caso de uso – Maquina Recicladora Sistema que controla una máquina de reciclamiento de botellas,

tarros y jabas. El sistema debe controlar y/o aceptar:• Registrar el número de ítems ingresados.• Imprimir un recibo cuando el usuario lo solicita:

a) Describe lo depositadob) El valor de cada ítemc) Total

• El usuario/cliente presiona el botón de comienzo• Existe un operador que desea saber lo siguiente:

a) Cuantos ítems han sido retornados en el día.b) Al final de cada día el operador solicita un resumen de

todo lo depositado en el día.• El operador debe además poder cambiar:

a) Información asociada a ítems.b) Dar una alarma en el caso de que:

i. Ítem se atora.ii. No hay más papel.



Caso de uso – Maquina Recicladora

Como una primera aproximación identificamos alos actores que interactúan con el sistema:




Luego, tenemos que un Cliente puede DepositarÍtems y un Operador puede cambiar la información deun Ítem o bien puede Imprimir un informe




Además podemos notar que un ítem puede ser unaBotella, un Tarro o una Jaba.



Caso de uso – Maquina Recicladora Otro aspecto es la impresión de comprobantes, que

puede ser realizada después de depositar algún ítempor un cliente o bien puede ser realizada a peticiónde un operador.



Caso de uso – Maquina Recicladora Diseño completo del diagrama Use Case es:



Caso de uso – Juego Buscaminas

¿Qué casos de uso identificamos?» Iniciar una nueva partida.» Descubrir una casilla.

» Marcar una casilla.¿Quién realiza estos casos de uso?» El jugador.



Caso de uso – Juegos Buscaminas



Caso de uso – Juego SOKOBAN Sokoban es un juego de varios niveles.Cada nivel está compuesto por un jugador, cajas, repisas y

muros.El objetivo del jugador es empujar todas las cajas sobre las

repisas.Cuando esto sucede el jugador pasa al siguiente nivel.Para mover una caja, el jugador debe colocarse al lado y

empujarla.Si la casilla hacia la que está empujando la caja está libre la

caja se moverá.Si el jugador se queda bloqueado, es decir, no puede terminar

el nivel, puede reiniciar el nivel perdiendo una vida.

Cuando el jugador pierde todas sus vidas la partida termina.



Caso de uso – Juego SOKOBAN



Caso de uso – Centros Hospitalarios

Un cierto hospital necesita organizar la asignación deguardias de sus médicos en sus diferentes centroshospitalarios mediante una aplicación informática. Paraello asigna a un Analista el diseño del sistema utilizando lanotación UML.

Un médico jefe tiene asignada la función de Planificadorde guardias y debe tener en cuenta los médicosdisponibles, las guardias que debe cubrir y algunasincompatibilidades como asignaciones de tareas de másalta prioridad.

Por otra parte, los datos de todos los médicos losmantiene un Supervisor, encargado de mantener estainformación: altas, bajas, cambios de datos, etc.



Existe también un Administrador del sistema que se

encarga de la asignación y revocación de permisos a losplanificadores.

Se desea, asimismo, disponer de una función estadísticaque permita generar listados informativos.

Dado que varios planificadores de guardias pueden trabajaren paralelo, se quiere que se actualicen automáticamentelas estadísticas que vea cada uno cada vez que haya uncambio por parte de cualquiera de ellos. Asimismo, cada

planificador puede editar y modificar planes de guardias.Se pide realizar el Diagrama de Casos de Uso de la aplicación. Realizar una descripción textual de loscasos de uso y actores contemplados.




Caso de uso – Centros Hospitalarios Solución:

Los casos de uso son:Gestionar Médicos: dar de alta, de baja y cambio de datosa todos los médicos de cada centro hospitalario.Gestionar Estadísticas: actualizar las Estadísticas ypresentarlas a los usuarios de la aplicación cuando lo

soliciten.Editar Planes: asignar los médicos disponibles a lasguardias previstas.Gestionar Planes: creación y borrado de planes, apertura ycierre de planes ya creados, edición e impresión (por ello seincluye al anterior “Editar Planes”)

Gestionar Usuarios: gestionar las cuentas de losplanificadores de guardias autorizados, creando usuarios yasignándoles una palabra clave.



Caso de uso – Centros Hospitalarios Los actores son:

Supervisor: empleado administrativo que trabaja condatos confidenciales y que tiene que tener permisosespeciales de acceso a datos restringidos.

Planificador: encargado de la asignación de guardias

teniendo en cuenta la restricciones introducidaspreviamente en el sistema por el Supervisor

Administrador: responsable de la asignación de cuentasde acceso y de asegurar la confidencialidad y la integridad

de la información del sistema.



Pautas a seguir para un buen modelo

• Asegurarse que cada caso de uso describe una partesignificativa del funcionamiento del sistema.

• Evitar un número excesivo de casos de uso• Un caso de uso no es un paso, operación o actividad

individual en un proceso.

• Un caso de uso describe un proceso completo que incluye varios pasos (flujo de trabajo de la empresa).

• Los casos de uso deben ser simples, dado que podríancambiar con facilidad

• Los casos de uso tienen que ser entendibles tanto por

desarrolladores software como por expertos deldominio• Es una descripción de alto nivel del sistema• Evitar conceptos de diseño



Identificarlos para un buen modelo A partir de los actores

• Qué actores? (relacionados con el sistema oorganización)quién necesita el sistema?qué necesita el sistema para funcionar: personal,

hardware especializado, otros programas (software).

• Para cada actor, identificar los procesos que inician o enlos que participanponerle nombredeterminar límites/frontera: qué es del sistema? Qué

queda fuera?

Qué espera recibir/obtener? A partir de los eventos

• Identificar los eventos externos a los que puederesponder el sistema.

• Relacionar los eventos con actores y casos de uso



Descubrimiento

1. Determinar los límites del sistema

• ¿Es sólo una aplicación software, el hardware y laaplicación como un todo?

• ¿Lo utiliza más de una persona o unaorganización completa?

2. Identificar los actores principales• Quienes interactúan con el sistema

3. Para cada actor, identificar sus objetivos comousuario• Seguir “flujos” en la empresa: dinero,

información,… 4. Definir los casos de uso que satisfagan losobjetivos de usuario• Nombrar los casos de uso con un verbo



Descripción usando plantillas



Casos de uso en el proceso de análisis • Las entrevistas con el cliente inician el proceso

Estas entrevistas producirán diagramas de clases Obtendremos la base de conocimiento para el

dominio del sistema, esto es, el área del cliente Ahora se está en condiciones de poder hablar con

el usuario• Las entrevistas con el usuario empiezan con laterminología del dominio, aunque deberánalternarse hacia la terminología de los usuarios. Estas entrevistas desvelarán a los actores y casos

de uso de alto nivel que descubrirán losrequerimientos funcionales en términos generales

Esta información también permitirá establecer loslímites y ámbito del sistema.



• Entrevistas posteriores con el usuario

Permitirán profundizar en los requerimientos, loque dará lugar a casos de uso que mostrarán losescenarios y las secuencias detalladamente

• Entrevistas posteriores con el usuario

Esto podría resultar en otros casos de uso quesatisfagan las relaciones de inclusión y extensión.En esta fase es importante confiar en la

compresión del dominio a partir de los diagramasde clase• Si no se comprende adecuadamente el dominio

se podrían crear demasiados casos de uso ydemasiados detalles, lo cual obstaculizaría lalabor de diseño.

Casos de uso en el proceso de análisis



Casos de uso – Ejercicios N 01 Se desea desarrollar un sistema de encuentros virtuales

(parecido a un chat).Cuando se conecta al servidor, un usuario puede entrar o salir

de un encuentro.Cada encuentro tiene un manager.El manager es el usuario que ha planificado el encuentro (el

nombre del encuentro, la agenda del encuentro y el moderadordel encuentro).

Cada encuentro puede tener también un moderador designadopor el manager.

La misión del moderador es asignar los turnos de palabra paraque los usuarios hablen.

El moderador también podrá dar por concluido el encuentro encualquier momento.

En cualquier momento un usuario puede consultar el estadodel sistema, por ejemplo los encuentros planeados y suinformación.



Casos de uso – Ejercicios N 01




Un sistema personal de bolsa se conectaperiódicamente a servidores que ofreceninformación de las cotizaciones.

El sistema personal permite marcar una serie devalores para realizar un seguimiento y consultar los

datos de dichos valores.Si a la hora de actualizar las cotizaciones uno de

los valores marcados presenta una gran subida obajada, informará a usuario de ello.




Un juego de teléfono móvil dónde participan dos jugadores cada uno con su propia terminal. Cuando dos jugadores desean jugar, uno de ellos

crea una nueva partida y el otro se conecta. El objetivo del juego es manejar una nave y

disparar al contrario. Si uno de los dos jugadoresacierta, la partida termina.

Si uno de los dos jugadores deja la partida (o sepierde la conexión) la partida termina.

5ta Clase UML-01

Documents

Transcript of 5ta Clase UML-01