MODELO DE CASOS DE USO, ESCRITURA DE REQUISITOS EN CONTEXTO

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.1 Objetivos e historias

Los clientes y los usuarios finales tienen objetivos (necesidades) y quieren sistemas informticos que le ayuden a conseguirlos. Los casos de uso son un mecanismo para ayudar a mantenerlo simple y entendible para todo el personal involucrado. De manera informal, son historias del uso de un sistema para alcanzar los objetivos. En esencia los casos de uso, necesitan descubrir y registrar los requisitos funcionales, mediante la escritura de historias del uso de un sistema (ver ej. Procesar Venta, pg. 44).

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).

6.3 Casos de uso y valor aadido

Un actor es algo con comportamiento, como una persona (identificada por un rol), sistema informatizado u organizacin. Un escenario es una secuencia especfica de accione e interacciones entre los actores y el sistema objeto de estudio; tambin denominada instancia de caso de uso. Es una historia particular del uso de un sistema, o un camino a travs del caso de uso. Ejemplo: o El escenario de xito de compra de artculos con pago en efectivo. o El escenario de fallo al comprar debido al rechazo de la transaccin de pago con tarjeta. Informalmente, un caso de uso es una coleccin de escenarios con xito y fallo relacionados, que describe a los actores utilizando un sistema para satisfacer un objetivo (ver ej. Gestionar Devoluciones, pg. 45). El RUP proporciona una definicin alternativa de un caso de uso: o Un conjunto de instancias de caso de uso, donde cada instancia es una secuencia de acciones que un sistema ejecuta, produciendo un resultado observable de valor para un actor principal. Una actitud clave en el trabajo con casos de uso es centrarse en la pregunta: Cmo puedo, utilizando el sistema, proporcionar un valor observable al usuario, o cumplir sus objetivos?

6.4 Casos de uso y requisitos funcionales

Los casos de uso ante todo, son requisitos funcionales que indican qu har el sistema. Los casos de uso, definen una promesa o contrato de la manera en la que se comportar un sistema. Los casos de uso son documentos, no diagramas y el modelado de casos de uso es, sobre todo, una accin de escribir texto, no dibujar. Sin embargo, UML define un diagrama de casos de uso para ilustrar los nombres de casos de uso y actores, y sus relaciones.

Longinos Recuero Bustos

Diseo del software 2012-13

http://longinox.blogspot.com

6.5 Tipos de casos de uso y formatos

Casos de uso de caja negra y las responsabilidades del sistema Los casos de uso de caja negra son la clase ms comn y recomendada. Describe el sistema en base a las responsabilidades que tiene (los elementos software tienen responsabilidades y colaboran con otros elementos que tienen responsabilidades). Es posible especificar el qu debe hacer el sistema sin decidir cmo lo har. Tipos de formalidad Los casos de uso se escriben con varios grados de formalidad, dependiendo de la necesidad: o Breve: resumen conciso de un prrafo. o Informal: formato de prrafo en un estilo informal. o Completo: se escriben con detalle todos los pasos y variaciones y hay secciones de apoyo como precondiciones y garantas de xito.

6.6 Ejemplo completo: Procesar Venta

El formato usecases.org Quizs el formato ms ampliamente extendido y compartido: Esquemas de composicin: o Actor principal o Personal involucrado e intereses o Precondiciones o Garantas de xito (Postcondiciones) o Escenario principal de xito (o Flujo Bsico) o Extensiones (o Flujos Alternativos) o Requisitos especiales o Lista de tecnologa y variaciones de datos o Frecuencia o Temas abiertos La variacin de dos-columnas Este formato, destaca el hecho de que se establece una interaccin entre los actores y el sistema. Propuesto por Rebeca Wirfs-Brock y promovido por Constantine y Lockwood para ayudar en el anlisis e ingeniera de usabilidad. Cul es el mejor formato? No existe un mejor formato.

6.7 Explicacin de las secciones

Elementos del prlogo Hay que situar al principio slo los elementos que son importantes que se lean antes del escenario principal de xito. Importante: Personal involucrado y lista de intereses Esta lista es muy importante. Sugiere y delimita que es lo que debe hacer el sistema. Citando a Cockburn:

Longinos Recuero Bustos

Diseo del software 2012-13

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.

6.8 Objetivos y alcance de un caso de uso

Cmo deberan descubrirse los casos de uso?

Longinos Recuero Bustos

Diseo del software 2012-13

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

6.9 Descubrimiento de actores principales, objetivos y casos de uso

Los casos de uso se definen para satisfacer los objetivos de usuario de actores principales. El procedimiento bsico es: 1. Elegir los lmites del sistema. Es slo una aplicacin software? El hardware y la aplicacin como un todo?, Lo utiliza ms de una persona? 2. Identificar los actores principales. 3. Identificar los objetivos de cada actor principal. Elevarlos al nivel de objetivos de usuario ms alto que satisfaga la gua EBP. 4. Definir los casos de uso que satisfagan los objetivos de usuario; nombrarlos de acuerdo con sus objetivos.

Longinos Recuero Bustos

Diseo del software 2012-13

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>.

Longinos Recuero Bustos

Diseo del software 2012-13

http://longinox.blogspot.com

6.10 Enhorabuena: se han escrito los casos de uso y no son perfectos

La necesidad de comunicacin y participacin Comunicacin personal contina. Comunicacin y participacin cercana y continua diaria, entre los desarrolladores y alguien que entienda el dominio y pueda tomar decisiones sobre los requisitos.

6.11 Escritura de casos de uso en un estilo esencial independiente de la interfaz de usuario

Nuevo y mejorado! Razones a favor de utilizar las huella dactilares Investigar y preguntar acerca de los objetivos, en lugar de las tareas y procedimientos fomenta que se centre la atencin en la esencia de los requisitos. Durante el proceso de descubrimiento es posible abrir la visin a soluciones nuevas y mejoradas, aunque esto puede conllevar tambin a un anlisis de usabilidad como, conocer el perfil de los usuarios tpicos del sistema. Escritura en estilo esencial Esta idea se ha resumido en varias guas de casos de uso como no considere la interfaz de usuario; cntrese. En un estilo de escritura esencial, la narracin se expresa al nivel de las intenciones de los usuarios y responsabilidades del sistema, en lugar de sus acciones concretas. Ejemplos de contraste Estilo esencial Estilo concreto, evitar durante el trabajo de requisitos inicial

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.

6.13 Diagramas de casos de uso

Los diagramas de caso de uso y las relaciones entre los casos de uso son secundarios en el trabajo con los casos de uso. Los casos de uso son documentos de texto. Trabajar con los casos de usos significa escribir texto. Una sugerencia es, dibujar un diagrama de casos de usos sencillo junto con la lista actor-objetivo. Un diagrama de casos de usos es una excelente representacin del contexto del sistema, conforma un buen diagrama de contexto. Sirve como herramienta de comunicacin que resume el comportamiento de un sistema y sus actores.

Longinos Recuero Bustos

Diseo del software 2012-13

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).

Advertencia sobre el exceso de diagramas

6.14 Requisitos en contexto y listas de caracterstica de bajo nivel

Una motivacin clave de la idea de caso de uso es considerar y organizar los requisitos en el contexto de los objetivos y escenarios de uso de un sistema. Un idea detrs de los casos de uso es sustituir las listas de caractersticas de bajo nivel por casos de uso: ID CARAC1.9 CARAC2.4 Caractersticas El sistema aceptar entradas de los identificadores de los artculos. El sistema registrar los pagos a crdito en el sistema de cuentas por cobrar.

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, ).

Longinos Recuero Bustos

Diseo del software 2012-13

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

Disciplina Modelado del Negocio Requisitos

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

Implementacin Gestin del Proyecto Pruebas Entorno

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.

Longinos Recuero Bustos

Diseo del software 2012-13

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

Longinos Recuero Bustos

Diseo del software 2012-13

http://longinox.blogspot.com