Documente Academic
Documente Profesional
Documente Cultură
6 Introduccin
La escritura de casos de uso (historias del uso de un sistema) es una tcnica excelente para entender y describir los requisitos. El UP define el Modelo de Casos de Uso en la disciplina Requisitos. Bsicamente, es el conjunto de todos los casos de uso; es un modelo de la funcionalidad y entorno del sistema.
6.2 Antecedentes
La idea fue introducida por Ivar Jacobson, uno de los contribuidores principales al UML y UP. El siguiente paso ms coherente, comprensible e influyente es la definicin de que son (o deberan ser) los casos de uso, procede de Alistair Cockburn (Writing Effective Use Cases).
http://longinox.blogspot.com
http://longinox.blogspot.com
El sistema funciona siguiendo un contrato entre el personal involucrado, donde los casos de uso detallan la parte de comportamiento del contratoEl caso de uso, como contrato de comportamiento, captura todo y slo el comportamiento relacionado con la satisfaccin de los intereses del personal involucrado. El punto de vista del inters del personal involucrado proporciona un procedimiento metdico y completo para el descubrimiento y registro de todos los comportamientos requeridos.
Precondiciones y garantas de xito (postcondiciones) La precondiciones: o Establecen lo que siempre debe cumplirse antes de comenzar un escenario en el caso de uso. o No se prueban en el caso de uso, sino que son condiciones que se asumen que son verdad. o Comunican suposiciones importantes de las que el escritor del caso de uso piensa que los lectores deberan ser avisados. Las garantas de xito (o postcondiciones): o Establecen que debe cumplirse cuando el caso de uso se completa con xito. o Debera satisfacer las necesidades de todo el personal involucrado. Escenario principal de xito y pasos (o Flujo Bsico) Describe el camino de xito tpico que satisface los intereses del personal involucrado. Ntese que, a menudo, no incluye ninguna condicin o bifurcacin. Aunque no es incorrecto, se supone que es ms comprensible y extensible ser muy consistente y postergar todo el manejo de caminos condicionales a la seccin Extensiones. El escenario recoge los pasos, que pueden ser de tres tipos: 1. Una interaccin entre actores. 2. Una validacin. 3. Un cambio de estado realizado por el sistema. Extensiones (o Flujos Alternativos) Indican todos los otros escenarios o bifurcaciones, tanto de xito como de fracaso. En la escritura de casos de uso completos, la combinacin del camino feliz y los escenarios de extensin deberan satisfacer casi todos los intereses del personal involucrado. Una extensin tiene dos partes: la condicin y el manejo. Algunas veces, un punto de extensin particular es bastante complejo. Esto puede ser motivo para expresar la extensin como un caso de uso aparte. Requisitos especiales Si un requisito no funcional, atributo o restriccin se relaciona de manera especfica con un sado de uso, se recoge en el caso de uso. Esto incluye cualidades tales como rendimiento, fiabilidad y facilidad de uso, restricciones de diseo que son obligados o se consideran probables. Lista de tecnologa y variaciones de datos A menudo, encontramos variaciones tcnicas en cmo se debe hacer algo, pero no en qu, y es importante registrarlo en el caso de uso. Un ejemplo tpico es una restriccin tcnica impuesta por el personal involucrado con respecto a las tecnologas de entrada y salida de datos.
http://longinox.blogspot.com
A qu nivel y alcance deberan expresarse los casos de uso? Casos de uso para los procesos del negocio elementales Para el anlisis de requisitos de una aplicacin informtica, hay que centrarse en los casos de uso al nivel de procesos del negocio elementales (EBPs, Elementary Business Processes). EBP se define como: Una tarea realizada por una persona en un lugar, en un instante, como respuesta a un evento del negocio, que aade un valor cuantificable para el negocio y deja los datos en un estado consistente, como por ejemplo, Autorizar Crdito o Solicitar Precio. Un error tpico de los casos de uso es definir muchos casos de uso a un nivel muy bajo, es decir, como un paso simple, subfuncin o subtarea en un EBP. Violaciones razonables de la gua EBP Normalmente es til crear subcasos de uso separados que representan subtareas o pasos, en un caso de uso base. La gua solo se utiliza para encontrar el nivel dominante de casos de uso en el anlisis de requisitos de una aplicacin, esto es, el nivel en el que nos tenemos que centrar para nombrarlos y escribirlos. Casos de usos y objetivos Los actores tienen objetivos y utilizan las aplicaciones para ayudarles a satisfacerlos. En consecuencia, un caso de uso de nivel EBP se denomina caso de uso de nivel de objetivo de usuario. Esto lleva a recomendar el siguiente procedimiento: 1. Encontrar los objetivos de usuario. 2. Definir un caso de usos para cada uno. En lugar de preguntar: Cules son los casos de uso?, uno comienza preguntando: Qu haces? o Cules son tus objetivos? Objetivos y casos de uso de subfuncin Aunque identificarse y ser validado o iniciar sesin se ha eliminado como objetivo de usuario, es un objetivo de nivel ms bajo, denominado objetivo de subfuncin. Slo deberan escribirse casos de uso de manera ocasional para estos objetivos de subfuncin. Un punto importante es que el nmero y granularidad de los casos de uso influyen en el tiempo y la dificultad para entender, mantener y gestionar los requisitos. El motivo vlido, ms comn para representar un objetivo de subfuncin como un caso de uso, es cuando la subfuncin se repite o es una precondicin en muchos casos de uso de nivel de objeto de usuario. Objetivos y casos de uso pueden ser compuestos
http://longinox.blogspot.com
Paso 1: Elegir el lmite del sistema Si no est clara la definicin de los lmites del sistema que se est diseando, se puede aclarar definiendo lo que est fuera. Paso 2 y 3: Identificar los actores principales y objetivos Es artificial establecer de manera estricta que la identificacin de los actores principales es antes que los objetivos de usuario. A veces, los objetivos ponen de manifiesto a los actores, o viceversa. Centrar la discusin en los actores principales en primer lugar, ya que establece el marco para investigaciones posteriores. Preguntas tiles para encontrar los actores principales Ver por el libro (pg. 61). Actores principales y de apoyo Los actores principales tienen objetivos de usuario que se satisfacen mediante el uso de servicios del sistema. stos adems pueden ser otros sistemas informticos. Los actores de apoyo, proporcionan servicios al sistema que se est diseando. La lista actor-objetivo Recoge los actores principales y sus objetivos de usurario en una lista actor-objetivo. En trminos de los artefactos UP, debera corresponderse con una seccin del artefacto Visin. Dimensin de la planificacin del proyecto En la prctica, esta lista tiene columnas adicionales para la prioridad, esfuerzo y riesgo. La complicada realidad Esta lista parece ordenada, pero la realidad de su creacin es cualquier cosa salvo eso. Son necesarias muchas tormentas de ideas y discusiones durante los talleres de requisitos. El actor principal y los objetivos de usuario dependes del lmite del sistema Actores y objetivos por medio del anlisis de eventos Otro enfoque para ayudar en la bsqueda de los actores, objetivos y casos de uso, es identificar los eventos externos. Cul son, de dnde proceden y porqu? Evento Externo Introducir lnea de venta Introducir el pago Parte del Actor Cajero Cliente o Cajero Objetivo Procesar una venta Procesar una venta
Paso 4: Definir los casos de uso Por lo general, definimos un caso de uso de nivel EBP por cada objetivo de usuario. Una excepcin tpica de lo anterior es, agrupar objetivos separados CRUD (Create, Restore, Update, Delete) en un caso CRUD, llamado, por convencin, Gestionar <X>.
http://longinox.blogspot.com
6.12 Actores
Un actor es cualquier cosa con comportamiento, incluyendo el propio sistema que se est estudiando (SuD, System under Discussion) cuando solicita los servicios de otros sistemas. Los actores no son solamente roles que juegan personas, sino tambin organizaciones, software y mquinas. Hay tres tipos de actores externos con relacin al Sud: o Actor principal: tienen objetivos de usuario que se satisfacen mediante el uso de los servicios del SuD. o Actor de apoyo: proporciona un servicio al SuD. o Actor pasivo: est interesado en el comportamiento del caso de uso, pero no es principal ni de apoyo.
http://longinox.blogspot.com
Sugerencia en la realizacin de los diagramas El smbolo encerrado entre << >>, se denomina estereotipo UML; se trata de un mecanismo para clasificar un elemento en cierto modo (<<actor>>, <<system>>, etc).
Estas listas conducen a algunos obstculos como: o Listas de funciones largas y detalladas no relacionan los requisitos en contexto cohesivo. En cambio, los casos de uso sitan los requisitos en el contexto de las historias y objetivos de uso del sitema. o Si se utilizan tanto los casos de uso como las listas de caractersticas detallada hay duplicacin.
Son aceptables las listas de caractersticas de alto nivel del sistema Es tpico y til resumir la funcionalidad del sistema con una breve lista de caractersticas de alto nivel, denominadas caractersticas del sistema, en un documento de Visin. La lista proporciona un resumen muy conciso de la funcionalidad del sistema, independientemente de la vista del caso de uso. Cuando son apropiadas las listas de caractersticas detalladas? Algunas veces los casos de uso no encajan realmente. Algunas aplicaciones exigen un punto de vista dirigido por las caractersticas (servidor de aplicaciones, sistemas middleware, ).
http://longinox.blogspot.com
6.15 Los casos de uso no son orientados a objetos 6.16 Casos de uso en el UP
Los casos de uso son vitales y centrales en el UP, que fomentan el desarrollo dirigido por casos de uso. Esto implica: o Los requisitos se recogen principalmente en casos de uso (el Modelo de Casos de Uso). o Los casos de uso son una parte importante de la planificacin iterativa. o Las realizaciones de caso de uso dirigen el diseo. o Los casos de uso, a menudo, influyen en la organizacin de los manuales de usuario. El UP diferencia entre : o Los casos de uso del sistema, como el visto en este tema (ProcesarVenta). o Los casos de uso del negocio, menos frecuentes. Se crean en la disciplina Modelado del Negocio, como parte de un esfuerzo de reingeniera de los procesos de negocio, describiendo una secuencia de acciones de un negocio como un todo para cumplir un objetivo de un actor del negocio (Restaurante -> Servir una Comida).
Casos de uso y especificacin de requisitos a lo largo de las iteraciones Esta seccin reitera la idea clave del UP y el desarrollo iterativo: medir el tiempo y el nivel de esfuerzo de la especificacin de requisitos a lo largo de las iteraciones (ver tabla 6.1, pg.73). Momento de la creacin de los artefactos del UP
Artefacto Iteracin Modelo del Dominio Modelos de Casos de Uso Visin Especificacin Complementaria Glosario Modelo de Diseo Documentacin de Arquitectura SW Modelo de Datos Modelo de Implementacin Plan de Desarrollo SW Modelo de Pruebas Marco de Desarrollo
Inicio I1 c c c c
Diseo
c c
Elab. E1En c r r r r c c c c r c r
Const. C1Cn
Trans. T1T2
r r r r r
r r
Casos de uso en la fase de inicio No todos los casos de uso se escriben en formato completo durante la fase de inicio. Supongamos que se lleva a cabo un taller de requisitos durando dos das al comienzo del estudio de un proyecto: o La primera parte del da se dedica a identificar los objetivos y el personal involucrado y especular sobre lo queda dentro o fuera del alcance del proyecto. o Se escribe una tabla de casos de uso actor-objetivo. o Se inicia el diagrama de contexto de casos de uso. Tras unas pocas horas, quizs se identifiquen unos 20 objetivos de usuario (casos de uso de nivel de usuario). o El equipo comienza a formarse un esquema de alto nivel de la funcionalidad del sistema. o Despus de esto, entre el 10% y el 20% de los casos de uso que representan las funciones complejas principales o especialmente arriesgadas, se escriben en formato completo.
http://longinox.blogspot.com
Se escriben las listas de Inters y Personal Involucrado para estos casos de uso, para descubrir requisitos ms refinados funcionales y no funcionales, o cualidades del sistema claves, como la fiabilidad y el rendimiento. El objetivo del anlisis no es completar los casos de uso de manera exhaustiva, sino dedicar unas horas a comprenderlos mejor. El promotor del proyecto necesita decidir si merece la pena un estudio profundo. La intencin del trabajo de inicio es adquirir una idea de poca fidelidad acerca del alcance de riesgo, esfuerzo, viabilidad tcnica y anlisis de negocio, para decidir avanzar, donde comenzar si se hace, o si parar.
Casos de uso en la elaboracin Se trata de una fase de mltiples iteraciones de duracin fija en las cuales se construyen incrementalmente partes del sistema arriesgadas de alto valor o significativas desde el punto de vista de la arquitectura y se identifican y clarifican la mayora de requisitos. En cada siguiente taller de requisitos breve, es el momento de adaptar y refinar la visin de los requisitos principales que sern inestables en las primeras iteraciones y se irn estabilizando en las ltimas. Durante cada taller de requisitos se refinan los objetivos de usuario y la lista de casos de uso. Se escriben y rescriben la mayora de casos de uso en formato completo. Al final de la elaboracin se escriben en detalle del 80 a 90% de los casos de uso. La elaboracin conlleva programar partes del sistema. Casos de uso en la construccin La etapa de construccin est compuesta de iteraciones de duracin fija que se centra en completar el sistema una vez que las principales cuestiones arriesgadas e inestables se han establecido en la elaboracin. En esta etapa, la mayora de los requisitos funcionales y no funcionales principales deberan haberse estabilizado de manera iterativa y adaptable.
6.17 Caso de estudio: casos de uso en la fase de inicio de NuevaEra 6.18 Lecturas adicionales 6.19 Artefactos UO y contexto del proceso
http://longinox.blogspot.com