Embed Size (px)
Citation preview
INGENIERÍA DE SOFTWARE
Ing. Richard Barrios Quispe. 3 ciclo “B”
1
INGENIERÍA DE SOFTWARE
EXPOSICIÓN DIAGRAMA DE CASOS DE USO III CICLO
Ing. Richard Barrios Quispe. 3 ciclo “B”
2
INGENIERÍA de software
FORMADOR: Ing. RICHARD BARRIOS
QUISPE
ALUMNOS:
o PALOMINO YUCRA YENNY
o JOSÉ MARTÍNEZ MAGALLANES
o LINO GARCIA FABRY
INGENIERÍA DE SOFTWARE
Ing. Richard Barrios Quispe. 3 ciclo “B”
3
En primer lugar dedicado a Dios,
En segundo lugar al esfuerzo de nuestros padres.
En tercer lugar al esfuerzo de nuestros profesores por su labor abnegada.
En cuarto lugar a todos los integrantes y amigos del tercer ciclo “B”.
INGENIERÍA DE SOFTWARE
ÍNDICE
1.- INTRODUCCIÓN
2.- OBJETIVO
3.- HISTORIA
4.- CONCEPTO
5.- CLASIFICACION DE LOS CASO DE USO
1. ALTO NIVEL2. EXPANDIDOS
6.- CARACTERISTICA GENERALES DE CASOS DE USO
7.- BENEFICIOS DE UN DIAGRAMA DE CASOS DE USO
8.- PROPIEDADES DE LOS CASOS DE USO
9.- VENTAJAS DEL DIAGRAMA CASOS DE USO
10.- ELEMENTOS DEL DIAGRAMA DE CASO DE USO
1. ACTORES
TIPOS DE ACTORES RELACIONES ENTRE ACTORES:
2. CASOS DE USO
RELACIONES ENTRE CASOS DE USO:i) DEPENDENCIAii) ASOCIACIÓNiii) GENERALIZACIÓN
11.- PASOS PARA ELABORAR UN CASO DE USO
SISTEMA DE GESTIÓN COMERCIAL
BUSCANDO CASOS DE USO:
12.- EJERCICIO
13.- CONCLUSIÓN.
Ing. Richard Barrios Quispe. 3 ciclo “B”
4
INGENIERÍA DE SOFTWARE
INTRODUCCIÓN
Durante mucho tiempo en todos los desarrollos O.O las personas usaban los escenarios para ayudarse a entender los requerimientos. Sin embargo los escenarios eran tratados muy informalmente.
Jacobson es conocido por cambiar esto. Mejoro la visibilidad del caso de uso, guiado de los conceptos de Mc. Menanin.
OBJETIVO
Saber cómo interactúan los diagramas de caso de uso con los actores y de esta forma saber cómo se va desarrollando el sistema.
Saber cómo utilizar los casos de uso teniendo en cuenta todos los requisitos.
Ing. Richard Barrios Quispe. 3 ciclo “B”
5
INGENIERÍA DE SOFTWARE
DIAGRAMA DE CASOS DE USO
HISTORIA
Los Casos de Uso fueron introducidos por Jacobson en 1992. Sin embargo, la idea de especificar un sistema a partir de su interacción con el entorno es original de Mc Menamin y Palmer, dos precursores del análisis estructurado, que escribieron en 1984 un excelente libro.En ese libro, se define un concepto muy parecido al del caso de uso: el evento. Para Mc Menamin y Palmer, un evento es algo que ocurre fuera de los límites del sistema, ante lo cual el sistema debe responder. Sin embargo, existen algunas diferencias entre los casos de uso y los eventos. Las principales son:
1) Los eventos se centran en describir qué hace el sistema cuando el evento ocurre, mientras que los casos de uso se centran en describir cómo es el diálogo entre el usuario y el sistema.2) Los eventos son “atómicos”: se recibe una entrada, se la procesa, y se genera una salida, mientras que los casos de uso se prolongan a lo largo del tiempo mientras dure la interacción del usuario con el sistema.De esta forma, un caso de uso puede agrupar a varios eventos.3) Para los eventos, lo importante es qué datos ingresan al sistema o salen de él cuando ocurre el evento (estos datos se llaman datos esenciales), mientras que para los casos de uso la importancia del detalle sobre la información que se intercambia es secundaria. Según esta técnica.
Los casos de uso combinan el concepto de evento del análisis estructurado con otra técnica de especificación de requerimientos bastante poco difundida: aquella que dice que una buena forma de expresar los requerimientos de un sistema es escribir su manual de usuario antes de construirlo. Esta técnica, si bien ganó pocos adeptos, se basa en un concepto muy interesante: al definir requerimientos, es importante describir al sistema desde el punto de vista de aquél que lo va a usar, y no desde el punto de vista del que lo va a construir. De esta forma, es más fácil validar que los requerimientos documentados son los verdaderos requerimientos de los usuarios, ya que éstos comprenderán fácilmente la forma en la que están expresados.
CONCEPTO
Ing. Richard Barrios Quispe. 3 ciclo “B”
6
INGENIERÍA DE SOFTWARE
Un caso de uso es una secuencia de acciones que ejecuta el actor dentro de un sistema para lograr un objetivo particular.
Se puede decir que los casos de uso no son parte del diseño, sino parte del análisis. De forma que al ser parte del análisis nos ayuda a describir que es lo que el sistema debe de hacer o hace.
Los casos de uso se elaboran del punto de vista del usuario es decir, describen el uso del sistema y como este interactúa con el usuario
Un caso de uso es iniciado por un agente externo (es decir siempre debe estar asociado a un actor), debido a esto un diagrama de este tipo generalmente es de lo más sencillo de interpretar en UML.
Un diagrama de caso de uso debe de ser Clara, Concreta y Precisa.
CLASIFICACION DE LOS CASO DE USO
3. ALTO NIVEL: Describen el proceso en dos o tres oraciones.Ayudan a comprender rápidamente:
a. La complejidad del sistema.b. La funcionalidad del sistema.
Ejemplo:
4. EXPANDIDOS:Pueden contener cientos de oraciones describiendo en detalle un proceso.
Nota:
Crear los casos de uso de alto nivel durante la fase de plan y elaboración. Escribir los más importantes y crítico de esos casos de uso, en formato
expandido. Se usa para conseguir una mejor comprensión de los procesos y requerimientos.
Ing. Richard Barrios Quispe. 3 ciclo “B”
7
Caso de uso: compra de ítems.
Actores: el cliente y el cajero.
Tipo de actores: primarios.
Descripción:
Un cliente llega a la caja con ítems a comprar.
El cajero registra los ítems comprados por el cliente y recibe el pago.
Al finalizar el cliente se retira con los ítems comprados
INGENIERÍA DE SOFTWARE
CARACTERISTICA GENERALES DE CASOS DE USO
Por muchos años, los analistas han usado escenarios o historias que describen maneras en que un usuario va a interactuar con u sistema.
Se los utiliza para la obtención y modelamiento de requerimientos. En UML, un diagrama de casos de uso muestra la relación entre 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. Pueden ser utilizados en proyectos que sigan cualquier metodología de
desarrollo.
BENEFICIOS DE UN DIAGRAMA DE CASOS DE USO
Da una descripción clara y consistente de lo que el sistema debe de hacer. Sirve como elemento para la estimación. Captura los requerimientos funcionales de la perspectiva del usuario.
PROPIEDADES DE LOS CASOS DE USO
Son iniciados por un actor con un objetivo en mente y es completado con éxito cuando el sistema lo satisface.
Pueden incluir secuencias alternativas que llevan al éxito y fracaso en la consecución del objetivo.
El conjunto completo de casos de uso especifica todas las posibles formas de usar el sistema (comportamiento requerido).
VENTAJAS DEL DIAGRAMA CASOS DE USO
La comprensión detallada de la funcionalidad del sistema. La comunicación entre usuarios y desarrolladores. Mayor control para mantener las sucesivas previsiones de los programas.
ELEMENTOS DEL DIAGRAMA DE CASO DE USO
Los elementos que pueden aparecer en un diagrama de casos de uso son:
1. ACTORES:
Ing. Richard Barrios Quispe. 3 ciclo “B”
8
INGENIERÍA DE SOFTWARE
a. Un actor es una entidad externa al sistema que realiza algún tipo de interacción con el mismo.
b. Un actor representa un rol que es desempeñado con respecto al sistema (es importante destacar el uso de la palabra “ROL”, ya que esto especifica que un actor no necesariamente representa a una persona en particular, si no la labor que realiza frente al sistema.
c. No forman parte del sistema.d. Un actor puede intervenir en varios casos de uso.e. Un actor necesita el caso de uso y/o participa en el.f. En la elaboración de un caso de uso pueden intervenir diferentes actores.g. Se representa mediante una figura humana.
ACTOR
TIPOS DE ACTORES:i) ACTORES PRINCIPALES: Son las personas que utilizan las funciones
principales del sistema.ii) ACTORES SECUNDARIOS: Personas que efectúan tareas administrativas o
de mantenimiento.iii) MATERIALES EXTERNOS: son los materiales imprescindibles que
forman parte de la aplicación y que deben de ser utilizados.
RELACIONES ENTRE ACTORES:i) Cuando varios actores desempeñan un rol general común puede ser descrito
como generalización.ii) Las relaciones entre actores no siempre son necesarias.iii) Los actores heredan el comportamiento y lo extiende de una manera.
2) CASOS DE USO: Es una terea que de poder llevarse a cabo con el apoyo del sistema que se está
desarrollando.
Ing. Richard Barrios Quispe. 3 ciclo “B”
9
INGENIERÍA DE SOFTWARE
Un caso de uso es una secuencia de transacciones en un sistema cuyo resultado proporciona un valor mesurable a un actor individual del sistema.
Es el conjunto de escenarios relacionados entre sí por un objetivo común del usuario.
Se representa mediante un elipse. Siempre es iniciado por un actor. Proporciona un resultado útil a un actor. El caso de uso es completo (no se debe dividir un caso de uso en otros más
pequeños). Para capturar el comportamiento deseado del sistema. Como medio de comprensión del sistema para desarrolladores, usuarios finales y
expertos del dominio.
3) RELACIONES ENTRE CASOS DE USO: DEPENDENCIA:
i) <<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.
Las flecha en el caso de uso extend va hacia el caso de uso original.
Ejemplo de relación extend:
ii) <<include>>
Ing. Richard Barrios Quispe. 3 ciclo “B”
10
<<extend>>
INGENIERÍA DE SOFTWARE
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.
<<include>>
Ejemplo de relación include:
ASOCIACIÓN:i) Es la relación entre un actor y un caso de uso. Hay una asociación entre un
actor y un caso de uso cuando el actor interactúa con el sistema para llevar a cabo un caso de uso.
Asociación
Ejemplo de relación Asociación:
Ing. Richard Barrios Quispe. 3 ciclo “B”
11
ACTOR HIJO
INGENIERÍA DE SOFTWARE
GENERALIZACIÓN (relaciones de herencia):i) El caso de uso origen hereda la especificación del caso uso destino o
posiblemente lo modifica y/o amplia.ii) Esta relación solo se puede dar entre dos objetos del mismo tipo que puede
ser entre actores o clases y casos de uso.iii) Una relación de generalización entre casos de uso implica que el caso de
uso hijo hereda todos los atributos, secuencias de comportamiento, puntos de extensión y relaciones definidos en el caso de uso padre.Donde el hijo puede ser suplido por el padre en cualquier momento.
Ejemplo de generalización:
Generalización
Ing. Richard Barrios Quispe. 3 ciclo “B”
12
ACTOR PADRE
INGENIERÍA DE SOFTWARE
PASOS PARA ELABORAR UN CASO DE USO
Identificar los usuarios del sistema.
encontrar todos los roles que juegan los usuarios y que son relevantes al sistema.
Para cada rol identificar todas las formas (objetivos) de interactuar con el
sistema.
Crear un caso de uso por cada objetivo.
estructurar los casos de uso.
revisar y validar con el usuario.
Asegurarse que cada caso de uso describe una parte significativa del
funcionamiento del sistema.
Evitar un número excesivo de casos de uso.
Un caso de uso no es un paso, operación o actividad individual en un proceso.
Un caso de uso describe un proceso completo que incluye varios pasos (flujo de
trabajo de la empresa)
Los casos de uso deben ser simples, dado que podrían cambiar con facilidad
Los casos de uso tienen que ser entendibles tanto por desarrolladores software
como por expertos del dominio.
Es una descripción de alto nivel del sistema
Evitar conceptos de diseño.
Ing. Richard Barrios Quispe. 3 ciclo “B”
13
Cliente
Usuario
Proveedor
Cajero
Gerente
Administrador
INGENIERÍA DE SOFTWARE
Ejemplo:
SISTEMA DE GESTIÓN COMERCIAL
Autoservicios las palmas
BUSCANDO ACTORES:
Ing. Richard Barrios Quispe. 3 ciclo “B”
14
El usuario será el encargado de loguearse al sistema.
Representante de la empresa. Encargado de coordinar el negocio con ayuda del administrador.
Encargado de llevar el control de la empresa supervisando los procesos de dicho negocio.
Encargado de la atención al público y de la venta de los repuestos para los automóviles.
Encargado de proveer productos a la empresa.
Solicita los productos que requiere.
Se registra o modifica.
INGENIERÍA DE SOFTWARE
BUSCANDO CASOS DE USO:
NÚMERO CASOS DE USO DESCRIPCIÓN
CU-01Login
Este caso de uso permite el ingreso al sistema y dependiendo del tipo de usuario contará con diferentes accesos y privilegios.
CU-02Gestionar cliente
Este caso de uso permitirá registrar un nuevo cliente como Modificar los datos de un cliente registrado.
CU-03Gestionar usuario
Este caso de uso permitirá Registrar a un nuevo empleado de la empresa o modificar los datos de un empleado existente.
CU-04Gestionar producto
Este caso de uso permitirá Registrar un nuevo producto como modificar los datos de un producto existente.
CU-05Gestionar ventas
Este caso de uso permitirá Registrar la venta de uno o más productos o eliminar la venta realizada.
CU-06Generar reporte del cliente
Este caso de uso permite a los Usuario Generar Reporte de Clientes.
Ing. Richard Barrios Quispe. 3 ciclo “B”
15
Sistema de contabilidad
Gerente de ventas
Gerente de compras
Empleado Vendedor
Cliente
INGENIERÍA DE SOFTWARE
EJERCICIO:
Farmacom, un laboratorio farmacéutico que provee de fármacos a gran cantidad de bodegas de la ciudad de un sistema integrado que controle las compras y ventas.
El gerente de compras se encarga de registrar nuevos productos al sistema y aprobar las órdenes de compra para los proveedores. Así mismo requiere de un reporte de cuenta por pagar.
El gerente de ventas debe fijar el precio de ventas de los productos y requiere de un reporte de ventas.
Los vendedores ingresan los pedidos y emiten comprobante a los clientes.
Ambos módulos deben comunicarse con el sistema contable.
Ing. Richard Barrios Quispe. 3 ciclo “B”
16
Emitir comprobante
Registrar productos
Registrar precio de ventas
Generar reporte de compras
Gestionar venta
Registrar cancelación
Actualizar sistema de contabilidad
Generar reporte de venta
Gestionar orden de compra
INGENIERÍA DE SOFTWARE
CONCLUSION
Podemos deducir que los diagramas de casos de uso son importantes porque nos permite describir el funcionamiento del sistema y como interactúan los actores con los casos de uso.
Tener conocimientos de los tipos de relaciones y como se relacionan los actores con los casos de uso o casos de uso con casos de uso o actores con actores.
Por último tener conocimiento de cómo poder diagramar un sistema para que sea más fácil de comprender su función y desarrollo.
Ing. Richard Barrios Quispe. 3 ciclo “B”
17
INGENIERÍA DE SOFTWARE
Ing. Richard Barrios Quispe. 3 ciclo “B”
18
