5 Como documento la “inclusión” de casos de uso

FAQ PROYECTO ES:E PARTE 2
A continuación se recopilan las respuestas que se han dado a las preguntas mas
frecuentes:
1 Errata en el Enunciado: método PRCS::getRoleDefinition ....................................... 2
2 Errata en Relatos de Usuario: Donde dice roles debería decir recursos ................. 2
3 Cuando se asigna un recurso a una tarea ¿Se ha de especificar el % de
asignación? ..................................................................................................................... 2
4 ¿Cómo he completar la plantilla el apartado “Especificaciones Casos de Uso”? ..... 3
5 Como documento la “inclusión” de casos de uso ..................................................... 3
6 ¿Puede haber distintos usuarios que hagan lo mismo con el sistema? ¿Que
diferencia hay entre Actores y Usuarios? ........................................................................ 3
7 ¿Que granularidad de casos de uso utilizo? ............................................................ 4
8 Error en las restricciones del modelo conceptual proporcionado: Iddle, OnGoing,
Completed ....................................................................................................................... 5
9 ¿Como pongo en un diagrama de secuencia Rose “*” para indicar que los
mensajes se repiten? ...................................................................................................... 5
10
¿Que significan las cajas que aparecen en las líneas de instancias en los
diagramas de secuencias? .............................................................................................. 5
11
¿A que clase de Tarea se refiere el diagrama de estados del enunciado? .......... 6
12
¿Que es un caso de uso abstracto? ..................................................................... 6
13
¿Cómo estructuro en packages el modelo? ¿Qué es un package? ..................... 6
14
¿Cómo pongo <<includes>> y << extends>>¿Mediante un diagrama de casos
de uso especifico el orden de ejecución? ........................................................................ 7
15
¿Para que sirve la Generalización entre Actores? ................................................ 7
16
¿Como se cierra un “Proyecto”? ¿Puede el sistema iniciar un caso de uso? ....... 8
17
Uso de “Precondiciones” “Postcondiciones”, <<includes>> y <<extends>> la en
Perspectiva Analítica. ...................................................................................................... 8
18
¿Cómo se espcifican el <<includes>> y <<extends>> en el diagrama de
secuencia? ...................................................................................................................... 9
1 Errata en el Enunciado: método PRCS::getRoleDefinition
La signatura de PRCS en el enunciado tiene un error, donde dice
getRoleDefinition(name:String): Role
debe decir
getRoleDefinition(activityName:String):Role
Esta operación devuelve al definición de un role para una tarea data (considerar que
actividad y tarea tienen el mismo nombre)
La versión de PMS actualizada es:
2 Errata en Relatos de Usuario: Donde dice roles debería
decir recursos
En la pagina 6, line2 columna 62 donde dice “El sistema presenta al usuario la lista de
roles ordenados de mayor a menor disponibilidad “ debe decir “El sistema presenta al
usuario la lista de recursos ordenados de mayor a menor disponibilidad”
3 Cuando se asigna un recurso a una tarea ¿Se ha de
especificar el % de asignación?
Si, mirar Visión en 5.7 y también el modelado conceptual la clase asignación.
4 ¿Cómo he completar la plantilla el apartado
“Especificaciones Casos de Uso”?
En la plantilla que os proporcionamos aparecen su-bapartados, como “frecuencia,
issues, decisiones”. En principio esta plantilla es para un proyecto de “verdad”. Solo
hace falta completar al completo







Descripción
Precondiciones
Postcondiciones
Flujo Básico
Flujos Alteranativos
Casos de Uso Incluidos
Casos de Uso Extendidos
El resto de sub-apartados no es obligatorio completarlos
5 Como documento la “inclusión” de casos de uso
En el punto del flujo básico o alternativos donde se lleva a cabo al inclusión, mediante
una referencia al caso de uso incluido
Por ejemplo:
Flujo Básico
1. El caso de uso comienza cuando el “Actor”…
2. El sistema …
3. El “actor”…
4. Aquí se Incluye Ref a Caso de Uso
5. El “actor”…
6 ¿Puede haber distintos usuarios que hagan lo mismo con
el sistema? ¿Que diferencia hay entre Actores y Usuarios?
Un Caso de Uso es un clasificador de historias de interacción entre usuarios y el
sistema, por medio de la cual un usuario(s) obtiene cierto valor del sistema. Un caso de
uso describe tipos de historias. Los “actores” no son mas que el “papel” o rol que
desempeñan los usuarios del sistema en las historias de interacción. Este “papel” se
describe en términos del sistema
Por ejemplo un usuario que participa en una interacción en al que lo que hace es usar
el sistema para enviar un mensaje, como actor sería un “Message Sender”.
Normalmente a los usuarios se les nombra mediante nombres del dominio. En una
empresa esto corresponde a los nombres de los puestos de trabajo. Estos nombres de
puestos de trabajo, no siempre coinciden con los papeles que dichos usuarios
desempeñan con respecto al sistema.
Así distintos usuarios (puestos de trabajo) pueden desempeñar el mismo papel con
respecto al sistema.(se describen con el mismo actor)
Igualmente, un mismo usuario puede desempeñar distintos papeles de Actor.
7 ¿Que granularidad de casos de uso utilizo?
Un caso de uso describe y especifica un tipo de historias. El documento de
especificación de casos de uso se puede ver como un generado de historias o
escenario de interacción entre usuarios desempeñando los papeles de actores y el
sistema (ver LESE04-01)
Ante un conjunto de historias o escenarios como:
Create Account
Create Account and Invalid UserName
Modify Account
Delete Account
Modify Account and Invalid Password
Modify Account and Invalid UserName
Create Account and Invalid Password
Delete Account and user does not confirm
….. etc…..
Podemos definir dos alternativas de modelo de casos de uso
A) Desde la perspectiva del usuario (síntesis). Perspectiva Sintética
Un solo caso de uso: Manage Account
Donde
Flujo Básico
Create Account without error
(el mas importante, sin el cual el resto no tiene sentido)
Flujos Alternativos:
Modify Account
Delete Account
Invalid UserName
Invalid Password
User does not confirm
….
B) Desde la perspectiva del Analista (analisis) .Perspectiva Analítica
Tres casos de Uso
Create Account
Flujo Básico
Create Account without error
Flujos alternatives
Invalid username
Invalid password
Modify Account
Flujo Básico
Modify Account without error
Flujos Alternativos
Invalid username
Invalid password
Delete Account
….
AMBAS alternativas las daremos por buenas para la práctica., siempre y cuando las
historias que especifiquen sean las mismas. Es decir las historias que se pueden
instanciar con los documentos de especificación de ambas alternativas son las mismas.
8 Error en las restricciones del modelo conceptual
proporcionado: Iddle, OnGoing, Completed
En el modelo conceptual que os proporcionamos las restricciones del porcentaje
completado de Iddle y Completed están puestas justos al revés


Iddle {pc= 0%}
Completed {pc =100%}
9 ¿Como pongo en un diagrama de secuencia Rose “*” para
indicar que los mensajes se repiten?
Con un Note Item atachado (anchor tool) a los mensajes que aplican. Dentro del note
item indicar con un texto que los mensajes se repiten
10 ¿Que significan las cajas que aparecen en las líneas de
instancias en los diagramas de secuencias?
Cuando una instancia recibe un mensaje, la “caja” simboliza el tiempo que esta activa la
llamada en la instancia. En el lenguaje de programación corresponde a la entrada y
salida de la operación, es decir su ejecución
11 ¿A que clase de Tarea se refiere el diagrama de estados
del enunciado?
Se refiere a la clase “SimpleTask” que es la que puede estar Iddle, Completed…. etc
12 ¿Que es un caso de uso abstracto?
Es el caso de uso que especifica historias que por si mismas no se pueden instanciar,
bien porque no son completas o bien por que son un fragmento de historia.
El primer caso es el del “caso de uso” general en una generalización.(podría no ser
abstracto
El segundo es el de un “caso de uso” que es incluido desde otros casos de uso
(<<includes>>). Este siempre es abstracto
En una relación <<extends>> puede ser que el caso de uso entendedor sea abstracto o
no.
Resumiendo respondiendo al revés un caso de uso no es abstracto cuando es
completo: especifica historias o escenarios que tienen sentido como tales, son
completos y aportan valor para el usuario. (En LESE04-01 “Login” no aporta valor como
tal, las historias o escenarios de Login son fragmentos)
13 ¿Cómo estructuro en packages el modelo? ¿Qué es un
package?
Los packages son como las capetas de archivos de Windows, donde en UML, en lugar
de archivos contienen: clases, casos de uso, actores, relaciones entre los anteriores, y
diagramas!!
Los diagramas son vistas de las clases, casos de uso, actores (bien de estructura o de
comportamiento). En un package puede haber multiples diagramas. Una clase, actor
caso de uso puede aparecer en varios diagramas de diferentes packages
Para hacer el modelo organizativo o de packages no existen reglas fijas, mas bien
buenas prácticas:
Agrupar por
 funcionalidad del sistema (Gestión de Ordenes, Notificaciones,
Administración….)
 tipo de clases/diagramas que contiene (Actores, Casos de Uso)
 tipo de modelo (análisis, diseño, casos de uso, comportamiento)
 por contener elementos comunes
 ….
Ver LESE 04-01 pag 9 para un ejemplo
14 ¿Cómo pongo <<includes>> y << extends>>¿Mediante un
diagrama de casos de uso especifico el orden de
ejecución?
Los casos de uso describen o especifican historias de interacción. Estas historias de
interacción, según el sistema puede ejecutarse en diferente orden, o en paralelo (sin
terminar una historia puede iniciarse otra, si el sistema lo permite). Un diagrama de
casos de uso NO DESCRIBE EL ORDEN NI PARALELIZACION de las historias. Un
diagrama de casos de uso es una VISTA ESTATICA de la funcionalidad del sistema. Es
como una descripción visual del indice del libro, donde los capítulos son los casos de
uso. Si luego tu lees el capitulo 3 antes del 1 y si a mitad del 1 te pones a leer el 2, es
un aspecto que no se refleja en los casos de uso. Es un aspecto dinámico que se
debería recogerse en escenarios (mediante diagramas de secuencia).
(por seguir con la analogía, el doc de especificación de un caso de uso especifica
múltiples historias, es decir multiples maneras de escribir un capitulo del libro sistema,
Una instancia de caso de uso, historia o escenario dependería del camino escogido
entre FBasico+FAlternativos)
El <<includes>> es para incluir fragmentos de flujos que pueden ser incluidos en mas
de un sitio (mira LESE04-01, el caso de uso Login, o el ejemplo de Pagament amb
tarjeta de la clase de teoría) .(es un trozo de capitulo que se re-usa entre varios
capítulos). El caso de uso base necesita del caso de uso incluido para poder realizarse.
Sin el caso de uso incluido es incompleto
El << extends>> representa flujos que pueden ejecutarse en un determinado punto
(punto de extensión) del flujo básico. Son como flujos alternativos opcionales, que si no
los implementásemos el caso de uso base sería completo. El caso de uso base no
necesita de los casos de uso que lo extienden, ni los conoce
Estas relaciones no se hacen a priori, sino que normalmente se hacen a posteriori, una
vez especificado los casos de uso
15 ¿Para que sirve la Generalización entre Actores?
La jerarquia de actores se utiliza para definir permisos de usuario cuando se administra
el sistema.
Un usuario en función de que papeles desempeña con respecto al sistema tendrá unos
permisos u otros, es decir podrá acceder a una funcionalidad u otra.
El actor mas génerido es User, no aparece interactuando directamente en ningun caso
de uso, pero se utiliza para definir los permiso "by default".
Mira LESE04-01, allí se explica para que sirve la generalización entre actores.
Los actores heredan capacidad de interacción o relaciones con casos de uso
16 ¿Como se cierra un “Proyecto”? ¿Puede el sistema iniciar
un caso de uso?
Un proyecto se cierra, bien porque el project manager o el executive manager lo cierran
Cuando se alcanza la fecha fin del proyecto el sistema notifica a los usuarios
pertinentes (Ver Visión) que se ha alcanzado esta fecha
Cuando un recurso reporta % completado de una tarea, si se ha alcanzado el 100% de
todas las tareas, el sistema notifica que el proyecto ha sido completado.
A partir de estas notificaciones, el PM/EM pueden decidir cerrar el proyecto.
Todos los casos de uso se inician siempre por al interacción de un actor, sea el que
sea, el sistema nunca inicia un caso de uso, pero si, un caso de uso puede iniciar la
interacción con otro actor. Son las flechas que salen del caso de uso al actor, pero ojo
esa punta de flecha solo indica quíen indicia la interación, ya que la información fluye en
ambos sentidos. Repasa LESE04-01/las FAQs, y la teoria
Pista: existen actores que se llaman de “sistema” (operativo). Por ejemplo en un
software de GPS en un dispositivo movil que en función de la posición calcula el
camino a seguir, el actor que inicia la interacción es la “Posición”. Cuando se
diseñe/implemente el sistema la interacción con esta actor se implementara utilizando
las facilidades disponibles en el sistema operativo del dispositivo, ya sea rutinas de
interrupción, callbacks, polling…normalmente disponibles a través de APIs accesibles
desde lenguajes de alto nivel.
.
17 Uso de “Precondiciones” “Postcondiciones”,
<<includes>> y <<extends>> la en Perspectiva Analítica.
En una perspectiva analítica ver [7], los casos de uso describen Funciones Atómicas del
sistema. Para este manera de hacer el modelo de casos de uso,, Un caso de uso como
“Login” de LESE04-01, no estaría incluido en el resto sino que se expresaría como un
caso de uso directamente relacionado con un actor, al mismo nivel de “Create Account”.
Eso si, en las precondiciones de “Modify Account” deberíamos poner que se requiere
que el usuario haya ejecutado el “Login”.
En las Postcondiciones se indica el estado del sistema y contexto de actores como
consecuencia de ejecutarse un flujo (Básico o Alternativo) del caso de uso
Las precondicciones describen, todo aquello que se de cumplir (estado, eventos) para
que se pueda ejecutar el flujo del caso de uso
18 ¿Cómo se espcifican el <<includes>> y <<extends>> en el
diagrama de secuencia?
En un diagrama de secuencia se ha describir los mensajes entre instancias siguiendo
un camino por entre todas las posibles de Flujo básico+Alternativos del caso de uso. Un
diagrama de secuencia describe un historia particular, instancia o escenario de uso del
sistema donde a todas las ramificaciones de FBasico+FAlternativos se les de un valor y
se recorren pintando los mensajes entre las instancias participantes.
Si hay un include hay que pintarlo, ya que sin ello el caso de uso base no es completo
Si hay un extends, pues depende de si el escenario que estas describiendo pasa por el
extends o no.