requerimientos y modelo de casos de uso - v3

UNIVERSIDAD NACIONAL DE SAN CRISTOBAL DE HUAMANGA FACULTAD DE ING. MINAS, GELOGIA Y CIVIL

ESCUELA DE FORMACIÓN PROFESIONAL DE INGENIERÍA DE SISTEMAS

Sistemas de información I Doc:Elvira Fernández J Pág.: 1 de 13

1. OBJETIVOS:

Conocer los diferentes tipos de diagramas para análisis y diseño básicos en UML

Ccomprender la estructura de un modelo UML en Rational Rose: vista de casos de uso y la

vista lógica

Identificar los requerimientos Funcionales y no Funcionales del Sistema

Identificar los elementos de un diagrama de caso de uso.

2. MARCO TEÓRICO

2.1 VISTAS DE LA ARQUITECTURA EN RATIONAL ROSE

En el explorador se tienen cuatro carpetas que representan cuatro vistas de la arquitectura

del sistema. Cada vista muestra una proyección de la arquitectura y usa un conjunto de

diagramas. Las vistas de Rose son las siguientes:

a) LA VISTA DE CASOS DE USO, Use Case View: que es la vista en la que se presenta el

comportamiento deseado del sistema, en ella se encontrarían los modelos relacionados con la

captura de requisitos. En esta vista se ubicarían el

modelo del negocio, el modelo conceptual, el modelo de

casos de uso del sistema y los diagramas de secuencia

del sistema.

b) LA VISTA LÓGICA, Logical View: en la que se

encuentran los modelos que muestran el vocabulario y

la funcionalidad (estructura y comportamiento) del

sistema, a través de un conjunto de colaboraciones que

realizan los casos de uso de la vista de casos de uso

mediante diagramas de clases y diagramas de

interacción:

c) LA VISTA DE COMPONENTES, Component View: en la que se representa la

implementación del sistema mediante componentes

d) LA VISTA DE DESPLIEGUE, Deployment View: en la que se modela la distribución o

despliegue de los componentes a los nodos de procesamiento del sistema. Muestra la

topología, distribución e instalación del sistema.




2.2 FACILIDADES DEL PRODUCTO O REQUISITOS FUNCIONALES

Define una breve descripción de los requisitos funcionales del producto. Cada característica o requisito funcional es un servicio deseable externo que normalmente requiere una serie de entradas de información para alcanzar el resultado deseado.

Definir lo que el sistema debe ser capaz de hacer según las necesidades de los usuarios

del negocio.

Se pueden aplicar las siguientes guías:

Evitar el diseño. Describir las características a un nivel general. Centrándose en por qué (y no cómo) se deberían implementar.

Define lo que el sistema debe ser capaz de hacer.

2.3 REQUISITOS NO FUNCIONALES

Requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que ni describen información a guardar, ni funciones a realizar.

2.4 MODELADO DE CASOS DE USO

Los diagramas de casos de uso documentan el comportamiento de un sistema desde el

punto de vista del usuario. Por lo tanto los casos de uso determinan los requisitos funcionales

del sistema, es decir, representan las funciones que un sistema puede ejecutar.

ELEMENTOS BÁSICOS

A) ACTORES: Los actores representan un tipo de usuario del sistema. Se entiende como

usuario cualquier cosa externa que interactúa con el sistema. No tiene por qué ser un ser

humano, puede ser otro sistema informático o unidades organizativas o empresas.

NewClass

Un actor en un diagrama de casos de uso representa un rol que alguien puede estar jugando,

no un individuo particular por lo tanto puede haber personas particulares que puedan estar

usando el sistema de formas diferentes en diferentes ocasiones: socio de biblioteca y

bibliotecario.

Actores Principales: personas que usan el sistema

Actores secundarios: personas que mantienen o administran el sistema

Otros Sistemas: sistemas con lo que el sistema interactúa

http://es.wikipedia.org/wiki/Requisito_(sistemas)

http://es.wikipedia.org/wiki/Requisito_funcional

http://es.wikipedia.org/wiki/Requisito_funcional




B) CASO DE USO: Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Se representan mediante un óvulo. Cada caso de uso debe detallarse, habitualmente mediante

una descripción textual.

.

Un caso de uso especifica un comportamiento deseado del sistema.

• Representan los requisitos funcionales del sistema.

• Un caso de uso debe especificar un comportamiento deseado. Describen qué hace el sistema,

no cómo lo hace.

C) TIPOS DE RELACIONES:

Asociación: Hay una asociación entre un actor y un caso de uso si el actor interactúa con el

sistema para llevar a cabo el caso de uso.

Generalización: En un diagrama de casos de uso también pueden mostrarse generalizaciones

(relaciones de herencia) para mostrar que diferentes elementos están relacionados como

tipos de otros. Son aplicables a actores o casos de uso.

d) Un escenario es una interacción entre el sistema y los actores, que puede ser descrito

mediante una secuencia de mensajes. Un caso de uso es una generalización de un escenario.

DEPENDENCIA

• <<extend>> el primero es una función opcional del segundo (variación o punto de

extensión). Se utiliza cuando se tiene un caso de uso que es similar a otro pero que hace un

poco más.

_ Utilícese extend uando se describa una variación de conducta normal

• <<include>> el primero hace una llamada obligatoria al segundo. Ocurre cuando se tiene

una porción de comportamiento que es similar en más de un caso de uso y no se quiere copiar

la descripción de tal conducta.

_ Empléese include cuando se dese evitar repeticiones

NewUseCase




Ejemplo de Asociaciones de dependencia y generalización

2.5 PAQUETES EN UML

Los paquetes ofrecen un mecanismo general para la organización de los modelos agrupando

elementos de modelado.

Se representan gráficamente como:

Cada paquete corresponde a un subconjunto del modelo y contiene, según el modelo, clases,

objetos, relaciones, componentes y diagramas asociados.

Un paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento

pertenece a (está definido en) sólo un paquete.

Ejemplo de paquetes:




3. DESARROLLO DE LA PRÁCTICA

REQUISITOS FUNCIONALES Y NO FUNCIONALES

1.-Encontrar los requisitos funcionales y no funcionales para el siguiente ejemplo sobre una tienda de música online. Descripción del problema • Quiero vender música a través de Internet. • Los usuarios comprarán a crédito para adquirir canciones. •Los usuarios buscarán las canciones que deseen y las pagarán con créditos. • Los usuarios tendrán algunos días para descargar en su ordenador las canciones que hayan adquirido. • Quiero hacer ofertas generales (afectan a todos los usuarios) y particulares (afectan a usuarios concretos). Solución: • La solución es un sistema software. • ¿Qué características debe tener este sistema para satisfacer las necesidades de nuestro cliente?. • Esto es ingeniería de requisitos. Requisitos funcionales

CODIGO REQUERIMIENTOS FUNCIONALES

ReqF01: El sistema debe mantener la información de los usuarios

ReqF02: El sistema debe permitir registrar los créditos que poseen los usuarios y

puedan comprar a créditos y proporcionar las herramientas para que los

usuarios paguen

ReqF03: Los usuarios buscarán las canciones que deseen y las pagarán con

créditos

ReqF04: El sistema debe almacenar información sobre las canciones que se pueden

adquirir y su precio en créditos

ReqF05: El sistema debe permitir a los usuarios buscar y consultar la información

sobre las canciones.

ReqF06: El sistema debe permitir a un usuario adquirir una canción a cambio de

una cantidad de crédito

ReqF07: Los usuarios tendrán algunos días para descargar en su ordenador las

canciones que hayan adquirido.

ReqF08: El sistema debe almacenar las canciones adquiridas por un usuario y la

fecha, para saber durante cuánto tiempo puede descargar dichas

canciones.

ReqF09: El sistema debe permitir descargar las canciones que un usuario ha

adquirido mientras tenga tiempo. Requisitos no funcionales ¿Se les ocurren requisitos (algo que la aplicación deba tener) que no sea funcional?

CODIGO REQUERIMIENTOS NO FUNCIONALES ReqNF01

El sistema debe visualizarse y funcionar correctamente en cualquier navegador, especialmente en Internet Explorer, Mozilla y Nautilus.




ReqNF02

El sistema no debe tardar más de cinco segundos en mostrar los resultados de una búsqueda. Si se supera este plazo, el sistema detiene la búsqueda y muestra los resultados encontrados.

ReqNF03

Uso del sistema: El deseo general del usuario es la facilidad de uso de la

herramienta.

ReqNF04 Extensibilidad: Grado en que la implementación del sistema toma en

consideración y facilita su crecimiento en el futuro.

2.- Caso 01: Implementar un software para la gestión DE SERVICIO DE

FARMACIA UNIVERSITARIA de la unsch

Se desea realizar el análisis, diseño para poder informatizar todo el sistema de gestión de farmacias con el fin de dar un servicio a los farmacéuticos y estudiantes, más independiente, más eficaz y más sencillo. El sistema permite al farmacéutico de realizar todas las tareas diarias que se realizan en la farmacia, como la adquisición y venta de medicamentos o artículos en general, gestión de stock, de clientes (estudiantes) y proveedores, siendo éstas las tareas más frecuentes y demandadas en este sector. Dentro de la gestión de servicio de farmacia universitaria de la UNSCH, se lograron identificar algunos problemas: Las actividades llevadas a cabo son desarrolladas manualmente y en muchos de los casos

consumen recurso de tiempo en el llenado de datos en la “ficha de control económico de atenciones”, en el libro “kardex” de medicamentos e insumos, en la “solicitud de requerimientos” y en el libro de “registro de medicamentos”, y se demoran al realizar la búsqueda manual para comprobar si el estudiante puede solicitar medicamentos mediante la ficha de control económico de atenciones y en la facturación de los medicamentos que van a entregarse al estudiante, generando en todos los casos expuesto incomodidad y desconfianza del estudiante.

El control de estudiantes para el manejo de farmacia es ineficiente por lo que no se encuentran conectado a un trabajo en red y en muchos de los casos no se encuentran registrados.

El seguimiento de los estudiantes en cuanto a los medicamentos no es adecuado y hace falta de información automatizada, actualizada y detallada.

El control de medicamentos no es adecuado a las necesidades deseadas, debido a que el profesional desconoce los medicamentos disponibles o no.

Las recetas médicas generadas por el profesional de especialidad no están en coordinación con farmacia, debiendo a ello, generar otra receta médica, en caso de que no existe el medicamento requerido anteriormente por parte del médico del área de consultorio médico.

La adquisición de medicamentos para el servicio de Farmacia, toma mucho tiempo debido a que demora en la rotación de medicamentos.

La verificación de los datos del estudiante se realizan por medio de Documento Nacional de Identidad, haciendo un uso indispensable para la entrega oportuna de medicamentos.

El inadecuado control de stock y la no existencia de medicamentos, genera el desabastecimiento de medicamentos, permitiendo al estudiante no adquirir medicamentos de la misma farmacia.

EJERCICIO 01:




Identifique los requisitos Funcionales y no funcionales del sistema y a partir de los

requisitos funcionales encuentre los casos de uso del sistema.

CODIGO REQUERIMIENTOS FUNCIONALES CASOS DE USO

ReqF01 Autentificación Cualquier usuario ya registrado, puede autentificarse y salir del sistema cuando quiera.

CU01: Iniciar sesión

CU02:Salir Sistema

ReqF02 Gestión de Usuarios. Todos los usuarios deben

ser correctamente identificados en el sistema. Para

ello, el usuario proporciona al administrador su

nombre de usuario, contraseña y tipo de usuario

del que se trata (Químico Farmacéutico

responsable, Técnico o Administrador/a), tras lo

cual el sistema deberá validar estos datos.

CU03: Registrar Usuario

CU04:Mantener Usuario

CU05: Dar de baja Usuario

CU06:Dar de alta al usuario

CO07:generar reporte

usuario

ReqF03 El software debe ser capaz de mostrar catálogo de medicamentos según categorías.

CU08: listar catálogo de

Medicamentos

ReqF04 El software debe ser capaz de controlar las fechas de vencimiento del medicamento.

CU09:controlar fecha

vencimiento

ReqF05 El químico farmacéutico debe ser capaz de registrar la salida de medicamento.

ReqF06 El software debe ser capaz de actualizar el stock de medicamentos a partir de las entregas realizadas

ReqF07 El químico farmacéutico debe ser capaz de emitir ficha de control económico de atención.

ReqF08 El software debe ser capaz de facturar la entrega de medicamentos.

ReqF09 El software debe ser capaz de realizar consultas de los estudiantes que utilizaron el servicio por escuela y fecha.

ReqF010 El software debe ser capaz de validar la identificación del estudiante

ReqF011 COMPLETAR

ReqF013

ReqF014

ReqF015

ReqF016

ReqF017

ReqF018

ReqF019

ReqF020




REQUERIMIENTOS NO FUNCIONALES

CODIGO REQUERIMIENTOS FUNCIONALES ReqNF01 El software para Farmacia Universitaria debe ser una aplicación web y contar con

ayudas para recordar la clave de acceso.

ReqNF02 El software debe ser capaz de ejecutarse en cualquier sistema operativo garantizando

su portabilidad.

ReqNF03 El software debe presentar interfaces fáciles de usar.

ReqNF04 El software debe ser personalizable para garantizar el cumplimiento del rol de un

personal químico farmacéutico.

ReqNF05 El software debe presentar una arquitectura técnica y codificación usando estándares

de que permita su operación y mantenimiento adecuado.

1.1. Ejecutamos el Rational Rose y creamos un nuevo Proyecto: FileNewrational unified process

1.2. Asignamos a nuestro proyecto un nombre adecuado y lo guardamos en un lugar adecuado, como por ejemplo podría ser el disco D:\




1.3. Seleccionamos el modelo a utilizar en nuestro proyecto:

1.4. Verifique en el explorador del proyecto, tener la estructura siguiente, que muestra el modelo seleccionado para su proyecto:

1.5. Ubíquese dentro del paquete Use-Cases

Dentro del archivo Global View of Actors and Use Cases, Crear los siguientes paquetes de

caso de usos del sistema:




1. Crear los siguientes diagramas correspondiente a cada paquetes:

2. Seleccione en el explorador de Modelos el paquete Actores, seleccione el archivo main y

cambiar de nombre a Diagrama de Actores, agregar los siguientes actores del sistema

El sistema bajo consideración tiene tres tipos de actores: Administrador, farmacéutico y técnico

farmacéutico.

3. Para cambiar el nombre, clik derecho a main

y escoger el menú Rename

4. Seleccione el tipo adecuado de elemento y

asígnele su respectivo nombre:

Seleccione el elemento actor insertado y clic derechoOpen Specification…

5. Ahora, crear el diagrama Gestion Seguridad dentro del paquete Gestión

Administración, repetir los pasos anteriores:

Arrastre cada paquete




EJERCICIO02: Crear el diagrama Gestión de medicamentos y Gestión Compras

DESCRIPCION DE CASOS DE USO:




MATRIZ DE TRAZABILIDAD

CODIGO REQUERIMIENTOS FUNCIONALES CASOS DE USO

ReqF01 Autentificación Cualquier usuario ya registrado, puede autentificarse y salir del sistema cuando quiera.

CU01: Iniciar sesión

CU02:Salir Sistema

ReqF02 Gestión de Usuarios. Todos los usuarios deben

ser correctamente identificados en el sistema. Para

ello, el usuario proporciona al administrador su

nombre de usuario, contraseña y tipo de usuario

del que se trata (Químico Farmacéutico

responsable, Técnico o Administrador/a), tras lo

cual el sistema deberá validar estos datos.

CU03: Registrar Usuario

CU04:Mantener Usuario

CU05: Dar de baja Usuario

CU06:Dar de alta al usuario

CO07:generar reporte

usuario

ReqF03 El software debe ser capaz de mostrar catalogo de medicamentos según categorías.

CU08: listar catálogo de

Medicamentos

ReqF04 El software debe ser capaz de controlar las fechas de vencimiento del medicamento.

CU09:controlar fecha

vencimiento

ReqF05 El químico farmacéutico debe ser capaz de registrar la salida de medicamento.

ReqF06 El software debe ser capaz de actualizar el stock de medicamentos a partir de las entregas realizadas

ReqF07 El químico farmacéutico debe ser capaz de emitir ficha de control económico de atención.

ReqF08 El software debe ser capaz de facturar la entrega de medicamentos.

ReqF09 El software debe ser capaz de realizar consultas de los estudiantes que utilizaron el servicio por escuela y fecha.

ReqF010 El software debe ser capaz de validar la identificación del estudiante

ReqF011 COMPLETAR

ReqF013

ReqF014

ReqF015

ReqF016




ReqF017

ReqF018

ReqF019

ReqF020

Ejercicio 02: Identificar los requisitos funcionales y no funcionales del siguiente caso, listar los casos de uso por cada requisito funcional encontrado, crear el diagrama de caso de usos organizados por cada paquete encontrado y mostrarlos en el Rational Rose. El dueño de un negocio de alquiler de vehículos quiere desarrollar un sistema para consultar sobre los vehículos disponibles y así poder reservar dichos vehículos. Los vehículos pueden ser de tres tipos: Autos, camionetas, y limosinas, y dos tipos de clientes: clientes habituales, y esporádicos. Una reservación almacena datos del cliente, del vehículo reservado, la fecha de comienzo, y el número de días que estará ocupado el vehículo. La persona encargada de alquilar los vehículos puede realizar las siguientes operaciones: - Puede obtener un listado de los vehículos disponibles de acuerdo al tipo. - Preguntar por el precio de un vehículo de acuerdo a su tipo - Preguntar por descuentos a los clientes habituales - Preguntar por el precio total del cliente. Especificando su Nº de Ruc, tipo de vehículo, y cantidad de días alquilados. - Mostrar en la pantalla la foto del vehículo recuerdo a su tipo. - Reservar un vehículo especificando la placa del vehículo, ruc, y nombre de cliente., también puede eliminar una reserva especificando la placa de vehículo El administrador podrá usar el sistema para: - Cambiar el precio del alquiler del vehículo de acuerdo a su tipo, cambiar el descuento ofrecido a los clientes habituales, calcular las ganancias que tendrá en un mes específico. - El sistema debe permitir agregar nuevos tipos de vehículos o clientes.

requerimientos y modelo de casos de uso - v3

Documents