Este documento presenta una introducción a la modelación de casos de uso en UML. Explica que un caso de uso describe un comportamiento deseado del sistema desde la perspectiva de un actor y que incluye un flujo principal y variantes. También describe los componentes clave de un caso de uso como actores, pre y poscondiciones, y escenarios.
Este documento presenta el Lenguaje Unificado de Modelado (UML) y cómo se pueden usar los diagramas de casos de uso y clases para modelar los requisitos funcionales de un sistema. Explica cómo los casos de uso describen el comportamiento deseado del sistema desde la perspectiva de los actores y cómo los diagramas de clases modelan la estructura del sistema.
Este documento presenta conceptos clave sobre sistemas y simulación, y caracteriza un sistema de cajero automático (ATM) que podría ser simulado. Explica que un sistema es un conjunto de elementos interrelacionados que cumplen una función, y que un modelo representa un sistema para aprender sobre él. Luego describe las simulaciones discretas y continuas, y finalmente caracteriza el sistema ATM detallando sus entidades, estados, eventos, ubicaciones, recursos y variables.
Los diagramas de casos de uso representan las interacciones entre actores y un sistema. Un caso de uso describe una funcionalidad del sistema y una secuencia de acciones entre un actor y el sistema. Los actores pueden ser personas u otros sistemas. Los casos de uso se utilizan para capturar los requisitos funcionales y describir las funcionalidades del sistema desde la perspectiva de los actores.
Este documento presenta una introducción general a la simulación. Explica que la simulación implica imitar el comportamiento de sistemas reales en una computadora usando software apropiado. Describe los tipos de simulaciones y los componentes clave de un modelo de simulación, como entidades, atributos, variables, recursos, colas y eventos. También cubre conceptos como medidas de desempeño y opciones para analizar resultados.
modelado casos de uso analisis y diseñooBereGarita
Este documento presenta el modelado de casos de uso con UML. Explica que los casos de uso especifican el comportamiento deseado del sistema desde la perspectiva de los actores y que representan los requisitos funcionales. Describe los componentes de un caso de uso como las secuencias de acciones, actores, variantes y objetivos tangibles. También cubre temas como la descripción textual y gráfica de casos de uso, las relaciones entre ellos, y cómo se obtienen y organizan los requisitos funcionales del sistema a través de este enfoque.
Este documento presenta el Lenguaje Unificado de Modelado (UML) y cómo se pueden usar los diagramas de casos de uso y clases para modelar los requisitos funcionales de un sistema. Explica qué son los casos de uso, cómo se describen y relacionan, e incluye ejemplos de diagramas y descripciones de casos de uso.
Este documento presenta el Lenguaje Unificado de Modelado (UML) 2.0 y describe cómo se pueden usar casos de uso y diagramas de clases en UML para modelar los requisitos y el diseño de un sistema de software. Explica qué son los casos de uso, cómo se describen y relacionan, e introduce los conceptos básicos de modelado estructural en UML como clases, paquetes y asociaciones.
El documento describe la técnica de casos de uso para la captura de requerimientos funcionales de un sistema. Explica que los casos de uso especifican el comportamiento del sistema a través de la interacción con usuarios u otros sistemas, describiendo qué hará el sistema a un alto nivel desde la perspectiva del usuario. También describe conceptos clave como actores, casos de uso, diagramas de casos de uso, y las relaciones que pueden existir entre casos de uso.
Este documento presenta el Lenguaje Unificado de Modelado (UML) y cómo se pueden usar los diagramas de casos de uso y clases para modelar los requisitos funcionales de un sistema. Explica cómo los casos de uso describen el comportamiento deseado del sistema desde la perspectiva de los actores y cómo los diagramas de clases modelan la estructura del sistema.
Este documento presenta conceptos clave sobre sistemas y simulación, y caracteriza un sistema de cajero automático (ATM) que podría ser simulado. Explica que un sistema es un conjunto de elementos interrelacionados que cumplen una función, y que un modelo representa un sistema para aprender sobre él. Luego describe las simulaciones discretas y continuas, y finalmente caracteriza el sistema ATM detallando sus entidades, estados, eventos, ubicaciones, recursos y variables.
Los diagramas de casos de uso representan las interacciones entre actores y un sistema. Un caso de uso describe una funcionalidad del sistema y una secuencia de acciones entre un actor y el sistema. Los actores pueden ser personas u otros sistemas. Los casos de uso se utilizan para capturar los requisitos funcionales y describir las funcionalidades del sistema desde la perspectiva de los actores.
Este documento presenta una introducción general a la simulación. Explica que la simulación implica imitar el comportamiento de sistemas reales en una computadora usando software apropiado. Describe los tipos de simulaciones y los componentes clave de un modelo de simulación, como entidades, atributos, variables, recursos, colas y eventos. También cubre conceptos como medidas de desempeño y opciones para analizar resultados.
modelado casos de uso analisis y diseñooBereGarita
Este documento presenta el modelado de casos de uso con UML. Explica que los casos de uso especifican el comportamiento deseado del sistema desde la perspectiva de los actores y que representan los requisitos funcionales. Describe los componentes de un caso de uso como las secuencias de acciones, actores, variantes y objetivos tangibles. También cubre temas como la descripción textual y gráfica de casos de uso, las relaciones entre ellos, y cómo se obtienen y organizan los requisitos funcionales del sistema a través de este enfoque.
Este documento presenta el Lenguaje Unificado de Modelado (UML) y cómo se pueden usar los diagramas de casos de uso y clases para modelar los requisitos funcionales de un sistema. Explica qué son los casos de uso, cómo se describen y relacionan, e incluye ejemplos de diagramas y descripciones de casos de uso.
Este documento presenta el Lenguaje Unificado de Modelado (UML) 2.0 y describe cómo se pueden usar casos de uso y diagramas de clases en UML para modelar los requisitos y el diseño de un sistema de software. Explica qué son los casos de uso, cómo se describen y relacionan, e introduce los conceptos básicos de modelado estructural en UML como clases, paquetes y asociaciones.
El documento describe la técnica de casos de uso para la captura de requerimientos funcionales de un sistema. Explica que los casos de uso especifican el comportamiento del sistema a través de la interacción con usuarios u otros sistemas, describiendo qué hará el sistema a un alto nivel desde la perspectiva del usuario. También describe conceptos clave como actores, casos de uso, diagramas de casos de uso, y las relaciones que pueden existir entre casos de uso.
El proceso de desarrollo de software incluye la asignación disciplinada de tareas y responsabilidades para asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles. Esto implica definir quién realiza qué tareas, cuándo y cómo. El objetivo es desarrollar software que cumpla con los requisitos del usuario de manera eficiente.
Este documento presenta varios ejercicios relacionados con diagramas de casos de uso. El primer ejercicio consiste en indicar si varias afirmaciones sobre casos de uso son verdaderas o falsas. El segundo ejercicio analiza un diagrama de casos de uso existente. El tercer ejercicio pide corregir errores en otros diagramas. Los ejercicios 4 y 5 analizan la identificación de actores y casos de uso en diagramas específicos de sistemas de ventas. En general, el documento proporciona ejemplos y preguntas para practicar
Este documento describe las actividades de ingeniería de requerimientos B y C, que incluyen priorizar casos de uso, detallar casos de uso mediante la descripción de sus flujos de eventos, y refinar las descripciones de casos de uso agregando más detalles. Se explican las secciones a incluir en la descripción de un caso de uso, como actores, precondiciones, flujo principal y alternativas. También se provee un ejemplo detallado de la descripción de un caso de uso.
Unidad 4 Mad Modelado Analisis Casos De UsoSergio Sanchez
El documento describe los fundamentos de los modelos de casos de uso en UML. Explica que los casos de uso documentan el comportamiento del sistema desde la perspectiva del usuario y ayudan con la captura de requisitos, la planificación del desarrollo y la validación del sistema. Define un caso de uso como una secuencia de acciones que produce un resultado observable para un actor en particular. Describe los componentes clave de un caso de uso como los actores, escenarios y formatos para documentarlos.
Modelado de Requisitos - 1ra parte 2022.pdfReneArancibia5
Este documento presenta información sobre la especificación de requisitos y el modelado de requisitos mediante casos de uso. Explica formas de escribir especificaciones de requisitos como lenguaje natural, especificaciones estructuradas y escenarios. También describe los componentes básicos de los casos de uso como actores, casos de uso, alternativas y relaciones.
Este documento presenta los conceptos básicos del modelado de requerimientos orientado a objetos, incluyendo los tipos de requerimientos, diagramas de casos de uso, elementos de los casos de uso como actores y casos, y las relaciones entre casos de uso. Explica cómo los casos de uso pueden usarse para modelar las necesidades del sistema desde la perspectiva del usuario.
El documento describe los elementos básicos de un diagrama de casos de uso para modelar la funcionalidad de un sistema. Explica que un caso de uso representa una unidad funcional del sistema, mientras que un actor representa una entidad externa que interactúa con el sistema. También describe las diferentes relaciones que pueden existir entre casos de uso, como asociación, inclusión, extensión y generalización.
Modelado funcional casos de uso, Modelado funcional casos de uso, Modelado funcional casos de uso, Modelado funcional casos de uso,Modelado funcional casos de uso
Este documento introduce los casos de uso y sus elementos principales. Explica que un caso de uso describe la interacción entre un sistema y sus actores en respuesta a un evento. Identifica los actores principales y secundarios, y describe cómo construir y trabajar con casos de uso de manera iterativa para describir funcionalidades y escenarios. También cubre diagramas de casos de uso y sus elementos, incluyendo relaciones como asociación, dependencia e inclusión.
10 Clase Captura De Los Requisitos Cap.6Julio Pari
Este documento describe los pasos para capturar los requisitos de un sistema de manera efectiva. Se necesitan modelos del dominio y del negocio para comprender el contexto del sistema. Los requisitos funcionales se capturan a través de casos de uso, mientras que los no funcionales se especifican por separado. El proceso iterativo permite actualizar los requisitos a lo largo del desarrollo del proyecto.
10 Clase Captura De Los Requisitos Cap[1].6Julio Pari
Este documento describe los pasos para capturar los requisitos de un sistema de manera efectiva. Se necesitan artefactos como un modelo de casos de uso, requisitos adicionales, modelos de dominio y de negocio. Los modelos de dominio y negocio ayudan a comprender el contexto mediante la identificación de objetos, procesos y actores. La captura de requisitos funcionales se basa en casos de uso, mientras que los no funcionales especifican propiedades como rendimiento y seguridad. El proceso iterativo permite actualizar los
Este documento describe conceptos clave de ingeniería de requisitos como casos de uso, actores, diagramas de casos de uso y especificaciones de casos de uso. Explica cómo modelar requisitos funcionales a través de casos de uso, incluyendo la estructuración y relaciones entre casos de uso como generalización, extensión e inclusión. También cubre temas como pre-condiciones, post-condiciones y la guía para elaborar especificaciones de casos de uso.
El documento describe los diagramas de casos de uso, incluyendo sus elementos principales como actores, casos de uso y las relaciones entre ellos. Explica que los diagramas de casos de uso modelan la funcionalidad de un sistema desde la perspectiva de los usuarios finales a través de la interacción entre actores y casos de uso.
El documento describe los conceptos básicos de los procesos de software y el modelado de procesos. Explica que un proceso es un conjunto de actividades coordinadas con un fin determinado. Luego describe las fases del ciclo de vida del software, incluido el modelado, y ofrece un ejemplo práctico de desarrollo de software para una empresa de autobuses. Finalmente, explica los conceptos de modelo de dominio, diagramas de casos de uso y cómo modelar el comportamiento y requisitos de un sistema.
El documento describe los siguientes puntos sobre requerimientos de software: establecer acuerdos con los clientes, definir el alcance del sistema, proporcionar una base para la planificación y estimación, y definir la interfaz de usuario centrándose en las necesidades de los usuarios. Además, explica conceptos como requerimientos funcionales y no funcionales, y el uso de casos de uso para modelar la funcionalidad del sistema desde la perspectiva del usuario.
El manual describe los procesos y características del sistema para que los usuarios puedan introducir y acceder información. Explica los objetivos de enseñar a los usuarios a preparar y obtener datos de entrada y salida, y servir como manual de aprendizaje y referencia. Detalla los pasos para definir los usuarios, sus roles, y los módulos en que participarán. Además, explica los elementos clave del manual como la portada, tabla de contenido, requisitos, instalación, diagramas de flujo, entradas y salidas del sistema, y situ
Este documento presenta los contenidos de una unidad sobre diseño de sistemas. Incluye introducciones a temas como el proceso de diseño, principios de diseño, documentación de diseño, análisis y diseño orientados a objetos, modelos de dominio y casos de uso, y el lenguaje UML. También presenta un caso de estudio de ejemplo sobre un videoclub y los primeros artefactos de análisis requeridos como la presentación general del sistema, descripción de clientes, metas, funciones y atributos.
Este documento describe los diagramas de casos de uso y su utilización para capturar los requisitos funcionales de un sistema. Explica que un caso de uso representa una interacción entre un actor y el sistema, y que un diagrama de casos de uso incluye actores, casos de uso y las comunicaciones entre ellos. Además, detalla el proceso de construcción de casos de uso a través de la identificación de actores, preguntas para detectar casos de uso y su descripción formal.
Casos de Uso - Juan Bernardo Quintero, Casos de Uso - Juan Bernardo Quintero, Casos de Uso - Juan Bernardo Quintero, Casos de Uso - Juan Bernardo Quintero
Este documento presenta el diseño de un sistema de facturación para una empresa de mantenimiento y repuestos de autos llamada REDICA DEL CENTRO C.A. El equipo de analistas describe el análisis de requisitos, el diseño de la interfaz, la arquitectura del sistema, el diseño de la base de datos y las pruebas del sistema. El objetivo del nuevo sistema es automatizar los procesos de facturación, registro de clientes y repuestos para mejorar la eficiencia y confiabilidad de la empresa.
El proceso de desarrollo de software incluye la asignación disciplinada de tareas y responsabilidades para asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles. Esto implica definir quién realiza qué tareas, cuándo y cómo. El objetivo es desarrollar software que cumpla con los requisitos del usuario de manera eficiente.
Este documento presenta varios ejercicios relacionados con diagramas de casos de uso. El primer ejercicio consiste en indicar si varias afirmaciones sobre casos de uso son verdaderas o falsas. El segundo ejercicio analiza un diagrama de casos de uso existente. El tercer ejercicio pide corregir errores en otros diagramas. Los ejercicios 4 y 5 analizan la identificación de actores y casos de uso en diagramas específicos de sistemas de ventas. En general, el documento proporciona ejemplos y preguntas para practicar
Este documento describe las actividades de ingeniería de requerimientos B y C, que incluyen priorizar casos de uso, detallar casos de uso mediante la descripción de sus flujos de eventos, y refinar las descripciones de casos de uso agregando más detalles. Se explican las secciones a incluir en la descripción de un caso de uso, como actores, precondiciones, flujo principal y alternativas. También se provee un ejemplo detallado de la descripción de un caso de uso.
Unidad 4 Mad Modelado Analisis Casos De UsoSergio Sanchez
El documento describe los fundamentos de los modelos de casos de uso en UML. Explica que los casos de uso documentan el comportamiento del sistema desde la perspectiva del usuario y ayudan con la captura de requisitos, la planificación del desarrollo y la validación del sistema. Define un caso de uso como una secuencia de acciones que produce un resultado observable para un actor en particular. Describe los componentes clave de un caso de uso como los actores, escenarios y formatos para documentarlos.
Modelado de Requisitos - 1ra parte 2022.pdfReneArancibia5
Este documento presenta información sobre la especificación de requisitos y el modelado de requisitos mediante casos de uso. Explica formas de escribir especificaciones de requisitos como lenguaje natural, especificaciones estructuradas y escenarios. También describe los componentes básicos de los casos de uso como actores, casos de uso, alternativas y relaciones.
Este documento presenta los conceptos básicos del modelado de requerimientos orientado a objetos, incluyendo los tipos de requerimientos, diagramas de casos de uso, elementos de los casos de uso como actores y casos, y las relaciones entre casos de uso. Explica cómo los casos de uso pueden usarse para modelar las necesidades del sistema desde la perspectiva del usuario.
El documento describe los elementos básicos de un diagrama de casos de uso para modelar la funcionalidad de un sistema. Explica que un caso de uso representa una unidad funcional del sistema, mientras que un actor representa una entidad externa que interactúa con el sistema. También describe las diferentes relaciones que pueden existir entre casos de uso, como asociación, inclusión, extensión y generalización.
Modelado funcional casos de uso, Modelado funcional casos de uso, Modelado funcional casos de uso, Modelado funcional casos de uso,Modelado funcional casos de uso
Este documento introduce los casos de uso y sus elementos principales. Explica que un caso de uso describe la interacción entre un sistema y sus actores en respuesta a un evento. Identifica los actores principales y secundarios, y describe cómo construir y trabajar con casos de uso de manera iterativa para describir funcionalidades y escenarios. También cubre diagramas de casos de uso y sus elementos, incluyendo relaciones como asociación, dependencia e inclusión.
10 Clase Captura De Los Requisitos Cap.6Julio Pari
Este documento describe los pasos para capturar los requisitos de un sistema de manera efectiva. Se necesitan modelos del dominio y del negocio para comprender el contexto del sistema. Los requisitos funcionales se capturan a través de casos de uso, mientras que los no funcionales se especifican por separado. El proceso iterativo permite actualizar los requisitos a lo largo del desarrollo del proyecto.
10 Clase Captura De Los Requisitos Cap[1].6Julio Pari
Este documento describe los pasos para capturar los requisitos de un sistema de manera efectiva. Se necesitan artefactos como un modelo de casos de uso, requisitos adicionales, modelos de dominio y de negocio. Los modelos de dominio y negocio ayudan a comprender el contexto mediante la identificación de objetos, procesos y actores. La captura de requisitos funcionales se basa en casos de uso, mientras que los no funcionales especifican propiedades como rendimiento y seguridad. El proceso iterativo permite actualizar los
Este documento describe conceptos clave de ingeniería de requisitos como casos de uso, actores, diagramas de casos de uso y especificaciones de casos de uso. Explica cómo modelar requisitos funcionales a través de casos de uso, incluyendo la estructuración y relaciones entre casos de uso como generalización, extensión e inclusión. También cubre temas como pre-condiciones, post-condiciones y la guía para elaborar especificaciones de casos de uso.
El documento describe los diagramas de casos de uso, incluyendo sus elementos principales como actores, casos de uso y las relaciones entre ellos. Explica que los diagramas de casos de uso modelan la funcionalidad de un sistema desde la perspectiva de los usuarios finales a través de la interacción entre actores y casos de uso.
El documento describe los conceptos básicos de los procesos de software y el modelado de procesos. Explica que un proceso es un conjunto de actividades coordinadas con un fin determinado. Luego describe las fases del ciclo de vida del software, incluido el modelado, y ofrece un ejemplo práctico de desarrollo de software para una empresa de autobuses. Finalmente, explica los conceptos de modelo de dominio, diagramas de casos de uso y cómo modelar el comportamiento y requisitos de un sistema.
El documento describe los siguientes puntos sobre requerimientos de software: establecer acuerdos con los clientes, definir el alcance del sistema, proporcionar una base para la planificación y estimación, y definir la interfaz de usuario centrándose en las necesidades de los usuarios. Además, explica conceptos como requerimientos funcionales y no funcionales, y el uso de casos de uso para modelar la funcionalidad del sistema desde la perspectiva del usuario.
El manual describe los procesos y características del sistema para que los usuarios puedan introducir y acceder información. Explica los objetivos de enseñar a los usuarios a preparar y obtener datos de entrada y salida, y servir como manual de aprendizaje y referencia. Detalla los pasos para definir los usuarios, sus roles, y los módulos en que participarán. Además, explica los elementos clave del manual como la portada, tabla de contenido, requisitos, instalación, diagramas de flujo, entradas y salidas del sistema, y situ
Este documento presenta los contenidos de una unidad sobre diseño de sistemas. Incluye introducciones a temas como el proceso de diseño, principios de diseño, documentación de diseño, análisis y diseño orientados a objetos, modelos de dominio y casos de uso, y el lenguaje UML. También presenta un caso de estudio de ejemplo sobre un videoclub y los primeros artefactos de análisis requeridos como la presentación general del sistema, descripción de clientes, metas, funciones y atributos.
Este documento describe los diagramas de casos de uso y su utilización para capturar los requisitos funcionales de un sistema. Explica que un caso de uso representa una interacción entre un actor y el sistema, y que un diagrama de casos de uso incluye actores, casos de uso y las comunicaciones entre ellos. Además, detalla el proceso de construcción de casos de uso a través de la identificación de actores, preguntas para detectar casos de uso y su descripción formal.
Casos de Uso - Juan Bernardo Quintero, Casos de Uso - Juan Bernardo Quintero, Casos de Uso - Juan Bernardo Quintero, Casos de Uso - Juan Bernardo Quintero
Este documento presenta el diseño de un sistema de facturación para una empresa de mantenimiento y repuestos de autos llamada REDICA DEL CENTRO C.A. El equipo de analistas describe el análisis de requisitos, el diseño de la interfaz, la arquitectura del sistema, el diseño de la base de datos y las pruebas del sistema. El objetivo del nuevo sistema es automatizar los procesos de facturación, registro de clientes y repuestos para mejorar la eficiencia y confiabilidad de la empresa.
Desarrollo Sostenible y Conservación del Medio Ambiente.pdfillacruzmabelrocio
La conservación del medio ambiente aborda la protección, gestión y restauración de los recursos naturales y los ecosistemas para mantener su funcionalidad y biodiversidad.
La fase luminosa, fase clara, fase fotoquímica o reacción de Hill es la primera fase de la fotosíntesis, que depende directamente de la luz o energía lumínica para poder obtener energía química en forma de ATP y NADPH, a partir de la disociación de moléculas de agua, formando oxígeno e hidrógeno.
2. 2
*Introducción al modelado del software
*Presentación de UML
*Modelado de Casos de Usos
*Diagramas de casos de uso
*Modelado Estructural
*Diagramas de clases
*Paquetes
3. 3
*Un caso de uso especifica un comportamiento
deseado del sistema.
*Representan los requisitos funcionales del sistema.
“Un caso de uso especifica un conjunto de
secuencias de acciones, incluyendo variantes, que
el sistema puede ejecutar y que produce un
resultado observable de valor para un particular
actor.” (Definición en
UML)
*Describen qué hace el sistema, no cómo lo hace.
4. 4
*Partes de un caso de uso (cdu)
*Conjunto de secuencias de acciones; cada secuencia representa un
posible comportamiento del sistema
*Actores, roles que pueden jugar los usuarios
*Variantes: versiones especializadas, un cdu que extiende a otro o un
cdu que incluye a otro
*Un caso de uso realiza un trabajo tangible.
5. Emisor Centralita Receptor
listo( )
tono
marcar_numero
tono_sonando
timbre_sonando
telefono_cogido
para_tono
para_timbre
Escenario
Los Casos de uso son ideados por Jacobson a principios de los noventa y
están inspirados en los Escenarios utilizados para describir procesos.
7. 7
Un actor representa un conjunto coherente de
roles que juegan los usuarios de los casos de
uso al interaccionar con el sistema.
*Roles jugados por personas, dispositivos, u
otros sistemas.
*El tiempo puede ser un actor (“procesos
iniciados automáticamente por el sistema”).
*No forman parte del sistema.
8. 8
*Un usuario puede jugar diferentes roles.
*En la realización de un caso de uso pueden
intervenir diferentes actores.
*Un actor puede intervenir en varios casos de uso.
*Identificar casos de uso mediante actores y
eventos externos.
*Un actor necesita el caso de uso y/o participa en
él.
9. 9
*Dos tipos de actores:
*Principal:
Requiere al sistema el cumplimiento de un objetivo.
*Secundarios:
El sistema necesita de ellos para satisfacer un objetivo.
10. 10
*Un caso de uso describe un conjunto de
secuencias de interacciones entre actores y el
sistema (escenarios): flujo principal y flujos
alternativos o excepcionales.
*Un escenario es una instancia de un caso de uso
*Un escenario es una historia particular de uso de
un sistema.
*Escenarios principales vs. Escenarios secundarios
11. 11
*Son iniciados por un actor con un objetivo en
mente y es completado con éxito cuando el
sistema lo satisface.
*Puede incluir secuencias alternativas que llevan
al éxito y fracaso en la consecución del objetivo.
*El sistema es considerado como una “caja negra”
y las interacciones se perciben desde fuera.
*El conjunto completo de casos de uso especifica
todas las posibles formas de usar el sistema, esto
es el comportamiento requerido.
12. 12
*Son documentos de texto, no son diagramas.
*El modelado de casos de uso consiste en escribir texto, no
en dibujar diagramas.
*Describir el flujo de eventos
*Texto estructurado informal
*Texto estructurado formal (plantillas)
*Pseudocódigo
*Notaciones gráficas: diagramas de secuencia
*Debe ser legible y comprensible para un usuario no
experto.
*Debe indicar: actores, flujos principal y excepcionales.
14. 14
Realizar Venta (en un Terminal de Punto de Venta o
TPV)
Actor Principal: Cajero
Flujo Principal: Un cliente llega al TPV con un conjunto de artículos.
El Cajero registra los artículos y se genera un ticket. El cliente paga en
efectivo y recoge los artículos.
1. El cliente llega al TPV con los artículos.
2. El cajero registra el identificador de cada artículo.
3. El sistema obtiene el precio de cada artículo y añade la información a la
transacción de venta.
4. Al acabar el cajero indica la finalización de la introducción de artículos.
15. 15
Realizar Venta (en un Terminal de Punto de Venta o
TPV)
5. El sistema calcula el total de la compra y lo muestra.
6. El cajero le dice al cliente el total.
7. El cliente realiza el pago.
8. El cajero registra la cantidad de dinero recibida.
9. El sistema muestra la cantidad a retornar al cliente y genera un recibo.
10. El cajero deposita el dinero recibido y saca la cantidad a devolver que
entrega al cliente junto al ticket de compra.
11. El sistema almacena la compra completada.
12. El cliente recoge los artículos comprados.
17. 17
Reservar Libro
Prestamo Libro
Devolver Libro
Socio
Extender Prestamo
Prestamo Revista
Profesor
Devolver Revista
Bibliotecario
Actualizar Catalogo
Socio
Consultar
18. 18
*Con un caso de uso se describe un
comportamiento esperado del sistema, pero no
se especifica cómo se implementa.
*Una caso de uso se implementa a través de una
colaboración:
“Sociedad de clases y otros elementos que
colaborarán para realizar el comportamiento
expresado en un caso de uso”
*Una colaboración tiene una parte estática
(diagramas de clases) y una parte dinámica
(diagramas de secuencia).
20. 20
*Tres tipos de relaciones:
*Generalización
*Un cdu hereda el comportamiento y significado de otro.
*Inclusión
*Un cdu base incorpora explícitamente el comportamiento de otro
en algún lugar de su secuencia.
*Extensión
*Un cdu base incorpora implícitamente el comportamiento de otro
cdu en el lugar especificado indirectamente por este otro cdu.
22. 22
*Permite factorizar un comportamiento en un
caso de uso aparte y evitar repetir un mismo
flujo en diferentes casos de uso.
*Ejemplo:
Hacer Pedido:
Obtener y verificar el número de
pedido;
Incluir “Validar usuario”;
Recoger los ítem del pedido del
usuario;
…
23. 23
*El caso de uso base incluye una serie de puntos
de extensión.
*Sirve para modelar:
*la parte opcional del sistema, o
*un subflujo que sólo se ejecuta bajo ciertas condiciones.
24. 24
*Ejemplo:
Hacer Pedido:
Incluir “Validar usuario”;
Recoger los ítem del pedido del usuario;
Establecer prioridad: punto de extensión
Enviar pedido para ser procesado según
la prioridad.
25. 25
1) Identificar los usuarios del sistema.
2) Encontrar todos los roles que juegan los usuarios y que son
relevantes al sistema.
3) Para cada rol identificar todas las formas (objetivos) de
interactuar con el sistema.
4) Crea un caso de uso por cada objetivo.
5) Estructurar los casos de uso.
6) Revisar y validar con el usuario.
26. 26
*Resumen
*Actores Principales y Secundarios
*Personas involucradas e Intereses
*Precondiciones
*Poscondiciones
*Escenario Principal (Flujo Básico)
*Extensiones (Flujos Alternativos)
*Requisitos de Interfaz de Usuario
*Requisitos No-Funcionales
*Cuestiones Pendientes
27. 27
*Resumen: Un cliente llega al TPV con un conjunto de
artículos. El cajero registra los artículos y se genera un
ticket. El cliente paga en efectivo y recoge los artículos.
*Actores: Cajero (principal), Sistema (secundario)
*Personal Involucrado e Intereses:
*Cajero: quiere entradas precisas, rápidas y sin errores de pago.
*Compañía: quiere registrar transacciones y satisfacer clientes.
*...
*Precondición: El cajero se identifica y autentifica.
*Poscondiciones: Se registra la venta. Se calcula el
impuesto. Se actualiza la contabilidad y el inventario.
28. 28
*Escenario Principal (Flujo Básico):
1. El cliente llega al TPV con los artículos.
2. El cajero inicia una nueva venta.
3. El cajero introduce el identificador de cada artículo.
4. El sistema registra la línea de venta y presenta descripción del
artículo, precio y suma parcial.
El cajero repite los pasos 3 y 4 hasta que se indique.
5. El sistema presenta el total.
6. El cajero le dice al cliente el total a pagar .
7. El cliente paga y el sistema gestiona el pago.
8. El sistema registra la venta completa y actualiza el inventario.
9. El sistema presenta recibo.
29. 29
*Extensiones (Flujos Alternativos):
A1: Identificador no válido
La secuencia A1 comienza en el punto 3.
4. El sistema señala el error y rechaza la entrada.
El escenario vuelve al punto 3.
A2: El cliente pide eliminar un artículo de la compra.
La secuencia A2 puede ocurrir entre los puntos 3-6.
1. El cajero introduce identificador a eliminar.
2. El sistema actualiza la suma.
El escenario continúa en el punto 6.
A3: Pago en efectivo
La secuencia A3 ocurre en el punto 7.
1. El cajero introduce la cantidad entregada por el cliente.
2. El sistema muestra cantidad a devolver.
El escenario continúa en el punto 8.
…
30. 30
*Requisitos de Interfaz de Usuario:
- Pantalla táctil en un monitor de pantalla plana.
- El texto debe ser visible a un metro de distancia.
*Requisitos No-Funcionales:
- El identificador del producto podría ser cualquier esquema
de código de barras UPC, EAN-8, EAN-13, ...
- El tiempo de respuesta para autorizar el pago con la
tarjeta de débito o de crédito es de 30 segundos.
*Cuestiones Pendientes:
- Explorar cuestiones de recuperación de accesos a servicios
remotos.
- ¿Qué adaptaciones son necesarias en un TPV para
diferentes negocios?
31. 31
*Hay consenso en considerar casos de uso como esenciales
para capturar requisitos y guiar el modelado.
*Pero todavía existe mucha confusión sobre cómo usarlos.
*¿Cuál es el número de casos de uso apropiado en un proyecto?
*¿Qué casos de uso hay en el sistema?
32. 32
*Diferente granularidad
*Casos de uso del negocio
*Procesos de Negocio: Objetivo estratégico de la empresa
*Ej. Vender productos
*Casos de uso del sistema
*Objetivo de un usuario
*Ej. Realizar una compra
*Casos de uso de inclusión
*Forman parte de otro, son como subfunciones
*Ej. Buscar, Validar, Login
33. 33
*Especificar casos de uso no es una actividad de
dibujar diagramas sino de escribir con el detalle
necesario el flujo principal y los flujos alternativos:
“centrado en la escritura en vez del dibujo”.
*No hay que preocuparse demasiado por las relaciones
entre casos de uso ni entre actores.
*El objetivo inicial es identificar los actores y a partir
de sus objetivos encontrar los casos de uso, ya que el
diagrama de casos de uso es una ayuda visual.
*Los actores deben interactuar con el sistema.
34. 34
*No incluir como caso de uso las operaciones CRUD sobre
un objeto de negocio (alta, consulta, borrado, actualización).
CRUD es el acrónimo de Crear, Obtener, Actualizar y
Borrar (Create, Retrieve, Update y Delete en inglés).
*La excepción es si se trata de operaciones relevantes para el
sistema, como “Registrar Cliente” en un sistema de venta por
Internet.
*Cuidado con el empleo de la relación “include”.
¡NO HACER UNA DESCOMPOSICION FUNCIONAL!
*Los casos de uso sólo consideran los requisitos
funcionales del proyecto, hay que añadir los no-
funcionales.