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.