Introducción a los casos de uso

Temas UNIDAD 1 Requerimientos de Software Actores e Involucrados relevantes ¿Qué es un caso de uso? ¿Cuándo usar casos de uso?

Requerimientos de Software Un requerimiento es considerado una condición o capacidad a la que se debe ajustar el sistema que se está desarrollando Un requerimiento es una capacidad o cualidad que el sistema ofrece.

Los requerimientos pueden ser funcionales y no funcionales.

Los requerimientos funcionales definen los servicios que el sistema ofrece al usuario.

Ej. Agregar registro de contrato, Eliminar registro.

Los requerimientos no funcionales definen aspectos de calidad del sistema.

Ej. Performance, usabilidad, etc.

Requerimientos Los requerimientos funcionales de software describen las funcionalidades en términos del sistema que entregan valor al usuario.

Los requerimientos funcionales de software deben concentrarse en el “qué” y no el “cómo”.

Proveen una definición de “caja negra” del sistema.

Objetivos de los requerimientos Llegar a un acuerdo formal con los clientes y usuarios finales sobre lo que el sistema debe Hacer.

Proporcionar a los miembros del proyecto una idea clara de los requerimientos del sistema.

Delimitar las fronteras del sistema.

Proporcionar las bases para la planificación del contenido técnico de las iteraciones, los costos y el tiempo para el desarrollo del sistema.

Definir la interface gráfica del sistema

Como capturar requerimientos Entrevistas.

Cuestionarios.

Encuestas.

Descripción de puestos.

Artefactos del Modelado de Negocio

TÉCNICAS DE RECOPILACIÓN DE INFORMACIÓN Los analistas utilizan una variable de métodos a fin de recopilar los datos sobre una situación existente, como entrevistas, cuestionario, inspección de registros y observación. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa. A continuación se verán cada una de ellas.

ENTREVISTA Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema, existen usuarios potenciales del sistema propuesto o aquellos que proporcionaran datos o serán afectadas por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos.

Recabar datos mediante la entrevista.

La entrevista es una forma de conversación, ¡no interrogación! Al analizar las características de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre ese sistema los analistas pueden conocerlos datos que no están disponibles en ninguna otra forma.

En las investigaciones de sistemas, las formas cualitativas y cuantitativas de la información son importantes. La información cualitativa está relacionada con opiniones, políticas y descripciones cuantitativas tratan con números, frecuencia o cantidades. A menudo las entrevistas dan la mejor fuente de información cualitativa; los otros métodos tienden a ser mas útiles en la recabación de datos cuantitativos.

Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en forma verbal. Como resultado de esto las entrevistas pueden descubrir rápidamente malos entendidos, falsas expectativas o incluso resistencia potencial para las aplicaciones en desarrollo; mas aún a menudo es más fácil calendarizar una entrevista con los gerentes del alto nivel, que pedirles que llenen cuestionarios.

Generalidades de la entrevista.

La estructura de las entrevistas varía. Si el objetivo de la entrevista radica en adquirir información general, es conveniente elaborar una serie de preguntas sin estructura, con una sección de preguntas y respuestas libres. La atmósfera abierta y de fácil flujo de esta modalidad proporciona una mayor oportunidad para conocer las actitudes, ideas y creencias de quien responde. Sin embargo, cuando los analistas necesitan adquirir datos más específicos sobre la aplicación o desean asegurar una alta confiabilidad en las respuestas a las preguntas que han propuesto a sus entrevistados, las entrevistas estructuradas son mejores.

Las entrevistas estructuradas utilizan preguntas estandarizadas. El formato de respuestas para las preguntas puede ser abierto o cerrado; las preguntas para respuesta abierta permiten a los entrevistados dar cualquier respuesta que parezca apropiada. Con las preguntas para respuestas cerradas se proporciona al usuario un conjunto de respuestas que se pueda seleccionar.

Todas las personas que responden se basan en un mismo conjunto de posibles respuestas.

La confiabilidad es solo una consideración en la selección del método de entrevista. Los analistas también deben dividir su tiempo entre desarrollar preguntas para entrevistas y analizar las respuestas. Las entrevistas no estructuradas requieren menos tiempo de preparación, porque no se necesita tener por anticipado las palabras precisas de las preguntas. Sin embargo, analizar las respuestas después de las entrevistas lleva más tiempo que con las entrevistas estructuradas. De cualquier manera, el mayor costo radica en la preparación, administración y análisis de las entrevistas estructuradas para preguntas cerradas.

Dado que un número de personas se seleccionara para la entrevista, los analistas deben tener cuidado de incluir aquellas personas que tienen información que no se podrá conseguir de otra forma. Durante las primeras etapas de un estudio de sistemas, cuando los analistas determinan la factibilidad del proyecto, con frecuencia las entrevistas solo se aplican a la gerencia o personal de supervisión. Sin embargo, durante la investigación detallada en donde el objetivo es descubrir hechos específicos, opiniones y conocer como se manejan las operaciones desempeñadas actualmente, las entrevistas se aplican en todos los niveles gerenciales y de empleados y dependen de quien pueda proporcionar la mayor parte de la información útil para el estudio. Así, los analistas que estudian ala administración de inventarios pueden entrevistar a los trabajadores del embarque y de recepción, al personal del almacén y a los supervisores de los diferentes turnos, es decir, aquellas personas que realmente trabajan en el almacén; también entrevistaran a los agentes más importantes.

Realización de la entrevista.

La habilidad del entrevistador es vital para el éxito en la búsqueda de hechos por medio de la entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparación del objetivo de una entrevista específica como de las preguntas por realizar a una persona determinada.

El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. La falta de estos factores puede reducir cualquier oportunidad de éxito. Por ejemplo, un analista que trabaja en la aplicación enfocada a la reducción de errores probablemente no tendría éxito si llegar a una oficina de gerencia de nivel medio con la presentación equivocada, por ejemplo, si dijera, "hola, fui enviado para encontrar una forma de mojar el rendimiento y de reducir los errores que presentan aquí. O la introducción: "Estamos aquí para resolver su problema", es igualmente mala. Es imaginable la rapidez con la que va a responder ser irrita y se molesta con un enfoque de este tipo.

A través de la entrevista, los analistas deben preguntarse a sí mismos las siguientes interrogantes: ¿Qué es lo que me está diciendo la persona? ¿Por qué me lo está diciendo a mí? ¿Qué se está olvidando? ¿Qué espera esta persona que haga yo?

Si se considera cada elemento de la información contra estas preguntas, los analistas tendrán más conocimientos no solamente de la información adquirida sino también de su importancia.

C U E S T I O N A R I O. Los cuestionarios proporcionan una alternativa muy útil para las entrevistas; sin embargo, existen ciertas características que pueden ser apropiadas en algunas situaciones e inapropiadas en otras.

Recabación de datos mediante cuestionarios Para los analistas los cuestionarios pueden ser la única forma posible de relacionarse con un gran número de personas para conocer varios aspectos del sistema. Cuando se llevan a cabo largos estudios en varios departamentos, se puede distribuir los cuestionarios a todas las personas apropiadas para recabar hechos con relación al sistema. Por supuesto, no es posible observar las expresiones o relaciones de quienes responden a los cuestionarios.

También las preguntas estandarizadas pueden proporcionar datos más confiables. Por otra parte, las características anteriores también son desventajas de los cuestionarios. Aunque su aplicación puede realizarse con un mayor número de individuos, es muy rara una respuesta total. Puede necesitarse algún seguimiento de los cuestionarios para motivar al personal que responda; todas las respuestas se encontraran en una proporción entre el 25 o 35%, que es lo más común.

Selección de formas para cuestionarios.

El desarrollo y distribución de los cuestionarios es caro; por lo tanto, el tiempo invertido en esto debe utilizarse en una forma inteligente. También es importante el formato y contenido de las preguntas en la recopilación de hechos significativos.

Existen dos formas de cuestionarios para recabar datos; cuestionario abierto y cerrados, y se aplican dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las preguntas y pueden incluirlos. Con frecuencia se utilizan ambas formas en los estudios de sistemas.

Cuestionarios abiertos.

Al igual, que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren conocer los sentimientos, opiniones y experiencias generales; también son útiles al explorar el problema básico, por ejemplo, un analista que utiliza cuestionarios para estudiar los métodos de verificación de crédito, en un medio ambiente de ventas al a menudeo, podría recabar mas información provechosa de una pregunta abierta de este tipo: ¿Cómo podría simplificarse y mejorarse el proceso de verificación de crédito para los clientes?

Cuestionarios cerrados.

El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el mejor método para obtener información sobre los hechos. También fuerza a los individuos para que tomen una posición y forma de opinión sobre los aspectos importantes.

Etapas en el desarrollo de un cuestionario Los cuestionarios bien hechos no se desarrollan rápidamente, llevan tiempo y mucho trabajo. La primera consideración se encuentra en determinar el objetivo del cuestionario. ¿Qué datos quiere conocer el analista a través de su uso? El analista define como utilizar los cuestionarios a fin de obtener los hechos al considerar la estructura mas útil para el estudio y la más sencilla de entender por parte de los interrogados.

Lleva tiempo desarrollar preguntas bien elaboradas y deben siempre probarse y modificarse, si es necesario, antes de que imprima una forma final y se distribuya.

Selección de quienes recibirán el cuestionario Aquellas personas que reciban el cuestionario deben seleccionarse de a cuerdo con la información que puedan proporcionar. Escribir o imprimir un cuestionario no significa que se pueda distribuir ampliamente sin un análisis previo. Lo pueden contestar personas no calificadas y si el cuestionario no es anónimo, y no será posible retirar sus respuestas de la muestra. La realización de esto también es desgastante y cara.

OBSERVACION ¡Ver es creer! Observar las operaciones le proporciona la analista hechos que no podría obtener de otra forma.

Recopilación de datos mediante la observación Leer en relación con una actividad del negocio le proporciona al analista una dimensión de las actividades del sistema. Entrevistar personal, ya sea directamente o a través de cuestionarios, también le ayuda y le dice algo más.

Ninguno de los dos métodos da una información completa; por ejemplo, leer en relación con un viaje en jet no reproduce la experiencia de volar a unos 30 mil pies de altura.

La observación proporciona información de primera mano en relación con la forma en que se llevan a cabo las actividades. Las preguntas sobre el uso de documentos, la manera en la que se realizan las tareas y si ocurren los pasos específicos como se pre-establecieron, pueden contestarse rápidamente si se observan las operaciones.

Cuando observar La observación es muy útil cuando el analista necesita ver de primera mano cómo se manejan los documentos, como se llevan a cabo los procesos y si ocurren los pasos especificados. Saber que buscar y como guiar su significado, también requiere de experiencia. Los observadores con experiencia captan quien utiliza los documentos y si encuentran dificultades; también están alertas para detectar documentos o registros que no se utilizan.

MUESTREO Con frecuencia, en muchas empresas la información ya se encuentra disponible para que el analista conozca las actividades u operaciones con las cuales no está familiarizado. Muchos tipos de registros e informes son accesibles si el analista sabe dónde buscar. En la revisión de registros, los analistas examinan datos y descripciones que ya están escritos o registrados y en relación con el sistema y los departamentos de usuarios. Esta forma de encontrar datos puede servir como presentación del analista, si se realiza al iniciar el estudio, o como un término de comparación de lo que sucede en el departamento con lo que los registros presentan como lo que debería suceder.

Recopilación de datos por medio de la inspección de registros.

El término "registro" se refiere a los manuales escritos sobre políticas, regulaciones y procedimientos de operaciones estándar que la mayoría de las empresas mantienen como guía para gerentes y empleados. Los manuales que documentan o describen las operaciones para los procesos de datos existentes, o sistemas de información que entran dentro del área de investigación, también proporcionan una visión sobre la forma en la que el negocio debería conducirse. Normalmente muestran los requerimientos y restricciones del sistema (como cantidad de transacciones o capacidad de almacenamiento de datos) y características de diseño (controles y verificación del procesamiento).

Los registro permiten que los analistas se familiaricen con algunas operaciones, oficinas de la compañía y relaciones formales a las que debe darse apoyo. No obstante, no muestran como producen de hecho las actividades, donde se ubica el poder verdadero para las decisiones, o como se realizan las tareas en la actualidad. Los otros métodos con objeto de encontrar

datos estudiados en esta sección son más eficaces para proporcionar al analista este tipo de información.

Selección de los registros para revisión En la mayor parte de las empresas los manuales de estándares sobre procedimientos de operación usualmente son obsoletos; a menudo no se mantienen al corriente lo suficiente para señalar los procedimientos existentes.

Los diagramas de organización muestran como las diferentes unidades deberían relacionarse con otras; pero muchas no reflejan las operaciones actuales.

Actores e Involucrados relevantes Definición Actores Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema. Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores.

Un actor es aquel involucrado relevante que tiene interacción con el sistema.

Puede ser una persona, una empresa u organización, un programa o un sistema computacional.

Se emplea el término de actor para llamar así al usuario, cuando desempeña ese papel dentro del sistema. Cuando se trata con actores, conviene pensar en los papeles, no en las personas ni en los títulos de sus puestos. Los actores llevan a cabo casos de uso. Un mismo actor puede realizar muchos casos de uso; a la inversa, un caso de uso puede ser realizado por varios actores.

Se debe tener en cuenta que no es necesario que los actores sean seres humanos, a pesar de que los actores estén representados por figuras humanas en el diagrama de casos de uso. El actor puede ser también un sistema externo, que necesite cierta información del sistema actual o interactúe con él, como una base de datos, por ejemplo.

Una forma fácil de representar casos de uso, es haciendo que sólo se muestren los actores del sistema cuando ellos sean los que necesiten el caso de uso. Por tanto, si el sistema genera cada noche un archivo que después es recogido por el sistema de contabilidad, entonces éste es el actor que corresponde, debido a que es quien necesita el archivo generado.

Un involucrado relevante es aquel que tiene un interés de por medio en las funcionalidades del sistema.

El actor primario es aquel que generalmente inicia un caso de uso.

Los involucrados relevantes pueden participar o no en un caso de uso.

Elementos Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso.

¿Qué es un caso de uso?

Típicamente los casos de uso son útiles para documentar requerimientos funcionales de un sistema o para documentar los procesos de negocio de una organización (casos de uso de negocio).

Un caso de uso describe el comportamiento de cómo un sistema responde a las solicitudes de uno de los involucrados relevantes llamado actor primario. El sistema responde protegiendo los intereses de todos los involucrados relevantes.

Los casos de uso son generalmente un documento de texto. Sin embargo, pueden ser representados como diagramas de flujo, diagramas de secuencia, redes de Petri o en un lenguaje de programación.

Un caso de uso debe ser fácil de leer. Contiene oraciones de una sola forma gramática -pasos que representan una acción- en las que el actor alcanza una meta.

Sirven como un medio de comunicación entre personas que no tienen habilidades especializadas en el área de desarrollo de software, por lo cual los casos de uso en forma de documentos de texto son la mejor opción.

Para escribir un caso de uso efectivo se deben tener en cuenta los siguientes tres aspectos: Alcance: Qué es el sistema en discusión.

Actor primario: Quién tiene la meta.

Nivel: Que tan alto o bajo es el nivel de esa meta.

Un caso de uso puede ser representado como una secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso

debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema.

Relaciones de Casos de Uso Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML, el cual describe notación gráfica para esas relaciones.

Inclusión (include o use) Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para extraer comportamientos verdaderamente comunes desde múltiples casos de uso a una descripción individual, desde el caso El estándar de Lenguaje de Modelado Unificado de OMG define una notación gráfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocación pensando que un caso de uso es una notación gráfica (o es su descripción). Mientras la notación gráfica y las descripciones son importantes, ellos forman parte de la documentación de un caso de uso --un propósito para el que el actor puede usar el sistema. de uso que lo incluye hasta el caso de uso incluido, con la etiqueta "«include»". Este uso se asemeja a una expansión de una macro, donde el comportamiento del caso incluido es colocado dentro del comportamiento del caso de uso base. No hay parámetros o valores de retorno.

Aquí también podemos decir q este va de padre a hijo.

Extensión (Extend) Es otra forma de interacción, un caso de uso dado, (la extensión) puede extender a otro. Esta relación indica que el comportamiento del caso de La extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o inclusión. Uso extensión puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea discontinua, desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión.

"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensión son los ejemplos o instancias de los conceptos."

Generalización "Entonces la Generalización es la actividad de identificar elementos en común entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonómicas entre conceptos que entonces se representan en jerarquías de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intención y extensión."

En la tercera forma de relaciones entre casos de uso, existe una relación generalización/especialización. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una línea sólida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de subclases, en la práctica puede ser útil factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.

Ejemplos de casos de uso Para comprender un poco mejor la funcionalidad de los casos de uso, se da un pequeño ejemplo de cómo funcionan todos los elementos integrados en un diagrama, tanto actores como relaciones y casos de uso como tal.

Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea. En la Figura se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automático.

Con este ejemplo podemos comprender las diferentes relaciones entre Casos de Uso

Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción con un alcance menor como caso de uso. La razón para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicación en el equipo de desarrollo, el manejo de la documentación de casos de uso. Para el caso de que queramos utilizar estos casos de uso más pequeños, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos: • Incluye (<>): Un caso de uso base incorpora explícitamente a otro caso de uso en un lugar especificado en dicho caso base. Se suele utilizar para encapsular un comportamiento parcial común a varios casos de uso. En la Figura se muestra cómo el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso Autorización.

• Extiende (<>): Cuando un caso de uso base tiene ciertos puntos (puntos de extensión) en los cuales, dependiendo de ciertos criterios, se va a realizar una interacción adicional. El caso de uso que extiende describe un comportamiento opcional del sistema (a diferencia de la relación incluye que se da siempre que se realiza la interacción descrita) En la Figura se muestra como el caso de uso Comprar Producto permite explícitamente extensiones en el siguiente punto de extensión: info regalo. La interacción correspondiente a establecer los detalles sobre un producto que se envía como regalo están descritos en el caso de uso Detalles Regalo.

Ambos tipos de relación se representan como una dependencia etiquetada con el estereotipo correspondiente (<> o <>), de tal forma que la flecha indique el sentido en el que debe leerse la etiqueta. Junto a la etiqueta <> se puede detallar el/los puntos de extensión del caso de uso base en los que se aplica la extensión.

• Generalización ( ): Cuando un caso de uso definido de forma abstracta se particulariza por medio de otro caso de uso más específico. Se representa por una línea continua entre los dos casos de uso, con el triángulo que simboliza generalización en UML (usado también para denotar la herencia entre clases) pegado al extremo del caso de uso más general. Al igual que en la herencia entre clases, el caso de uso hijo hereda las asociaciones y características del caso de uso padre. El caso de uso padre se trata de un caso de uso abstracto, que no está definido completamente. Este tipo de relación se utiliza mucho menos que las dos anteriores.

¿Cuándo usar casos de uso?

Son una herramienta esencial para la captura de requerimientos, la planificación o el control de proyectos iterativos. La captura de los casos de uso es una de las tereas principales durante la fase de elaboración; de hecho es lo primero que se debe hacer.

La mayoría de los casos de uso se generaran durante la fase del proyecto, pero se irán descubriendo otros a medida que se avance. Todo caso de uso es un requerimiento potencial y hasta que o se hayan capturado todos los requerimientos, no se podrá planear como se manejaran estos en el proyecto.

Algunas personas prefieren listar y analizar los casos de uso primero y luego llevar a cabo un poco de modelado. Esta fase ayuda en gran medida a comprender mejor los procesos de interacción, el modelado conceptual ayuda a descubrir los casos de uso.

Los diseñadores emplean casos de uso en distintos grados de granularidad.

Pero es recomendable o manejar demasiados, que hagan tedioso y extenso el trabajo dependiendo de su interpretación.

Para concluir podemos comentar que los casos de uso se usan cuando se desea definir el comportamiento de un sistema de una manera clara, coherente y fácil de entender. Cuando se tienen la necesidad de comunicar el comportamiento de un sistema con miembros de un equipo multidisciplinario.

Cuando es necesario documentar los requerimientos funcionales de un sistema. Cuando se desea estimar el esfuerzo que representará el diseño y construcción de un sistema.