Cuestiones
ayuda
option
Mi Daypo

TEST BORRADO, QUIZÁS LE INTERESETEST FIS TODOS LOS TEMAS

COMENTARIOS ESTADÍSTICAS RÉCORDS
REALIZAR TEST
Título del test:
TEST FIS TODOS LOS TEMAS

Descripción:
TEST HASTA TEMA 11 FIS (COMPLETO)

Autor:
Fatema
(Otros tests del mismo autor)

Fecha de Creación:
24/06/2022

Categoría:
Informática

Número preguntas: 653
Comparte el test:
Facebook
Twitter
Whatsapp
Comparte el test:
Facebook
Twitter
Whatsapp
Últimos Comentarios
No hay ningún comentario sobre este test.
Temario:
No todas las economías de los países desarrollados dependen del software V F.
La mayoría de los sistemas están controlados por el software V F.
El software puede ser utilizado como un elemento diferenciador entre distintas compañías V F.
Los problemas que se presentan en la construcción de grandes sistemas software son simples versiones a gran escala de los problemas de escribir pequeños programas V F.
Una de las razones por las que fracasa el software es por la baja calidad de los sistemas construidos V F.
Una de las razones por las que fracasa el software es por la baja productividad en desarrollo, tiempo y/o recursos consumidos V F.
Los cambios de requisitos en un proyecto software NO influyen en el desarrollo del mismo V F.
Para solucionar los problemas asociados a la baja calidad del sistema construido, podemos definir modelos entregables que permitan comprender mejor el sistema y ayuden a incrementar las posibilidades de éxito V F.
Para solucionar los problemas asociados a la baja calidad del sistema construido podemos definir modelos de desarrollo de software a partir de los cuales se instancian procesos que subdividen los pasos a realizar para el desarrollo del software V F.
Un proceso es una instancia particular de un modelo de desarrollo adaptado a una organización y un proyecto de desarrollo concreto V F.
El software está formado por: Instrucciones, estructuras de datos y máquinas para la ejecución de las instrucciones y estructuras de datos. V F.
El software tiene doble función, de producto y de servicio V F.
El software es un producto pero no una herramienta para desarrollar productos V F.
Tanto el hardware como el software tienen un enfoque lógico V F.
El software tiene un carácter lógico V F.
El software se fabrica, no se desarrolla en un sentido clásico. V F.
El software se desgasta V F.
La mayoría del software se construye para uso individualizado V F.
Software de sistemas: conjunto de programas escritos para dar servicio a otros programas V F.
Software de aplicación: programas independientes que resuelven una necesidad de negocios específica V F.
Software científico y de ingeniería: aplicaciones en astronomía, vulcanología, análisis de tensiones en automóviles, etc V F.
Software empotrado: reside dentro de un producto o sistema y se usa para el control de características específicas de ese producto V F.
Software de línea de productos: puede estar centrado en un mercado limitado (p.e. control del inventario de productos) o en un mercado masivo de consumidores V F.
Aplicaciones Web y Móviles: concentra un amplio abanico de aplicaciones, tanto las basadas en el uso del navegador como aquellas desarrolladas para dispositivos móviles V F.
Software de inteligencia artificial: Se caracteriza por el uso de algoritmos no numéricos para la resolución de problemas complejos V F.
Software de sistemas: programas independientes que resuelven una necesidad de negocios específica V F.
Software científico y de ingeniería: Se caracteriza por el uso de algoritmos no numéricos para la resolución de problemas complejos V F.
Software empotrado: programas independientes que resuelven una necesidad de negocios específica V F.
Software de aplicación: conjunto de programas escritos para dar servicio a otros programas V F.
Software de aplicación: reside dentro de un producto o sistema y se usa para el control de características específicas de ese producto V F.
El software heredado está caracterizado por su longevidad y por ser críticos en los negocios V F.
El software heredado tiene diseños imposibles de entender, código complicado, escasa documentación, casos de prueba no archivados V F.
El software heredado tiene diseños simples, código sencillo y está bien documentado V F.
El software heredado no tiene porqué evolucionar V F.
El software heredado debe adaptarse para satisfacer las necesidades de nuevos ambientes o nuevas tecnologías V F.
Los mitos suelen ser aceptados puesto que contienen algún elemento de verdad V F.
Los mitos no nos encaminan a decisiones erróneas V F.
Es un mito de gestión y administración: Tenemos las computadoras más modernas con lo que nuestro software será de mayor calidad V F.
Es un mito del cliente: Una declaración inicial de objetivos es suficiente para comenzar a escribir programas, los detalles se pueden refinar después V F.
Es un mito del desarrollador: Una vez escribimos el programa y funcionando nuestro trabajo ha terminado V F.
Es un mito del desarrollador: Los requisitos del proyecto son cambiantes pero éstos pueden ser ajustados con facilidad dada la flexibilidad del software V F.
Es un mito del cliente: Lo único que se entrega es el programa funcionando V F.
Es un mito de gestión y administración: La ingeniería del software obligará a crear una voluminosa e innecesaria documentación que hará que el proceso de desarrollo sea más lento V F.
Es un mito del desarrollador: Tenemos las computadoras más modernas con lo que nuestro software será de mayor calidad V F.
Es necesario un esfuerzo concertado para entender el problema antes de desarrollar una aplicación de software V F.
El diseño no es una actividad crucial en el desarrollo software V F.
El software no siempre debe tener alta calidad V F.
El software debe facilitar el mantenimiento V F.
Según la IEEE, 1993 la Ingeniería del Software es: El establecimiento y uso de principios fundamentales de la ingeniería con objeto de desarrollar de forma económica software que sea fiable y que trabaje eficientemente en máquinas reales V F.
Según Según Fritz Bauer, 1969 La Ingeniería del Software es: La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software; es decir, la aplicación de la ingeniería al software V F.
La tecnología de capas está formada por: Herramientas, modelos, procesos y compromisos con la calidad V F.
La tecnología de capas está formada por: Herramientas, métodos, procesos y compromisos con la calidad V F.
Aunque existen herramientas de automatización software, hoy en día es difícil automatizar más V F.
La automatización de la creación software es sencilla y existen muchas herramientas para ello V F.
El modelo en cascada es el paradigma más moderno V F.
Las etapas del modelo en cascada son: Comunicación, planificación, construcción y despliegue V F.
Una ventaja del modelo en cascada es que es un modelo secuencial y el desarrollo software es altamente lineal V F.
Una desventaja del modelo en cascada es que es un modelo secuencial V F.
En el modelo en cascada el cliente dispondrá de versiones de prueba en etapas tempranas del proyecto V F.
En el modelo incremental: el producto se divide en incrementos de tal modo que cada entrega es un producto operativo pero incompleto V F.
En el modelo incremental el cliente no dispondrá de ninguna versión hasta etapas muy avanzadas del proyecto V F.
Los incrementos se estructuran de modo que los últimos incluyan los requisitos más importantes del producto V F.
Una vez ha comenzado el desarrollo de un incremento, sus requisitos se pueden modificar en cualquier momento V F.
En el modelo incremental los clientes pueden hacer uso de un software con las características primordiales en etapas tempranas V F.
El modelo incremental disminuye el riesgo de que el proyecto falle se con respecto al modelo en cascada V F.
El modelo DRA es una estrategia ágil V F.
El modelo DRA es una aplicación a alta velocidad del modelo en cascada V F.
El modelo DRA es una aplicación a alta velocidad del modelo incremental V F.
El modelo DRA se basa en la utilización de componentes ya existentes y en la creación de componentes reutilizables V F.
El modelo incremental está especialmente diseñado para el desarrollo de aplicaciones para negocios que hacen un uso intensivo de datos. V F.
Una desventaja del modelo DRA es que gran parte del código no está implementado V F.
En el modelo DRA es sencillo organizar a todos los equipos en sistemas grandes V F.
El prototipado tiene como utilidad el estudio de la interfaz hombre-máquina, para decidir qué debe mostrarse y qué debe introducir el usuario V F.
El diseño basado en componentes suele tener limitada la capacidad de procesamiento de datos, tener un pobre rendimiento y una limitada calidad V F.
Un prototipo suele tener limitada la capacidad de procesamiento de datos, tener un pobre rendimiento y una limitada calidad V F.
Las etapas del prototipado son: Realizar un análisis inicial Definir los objetivos del prototipo Repetir: Especificar el prototipo Construir el prototipo Evaluar el prototipo y recomendar cambios V F.
Las etapas del modelo en cascada son: Realizar un análisis inicial Definir los objetivos del prototipo Repetir: Especificar el modelo Construir el modelo Evaluar el modelo y recomendar cambios V F.
El prototipado ayuda a encontrar requisitos que se hayan podido pasar por alto V F.
Una desventaja del prototipado es que el cliente puede percibir el prototipo como parte del sistema V F.
Una desventaja del prototipado es que se puede apartar la atención de los asuntos funcionales para centrar la atención en temas de la interfaz V F.
El prototipado no requiere una importante implicación del usuario V F.
En el modelo en espiral existen fases como el análisis y el diseño V F.
A diferencia del resto de modelos, el modelo en espiral tiene un análisis de riesgos de manera explícita V F.
El único modelo que no tiene un análisis de riesgos de manera explícita es el modelo en espiral V F.
La principal característica del modelo incremental es la reusabilidad V F.
Un incremento se diferencia del sistema final en que se encuentra inacabado y tiene una construcción menos elástica V F.
La principal característica del modelo basado en componentes es la reusabilidad V F.
Las etapas del modelo basado en componentes son: Análisis de componentes Modificación o adaptación de requisitos Diseño del sistema con reusabilidad Desarrollo e integración V F.
El desarrollo basado en componentes no necesita obligatoriamente una biblioteca de componentes V F.
El modelo DRA reduce la cantidad de código a generar y reduce los riesgos y costes V F.
El modelo basado en componentes reduce la cantidad de código a generar y reduce los riesgos y costes V F.
Una desventaja del modelo basado en componentes es que los desarrolladores no pueden garantizar la calidad de todo el producto. Este tiene dependencias externas V F.
Una desventaja del modelo en espiral es que los desarrolladores no pueden garantizar la calidad de todo el producto. Este tiene dependencias externas V F.
El modelo de métodos formales conduce a la especificación matemática del software V F.
El modelo de métodos formales garantizan un software prácticamente libre de errores V F.
El modelo de métodos formales suele ser caro y consumir mucho tiempo V F.
El proceso unificado nace a partir de la unificación de los métodos de Booch, Jacobson y Rumbaugh V F.
El modelo en espiral dio lugar al al lenguaje UML V F.
El UML proporciona una serie de diagramas que servirán como herramienta de especificación durante el proceso de desarrollo que propone el proceso unificado V F.
El UML proporciona una serie de herramientas que servirán como diagramas de especificación durante el proceso de desarrollo que propone el proceso unificado V F.
El proceso unificado está basado en el modelo en espiral V F.
El proceso unificado está basado en el modelo en incremental V F.
Cada incremento debe aportar nuevas funcionalidades V F.
Las fases del proceso unificado son: Concepción, elaboración, construcción y transición V F.
Las fases del proceso unificado son: Concepción, construcción y transición V F.
Proceso unificado: Elaboración: Implementación iterativa del resto de requisitos de menor riesgo y elementos más fáciles, preparación para la puesta en marcha V F.
Proceso unificado: Transición: Visión aproximada, análisis del negocio, alcance, estimaciones imprecisas V F.
SCRUM es un modelo basado en componentes V F.
La programación extrema (XP) es una estrategia ágil V F.
SCRUM es una estrategia ágil V F.
Lean Development es un modelo en espiral V F.
El método más adecuado es el espiral V F.
El método más adecuado es el Proceso Unificado V F.
Ningún método funciona de manera universal V F.
El modelo a utilizar depende de: El tipo de proyecto La cultura existente en la empresa El conocimiento de herramientas asociadas a las metodologías V F.
Los requisitos son la base para el diseño y la implementación en la ingeniería de software V F.
Los requisitos son una lista completa de las propiedades específicas y la funcionalidad que debe tener la aplicación, expresada con todo detalle V F.
Los errores más costosos de reparar se dan en la fase de diseño e implementación V F.
Ingeniería de Requisitos: Proceso para establecer los servicios que el cliente requiere de un sistema junto con las restricciones de funcionamiento bajo las que será desarrollado V F.
Ingeniería de Requisitos: Podemos definirlo como el proceso de entender y documentar qué es lo que debe hacer un sistema V F.
Un requisito es conjunto de propiedades o restricciones definidas con precisión, que un sistema software debe satisfacer V F.
Un requisito es un proceso para establecer los servicios que el cliente requiere de un sistema junto con las restricciones de funcionamiento bajo las que será desarrollado V F.
Un requisito de alto nivel se irá concretando a lo largo del proceso V F.
Un requisito de alto nivel es una función matemática perfectamente definida V F.
Los requisitos de alto nivel se definen al inicio del proceso, no se pueden concretar a lo largo del mismo V F.
Análisis de requisitos: Podemos definirlo como el proceso de entender y documentar qué es lo que debe hacer un sistema V F.
Análisis de requisitos: Podemos definirlo como el proceso de entender y documentar cómo debe hacerse algo en un sistema V F.
Análisis de Requisitos: Documento final entregable donde deben quedar perfectamente numerados, especificados, y detallados todos y cada uno de los requisitos que debe reunir un sistema V F.
Especificación de Requisitos: Documento final entregable donde deben quedar perfectamente numerados, especificados, y detallados todos y cada uno de los requisitos que debe reunir un sistema V F.
Especificación de Requisitos: Proceso para establecer los servicios que el cliente requiere de un sistema junto con las restricciones de funcionamiento bajo las que será desarrollado V F.
Existen solo dos tipos de requisitos: funcionales y de facilidad de uso V F.
Requisitos funcionales: describen lo que hace un sistema o lo que se espera que haga; es decir, su funcionalidad V F.
Requisitos no funcionales: describen aspectos del sistema que están relacionados con el grado de cumplimiento de los requisitos funcionales V F.
Requisitos de facilidad de uso: permiten asegurar que existe un buen acoplamiento del sistema desarrollado con los usuarios V F.
Requisitos funcionales: permiten asegurar que existe un buen acoplamiento del sistema desarrollado con los usuarios V F.
Requisitos no funcionales: describen lo que hace un sistema o lo que se espera que haga; es decir, su funcionalidad V F.
Requisitos de facilidad de uso: describen aspectos del sistema que están relacionados con el grado de cumplimiento de los requisitos funcionales V F.
Las restricciones que tienen en cuenta los requisitos no funcionales son: Criterios de rendimiento, Previsión del volumen de datos y Consideraciones de seguridad V F.
Algunas de las medidas de los requisitos funcionales son: Velocidad, tamaño, facilidad de uso, robustez... V F.
La facilidad de uso es el grado en que usuarios específicos pueden conseguir objetivos específicos dentro de un entorno determinado, de forma eficaz, eficiente, confortable y aceptable V F.
Para satisfacer los requisitos de facilidad de uso no hace falta reunir información sobre las características de los usuarios ni las tareas que realizarán V F.
Las técnicas de búsqueda de requisitos son: Lecturas preparatorias, entrevistas, cuestionarios y muestreo de documentos V F.
Las lecturas preparatorias buscan entender bien la organización así como los objetivos de negocio V F.
Las lecturas preparatorias buscan obtener un profundo conocimiento de los objetivos de la organización, los requisitos de los usuarios y los roles de cada persona V F.
Las lecturas preparatorias no ayudan a identificar requisitos, solo sirven de familiarización V F.
La desventaja de las lecturas preparatorias es que los documentos pueden estar desactualizados V F.
Las lecturas preparatorias son óptimas cuando el analista no está familiarizado con la organización y en etapas iniciales de la investigación V F.
Las lecturas preparatorias ofrece una idea real de cómo funciona el sistema V F.
Entrevistas: Obtener un profundo conocimiento de los objetivos de la organización, los requisitos de los usuarios y los roles de cada persona V F.
Las entrevistas permiten obtener el punto de vista de un gran número de personas de manera que permita su análisis estadístico V F.
Las entrevistas requieren de una buena planificación, buenas habilidadespara las relaciones interpersonales y una mente abierta y ágil. V F.
El muestreo de documentos requieren de una buena planificación, buenas habilidades para las relaciones interpersonales y una mente abierta y ágil. V F.
En las entrevistas no es necesario tomar anotaciones V F.
Las entrevistas no generan información de gran calidad V F.
Las entrevistas requieren mucho tiempo para preparar pero no son costosas V F.
Las entrevistas no son apropiadas en la mayoría de proyectos V F.
Observacion: Permite observar qué realmente sucede, y no sólo qué se dice en las entrevistas que sucede V F.
Observacion: Obtener un profundo conocimiento de los objetivos de la organización, los requisitos de los usuarios y los roles de cada persona V F.
La observación ofrece una idea real de cómo funciona el sistema y permite verificar información de otras fuentes V F.
La desventaja de las entrevistas es que a la gente no le gusta ser observada V F.
La observación no requiere entrenamiento ni capacitación V F.
La observación permite obtener datos cuantitativos V F.
Muestreo de documentos: Determinar la información que realmente utiliza el personal en su trabajo V F.
Muestreo de documentos: Realizar análisis estadístico de los documentos para localizar patrones de datos V F.
Al contrario que la observación, el muestreo de documentos nos permite obtener datos cuantitativos. V F.
El muestreo de documentos no ayuda si el sistema va a cambiar drásticamente V F.
El muestreo de documentos no es adecuado cuando hay porcentajes de error elevados V F.
Cuestionarios: Obtener el punto de vista de un gran número de personasde manera que permita su análisis estadístico V F.
Cuestionarios: Obtener un profundo conocimiento de los objetivos de la organización, los requisitos de los usuarios y los roles de cada persona V F.
Los cuestionarios permite la recogida de información de gente geográficamente dispersa V F.
Los buenos cuestionarios son sencillos de diseñar, por eso se usan con frecuencia V F.
Los casos de uso se utilizan en técnicas orientadas a objetos y en análisis estructurado V F.
Los casos de uso son descripciones de la funcionalidad del sistema independientes de la implementación V F.
Los casos de uso se expresan en lenguaje máquina V F.
Los casos de uso describen mediante acciones y reacciones el comportamiento de un usuario desde el punto de vista del sistema V F.
Los actores son una agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema V F.
Los actores son internos al sistema V F.
Un usuario solo puede acceder al sistema con un único perfil V F.
Todos los perfiles de un usuario corresponden a un mismo actor V F.
Los casos de uso se expresan en forma de lista numerada de los pasos que sigue el actor para interactuar con el sistema V F.
Los casos de uso describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él V F.
Los casos de uso describen solo lo que hace el sistema cuando el actor interactúa con él V F.
Diagrama de casos de uso: Diagrama que muestra los casos de uso representados en forma de elipses y a los actores en forma de personajes. También representa las diferentes relaciones entre actores y casos de uso V F.
Diagramas de casos de uso: Representación gráfica de un sistema que ilustra cómo fluyen los datos a través de distintos procesos V F.
En los casos de uso las relaciones que existen son de: inclusión, extensión, herencia (entre casos de usos y actores) V F.
Relación de comunicación: Es la relación que vincula a un actor con un caso de uso V F.
Relación de comunicación: Sirve para relacionar un caso de uso con otros V F.
Relación de inclusión: Sirve para enriquecer un caso de uso con otro. Dicho enriquecimiento se lleva a cabo mediante una inclusión imperativa V F.
Relación de inclusión: Enriquece un caso de uso mediante un caso de uso de subfunción. En este caso se trata de una funcionalidad opcional V F.
Relación de extensión: Enriquece un caso de uso mediante un caso de uso de subfunción. En este caso se trata de una funcionalidad opcional V F.
Relación de extensión: Permite la especialización de un caso de uso en otro u otros, obteniendo uno o varios subcasos de uso V F.
Puntos de extensión: serie de puntos concretos y previstos en el momento del diseño V F.
Herencia entre casos de uso: Permite la especialización de un caso de uso en otro u otros, obteniendo uno o varios subcasos de uso V F.
Herencia entre casos de uso: Permite a un actor heredar la funcionalidad de otro V F.
Los supercasos de uso siempre son abstractos V F.
Los subcasos solo heredan el comportamiento de los supercasos de uso pero no sus relaciones V F.
Herencia entre actores: Permite a un actor heredar la funcionalidad de otro V F.
El actor que actúa como generalización siempre es abstracto V F.
Si un actor es abstracto, otro actor concreto puede heredar su funcionalidad V F.
Los casos de uso aumentan la trazabilidad del sistema V F.
Diagrama de Flujo de Datos: Representación gráfica de un sistema que ilustra cómo fluyen los datos a través de distintos procesos V F.
Diagrama de Flujo de Datos: Representación gráfica de un sistema que ilustra en forma de elipse los datos. V F.
Los DFD solo se realizan en un único nivel de abstracción V F.
Los componentes de un DFD son: entidades externas, flujos de datos, procesos o actividades y almacenes de datos y ficheros. V F.
En los DFD cada elemento tiene asociado un nombre unívoco a modo de etiqueta V F.
Los flujos de datos en DFD solo pueden converger V F.
Los flujos pueden incluir información de control (DFD) V F.
Las entradas y salidas netas de un DFD deben coincidir con los flujos de entrada y salida del proceso a que corresponde en el nivel superior V F.
En el diagrama de máquinas de estado, mientras se encuentra en un estado se considera que está en reposo V F.
En el diagrama de máquinas de estado, mientras se encuentra en un estado se considera que está inactivo V F.
Una actividad es la ejecución de una serie de métodos y de interacciones con otros objetos V F.
En el diagrama de máquinas de estado solo existe un único estado final donde se destruye el objeto V F.
En un diagrama de máquinas de estado siempre hay estado final V F.
En el diagrama de máquinas de estado el estado inicial corresponde al estado del objeto justo después de su creación V F.
En los diagramas de máquinas de estado un evento es un hecho que activa el cambio de estado V F.
En los diagramas de máquinas de estado los eventos no están condicionados a que un objeto reciba una señal V F.
El diagrama de máquina de estados representa el ciclo de vida de las instancias de una clase V F.
El diagrama de máquina de estados describe los estados, las transiciones que los vinculan y los eventos que provocan el traspaso de las transiciones V F.
El diagrama de máquinas de estado se aplica tanto a objetos con ciclo de vida como a aquellos sin él V F.
En un diagrama de máquina de estado los estados se representan con una elipse con su nombre en el interior V F.
En un diagrama de máquina de estado los estados se representan con un rectángulo de esquinas redondeadas con su nombre en el interior V F.
Tanto en diagramas de actividades y de máquinas de estado el estado inicial se representa con un punto negro V F.
Tanto en diagramas de actividades y de máquinas de estado el estado final se representa con un punto negro rodeado de un circulo V F.
Tanto en diagramas de actividades y de máquinas de estado el estado final se representa con un punto negro V F.
Tanto en diagramas de actividades y de máquinas de estado el estado inicial se representa con un punto negro rodeado de un circulo V F.
En un diagrama de máquina de estados no es necesario etiquetar las transiciones condicionales V F.
En un diagrama de máquina de estados no es necesario etiquetar las transiciones automáticas V F.
En un diagrama de máquina de estados es necesario etiquetar las transiciones automáticas V F.
Transición reflexiva, aquella que tanto estado inicial y final es coincidente V F.
En un diagrama de máquinas de estado una condición de control se utiliza para asociar condiciones de ejecución a una transición V F.
En un diagrama de maquinas de estado, para ejecutar una transición, no es necesario que se cumpla la condición al recibir el evento. V F.
En un diagrama de máquinas de estado la condición de control se escribe a la izquierda del nombre del evento V F.
En un diagrama de máquinas de estado la condición de control se escribe a la derecha del nombre del evento V F.
En un diagrama de máquinas de estado la condición de control se escribe entre paréntesis V F.
El diagrama de actividades es una forma específica del diagrama de máquina de estados en la que cada estado se asocia a una actividad y todas las transiciones son automáticas V F.
En el diagrama de actividades las transiciones se llaman conexiones V F.
En el diagrama de actividades las transiciones se llaman encadenamientos V F.
Las condiciones de control en diagramas de actividades permiten reflejar caminos imperativos V F.
En un diagrama de actividades un encadenamiento es un vínculo no orientado entre varias actividades V F.
En un diagrama de actividades un encadenamiento es un vínculo orientado entre varias actividades V F.
En los diagramas de actividades hay dos tipos de encadenamiento horquilla y sincronización V F.
Los swimlanes pueden ser utilizados tanto en diagramas de actividades como en diagramas de máquinas de estado V F.
Los diagramas de máquina de estado puede presentar las actividades realizadas por varios objetos con sus encadenamientos V F.
En los diagramas de actividades, cuando participan varios objetos dividimos el diagrama en carreteras V F.
En los diagramas de actividades, cuando participan varios objetos dividimos el diagrama en calles o carriles V F.
En los diagramas de actividades cada una de las calles al usar swimlanes corresponde a un objeto V F.
Un encadenamiento en diagramas de actividades nunca puede cortar la línea de separación de dos calles. V F.
Una colaboración es un grupo de objetos o clases que trabajan juntas para proporcionar un elemento de funcionalidad o comportamiento V F.
Una interacción es un grupo de objetos o clases que trabajan juntas para proporcionar un elemento de funcionalidad o comportamiento V F.
Una interacción define el paso de mensajes entre líneas de vida (por ejemplo, objetos) en el contexto de una colaboración para lograr un comportamiento particular V F.
Una colaboración define el paso de mensajes entre líneas de vida (por ejemplo, objetos) en el contexto de una colaboración para lograr un comportamiento particular V F.
Los diagramas de secuencia muestran una interacción entre objetos organizados en una secuencia de tiempo V F.
Un diagrama de secuencia se puede considerar como una especificación detallada del caso de uso si se utiliza para modelar el comportamiento dinámico de un caso de uso V F.
En los diagramas de secuencia la dimensión vertical representa el tiempo V F.
En los diagramas de secuencia la dimensión horizontal representa el tiempo V F.
En los diagramas de secuencia la dimensión horizontal representa los objetos involucrados en la interacción V F.
En los diagramas de secuencia la dimensión vertical representa los objetos involucrados en la interacción V F.
En los diagramas de secuencia cada objeto esta representado por una o muchas líneas de vida por líneas verticales discontinuas V F.
En los diagramas de secuencia los mensajes se representan por una flecha horizontal que va desde una línea de vida a otra V F.
En los diagramas de secuencia cuando se envía un mensaje a un objeto se está llamando a una operación de ese objeto V F.
La ocurrencia de ejecución o activación es el periodo de tiempo durante el que se está ejecutando una operación V F.
La temporización es el periodo de tiempo durante el que se está ejecutando una operación V F.
La ocurrencia de ejecución o activación se representa mediante un bloque rectangular situado a lo largo de la línea de vida V F.
El rectángulo en el que se representan los diagramas de secuencia se llama cuadro. V F.
El rectángulo en el que se representan los diagramas de secuencia se llama marco V F.
La interacción dentro de los marcos en los diagramas de secuencia se conoce como fragmento combinado, donde la palabra clave loop es un ejemplo de un operador de interacción V F.
Un fragmento combinado con una limitación de interacción sólo se ejecutará si la limitación se evalúa como verdadera V F.
La creación de un objeto es mostrada mediante una flecha de construcción continua apuntando directamente al símbolo del objeto creado V F.
La clase límite en los diagramas de secuencia es aquella que establezca el diálogo entre el actor y el sistema V F.
La clase límite en los diagramas de secuencia es aquella que se encarga de gestionar la comunicación con los demás objetos V F.
La clase de control en los diagramas de secuencia se encarga de gestionar la comunicación con los demás objetos V F.
La clase límite en los diagramas de secuencia se encarga de gestionar la comunicación con los demás objetos V F.
Un mensaje reflexivo en diagramas de secuencia es aquel que envía mensajes a otro objeto V F.
En los diagramas de secuencias el paso de mensajes se representan mediante flechas horizontales que unen la línea de vida del objeto emisor con la línea de vida del objeto destinatario V F.
En los diagramas de secuencia los mensajes no se pueden numerar de ninguna forma porque tienen dimensión de tiempo V F.
En los diagramas de secuencia los mensajes pueden ser solo síncronos o asíncronos V F.
Los mensajes síncronos en los diagramas de secuencia son aquellos en los que el expedidor del mensaje espera que la activación del método asociado al destinatario finalice para poder continuar su actividad V F.
Los mensajes síncronos en los diagramas de secuencia se llaman también llamada a procedimiento V F.
Los mensajes asíncronos en los diagramas de secuencia se llaman también llamada a procedimiento V F.
Los mensajes asíncronos en los diagramas de secuencia son aquellos en los que el expedidor del mensaje espera que la activación del método asociado al destinatario finalice para poder continuar su actividad V F.
Los mensajes asíncronos en diagramas de secuencia son los que más se utilizan V F.
Los mensajes de retorno en los diagramas de secuencia se encargan de devolver el control al objeto que originó el mensaje que inició la activación V F.
Los mensajes asíncronos en los diagramas de secuencia se encargan de devolver el control al objeto que originó el mensaje que inició la activación V F.
Los mensajes de retorno en los diagramas de secuencia se representan mediante una línea discontinua V F.
Los mensajes síncronos en los diagramas de secuencia se representan mediante una línea discontinua V F.
El uso de mensajes de retorno en los diagramas de secuencia es obligatorio ya que no podemos asumir que el control siempre es devuelto al objeto que originó el mensaje a la finalización de la ocurrencia de ejecución V F.
En los mensajes asíncronos en los diagramas de secuencia son aquellos en los que el expedidor no espera el término de la activación invocada por el destinatario V F.
En los mensajes síncronos en los diagramas de secuencia son aquellos en los que el expedidor no espera el término de la activación invocada por el destinatario V F.
La destrucción de los objetos en diagramas de secuencia da fin a su línea de vida y se representa mediante una cruz al final de la línea de vida V F.
La destrucción de los objetos en diagramas de comunicación da fin a su línea de vida y se representa mediante una cruz al final de la línea de vida V F.
El operador alt es el único operador que admite parámetros V F.
El operador loop (1,3) indica que el fragmento combinado se ejecutará dos veces V F.
El operador loop (*, 1) ejecuta el fragmento combinado indefinidamente V F.
El operador loop (1,*) ejecutará un fragmento combinado indefinidamente ignorando cualquier condición de control en el mismo V F.
El operador opt es el único operador de interacción que permite ejecutar distintas alternativas en un fragmento combinado V F.
En los fragmentos combinados con operador alt podemos ejecutar cualquiera de las opciones simultáneamente siempre que queramos V F.
El operador opt en un fragmento combinado puede incluir una condición else V F.
El operador ref permite simplificar la representación de un diagrama de secuencia de interacción, referenciando desde el correspondiente fragmento combinado otros fragmentos de interacción V F.
Los diagramas de comunicación no mantienen la misma información que los diagramas de secuencia V F.
Los diagramas de comunicación, al igual que los de secuencia tienen una dimensión para el tiempo V F.
Los diagramas de secuencia no tienen dimensión de tiempo y la secuencia se captura con números de secuencia V F.
Los diagramas de comunicación no proporcionan el mismo nivel de sintaxis que los diagramas de secuencia y no son adecuados para interacciones complejas V F.
Los diagramas de secuencia no proporcionan el mismo nivel de sintaxis que los diagramas de comunicación y no son adecuados para interacciones complejas V F.
Cuando hay muchos mensajes entre dos objetos un diagrama de comunicación es más difícil de leer que el diagrama de secuencia equivalente V F.
Los diagramas de comunicación muestran con mayor claridad las interacciones de diseño detalladas V F.
Los diagramas de comunicación ofrecen más indicaciones visuales explícitas de la duración de cada activación V F.
Los diagramas de comunicación se suelen utilizar para describir casos de uso de análisis, por no estar aún completamente especificados los mensajes V F.
Los diagramas de secuencia son mejor para el modelo genérico de la interacción y los diagramas de comunicación son mejor para los escenarios específicos V F.
Los diagramas generales de interacción han sido presentados en UML 2 V F.
Los diagramas generales de interacción se centran en la visión de conjunto del flujo de control en una interacción V F.
Los nodos de los diagramas generales de interacción pueden ser interacciones u ocurrencias de interacción V F.
Para generar un diagrama general de interacción basta con conocer las interacciones de forma general V F.
Los diagramas de tiempo son una nueva característica de UML 2 V F.
Los diagramas de tiempo muestran los cambios de estado de un objeto cuando éstos dependen del tiempo y de otros objetos V F.
Tanto los diagramas de secuencia, de comunicación y de clases deberían ser mutuamente consistentes V F.
Los diagramas de secuencia, comunicación y clase no tienen porqué ser mutuamente consistentes V F.
Para que un objeto remitente pueda conocer la referencia del objeto destino este debe tener un enlace directo al objeto destino o mediante otro objeto que tiene una relación con el objeto destino (existe una ruta de asociaciones) V F.
Un objeto es una entidad identificable del mundo real V F.
Los objetos tienen tanto existencia física como no V F.
Un objeto identificable es aquel que se puede implementar V F.
En UML todo objeto posee un conjunto de atributos y un conjunto de métodos V F.
Incluso los objetos estáticos del mundo real son percibidos en UML como dinámicos V F.
Incluso los objetos dinámicos del mundo real son percibidos en UML como estáticos V F.
La abstracción consiste en tener en cuenta únicamente las propiedades pertinentes de un objeto para un problema concreto V F.
Los objetos de UML son abstracciones del mundo real V F.
Clase de objetos es aquella en la que cada objeto de una clase se denomina instancia de clase y se distinguen por tener una identidad propia y un comportamiento específico a través de sus atributos V F.
La clase de objetos se define como un conjunto de objetos similares, con la misma estructura y comportamiento, y constituidos por los mismos atributos y métodos V F.
Cada objeto de una clase se denomina instancia de clase y se distinguen por tener una identidad propia y un comportamiento específico a través de sus atributo V F.
Una instancia de clase es se define como un conjunto de objetos similares, con la misma estructura y comportamiento, y constituidos por los mismos atributos y métodos V F.
Encapsulación: consiste en ocultar los atributos y métodos del objeto a otros objetos V F.
Encapsulación: consiste en almacenar los atributos de otra clase en sí misma V F.
La encapsulación no es una abstracción ya que no simplifica la representación del objeto V F.
En UML los atributos y métodos precedidos por el símbolo + no están encapsulados y son visibles para todos V F.
En UML los atributos y métodos precedidos por el símbolo - no están encapsulados y son visibles para todos V F.
En UML los atributos y métodos precedidos por el símbolo # son elemento encapsulado visible en las subclases de la clase V F.
En UML los atributos y métodos precedidos por el símbolo ~ son elemento encapsulado visible en las subclases de la clase V F.
En UML los atributos y métodos precedidos por el símbolo - son elemento encapsulado visible sólo en la clase V F.
En UML los atributos y métodos precedidos por el símbolo + son elemento encapsulado visible sólo en la clase V F.
En UML los atributos y métodos precedidos por el símbolo ~ son elemento encapsulado visible sólo en las clases del mismo empaquetado V F.
En UML los atributos y métodos precedidos por el símbolo - son elemento encapsulado visible sólo en las clases del mismo empaquetado V F.
Las clases pueden especificarse como subconjuntos de otras clases siempre que éstos constituyan conjuntos de objetos similares V F.
Las clases pueden especificarse como subconjuntos de otras clases siempre que éstos constituyan conjuntos de objetos diferentes V F.
La generalización es la relación inversa a la especialización. V F.
La clase especializada es una subclase de la generalizada, la cual a su vez es una superclase de la especializada V F.
La clase generalizada es una subclase de la especializada, la cual a su vez es una superclase de la generalizada V F.
La herencia significa que una clase (generalmente abstracta) representa un conjunto formado por objetos diferentes, ya que éstos son instancias de subclases diferentes V F.
La herencia es la propiedad que hace que una subclase se beneficie de la estructura y comportamiento de su superclase V F.
La herencia es la propiedad que hace que una superclase se beneficie de la estructura y comportamiento de su subclase V F.
Las subclases no se pueden beneficiar de la estructura y comportamiento de las superclases V F.
Clase abstracta: Es aquella que tiene subclases asociadas, y por tanto no poseen directamente instancias, al pertenecer éstas a las subclases declaradas V F.
Clase abstracta: Es aquella que sí permite instancias de esa clase y no poseen subclases asociadas V F.
Clase concreta: Es aquella que sí permite instancias de esa clase y no poseen subclases asociadas V F.
Clase concreta: Es aquella que tiene subclases asociadas, y por tanto no poseen directamente instancias, al pertenecer éstas a las subclases declaradas V F.
Polimorfismo: significa que una clase (generalmente abstracta) representa un conjunto formado por objetos diferentes, ya que éstos son instancias de subclases diferentes V F.
En polimorfismo cuando se llama a un método del mismo nombre esto se traduce en comportamientos diferentes. V F.
En polimorfismo cuando se llama a un método del mismo nombre esto se traduce en el mismo comportamiento. V F.
Un objeto puede ser complejo y estar compuesto por otros objetos V F.
La asociación que une a los objetos compuestos por otros es la asociación V F.
La composición puede tomar dos formas, composición débil o agregación y composición fuerte V F.
Composición débil o agregación: los componentes pueden ser compartidos por varios objetos complejos V F.
Composición débil o agregación: los componentes no pueden compartirse y la destrucción del objeto compuesto conlleva la destrucción de sus componentes V F.
Composición fuerte: los componentes no pueden compartirse y la destrucción del objeto compuesto conlleva la destrucción de sus componentes V F.
Composición fuerte: los componentes pueden ser compartidos por varios objetos complejos V F.
Los estereotipos en UML pueden ser implícitos y explicativos V F.
El estereotipo UML implícito es aquel en el que se escribe el nombre de la clase abstracta en cursiva V F.
El estereotipo UML explícito es aquel en el que se escribe el nombre de la clase abstracta en cursiva V F.
El estereotipo UML explícito es aquel en el podemos prescindir de poner el nombre de la clase en cursiva precisando de forma explícita el estereotipo «abstract» V F.
El estereotipo UML implícito es aquel en el podemos prescindir de poner el nombre de la clase en cursiva precisando de forma explícita el estereotipo «abstract» V F.
El nombre de las asociaciones entre clases se escribe debajo de la línea V F.
El sentido de lectura de las asociaciones se indica por el símbolo < o > V F.
Los extremos de la asociación no reciben nombres representativos ya que el nombre importante es el de la propia asociación V F.
Asociación ternaria: La representación gráfica de una asociación ternaria y superiores consiste en un rombo que une las diferentes clases V F.
Asociación ternaria: La representación gráfica de una asociación ternaria y superiores consiste en una elipse que une las diferentes clases V F.
Si no se especifica la cardinalidad de una asociación, se supone que es 0 V F.
La cardinalidad * en una asociación es de una a varias veces V F.
Por defecto, las asociaciones tienen una navegación unidireccional V F.
Las navegaciones bidireccionales en las asociaciones son más sencillas de realizar para los desarrolladores V F.
La navegación bidireccional suele ser más compleja de realizar para los desarrolladores, por lo que conviene evitarlas en la medida de lo posible V F.
Para identificar un único sentido de navegación en asociaciones se utiliza un círculo en el extremo de la asociación V F.
Las asociaciones reflexivas son aquellas que tenemos a la misma clase en ambos extremos de la asociación V F.
La clase-asociación es aquella en la que encontramos que el vínculo entre dos instancias de clases tiene información específica de ese vínculo V F.
La calificación de una instancia es un valor o conjunto de valores que permiten encontrar dicha instancia V F.
Las calificaciones de una instancia suelen ser índices para encontrar un elemento en una tabla, llaves... etc V F.
La relación de exclusión es la que establecer restricciones para que dos asociaciones no puedan darse a la vez V F.
Si dos asociaciones no se pueden dar a la vez se indicará mediante una línea en negrita y una nota las restricciones existentes V F.
Cuando una de las clases del extremo de una asociación tiene que mantener un orden respecto a la clase del otro extremo podemos establecer la restricción de orden con el término {ordered} V F.
Cuando una de las clases del extremo de una asociación tiene que mantener un orden respecto a la clase del otro extremo podemos establecer la restricción de orden con el término {subset} V F.
Las relaciones de inclusión se dan cuando dos clases tienen dos o más asociaciones entre sí V F.
Las restricciones de relación de inclusión se pueden etiquetar utilizando el término {subset} V F.
Las restricciones de relación de inclusión se pueden etiquetar utilizando el término {ordered} V F.
El software que se implementa está formado por clases en la metodología orientada a objetos V F.
Clases límite: : los objetos límite modelan la interacción entre el sistema y los actores (y otros sistemas) V F.
Clases control: los objetos control coordinan y controlan otros objetos V F.
Clases entidad: los objetos entidad representan información y conducta en el dominio de la aplicación V F.
Clases límite: los objetos límite coordinan y controlan otros objetos V F.
Clase control: los objetos control modelan la interacción entre el sistema y los actores (y otros sistemas) V F.
Las clases límite representan la interacción con el sistema V F.
Las clases entidades se utilizan para modelar la información y el comportamiento asociado a algún objeto o evento de la vida real V F.
Una clase entidad puede representar solo objetos físicos V F.
Las clases control encapsulan la conducta única de un caso de uso V F.
Las clases límite encapsulan la conducta única de un caso de uso V F.
Se recomienda utilizar una sola clase de control para todos los casos de uso V F.
Realización: Consiste en el desarrollo de un modelo o elemento abstracto para pasar a otro modelo o elemento que esté más cerca de su ejecución V F.
Especificación: Consiste en el desarrollo de un modelo o elemento abstracto para pasar a otro modelo o elemento que esté más cerca de su ejecución V F.
Un diagrama de clases de análisis es un producto final V F.
Los diagramas de clases de análisis se transforman en diagramas de clases explícitas V F.
El resultado final de una realización es la implementación software de ese caso de uso V F.
El resultado final de una realización es la creación de clases de diseño V F.
En una realización de un caso de uso el conjunto de clases se llama colaboración V F.
En una realización de un caso de uso el conjunto de clases se llama conjunto V F.
Un diagrama de comunicación muestra los detalles internos de una colaboración, puesto que representa explícitamente la interacción entre objetos V F.
Un diagrama de secuencia muestra los detalles internos de una colaboración, puesto que representa explícitamente la interacción entre objetos V F.
Un diagrama de secuencia de interacción oculta la mayor parte de la estructura (la interacción entre objetos no es tan explícita), pero muestra la secuencia de mensajes con mayor claridad V F.
Un diagrama de comunicación oculta la mayor parte de la estructura (la interacción entre objetos no es tan explícita), pero muestra la secuencia de mensajes con mayor claridad V F.
El diagrama de comunicación está más orientado al análisis de requisitos y la obtención de las clases intervinientes V F.
El diagrama de secuencia de interacción está más orientado al análisis de requisitos y la obtención de las clases intervinientes V F.
El diagrama de secuencia de interacción está más orientado al diseño, prueba e implementación del modelo del sistema V F.
El diagrama de comunicación está más orientado al diseño, prueba e implementación del modelo del sistema V F.
La transición de diagramas de comunicación a diagramas de clase generalmente es difícil V F.
Para pasar de casos de uso a diagrama de clases hay que obtener la colaboración, el diagrama de comunicación y por último el diagrama de clases de cada caso de uso V F.
Los diagramas de comunicación muestran los objetos unidos mediante rombos y los diagramas de clase mediante líneas de conexión V F.
En los diagramas de comunicación se muestra un actor y en el diagrama de clases no V F.
Tanto en diagramas de comunicación como en diagramas de clase se muestra siempre un actor V F.
Un diagrama de comunicación contiene clases y un diagrama de clases contiene ejemplos objeto V F.
Las conexiones en los diagramas de comunicación representan vínculos y en los diagramas de clases representan asociaciones entre clases V F.
Las conexiones en los diagramas de comunicación representan asociaciones entre símbolos y en los diagramas de clases representan vínculos entre clases V F.
Tanto los objetos límite y de control se crean únicamente durante la ejecución del software mientras que los objetos entidad y sus vínculos permanecen más allá de un ciclo de ejecución y, probablemente, requieran almacenaje permanente V F.
Los objetos límite y de entidad y sus vínculos se crean en la ejecución del software V F.
Los objetos entidad y sus vínculos permanecen más allá de la ejecución y requieren almacenaje permanente V F.
Un diagrama de comunicación representa un modelo estático y el diagrama de clases un modelo dinámico V F.
Las tarjetas CRC constituyen otra metodología para obtener las clases involucradas en una colaboración de un caso de uso V F.
Las tarjetas RCR constituyen otra metodología para obtener las clases involucradas en una colaboración de un caso de uso V F.
Las tarjetas CRC se basan en que, generalmente, es más fácil pensar una clase en términos de responsabilidades globales que en sus operaciones individuales V F.
Responsabilidad: Es una descripción de alto nivel de algo que una clase puede hacer V F.
Responsabilidad: Es una descripción de alto nivel de algo que una tarjeta CRC puede hacer V F.
Una tarjeta CRC refleja la información disponible para esa clase pero no los servicios que puede ofrecer a otros objetos V F.
Una responsabilidad refleja tanto la información de esa clase como los servicios que puede ofrecer a otras clases V F.
Diseño: proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, proceso o sistema con suficientes detalles como para permitir su realización física V F.
El diseño es la primera fase de construcción del sistema desde el punto de vista del dominio de la solución V F.
El análisis es la primera fase de construcción del sistema desde el punto de vista del dominio de la solución V F.
El análisis estudia el sistema a desarrollar desde el punto de vista del dominio del problema V F.
El diseño estudia el sistema a desarrollar desde el punto de vista del dominio del problema V F.
Depende del ciclo de vida se desarrolla en una fase u otra V F.
El diseño preliminar y detallado se desarrolla en el punto de vista de gestión V F.
El diseño preliminar y detallado se desarrolla en el punto de vista técnico V F.
El diseño de datos, arquitectónico, a nivel de componentes y de la interfaz se dan en el punto de vista técnica V F.
El diseño de datos, arquitectónico, a nivel de componentes y de la interfaz se dan en el punto de vista de gestión V F.
El diseño preliminar y el diseño de datos se da en el punto de vista de gestión V F.
El diseño detallado y el diseño arquitectónico se dan en el punto de vista técnico V F.
El diseño a nivel de componentes y el diseño de la interfaz se dan en el punto de vista técnico V F.
El diseño plantea cómo construir el sistema sin realmente construirlo V F.
El análisis plantea cómo construir el sistema sin realmente construirlo V F.
El análisis identifica qué debe hacer el sistema y el diseño cómo debe hacerlo V F.
El diseño identifica qué debe hacer el sistema y el análisis cómo debe hacerlo V F.
Un analista busca entender la organización, sus requisitos y sus objetivos V F.
Un diseñador busca entender la organización, sus requisitos y sus objetivos V F.
Un diseñador busca especificar un sistema que se ajuste a la organización, provea sus requisitos eficazmente y permita alcanzar sus objetivos V F.
Un analista busca especificar un sistema que se ajuste a la organización, provea sus requisitos eficazmente y permita alcanzar sus objetivos V F.
En el ciclo de vida en cascada no existe una transición clara entre análisis y diseño V F.
En el ciclo de vida iterativo el análisis del sistema precederá al diseño, pero ambos podrían desarrollarse en paralelo V F.
En el ciclo de vida iterativo el diseño del sistema precederá al análisis, pero ambos podrían desarrollarse en paralelo V F.
En el ciclo de vida iterativo análisis y diseño no pueden desarrollarse en paralelo V F.
El diseño tradicional se divide en las fases Análisis Orientado a Objetos, Diseño Orientado a Objetos y POO V F.
El diseño en el ciclo de vida iterativo se divide en las fases Análisis Orientado a Objetos, Diseño Orientado a Objetos y POO V F.
Las fases del diseño en el ciclo de vida iterativo son planificación y especificación de requisitos, construcción e instalación V F.
Las fases del diseño tradicional son planificación y especificación de requisitos, construcción e instalación V F.
La fase de construcción del diseño en el ciclo de vida iterativo se divide en análisis, diseño e implementación V F.
El diseño de ciclo de vida iterativo tiene una calidad mejorado respeto al diseño tradicional V F.
Una solución modular nunca se divide en niveles de abstracción V F.
En los niveles de abstracción más elevados se enuncia una solución a grandes rasgos para el problema V F.
En los niveles más bajos de abstracción se da una descripción más detallada de la solución V F.
En el nivel más bajo de abstracción se plantea la solución, de modo que pueda implementarse directamente V F.
En el nivel más bajo de abstracción se enuncia una solución a grandes rasgos para el problema V F.
En el nivel más elevado de abstracción se plantea la solución, de modo que pueda implementarse directamente V F.
Existen tres tipos de abstracción, de datos, funcional y de control V F.
Abstracción funcional: secuencia de instrucciones con una función limitada y específica V F.
Abstracción de datos: tipos de datos a utilizar, junto a sus operaciones permitidas. Encapsulado de datos V F.
Abstracción de datos: secuencia de instrucciones con una función limitada y específica V F.
Abstracción funcional: tipos de datos a utilizar, junto a sus operaciones permitidas. Encapsulado de datos V F.
Un patrón es una solución a un problema general, utilizable para resolver un problema particular ajustando sus atributos V F.
Un patrón es una secuencia de instrucciones con una función limitada y específica V F.
Existen tres tipos de patrones según el grado de abstracción: arquitectónicos, de diseño y de código V F.
Un patrón arquitectónico es el que define la estructura general del software y las relaciones entre subsistemas y componentes del software V F.
Un patrón de diseño es el que consiste en un diagrama de objetos que ofrece una solución a un problema conocido y frecuente. V F.
Un patrón de código suele implementar un elemento algorítmico o un componente, un protocolo de interfaz específico o un mecanismo de comunicación entre los componentes V F.
Un patrón de diseño define la estructura general del software y las relaciones entre subsistemas y componentes del software V F.
Un patrón arquitectónico suele implementar un elemento algorítmico o un componente, un protocolo de interfaz específico o un mecanismo de comunicación entre los componentes V F.
Los patrones pueden describirse mediante una plantilla V F.
La GoF ofrece un catálogo de 20 patrones de diseño V F.
Dentro de los patrones de diseño tenemos los patrones de construcción y estructuración V F.
Los patrones de construcción tienen como objetivo organizar la creación de objetos V F.
Los patrones de estructuración facilitan la organización de la jerarquía de clases y de sus relaciones. V F.
Los patrones de comportamiento proporcionan soluciones para organizar las interacciones y para repartir el procesamiento entre los objetos. V F.
Los patrones de comportamiento son once V F.
Los patrones de construcción son cinco V F.
Los patrones de estructuración son siete V F.
Los patrones de construcción facilitan la organización de la jerarquía de clases y de sus relaciones. V F.
Los patrones de estructuración proporcionan soluciones para organizar las interacciones y para repartir el procesamiento entre los objetos V F.
Los patrones de construcción proporcionan soluciones para organizar las interacciones y para repartir el procesamiento entre los objetos. V F.
Los patrones de comportamiento son cinco V F.
Los patrones de estructuración son once V F.
Los patrones de construcción son siete V F.
Factory Method es un patrón de estructuración V F.
Template Method es un patrón de construcción V F.
Adapter es un patrón de estructuración V F.
El objetivo del patrón Factory Method es proveer un método abstracto de creación de un objeto delegando en las subclases concretas su creación efectiva V F.
El objetivo del patrón Factory Method es convertir la interfaz de una clase existente en la interfaz esperada por los clientes también existentes de modo que puedan trabajar de manera conjunta V F.
El patrón Adapter permite delegar en las subclases ciertas etapas de una de las operaciones de un objeto, quedando estas etapas descritas en las subclases V F.
El patrón Template Method busca proveer un método abstracto de creación de un objeto delegando en las subclases concretas su creación efectiva V F.
La modularidad es el único atributo de un software que permite que un programa sea manejable intelectualmente V F.
El software monolítico es fácil de seguir V F.
En un diseño modular, el software se divide en componentes con nombres independientes a los que se denomina modelos V F.
El desarrollo y mantenimiento de software es más fácil utilizando módulos conjuntos V F.
El desarrollo y mantenimiento de software es más fácil utilizando módulos independientes V F.
La independencia funcional mide a independencia entre módulos utilizando dos criterios: acoplamiento y cohesión V F.
La independencia funcional mide la dependencia entre módulos utilizando dos criterios: acoplamiento y cohesión V F.
Acoplamiento: Medida de la interdependencia entre los módulos V F.
Cohesión: Medida de la fuerza funcional relativa de un módulo V F.
Cohesión: Medida de la interdependencia entre los módulos V F.
Acoplamiento: Medida de la fuerza funcional relativa de un módulo V F.
El encapsulamiento permite a los módulos ocultar los detalles internos de sus procesos comunicándose con otros módulos a través de interfaces bien definidas V F.
El refinamiento por pasos es un enfoque de diseño descendente en el que el desarrollo de una aplicación se realiza mediante refinamiento sucesivo de los niveles de detalle procedimentales V F.
El refinamiento por pasos es un enfoque de diseño ascendente en el que el desarrollo de una aplicación se realiza mediante refinamiento sucesivo de los niveles de detalle procedimentales V F.
El Refinamiento por pasos permite añadir los detalles rápidamente V F.
El diseño de datos / clases crea un modelo de datos o información que se representa con un alto grado de abstracción que se va refinando progresivamente V F.
La arquitectura de los datos tendrá una profunda influencia sobre la arquitectura del software que los procesa y sobre la calidad del software V F.
La arquitectura del software tendrá una profunda influencia sobre la arquitectura de datos que los procesa y sobre la calidad del software V F.
La arquitectura es el software operativo V F.
Los elementos del diseño arquitectónico dan una visión general del software y de sus funcionalidades V F.
Las fuentes de las que se obtiene el modelo arquitectónico son: la información del dominio de la aplicación del software que se va a elaborar, los elementos del modelo de análisis específico y la disponibilidad estilos arquitectónicos y sus patrones V F.
En el diseño de la interfaz tenemos dos elementos importantes, la interfaz de usuario y las interfaces externas V F.
La interfaz de usuario implementa elementos estéticos, elementos ergonómicos y elementos técnicos V F.
Las interfaces internas implementa elementos estéticos, elementos ergonómicos y elementos técnicos V F.
Las interfaces externas son las que actúan sobre otros sistemas, dispositivos, redes y otros productores o consumidores de información V F.
Las interfaces de usuario son las que actúan sobre otros sistemas, dispositivos, redes y otros productores o consumidores de información V F.
Las Interfaces internas que involucran a los distintos componentes del diseño V F.
Las interfaces externas involucran a los distintos componentes del diseño V F.
El diseño de componentes describe por completo el detalle interno de cada componente de software V F.
El diseño arquitectónico describe por completo el detalle interno de cada componente de software V F.
La primera vista de la arquitectura del sistema desarrollada en el análisis se denomina descomposición del modelo en paquetes V F.
La primera vista de la arquitectura del sistema desarrollada en el diseño se denomina descomposición del modelo en paquetes V F.
El diseño arquitectónico es un paso aparte ya que los procesos orientados a objetos son procesos iterativos, y la arquitectura no se va desarrollando a la vez que los detalles V F.
Los arquitectos no pueden ver más allá de los requisitos inmediatos V F.
Los arquitectos solucionan los problemas de forma creativa V F.
Sistema: conjunto de componentes que cumple una función o conjunto de funciones específicas V F.
Arquitectura: organización fundamental de un sistema incorporada en sus componentes, en sus relaciones mutuas y en el entorno, y los principios que guían su diseño y evolución V F.
Descripción de la arquitectura: conjunto de productos que documentan la arquitectura V F.
Sistema: organización fundamental de un sistema incorporada en sus componentes, en sus relaciones mutuas y en el entorno, y los principios que guían su diseño y evolución V F.
Arquitectura: conjunto de componentes que cumple una función o conjunto de funciones específicas V F.
La Arquitectura de software define y organiza un sistema en términos de sus componentes de software, incluyendo los subsistemas y las relaciones entre ellos, y los principios que guían el diseño de ese sistema de software V F.
La arquitectura es el software en funcionamiento V F.
La arquitectura permite solo analizar la eficacia del diseño y considerar alternativas arquitectónicas V F.
La arquitectura consiste en solo analizar la eficacia de un diseño V F.
En aplicaciones OO las clases representan unidades de granularidad muy fina; en sistemas grandes se requiere hablar de unidades que representen una funcionalidad mayor V F.
La arquitectura permite evitar que el sistema se convierta en una maraña de código V F.
La notación UML para el diseño arquitectónico utiliza diagramas de despliegue y diagramas de clase V F.
Los diagramas de componentes muestran la organización y las dependencias entre un conjunto de componentes V F.
Los componentes pertenecen al mundo abstracto y representan un bloque de construcción al modelar aspectos lógicos de un sistema V F.
Los componentes pertenecen al mundo físico, y representan un bloque de construcción al modelar aspectos físicos de un sistema V F.
Componente: es una unidad de software que ofrece una serie de servicios a través de una o varias interfaces V F.
Los componentes son una caja blanca ya que el contenido no puede quedar fuera del interés de los clientes V F.
Componente: Conjunto de clases del sistema que mantienen una cierta coherencia interna y una cierta independencia externa V F.
Los componentes no están totalmente encapsulados, sus detalles deben estar disponibles V F.
Los componentes deben definir una abstracción precisa con una interfaz bien definida, y permitiendo reemplazar fácilmente los componentes más viejos con otros más nuevos y compatibles V F.
Los componentes no son fáciles de reemplazar con otros más nuevos y compatibles V F.
Los componentes pueden depender de otros componentes V F.
Los componentes no necesitan tener nombres identificativos V F.
Interfaz: Especifican los servicios propios de una clase o de un componente V F.
Componente: Especifican los servicios propios de una clase o de una interfaz V F.
Los componentes interactúan mediante relaciones entre clases V F.
La interacción con un componente se realiza exclusivamente a través de sus interfaces V F.
Interfaces necesarias: interfaces que describen los servicios necesitados por un componente. V F.
Interfaces suministradas: interfaces que describen los servicios ofrecidos por un componente V F.
Interfaces necesarias: interfaces que describen los servicios ofrecidos por un componente V F.
Interfaces suministradas: interfaces que describen los servicios necesitados por un componente. V F.
Las interfaces necesarias se representan por un semicírculo V F.
Las interfaces suministradas se representan por un circulo V F.
Las interfaces suministradas se representan por un semicírculo V F.
Los componentes se representan dentro de un rectángulo con el estereotipo component V F.
Los componentes se representan dentro de una circunferencia con el estereotipo component V F.
Un componente no puede ser representado por su logo V F.
Diagrama de despliegue: Es un modelo de objetos que describe la arquitectura física del sistema en términos de cómo se distribuye la funcionalidad entre los distintos nodos V F.
Diagrama de componentes: Es un modelo de objetos que describe la arquitectura física del sistema en términos de cómo se distribuye la funcionalidad entre los distintos nodos V F.
Diagrama de despliegue: Muestran la organización y las dependencias entre un conjunto de componentes. V F.
Un nodo es una unidad capaz de recibir y de ejecutar software V F.
Un componente es una unidad capaz de recibir y de ejecutar software V F.
Los nodos representan recursos computacionales V F.
Los componentes representan recursos computacionales V F.
El modelo de despliegue es la correspondencia entre la arquitectura del software y la arquitectura del sistema V F.
El modelo de componentes es la correspondencia entre la arquitectura del software y la arquitectura del sistema V F.
Los diagramas de despliegue representan la topología del sistema V F.
Los nodos pertenecen al mundo lógico V F.
Los nodos son elementos físicos, que existen en tiempo de ejecución y representan un recurso computacional que generalmente tiene alguna memoria y, a menudo, capacidad de procesamiento V F.
Los componentes son elementos físicos, que existen en tiempo de ejecución y representan un recurso computacional que generalmente tiene alguna memoria y, a menudo, capacidad de procesamiento V F.
Los nodos contienen software en su forma física, conocida como artefact V F.
Los nodos no requieren nombres unívocos V F.
En un diagrama de clases la sintaxis UML determina que la palabra "name" es el nombre del atributo V F.
En un diagrama de clases la sintaxis UML determina que la palabra "prop-type" es el nombre del atributo V F.
En un diagrama de clases la sintaxis UML determina que la palabra "prop-type" es el tipo de dato V F.
En un diagrama de clases la sintaxis UML determina que la palabra "property-string" es el tipo de dato V F.
En un diagrama de clases la sintaxis UML determina que la palabra "default" es el valor que se le asigna al atributo cuando el objeto se crea por primera vez V F.
En un diagrama de clases la sintaxis UML determina que la palabra "prop-type" es el valor que se le asigna al atributo cuando el objeto se crea por primera vez V F.
En un diagrama de clases la sintaxis UML determina que la palabra "property-string" describe una propiedad del atributo, tal como constante o fijo V F.
En un diagrama de clases la sintaxis UML determina que la palabra "prop-type" describe una propiedad del atributo, tal como constante o fijo V F.
Constructor: Operación para crear una instancia de una clase. Por lo general, tiene el mismo nombre que la clase V F.
Destructor: Operación para eliminar una instancia de una clase de memoria V F.
Inicializador: Operación para crear una instancia de una clase. V F.
Las operaciones "get" sirven para obtener el valor de un atributo V F.
Las operaciones "set" sirven para establecer el valor de un atributo V F.
La operación para establecer el valor de un atributo se llama también Mutator V F.
La operación para establecer el valor de un atributo se llama también Accessor V F.
La operación para obtener el valor de un atributo se llama también Accessor V F.
La operación para obtener el valor de un atributo se llama también Mutator V F.
La firma de una operación viene determinada exclusivamente por el nombre de la operación V F.
En la firma de operaciones la parte obligatoria es la lista de parámetros V F.
UML utiliza tres notaciones para mostrar las interfaces un círculo pequeño, semicírculo y el icono de la clase estereotipada con una lista de las operaciones soportadas V F.
En las interfaces de UML el círculo pequeño si muestra los detalles V F.
Para indicar que una clase soporta las funcionalidades de una interfaz en UML se utiliza una flecha discontinua con punta triangular V F.
Acoplamiento: Describe el grado de interconexión entre los componentes diseñados V F.
Cohesión: Es una medida del grado en que un elemento contribuye a un objetivo concreto V F.
Acoplamiento: Es una medida del grado en que un elemento contribuye a un objetivo concreto V F.
Cohesión: Describe el grado de interconexión entre los componentes diseñados V F.
El acoplamiento queda reflejado por el número de enlaces que presenta un objeto y por el grado de interacción del objeto con otros objetos V F.
La cohesión queda reflejada por el número de enlaces que presenta un objeto y por el grado de interacción del objeto con otros objetos V F.
Acoplamiento y cohesión se complementan mutuamente V F.
Acoplamiento de interacción: medida del número de tipos de mensajes que un objeto envía a otros objetos y el número de parámetros que se pasan con este tipo de mensajes V F.
El acoplamiento de interacción debe mantenerse al máximo para hacer más fácil la reutilización V F.
Acoplamiento de herencia: describe el grado con el que una subclase necesita realmente las funciones que hereda de su clase superclase V F.
Acoplamiento de herencia: describe el grado con el que una superclase necesita realmente las funciones que hereda de su clase subclase V F.
Existen dos tipos de cohesión: cohesión de operación y de clase V F.
Cohesión de operación: Mide el grado con el que se centra una operación sobre un único requisito funcional V F.
Cohesión de clase: Refleja el grado con el que una clase se centra en un único requisito V F.
Cohesión de especialización: Aborda la cohesión semántica de las jerarquías de herencia V F.
Cohesión de especialización: Refleja el grado con el que una clase se centra en un único requisito V F.
Cohesión de clase: Mide el grado con el que se centra una operación sobre un único requisito funciona V F.
Cohesión de operación: Aborda la cohesión semántica de las jerarquías de herencia V F.
Principio de sustitución de Liskov (LSP): Establece que, en la interacción entre objetos, debe ser posible tratar a un objeto derivado como si fuera un objeto base sin problemas de integridad V F.
Principio de sustitución de Liskov (LSP): Establece que, en la interacción entre objetos, un objeto derivado no podrá comportarse como un objeto base para evitar violar la integridad del objeto derivado V F.
Una asociación bidireccional es la que soporta el paso de mensajes en ambos sentidos V F.
Minimizar el número de asociaciones bidireccionales mantiene el acoplamiento entre objetos al mínimo V F.
Minimizar el número de asociaciones bidireccionales mantiene la cohesión entre objetos al mínimo V F.
Las clases colección se utilizan para mantener los identificadores de los objetos cuando el paso de mensajes requiere de una asociación de uno a muchos V F.
Un ejemplo de clase colección es una lista o vector de objetos V F.
Las clases colección en los lenguajes de programación como Java no permite iterar sobres los objetos de la colección V F.
Integridad referencial: Asegura que un identificador de objeto referenciado dentro de otro objeto se refiere a un objeto que realmente existe V F.
Restricciones de dependencia: Aseguran que las dependencias de atributos, donde un atributo puede ser calculado a partir de otros, son consistentes V F.
Integridad de dominio: Asegura que los atributos únicamente tomen valores adecuados al dominio en el que están definidos V F.
Integridad de dominio: Aseguran que las dependencias de atributos, donde un atributo puede ser calculado a partir de otros, son consistentes V F.
Integridad referencial: Asegura que los atributos únicamente tomen valores adecuados al dominio en el que están definidos V F.
Restricciones de dependencia: Asegura que un identificador de objeto referenciado dentro de otro objeto se refiere a un objeto que realmente existe V F.
La complejidad computacional según Rumbaugh no influye en la elección de diseños para algoritmos V F.
El diseño de algoritmos está limitado por el coste de la implementación V F.
Pregunta Chill: ¿FIS es un coñazo? SÍ NO.
Denunciar test Consentimiento Condiciones de uso