0% encontró este documento útil (0 votos)
736 vistas6 páginas

Examen SI

1. Los bloques de construcción de UML incluyen elementos, relaciones y diagramas. Los elementos son abstracciones como clases y objetos. Las relaciones conectan elementos. Los diagramas representan gráficamente elementos y relaciones.

Cargado por

Scofield Michael
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
736 vistas6 páginas

Examen SI

1. Los bloques de construcción de UML incluyen elementos, relaciones y diagramas. Los elementos son abstracciones como clases y objetos. Las relaciones conectan elementos. Los diagramas representan gráficamente elementos y relaciones.

Cargado por

Scofield Michael
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd

1.

- Explique los bloques de construcción de UML y describa cada aspecto

Los bloques de construcción de UML son:

Elementos: son abstracciones que constituyen los ciudadanos de primera clase en un modelo.

Elementos estructurales, elementos de comportamiento, elementos de agrupación, elementos de anotación.

Relaciones: las relaciones ligan estos elementos entre sí.

Dependencia, generalización, realización.

Diagramas: es la representación gráfica de un conjunto de elementos visualizado la mayoría de las veces como un grafo
anexo de nodos y arcos.

Diagramas de clases, diagramas de objetos, diagramas de componentes, diagrama de estructura compuesta,


diagrama de casos de uso, diagrama de secuencia, diagrama de comunicación, diagrama de estado, diagrama
de actividades, diagrama de despliegue, diagrama de paquetes, diagrama de tiempos, diagrama de visión global
de interacciones.

2.- Describa brevemente el worflow requisito del PUDS

Analista de sistema: es el responsable del conjunto de requisitos que están modelados en los casos de uso, lo que
incluye todos los requisitos funcionales y no funcionales.

Encontrar actores y casos de uso: Encontrar los actores, encontrar los casos de uso, describir brevemente cada
caso de uso, describir el modelo de casos de uso completo

Estructurar el modelo de caso de uso: extraer descripciones de funcionalidades generales y compartida que
pueden ser utilizadas por descripciones más específicas, adicionales u opcionales que pueden extender
descripciones más específica.

Arquitecto: describe las vistas de la arquitectura del modelo de casos de uso, la vista de la arquitectura del modelo de
caso de uso es una entrada importante para planificar las iteraciones.

Priorizar los casos de uso:

Especificador de casos de uso: el trabajo de captura de requisitos pueden no estar dirigidos por un solo individuos, el
analista de sistemas esta asistido por otros trabajadores que asumen las responsabilidades de las descripciones
detalladas de uno o mas casos de uso: “trabaja específicamente con los casos de uso”.

Detallar un caso de uso: describe su flujo de sucesos en detalle, incluyendo como comienza, termina e
interactúan con los actores.

Diseñador de interfaces de usuario: el diseñador de interfaz de usuario es responsable de cada prototipo de interfaz de
usuario.

Prototipar la interfaz de usuario:

3.-Cuales son las actividades del análisis de la arquitectura, analizar paquetes y arquitectura de la
implementación

Su propósito del análisis de la arquitectura es esbozar el modelo de análisis y la arquitectura mediante la identificación
de paquetes del análisis, clases del análisis evidentes, y requisitos especiales comunes.
Las actividades de analizar un paquete son:

Definir y mantener las dependencias del paquete con otros paquetes cuya clases contenidas estén asociadas con él.

Asegurarnos de que el paquete contiene las clases correctas. Intentar hacer cohesivo el paquete incluyendo solo objetos
relacionados funcionalmente.

Limitar las dependencias con otros paquetes. Considerar la reubicación de aquellas clases contenidas en paquetes que
son demasiado dependientes de otros paquetes.

El propósito de la implementación de la arquitectura es esbozar el modelo de implementación y su arquitectura mediante:

La identificación de componentes significativos arquitectónicamente, tales como componentes ejecutables.

La asignación de componentes a los nodos en las configuraciones de redes relevantes.

4.- UML combina notaciones de que modelado provienen

5.- Que diferencia existe entre los diagramas de comportamiento y los diagramas de estructura estática

Los diagramas de comportamiento se pueden ver los aspectos dinámicos de un sistema como aquellos que representan
sus partes mutables. Así como los aspectos dinámicos de una casa incluyen flujos de aire y el tránsito entre las
habitaciones, los aspectos dinámicos de un sistema software involucran cosas tales como el flujo de mensaje a lo largo
del tiempo y el movimiento físico de componentes en una red.

Los diagramas de estructura estática se pueden ver los aspectos estáticos de un sistema como aquellos que representan
su esqueleto y su andamiaje, ambos relativamente estables. Así como el aspecto estático de una casa incluye la
existencia y ubicación de paredes, puertas, ventanas, tuberías, cables y conductos de ventilación, también los aspectos
estáticos de un sistema software incluyen la existencia y ubicación de clases, interfaces, colaboraciones, componentes y
nodos.

6.-Cuales son las claves en el desarrollo de los sistemas de información según las tres esquinas del triángulo,
describa cada uno

7.- UML es un modelo o una metodología, justifique su respuesta

8.- Que diferencia existe entre el diagrama de clase y el diagrama entidad relación

Un diagrama de clases en Lenguaje Unificado de Modelado (UML) es un tipo de diagrama de estructura estática que


describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las
relaciones entre los objetos.

Un modelo de entidad relación es una herramienta para el modelo de datos, la cual permite representar entidades de una
Base de Datos.

9.- Describe el esquema de las “4+1 vistas” de kruchten

La arquitectura del software no tiene que ver solamente con la estructura y el comportamiento, sino también con el uso,
la funcionalidad, el rendimiento, la capacidad de adaptación, la reutilización, la capacidad de ser comprendido, las

restricciones económicas y tecnológicas y los compromisos entre alternativas, así como los aspectos estéticos.
Vista de casos de uso: comprende los casos de uso que describen el comportamiento del sistema tal y como es
percibido por los usuarios finales, analistas y encargados de las pruebas.
Vista de diseño: comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y su
solución. Esta vista soporta principalmente los requisitos funcionales del sistema, entendiendo por ellos los servicios que
el sistema debería proporcionar a sus usuarios finales.
Vista de interacción: muestra el flujo de control entre sus diversas partes, incluyendo los posibles mecanismos de
concurrencia y sincronización.
Vista de implementación: comprende los artefactos que se utilizan para ensamblar y poner en producción el sistema
físico.
Vista de despliegue: contiene los nodos que forman la topología hardware sobre la que se ejecuta el sistema.
10.-Cual es el propósito del vocabulario de UML

Un lenguaje proporciona vocabulario y las reglas para combinar palabras de ese vocabulario con el objetivo de
posibilitar la comunicación. En un lenguaje de modelado su vocabulario y reglas se centran en la representación
conceptual y física de un sistema. UML es un lenguaje estándar para los planos software. Proporciona una comprensión
del sistema. Nunca es suficiente un único modelo, para comprender cualquier cosa se necesitan
múltiples modelos conectados entre sí. Para sistemas con gran cantidad de software, se requiere un lenguaje que
abarque las diferentes vistas de la arquitectura de un sistema conforme evoluciona a través del ciclo de vida del
desarrollo de software. El vocabulario y las reglas de un lenguaje como UML indican cómo crear y leer modelos bien
formados pero no dicen qué modelos se deben crear ni cuándo se deberían crear. Esta es la tarea del proceso de
desarrollo de software. Un proceso bien definido guiará a sus usuarios al decidir qué artefactos producir, qué actividades
y qué personal se emplea para crearlos y gestionarlos, y cómo usar esos artefactos para medir y controlar el proyecto de
forma global.

11.- Cuales son las características del diagrama de casos de uso y que actividades realizan en el RUP

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos
de las iteraciones. Su característica son: requisitos, análisis, diseño, implementación, prueba.

12.- Que diferencia existe entre el modelo de dominio y el diagrama de clase

El modelo de dominio captura los tipos más importantes de objetos en el contexto del sistema. Los objetos del dominio
representan las cosas que existen o los eventos que suceden en el entorno en el que trabaja el sistema.

Los diagramas de clases son más utilizados en el modelado de sistemas orientados a objetos. Un diagrama de clases
muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones.

13.- Explicar cada una de las fases del RUP

Consta de cuatro fases: inicio, elaboración, construcción y transición

Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores o
alumnos de un proyecto en el cual tenemos que, identificar los riesgos asociados al proyecto, proponer una visión muy
general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.

Fase de Elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura
base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el
primer análisis del dominio del problema, se diseña la solución preliminar.

Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los
requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan
las mejoras para el proyecto.

Fase de Transición: El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales,
ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte
técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas
involucradas en el proyecto.

14.-Que diferencia existen entre los estereotipos INCLUDE, EXTEND y ASOCIACION de los casos usos,
especificar con ejemplos

251

15.- En el PUDS, que realiza el desarrollo iterativo e incremental y como se realiza la organización del proyecto

Es practico dividir el trabajo en partes más pequeñas o mini proyectos. Cada mini proyecto es una iteración que resulta
en un incremento. Las iteraciones hacen referencia a los pasos en el flujo de trabajo, y los incrementos, al crecimiento
del producto. Para la efectividad máxima, las iteraciones deben estar controladas. Deben seleccionarse y ejecutarse de
una forma planificada. Es por esto por lo que son mini proyectos.

Cada iteración, los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseño utilizando la
arquitectura seleccionada como guía, implementan el diseño mediante componentes y verifican que los componentes
satisfacen los casos de uso.

Cuando una iteración no cumple sus objetivos los desarrolladores revisan decisiones previas y probar con un nuevo
enfoque.

Un proyecto con éxito se ejecutara de una forma directa, solo con pequeñas desviaciones del curso que los
desarrolladores planificaron inicialmente.

Son muchos los beneficios de un proyecto iterativo controlado:

la iteración controlada reduce el coste del riesgo a los costes de un solo incremento.

La iteración controlada reduce el riesgo de no sacar al mercado el producto en el calendario previsto.

La iteración controlada acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los
desarrolladores trabajan de manera mas eficiente para obtener resultados claros a corto plazo, en lugar de tener
un calendario largo, que se prolonga eternamente.

La iteración controlada reconoce una realidad que a menudo se ignora. Que las necesidades del usuario y sus
correspondientes requisitos no pueden definirse completamente al principio. Tipicamente, se refinan en
iteraciones sucesivas. Esta forma de operar hace masfacil la adaptación a los requisistos cambiantes.

16.- Cuando y como se desarrolla un modelo de negocio y un modelo de dominio

Un modelo de dominio se lo desarrolla cuando se está diseñando o modelando un sistema de software y el


modelo de negocio cuando se quiere saber o describir procedimientos sistemáticos de procesos que realiza
el sistema de software.

Como se desarrolla mediante un diagrama de clases

Y el modelo de negocio mediante un diagrama de actividad

Modelo de dominio: El objetivo es comprender y describir las clases más importantes del contexto del sistema

Modelo de negocio: Describe los procesos de negocio de una empresa en términos de casos de uso de negocio y
actores de negocio.

17.-En captura de requisitos que comprende por contexto de sistema

109

18.-Cuales son los objetivos del análisis

168

19.- Explicar la diferencia entre captura de requisitos funcionales y captura de requisitos no funcionales

20.-Describa la entrada y el resultado de priorizar casos de uso

21.-Describir los mecanismos comunes y técnicas comunes del modelado de UML

81

22.- Realizar el flujo de trabajo del análisis


23.-Como sugiere el PUDS distribuir el esfuerzo y el tiempo en una planificación de un proyecto de software

24.-Durante la captura de requisitos según el PUDS a que se denomina factorización

Se denomina factorización de casos de uso cuando organizamos un conjunto de casos de uso en: versiones
especializadas de otros casos de uso, casos de uso incluidos como parte de otros, y casos de uso que se extienden el
comportamiento de otros casos de uso básicos.

25.-Pueden existir casos de uso que solo existan como inclusión o extensión de otros CU y nunca sean
invocados por un actor, sino por los CU que lo incluyen o lo extienden. Justifique su respuesta

Si, estos casos de uso se relacionan de manera indirecta con los actores.

26.- En el modelo de negocio a que se denomina “estado de acción” y “estado de actividad”

Estado de actividad: Un nodo de actividad es una unidad organizativa dentro de una actividad. En general, los nodos de
actividad don agrupaciones anidadas de acciones o de otros nodos de actividad.

Estado de acción: Las acciones no se pueden descomponer. Además, las acciones son atómicas, lo que significa que
pueden ocurrir eventos, pero el comportamiento interno de la acción no es visible. No se puede ejecutar una parte de
una acción; o se ejecuta o no se ejecuta.

27.-Explicar los tipos de diagramas de UML y clasificarlo

DIAGRAMAS DE COMPORTAMIENTO: Permiten exhibir comportamientos de un sistema o de los procesos de las


organizaciones.

Diagrama de Estados

Diagrama de Actividades

Diagrama de Casos de Uso

DIAGRAMA DE INTERACCION: Es un subconjunto de los diagramas de comportamiento que permiten enfatizar las
interacciones entre los objetos.

Diagrama Secuencia

Diagrama Comunicación (antes de Colaboración)

Diagrama de Tiempos

DIAGRAMAS DE ESTRUCTURA: Muestran los elementos de una especificación que sean independientes del tiempo.

Diagrama de Clases

Diagrama de Estructura Compuesta

Diagrama de Componentes

Diagrama de Despliegue

Diagrama de Objetos

Diagrama de Paquetes

Diagrama de Artefactos

28.-Que es el modelo de negocio, realizar un ejemplo con todos sus elementos y relaciones

29.-Bajo qué criterios decide usar los estereotipo <<uses>> y <<extiende>> en un diagrama de casos de uso

Use: Es el estereotipo de dependencia más común. Ésta dependencia esta generada por cualquier de los siguientes
casos:
Una operación de clase A necesita un parámetro de la clase B.

Una operación de clase A devuelve un valor de la clase B.

Una operación de clase A utiliza un objeto de clase B en algún lugar en su implementación, pero no como
atributo.

Extend: Se emplea para especificar exactamente qué puntos de extensión en el caso de uso se están extendiendo.
Engancha nuevos comportamientos.

Cuando se utiliza <<extend>> el caso de uso base actúa como un marco de trabajo modular en el que conectar
extensiones en puntos de extensión definidos.

30.-Es posible tener un caso de uso que no tenga ningún actor

Sí, es posible que un caso de uso no se encuentre relacionado de forma directa con un actor si no a través de otra que la
contenga.

31.-Un caso de uso representa a un requerimiento funciona

Si, un caso de uso representa un requisito funcional del sistema global. Es decir, describe un conjunto de secuencias
donde cada secuencia representa la interacción de los elementos externos (sus actores) con el propio sistema (y con sus
abstracciones claves).

32.-Como representa el diseño modular con UML

UML realiza el diseño modular a través de una arquitectura en capas.

Capa de presentación: la que ve el usuario (también se la denomina "capa de usuario"),

Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las
respuestas tras el proceso

Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos.

33.-Concepto de diagrama de despliegue

Un diagrama de despliegue es un diagrama que muestra la configuración de los nodos de procesamiento en tiempo de
ejecución y de los artefactos que residen en ellos. Los diagramas d despliegue abordan la vista de despliegue estática de
una arquitectura. Normalmente, un nodo alberga uno o más artefactos. Gráficamente, un diagrama de despliegue es una
colección de nodos y arcos.

34.-Concepto de diagrama de componente

Un diagrama de componentes representa la encapsulación de una clase, junto con sus interfaces, puertos y estructura
interna, la cual está formada por otros componentes anidados y conectores. Los diagramas de componentes cubren la
vista de implementación estática del diseño de un sistema. Son importantes para construir sistemas más grandes a partir
de partes pequeñas.

También podría gustarte