Documentos de Académico
Documentos de Profesional
Documentos de Cultura
FAQ Proyecto II
FAQ Proyecto II
A continuación se recopilan las respuestas que se han dado a las preguntas mas
frecuentes:
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)
<<Actor>>
Process Management System
(from Actors)
Descripción
Precondiciones
Postcondiciones
Flujo Básico
Flujos Alteranativos
Casos de Uso Incluidos
Casos de Uso Extendidos
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”…
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.
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…..
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
….
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.
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)
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
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
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.
Cuando se alcanza la fecha fin del proyecto el sistema notifica a los usuarios
pertinentes (Ver Visión) que se ha alcanzado esta fecha
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
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
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.