• Author / Uploaded
• Isidro Padilla

Citation preview

2.8.1 Ejemplo de un caso expandido de uso: Preparar Producto Un caso expandido de uso muestra más detalles que uno de alto nivel; suelen ser útiles para alcanzar un conocimiento más profundo de los procesos y de los requerimientos. Se llevan a cabo en un estilo coloquial entre los actores y el sistema. Ejemplo: Caso de Uso:

Preparar Producto.

Actores:

Máquina

Propósito:

Preparación del producto solicitado.

Resumen:

Un usuario hace uso de la máquina introduciendo el dinero y seleccionando el producto que desea. Si todo es correcto, la máquina se encarga de preparar el producto para que el usuario lo retire.

Tipo:

Primario y esencial.

Referencias Cruzadas:

Funciones: R1, R2, R3 Curso normal de los eventos Acción del actor

Respuesta del sistema

1. Este caso de uso comienza cuando el 2. El sistema comprueba que exista el operario introduce en la máquina el producto solicitado. dinero e indica el producto que desea. 3. El usuario elige el nivel de azúcar que 4. La máquina inicia el proceso de desee. preparación y el usuario espera hasta que esta termina. Cursos alternos: 

Línea 1: introducción de cantidad de dinero menor que el precio del producto. Indicar error.

2.8.2 Explicación del formato expandido: Caso de uso: Actores: Propósito: Resumen: Tipo: Referencias cruzadas:

Nombre del caso de uso. Lista de actores(agentes externos), en la cual se indica quién inicia el caso de uso. Intención del caso de uso. Repetición del caso de uso de alto nivel o alguna síntesis similar. 1. Primario, secundario u opcional. 2. Esencial o real. Casos relacionados de uso y funciones también relacionadas del sistema.

La sección intermedia, curso normal de los eventos, es la parte principal del formato expandido; describe los detalles de la conversión interactiva entre los actores y el sistema. Explica la secuencia más común de los eventos: la historia normal de las actividades y la terminación exitosa de un proceso. No incluye situaciones alternas. Curso normal de los eventos: Acción del actor Acciones numeradas de los actores.

Respuesta del sistema Descripciones numeradas de las respuestas del sistema.

La última sección, curso alterno de los eventos, describe importantes opciones o excepciones que pueden presentarse en relación con el curso normal. Si son complejas, podemos expandirlas y convertirlas en nuestros casos de uso. Cursos alternos: Alternativas que pueden ocurrir en el número de línea. Descripción de excepciones.

Diagramas de casos de uso. Un diagrama de casos de uso explica gráficamente un conjunto de casos de uso de un sistema, los actores y la relación entre éstos y los casos de uso. Los casos de uso se muestran en óvalos y los actores en figuras estilizadas. Hay líneas de comunicaciones entre los casos y los actores; las flechas indican el flujo de la información o el estímulo. El objetivo del diagrama es ofrecer una clase de diagrama contextual que nos permita conocer rápidamente los actores externos de un sistema y las formas básicas en que lo utilizan.

Máquina de Café

Preparar Producto

Figura 2.3 Diagrama parcial de casos de uso

2.13

Formatos de los casos de uso.

Un mismo caso de uso puede escribirse en diferentes formatos y con diversos niveles de detalle. Los podemos dividir en: casos con formato de alto nivel y expandido. 2.13.1 Formato de alto nivel: Un caso de uso de alto nivel describe un proceso muy brevemente, casi siempre en dos o tres enunciados. Se aconseja su uso durante el examen inicial de los requerimientos y del proyecto, para entender de forma rápida el grado de complejidad y funcionalidad del sistema. 2.13.1 Formato expandido: Un caso de uso expandido describe un proceso más a fondo que el de alto nivel. Se diferencia con éste, en que tiene una sección destinada al curso normal de los eventos, que los describe paso por paso. Durante la fase de especificación de requisitos, es conveniente escribir en el formato expandido los casos más importantes y de mayor influencia. 2.14

Los sistemas y sus fronteras.

Un caso de uso describe la interacción con un sistema. Las fronteras del sistema son:   

La frontera hardware/software de un dispositivo o sistema de cómputo. El departamento de una organización. La organización entera.

Caso de uso

Actor Frontera de un caso de uso

Figura 2.4 Frontera de un caso de uso Es importante definir la frontera del sistema para identificar lo que es interno o externo, así como las responsabilidades del sistema. El ambiente externo está representado únicamente por actores. Estudiaremos un ejemplo de la influencia que tiene seleccionar la frontera del sistema: la compra del producto en la máquina de café y en el supermercado. Si elegimos como “el sistema” el supermercado, el único actor es el usuario y no la máquina, porque este último es un recurso del supermercado que realiza las funciones. Pero si escogemos como sistema el hardware y el software de la máquina de café, se trata como actores al usuario y a la máquina. Ambas situaciones se ilustran mejor a continuación:

Compra productos

Máquina

Usuario

Prepara producto

Entrega cambio

Puesto de máquina de café

Compra productos

Usuario

Prepara producto

Entrega cambio

Supermercado

Figura 2.5 Casos de uso y actores cuando las fronteras son distintas 2.15

Casos de uso primarios, secundarios y opcionales. Los casos de uso se clasifican en:   

2.16

Casos primarios de uso: representan los procesos comunes más importantes, como Preparar Producto. Casos secundarios de uso: representan procesos menores o raros, por ejemplo: Pedir Azúcar. Casos opcionales: representan procesos que pueden no abordarse.

Casos esenciales de uso comparados con los casos reales de uso.

2.16.1 Casos esenciales de uso: Los casos esenciales de uso son casos expandidos que se expresan en una forma teórica que contiene pocos detalles de implementación; las decisiones de diseño se posponen, especialmente las de la interfaz para el usuario. Estos casos describen el proceso a partir de sus actividades. Los casos de alto nivel siempre son de carácter esencial, debido a su brevedad y abstracción. Como ejemplo vamos a ver, un caso de Retiro de efectivo en un cajero automático, que se expresa de forma esencial.

Acción de los actores 1. El cliente se identifica. 3. y así sucesivamente.

Respuesta del sistema 2. Presenta opciones. 4. y así sucesivamente.

La forma en que un cliente se identifica cambia con el tiempo(es una decisión de diseño), pero forma parte del proceso esencial de que la identificación se realice de alguna manera. Conviene crear casos esenciales de uso al comenzar a investigar los requerimientos, para entender mejor el alcance del problema y las funciones necesarias. Este tipo de casos permiten captar la esencia del proceso y sus motivos fundamentales, sin ahondar en detalles de diseño. 2.16.2 Casos reales de uso:

Un caso real de uso describe el proceso a partir de su diseño concreto actual, sujeto a las tecnologías de entrada y de salida. Cuando se trata de la interfaz para el usuario, ofrece presentaciones de pantalla y explica la interacción con los artefactos. Por ejemplo, el caso Retiro de efectivo expresado en forma real:

Acción de los actores 1. El cliente introduce su tarjeta. 3. Introduce el NIP con un teclado numérico. 5. y así sucesivamente.

Respuesta del sistema 2. Pide el número de identificación personal(NIP). 4. Muestra el menú de opciones. 6. y así sucesivamente.

Observe que la acción esencial del “Cliente se identifica a sí mismo”, se realizó ahora en la serie de acciones comenzando con “El cliente introduce su tarjeta”. Los casos reales de uso se crean durante la fase de diseño por ser un elemento de éste. Sin embargo, en algunos proyectos las primeras decisiones de diseño con respecto a la interfaz para el usuario, se discuten en la fase de elaboración, debido a esto, se establecen casos reales en dicha fase. 2.17

Notación de los casos de uso.

2.17.1 Asignación de nombres a los casos de uso: El nombre de un caso de uso debe comenzar con un verbo para especificar que se trata de un proceso. Ejemplo:   

Preparar producto. Dar cambio. Recibir dinero.

2.17.2 Inicio de un caso expandido de uso: Comience un caso expandido con el siguiente esquema: 1. Este caso comienza cuando

Por ejemplo: 1. Este caso de uso comienza cuando la máquina recibe el dinero por parte del usuario. De esta manera, se identifica claramente el actor y el evento iniciadores. 2.17.3 Decisión de notación y ramificación: Un caso de uso puede contener puntos de decisión. Si una de las trayectorias de decisión es un caso muy representativo y las otras alternativas son raras, inusuales o excepcionales, el caso típico debe ser el único acerca del cual se escribe en el Curso normal de los eventos y las opciones deben de escribirse en la sección Alternativas. Cuando el punto de decisión representa opciones cuya probabilidad es igual y normal, se usa la siguiente forma de notación: 1.

En la sección principal Curso normal de los eventos, indique las ramas de las subsecciones.

2.

Escriba una subsección en cada rama, usando otra vez Curso normal de los eventos. Inicie el evento numerando en 1 cada sección.

3.

Si las subsecciones tienen opciones, escríbalas en una sección de alternativas de cada subsección.

Por ejemplo, supongamos que un solicitante de pedidos puede modificar la cantidad a pedir, pero siempre por debajo de la cantidad máxima. Esto puede dar origen a dos modos distintos de realizar un pedido, automático o manual. En el modo automático no se podrá modificar la cantidad a pedir, mientras que en el modo manual sí. En el modo manual, el actor deberá confirmar el pedido, para indicar así que no va a realizar más modificaciones.

Sección: principal

Curso normal de los eventos

Acción del actor 1.Este caso de uso comienza cuando el solicitante de pedido indica el producto para el que se va a realizar el pedido. 2. El solicitante, puede hacer el pedido de dos formas:

Respuesta del sistema

Si lo hace de manera manual, consúltese la sección Realizar pedido manual. b) Si lo realiza de forma automática, consulte la sección Realizar pedido automático. a)

3. Comprueba que no exista un pedido para ese mismo producto. 4. Calcula la cantidad a pedir. 5. Registra el pedido.

Sección: Realizar pedido manual Curso normal de los eventos Acción del actor

Respuesta del sistema

1. El solicitante realiza el pedido de forma manual. 2. Comprueba que no exista un pedido para ese producto. 3. Calcula la cantidad a pedir. 4. Modifica la cantidad a pedir. 5. Confirma el pedido. 6. Registra el pedido. Cursos alternativos: Línea 2: Existe un pedido para el producto. Indica error. Finaliza caso de uso. Línea 4: Cantidad introducida no está dentro de los límites. No permite la modificación. Sección: Realizar pedido automático. Curso normal de los eventos Curso normal de la historia con solicitud manual, exceptuando las líneas 4 y 5. Cursos alternativos: Línea 2: Existe un pedido para el producto. Indica error. Finaliza caso de uso. 2.18

Casos de uso dentro de un proceso de desarrollo.

2.18.1 Pasos de la fase de planeación y elaboración: 1. Después de haber listado las funciones del sistema, defina la frontera e identifique los actores y casos de uso. 2. Escriba todos los casos de uso en el formato de alto nivel. Clasifíquelos en primarios, secundarios u opcionales. 3. Dibuje el diagrama de casos de uso. 4. Relacione los casos de uso y dé ejemplo de las relaciones en el diagrama correspondiente.

5. Escriba en el formato esencial expandido los casos de uso más importantes, para entender mejor el problema. 6. Los casos reales deberían posponerse hasta una fase de diseño, porque su creación conlleva decisiones de diseño. Sin embargo, a veces es necesario crear casos reales de uso durante la etapa de los requerimientos si:  

Las descripciones facilitan la comprensión. Los clientes exigen especificar sus procesos en esta forma.

2.18.2 Identifique los actores y casos de uso: Defina la frontera del sistema que será el sistema de hardware/software. Un ejemplo de lista de los actores y procesos relevantes son los siguientes:  

El usuario de la máquina.  Introduce las monedas en la máquina.  Si lo desea, pide el nivel de azúcar. La máquina  Recibe el dinero.  Prepara el producto.  Si es necesario, prepara el cambio.  Si es necesario, cancela la operación.

2.18.3 Escriba los casos de uso en el formato de alto nivel: Una muestra de casos de uso de alto nivel comprende: Caso de uso:

Recibir Dinero

Actores:

Máquina

Tipo:

Primario

Descripción:

Antes de realizar cualquier otra operación, la máquina espera el dinero para almacenarlo y luego brindar el servicio.

2.18.4 Dibuje un diagrama de casos de uso: Se presenta a continuación el diagrama de nuestro ejemplo:

Recibir dinero

Pedir azúcar

Figura 2.6 Diagrama de casos de uso de la máquina de café 2.18.5 Relacione los casos de uso: Este tema se abordará posteriormente. 2.18.6 Escriba algunos casos esenciales expandidos de uso: Entre los casos primarios de uso realmente significativos figuran:  Preparar producto. Escribirlo en una forma esencial expandida suministrará una mayor información y claridad de los requerimientos. A continuación se presenta el caso de uso Preparar producto en su forma esencial expandida completa: Caso de Uso:

Preparar Producto.

Actores:

Máquina

Propósito:

Preparación del producto solicitado.

Resumen:

Un usuario hace uso de la máquina introduciendo el dinero y seleccionando el producto que desea. Si todo es correcto, la máquina se encarga de preparar el producto para que el usuario lo retire.

Tipo:

Primario y esencial.

Referencias Cruzadas:

Funciones: R1, R2, R3

Curso normal de los eventos Acción del actor

Respuesta del sistema

1. Este caso de uso comienza cuando el 2. El sistema comprueba que exista el operario introduce en la máquina el producto solicitado. dinero e indica el producto que desea. 3. El usuario elige el nivel de azúcar que 4. La máquina inicia el proceso de desee. preparación y el usuario espera hasta que esta termina. 2.18.7 Si es necesario, escriba algunos casos reales de uso: Esto se realizará en temas posteriores.

Modelos conceptuales. El modelo conceptual es el elemento más importante a crear durante el análisis orientado a objetos1. El paso esencial de un análisis orientados a objetos es descomponer el problema en conceptos u objetos individuales. Un modelo conceptual es una representación de conceptos en un dominio del problema. En UML, se ilustra con un grupo de diagramas de estructura estática donde no se define ninguna operación. Una cualidad esencial que debe tener un modelo conceptual es que representa cosas del mundo real, no componentes del software. Puede mostrarnos:  Conceptos.  Asociaciones entre conceptos. Atributos de conceptos.

2.20.1 Obtención de conceptos a partir de una lista de categorías de conceptos: Al crear un modelo conceptual, debemos comenzar preparando una lista de conceptos idóneos a partir de la siguiente lista. Contiene muchas categorías comunes que se debe tener en cuenta, sin importar el orden de importancia. Categoría del concepto Objetos físicos o tangibles Especificaciones, diseño o descripciones de cosas Lugares Transacciones Línea o renglón de elemento de transacciones Papel de las personas Contenedores de otras cosas Cosas dentro de un contenedor Otros sistemas de cómputo o electromecánicos externos al sistema Conceptos de nombres abstractos Organizaciones Eventos Procesos(a menudo no están representados como conceptos, pero pueden estarlo) Reglas y políticas Catálogos Registros de finanzas, de trabajo, de contratos de asuntos legales Instrumentos y servicios financieros Manuales, libros 1

Ejemplos Producto Catálogo de libros Centro de almacenamiento Venta Descripción Bibliotecario, Vendedor. Catálogo Producto Fax Stock Universidad Robo, incendio SolicitarPedido TramitarPedidoEspecial CatalogodeProductos ContratoProveedor

Los casos de uso son importantes en el análisis de requerimientos, pero no están orientados a objetos.

Identificación de las asociaciones: lista de asociaciones comunes. Agregue las asociaciones utilizando la lista que se presenta a continuación. El ejemplo corresponde al dominio de una universidad. Categoría A es una parte física de B A es una parte lógica de B A está físicamente contenido en B A está contenido lógicamente en B A es una descripción de B A es un elemento de línea en una transacción o reporte B A se conoce/introduce/registra/presenta/captura en B A es miembro de B A es una subunidad organizacional de B A usa o dirige a B A se comunica con B A se relaciona con una transacción B A es una transacción relacionada con otra transacción de B A es propiedad de B 2.26.1 Asociaciones de alta prioridad:

Ejemplo Edificio – Universidad CalificacionesSemestrales – CalificacionesAnuales Estudiante – Edificio Asignatura – Programa de asignatura Objetivo de asignatura – Asignatura Nota de Estudiante – Reporte de Estudiante Matrícula – Lista de estudiantes Profesor – Departamento Secretaría – Departamento Director – Secretaria Profesor – Estudiante Estudiante – Inscripción de curso Inscripción – Cancelación Auditorio – Universidad

Las siguientes, son algunas categorías de alta prioridad que siempre conviene incluir en un modelo conceptual:    2.27

A es una parte física o lógica de B. A está física o lógicamente contenido en B. A está registrado en B.

Directrices de las asociaciones.

Es necesario identificar las asociaciones de los conceptos que se requieren para satisfacer los requerimientos de información de los casos de uso en cuestión y los que contribuyen a entender el modelo conceptual. Para identificar dichas asociaciones se deben tomar en cuenta las siguientes directrices:    

Concentrarse en las asociaciones en que el conocimiento de la relación ha de preservarse durante algún tiempo. Es más importante identificar los conceptos que las asociaciones. Muchas asociaciones tienden a confundir el modelo conceptual en vez de aclararlo. A veces se requiere mucho tiempo para descubrirlas, y los beneficios son escasos. No incluir las asociaciones redundantes ni las derivables.

2.28

Papeles. A los extremos de una asociación se les llama papeles. Estos pueden tener:   

nombre expresión de multiplicidad navegabilidad

2.28.1 Multiplicidad: La multiplicidad define cuántas instancias de un tipo A pueden asociarse a una instancia del tipo B en determinado momento. En el UML, el valor de multiplicidad depende del contexto. Por ejemplo: