2015

Resumen Parcial N° 2: ASI

Digliodo, Mateo - Legajo: 11229

Gómez, Julián - Legajo: 11438
15-10-2015
Contenido
Workflow de Requisitos. 3
1. Defina el propósito del WF de Modelado de Requisitos. 3
2. ¿En qué fases del ciclo de vida del Proceso Unificado se desarrolla el
Workflow de requisitos? 3
3. Mencione y explique los pasos a seguir en el descubrimiento y modelado
de requisitos. 3
4. Mencione cuáles son las actividades, artefactos y trabajadores del WF de
requisitos. 3
Modelado de Casos de Uso 4
5. ¿Qué permite modelar el Diagrama de Casos de Uso del SI? ¿Qué vista
constituye del sistema? 4
7. Defina qué es un Actor, mencione aquellas cosas pueden llegar a ser
actores del sistema. 5
8. ¿Qué distinción hay entre trabajador y rol? Dar un ejemplo. 5
9. ¿Qué es un actor secundario? 5
10. ¿Qué es un caso de uso del SI? ¿Qué representa en el diagrama de casos
de uso del SI? 5
11. Explicar que es una instancia de un caso de uso. 5
12. Explica y da ejemplos de: caso de uso concreto y caso de uso abstracto. 5
13. ¿Qué tipo de relaciones existe entre los casos de uso del SI? Explique y
ejemplifique cada una. 6
14. Explicar con un ejemplo la forma en la que se derivan los requerimientos
de un sistema de información a partir de un modelo de negocio. 7
15. ¿Qué relación existe entre los requerimientos de un sistema de
información y el diagrama de clases? 7
16. Enumerar y explicar cuáles son los artefactos involucrados en la captura
de requisitos con casos de uso. 7
17. ¿Qué vista muestra del sistema la descripción de los casos de uso? 7
La descripción de los casos de uso muestra la vista externa del sistema. 7
18. Explicar la actividad del flujo de trabajo de requisitos: Detallar un caso de
uso. Enumerar en función de su experiencia práctica los “tips” más
importantes a considerar en esta descripción. 7
Prototipos de Interfaz 7
19. Detallar la importancia del artefacto: prototipo de interfaz en el flujo de
trabajo de requisitos. 8
20. ¿Qué cantidad de Prototipos de Interfaz pueden existir en relación a los
casos de uso? 8
 21. Explique los tipos de enfoques para la construcción de prototipos en el
proceso del software. 8
22. Explique qué son los prototipos de tecnología básica y los de alta
tecnología. Indique las 9
23. ¿Cuáles son las técnicas para la revisión de los prototipos con los
usuarios? 10
24. Mencione y explique tres criterios para un buen diseño de interfaz. 10
Patrones 10
26. ¿Qué son los patrones? 10
27. ¿Qué características debe poseer un buen patrón? 10
28. ¿Qué indica el patrón fundamental para la construcción del modelo de
objetos del dominio? 11
29. ¿Qué son los patrones transaccionales? Dé un ejemplo. 11
30. ¿Cuáles son las categorías de los patrones de caso de uso? Explique. 11
31. Elija un sistema de información específico y ejemplifique el uso de los
siguientes patrones: 11
Workflow de Análisis 11
32. Defina el propósito del WF de Análisis. 11
33. ¿Qué tipo de vista brinda este workflow? 12
34. ¿En qué fases del ciclo de vida del Proceso Unificado se desarrolla el
workflow de análisis? 12
35. Mencione cuáles son las actividades, artefactos y trabajadores del WF de
análisis. 12
36. ¿Qué representan las clases del análisis y cuáles son sus tipos? 13
37. ¿Para qué se utilizan los paquetes? 13
38. ¿Qué características son deseables que tengan los paquetes? 13
39. Explique en qué consiste la Realización de un caso de uso. 13
40. ¿Qué son los diagramas de interacción? 14
41. ¿Cuál es la utilidad del diagrama de comunicación? 14
Workflow de Requisitos.
1. Defina el propósito del WF de Modelado de Requisitos.
El propósito fundamental del flujo de trabajo de requisitos es guiar el proceso de desarrollo
hacia el sistema correcto. Esto se consigue mediante una descripción de los requerimientos del
sistema suficientemente buena como para que pueda llegarse a un acuerdo entre el cliente
(incluyendo a los usuarios) y los desarrolladores sobre que debe y que no debe hacer el sistema.

2. ¿En qué fases del ciclo de vida del Proceso Unificado se desarrolla el Workflow
de requisitos?
El Workflow de requisitos se desarrolla principalmente en las fases de inicio y
elaboración. Una pequeña parte del trabajo se realiza en la fase de construcción. Se encarga de
recoger y organiza los requisitos funcionales y no funcionales.

3. Mencione y explique los pasos a seguir en el descubrimiento y modelado de

requisitos.
 Enumerar los requisitos candidatos: se realiza una lista de ideas, que son un conjunto
de requisitos candidatos que podemos decidir implementar en una versión futura del sistema.
Esta lista se utiliza solo para la planificación del trabajo. Cada una tiene un nombre corto y una
breve explicación o definición.
 Comprender el contexto del sistema: para obtener un conocimiento firme del contexto
en el que se emplaza el sistema se utiliza:
Modelado del dominio: describe los conceptos importantes del contexto como objetos del
dominio, y enlaza estos objetos unos con otros.
Modelado del negocio: permite describir los procesos con el objetivo de comprenderlos.
 Capturar requisitos funcionales: la técnica que se utiliza para identificar los requisitos
del sistema son los CU. Estos capturan tanto los requisitos funcionales como los no funcionales
que son específicos de cada CU.
 Capturar requisitos no funcionales: es una lista de requisitos adicionales. Los requisitos
no funcionales especifican propiedades del sistema, como restricciones del entorno o de la
implementación, rendimiento, dependencias de la plataforma, facilidad de mantenimiento,
extensibilidad y fiabilidad.

4. Mencione cuáles son las actividades, artefactos y trabajadores del WF de

requisitos.
 Los artefactos son:
Modelo de CU: El modelo de CU permite que los desarrolladores de software y los clientes
lleguen a un acuerdo sobre los requerimientos que debe cumplir el sistema. Un modelo de CU
es un modelo del sistema que contiene actores, CU y sus relaciones.
Descripción de la arquitectura (vista del modelo de CU): La descripción de la arquitectura
contiene una vista de la arquitectura del modelo de CU, que representa los CU significativos
para la arquitectura.
La vista de la arquitectura del modelo de CU debería incluir los CU que describan alguna
funcionalidad importante y crítica, o que impliquen algún requisito importante.
Glosario: Podemos utilizar un glosario para definir términos comunes importantes que se
utilizan al describir el sistema y deben ser entendidos por las personas implicadas en el
proyecto. Un glosario es muy útil para alcanzar un consenso entre los desarrolladores y para
reducir en general el riesgo de confusiones.
Prototipo de interfaz de usuario: Los prototipos de interfaz de usuario nos ayudan a
comprender y especificar las interacciones entre actores humanos y el sistema durante la
captura de requisitos. Nos ayuda a comprender mejor los CU.
  Los trabajadores son:
Analista de sistemas: El analista de sistemas es el responsable del conjunto de requerimientos
que están modelados en los CU, lo que incluye todos los RF y RNF. También es el responsable
de delimitar el sistema, encontrando los actores y los CU. El analista de sistemas no es
responsable de cada CU en particular; esto es responsabilidad del especificador de CU.
Especificador de CU: El especificador de CU es el encargado de describir detalladamente uno o
más CU.
Diseñador de interfaz de usuario: Los diseñadores de interfaces de usuario dan forma visual a
las interfaces de usuario. Esto puede implicar el desarrollo de prototipos de interfaces de
usuario para algunos CU.
Arquitecto: El arquitecto participa en el FTR para describir la vista de la arquitectura del
modelo de CU.
 Los actividades son:
Encontrar actores y CU: La identificación de actores y CU es la actividad más decisiva para
obtener adecuadamente los requerimientos, y es responsabilidad del analista de sistemas.
Una vez que se han identificado los actores y CU, se procede a hacer una descripción breve de
cada CU. Por último, lo que se hace es una descripción completa del modelo de CU.
Priorizar CU: El propósito de esta actividad es proporcionar una priorización de CU para
determinar cuáles son necesarios para el desarrollo en las primeras iteraciones, y cuales pueden
dejarse para más tarde. Los resultados se recogen en la vista de la arquitectura del modelo de
CU.
Detallar un CU: El objetivo principal de detallar cada CU es describir su flujo de sucesos en
detalle, incluyendo cómo comienza, termina e interactúan con los actores. El especificador de
CU detalla paso a paso la descripción de cada CU en una especificación precisa de la secuencia
de acciones.
Prototipar la interfaz de usuario: El objetivo de esta actividad es construir un prototipo de
interfaz de usuario. El resultado final de esta actividad es un conjunto de esquemas de
interfaces de usuario y prototipos de interfaces de usuario que especifican la apariencia de esas
interfaces de cara a los actores más importantes.
Estructurar el modelo de CU: El modelo de CU se estructura para:
-Extraer descripciones de funcionalidades generales y compartidas que pueden ser utilizadas
por descripciones más específicas (generalizaciones).
-Extraer descripciones de funcionalidad adicionales u opcionales que pueden extraer
descripciones más específicas (inclusiones y extensiones).

Modelado de Casos de Uso

5. ¿Qué permite modelar el Diagrama de Casos de Uso del SI? ¿Qué vista constituye
del sistema?
El diagrama de CU permite modelar el comportamiento de un sistema o subsistema. Un
diagrama de casos de uso constituye la vista estática y externa del sistema de información.

6. Hay dos posibilidades para iniciar la captura de requisitos; esto es desde

la visión del negocio y la derivación a partir de este o desde la captura
directa de requisitos de información. Explicar los momentos en los que se
utilizan cada uno.
Las dos diferentes posibilidades para iniciar la captura de requisitos queda determinada según
la noción que tengan los clientes de lo que debería hacer el sistema. Cuando el cliente tiene una
vaga noción de lo que debería hacer, el analista debería capturar los requisitos desde la visión
del negocio y la derivación a partir de este, haciendo un modelo de negocio o comenzando con
uno que ya está desarrollado. En caso contrario, el cliente puede realizar una especificación de
requisitos completa y detallada. Es decir, depende de que tan complejo sea el proyecto, de que
tanto lo conozco.

7. Defina qué es un Actor, mencione aquellas cosas pueden llegar a ser actores del
sistema.
Un actor es el rol que juega un usuario en relación al sistema. Normalmente, un actor del
sistema representa un rol que es jugado por una persona, un dispositivo de hardware o incluso
otro sistema al interactuar con nuestro sistema.

8. ¿Qué distinción hay entre trabajador y rol? Dar un ejemplo.

La diferencia es que en este caso se refiere en que un trabajador es un empleado del negocio,
quien lleva a cabo el proceso de negocio y el rol el papel que cumple como usuario del sistema
de información, es decir qué funcionalidades podrá utilizar del mismo.
Ejemplo de trabajador: Vendedor
Ejemplo de rol: Encargado de venta
Un actor es el rol que juega un usuario en un CU al interactuar con nuestro sistema. Cada rol
(actor) define lo que hace un trabajador del negocio en un proceso concreto. Cada vez que un
usuario en concreto interactúa con el sistema, la instancia correspondiente del actor está
desarrollando ese papel. Una instancia de un actor es, un usuario concreto que interactúa con el
sistema. Existen actores primarios que tiene un objetivo claro y actores secundarios que ayudan
a los primarios. Ej.: jefe de vendedores, administrador del sistema, encargado de recepción, etc.

9. ¿Qué es un actor secundario?

 Actor Primario: Tiene un objetivo claro que debe ser tenido en cuenta y concretado con
la ayuda del sistema de información. Son los actores que activan los CU.
 Actor Secundario: Es de quién el sistema necesita ayuda para cumplir con el objetivo
del actor primario. Estos actores interactúan con el caso de uso después de haberse
activado.

10. ¿Qué es un caso de uso del SI? ¿Qué representa en el diagrama de casos de uso
del SI?
Un caso uso del SI representa cada forma en que los actores usan el sistema. Los casos de uso
son fragmentos de funcionalidad que el sistema ofrece para aportar un resultado de valor para
sus actores.
El diagrama de CU representa un conjunto de CU, actores y sus relaciones, que permiten
visualizar, especificar y documentar el comportamiento de un elemento.

11. Explicar que es una instancia de un caso de uso.

Una instancia de caso de uso es la realización o ejecución de un caso de uso.

12. Explica y da ejemplos de: caso de uso concreto y caso de uso abstracto.
 CU concreto: es aquel CU que es instanciado por sí solo, por iniciativa de un actor o de
un trabajador de negocio.
 CU abstracto: es aquel CU que no es instanciado por sí solo, sino que es instanciado por
otro CU (por inclusión o extensión).
 CU: esenciales: describen la funcionalidad principal o esencial con la que tiene que
cumplir el sistema.
 CU de soporte: comprenden la funcionalidad que surge a partir de analizar aquello que
se necesita para que puedan funcionar los CU esenciales.
Ejemplo: El CU “pedir menú” es iniciado por el actor cliente por lo que es concreto; el CU
“elegir menú” es iniciado por el CU “pedir menú” por lo que es abstracto.

13. ¿Qué tipo de relaciones existe entre los casos de uso del SI? Explique y
ejemplifique cada una.
 Relaciones de extensión: es una relación desde un CU de extensión a un CU base, donde
el comportamiento definido en el CU de extensión puede der insertado en el comportamiento
definido por el CU base. La ejecución del CU es opcional, al ejecutarse el CU base, el CU de
extensión sólo se ejecutará bajo ciertas condiciones.

uc Actores

registrar pedido
armado

«extend»
consultar pedidos
responsable de pedidos pendientes

«extend»
registrar entrega de
pedido

 Relación de inclusión: es una relación desde un CU base a un CU de inclusión, donde el

comportamiento definido en el CU de inclusión es explícitamente insertado en el
comportamiento definido en el CU base. La relación no es opcional, por ello, al ejecutarse el CU
base, siempre se ejecutará el CU de inclusión.
uc Actores

reserv ar pieza

«include»

actualizar reserv a

recepcionista de hotel
«include»

eliminar reserv a

 Relación de generalización: es una relación de un CU hijo a un CU padre, donde el hijo

hereda todo el comportamiento y características descriptas por el padre.
 uc Actores

registrar v enta de
contado

registrar v enta

v endedor

registrar v enta con

tarj eta

14. Explicar con un ejemplo la forma en la que se derivan los requerimientos de un

sistema de información a partir de un modelo de negocio.

15. ¿Qué relación existe entre los requerimientos de un sistema de información y el

diagrama de clases?
Los requerimientos de un SI descubiertos son los más relevantes del dominio, y estos van a
pasar a ser clases del diagrama de clase.

16. Enumerar y explicar cuáles son los artefactos involucrados en la captura de

requisitos con casos de uso.
• casos de uso (pregunta 10)
• actores: representa un rol jugado en relación al negocio, por algo o alguien en el entorno
del negocio. Varios usuarios físicos pueden jugar el mismo rol; y un mismo usuario puede
actuar como varios actores diferentes.
• prototipos de interfaces de usuario (pregunta 4)
• glosario (pregunta 4)
• modelo de dominio: representa las “cosas” que existen o los “eventos” que suceden en
el entorno del sistema. La herramienta que se utiliza para desarrollarse en el diagrama de clase.
• descripción de la arquitectura(pregunta 4)

17. ¿Qué vista muestra del sistema la descripción de los casos de uso?
La descripción de los casos de uso muestra la vista externa del sistema.

18. Explicar la actividad del flujo de trabajo de requisitos: Detallar un caso de uso.
Enumerar en función de su experiencia práctica los “tips” más importantes a
considerar en esta descripción.

Prototipos de Interfaz
Un prototipo es una versión inicial de un sistema de software que se utiliza para demostrar los
conceptos, probar las opciones de diseño y, enterarse más acerca del problema y sus posibles
soluciones. El desarrollo rápido de prototipos es esencial puesto que se controlan los costos, y
los usuarios pueden experimentar con el prototipo en las primeras etapas del proceso de
software. Un prototipo de software apoya dos actividades del proceso de ingeniería de
requerimientos:
  Obtención de requerimientos: los prototipos del sistema permiten a los usuarios
experimentar para ver como este ayuda a su trabajo. Les permite adquirir nuevas ideas para los
requerimientos y encontrar aéreas fuertes y débiles de software. Entonces pueden proponer
nuevos requerimientos del sistema
 Validación de requerimientos: el prototipo puede revelar errores y omisiones en los
requerimientos propuestos. Una función descripta en una especificación podría parecer útil y
bien definida. Sin embargo, cuando la función se utiliza con otras, a menudo los usuarios
encuentran que su visión inicial fue incorrecta o incompleta. La especificación del sistema
podría modificarse para reflejar el cambio en la comprensión de los requerimientos.

19. Detallar la importancia del artefacto: prototipo de interfaz en el flujo de trabajo

de requisitos.
Los prototipos de interfaz de usuario se utilizan para completar definición de la funcionalidad
del sistema, que acompaña la descripción de los casos de uso y es de gran importancia, ya que
se puede mostrar a través de ella al usuario la cara visible del sistema.

20. ¿Qué cantidad de Prototipos de Interfaz pueden existir en relación a los casos
de uso?
En relación a los casos de uso pueden existir: una o más de una GUI.

21. Explique los tipos de enfoques para la construcción de prototipos en el proceso

del software.
ENFOQUE USOS VENTAJAS DESVENTAJAS
evolutivos Se proporciona Es utilizado en Entrega acelerada Problemas de
al usuario un aquellos del sistema: el administración:
sistema sistemas que ritmo de cambio en evolucionan tan
incompleto y son difíciles o los negocios rápidamente que no
después imposibles de implica que la es costeable producir
modificarlo y especificar. ayuda del software una gran cantidad de
aumentarlo en Actualmente, es debe estar documentación del
el momento en usado para el disponible sistema. También se
que los desarrollo de rápidamente. En requiere el uso de
requerimientos sitios Web y algunos casos, esta tecnologías no tan
del usuario sean aplicaciones de entrega y la familiares. Donde es
claros. comercio usabilidad son más difícil encontrar
Finalmente, se electrónico. importantes que los personal que posea
convierte en el detalles de las habilidades
sistema funcionalidad o el requeridas.
requerido. mantenimiento del Problemas de
software a largo mantenimiento: los
lazo. cambios continuos
Compromiso del tienden a corromper
usuario con el la estructura del
sistema: involucrar prototipo, y nadie,
el usuario con el excepto los
proceso de desarrolladores
desarrollo no sólo originales, pueden
significa que el entenderla. Es difícil
sistema encontrar personas
probablemente capacitadas para dar
cumple sus mantenimientos.
requerimientos,
 sino que los Problemas
usuarios finales del contractuales: el
sistema tiene que modelo contractual
hacer un normal entre un
compromiso con él cliente y un
y hacer que éste desarrollador de
llegue a funcionar. software se basa en la
especificación del
sistema. Cuando no
existe la
especificación, es
difícil diseñar un
contrato para el
desarrollo del
sistema.

desechables Se lo construye Se utiliza para Extiende el proceso Las características

para ayudar el sistemas de de análisis de importantes se
análisis y hardware para requerimientos, excluyen del
validación de verificar el reduciendo los prototipo para
requerimientos. diseño antes de costos del ciclo de simplificar la
Después de la que se hagan vida completo. implementación
evaluación, el compromisos Clarifica los rápida.
prototipo ya no para construir requerimientos y Una implementación
es útil y se el sistema. provee información no tiene un valor
descartaría y se También se usa adicional a los legal para el contrato
construiría un para ayudar a administradores entre el cliente y el
sistema de desarrollar los para valorar los contratista.
calidad. requerimientos riesgos del proceso. No se pueden probar
del sistema. de manera adecuada
los requerimientos no
funcionales en el
prototipo.
El prototipo
desechable ejecutable
no se utiliza como el
sistema final
entregado.
Los administradores
presionan a los
desarrolladores para
que entreguen los
prototipos
desechables para su
utilización.

22. Explique qué son los prototipos de tecnología básica y los de alta tecnología.
Indique las ventajas y desventajas en el uso de cada uno.
 Prototipos de tecnología básica: es la creación de prototipo más simple. Se utiliza hojas
de papel, procesador de textos, herramientas de dibujo o un pizarrón blanco para construir el
prototipo.
Es barato, rápido y satisface el objetivo de la creación de prototipos en la fase de análisis.
Además es de bajo costo para realizar cambio.
  Prototipos de alta tecnología: es un prototipo que evolucionará hacia un sistema
terminado. El sistema se codifica en forma progresiva, comenzando con la disposición de
interfaz y añadiendo luego más y más detalles para dar mayor vida al sistema.
Se utilizan herramientas de desarrollo GUI, donde deben instalarse una base de datos
relacional antes de hacer ventanas que sean capaces de ser reutilizadas en la aplicación final, lo
que produce costos al hacer cambios en el prototipo. Se utiliza para aplicaciones muy pequeñas.

23. ¿Cuáles son las técnicas para la revisión de los prototipos con los usuarios?
 Animación (sobre todo para juegos)
 Revisión con el usuario
 Prototipo
 Sistema experto

24. Mencione y explique tres criterios para un buen diseño de interfaz.

 Realmente introduce a los usuarios en el proyecto. Alguien le dirá al analista acerca de
un evento que hasta ese momento no se había mencionado. También añadirá conceptos de
datos a la ventana que no se mencionaron durante las entrevista y posiblemente elimine
algunos por irrelevantes.
 Causará que salgan a la superficie los asuntos de los procesos de negocio. Tal vez se
encuentre que personas que realizan la misma tarea en forma diferente. El nuevo sistema puede
eliminar la captura de datos redundantes en hojas de cálculo o en sistemas auxiliares o alterar o
eliminar la descripción de trabajo de alguien.
 El prototipo permite que se exploren ambientes de destino posibles. Tal vez la interfaz
gráfica no sea lo óptimo para su aplicación particular. Se puede explorar como se vería la
interfaz con dispositivos portátiles pequeños, lectores de código de barra, una página web o las
antiguas pantallas verdes de caracteres.
25. ¿Bajo qué circunstancias se recomienda que la construcción de prototipos sea utilizada como
un medio para validar los requerimientos del sistema?
Se recomienda que la construcción de prototipos sea utilizada como un medio para validar los
requerimientos del sistema cuando los clientes y los usuarios finales encuentran muy difícil
expresar sus requerimientos reales. Es casi imposible predecir la manera en que un sistema
afectará el trabajo diario, como interactuará con los otros sistemas y qué operaciones se deberán
automatizar. / En la construcción de prototipos de interfaces de usuario basadas en la WEB las
páginas WEB pueden incluir botones, campos, formularios, links y objetos multimedia.

Patrones

26. ¿Qué son los patrones?

Los patrones examinan los problemas que enfrentan las personas al escribir casos de uso y
describen las soluciones simples, elegantes y probadas para los problemas específicos de la
escritura de casos de uso en proyectos reales./ Ayudan a establecer la estructura funcional del
sistema./ los patrones realizan una descripción del problema que ocurre y como solucionarlo.

27. ¿Qué características debe poseer un buen patrón?

 plantea una solución al problema
 provee conceptos (captura soluciones)
 permite derivar soluciones desde primeros principio
 describe relaciones
 debe tener en cuenta el componente humano
28. ¿Qué indica el patrón fundamental para la construcción del modelo de objetos
del dominio?
El patrón fundamental indica la plantilla que todos los patrones siguen para la construcción del
modelado de objetos del dominio.

29. ¿Qué son los patrones transaccionales? Dé un ejemplo.

Los patrones transaccionales son aquellos patrones que tienen un jugador de transacción o
tienen jugadores que comúnmente juegan con un jugador de transacción.
Los patrones transaccionales son:
1. actor-participante
2. participante-transacción
3. lugar-transacción
4. ítem especifico-transacción
5. transacción-detalle transacción
6. transacción-transacción subsiguiente
7. detalle transacción-detalle transacción subsiguiente
8. ítem-detalle transacción
9. ítem especifico-detalle transacción
10. ítem-ítem especifico
11. asociación-otra asociación
12. ítem especifico-jerarquía de ítem

30. ¿Cuáles son las categorías de los patrones de caso de uso? Explique.
 Patrones estructurales: describen los componentes básicos de los CU, cómo deberían
estar organizados y ofrecen criterios para juzgar su uso.
 Patrones de desarrollo: describen características de prácticas de escritura de CU
probadas y ofrecen criterios para medir la calidad del proceso de escritura.

31. Elija un sistema de información específico y ejemplifique el uso de los

siguientes patrones:

a. VerbPhraseName
b. TechnologyNeutral
c. ClearCastOfCharacters
d. ScenarioPlusFragments
e. ActorIntentAccomplished

Workflow de Análisis
32. Defina el propósito del WF de Análisis.
El propósito es conseguir una mejor compresión más precisa de los requerimientos que se
describieron en la captura de requisitos (o workflow de requisitos), refinándolos y
estructurándolos.
El lenguaje que se utiliza en el análisis se basa en un modelo de objeto que se denomina modelo
de análisis, y nos permite refinar los requisitos y razonar sobre los aspectos internos del sistema.
La estructura del sistema que se obtiene en la actividad de análisis está basada en clases y
paquetes y nos da una vista interna del sistema.
Algunas características del modelo de análisis son:
 Proporcionar una vista interna del sistema
 Está estructura por clases y paquetes
 Es utilizado fundamentalmente por los desarrolladores para comprender cómo debería
darse forma al sistema.
 Plantea cómo llevar a cabo la funcionalidad dentro del sistema, sirve como una primera
aproximación al diseño.
 Define realizaciones de CU y cada una de ellas representa el análisis de un CU.
 Los artefactos son orientados a los desarrolladores.

33. ¿Qué tipo de vista brinda este workflow?

Brinda la vista interna del sistema.
Nos va a mostrar como el sistema debe interactuar con los objetos y el paso de mensajes entre
ellos.

34. ¿En qué fases del ciclo de vida del Proceso Unificado se desarrolla el workflow
de análisis?
El trabajo principal empieza hacia el final de la fase de inicio y el foco principal de la fase de
elaboración, junto con construccion.

35. Mencione cuáles son las actividades, artefactos y trabajadores del WF de

análisis.
 Los artefactos claves son:
i. Clases de análisis: tenemos clases de entidad, de interfaz, control.
ii. Realizaciones de CU: éstas ilustran como las instancias de clases de análisis
pueden interactuar para realizar el comportamiento del sistema especificado por
un CU. Diagrama de comunicación, interacción.
iii. Modelo de análisis: Todo lo que realicemos, compuesto por las realizaciones de
caso de uso, por las clases de análisis y por los paquetes.
iv. Descripción de la arquitectura (vista del modelo de análisis): Diferentes vistas
del sistemas, vistas internas, externas, estáticas, dinámicas, etc. (Diagrama de
clases, vista estática).
v. Paquete del análisis: metemos los elementos que tengan ciertas características y
similitudes en común. (Herramienta que organiza las clases de análisis).
Propiedades: Altamente cohesivos (Los elementos deben estar altamente
relacionados) y débilmente acoplados (tiene que ver con la dependencia que
puede haber entre un paquete u otro, hay que tratar de llevarlas al mínimo, una
cosa que toquemos en uno, desencadena cambios en otros).
 Los trabajadores son:
Arquitecto: es el responsable de la integridad del modelo de análisis, garantizando que éste sea
correcto, consistente y legible como un todo. Es responsable de lo que es significativo para la
arquitectura (descripción de la arquitectura).
Ingeniero de CU: es el responsable tanto del análisis como del diseño del CU, garantizando que
cumplen los requerimientos que recaen sobre ellos.
Ingeniero de componentes: se encarga de analizar una o varias clases y también de analizar uno
o varios paquetes, garantizando que sus contenidos son correctos.
 Las actividades son:
Análisis de arquitectura: su propósito es esbozar el modelo de análisis y la arquitectura
mediante la identificación de paquetes del análisis, clases del análisis y requisitos especiales.
Analizar un CU: se refina cada CU como colaboración de clases de análisis.
Analizar una clase
Analizar un paquete

36. ¿Qué representan las clases del análisis y cuáles son sus tipos?
Las clases de análisis representan conceptos clave en el dominio de negocio. Algunas de sus
características son:
 Se centra en el tratamiento de los requisitos funcionales.
 Su comportamiento se define mediante responsabilidades
 Define atributos, también de un nivel alto de abstracción. Normalmente son conceptuales y
reconocibles en el dominio del problema.
 Participa en relaciones, también del tipo conceptual,
Los distintos tipos don:
 Clases de interfaz: se utilizan para modelar la interacción entre el actor y el sistema.
Esta interacción implica un intercambio de información y de solicitudes. Representan
normalmente abstracciones de ventanas, formularios, paneles, interfaces de comunicaciones,
impresoras, sensores, terminales, manteniéndose de todos modos en un nivel bastante
conceptual. (Permite la entrada y salida de los datos).
 Clases de entidad: se utilizan para modelar información que posee una larga vida y que
es a menudo persistente. En la mayoría de los casos, las clases de entidad se derivan
directamente desde el modelo del dominio. Representan los objetos relevantes en el dominio del
problema.
 Clases de control: representan coordinación, secuencia, transacciones y control de otros
objetos y se usan con frecuencia para encapsular el comportamiento específico de un CU. Sirve
para modelar los aspectos dinámicos del sistema, debido a que manejan y coordinan las
acciones y los flujos de control principales y delegan trabajo a otros objetos (de interfaz y de
entidad).

37. ¿Para qué se utilizan los paquetes?

Los paquetes de análisis se utilizan para organizar los artefactos del modelo de análisis en
piezas manejables, además permiten crear límites semánticos en el modelo donde diferentes
paquetes describen diferentes aspectos de la funcionalidad del sistema.

38. ¿Qué características son deseables que tengan los paquetes?

Los paquetes deberían ser altamente cohesivos (es decir sus contenidos deberían estar
fuertemente relacionados) y débilmente acoplados (es decir, las dependencias de unos con otros
deberían ser mínimas).

39. Explique en qué consiste la Realización de un caso de uso.

 Muestran cómo las instancias de las clases de análisis pueden interactuar para realizar el
comportamiento del sistema especificado por un caso de uso (vista dinámica).
 Muestra el comportamiento de un CU, indicando las interacciones entre las clases del
análisis.
Una realización de un caso de uso consta de:
 diagramas de clase de análisis
 diagramas de interacción
 requisitos especiales.
  mejora del caso de uso

40. ¿Qué son los diagramas de interacción?

Un diagrama de interacción muestra una interacción, que consiste en un conjunto de objetos y
sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos. En la realización de
CU se utilizan específicamente para modelar interacciones entre objetos que realizan un CU o
parte de un CU. Estos no solo son importantes para modelar los aspectos dinámicos de un
sistema, sino también para construir sistemas ejecutables. Hay cuatro diagramas de interacción,
cada uno de los cuales enfatiza un aspecto diferente de la interacción:
 Diagrama de comunicación: enfatiza las relaciones estructurales entre objetos y la
colaboración existente entre ellos. (Nos va a mostrar para un caso de uso, quien es el
actor que instancia el caso de uso, cuales son las clases y como se comunican esas clases
entre sí).
 Diagrama de secuencia: enfatizan la secuencia de envío de mensajes ordenada en el
tiempo entre líneas de vida.
 Diagrama de visión de interacción: caso especial de diagrama de actividad en el que los
nodos hacen referencia a otras interacciones.
 Diagrama de tiempo: enfatizan los aspectos en tiempo real de una interacción.

41. ¿Cuál es la utilidad del diagrama de comunicación?

Los diagramas de comunicación se utilizan para destacar la organización de los objetos que
participan en una interacción. Enfatizan las relaciones estructurales entre objetos que participan
en una interacción.

Su objetivo es identificar responsabilidades de los objetos y no tiene tanta importancia la

secuencia detallada y ordenada cronológicamente.
Se construyen colocando en primer lugar los objetos que participan en la comunicación como
nudos del grafo. A continuación se representan los enlaces que conectan esos objetos como
arcos del grafo. Por último, esos enlaces se “adornan” con los mensajes que envían y reciben los
objetos.