Modelado de <br />Análisis Orientado a Objetos <br />
<ul><li>REQUERIMIENTOS
TIPOS  DE REQUERMIENTOS
	DE USUARIO
	DEL SISTEMA
		FUNCIONALES
		NO FUNCIONALES
DIAGRAMA DE CASOS DE USO
INTRODUCCIÓN
ELEMENTOS BÁSICOS
ACTORES
CASOS DEUSO
GENERALIZACION, RELACIONES DE ASOCIACIÓN
LIMITES Y MODELO DE CONTEXTO
MODELAR LAS NECESIDADES DEL SISTEMA</li></li></ul><li>El éxito de un proyecto es el valor final del resultado para el nego...
Requerimientos del Software<br />Son una descripción de las necesidades a las que debe responder el producto a desarrollar...
Requerimientos por Niveles<br />Requerimientos de usuario (de alto nivel): Son declaraciones, en lenguaje natural y en dia...
Requerimientos del sistema: Establecen con detalle las funciones, servicios y restricciones operativas del sistema. Debe d...
Requerimientos funcionales:  Son declaraciones de los servicios que debe proporcionar el sistema, de tal manera que éste d...
Requerimientos no funcionales: Son restricciones de los servicios  o funciones ofrecidos por el sistema. Incluyen restricc...
DIAGRAMA DE CASOS DE USOINTRODUCCIÓN<br />Permite  modelar el comportamiento de un sistema  desde el punto de vista del us...
Elementos Básicos: Actor<br />	Representa un conjunto coherente de roles que desempeñan los usuarios al interaccionar con ...
IDENTIFICACION DE ACTORES<br />Las siguientes preguntas pueden ayudar a identificar a los actores de un sistema:<br />¿Qui...
Actores<br />Por lo general los actores son identificados durante la declaración del problema y<br />Durante las entrevist...
CASOS DE USO<br />Especifica un requerimiento funcional del sistema. <br />Un caso de uso es un documento que narra la sec...
Notación gráfica <br />Se representan con un óvalo, el nombre debe estar expresado con un verbo, seguido por el principal ...
CARACTERISTICAS DE LOS CASOS DE USO<br />Los casos de uso tienen las siguientes características:<br />Están expresados des...
Ejm.<br />ID: CU2<br />Nombre:  Realizar Retiro<br />Actores: Cliente<br />Tipo: Primario<br />-   Descripción Breve: Un C...
Encontrar los casos de uso<br />Lluvia de ideas<br />Revisión  de documentos de requerimientos<br />Basado en los actores<...
PREGUNTAS PARA ENCONTRAR CASOS DE USO<br /> ¿Cuales son las tareas que realiza cada actor?<br />¿Cualquier actor creará, g...
Casos de Uso y Escenarios<br />Un caso de uso describe un conjunto de  secuencias de interacciones o escenarios(INSTACIA D...
Ejemplo<br />En un sistema de Recursos Humanos podría aparecer el caso de uso  Contratar Empleado, esta función podría ten...
Descripción de un caso de uso<br />Se lo hace de acuerdo a una plantilla y además<br />Describe el flujo de eventos: que e...
Vista de Casos de Usos <br />Los sustantivos en el caso de uso<br />Ayudan a definir clases del sistemas y atributos, adem...
<ul><li>ALQUILER
COMPROBAR
EMITIR
ASIGNAR
GESTIONAR
REGISTRAR
COMPRAR
HACER
ADMINISTRAR
ACTUALIZAR
SELECCIONAR</li></ul>VERBOS QUE PUEDEN APLICARSE A LOS CASOS DE USO<br /> REALIZAR<br />CAMBIAR<br />TRANSFERIR<br />SOLIC...
Notación y ejemplo de Casos de Uso<br />actor<br />caso de uso<br />Procesar Préstamo<br />ResponsablePrestamos<br />Nombr...
Tipos de casos de uso<br />Según el nivel de detalle<br />De alto nivel: Describe un proceso muy brevemente y permite ente...
Según la importancia<br />Primarios: Representan los procesos comunes más importantes.<br />Secundarios: Representan proce...
Ejemplos de  casos de uso<br />CASO PRIMARIO DE USO: Comprar productos.<br />CASO SECUNDARIOS DE USO:  Solicitar increment...
Organización de un Caso de Uso<br />Pueden agruparse en paquetes.<br />También pueden organizarse especificando relaciones...
Relación de inclusión <<include>><br />La relación de inclusión se usa para evitar describir el mismo flujo de eventos rep...
Asociación <<includes>><br />El caso de uso Base incluye en alguno de sus flujos el caso de uso Incluido<br />El caso de u...
Relación de extensión<br />Se utiliza una relación de tipo <<extend>> entre casos de uso cuando nos encontramos con un cas...
Próxima SlideShare
Cargando en…5
×

UNIDAD V - MODELADO DE ANALISIS ORIENTADO A OBJETOS

6.154 visualizaciones

Publicado el

Diapositiva de la quinta Unidad MODELADO DE ANALISIS ORIENTADO A OBJETOS

1 comentario
1 recomendación
Estadísticas
Notas
Sin descargas
Visualizaciones
Visualizaciones totales
6.154
En SlideShare
0
De insertados
0
Número de insertados
644
Acciones
Compartido
0
Descargas
281
Comentarios
1
Recomendaciones
1
Insertados 0
No insertados

No hay notas en la diapositiva.

UNIDAD V - MODELADO DE ANALISIS ORIENTADO A OBJETOS

  1. 1. Modelado de <br />Análisis Orientado a Objetos <br />
  2. 2. <ul><li>REQUERIMIENTOS
  3. 3. TIPOS DE REQUERMIENTOS
  4. 4. DE USUARIO
  5. 5. DEL SISTEMA
  6. 6. FUNCIONALES
  7. 7. NO FUNCIONALES
  8. 8. DIAGRAMA DE CASOS DE USO
  9. 9. INTRODUCCIÓN
  10. 10. ELEMENTOS BÁSICOS
  11. 11. ACTORES
  12. 12. CASOS DEUSO
  13. 13. GENERALIZACION, RELACIONES DE ASOCIACIÓN
  14. 14. LIMITES Y MODELO DE CONTEXTO
  15. 15. MODELAR LAS NECESIDADES DEL SISTEMA</li></li></ul><li>El éxito de un proyecto es el valor final del resultado para el negocio.<br />Una deficiente identificación de requisitos, la falta de objetivos claros y la inexistencia de análisis de usuario, son causas frecuentes del fracaso.<br />
  16. 16. Requerimientos del Software<br />Son una descripción de las necesidades a las que debe responder el producto a desarrollar.<br />
  17. 17. Requerimientos por Niveles<br />Requerimientos de usuario (de alto nivel): Son declaraciones, en lenguaje natural y en diagramas de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.<br />Ejm. El sistema controlará los datos requeridos por las agencias que licencian los derechos de autor en Europa y en otra parte.<br />
  18. 18. Requerimientos del sistema: Establecen con detalle las funciones, servicios y restricciones operativas del sistema. Debe definir exactamente que es lo que se va a implementar.<br />Ejm. Al hacer una petición de un documento del sistema se presentará un formulario que registre los detalles de usuario y de la petición hecha.<br />
  19. 19. Requerimientos funcionales: Son declaraciones de los servicios que debe proporcionar el sistema, de tal manera que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. Ejm:<br />El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella.<br />El sistema deberá proporcionar visores adecuados para que el usuario lea documentos en el almacén de documentos.<br />
  20. 20. Requerimientos no funcionales: Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares . Se aplican al sistema en su totalidad.<br />
  21. 21. DIAGRAMA DE CASOS DE USOINTRODUCCIÓN<br />Permite modelar el comportamiento de un sistema desde el punto de vista del usuario.<br />• Determinan los requisitos funcionales del sistema<br /> – representan las funciones que un sistema puede ejecutar<br />• Facilidad de interpretación<br /> – comunicación entre el ADS y el USR<br />• Importante:<br /> – Reflejan lo esencial del sistema<br />• Se pueden usar durante:<br /> – Captura de Requisitos<br /> – Especificación Funcional del Sistema<br /> – Planificación de iteraciones de desarrollo<br /> – Validación del sistema<br />
  22. 22. Elementos Básicos: Actor<br /> Representa un conjunto coherente de roles que desempeñan los usuarios al interaccionar con el sistema.<br />Pueden ser:<br /> personas, dispositivo u otros sistemas<br />Iniciador: inicia un caso de uso<br />Participante: involucrado en el caso de uso, pero no lo inicia<br />Aunque se utilizan actores en los modelos, estos no forman parte del sistema. Son externos a él.<br />
  23. 23. IDENTIFICACION DE ACTORES<br />Las siguientes preguntas pueden ayudar a identificar a los actores de un sistema:<br />¿Quién o quienes están interesados en utilizar determinada funcionalidad?<br />¿Dónde será usado el sistema dentro de la organización?<br />¿Quién o quienes se beneficiarán con el uso del sistema?<br />¿Quién proporcionará, utilizará y eliminará información del sistema?<br />¿Quién brindará soporte y mantenimiento al sistema?<br />¿Usa el sistema recursos externos?<br />¿Cumple una persona varios roles diferentes dentro del sistema?<br />¿Cumple varias personas un mismo rol?<br />¿Actúa el sistema recíprocamente con algún sistema de índole legal o gubernamental?<br />
  24. 24. Actores<br />Por lo general los actores son identificados durante la declaración del problema y<br />Durante las entrevistas con los clientes.<br />El nombre del actor describe el papel desempeñado, no la persona física<br />• Actores como clases:<br />– Cuando se necesite almacenar información sobre el actor<br />– Cuando se interactúe con un sistema externo<br />actor<br />Cliente<br />generalización<br />Cliente<br />Corporativos<br />Cliente<br />Individuales<br />
  25. 25. CASOS DE USO<br />Especifica un requerimiento funcional del sistema. <br />Un caso de uso es un documento que narra la secuencia de acciones necesarias para que un actor (agente externo) complete un proceso por medio de la utilización de un sistema. <br />Especifica una secuencia de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un actor particular.<br />
  26. 26. Notación gráfica <br />Se representan con un óvalo, el nombre debe estar expresado con un verbo, seguido por el principal objeto del sistema que es afectado por el caso. El nombre siempre debe estar expresado desde el punto de vista del actor y no del sistema<br />
  27. 27. CARACTERISTICAS DE LOS CASOS DE USO<br />Los casos de uso tienen las siguientes características:<br />Están expresados desde el punto de vista del actor. <br />Se documentan con texto informal. <br />Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él, aunque el énfasis está puesto en la interacción. <br />Son iniciados por un único actor. <br />Un caso de uso describe qué hace un sistema , pero no como lo hace.<br /><ul><li>Los casos de uso pueden tener relaciones con otros casos de uso.</li></li></ul><li>Ejm.<br />ID: CU 1.0.Nombre: Comprar Ticket.Actor: Usuario del Metro.Descripción breve: El usuario del metro compra un boleto del sistema luego del pago de la cantidad apropiada.<br />
  28. 28. Ejm.<br />ID: CU2<br />Nombre: Realizar Retiro<br />Actores: Cliente<br />Tipo: Primario<br />- Descripción Breve: Un Cliente llega al cajero automático, introduce la tarjeta, se identifica y solicita realizar una operación de retiro por una cantidad específica. El cajero le da el dinero solicitado tras comprobar que la operación puede realizarse. El cliente coge el dinero y la tarjeta y se va.<br />
  29. 29. Encontrar los casos de uso<br />Lluvia de ideas<br />Revisión de documentos de requerimientos<br />Basado en los actores<br />Se identifican los actores relacionados con un sistema o empresa.<br />En cada actor, se identifican los procesos que inician o en que participan<br />Basado en eventos<br />Se identifican los eventos externos a los que un sistema ha de responder<br />Se relacionan los eventos con los actores.<br />
  30. 30. PREGUNTAS PARA ENCONTRAR CASOS DE USO<br /> ¿Cuales son las tareas que realiza cada actor?<br />¿Cualquier actor creará, guardará, modificará, eliminará, o leerá la información en el sistema?<br />¿Qué casos de uso crearán, guardarán, modificarán, eliminarán o leerán esta información?<br />¿Cualquier actor informará los cambios súbitos externos que sufra el sistema?<br />¿Qué casos de uso brindarán soporte y mantenimiento al sistema?<br />¿Todos los requisitos funcionales pueden ser realizados por los casos de uso?<br /> <br />
  31. 31. Casos de Uso y Escenarios<br />Un caso de uso describe un conjunto de secuencias de interacciones o escenarios(INSTACIA DE CASOS DE USO): flujo principal y flujosalternativos o excepcionales<br />Un escenario es una secuencia específica de acciones que ilustra un comportamiento<br />
  32. 32. Ejemplo<br />En un sistema de Recursos Humanos podría aparecer el caso de uso Contratar Empleado, esta función podría tener muchas variantes. Podría contratarse a una persona de otra empresa (el escenario más frecuente): podría transferirse una persona de un departamento a otro(algo muy frecuente en algunas compañías) o podría contratarse a un extranjero (lo que conlleva sus reglas específicas). <br />¿Existen varios escenarios si ó no?<br />
  33. 33. Descripción de un caso de uso<br />Se lo hace de acuerdo a una plantilla y además<br />Describe el flujo de eventos: que es lo que el sistema debe hacer: Debe contener<br />Cómo y cuando inicia un caso de uso<br />Cómo y cuando termina un caso de uso<br />Qué interacciones tiene el caso de uso con los actores<br />Qué datos necesita el caso de uso<br />La secuencia normal de eventos para el caso de uso<br />La descripción de cualquier alternante o flujos excepcionales<br />Debería en cualquier momento responder a ¿Qué pasa si …?<br />Debe ser legible y comprensible para un usuario no experto.<br />
  34. 34. Vista de Casos de Usos <br />Los sustantivos en el caso de uso<br />Ayudan a definir clases del sistemas y atributos, además atributos de clase. •<br />Los verbos en el caso de uso<br />Ayudan a determinar métodos de clase<br />Las preposiciones en los casos de uso<br />Ayudan a determinar relaciones entre clases<br />El conjunto de todos los casos de uso:<br />Ayudan a verificar el diseño, implementación del sistema. El sistema comprende los requerimientos del usuario? <br />Provee un excelente medio de intercambio entre usuarios y personal técnico<br />
  35. 35. <ul><li>ALQUILER
  36. 36. COMPROBAR
  37. 37. EMITIR
  38. 38. ASIGNAR
  39. 39. GESTIONAR
  40. 40. REGISTRAR
  41. 41. COMPRAR
  42. 42. HACER
  43. 43. ADMINISTRAR
  44. 44. ACTUALIZAR
  45. 45. SELECCIONAR</li></ul>VERBOS QUE PUEDEN APLICARSE A LOS CASOS DE USO<br /> REALIZAR<br />CAMBIAR<br />TRANSFERIR<br />SOLICITAR<br />GENEREAR<br />PROCESAR<br />MANTENER<br />SELECCIONAR<br />AÑADIR<br />IMPRIMIR<br />MODIFICAR<br />ELIMINAR<br />CREAR<br />
  46. 46. Notación y ejemplo de Casos de Uso<br />actor<br />caso de uso<br />Procesar Préstamo<br />ResponsablePrestamos<br />Nombre<br />asociación<br />
  47. 47. Tipos de casos de uso<br />Según el nivel de detalle<br />De alto nivel: Describe un proceso muy brevemente y permite entender los principales procesos globales<br />Expandido : Descripción detallada, la diferencia básica con el caso de uso de alto nivel consiste en que tiene una sección destinada al curso o flujo normal de eventos, que los describe paso por paso.<br />
  48. 48. Según la importancia<br />Primarios: Representan los procesos comunes más importantes.<br />Secundarios: Representan procesos menores o raros.<br />Opcionales: representan procesos que pueden no abordarse.<br />Según el nivel de abstracción<br />Esencial : ¿Qué hace el sistema? <br />Concreto/ Real : Se contemplan detalles de implementación (GUI y tecnología) <br /> Esencial Real<br /> Muy abstracto muy concreto<br />
  49. 49. Ejemplos de casos de uso<br />CASO PRIMARIO DE USO: Comprar productos.<br />CASO SECUNDARIOS DE USO: Solicitar incrementar un nuevo producto.<br />CASOS ESENCIALES DE USO:Uncaso de Retiro en efectivo de un cajero automático, que se expresa en una forma relativamente esencial.<br />ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA<br />1. El cliente se identifica 2. Presenta las opciones<br />3. El cliente selecciona la opción 3.y así sucesivamente<br />CASOS REALES DE USO.<br />Describe concretamente el proceso a partir de su diseño concreto actual, sujeto a las tecnologías específicas de entrada y de salida, para el ejm. Anterior.<br />ACCION DE LOS ACTORES RESPUESTA DEL SISTEMA<br />1. El cliente introduce su tarjeta 2.Pide el número de identificación <br /> Personal (clave)<br />3. Introduce la clave en una pantalla táctil. 4. Muestra el menú de opciones<br /> Y así sucesivamente.<br />Nota:Si existe algunas excepciones en los cursos normales de eventos, se deberá escribir en una sección de alternativas, es decir como cursos alternativos.. Ejm. En el caso de Realizar transacción podría ser un curso alterno. – Se introduce clave inválido. Indique el error. –El cliente no pudo pagar. Cancele la transacción.<br />
  50. 50. Organización de un Caso de Uso<br />Pueden agruparse en paquetes.<br />También pueden organizarse especificando relaciones de generalización, inclusión y extensión entre ellos<br />
  51. 51. Relación de inclusión <<include>><br />La relación de inclusión se usa para evitar describir el mismo flujo de eventos repetidas veces, poniendo el comportamiento común en un caso de uso aparte (que será incluido por un caso de uso base). La relación de inclusión es básicamente un ejemplo de delegación.<br />Ejemplo caso de uso “Hacer Pedido”:<br /> “Obtener y verificar el número de pedido. Include(Validar usuario). Examinar el estado de cada parte del pedido y preparar un informe para el usuario”.<br />Hacer pedido<br /><<Include>><br />Validar cliente<br />
  52. 52. Asociación <<includes>><br />El caso de uso Base incluye en alguno de sus flujos el caso de uso Incluido<br />El caso de uso incluido es un “fragmento” de flujo que no tiene sentido por si mismo<br />Se incluye en múltiples sitios<br />Es abstracto<br />Base necesita del incluido (en algún flujo)<br /><<includes>><br />Base<br />Incluido<br />
  53. 53. Relación de extensión<br />Se utiliza una relación de tipo <<extend>> entre casos de uso cuando nos encontramos con un caso de uso similar a otro pero que hace algo más que éste (variante).<br />Sirve para modelar <br />la parte opcional del sistema <br /> un subflujo que sólo se ejecuta bajo ciertas condiciones<br />varios flujos que se pueden insertar en un punto<br />Ejemplo caso de uso “Hacer Pedido”:<br /> “ extend” (Hacer Pedido Urgente).<br />Indica que un caso de uso soporta un comportamiento adicional al comportamiento base.<br />Hacer pedido<br />Hacer pedido <br />urgente<br /><<extend>><br />Base<br />Extendido<br />
  54. 54.
  55. 55. Diagrama De Casos De Uso<br />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<br /> Los diagramas se emplean para visualizar el comportamiento de un sistema de forma que los usuarios puedan comprender como utilizar ese elemento y de forma que los desarrolladores puedan implementarlo.<br />Un diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso). <br />
  56. 56. Elementos del diagrama de casos de uso<br />Actor <br />Casos de Uso <br />Relaciones de dependencia (include y extend), Herencia y Comunicación<br />En general utilizaremos <<extends>> cuando se presenta una variación del comportamiento normal, e <<include>> cuando se repite un comportamiento en dos casos de uso y queremos evitar dicha repetición.<br />
  57. 57. 36<br />Comprar Articulos<br />Cajero<br />Cliente<br />
  58. 58. CASO DE ESTUDIO<br />En el almacén “Don Diego” los clientes al comprarproductoscadadía se les dificultamásyaque al acercarse a pagar en un terminal de punto de venta, el cajeroregistra los productos, entrega el cambio y la factura de maneralenta y deficiente , estoestáafectando mucho porque los ingresos van bajando y el gerente no sabenrealmentecuales son lasgananciasmensuales.<br /> El gerenteesencargado de activar un TPDV parainiciarsusactividades, controlando la fecha y hora y asímismofinaliza la sesión de trabajo.<br />
  59. 59. DEFINICION DEL PROBLEMA<br />
  60. 60. Requisitos<br />a)Objetivo<br /> Este proyectotieneporobjetocrear un sistema de terminal para<br /> el punto de ventaque se utilizará en lasventas de un almacén.<br />b)Metas<br /> La meta esunagranautomatización del pago en lascajasregistradoras, y darsoporte a serviciosmásrápidos, másbaratos y mejores.<br />Concretamente, la meta incluye:<br /> · Pago rápido de los clientes.<br /> · Análisisrápido y exacto de lasventas.<br /> · Control automático del inventario.<br />
  61. 61. Requisitos<br /> c) Funciones del sistema<br />Las funciones del sistema son lo queéstedeberá de hacer.<br />El sistemadeberáhacer <X><br />Las funcionespuedenclasificarse en lascategorías:<br />
  62. 62. CATEGORIAS DE LAS FUNCIONES<br />
  63. 63. Requisitos<br />Estas son algunas de lasfunciones del sistema de punto de venta:<br />Ref. FunciónCategoría<br />R1.1 Registra la venta en proceso (actual): los productoscomprados. evidente<br />R1.2 Calcula el valor del impuesto a la venta actual evidente<br />R1.3 Captura la informaciónsobre el objetocompradousando<br />usandounacaptura manual del código de producto. evidente<br />R1.4 Reduce lascantidades del inventariocuando se realizaunaventa. oculta<br />R1.5 Se registranlasventasefectuadas. oculta<br />R1.6 El cajerodebeintroducirunaidentificación y unacontraseñapara<br />poderutilizar el sistema. evidente<br />R1.7 Ofrece un mecanismo de almacenamientopersistente. oculta<br />R1.8 Ofrecemecanismos de comunicación entre los procesos y entre<br /> los sistemas. oculta<br />R1.9 Muestra la descripción y el precio del productoregistrado. evidente<br />
  64. 64. ENCONTRAR CASOS DE USO POR LA IDENTIFICACION DE ACTORES <br />Los clientes requieren registrar sus compras y pagar sus artículos<br />Los vendedores necesitan cobrar los productos y dar cambio sin equivocarse<br />Propietarios requieren conocer los ingresos y sus utilidades mensuales.<br />Basados en las respuestas emitidas extraemos la siguiente matriz de actores.<br />
  65. 65. IDENTIFICACION DE CASOS DE USO<br />La colección de casos de uso de un sistema constituye todas las maneras en que un sistema puede ser utilizado<br />Con la identificación de actores ahora podemos mencionar unas preguntas para identificar casos de uso.<br />¿ Cuales son las tareas que realiza cada actor?<br />¿Cualquier actor creará, guardará, modificará, eliminará, o leerá la información en el sistema?<br />¿Qué casos de uso crearán, guardarán, modificarán, eliminarán o leerán esta información?<br />¿Cualquier actor informará los cambios súbitos externos que sufra el sistema?<br />¿Qué casos de uso brindarán soporte y mantenimiento al sistema?<br />¿Todos los requisitos funcionales pueden ser realizados por los casos de uso?<br />
  66. 66. De acuerdo al ejercicio debemos tomar en cuenta que el sistema debe soportar las siguientes necesidades:<br />El actor cliente necesita comprar productos<br />El actor cajero necesita usar el sistema para registrar los productos y datos adicionales de la venta y entregar el cambio.<br />El actor gerente es el responsable de iniciar y cerrar el sistema <br />De acuerdo a éstas necesidades podemos identificar los siguientes casos de uso:<br />Registrar datos<br />Comprar productos<br />Entregar cambio<br />Iniciar Venta<br />Cerrar Venta<br />
  67. 67. Descripción de un caso de uso<br />Comprar productos<br />Flujo Principal: Un cliente llega a la caja registradora con un conjunto de productos. El Cajero registra los artículos y se genera una factura. El cliente paga en efectivo y recoge los productos<br /> COMPRENDER CONTEXTO DEL SISTEMA<br /> 1. El cliente llega a la caja registradora con los productos.<br /> 2. El cajero registra el código de cada productos.<br /> 3. El sistema obtiene el precio de cada producto y añade la información a la transacción de venta.<br /> 4. Al acabar el cajero indica la finalización de la introducción de productos. <br /> 5. El sistema calcula el total de la compra y lo muestra.<br />
  68. 68. Descripción de un caso de uso<br />Comprar productos (en un terminal de punto de venta)<br /> 6. El Cajero le dice al cliente el total.<br /> 7. El cliente realiza el pago.<br /> 8. El cajero registra la cantidad de dinero recibida.<br /> 9. El sistema muestra la cantidad a retornar al cliente y genera un recibo.<br /> 10. El cajero deposita el dinero recibido y saca la cantidad a devolver que entrega al cliente junto a la factura de compra.<br /> 11. El sistema almacena la compra completada.<br /> 12. El cliente recoge los prodcuctos comprados.<br />
  69. 69. Casos de uso: <br />FORMATO DE ALTO NIVEL<br />El formato para la descripción de los casos de uso es el siguiente:<br />Identificación: Cu …<br />Caso de uso: Nombre<br />Actores: Lista de actores (agentes externos)<br /> Tipo: Primario, secundario u opcional. Esencial o real.<br />Descripción: Descripción del caso de uso<br />
  70. 70. Casos de uso: <br />FORMATO DE ALTO NIVEL<br />Ejemplo: el siguientecaso de uso describe el proceso de comprarproductos en unatienda, a través de un terminal de punto de venta.<br />Identificación: CU2<br />Caso de uso: Comprarproductos<br />Actores: Cliente(iniciador), cajero<br />Tipo: Primario<br />Descripción: Un Clientellega a unacaja con productosquedesea<br />comprar. El Cajeroregistra los prodcutos y obtiene<br /> el pago. Al terminar la transacción, el Cliente se marcha<br /> con los productos.<br />Es conveniente comenzar con los casos de uso de más alto nivel para<br />lograr comprender mejor los principales procesos globales.<br />
  71. 71. Casos de uso: <br />FORMATO DE ALTO NIVEL<br />Ejemplo: el siguientecaso de uso describe el proceso de Inicaroperaciones en un almacén, a través de un terminal de punto de venta.<br />Identificación: …………..<br />Caso de uso: ………………………..<br />Actores: ……………………………….<br />Tipo: ………………………………………..<br />Descripción: …………………………………………………………………...…<br />
  72. 72. Casos de uso: <br />FORMATO EXPANDIDO<br />El formatopara la descripción de los casos de usoes el siguiente:<br />Identificación: CU..<br />Caso de uso: Nombre<br />Actores: Lista de actores (agentesexternos)<br />Propósito: Intención del caso de uso<br />Resumen: Repetición del caso de uso de alto nivel o algunasíntesis.<br />Tipo: Primario, secundario u opcional. Esencial o real.<br />Referencias<br />cruzadas: Casos de usorelacionados y funcionesrelacionadas del sistema.<br />Condiciones<br />Previas: Casos de Usoquetienenquehabersedesarrollado antes<br />Post-condiciones: Que pasó después de haberse ejecutado el caso de uso.<br />Continúa<br />
  73. 73. Flujo Normal de Eventos<br />Acción de los Actores Respuesta del sistema<br />Sección:…(subflujo…..)<br />Flujo alternativos / excepcionales<br />Existen otros formatos<br />

×