Cuestionario sobre Diagramas de Casos de Uso

¿Qué representa un diagrama de casos de uso?. La arquitectura del sistema. Las funcionalidades del sistema desde la perspectiva del usuario. El diseño de la base de datos. El código fuente del sistema.

¿Cuál es el propósito principal de los diagramas de casos de uso?. Documentar el código fuente. Describir la interfaz de usuario. Especificar las funcionalidades de un sistema desde la perspectiva del usuario. Diseñar la base de datos.

¿Qué representa un "actor" en un diagrama de casos de uso?. Una funcionalidad específica del sistema. Un componente de hardware del sistema. Un usuario o sistema externo que interactúa con el sistema. Una base de datos.

¿Cómo se representa visualmente un caso de uso en un diagrama?. Un rectángulo. Un círculo. Un óvalo. Un triángulo.

¿Cuál es la función de las relaciones de 'inclusión' en los diagramas de casos de uso?. Modificar el comportamiento de un caso de uso. Indicar que un caso de uso incluye a otro. Delimitar el sistema. Crear una jerarquía de casos de uso.

¿Qué indica la relación de 'extensión' en un diagrama de casos de uso?. Que un caso de uso es especializado. Que un caso de uso es incluido. Que un caso de uso puede modificar el comportamiento de otro. Que delimita el sistema.

¿Cómo se representa el límite de un sistema en un diagrama de casos de uso?. Con una línea punteada. Con un rectángulo. Con un óvalo. Con una flecha.

¿Qué es la 'generalización' en los diagramas de casos de uso?. Crear un nuevo sistema. Indicar la inclusión de otro caso de uso. Crear una jerarquía de casos de uso. Modificar el comportamiento de un caso de uso.

¿Qué elemento del diagrama de casos de uso se conecta con los casos de uso mediante líneas?. El sistema. Los actores. Las relaciones de inclusión. Las relaciones de extensión.

¿Qué información se encuentra en el índice del documento?. Solo diagramas UML. Introducción, diagramas de casos de uso, simbología y casos prácticos. El código fuente del sistema. Solo los actores y casos de uso.

¿Por qué es importante documentar los casos de uso?. Para que los diagramas sean más largos. Para evitar ambigüedades y facilitar la comprensión a los desarrolladores. Para complicar el diseño del sistema. Para reducir el tiempo de desarrollo.

¿Qué tipo de información no siempre se refleja en los diagramas de casos de uso?. Los actores. Los casos de uso. Las relaciones entre actores y casos de uso. Los requisitos no funcionales.

¿Qué son los requisitos no funcionales?. Las funcionalidades del sistema. El tiempo de ejecución de un caso de uso. Los actores del sistema. Los casos de uso que se incluyen.

¿Qué son las precondiciones y poscondiciones de un caso de uso?. Los pasos dentro del caso de uso. Las restricciones de tiempo. Las condiciones que deben cumplirse antes y después de la ejecución del caso de uso. El actor del caso de uso.

¿Para qué se utilizan los diagramas de casos de uso?. Para escribir el código fuente. Para diseñar la base de datos. Para modelar las funcionalidades básicas que deben implementarse en un sistema informático. Para crear la interfaz gráfica del usuario.

¿Qué sucede si no se documentan correctamente los requisitos?. El desarrollo del sistema es más rápido. Pueden surgir problemas, conflictos y afectar la relación con el cliente. No hay ningún impacto. Los diagramas de casos de uso son más simples.

¿Cuál es un ejemplo de un requisito no funcional?. El usuario debe poder iniciar sesión. El sistema debe procesar las transacciones en menos de 1 segundo. El sistema debe mostrar una lista de productos. El usuario debe registrarse.

¿Qué tipo de elementos se pueden modelar con diagramas de casos de uso?. Solo las relaciones de herencia. Actores, casos de uso, funcionalidades, sistemas y relaciones. Solo la base de datos. Solo el código fuente.

¿Qué herramienta se puede usar para documentar un caso de uso?. Solo un diagrama UML. Un diagrama UML con los casos de uso indicados y un documento detallado. Solo el código fuente. Solo una descripción breve.

¿Por qué es importante modularizar el código?. Para que sea más difícil de entender. Para ahorrar tiempo de implementación y reutilizar código. Para escribir más código. Para que los diagramas de casos de uso sean más complejos.