Análisis de Sistemas - Módulos 3 y 4 - Preguntero

En el flujo de trabajo de análisis del Proceso Unificado, los trabajadores responsables de producir los artefactos del modelado de análisis son: El Arquitecto del sistema. El Probador del sistema. El Ingeniero de casos de uso. El Administrador del proyecto. El Ingeniero de componentes.

¿Cuáles son las actividades que los trabajadores del análisis deben realizar para producir los distintos artefactos?. Analizar la arquitectura. Analizar un caso de uso. Analizar una clase. Diseñar la arquitectura. Analizar un paquete.

¿Cuáles de los siguientes son artefactos fundamentales que se utilizan en el flujo de trabajo de análisis?. El modelo de casos de uso del sistema. El modelo de análisis del sistema. La clase de análisis del sistema. El modelo de diseño del sistema. La realización de caso de uso de análisis.

Las clases de análisis siempre encajan en uno de los tres estereotipos estandarizados en UML. ¿Cuáles son?. La clase de entidad. La clase de interfaz. La clase de persistencia. La clase de control. La clase de implementación.

Según el material, una realización de caso de uso de análisis posee: Diagramas de clases que muestran sus clases participantes. Un diagrama de despliegue del sistema en sus nodos físicos. Diagramas de interacción de un flujo o escenario particular. Una descripción textual del flujo de sucesos del caso de uso. Un diagrama de componentes del modelo de implementación.

Un paquete de análisis puede contener: Los actores del sistema. Las clases de análisis del sistema. Las realizaciones de casos de uso. Los casos de uso del sistema. Los otros paquetes de análisis.

¿Cómo se estructura el modelo de análisis para organizar sus artefactos?. En paquetes de diseño que agrupan clases concretas del sistema. En subsistemas de implementación derivados de los componentes. En paquetes de análisis que son abstracciones de subsistemas. En paquetes de casos de uso asociados a cada actor del sistema. En colaboraciones que reúnen actores y escenarios del sistema.

La descripción de la arquitectura, dentro del flujo de trabajo de análisis: Contiene el modelo de casos de uso con sus actores y escenarios principales. Contiene el modelo de implementación con sus componentes y nodos físicos. Contiene el diagrama de colaboraciones del modelo de análisis completo del sistema. Contiene una vista del modelo de análisis con los artefactos más significativos para la arquitectura. Contiene el modelo de dominio con las entidades del problema del sistema.

¿Cuál es el objetivo principal de la actividad de análisis dentro del Proceso Unificado?. Refinar y estructurar los requisitos de la captura de requisitos. Definir la implementación definitiva de los componentes del sistema. Documentar el modelo de casos de uso con sus actores y escenarios. Validar los requisitos no funcionales con los usuarios del sistema. Especificar las signaturas de las operaciones de las clases de análisis.

El lenguaje que se utiliza en la actividad de análisis se basa en: Un modelo de datos conceptual denominado modelo de dominio. Un modelo de objetos conceptual, que llamamos modelo de análisis. Un modelo de procesos denominado modelo de casos de uso. Un modelo de componentes denominado modelo de diseño. Un modelo relacional derivado de las entidades del sistema.

En el ciclo de vida del Proceso Unificado (PUD), la actividad de análisis recibe el mayor énfasis durante: Las iteraciones iniciales de la fase de inicio. Las iteraciones finales de la fase de construcción. Las iteraciones iniciales de la fase de elaboración. Las iteraciones posteriores de la fase de transición. Las iteraciones iniciales de la fase de implementación.

Con respecto a los requisitos no funcionales, una clase de análisis: Los incorpora como atributos conceptuales del dominio del problema. Los traduce en signaturas de operaciones de las clases. Los delega a las clases de interfaz y de control del modelo. Los documenta junto con el flujo de sucesos del caso de uso. Los pospone para las actividades de diseño e implementación.

Con respecto a los atributos, una clase de análisis: Define atributos con tipos de lenguajes de programación concretos. Define atributos derivados del modelo de casos de uso del sistema. Define atributos conceptuales, reconocibles en el dominio del problema. Define atributos de carácter físico propios de la implementación. Define atributos sin tipos, que se descartan al llegar al diseño.

¿Cuál es el propósito de las clases de interfaz en el modelo de análisis?. Modelar la información persistente asociada a los hechos del dominio. Coordinar la secuencia de acciones de un caso de uso concreto. Organizar los artefactos del modelo de análisis en piezas manejables. Modelar la interacción entre el actor y el sistema de información. Encapsular los cálculos complejos de la lógica del sistema.

Las clases de entidad se utilizan para modelar: La interacción de comunicación entre el actor y el sistema. La coordinación de los flujos de control del sistema. Los cálculos complejos de la lógica de negocio del sistema. Las ventanas y formularios de la interfaz de usuario. Información de larga vida que es a menudo persistente.

Las clases de control se usan con frecuencia para: Modelar la información persistente de larga vida del dominio. Encapsular el control de un caso de uso concreto. Representar las ventanas y paneles de la interfaz. Aislar los cambios en la interfaz de comunicación. Organizar el modelo de análisis en paquetes manejables.

¿Cómo se identifican, según la lectura, las responsabilidades de una clase de análisis?. Estudiando los diagramas de clases participantes y los diagramas de interacción en los que interviene. Analizando los atributos que la clase encapsula y las cosas derivables o calculables de ellos. Definiendo las operaciones que la clase publicará en el diagrama de clases de diseño. Consultando todos los requisitos especiales capturados en la realización del caso de uso. Reuniendo los roles que deben cumplirse en las realizaciones de casos de uso en las que participan sus objetos.

¿Cuáles son, según la lectura, las responsabilidades de las clases de control?. Las relacionadas con la interacción con el actor, como solicitarle una selección o una confirmación. Las relacionadas con el control de la ejecución del caso de uso y el seguimiento del flujo de eventos. Las relacionadas con los aspectos del dominio del problema, respondiendo a '¿qué conozco?' y '¿qué hago?'. Las relacionadas con estar enterado de los datos privados encapsulados y de los objetos conexos. Las relacionadas con reunir los roles que se cumplen en las realizaciones de casos de uso en que participan.

Respecto de las relaciones entre clases de análisis, la lectura sostiene que: Los enlaces de los diagramas de colaboración implican agregaciones entre las clases participantes. Las generalizaciones deben mantenerse en un nivel conceptual alto y facilitar la comprensión del modelo. Las asociaciones necesarias se determinan recién en el diseño a partir de los diagramas de secuencia. Las agregaciones se identifican únicamente cuando una clase se vuelve difícil de entender. Los enlaces solo pueden convertirse en referencias cuando las clases residen en paquetes distintos.

¿Por qué, según la lectura, en la actividad de análisis se prefiere el diagrama de colaboraciones sobre el diagrama de secuencia?. Porque el objetivo es identificar las operaciones de los objetos y graficar la secuencia cronológica de sus mensajes. Porque los objetos de las clases de análisis no pueden participar en diagramas de secuencia, que son del diseño. Porque el diagrama de secuencia no permite representar los enlaces entre los objetos participantes de la interacción. Porque el objetivo es identificar responsabilidades de los objetos y la secuencia detallada y cronológica se deja para el diseño. Porque los mensajes de los diagramas de colaboración sí se asocian con operaciones definidas en el modelo de análisis.

En el contexto del modelo de análisis, un enlace entre objetos se define como: Un comportamiento que comprende un conjunto de mensajes intercambiados entre objetos dentro de un contexto. Una especificación de comunicación entre objetos que transmite información a la espera de una actividad. Un mensaje proveniente de una instancia de un actor que se envía sobre un objeto de interfaz. Una responsabilidad del objeto receptor cuyo nombre revela el propósito del mensaje recibido. Una conexión semántica entre dos objetos que constituye una instancia de una asociación del modelo.

La actividad 'analizar un caso de uso', responsabilidad del ingeniero de casos de uso, se realiza para: (seleccione todas las opciones correctas). Definir las operaciones que tendrán las clases de análisis participantes en el caso de uso. Identificar las clases de análisis cuyos objetos serán necesarios para llevar a cabo el flujo de sucesos. Graficar la secuencia cronológica de los mensajes entre los objetos del análisis. Distribuir el comportamiento del caso de uso entre los objetos de análisis que interactúan en él. Capturar los requisitos especiales sobre la realización de ese caso de uso en particular.

De acuerdo con las pautas de la lectura, en los diagramas de colaboración del análisis los mensajes: Se asocian con las operaciones de las clases tal como fueron definidas durante el diseño del sistema. Deben revelar el propósito del objeto que los envía, origen de una responsabilidad del objeto receptor. Se grafican únicamente para los flujos alternativos que cambian respecto del curso normal del caso. Deben tener el mismo nombre que el caso de uso que evocan sobre el objeto de interfaz del sistema. Se envían siempre desde una instancia de un actor hacia un objeto de interfaz del sistema.

Según las pautas de la lectura para los diagramas de colaboración, si una clase de análisis identificada no tiene ningún objeto que participe en un diagrama de colaboración: Debe participar igualmente mediante una instancia de actor que la represente en la colaboración. Debe incluirse en la realización del caso de uso como una clase de control del análisis. Debe graficarse con los mensajes de los flujos alternativos correspondientes al caso de uso. Debe eliminarse del modelo, ya que una clase sin objeto participante no se necesita. Debe separarse en clases independientes por el exceso de atributos que acumula.

Para modelar los cursos alternativos de un caso de uso en un diagrama de colaboración, la lectura adopta la convención de: Crear un diagrama de colaboración independiente para cada curso alternativo del caso. Utilizar un diagrama de secuencia adicional para representar cada flujo alternativo. Graficar únicamente los mensajes que cambian respecto del curso normal del caso de uso. Reemplazar por completo los mensajes del curso normal por los del curso alternativo. Describir los flujos alternativos solo de manera textual en la realización del caso de uso.

Según la lectura, una realización de caso de uso-análisis proporciona una traza directa hacia: Las clases de diseño que implementan el comportamiento del caso de uso analizado. Un caso de uso concreto, ya que describe cómo se lleva a cabo y se ejecuta ese caso. El paquete de análisis que contiene las clases participantes de la colaboración. El diagrama de colaboración correspondiente al flujo alternativo del caso de uso. Los requisitos no funcionales capturados durante el análisis del caso de uso.

¿Cuáles son las pautas que indica la lectura para reunir casos de uso en un paquete de análisis? (seleccione todas las opciones correctas). Casos de uso que dan soporte a determinado proceso de negocio del dominio del problema. Casos de uso que comparten el mismo diagrama de colaboración de análisis del caso. Casos de uso que dan soporte a un determinado actor del sistema en análisis. Casos de uso vinculados entre sí por relaciones de generalización, extensión e inclusión. Casos de uso cuyas clases de control pertenecen a una misma clase de entidad del dominio.

El material enumera los propósitos del flujo de trabajo de diseño. ¿Cuál de los siguientes propósitos NO corresponde a dicho flujo de trabajo?. Comprender en profundidad los requisitos no funcionales y las restricciones de la implementación. Identificar las interfaces entre los subsistemas que componen el sistema propuesto. Producir una entrada apropiada como punto de partida para las actividades de implementación. Descomponer los trabajos de implementación en partes manejables para distintos equipos. Especificar el vocabulario del dominio del problema y los actores que participan del sistema.

El material afirma que el modelo de diseño es un modelo físico. ¿Qué significa exactamente esta afirmación?. Que es un plano de la implementación, genérico e independiente de las condiciones particulares de implementación. Que es un plano de la implementación que describe la distribución de la funcionalidad entre los nodos de cómputo. Que es un plano de la implementación que se centra exclusivamente en los requisitos funcionales del sistema. Que es un plano de la implementación, específico para determinadas condiciones y preserva la estructura del análisis. Que es un plano de la implementación que se elabora durante el flujo de trabajo de requerimientos.

Según la lectura, el diseño es la actividad central en qué momento del ciclo de vida: al comienzo de la fase de inicio y durante todas las iteraciones de la fase de elaboración. al final de la fase de elaboración y al comienzo de las iteraciones de la fase de construcción. durante la fase de construcción, cuando la arquitectura ya es estable y los requisitos están bien entendidos. al final de la fase de construcción y durante la mayor parte de las iteraciones de la fase de transición. al comienzo de la fase de elaboración, antes de que la arquitectura del sistema sea estable y sólida.

¿Qué describe el modelo de despliegue según el material?. La realización física de los casos de uso, con el impacto de los requisitos no funcionales. La descomposición del modelo de diseño en subsistemas, interfaces y dependencias entre ellos. La distribución física del sistema y de su funcionalidad entre los nodos de cómputo de la red. Las operaciones que las clases y los subsistemas del diseño ponen a disposición de sus clientes. La traducción directa de las clases de análisis al lenguaje de programación elegido.

¿Qué contiene la descripción de la arquitectura cuando se la considera como vista del modelo de diseño?. La correspondencia de los componentes del software sobre los nodos de cómputo. La distribución de la funcionalidad del sistema entre los nodos de la red. La especificación de las operaciones que son accesibles desde afuera de cada clase. La descomposición del modelo de diseño en subsistemas, sus interfaces y dependencias. La descripción textual de los flujos de eventos de los casos de uso más importantes.

Según el material, ¿cuál es la utilidad principal de las interfaces en el diseño?. Especificar los métodos de las clases tal como se implementan en el lenguaje de programación. Separar la especificación de la funcionalidad, en operaciones, de su implementación, en métodos. Organizar los artefactos del modelo de diseño en piezas más manejables para los equipos. Describir la distribución física de la funcionalidad del sistema entre los nodos de cómputo. Traducir directamente las clases de análisis en clases concretas del lenguaje elegido.

¿Qué afirma la lectura sobre la clase de diseño?. Es una abstracción de un concepto del mundo real elaborada durante el flujo de requerimientos. Es una clase que encapsula secuencias, coordinación de otros objetos o lógica del negocio. Es una abstracción que permite una traducción directa en la implementación del sistema. Es una clase cuyas instancias tienen un proceso o hilo e inician una actividad de control. Es una clase que representa información persistente correspondiente a las tablas de la base de datos.

De acuerdo con el material, el estereotipo de una clase de diseño expresa: el rol de análisis que cumple la clase, ya sea de interfaz, de entidad o de control. el nivel de visibilidad que tendrán los atributos y los métodos en la implementación. la multiplicidad de las asociaciones y agregaciones en las que participa la clase. la tecnología de base de datos que se utilizará para la persistencia de sus instancias. la correspondencia de la clase con una construcción del lenguaje de programación elegido.

¿En qué se diferencia el diagrama de clases de diseño del modelo de objetos del dominio del problema?. En que se elabora a partir de los diagramas de estados de los objetos del sistema. En que describe la distribución física de los componentes del sistema sobre los nodos. En que se centra en los conceptos del mundo real y no en las entidades del software. En que contiene definiciones de las entidades del software y no conceptos del mundo real. En que se confecciona durante el flujo de trabajo de requerimientos, antes del análisis.

¿Cómo se interpreta usualmente una asociación con flecha de navegabilidad en un diagrama de clases de diseño?. Como la visibilidad de los atributos, desde la clase fuente hacia la clase destino. Como la dirección en que fluyen los mensajes entre las instancias de ambas clases. Como la dirección de la herencia entre las clases generales y las clases específicas. Como la multiplicidad que relaciona las instancias de la clase fuente con la clase destino. Como la visibilidad de parámetro que un método recibe desde la clase destino.

En un diagrama de secuencia, ¿cómo se interpreta un mensaje enviado a un multiobjeto?. Como un mensaje que se replica en cada uno de los objetos que contiene la colección. Como un mensaje que solo es válido para los objetos de la clase contenedora de la biblioteca. Como un mensaje que crea un nuevo objeto contenedor dentro de la colección. Como un mensaje que se muestra en la clase contenedora, incluida explícitamente en el diagrama. Como un mensaje destinado al objeto contenedor o colección que agrupa los elementos.

¿Cuál de los siguientes métodos respeta la sintaxis UML recomendada por el material para nombrar métodos en el diagrama de clases de diseño?. calcularRecargo (fechaPago, porcentajeInteres): Double, Double. Double calcularRecargo (Date fechaPago, Double porcentajeInteres). calcularRecargo (fechaPago: Date, porcentajeInteres: Double): Double. calcularRecargo: (Date fechaPago, Double porcentajeInteres) → Double. fechaPago: Date, porcentajeInteres: Double → calcularRecargo: Double.

¿Qué es un objeto activo según el material?. Un objeto que encapsula secuencias y coordina la interacción de otros objetos. Un objeto cuya respuesta ante un mensaje depende del estado en que se encuentre. Un objeto que guarda información persistente en una base de datos relacional. Un objeto que posee un proceso o hilo y puede iniciar una actividad de control. Un objeto de interfaz que depende de la tecnología visual de la aplicación.

El material señala que diseñar clases de control es una tarea delicada. ¿Qué aspectos deben considerarse al diseñarlas? (Seleccioná todos los que correspondan). Los aspectos de distribución de la secuencia en distintos nodos de la red. Los aspectos de persistencia de los datos en tablas de un modelo relacional. Los aspectos de rendimiento, pues puede no justificarse una clase de diseño separada. Los aspectos de visibilidad de los métodos definidos por las interfaces. Los aspectos de transacción, ya que las clases de control suelen encapsular transacciones.

Para identificar las operaciones de una clase de diseño, el material se apoya en varios elementos. ¿Cuáles? (Seleccioná todos los que correspondan). Los atributos de la clase de análisis que tiene traza con la clase de diseño. Las responsabilidades de la clase de análisis que tiene traza con la clase de diseño. Los estados controlados descriptos en el diagrama de estados del objeto de diseño. Las interfaces que la clase necesita proporcionar y sus operaciones asociadas. Las realizaciones de caso de uso-diseño en las que la clase participa activamente.

¿Qué afirma el material sobre los atributos en el pasaje del análisis al diseño?. Cada atributo de análisis se traduce en un único atributo de diseño con su mismo tipo. Un atributo de una clase de análisis puede implicar uno o más atributos en el modelo de diseño. Los tipos de los atributos disponibles están restringidos por el modelo de análisis. Los atributos de una clase muy compleja deben eliminarse para simplificar el diagrama de clases. Los atributos se definen con la sintaxis del lenguaje natural hasta la etapa de implementación.

Si el lenguaje de programación elegido no admite generalización (herencia), el material recomienda: modelar la generalización de todos modos, ya que UML es independiente del lenguaje de implementación. crear una clase de control que coordine a los objetos de las clases más específicas del sistema diseñado. definir una clase asociación entre las dos clases implicadas, con la multiplicidad apropiada. utilizar asociaciones y/o agregaciones para delegar de las clases específicas hacia las más generales. eliminar la jerarquía del modelo y duplicar los atributos y operaciones en cada clase concreta.

Según el material, ¿qué es una realización de caso de uso-diseño?. Una colaboración en el modelo de diseño que describe cómo se realiza un caso de uso en términos de clases de diseño y sus objetos. Una colaboración en el modelo de análisis que describe cómo se realiza un caso de uso en términos de clases de análisis y sus objetos. Una colaboración en el modelo de diseño que describe cómo se organizan los subsistemas y sus interfaces en el sistema. Una colaboración en el modelo de análisis que describe cómo se ejecutan las operaciones definidas en las interfaces. Una colaboración en el modelo de diseño que describe el flujo de control entre los estados de una clase.

Además de gestionar los requisitos no funcionales, una realización de caso de uso-diseño... proporciona la realización lógica de la realización de caso de uso-análisis para la que es trazada. proporciona la realización física de la realización de caso de uso-análisis para la que es trazada. proporciona la implementación en código de la realización de caso de uso-análisis. proporciona la especificación de los estados por los que pasa cada objeto de diseño. proporciona la trazabilidad entre los paquetes de análisis y las capas del sistema.

De los dos diagramas de interacción que proporciona UML, ¿cuál se utiliza en el modelo de diseño según el material?. El diagrama de colaboración, porque permite mostrar los mensajes sin orden temporal. El diagrama de secuencia, porque ofrece una señal clara del flujo de control espacial. El diagrama de colaboración, porque se genera automáticamente desde la herramienta CASE. El diagrama de secuencia, porque destaca la ordenación temporal de los mensajes. Ambos diagramas se utilizan con la misma frecuencia en el modelo de diseño.

Para confeccionar un diagrama de secuencia, ¿cómo se disponen los objetos y los mensajes?. Los objetos se colocan a lo largo del eje “y” y los mensajes a lo largo del eje “x”, de izquierda a derecha. Los objetos se colocan siempre en el centro y los mensajes se distribuyen alrededor de ellos. Los objetos se colocan en la parte superior a lo largo del eje “x” y los mensajes a lo largo del eje “y”, desde arriba hacia abajo. Los objetos se colocan en la parte inferior a lo largo del eje “x” y los mensajes a lo largo del eje “y”, desde abajo hacia arriba. Los objetos se colocan a lo largo del eje “x” y los mensajes a lo largo del eje “y”, sin un orden fijo de sucesión.

¿Qué es la línea de la vida en un diagrama de secuencia?. El rectángulo delgado que representa el período en que un objeto ejecuta una acción. La línea continua vertical que representa las transferencias de mensajes entre objetos. El evento que inicia la interacción entre el objeto y el actor del caso de uso. La línea discontinua horizontal que representa la duración de cada mensaje enviado. La línea discontinua vertical que representa la existencia del objeto a lo largo de un período de tiempo.

En un diagrama de secuencia, ¿cuándo se crea o se destruye un objeto durante la interacción?. Cuando recibe los mensajes “destroy” y “create”, respectivamente. Cuando recibe los mensajes “create” y “destroy”, respectivamente. Cuando su línea de vida se extiende más allá del foco de control. Cuando el objeto envía el último mensaje de la interacción. Cuando el objeto inicia o finaliza la transmisión de sus mensajes.

¿Qué representa el foco de control en un diagrama de secuencia?. El período de tiempo durante el cual un objeto ejecuta una acción, directamente o a través de un procedimiento subordinado. La secuencia de estados por los que atraviesa un objeto durante toda su vida útil. El conjunto de mensajes que un objeto envía hacia los demás objetos que participan. La existencia del objeto a lo largo del período de tiempo que dura la interacción. La operación de la interfaz que recibe los mensajes cualificados del subsistema.

La actividad “diseñar un caso de uso” persigue varios objetivos. ¿Cuáles de los siguientes forman parte de esos objetivos? (Seleccioná todas las que correspondan.). Identificar las clases de diseño y/o subsistemas cuyas instancias son necesarias para llevar a cabo el flujo de sucesos del caso de uso. Garantizar la alta cohesión y el bajo acoplamiento del subsistema resultante. Distribuir el comportamiento del caso de uso entre los objetos de diseño que interactúan en él. Definir los requisitos sobre las operaciones de las clases de diseño y/o subsistemas y sus interfaces. Capturar los requisitos de implementación del caso de uso.

Para identificar las clases de diseño participantes en un caso de uso, ¿cuál es el primer paso indicado por el material?. Estudiar los requisitos especiales e identificar las clases de diseño que los realizan. Asignar las clases identificadas a los distintos ingenieros de componentes. Graficar las clases de diseño participantes en el diagrama de clases del diseño. Definir los requisitos sobre las operaciones de las clases identificadas. Estudiar las clases de análisis participantes e identificar las clases de diseño que tienen una traza hacia esas clases.

¿Cuándo es apropiado, y necesario, cualificar un mensaje con el nombre de la interfaz en un diagrama de secuencia entre subsistemas?. Cuando el subsistema proporciona una única interfaz para todos los actores. Cuando el mensaje proviene de un actor externo al sistema. Cuando se desea mostrar las dependencias entre los subsistemas de diseño. Cuando el subsistema proporciona varias interfaces distintas. Cuando la interfaz es proporcionada por más de un subsistema.

Según el material, ¿qué es una máquina de estados?. Un comportamiento que especifica las secuencias de estados por las que pasa un objeto a lo largo de su vida en respuesta a eventos. Un diagrama que describe la ordenación temporal de los mensajes entre los objetos del diseño. Una condición o situación en la vida de un objeto durante la cual espera un evento. Una relación entre dos estados que se activa cuando ocurre un evento especificado. Una especificación de todas las operaciones que la clase debe implementar.

Según el material, un estado es... la aparición de un estímulo que puede activar una transición entre dos estados del objeto. una relación entre dos estados en la que el objeto realiza ciertas acciones y pasa al segundo cuando ocurre un evento y se cumple una condición. una computación atómica ejecutable que produce un cambio en el estado del modelo o la devolución de un valor. una ejecución no atómica en curso, dentro de la máquina de estados del objeto. una condición o situación en la vida de un objeto de la clase, durante la cual satisface una condición, realiza una actividad o espera un evento.

Según el material, la sintaxis de la especificación que acompaña a una transición de estados es: [condición] / acción ^ evento. [condición] ^ evento / acción. evento ^ [condición] / acción. acción / [condición] ^ evento. [evento] ^ condición / acción.

Para comprobar la consistencia de un diagrama de estados, el material indica que se deben verificar dos aspectos. ¿Cuáles son? (Seleccioná todas las que correspondan.). Que los métodos que figuran en el diagrama de estados, y que provocan los cambios de estado, estén presentes en la definición de la clase. Que las actividades representadas en los estados sean todas ejecuciones atómicas ejecutables. Que cada estado de la clase tenga al menos una transición entrante y una saliente. Que haya al menos un caso de uso en el que cada método que provoca un cambio de estado sea invocado. Que los métodos de la clase que no figuran en el diagrama sean excluidos del modelo de diseño.

Según la definición citada en el material, los subsistemas de diseño son... una forma de organizar los artefactos del modelo de análisis en piezas más manejables. una forma de organizar los requisitos no funcionales del sistema en piezas más manejables. una forma de organizar los artefactos del modelo de diseño en piezas más manejables. una forma de organizar los casos de uso del sistema en piezas más manejables. una forma de organizar los componentes de implementación en piezas más manejables.

Un subsistema de diseño puede contener varios tipos de elementos. ¿Cuáles de los siguientes? (Seleccioná todas las que correspondan.). Las clases de análisis que participan en la realización del caso de uso. Las clases del diseño del modelo de diseño. Las realizaciones de caso de uso del diseño. Las interfaces que exponen sus operaciones. Los subsistemas de diseño de menor nivel.

Respecto de las características que debe reunir un subsistema de diseño, el material sostiene que debe ser... cohesivo, con contenidos fuertemente asociados, y débilmente acoplado, reduciendo las dependencias con otros subsistemas al mínimo. cohesivo, reduciendo las dependencias entre sus contenidos, y débilmente acoplado, con contenidos fuertemente asociados. cohesivo, con contenidos independientes, y fuertemente acoplado, maximizando las dependencias entre subsistemas. débilmente cohesionado, agrupando contenidos disímiles, y fuertemente acoplado, compartiendo todas sus interfaces. cohesivo, con contenidos fuertemente asociados, y fuertemente acoplado, compartiendo interfaces con todos los subsistemas.

Según el material, los subsistemas y el software de base del sistema se organizan en... tres capas, que agrupan los subsistemas y el software de base del sistema. cinco capas, que agrupan los subsistemas y el software de base del sistema. dos capas, que agrupan los subsistemas y el software de base del sistema. cuatro capas, que agrupan los subsistemas y el software de base del sistema. seis capas, que agrupan los subsistemas y el software de base del sistema.

Según la lectura, entre los mecanismos genéricos de diseño e implementación que corresponde estudiar e identificar al comenzar el trabajo de implementación se encuentran: la persistencia de los datos del sistema. la distribución de objetos entre los componentes. la gestión de la interfaz gráfica de usuario. las características de seguridad, detección y reparación de errores. la gestión de las transacciones.

Siguiendo a Jacobson, Booch y Rumbaugh (1999), ¿cuál de las siguientes opciones NO corresponde a uno de los propósitos de la implementación planteados por los creadores del PUD?. planificar las integraciones de sistemas necesarias en cada iteración del proceso. asignar artefactos ejecutables a nodos del diagrama de despliegue del sistema. implementar las clases y subsistemas de diseño definidos previamente. modelar los casos de uso de negocio de la organización en el análisis. probar los componentes individualmente para luego integrarlos, compilarlos y enlazarlos.

En el proceso unificado de desarrollo, la actividad fuerte de la implementación se realiza durante la fase de: construcción. inicio. elaboración. transición. pruebas del sistema.

Según el flujo de trabajo de implementación, ¿cuáles son los trabajadores responsables de los artefactos que se producen en el modelo de implementación?. el arquitecto. el analista de requisitos. el ingeniero de componentes. el administrador de bases de datos. el integrador de sistemas.

¿Cuál de las siguientes opciones NO es una de las actividades que realizan los trabajadores para producir los artefactos del flujo de trabajo de implementación?. implementar la arquitectura. integrar el sistema completo. definir el modelo de casos de uso. implementar una clase de diseño. realizar la prueba de unidad.

¿Cuál de los siguientes artefactos describe cómo los elementos del diseño se implementan en términos de componentes?. el modelo de análisis, que describe el dominio del problema en clases de análisis. el modelo de despliegue, que describe la distribución física del sistema en nodos. la descripción de la arquitectura con la vista del modelo de casos de uso. el plan de integración de construcciones previsto para la iteración. el modelo de implementación, que describe los elementos del diseño en componentes.

Para cada construcción, el plan de integración de construcciones define: la funcionalidad que debe implementar y los subsistemas y componentes afectados. los nodos de la red y los protocolos de comunicación que se utilizarán para el despliegue. el lenguaje de programación y las herramientas de cada componente del sistema. los responsables de cada actividad y el calendario de las pruebas de integración. la arquitectura lógica y las clases de diseño que componen la solución.

Según la lectura, un subsistema de implementación se manifiesta a través del mecanismo de empaquetamiento que provee cada entorno. En el lenguaje Java, ese mecanismo es: un directorio de ficheros, en el lenguaje C++. un proyecto de aplicación, en Visual Basic. un paquete de clases, en el lenguaje Java. una librería dinámica de vínculos del sistema. un archivo binario ejecutable compilado.

Durante la actividad "integrar el sistema", por cada caso de uso que se va a implementar se debe identificar: los atributos y los métodos de cada clase de diseño que participa. su realización de caso de uso correspondiente en el modelo de diseño. los nodos de la red donde se ejecutarán los componentes del caso de uso. los subsistemas y clases de diseño que participan en la realización del caso. los subsistemas y componentes de implementación que siguen la traza de las clases de diseño.

Entre las tareas de la actividad "implementar una clase" se encuentra: asignar la clase a un nodo del modelo de despliegue de la arquitectura. comprobar que el componente proporciona las mismas interfaces que la clase de diseño. definir las construcciones en las que participará la clase en la iteración. documentar la realización de caso de uso correspondiente a la clase. verificar todos los caminos posibles del código fuente de la clase.

¿Qué verifican las pruebas de unidad de estructura, también llamadas de "caja blanca"?. el comportamiento externo de la unidad observable para un conjunto de entradas. que el componente proporcione las mismas interfaces que la clase de diseño. la correcta integración de la unidad con el resto de los componentes del sistema. la implementación interna de la unidad, cubriendo todos los caminos posibles del código. la asignación de la unidad a los nodos definidos en el modelo de despliegue.

Según la lectura, el orden aconsejado para implementar las clases y subsistemas, y realizar idealmente las pruebas de unidad, es: de los menos a los más acoplados. de los más a los menos acoplados. de los más complejos a los más simples. según la prioridad de los casos de uso que los requieren. según el orden alfabético de los subsistemas.

¿Qué caracteriza a la arquitectura cliente/servidor de dos capas según la lectura?. la funcionalidad de la base de datos se distribuye entre todas las capas. la lógica del negocio se elimina y las capas solo intercambian datos. la lógica del negocio se mueve hacia alguna de las otras dos capas. las tres capas se ejecutan físicamente en un único nodo. el cliente contiene la aplicación y la base de datos simultáneamente.

La lectura denomina "diseño arquitectónico" a: el modelo que describe la distribución física de la funcionalidad del sistema entre los nodos. la asignación de los modelos de requerimientos esenciales hacia una tecnología específica. la descomposición del sistema en subsistemas de implementación y sus interfaces definidas. el proceso de identificación de los nodos y las configuraciones de red necesarias del sistema. el proceso de diseño inicial que identifica los subsistemas y establece el marco de control y comunicación.

Según Roger Pressman (2006), la arquitectura del software de un sistema de cómputo es: el mapeo de los requerimientos esenciales de la fase de análisis del sistema hacia una arquitectura tecnológica elegida. la estructura o las estructuras del sistema, con componentes de software, propiedades visibles externamente y relaciones entre ellos. el proceso de diseño inicial que identifica los subsistemas del sistema y establece el marco de control entre ellos. el modelo de objetos que describe la distribución de la funcionalidad del sistema entre los nodos de cómputo disponibles. la organización de los elementos del modelo de implementación en partes manejables y procesables del proceso de desarrollo.

De acuerdo con la definición de la lectura, un diagrama de despliegue muestra: La configuración de los nodos de procesamiento y de los artefactos que residen en ellos. La configuración de los componentes de software y de las interfaces que exportan e importan. La configuración de los nodos de procesamiento y de los mensajes que intercambian entre sí. La configuración de los paquetes de diseño y de las clases que contiene cada paquete. La configuración de los subsistemas lógicos y de las dependencias entre sus artefactos.

Según la lectura, un diagrama de despliegue, normalmente, contiene: nodos de procesamiento. componentes estereotipados como tablas. interfaces exportadas e importadas. relaciones de dependencia y asociación. actores y casos de uso.

Cuando los nodos se muestran en forma de “descriptor” y se agrupan en paquetes, el diagrama de despliegue resultante: representa cada instancia de nodo junto con los artefactos que residen en ella. detalla las interfaces que cada nodo del sistema exporta hacia los demás. muestra la secuencia temporal de las conexiones establecidas entre los nodos. indica solamente los tipos de nodos y sus conexiones, sin representar cada nodo. exige representar por separado los paquetes de análisis y de diseño del sistema.

De acuerdo con la lectura, el diagrama de despliegue se puede utilizar para modelar: sistemas embebidos que interactúan con el mundo físico. el código fuente y las dependencias de compilación de los archivos. sistemas cliente/servidor con separación de intereses. las bases de datos físicas con componentes estereotipados como tablas. sistemas completamente distribuidos con varios niveles de servidores.

Según la lectura, una característica de los sistemas ampliamente o totalmente distribuidos es que: se basan en una clara separación entre la interfaz de usuario y los datos persistentes. incluyen varios niveles de servidores y, a menudo, varias versiones de artefactos. están controlados por estímulos externos provenientes del mundo físico. se modelan mediante componentes estereotipados como tablas de datos. mantienen una única versión estable de cada artefacto de software.

De acuerdo con la lectura, un componente es: una parte lógica y no reemplazable de un sistema que existe en el modelo de análisis. una clase de análisis que representa la interfaz con el usuario del sistema. una colección de nodos de procesamiento y de artefactos que residen en ellos. una parte física y permanente de un sistema que se define en la vista de casos de uso. una parte física y reemplazable de un sistema que existe a nivel de la plataforma de implementación.

Un diagrama de componentes modela un conjunto de componentes y sus relaciones. Según la lectura, las relaciones que pueden intervenir en un diagrama de componentes son: dependencia. generalización. inclusión. asociación. realización.

De acuerdo con la lectura, una versión es: una copia de seguridad de los archivos de código fuente de un proyecto. la instancia concreta de un componente que se despliega en un nodo de procesamiento. un conjunto de artefactos relativamente consistentes y completos que se entrega al usuario. la realización concreta de un esquema lógico de base de datos relacional. el valor de etiquetado que indica la fecha de la última modificación.

Según la lectura, una base de datos física puede ser vista como: la realización concreta de un esquema de base de datos. el esquema lógico del modelo de análisis del sistema. la colección de nodos que almacenan los datos persistentes. la versión ejecutable que se entrega al usuario final. el conjunto de interfaces que importan y exportan las tablas.

En los sistemas adaptables, los componentes pueden migrar de un nodo a otro. Según la lectura, ¿con qué propósito lo hacen?. para actualizar la interfaz de usuario de los clientes del sistema. para equilibrar la carga o la recuperación de fallos. para reflejar los cambios en el esquema lógico de los datos. para documentar las decisiones sobre las partes físicas del sistema. para mantener la coherencia entre el código y las versiones.

Según Sommerville (2005), el papel de la verificación dentro del proceso de V & V comprende: comprobar que el software satisfaga las expectativas del cliente, aun cuando difieran de la especificación. asegurar que el sistema se ajuste a los propósitos previstos, sin exigir que esté libre de defectos. comprobar que el software esté de acuerdo con su especificación y cumpla los requerimientos funcionales y no funcionales. garantizar que el software no contenga defectos durante la etapa de implementación del sistema. verificar que el sistema pueda ser instalado en la plataforma del cliente y funcione correctamente.

La validación, a diferencia de la verificación, se ocupa de: comprobar que el sistema cumpla los requerimientos funcionales y no funcionales que fueron especificados. asegurar que el software cumpla las expectativas del cliente mostrando que hace lo que el usuario espera. verificar que el código fuente del programa se corresponda con los diagramas de diseño elaborados. confirmar que cada construcción haya sido probada con los datos de prueba definidos. garantizar que el plan de pruebas cubra todos los escenarios posibles de cada caso de uso.

Dentro del proceso de V & V, ¿cuáles de las siguientes técnicas se consideran estáticas porque no requieren que el sistema se ejecute? (Seleccioná dos). Las pruebas del software ejecutadas con datos de prueba sobre una implementación. Las inspecciones del software sobre los requerimientos, los diagramas de diseño y el código fuente. Las pruebas de aceptación que se realizan en el ambiente de operación del cliente. Los análisis automatizados del texto de un sistema o de sus documentos asociados. Las pruebas de tensión que sobrecargan el sistema para revelar sus debilidades.

La estrategia incluida en el plan de prueba define, entre otras cosas: el flujo de eventos de cada caso de uso con los valores de entrada que deben utilizarse en la prueba. las condiciones bajo las cuales debe ejecutarse cada caso de prueba definido para el sistema. el tipo de pruebas por iteración, sus objetivos, el nivel de cobertura y el porcentaje esperado de resultados. las instrucciones para interactuar con la herramienta de automatización de pruebas del sistema. la interacción interna de los componentes que implementan la realización del caso de uso definido.

Según el material, un defecto es: un error de codificación cometido por un ingeniero durante la implementación. una falla detectada por el cliente durante la fase de transición del sistema. una diferencia entre el comportamiento esperado y el comportamiento real del software. un problema de diseño que impide que la construcción supere las pruebas de integración. una anomalía del sistema que se registra como síntoma de un problema a controlar y resolver.

El procedimiento de prueba es el artefacto del flujo de trabajo de prueba que: especifica qué probar, indicando la entrada o resultado y las condiciones bajo las que ha de probarse. automatiza uno o varios procedimientos de prueba o partes de ellos que se ejecutan repetidamente. especifica cómo realizar uno o más casos de prueba, con instrucciones para la persona o para la herramienta. describe las estrategias, los recursos y la planificación de la prueba para cada iteración. describe cómo se prueban los componentes ejecutables del modelo de implementación.

Un caso de prueba especifica una forma de probar el sistema. Esta especificación incluye: las instrucciones paso a paso para que una persona ejecute la prueba de forma manual. las estrategias y los recursos necesarios para planificar la prueba de la iteración. los componentes de prueba automatizados que realizan el procedimiento de prueba. las anomalías del sistema que deben registrarse y controlarse durante la prueba. la entrada o resultado con la que se ha de probar y las condiciones bajo las que ha de probarse.

En el flujo de trabajo de prueba del Proceso Unificado, la prueba de caja negra sobre un caso de uso: verifica la interacción interna de los componentes que implementan la realización del caso de uso del sistema. verifica el resultado de la interacción entre actores y sistema, satisfaciendo las precondiciones y postcondiciones. automatiza el procedimiento de prueba mediante una herramienta de automatización de pruebas del sistema. intenta provocar que el sistema falle utilizándolo deliberadamente de forma incorrecta. identifica problemas del sistema cuando hay recursos insuficientes o competencia por los recursos.

Entre las pruebas de sistema planteadas en el flujo de trabajo de prueba se encuentran: (Seleccioná tres). Las pruebas de instalación, que verifican que el sistema pueda instalarse en la plataforma del cliente. Las pruebas unitarias, que verifican el comportamiento de cada clase de diseño por separado. Las pruebas negativas, que intentan provocar que el sistema falle para revelar sus debilidades. Las pruebas de caja blanca que verifican la realización de caso de uso de diseño. Las pruebas de aceptación, que se realizan en el ambiente de operación del cliente.

Las pruebas de tensión o de estrés tienen por objetivo: comprobar el funcionamiento del sistema en diferentes configuraciones de red. verificar que el sistema pueda ser instalado en la plataforma y funcione correctamente. provocar que el sistema falle mediante un uso deliberadamente incorrecto del mismo. identificar problemas cuando hay recursos insuficientes o competencia por los recursos. validar en el ambiente de operación que el sistema cumpla las expectativas del cliente.

Un componente de prueba es el artefacto que: especifica cómo realizar uno o más casos de prueba mediante instrucciones para la persona o la herramienta. describe las estrategias, los recursos y la planificación de la prueba para cada iteración. registra las anomalías del sistema que los desarrolladores deben controlar y resolver. automatiza uno o varios procedimientos de prueba o partes de ellos mediante código o una herramienta. especifica la entrada o resultado con la que se ha de probar y las condiciones de ejecución.

Indique cuáles de los siguientes elementos forman parte de los pasos que Eric Braude (2003) propone para confeccionar un plan de pruebas de unidades: Diseñar un conjunto de pruebas para cada unidad que se selecciona. Determinar el alcance de las pruebas unitarias con especial cuidado. Refinar el plan general antes de ejecutar todos los procedimientos de prueba. Decidir la filosofía de las pruebas de unidades que se van a realizar. Registrar el tiempo, la cuenta de defectos, su tipo y su fuente de origen.

Los casos de prueba de regresión permiten asegurar, al finalizar una iteración, que: Todos los defectos detectados durante la iteración fueron efectivamente corregidos. El sistema cumple los objetivos de calidad de integración fijados en el plan de prueba. No se ha estropeado ninguna parte del sistema que antes funcionaba bien y ya se probó. Todos los casos de uso de la iteración se ejecutan en paralelo sin interferencias. Los procedimientos de prueba automatizados cubren la totalidad de las sentencias.

En el proceso de desarrollo unificado, las pruebas de unidad se realizan en: El flujo de trabajo de requerimientos, junto con las pruebas de aceptación del cliente del sistema. El flujo de trabajo de prueba, al igual que las pruebas de integración y de sistema del proceso. El flujo de trabajo de análisis, durante todas las iteraciones de la fase de concepción. El flujo de trabajo de implementación, al igual que las pruebas de integración y de sistema. El flujo de trabajo de implementación; las de integración y de sistema, en el flujo de prueba.

De acuerdo con el material, la parte más pequeña a la que se aplica una prueba de unidad es: El módulo, que en el caso de la orientación a objetos se refiere a una clase completa. El paquete, que agrupa las clases relacionadas que se prueban en su conjunto. La construcción, que reúne el código de varios desarrolladores del proyecto en un todo. El subsistema, que combina paquetes para validar la funcionalidad global de la aplicación. La función, que en orientación a objetos se refiere a los métodos de una clase.

En sistemas orientados a objetos, además de la evaluación estructural y de la evaluación de especificación, también se necesita ejecutar: Una evaluación de regresión que reejecuta las pruebas de las iteraciones anteriores del proyecto. Una evaluación de volumen que somete las operaciones del sistema a grandes cantidades de datos. Una evaluación basada en estado, sobre los estados encapsulados y la interacción de operaciones. Una evaluación de aceptación que valida el comportamiento frente a la organización del cliente. Una evaluación de integración que prueba la interacción entre las clases de un mismo paquete.

La partición de equivalencia consiste en: Dividir los datos de entrada en subconjuntos: el éxito de una entrada implica el probable éxito de las demás. Ejecutar cada sentencia del programa al menos una vez para alcanzar la cobertura de sentencias necesaria. Establecer el objeto en su estado inicial y verificar cada transición del estado ante cada evento de la prueba. Seleccionar al azar las combinaciones de métodos para cubrir las secuencias de la clase. Dividir los datos de salida en clases de equivalencia para estimar el tiempo medio entre fallas del sistema.

Respecto de las coberturas de sentencias y de decisiones, el material sostiene que: La cobertura de decisiones por sí sola es suficiente para asegurar que el programa sea totalmente correcto. La cobertura de sentencias asegura que cada rama de cada decisión se recorra al menos una vez en las pruebas. La cobertura de sentencias es necesaria, pero de ninguna manera suficiente para asegurar la corrección del programa. La cobertura de decisiones se limita a los ciclos FOR, ya que los while siempre pueden enumerarse por completo en las pruebas. Las coberturas de sentencias y de decisiones garantizan juntas la corrección total del programa probado.

Para evitar la integración "explosiva", el proceso de desarrollo unificado: Completa todos los módulos individuales de software antes de comenzar la integración. Pospone la integración hasta que todas las construcciones estén completamente terminadas. Realiza una única integración al final del proceso y luego ejecuta todas las pruebas. Practica la integración continua con múltiples iteraciones desde etapas tempranas. Integra exclusivamente los casos de uso más pequeños al comienzo del proyecto.

Las dificultades de integrar las aplicaciones resaltan la importancia de diseñar unidades como clases y paquetes que: Agrupen la mayor cantidad de propósitos posible para facilitar su integración. Se centren en un propósito lo más que se pueda, disminuyendo sus interfaces mutuas. Se centren en un único propósito y aumenten sus interfaces para lograr bajo acoplamiento. Mantengan propósitos independientes sin considerar el acoplamiento hasta la prueba. Compartan la mayor cantidad de interfaces posibles para reducir la cohesión.

En las pruebas de interacción entre casos de uso, las matrices CRUD se utilizan principalmente para: Definir los casos de prueba de sistema priorizando las combinaciones de casos de uso que funcionan en paralelo. Verificar las transiciones de estado de cada objeto entre los casos de uso de una construcción. Medir los defectos creados, leídos, actualizados y borrados en cada iteración del proyecto de pruebas. Asegurar que cada objeto del sistema sea creado y borrado por el mismo caso de uso de forma consistente. Buscar objetos compartidos entre casos de uso, como leídos o borrados en uno y creados en otro.

Para calcular el MTBF (tiempo medio entre fallas), el material describe el siguiente procedimiento: Ejecutar la aplicación con todos los escenarios posibles y calcular la mediana de los tiempos de respuesta obtenidos. Registrar el tiempo de cada prueba con resultado esperado y promediar los tiempos de recuperación. Contar los defectos detectados en cada iteración del proyecto y dividirlos por el tiempo total de las pruebas. Definir qué es una falla, ejecutar la aplicación con un escenario aleatorio hasta el fallo y promediar los tiempos. Ejecutar la aplicación en el entorno del cliente y medir el tiempo promedio de cada transacción.

De la siguiente lista, indique cuáles son tipos de pruebas de sistema mencionados en el material: Prueba de seguridad. Prueba de accesibilidad. Prueba de eficiencia. Prueba de recuperabilidad. Prueba de configurabilidad.

Indique cuáles de los siguientes criterios corresponden a las pruebas de utilidad: Accesibilidad. Rapidez de respuesta. Seguridad. Recuperabilidad. Comprensión.

Una diferencia clave entre las pruebas de aceptación y las pruebas de sistema es que en las de aceptación: La organización desarrolladora diseña y ejecuta las pruebas sin intervención del cliente. Se ejecutan en el entorno de desarrollo para garantizar la reproducibilidad de los resultados. La organización del cliente es testigo y se ejecutan en la plataforma donde van a operar. Solo se prueban los requerimientos funcionales de la aplicación que se entrega al cliente. El desarrollador obtiene la declaración de entrega del cliente al inicio del proyecto.

De acuerdo con la actividad de evaluación de la prueba, las dos métricas fundamentales que se observan son: La cobertura de decisiones y la cobertura de sentencias del programa. La compleción de la prueba, con los casos ejecutados y el código probado. El tiempo medio entre fallas (MTBF) de la aplicación probada. La fiabilidad, basada en las tendencias de defectos detectados. La cantidad de casos de uso del sistema probados al finalizar la iteración.