option
Cuestiones
ayuda
daypo
buscar.php

Examen ordinaria Fundamentos Inegeniería del Software (FIS) 2025-26 UJA

COMENTARIOS ESTADÍSTICAS RÉCORDS
REALIZAR TEST
Título del Test:
Examen ordinaria Fundamentos Inegeniería del Software (FIS) 2025-26 UJA

Descripción:
1 pregunta mal resta 1 bien

Fecha de Creación: 2026/07/03

Categoría: Otros

Número Preguntas: 25

Valoración:(1)
COMPARTE EL TEST
Nuevo ComentarioNuevo Comentario
Comentarios
NO HAY REGISTROS
Temario:

Según la técnica de Tarjetas CRC, una estrategia recomendada para asignar responsabilidades es que cada objeto sea lo más "perezoso" posible. V. F.

La ingeniería de requisitos es el proceso que establece cómo hacer un sistema. V. F.

El prototipado es una metodología de desarrollo ágil, ya que nos permite desarrollar las aplicaciones de manera rápida y precisa. V. F.

El "Manifiesto por el Desarrollo Ágil de Software" establece que no se debe realizar documentación exhaustiva en los proyectos, ya que el valor reside únicamente en el software funcionando. V. F.

Los requerimientos, tanto funcionales como no funcionales, se pueden describir en los diagramas de casos de uso. V. F.

Una de las principales utilidades del prototipado es el estudio de la interfaz hombre-máquina, permitiendo decidir qué debe mostrarse y qué debe introducir el usuario. V. F.

Una desventaja del modelo de métodos formales es que, aunque garantiza un software libre de errores, requiere mucha capacitación y hace difícil la comunicación con el cliente. V. F.

Según los principios de diseño modular, para facilitar el mantenimiento y la reutilización, se debe buscar un diseño con bajo acoplamiento y alta cohesión. V. F.

Las clases de análisis estereotipadas como "Entidad" modelan la interacción entre el sistema y los actores, y suelen tener una vida efímera que dura solo lo que la ejecución del caso de uso. V. F.

Las clases de análisis estereotipadas como "Control" suelen utilizarse para modelar la información persistente del sistema. V. F.

Analiza el siguiente diagrama de un sistema de frenado de emergencia. Fíjate en la regla definida entre que se detecta un evento, el sensor se activa y el estado del freno. La notación "{t..t+20ms}" es una restricción de tiempo que indica una ventana de tolerancia. Significa que, desde que ocurre el evento que activa el sensor (tiempo t), el sistema debe cambiar el estado del Freno a 'On' en un plazo máximo de 20 milisegundos. Si el cambio ocurre a los 25ms, el sistema no cumple el requisito. V. F.

El fragmento "loop" indica que la secuencia de mensajes en su interior se repetirá. Sin embargo, para que el diagrama sea válido, es obligatorio especificar el número exacto de iteraciones (por ejemplo, "loop(10)"). La expresión "[para cada artículo]" es inválida porque UML no permite condiciones textuales o booleanas en los bucles. V. F.

El sistema necesita descargar dos archivos grandes simultáneamente para optimizar el tiempo. Se utiliza el fragmento combinado "par". El uso del fragmento "par" implica que las operaciones en las diferentes secciones (operandos) se ejecutan de forma concurrente. Esto significa que el orden relativo entre el mensaje iniciarDescarga(Video) y iniciarDescarga(Audio) es irrelevante: podrían ocurrir al mismo tiempo o en cualquier orden. V. F.

El siguiente diagrama de secuencia modela un proceso de inicio de sesión (login) durante una compra en una plataforma de comercio electrónico. En el diagrama aparece un fragmento combinado de tipo alt. El fragmento alt funciona como un if simple sin else. Por tanto, este diagrama es incorrecto para representar dos caminos mutuamente excluyentes (éxito o error). Para representar una decisión "A o B", se debería haber usado el fragmento opt (Option). V. F.

Observa la diferencia en las puntas de flecha de los mensajes 1 y 2 en el siguiente diagrama de interacción entre un Cliente y un Servidor. El mensaje 1 (solicitarDatos) es un mensaje Síncrono, lo que implica que el Cliente bloquea su ejecución y espera a que el Servidor termine de procesar. Por el contrario, el mensaje 2 (notificarLog) es Asíncrono, indicando que el Cliente envía el mensaje y continúa inmediatamente con su siguiente tarea sin esperar respuesta. V. F.

En la transición del análisis al diseño, los diagramas de comunicación son preferibles a los diagramas de secuencia para el diseño detallado porque muestran con mayor claridad la duración de cada activación y las interacciones complejas. V. F.

Los patrones de diseño están íntimamente relacionados con el concepto de polimorfismo. V. F.

Un diagrama de máquina de estados puede carecer de estados finales. V. F.

Las siguientes imágenes comparan dos formas de realizar un flujo de actividades en un diagrama de actividad. En el de la izquierda se usa una horquilla, y en el de la derecha se sale de una decisión. Si queremos modelar que la actividad "c" se ejecute cada vez que se complete cualquiera de los flujos anteriores (sin esperar al otro), debemos usar el diagrama de la derecha. El diagrama de la izquierda obliga a esperar a ambos. V. F.

No es posible que un caso de uso no esté iniciado por un actor. V. F.

Un swimlane representa las actividades de un actor del sistema. V. F.

Observa la conexión entre el componente GestorVentas y el componente Inventario. En este diagrama, el componente GestorVentas está ofreciendo una funcionalidad que el componente Inventario necesita para funcionar. Por tanto, Inventario depende de GestorVentas. V. F.

El lenguaje de modelado UML solo representa entidades software, quedando el hardware excluido. V. F.

Analiza el siguiente diagrama de la clase SuperGestor. Presta atención a la naturaleza de sus métodos y su relación lógica. Observando las responsabilidades definidas en los métodos de la clase SuperGestor(persistencia, lógica de negocio y presentación gráfica), podemos afirmar que esta clase posee una Alta Cohesión, ya que centraliza todo el control de la aplicación en un único punto, facilitando la localización del código. V. F.

Se ha diseñado un sistema de simulación de aves. La clase base Ave tiene un método "volar()". Se añade la clase "Pingüino" que hereda de "Ave", pero como los pingüinos no vuelan, se decide lanzar una excepción si se intenta invocar ese comportamiento.Este diseño viola el Principio de Sustitución de Liskov porque un cliente que itere sobre una lista de objetos Ave esperando que todos vuelen, fallará inesperadamente al encontrar una instancia de "Pingüino". Para cumplir LSP, la abstracción "Ave" no debería incluir el método volar si no todas las subclases pueden realizarlo. V. F.

Denunciar Test