Understanding Use Cases and Git Commands

¿Qué es un requisito de caso de uso?

• Un requisito de caso de uso describe el hardware necesario para un proyecto.

• Un requisito de caso de uso es una especificación técnica detallada.

• Un requisito de caso de uso describe las limitaciones presupuestarias para un sistema.

• Un requisito de caso de uso especifica un escenario para la interacción del sistema para lograr un objetivo.

¿Cómo identificas a los actores en un caso de uso?

• Identificar los requisitos de hardware del sistema.

• Determinar el ciclo de vida del desarrollo de software.

• Identificar a los usuarios principales y a los sistemas externos que interactúan con el sistema.

• Enumerar todas las características y funciones del sistema.

¿Cuál es el propósito de un diagrama de casos de uso?

• El propósito de un diagrama de casos de uso es representar los requisitos funcionales de un sistema y las interacciones entre los usuarios y el sistema.

• Ilustrar la estructura de la base de datos de un sistema.

• Mostrar los requisitos de hardware para un sistema.

• Definir los estándares de codificación para un proyecto.

¿Cuáles son los componentes principales de un caso de uso?

• Título, Actores, Precondiciones, Flujo Principal, Flujos Alternativos, Postcondiciones

• Título, Pasos, Resultados

• Actores, Objetivos, Restricciones

• Requisitos, Escenarios, Resultados

Explica la importancia de requisitos claros en los casos de uso.

• Los requisitos claros solo son necesarios para proyectos grandes.

• Los requisitos claros son irrelevantes para la satisfacción del usuario.

• Los requisitos claros son cruciales ya que proporcionan un entendimiento compartido, reducen la ambigüedad y guían el desarrollo, minimizando errores y retrabajos.

• Los requisitos ambiguos pueden mejorar la creatividad en el desarrollo.

¿Qué significa la 'S' en SOLID?

• Regla de Responsabilidad Única

• Principio de Responsabilidad Única

• Modelo de Responsabilidad Única

• Teoría de Responsabilidad Única

¿Cuál es el principio de Responsabilidad Única en SOLID?

• Una clase debe tener solo una razón para cambiar, enfocándose en una única responsabilidad.

• Una clase debe manejar múltiples responsabilidades para ser más eficiente.

• Una clase debe ser diseñada para cambiar con frecuencia por flexibilidad.

• Una clase solo debe contener métodos estáticos y ninguna variable de instancia.

¿Cómo mejora el Principio de Abierto/Cerrado el diseño de software?

• El Principio de Abierto/Cerrado mejora el diseño de software al promover la extensibilidad y mantenibilidad, permitiendo agregar nuevas características sin modificar el código existente.

• Exige el uso de una sola clase para todas las funcionalidades, reduciendo la flexibilidad.

• Restringe los cambios en el código existente, dificultando la adición de nuevas características.

• Fomenta el uso de variables globales para simplificar la gestión del código.

¿Cuál es el Principio de Sustitución de Liskov?

• El Principio de Sustitución de Liskov (LSP) es un concepto clave en la programación orientada a objetos que promueve la sustituibilidad de las subclases por sus clases padre.

• El Principio de Sustitución de Liskov requiere que todas las clases deben ser abstractas.

• El Principio de Sustitución de Liskov es un patrón de diseño para crear interfaces de usuario.

• El Principio de Sustitución de Liskov establece que las subclases deben tener métodos diferentes a los de sus clases padre.

Describe el Principio de Segregación de Interfaces.

• El Principio de Segregación de Interfaces se centra en reducir el número de clases en un sistema.

• El Principio de Segregación de Interfaces aboga por crear interfaces más pequeñas y específicas para evitar que los clientes dependan de métodos no utilizados.

• El Principio de Segregación de Interfaces establece que todos los métodos deben ser implementados por los clientes.

• El Principio de Segregación de Interfaces fomenta interfaces grandes y generales para mayor flexibilidad.