FB

Unidad N° 1 Modelado de negocios.

4- ¿Qué son los modelos y para que se construyen?

Un modelo es una representación abstracta de un objeto que existe o

esta por existir, se pueden construir distintos modelos de una misma
cosa. Sirven para entender lo que se está modelando.

5- ¿En que ayudan los modelos a los analistas?

• Predecir el comportamiento del sistema.

• Revisar en que punto del desarrollo nos encontramos.
• Permiten tener documentado el sistema.

6- Características de los modelos

• Deben ser gráficos, con detalles textuales apropiados.

• Deben permitir que el sistema sea visto en partes.
• Deben tener redundancia mínima.
• Deben ayudar al lector a predecir el comportamiento del sistema.
• Deben ser transparentes para el lector.

7- ¿Cuáles son las ventajas de usar modelos?

• Ayudan a establecer el foco de atención en los aspectos principales

del proceso modelado, ayudando de esta forma a evitar las
distracciones que puedan generarse.
• Permiten discutir cambios a bajo costo.
• Ahorro de tiempo en la preparación.
• Permiten analizar y experimentar situaciones complejas.
• Permiten verificar que el analista comprendió lo que se le pidió.

1
 FB

8- ¿Qué es el modelado de negocio?

El modelado de negocios es una técnica que permite comprender los

procesos de negocio de las organizaciones, además muestran como
interactúa la organización con su ambiente.

9- ¿Por qué necesitamos modelar el negocio?

Es importante modelar el negocio porque debemos entender el contexto

en el cual se va a incluir el sistema de información. De allí vamos a
obtener los usuarios del negocio, quienes posteriormente serán los
usuarios del SI.
Por medio del modelado vamos a poder conocer todos los procesos de
negocio, y también los diferentes tipos de documentos que se producen
en cada proceso.

10- ¿Cuáles son los propósitos del modelado de negocio?

a. Entender la estructura y dinámica de la organización en la que se

desarrollará el sistema.
b. Comprender los problemas reales e identificar potenciales mejoras.
c. Asegurar que los usuarios y los desarrolladores entendieron lo mismo
respecto de la organización.
d. Derivar los requerimientos del sistema.

11- ¿Cómo está formado el modelo de negocios y que muestra c/u?

2
 FB

12- ¿Qué es el BPMN? ¿Qué promueve?

BPMN es una disciplina que se ocupa de modelar, automatizar, manejar y

optimizar procesos para incrementar la rentabilidad de un negocio,
promueve:
• Agregar valor al cliente.
• Incorporar el concepto de calidad en los procesos.
• Tener procesos controlados.
• Definir un elemento que permita medir el desempeño y la eficiencia.
• Posibilitar la certificación en normas de calidad.
• Conocer lo que hacemos y como lo hacemos para mejorar
continuamente.

13- ¿Por qué usar BPMN?

Porque es un estándar internacional de modelado de procesos aceptado

por la comunidad, es independiente de cualquier metodología de
modelado de procesos, permite modelar los procesos de manera
unificada permitiendo un entendimiento a todas las personas de la
organización.

14- ¿Qué es la gestión de procesos?

Es una técnica de gestión que ayuda a los dueños de procesos a

identificar, diseñar, formalizar, controlar, mejorar y hacer más
productivos los procesos de la organización para lograr la confianza del
cliente. La estrategia de la organización aporta las definiciones necesarias
en un contexto de amplia participación de todos sus integrantes, donde
los especialistas en procesos son facilitadores.

15- ¿Qué es un proceso para BPMN?

Un proceso es una totalidad que cubre un objetivo completo, útil a la

organización y que agrega valor al cliente.
Es un conjunto de actividades, interrelaciones y recursos que tienen una
finalidad común. Transformar entradas en salidas que generen valor al
cliente.

3
 FB

16- Explique brevemente los conceptos utilizados en la gestión de procesos.

a. Proceso clave o critico: Es aquel proceso que se define como clave o

vital para el funcionamiento del negocio desde las definiciones
estratégicas. Caen en esta categoría los procesos del negocio. Pueden
cambiar y están sujetos a condiciones de tiempo y espacio.
b. Actividad: Es una acción que realiza un rol en un periodo de tiempo
específico y controlado. Tiene entradas y salidas precisas. Está
formado por un conjunto de tareas concretas. Solo tiene sentido al
interior del proceso.
c. Tarea: Desarrollo de la actividad en acciones muy precisas. Incluidas
en la descripción del proceso.
d. Procedimiento: Descripción detallada de una parte del hacer de la
organización, puede ser un proceso o un grupo de procesos
agrupados en uno. Tiene actividades.
e. Protocolo o instructivo: Acuerdo interno, mandatorio y especifico.
f. Norma: Estandarización con el medio con un mayor o menor grado de
obligatoriedad.

17- Tipos de procesos.

Procesos de estrategia: (similares para todas las empresas).

a. Planificar: Realizar un proceso para obtener un plan estratégico.
b. Implementar: Llevar a la realidad el plan estratégico.
c. Verificar: Medir y controlar que se sigue el plan de acuerdo a las
necesidades vigentes.
d. Retroalimentar: Capturar el aprendizaje para incluir en un nuevo ciclo
de procesos de la estrategia.

Procesos de negocio: Atienden la misión de la empresa y se relacionan

con los clientes.
a. En empresas pequeñas: de uno a tres procesos.
b. En empresas grandes: de tres a seis procesos.

Procesos de Apoyo: Acciones necesarias para realizar los procesos de

negocio (secundarios).
a. En empresas pequeñas: hasta 20.
b. En empresas grandes: hasta 200.

4
 FB

18- ¿Cómo describir un proceso?

a. Identificar y describir al cliente del proceso con un rol.

b. Describir el producto del proceso (Es el requerimiento del cliente
respecto al proceso, o sea el bien o servicio que espera).
c. Identificar o dar un nombre al proceso.
d. Describir el objetivo desde la perspectiva del cliente, o sea, lo que
hace el proceso para el.
e. Describir los límites del proceso.
f. Describir los roles involucrados en las actividades, o sea todos los
trabajadores del negocio que realizarán al menos una actividad del
proceso.
g. Enunciar los recursos del proceso.
h. Enunciar los formularios, registros y toda la información que se utiliza
en el proceso.
i. Enumerar las restricciones.

19- ¿Qué modelos pueden utilizarse para visualizar procesos?

• Mapa de proceso global (todos los procesos): Permite reconocer la

totalidad y ubicarse en el contexto, incluyendo todos los procesos de
la organización. Es la cadena de valor de todas las actividades que
realizan en la empresa, se requiere para el análisis crítico.

• Mapa de ámbito: detalla una parte del proceso, se encarga de

desagregar hasta llegar al proceso operativo. Es un mapa de procesos
operativos (incluye todas las relaciones).

• Flujograma de información: Un diagrama de los procesos operativos,

se utiliza el “curso normal de los eventos”, no se diagraman las
contingencias.

• Tareas de la actividad: Los modelos construyen un conjunto de todas

las áreas usuarias. Lo centraliza el área de gestión, los dueños son los
responsables directos.

5
 FB

6
 FB

Unidad N° 2 Sistema de información.

1- ¿Qué significa proceso de software e ingeniería de software?

Proceso de software: Se define como un marco de trabajo para las tareas

que se requieren en la construcción del software de alta calidad
Ingeniería de software: Es la aplicación de un enfoque sistemático,
disciplinado y confiable al desarrollo, operación y mantenimiento del
software.
Un proceso de software define el enfoque que se adopta mientras el
software esté en desarrollo, mientras que la ingeniería de software
abarca las tecnologías que requiere el proceso.

2- Explique el marco de trabajo para el proceso.

Establece la base para un proceso de software completo, identificando

las pequeñas actividades.
A. Comunicación: Implica una intensa colaboración y comunicación con
los clientes, incluye los requisitos y las actividades relacionadas.
B. Planeación: Describe las tareas técnicas que deben realizarse, los
riesgos posibles, los recursos requeridos, los productos de trabajo que
se deben producir y un programa de trabajo.
C. Modelado: Abarca la creación de modelos para que el cliente y el
desarrollador entiendan mejor los requisitos del software y del
diseño.
D. Construcción: Combina la generación del código y la realización de las
pruebas necesarias para descubrir errores en el código.
E. Despliegue: El software se entrega al cliente quien evalúa el producto
recibido y proporciona información basada en la evaluación.

7
 FB

3- ¿Cuáles son las actividades genéricas que se llevan a cabo para

construir y poner en marcha un sistema de información? Explique en
que consiste c/u y que es el estudio de prefactibilidad

A. Análisis.
a. Capturar los requerimientos del cliente.
b. Relevamiento: investigar el proceso.
c. Identificar: Funciones que se hacen bien, funciones que se
hacen mal, funciones que faltan y funciones con alto costo
operativo.
d. Definir salidas de información y que datos son necesarios para
generarlas.
B. Diseño.
a. Definir fronteras de automatización.
b. Definir modelo arquitectónico.
c. Definir interfaz hombre-maquina.
C. Construcción: código.
D. Implementación: Prueba y puesta en marcha.
E. Mantenimiento: Ciclo de vida, se hace 1 año y medio después para:
a. Corregir errores.
b. Mejorar lo que se está haciendo/modificar.
c. Ampliar lo que estaba.
Estudio de prefactibilidad: Consiste en determinar si es posible llevar
adelante ese proyecto, para eso se analizan 3 aspectos o factores, los
factores son:
Técnico: Si la organización tiene o puede adquirir la tecnología
Económico: Se comparan los costos/beneficios de la implementación del
nuevo sistema.
Operativo: Estudiar el comportamiento del usuario o enseñarle al mismo.
Se trabaja con el usuario final.

4- ¿Qué significa métodos, herramienta, técnica y metodología?

Método: Conjunto de pasos para cumplir un objetivo, establece que hay

que hacer.
Técnica: Procedimiento que indica como realizar ordenadamente una
tarea, establece el como hacer.
Herramienta: Elementos que utilizamos y que nos ayudan a construir
modelos (¿con qué?)

8
 FB

Metodología: Conjunto de métodos, técnicas y herramientas (que, como,

con qué).

5- ¿Es importante utilizar una metodología estandarizada? Justifique

Es importante porque permite aumentar la productividad del grupo de

desarrollo del sistema, ya que las mismas facilitan la comunicación y
permite utilizar herramientas que ya fueron probadas.

6- ¿Qué características deben tener todas las metodologías?

a. Deben ser completas (modelar tanto la solución como los

inconvenientes que detecte).
b. Deben ser verificables: Tanto los desarrolladores como los usuarios
pueden ver lo que están haciendo y corregir lo que sea necesario
(errores).
c. Que los modelos del análisis o diseños me permitan ver donde estoy
parado.
d. Cada modelo del análisis debe ser utilizado en el diseño, cada cosa
que hago en el diseño debe ser útil para el programador.

7- ¿Qué importancia tiene la documentación en el sistema de

información?

Objetivo: Permite ejercer el control y la comunicación entre los

miembros del grupo de trabajo.
Se documenta para:
a. Comprender los compromisos que se asumen.
b. Comunicar la información de un sector a otro.
c. Controlar las alternativas que sufre el proyecto y prevenir
situaciones indeseables.
d. Comunicarnos con los usuarios.

¿Qué se documenta? Todas las decisiones que se toman y todos los

modelos que se construyen.
¿Cómo o cuando se documenta? A medida que van ocurriendo las cosas.

9
 FB

¿Quién va a documentar? Se va a ocupar de recolectar la información,

organizarla y dejarla plasmada en un documento.

8- ¿Qué engloba la calidad en un sistema de información?

Muchos creen que el tema de calidad inicia una vez generado el código,
la garantía de calidad es una utilidad de protección que se aplica en cada
paso del proceso y engloba:
a. Métodos y herramientas de análisis, diseño, codificación y prueba.
b. Revisiones formales a cada paso.
c. Una estrategia de prueba.
d. Control de la documentación y de los cambios realizados.
e. Mecanismos de medidas (métricos).

9- ¿Qué es la calidad y que factores determinan la calidad del software?

Calidad es la concordancia de los requisitos funcionales documentados

(criterios que guían el desarrollo) con características implícitas que se
esperan de todo sistema desarrollado profesionalmente.

10
 FB

10- Explique las características de los distintos modelos de proceso.

11
 FB

11- ¿Por qué es importante utilizar un proceso para desarrollar un SI?

Se necesita un proceso para que:

a. Proporcione una guía para ordenar las actividades de un equipo.
b. Dirija las tareas de cada desarrollador por separado y del equipo
como un todo.
c. Especifique artefactos (modelos) que deben desarrollarse.
d. Ofrezca criterios para el control y la medición de los productos y
actividades del proyecto (¿Qué tanto avancé?).

12- ¿Qué es el PUD? ¿Cuáles son sus características?

El proceso unificado de desarrollo de software es un conjunto de

actividades necesarias para transformar los requisitos de un usuario en
un sistema de software. Está basado en componentes Utiliza el lenguaje
unificado de modelado (UML).
Se resume en tres fases clave:
a. Dirigido por casos de uso: Representan requisitos funcionales, se
tienen en cuenta al usuario y guían el proceso de desarrollo.
b. Centrado en la arquitectura: Incluye los aspectos estéticos y
dinámicos del sistema, se refleja en los casos de uso. La
arquitectura es una vista del diseño completo con las
características más importantes.
c. Iterativo e incremental: Se divide el trabajo en mini-proyectos. Las
iteraciones hacen referencia a pasos en el flujo de trabajo y los
incrementos al crecimiento del producto. Iteraciones deben ser
controladas, se van largando versiones del sistema.

13- ¿Por qué aparecen las metodologías agiles y a partir de que año
comienzan a tener éxito en el mercado?

12
 FB

14- Explique las características de los procesos de desarrollo rápido y

mencione en que tipos de sistemas tienen éxito.

Características:
a. Los procesos de especificación, diseño e implementación están
entrelazados. No hay una especificación detallada del sistema, la
documentación se minimiza y el documento de requerimientos
solo define las características más importantes.
b. El sistema se desarrolla en versiones diferentes (usuarios y
colaboradores del sistema intervienen).
c. Las interfaces del usuario del sistema se desarrollan usando un
sistema de elaboración interactiva.

Tipos de sistemas en el que tuvieron éxito:

a. Desarrollo del producto (pequeña o mediana para ventas).
b. Diseño de sistemas a medida dentro de una organización. (Hay
compromiso del cliente por intervenir y no existen nuevas reglas
externas).

15- Explique lo que dice el manifiesto ágil.

13
 FB

16- ¿Qué problemas aparecen al querer utilizar metodologías agiles y como

abordarlos?

a. Requisitos imprevisibles: Se puede abordar implementando un

mecanismo de retroalimentación en intervalos frecuentes mediante la
iteratividad.
b. Gran requerimiento de sinergia y colaboración entre las partes: En vez
de imponer un proceso es necesaria la aceptación de un proceso que
se adapte al equipo de trabajo.
c. Dificultad en medir la productividad del trabajo: Delegación del
control o la parte interna del trabajo.
d. Necesidad del apoyo por parte de los expertos del negocio: Buscar
asesores de calidad que puedan estar disponibles para el desarrollo.

17- Mencione algunas consideraciones a la hora de seleccionar el tipo de

metodología (ágil o tradicional).

1. Es necesaria una especificación y diseño detallado antes de la

implementación -> PLAN.
2. Es necesaria una estrategia de entrega incremental donde se entregue
el soft al cliente y se haga retroalimentación -> MA.
3. Tamaño del sistema:
a. Pequeño equipo -> MA.
b. Equipos amplios con sistema grande -> PLAN.
4. Tipos de sistemas: Demandan mucho análisis -> PLAN.
5. Tiempo de vida el sistema: PLAN o MA.
6. Tecnologías disponibles:
a. Buenas herramientas -> MA.
b. Malas herramientas -> PLAN.
7. Organización del equipo de desarrollo: Distribuido -> PLAN.
8. Existen problemas culturales que afectan al desarrollo -> PLAN.
9. Habilidad de programadores:
a. Alto nivel -> MA.
b. Bajo nivel -> PLAN.
10. Si el sistema está sujeto a regulación externa -> PLAN.

14
 FB

18- Explique cómo trabaja XP.

19- Explique cómo trabaja SCRUM.

20- Mencione alguna sugerencia para que los métodos agiles funcionen en
sistemas grandes.

a. Diseñar la arquitectura del software y producir documentación

para describir los aspectos críticos del sistema.
b. Se deben diseñar y usar mecanismos de comunicación entre
equipos. Hay que ofrecer diferentes canales de comunicación.
c. Se deben mantener construcciones del sistema frecuente y
liberaciones del sistema regulares.

15
 FB

16
 FB

Unidad N° 3: Paradigma de la programación orientada a objetos.

1- Concepto de paradigma.

El paradigma es un conjunto de teorías estándares y métodos, que juntos

representan una forma de organizar el conocimiento. Es decir, una forma
de ver el mundo.

2- ¿Qué es el paradigma orientado a objetos?

El paradigma orientado a objetos es una metodología no algorítmica,

identifica objetos que se comunican entre sí haciéndose peticiones, cada
uno de ellos encapsulan atributos y un conjunto de operaciones. No hay
ejecución procedimental de tareas, sino que hay mensajes de un objeto a
otro.

3- ¿Qué tipo de software se puede desarrollar y cuáles son sus

características?

Software simple:
a. Son aplicaciones construidas, mantenidas y utilizadas por la misma
persona.
b. Tienen un propósito en particular y un ciclo de vida muy corto.
c. Se lo puede reemplazar con un software completamente nuevo.
Software complejo:
a. Son dirigidos por eventos.
b. Tienen un ciclo de vida largo.
c. A lo largo del tiempo muchos usuarios llegan a depender de su
correcto funcionamiento.
d. Resulta muy difícil para el desarrollador individual comprender todo
el sistema de como se sustenta el diseño.
e. Si los requerimientos cambian se modifica el sistema (se reutiliza).

17
 FB

4- ¿Qué dificultades se pueden presentar en el desarrollo de software?

Se pueden presentar las siguientes dificultades:

a. Una planificación y estimación de costos imprecisos.
b. Un software que no corresponda con lo pedido.
c. Calidad de los sistemas que a veces no llega a ser ni aceptable.
Otros problemas que pueden aparecer corresponden al propio software
y a las personas encargadas de su desarrollo:
a. Problemas por no tener conocimientos de nuevas técnicas de
desarrollo.
b. Resistencia al cambio por parte del desarrollador.
Problemas en cuanto al carácter del software o su complejidad:
a. Complejidad del dominio. Por ejemplo, requerimientos que se
contradicen, dificultad del cliente en expresarlos.
b. Dificultades en el proceso de desarrollo. Por ejemplo, a mayor
número de desarrolladores, mayores problemas de comunicación y
coordinación.
Para satisfacer las exigencias del mercado se necesitan sistemas:
a. Más rápidos.
b. Fáciles para modificar.
c. Flexibles.
d. Más complejos pero confiables.

5- ¿Cuál es el rol de la descomposición?

Cuando se desarrolla un software complejo es esencial descomponerlo

en partes más pequeñas, donde cada una de estas se puede representar
de forma independiente. Para entender un nivel del sistema, solo hace
falta entender unas pocas partes del mismo.
Hay dos tipos de descomposición:
a. Descomposición algorítmica: Divide al sistema en módulos, donde
cada uno de estos representa un paso importante del proceso global.
b. Descomposición orientada a objetos: Se identifican objetos, donde
cada uno de estos tiene un comportamiento propio y modela algún
objeto del mundo real.

18
 FB

6- ¿Cuáles son las características de las técnicas orientadas a objetos?

Las características de las técnicas orientadas a objetos son:

a. Cambian nuestra forma de pensar sobre los sistemas, ya que es más
natural.
b. Los sistemas suelen construirse a partir de objetos ya existentes, lo
que lleva a un alto grado de reutilización, ahorro de dinero, ahorro de
tiempo de desarrollo y mayor confiabilidad del sistema.
c. La complejidad de los objetos sigue en aumento, ya que nuevos
objetos se construyen a partir de otros.
d. Ayuda a explotar la potencia expresiva de los lenguajes de
programación orientados a objetos.

7- ¿Qué es una clase y qué es un objeto?

Una clase es una abstracción de un conjunto de atributos y

comportamientos comunes de los objetos.
Un objeto representa un elemento del mundo real, que puede tanto real
como abstracto; tiene un papel bien definido en el dominio del
problema.

8- ¿Cuáles son los elementos fundamentales del modelo de objetos?

Hay 4 elementos fundamentales:

a. Abstracción: Denota las características esenciales de un objeto que lo
distingue de los demás tipos de objetos. Se centra en la visión externa
de un objeto y por lo tanto sirve para separar el comportamiento
esencial de un objeto de su implementación.
b. Encapsulamiento: Sirve para separar el interfaz de una abstracción y
su implementación.
c. Modularidad: Es la propiedad que tiene un sistema que ha sido
descompuesto en un conjunto de módulos. Cuando se trabaja con un
sistema en partes, estas tienen que estar relacionadas y esta relación
debe ser altamente cohesiva y débilmente acopladas.
d. Jerarquía: Es la ordenación de las abstracciones, sirve para disminuir
la complejidad de los sistemas, hay dos tipos:
a. Herencia o generalización: “Es un” por ejemplo: es auto es un
vehículo. La herencia es la jerarquía de clases más importante y

19
 FB

es un elemento esencial de los sistemas orientados a objetos.

Define una relación entre clases.
b. Agregación: “Es parte de” por ejemplo: ítem de factura es
parte de la factura.

9- ¿Qué significa estado, comportamiento e identidad de un objeto?

Identidad: Es la propiedad que permite distinguir a un objeto de los

demás objetos.
Estado: Abarca todas las propiedades del objeto más los valores actuales
de esas propiedades.
Comportamiento: Es como reacciona el objeto de acuerdo a los cambios
de estado y paso de mensajes.

10- ¿Qué significa operación?

Una operación es la implementación de un servicio que puede ser

requerido a cualquier objeto de la clase para que muestre un
comportamiento. Una clase puede tener cualquier número de
operaciones o ninguna.

11- ¿Cuáles son las vistas de una clase?

Las vistas de una clase son externas o de interfaz e internas o de

implementación. Una clase se representa mediante un rectángulo que
esta separado en 3 partes.
a. En la primera va el nombre, el cual debe contener la primera letra en
Mayúscula y el resto en minúscula y si el nombre es compuesto no se
utilizan espacios y la primera letra de cada palabra va con mayúscula.
b. En la segunda parte van los atributos, se escriben con minúscula y en
el caso de contener más de una palabra, la primera letra de cada una
se escribe con mayúscula.
c. En la tercera parte se encuentran las operaciones, se escriben igual
que los atributos y al final llevan paréntesis.

20
 FB

12- ¿Cuál es la diferencia entre el concepto de operación y responsabilidad?

La responsabilidad es una obligación de una clase, esta dada por los

atributos más las operaciones que puede hacer la clase. Cada clase tiene
responsabilidades y no siempre va a poder cumplirlas todas con las
operaciones que tiene, en ese caso va a tener que ir a buscar algo a otra
clase (clase B) para poder cumplir con esa responsabilidad.

13- Concepto de colaboración y método.

Colaboración es cuando dada una clase A y una clase B, la clase A para

poder cumplir con su responsabilidad le pide algo a la clase B. Se dice que
el objeto B colabora con el objeto A si A para cumplir con su
responsabilidad necesita enviarle un mensaje a B solicitándole un
servicio.
Un método es la implementación de una operación.

14- Mencione las relaciones entre objetos.

Relaciones entre objetos:

a. Agregación.
b. Enlace: Una conexión física o conceptual entre objetos, un objeto
colabora con otros a través de estos enlaces. Para representar enlaces
se usan los diagramas de comunicación o colaboración que usamos
para el modelado de negocios.

15- Explique los tipos de relaciones entre clases.

Relaciones entre clases:

a. Asociación: La clase A se vincula con la clase B, es el vínculo entre dos
clases, si posee navegabilidad se cómo se accede.
b. Agregación: Particularidad de la asociación, es una relación todo,
parte.
c. Generalización: Se da entre dos o más clases, la clase B hereda los
atributos y operaciones de la clase A.
d. Relación de dependencia: Por ejemplo, el pago con tarjeta, si toco la
tarjeta altero el pago.

21
 FB

16- ¿Qué es el polimorfismo?

El polimorfismo es que una operación adopta varias formas de

implementación, es decir que puede tener diferentes comportamientos
en diferentes objetos.

17- ¿Qué significa multiplicidad?

Indica un objeto de una clase con cuantos objetos de la otra clase se va a

relacionar, siempre la multiplicidad se coloca arriba o debajo de la punta
de la flecha.

18- ¿Qué significa navegabilidad?

La navegabilidad es como accedo a los datos, es decir nos indica cual de

las clases le está solicitando algo a la otra clase; lo marca el sentido de la
flecha.

19- ¿Qué es un diagrama de clases? ¿Qué modela?

Un diagrama de clases en un conjunto de clases, con sus respectivas

relaciones, multiplicidades y navegabilidades, que se utilizan para
modelar la vista de diseño estática de un sistema. Soporta
principalmente los requisitos funcionales de un sistema, que son los
servicios que el sistema debe proporcionar a sus usuarios finales.

20- ¿Qué es el modelo de objeto de dominio? ¿Con qué herramientas se

construye?

Los objetos de dominio representan las cosas que existen o los eventos
que suceden en el entorno en que se desenvuelve el sistema. Muchas de
las clases del dominio pueden deducirse de la especificación de
requerimientos o mediante las entrevistas. Las clases del dominio
aparecen como:
a. Entidades del negocio: representan cosas que se manipulan en el
negocio, como pedidos, cuentas, contratos.

22
 FB

b. Entidades del mundo real y conceptos de los que el sistema debe

realizar un seguimiento: como artículos y vehículos.
c. Sucesos que ocurrirán o han ocurrido: como la partida o llegada de un
avión.
Las clases del dominio que se encuentren se utilizarán al describir los
casos de uso, diseñar el prototipo de interfaz y para sugerir clases
internas durante el análisis.

21- Explique brevemente el surgimiento de UML

Los lenguajes de modelado orientados a objetos aparecen a mitad de los

90 y finales de los 80. El número de métodos orientados a objetos se
incrementó entre 1989 y 1994. En la primera mitad de los 90, Booch
(Rational Soft Corporation), Jacobson (Objetory) y Rumbaugh (General
Electric) empezaron a adoptar ideas de cada uno de los otros métodos,
los cuáles habían sido reconocidos a nivel mundial. Estos 3 autores
comenzaron a trabajar en conjunto para unificar sus métodos y darle
estabilidad al mercado orientado a objetos. Varias organizaciones
colaboraron con sus recursos, y así, en 1997, se presentó la primera
versión de UML.

22- ¿Qué es UML? Explique sus características.

UML es un lenguaje estándar para escribir planos de software,

proporciona un vocabulario y reglar que se centran en la representación
conceptual y física de un sistema. Es una parte de un método de
desarrollo de software, independiente del proceso, este proceso tiene
que ser dirigido por casos de uso, centrado en la arquitectura, iterativo e
incremental.

23- Explique la visión general de UML.

Visualizar: UML es un modelo explicito, que facilita la comunicación.

Utiliza lenguaje gráfico, el modelo se puede interpretar por otro
desarrollador o herramienta sin ningún problema.
Especificar: Permite construir modelos precisos, no ambiguos y
completos. UML cubre la especificación de todas las decisiones de
23
 FB

análisis, diseño e implementación que deben realizarse al desarrollar y

desplegar un sistema con gran cantidad de software.
Construir: Los modelos de UML pueden conectarse de forma directa a
una gran variedad de lenguajes de programación, es decir que se puede
lograr la generación de código a partir de un modelo UML y también
reconstruir un modelo UML a partir de una implementación.
Documentar: UML cubre la documentación de la arquitectura de un
sistema y todos sus detalles. También proporciona un lenguaje para
expresar requisitos y pruebas.

24- ¿Qué no dice UML?

UML no nos dice que modelo construir y cuando construirlo, por eso es
necesario asociarlo a un proceso.

24
 FB

25- Explique brevemente la estructura o modelo conceptual de UML.

Bloques de Construcción.
• Elementos: bloques básicos de construcción orientados a objetos de
UML. Se utilizan para escribir modelos bien formados.
o Estructuras: son los nombres de los modelos de UML. En su
mayoría son las partes estáticas de un modelo y representan
conceptos o cosas materiales.
▪ Clase.
▪ Interfaz.
▪ Colaboración.
o Comportamiento: son las partes dinámicas de los modelos de
UML. Hay tres tipos:
▪ Interacción.
▪ Actividad.
▪ Máquina de Estado.
o Agrupación: son las partes organizativas de los modelos UML.
Estas son las cajas en las que puede descomponerse un
modelo.
▪ Paquete.
o Anotación: son las partes explicativas de los modelos de UML.
Son comentarios que se pueden aplicar para describir, clasificar
y hacer observaciones sobre cualquier elemento de un modelo.
▪ Notas.

25
 FB

• Relaciones: hay cuatro tipos de relaciones:

o Dependencia (línea discontinua).
o Asociación (línea continua, puede tener etiquetas,
multiplicidad entre otros).
o Generalización (flecha continua, punta sin relleno)
o Realización (línea discontinua, punta sin relleno)
.

• Diagramas: representación gráfica de un conjunto de elementos. Son

13:
o Clases: es un tipo de diagrama estático que describe la
estructura de un sistema mostrando sus clases, atributos y las
relaciones entre ellos. Son utilizados durante el proceso de
análisis y diseño de los sistemas, donde se crea el diseño
conceptual de la información que se manejará en el sistema, y
los componentes que se encargaran del funcionamiento y la
relación entre uno y otro.
o Objetos: son utilizados durante el proceso de Análisis y Diseño
de los sistemas informáticos en la metodología UML. Se puede
considerar un caso especial de un diagrama de clases en el que
se muestran instancias específicas de clases (objetos) en un
momento particular del sistema. Los diagramas de objetos
utilizan un subconjunto de los elementos de un diagrama de
clase. No muestran la multiplicidad ni los roles, aunque su
notación es similar a los diagramas de clase. Vista estática.
o Componentes: representa cómo un sistema de software es
dividido en componente y muestra las dependencias entre
estos componentes. Los componentes físicos incluyen archivos,
cabeceras, bibliotecas compartidas, módulos, ejecutables, o
paquetes. Los diagramas de Componentes prevalecen en el
campo de la arquitectura de software, pero pueden ser usados
para modelar y documentar cualquier arquitectura de sistema.
ESTATICA
o Estructura compuesta: ESTATICA.
o Casos de uso: es una especie de diagrama de comportamiento.
El Lenguaje de Modelado Unificado define una notación gráfica
para representar casos de uso llamada modelo de casos de
uso. ESTATICA
o Secuencia: es un tipo de diagrama usado para modelar
interacción entre objetos en un sistema según UML. En inglés

26
 FB

se pueden encontrar como "sequence diagram", "event-trace

diagrams", "event scenarios" o "timing diagrams" DINAMICA.
o Comunicación: En UML 2.0, un diagrama de comunicación es
una versión simplificada del diagrama de colaboración de la
versión de UML 1.x.
o Estados: Es un diagrama utilizado para identificar cada una de
las rutas o caminos que puede tomar un flujo de información
luego de ejecutarse cada proceso. Permite identificar bajo qué
argumentos se ejecuta cada uno de los procesos y en qué
momento podrían tener una variación. DINAMICA.
o Actividades: representa los flujos de trabajo paso a paso de
negocio y operacionales de los componentes en un sistema.
Muestra el flujo de control general. DINAMICA.
o Despliegue: se utiliza para modelar el hardware utilizado en las
implementaciones de sistemas y las relaciones entre sus
componentes. ESTATICA.
o Paquetes: ESTATICA.
o Tiempos: DINAMICA.
o Visión global de interacciones: es un híbrido entre un diagrama
de actividades y un diagrama de secuencia (ambos dinámicos).

Los modelos deben ser concretos y consistentes, pero siempre van a

empezar no siéndolo, ya que el PUD es un proceso iterativo, que va
completando sus modelos a través del tiempo.

27
 FB

• Reglas: las reglas semánticas me dan las pautas para un modelo bien
formado.
o Reglas semánticas para:
▪ Nombres: Cómo llamar a los elementos, relaciones y
diagramas.
▪ Alcances: El contexto que da un significado específico a
un nombre.
▪ Visibilidad: Cómo se pueden ver y utilizar esos nombres
por otros.
▪ Integridad: Cómo se relacionan apropiada y
consistentemente unos elementos con otros.
o Contempla construcción de modelos:
▪ Abreviados: Ciertos elementos se ocultan para
simplificar la vista.
▪ Incompletos: Pueden estar ausentes ciertos elementos.
▪ Inconsistentes: No se garantiza la integridad del modelo.
• Mecanismos comunes: UML se simplifica mediante la presencia de 4
mecanismos que se aplican de forma consistente a través de todo el
lenguaje:
• Especificaciones.
• Adornos.
• Divisiones comunes.
• Mecanismos de extensibilidad.

26- ¿Cuáles son las vistas de un sistema realizado con UML?

27- ¿Qué son los patrones y qué utilidad tienen?

Los patrones nos dan una descripción de los problemas que ocurren y
como solucionarlos. Se los utiliza una y otra vez para resolver problemas
parecidos, se los puede utilizar todas las veces que se quiera y
perfeccionarlos. El objetivo que se persigue es tener catálogos de
patrones estandarizados.

28
 FB

28- ¿Cómo se describen o expresan los patrones?

Son soluciones expresadas en términos de objetos e interfaces para

resolver los problemas de contexto.

29- ¿Qué es un patrón de modelo de objeto de dominio?

Un patrón de modelo de objeto de dominio es una agrupación de objetos

con responsabilidades estereotipadas y escenarios de interacción.

30- ¿Cómo se organizan los patrones para la construcción de modelos de

objeto de dominio?

• Patrón fundamental.
• Patrón transaccional.
• Patrón agregación.
• Patrón plan.

29
 FB

30
 FB

Unidad N° 4 Ingeniería de requerimientos.

1- Concepto de requerimientos. Problemas por errores en la definición de

requerimientos.

Los requerimientos son una descripción de los servicios que debe

proporcionar un sistema y de las restricciones de operación en el que el
mismo debe desempeñarse. Los mismos reflejan necesidades de los
clientes.
Es una parte crucial del proceso de software, ya que constituye la base de
todo el desarrollo. La mala definición de los requerimientos puede causar
malentendidos entre desarrolladores y clientes, sistemas que no cumplen
con la necesidad real, tiempo perdido y mantenimiento costoso.

2- Explique las categorías de requerimientos.

La categorización sirve para priorizar requerimientos. Categorías:

• Requerimientos que deben ser absolutamente satisfechos.
• Requerimientos deseables, pero no indispensables.
• Requerimientos posibles pero que se pueden eliminar.

3- ¿Cuál es el propósito de los requerimientos? Mencione la lista de

comprobación.

Los requerimientos sirven para 3 propósitos:

a. Permite a los desarrolladores explicar cómo han entendido lo que el
cliente pretende del sistema.
b. Indica a los diseñadores que funcionalidades y características va a
tener el sistema final.
c. Indican al equipo de prueba que demostraciones llevar a cabo para
convencer al cliente que el sistema entregado es el solicitado.
Para poder comprobar
• ¿Son correctos? Tanto el desarrollador como el cliente deben poder
revisarlos para asegurarse que no tienen errores.
• ¿Son consistentes? Que no haya definiciones contradictorias o
ambiguas.

31
 FB

• ¿Son completos? Todos los servicios solicitados deben estar definidos.

• ¿Son realistas? Si el sistema realmente puede hacer lo que el cliente
solicita.
• ¿Son verificables? Demostrar a partir de pruebas, que el sistema
cumple con los requerimientos.
• ¿Son rastreables? Cada función del sistema pueda ir hasta el conjunto
de requerimientos que la definen.

4- Explique los tipos de requerimientos.

Requerimientos funcionales: Son los enunciados de los servicios que el

sistema debe proveer, de cómo debería reaccionar el sistema a entradas
particulares y de cómo debería comportarse el sistema en situaciones
específicas. En algunos casos también especifican cosas que el sistema no
debe hacer.
Requerimientos no funcionales: Son limitaciones sobre servicios o
funciones que ofrece el sistema. Incluyen restricciones tanto de
temporización y del proceso de desarrollo, como impuestas por los
estándares. Los requerimientos no funcionales se suelen aplicar al
sistema como un todo, más que a características o servicios individuales
del sistema.
Requerimientos de Dominio: Se derivan del dominio de aplicación del
sistema, más que a partir de las necesidades de los usuarios. Pueden ser
requerimientos funcionales nuevos.
Requerimientos duraderos: Se asocian con las actividades centrales, de
lento cambio.
Requerimientos volátiles: Son más susceptibles al cambio, se asocian con
las actividades de apoyo. Son cuatro, los mutantes (cambian debido a los
cambios del ambiente), los emergentes (surgen al incrementarse la
comprensión del cliente en el desarrollo del sistema), los consecutivos
(son el resultado de la introducción del sistema que puede cambiar los
procesos de la organización y abrir nuevas formas de trabajo que
generan nuevos requerimientos) y los de compatibilidad (dependen de
sistemas o procesos, cuando estos cambian, los requerimientos
cambian).

32
 FB

5- ¿Cuáles son los niveles de descripción de requerimientos?

Algunos de los problemas que surgen durante el proceso de ingeniería de

requerimientos son resultado de no hacer una clara separación entre los
diferentes niveles de descripción.
Requerimientos del usuario: Declaraciones, en lenguaje natural y en
diagramas, de los servicios que se espera que el sistema proporcione y de
las restricciones bajo las cuales debe funcionar.
Requerimientos del sistema: Son las funciones, servicios y restricciones
operativas del sistema. El documento de requerimientos del sistema
debe ser preciso y debe definir exactamente qué es lo que se va a
implementar.

6- Explique qué es la ingeniería de requerimientos y el proceso de

ingeniería de requerimientos.

Los requerimientos para un sistema son descripciones de lo que el

sistema debe hacer: el servicio que ofrece y las restricciones en su
operación. Al proceso de descubrir, analizar, documentar y verificar estos
servicios y restricciones se llama Ingeniería de Requerimientos. Es un
Subcampo de la ingeniería en Software.
El proceso de Ingeniería de Requerimientos incluye cuatro actividades:
• Estudio de factibilidad: Estudio enfocado que debe realizarse con
oportunidad en el proceso.
• Adquisición y análisis: Descubrir el dominio de la aplicación, que
servicios debe proporcionar el sistema, el desempeño requerido, las
restricciones de hardware, etc.
• Especificación (documentación): Pueden producirse documentos de
requerimientos formales e informales.
• Validación: comprobar que los requerimientos definen realmente el
sistema que quiere el cliente.

33
 FB

7- ¿Qué significa administrar requerimientos y por qué cambian los

requerimientos en sistemas grandes?

La administración de requerimientos es el proceso de comprender y

controlar los cambios en los requerimientos del sistema. Es necesario
mantenerse al tanto de los requerimientos particulares y mantener
vínculos entre los requerimientos dependientes de forma que se pueda
evaluar el impacto de los cambios en los requerimientos.
Los requerimientos para sistemas de software grandes son siempre
cambiantes ya que estos sistemas normalmente se desarrollan para
abordar problemas “traviesos”. Debido a que el problema no puede
definirse completamente, es muy probable que los requerimientos del
software sean incompletos. Durante el proceso del software, la
comprensión del problema por parte de los stakeholders está cambiando
constantemente. Estos requerimientos deben entonces evolucionar para
reflejar esta perspectiva cambiante del problema.
Además, una vez que un sistema se ha instalado, inevitablemente surgen
nuevos requerimientos. Es difícil para los usuarios y clientes del sistema
anticipar qué efectos tendrá el sistema nuevo en la organización.

34
 FB

Unidad N° 5: Proceso de elicitación de requerimientos.

1- ¿Por qué utilizar una estrategia de búsqueda y en qué consiste?

Es bueno utilizar una estrategia, ya que esta nos indica una serie de pasos
a seguir para evitar obtener información repetida y perder tiempo de
búsqueda.
La estrategia de búsqueda consiste en:
a. Identificar fuentes de información:
i. Cliente/usuario: Del cliente vamos a obtener las nuevas
necesidades y los problemas que tiene con el sistema actual.
ii. Documentos:
i. Manuales de política (reglas), manuales de la
organización (Organigrama y descripción de puestos),
manuales de procedimiento y normas.
ii. Formularios: se obtienen los datos, la estructura y las
copias que se utilizan.
iii. Sistema actual: Se obtienen las ventajas y desventajas.
b. Realizar un procedimiento de búsqueda: Nos dice por dónde
comenzamos a buscar la información, como vamos a continuar, qué
fuentes vamos a consultar y qué técnicas vamos a utilizar.
c. Establecer técnicas: Nos dice con qué obtener la información
(entrevista, cuestionario, análisis de documentación, observación).
d. Modelos para darle sentido a la información recopilada.

2- ¿Qué es el muestreo?

El muestreo es un proceso que consiste en seleccionar sistemáticamente

elementos representativos de una población, este análisis revelará
información útil de la población en general.

El muestreo nos permite:

a. Reducir costos: por lo general un muestreo es menos costoso que un
censo.
b. Acelerar la recopilación de datos: al estudiar solo una parte de la
población, la recopilación se hace mucho más rápido.
c. Mejorar la efectividad.
d. Reducir la parcialidad.

35
 FB

3- ¿Cómo se diseña una muestra?

a. Determinar qué datos se van a recopilar. El analista de sistemas

necesita un plan sobre lo que hará con los datos una vez que se hayan
recopilado. Consiste en saber que datos de la muestra se necesitan
teniendo en cuenta el objetivo.
b. Determinar de qué población se van a tomar las muestras. El analista
de sistemas debe determinar la población, decidir a quien va a
entrevistar, si se va a incluir en la población un solo nivel de
organización o todos.
c. Escoger el tipo de muestreo. Muestreo sistemático, muestreo
aleatorio simple, muestreo aleatorio estratificado, muestreo
conglomerado.
d. Decidir el tamaño de muestra. Depende del tiempo que tiene el
analista, debe ser mayor a 1 y menor al tamaño de la población.

4- Entrevistas:

a. Concepto.
Una entrevista para conseguir información es una conversación
oral que utiliza el formato de preguntas y respuestas. En la
entrevista necesitamos obtener las opiniones de los entrevistados
y su parecer acerca del estado actual del sistema, metas
organizacionales, personales, además procedimientos informales.
Conviene usarla para sacar información cualitativa.

b. Tipos de entrevista.
i. Estructurada. Utiliza una lista de preguntas predefinidas
con un orden definido.
ii. No estructurada. Se trabaja con preguntas abiertas, sin
orden prestablecido.

c. Tipos de preguntas.
i. Preguntas abiertas. La respuesta puede ser de dos palabras
o dos párrafos. Permiten al entrevistador entender el
vocabulario del entrevistado, proporcionan gran cantidad
de detalles. También podrían dar como resultado muchos
detalles irrelevantes y una posible pérdida del control de la
entrevista.

36
 FB

ii. Preguntas cerradas. La respuesta se cierra al entrevistado,

dado que se puede contestar con un número finito. Un tipo
especial de pregunta cerrada es la pregunta Bipolar, sólo
permite una opción de cada polo, si o no, verdadero o falso.
Permite ahorrar tiempo, ir al grano, conseguir datos
relevantes. No permiten obtener gran cantidad de detalles.

d. Estructura de las preguntas.

i. Estructura pirámide. La organización de las preguntas de la
entrevista se puede ver como si fuera una pirámide. En la
base (punta) se encuentran las preguntas cerradas, muy
detalladas, y luego se extiende permitiendo preguntas
abiertas y respuestas más generalizadas.
ii. Estructura embudo. Se inicia con preguntas generales y
abiertas, y luego se limitan las posibles respuestas
utilizando preguntas cerradas.
iii. Estructura diamante. Con frecuencia es una mejor
combinación de las dos anteriores. Se empieza de una
manera muy específica, después se examinan los aspectos
generales y finalmente se termina con una conclusión muy
específica.

e. Sondeo. El propósito del sondeo es ir más allá de la respuesta

inicial para conseguir mayor significado, ampliar la opinión del
entrevistado. Los sondeos pueden tender a preguntas abiertas o
cerradas.

f. ¿A quién entrevistar? Se debe incluir a todas las personas que

vayan a ser afectados por el sistema.

g. Registro de entrevista.
i. Tomar notas. Consiste en ir tomando notas de lo que el
cliente nos va contando durante la entrevista. Es
conveniente tener otra persona preguntando o tomando
notas.
ii. Grabar. Grabar la entrevista mientras se realiza
iii. Combinado. Grabar para luego redactar el informe, pero
teniendo en cuenta las notas.

37
 FB

h. Etapas de una entrevista.

i. Planificación de la entrevista:
1. Leer los antecedentes: Permite entender la
organización y los puestos de trabajo.
2. Establecer los objetivos: Fijar la información que se
debe obtener de la entrevista.
3. Definir el tipo de entrevista que se va a realizar.
4. Preparar al entrevistado: informarle al entrevistado
el día, la hora y la duración que debe estar entre 45 y
60 minutos.
5. Decidir a quién entrevistar.
ii. Entrevista. Presentarse, explicar el tema de la entrevista y
el objetivo del proyecto. Comenzar con preguntas generales
para romper el hielo. El tacto, la imparcialidad e incluso la
vestimenta ayudan a asegurar una entrevista exitosa.
iii. Conclusión. Se hace un informe de la entrevista, debe
quedar a disposición para ser modificado por la persona (el
entrevistado).

5- Cuestionario:

a. Concepto. Un cuestionario es una manera de obtener información

por escrito.

b. Tipos de cuestionario.
i. Con preguntas abiertas. Le permiten al encuestado todas
las posibles opciones de respuesta. Son utilizadas cuando se
desea descubrir las opiniones de los miembros sobre algún
aspecto.
ii. Con preguntas cerradas. Limitan o cierras las opciones de
respuesta disponibles para el encuestado.

c. El cuestionario se utiliza cuando:

i. Las personas a las que se necesita encuestar se encuentran
dispersas geográficamente.
ii. Una gran cantidad de personas está involucrada en el
proyecto de sistemas y se quiere saber quiénes están de
acuerdo y quienes no con una característica específica del
sistema.

38
 FB

iii. Se está haciendo un estudio preliminar y se desea medir la

opinión general antes de que se determine el rumbo que
tomará el proyecto de sistemas.
iv. Se desea tener la certeza de que en las entrevistas de
seguimiento se identificara y abordara cualquier problema
relacionado con el sistema actual.

d. A la hora de diseñar el cuestionario debemos tener en cuenta:

i. Dejar bastante espacio en blanco.
ii. Proporcionar suficiente espacio para escribir las respuestas.
iii. Dejar escrito que se marquen con claridad las respuestas.
iv. Mantener un estilo consistente.
En cuanto a las preguntas, es importante:
v. Colocar primero las preguntas más importantes para los
encuestados.
vi. Agrupar los elementos de contenido similar.
vii. Incorporar primero las preguntas menos polémicas.

e. Tenemos varias opciones para aplicar el cuestionario:

i. Citar a todos lo encuestados al mismo tiempo, de esta
forma nos garantizamos de que todos los encuestados van
a responder.
ii. Entregar personalmente los cuestionarios en blanco y
retirarlos una vez listos.
iii. Entregar los cuestionarios y permitirles que una vez
finalizado lo dejen en una caja que se encuentra en algún
punto central.
iv. Enviar por correo los cuestionarios a los empleados e
indicarles fecha límite e instrucciones.

6- Análisis de documentación.

a. Concepto. Es importante examinar los diferentes tipos de datos

reales que con otros métodos de recopilación no obtenemos
información. Los datos reales nos dicen en dónde está la
organización y hacia donde creen sus miembros que se dirige. El
analista para ver un panorama preciso necesita examinar datos
reales tanto cuantitativos como cualitativos.

39
 FB

i. Documentos cuantitativos. Informes utilizados para la toma

de decisiones, informe de desempeño, registros,
formularios de captura de datos.
ii. Documentos cualitativos. Mensajes de correo electrónico,
memorandos, carteles en los tableros de anuncio, páginas
web, manuales de procedimiento y manuales de política.

b. Cuando utilizarla. Se la utiliza cuando esa información está

actualizada, si no, se tiene que utilizar otro método.

7- Observación:

a. ¿Qué observar?
b. ¿Cómo observar?

8- ¿Qué es un informe?
Es un conjunto de hechos analizados, que le permite al destinatario
tomar una decisión. El informe tiene dos etapas, la preparación, que
consiste en recolectar información, separando lo más importante, y la
redacción, la cual posee:
a. Objeto del informe. Es el por qué hacemos el informe.

b. Cuerpo del informe.

• Hechos. Es donde se narra lo ocurrido, tal cual sucedió.
• Demostración. Se pueden colocar opiniones sobre los
hechos.

c. Conclusión. Ésta debe ser deducible de los que se vino leyendo

anteriormente.

40
 FB

Unidad N° 6: Proceso de especificación de requerimiento.

1- Concepto de especificación de requerimiento. ¿En qué momento se

realiza?

Especificar los requerimientos hace referencia a documentarlos, los de

usuario en lenguaje natural y los de sistema en lenguaje técnico. La
especificación de requerimientos se realiza en el análisis.

2- ¿Cuáles son las perspectivas que se modelan de un SI?

Perspectiva externa. Se modela el contexto o entorno del sistema.

Perspectiva comportamiento. Se modela el comportamiento del sistema.
Perspectiva estructural. Se modela la arquitectura del sistema.

3- Explique para cada perspectiva que diagrama utiliza.

4- ¿Qué describe el modelo de CU? ¿Cómo está formado?

Un modelo de Caso de uso contiene la funcionalidad completa de un

sistema de información y la interacción con el ambiente. Está
conformado por el diagrama de CU (representación gráfica) y por la
descripción que se puede realizar de cada CU (plantilla).

5- ¿Qué es un CU? ¿Qué es un escenario?

Un caso de uso es una descripción de un conjunto de secuencias de

acciones, que las ejecuta un sistema para producir un resultado de valor
para un actor.
Un escenario es una secuencia específica de acciones que ilustra un
comportamiento, es básicamente una instancia de caso de uso. Es un
camino del proceso.

41
 FB

6- Explique los componentes gráficos o elementos del diagrama de CU.

a. Actores. Un actor representa un rol que es desempeñado por una

persona, dispositivo o incluso otro sistema al interactuar con nuestro
sistema. Se deben organizar de los roles más generales a los más
específicos.
i. Principal. Es el que solicita algo del sistema.
ii. Secundario. Es el que participa de algún paso del proceso.

b. Caso de uso. Es una porción de funcionalidad del sistema.

i. Caso de uso esencial. Representan actividades comercialmente
importantes para el negocio.
ii. Caso de uso de soporte. Son actividades que dan soporte a los
casos.
iii. Caso de uso base (concreto).
iv. Caso de uso adicional (abstracto).

c. Nombres. Cada caso de uso debe tener un nombre que lo diferencie

de los demás casos de uso. Son los alcances del sistema.

d. Relaciones. Los casos de uso se pueden organizar especificando las

relaciones de generalización, inclusión y extensión entre ellos (entre
casos de uso). Estas relaciones sirven para factorizar el
comportamiento común y para factorizar variantes. Es importante el
sentido de la flecha.

i. Generalización. La generalización entre casos de uso es como

la generalización entre las clases, el caso de uso hijo hereda el
comportamiento y el significado del caso de uso padre.

42
 FB

ii. Inclusión. La inclusión se utiliza en el caso de que el caso de

uso sea extenso o reutilizado. Tengo una relación de inclusión
cuando para cumplir el objetivo del CU base si o si tengo que
pasar por el CU adicional. Grafico.

Base

Adicional

iii. Extensión. La extensión se utiliza cuando tengo un CU base y

por alguna razón se extiende el CU, esta extensión se da por
una condición determinada. Se puede cumplir el objetivo del
CU base sin pasar por el otro CU. Grafico.

Base

Adicional

e. Paquetes. Se colocan grupos de casos de uso y se agrupan por

distintos criterios.

7- ¿Para qué se usa el flujo de eventos? Explique sus tipos.

Un flujo de eventos se utiliza para describir el comportamiento de un

caso de uso, debe ser lo suficientemente claro para que alguien ajeno al
sistema lo entienda.
Flujo de eventos principal. Describe el escenario por el cual se llega al
objetivo del caso de uso.
Flujo de eventos excepcional. Describe los distintos escenarios que se
pueden derivar del caso de uso, que no llegan al objetivo del caso de uso.

43
 FB

8- ¿Cuál es la relación entre CU y colaboraciones?

La colaboración es la implementación del CU, se hace creando una

sociedad de clases y otros elementos que colaborarán para llevar a cabo
el comportamiento del CU.

9- ¿Cómo modelamos el contexto de un CU?

Para modelar el contexto de un sistema:

a. Hay que identificar las fronteras del sistema, decidiendo los
comportamientos que formarán parte de él y cuáles serán ejecutados
por otras entidades externas.
b. Hay que identificar los actores del sistema, considerando los grupos
que requieren ayuda del sistema para llevar a cabo sus tareas. Que
grupos son necesarios para ejecutar las funciones del sistema, que
grupos interactúan con el hardware externo o con otros sistemas de
software y que grupos realizan funciones secundarias de
administración y mantenimiento.
c. Organizar los actores similares en jerarquías de generalización.
d. Proporcionar un estereotipo para cada uno de esos actores.

10- Como modelar requisitos con CU.

Para modelar los requisitos de un sistema:

a. Establecer el contexto del sistema, identificando actores.
b. Considerar lo que cada actor pide del sistema.
c. Nombrar los comportamientos comunes como caso de uso.
d. Factorizar el comportamiento común (relación de generalización) en
nuevos casos de uso que puedan ser utilizados por otros y factorizar
el comportamiento variante (relación de extensión) en nuevos casos
de uso que extiendan los flujos principales.
e. Modelar esos casos de uso, actores y relaciones en un diagrama de
casos de uso.
f. Completar los casos de uso con notas que enuncien los requisitos no
funcionales.

44
 FB

11- ¿Qué significa estructurar el modelo de CU? ¿Para qué se hace?

Estructurar el modelo de CU significa establecer algunos de los tipos de

relaciones entre caso de uso. Se hace para:
i. Simplificar el modelo de caso de uso.
ii. Que el modelo de caso de uso sea más fácil de mantener.
iii. Poder reutilizar partes.

12- ¿Qué es la ingeniería directa e inversa?

Ingeniería directa. Es el proceso de transformar un modelo en código, a

través de una correspondencia con un lenguaje de implementación. A un
diagrama de CU se le puede aplicar ingeniería directa para realizar
pruebas con un elemento, al cual se le aplica.
Ingeniería inversa. Es el proceso de transformar código, a través de una
correspondencia, con un lenguaje de implementación específica.
Considere un diagrama de caso de uso, a través de la ingeniería inversa,
automáticamente es impensable con la tecnología actual.

13- ¿Qué es el documento de especificación de requerimientos?

El documento de requerimiento de software es un comunicado oficial de

lo que deben implementar los desarrolladores del sistema. Incluye tanto
los requerimientos del usuario como una especificación detallada de los
requerimientos del sistema.

14- ¿Cuáles son las características de la ERS (especificación de

requerimientos)?

Una buena ERS debe tener las siguientes características:

i. No ambigua.
ii. Completa.
iii. Fácil de verificar.
iv. Consistente.
v. Clasificado por importancia.
vi. Fácil de modificar.
vii. Fácil de identificar origen y consecuencia de cada requisito.
viii. Fácil de utilizar.
45
 FB

15- ¿Cómo evoluciona la ERS?

Hay que tener en cuenta que no siempre pueden especificarse detalles al

inicio o que puede haber modificaciones, entonces el requerimiento,
debe ser especificado de la forma más completa posible aun en el caso
en que se prevean de forma inevitable revisiones en el proceso de
desarrollo. En caso de cambios deben hacerse de manera formal, para
identificar, controlar, seguir e informar los mismos. Los cambios
aprobados deben ser incluidos en la ERS.

46
 FB

Unidad N° 7: Proceso de validación de requerimientos.

1- ¿Qué es la validación de requerimientos? ¿Por qué es importante?

La validación de requerimientos es el proceso en el cual se verifica que

los requerimientos definen realmente el sistema que quiere el cliente. Es
importante porque los errores en un documento de requerimientos
pueden conducir a grandes costos por tener que rehacer; más tarde
encuentro los errores, más costoso es.

2- ¿Qué tipos de verificaciones se deben llevar a cabo?

Los tipos de verificación que se deben llevar a cabo son:

a. Comprobaciones de validez. Consiste en identificar funciones
adicionales o diferentes que se requieren.
b. Comprobaciones de consistencia. No debe haber restricciones
contradictorias, o descripciones diferentes de la misma función del
sistema.
c. Comprobaciones de totalidad. El documento de requerimiento debe
incluir requerimientos que definen todas las funciones y las
restricciones pretendidas por el usuario del sistema.
d. Comprobaciones de realismo. Los requerimientos deben
comprobarse ver si en realidad se pueden implementar. Veo si
realmente puedo hacer eso.
e. Verificabilidad. Los requerimientos del sistema deben escribirse
siempre de manera que sean verificables, es decir, escribir las pruebas
que demuestren que el sistema cumple con cada requerimiento.

3- Explique las técnicas de validación.

Técnicas de validación:
a. Revisiones de requerimiento. Un equipo de revisores analiza los
requerimientos y verifica si hay errores.
b. Creación de prototipos. Se muestra un modelo ejecutable del sistema
a los usuarios finales y clientes. Así, ellos podrán comprobar si cumple
con sus necesidades reales.

47
 FB

c. Generación de casos de prueba. Si una prueba es difícil de diseñar,

esto significa que los requerimientos serán difíciles de implementar,
por lo que se deberán reconsiderar.

4- ¿Qué es un prototipo?

Un prototipo es un modelo de comportamiento del sistema, que puede

ser usado para entenderlo completamente, con ciertos aspectos de él y
así clarificar los requerimientos. Es una representación del sistema, pero
no del sistema completo, posee características del sistema final.

5- ¿Qué utilidad tienen los prototipos?

Los prototipos ayudan a:

a. Obtener requerimientos.
b. Validar requerimientos.
c. Capacitar a los usuarios.
d. Probar el sistema.

6- ¿Cuáles son las ventajas de trabajar con prototipos?

Si bien su construcción al inicio aumenta los costos, los reduce luego.

Evita rehacer el trabajo durante el desarrollo cuando los clientes solicitan
pequeños cambios.

Ventajas:
a. Mejora la usabilidad del sistema.
b. Mejora el acoplamiento entre el sistema y la necesidad del usuario.
c. Mejora la calidad del diseño.
d. Mejora el mantenimiento.
e. Reduce el esfuerzo en el desarrollo.
Desventajas:
a. Cada vez que realizo un prototipo necesito al cliente al lado.
b. Avisar que el prototipo no es el sistema.

48
 FB

7- ¿Qué tipos de prototipos se pueden construir? Explique las

características.

Desechables. Tienen un objetivo en concreto; una vez que veo que era lo
que quería ya lo puedo desechar.
a. Sirven para el análisis y validación de requerimientos.
b. Después se redacta la especificación del sistema y se desecha el
prototipo.
c. La aplicación se desarrolla siguiendo paradigmas diferentes.
d. Problema: cuando el prototipo no se desecha y termina
convirtiéndose en el sistema final.

Evolutivos. Tienen calidad, no tienen documentación asociada.

a. Comienza con un prototipo simple, que implementa los requisitos
más importantes.
b. El prototipo se aumenta o cambia cuando se descubren nuevos
requisitos.
c. Finalmente se convierte en el sistema requerido.
d. Los sitios web y aplicaciones de comercio electrónico se construyen a
partir del prototipo evolutivo.

49
 FB

50
 FB

Unidad N° 8: Proceso unificado de desarrollo (PUD), flujo de trabajo

de requisitos y de análisis. PARTE 1.

1- ¿Qué es el proceso unificado de desarrollo? Características.

El PUD es un proceso de desarrollo de software, o sea, es un conjunto de

actividades necesarias para transformar los requisitos de un usuario en
un sistema de software. Su objetivo es guiar a los desarrolladores en la
implementación y distribución eficientes del sistema que se ajustan a las
necesidades de los clientes. El proceso unificado esta dirigido por casos
de uso, centrado en la arquitectura y es iterativo e incremental.

2- Explique brevemente como trabaja el PUD y sus fases.

En el PUD divide el tiempo total de desarrollo en cuatro fases, en donde

cada una se divide normalmente en iteraciones, a su vez cada iteración
atraviesa cinco flujos de trabajo: requisitos, análisis, diseño,
implementación y prueba.
Las fases del PUD son:

Fase de inicio: Desarrolla una descripción del producto formal y presenta

el análisis para el producto. Su objetivo es establecer:
• Principales funciones del sistema.
• Arquitectura posible.
• Plan y presupuesto del producto.
Fase de elaboración: Especifica los CU y diseña la arquitectura del
sistema en forma de vistas de cada modelo. Permite planificar las
actividades y estimar los requisitos reales para terminar el proyecto.
Fase de construcción: Se crea el producto. Al final de esta fase, el
producto contiene todos los casos de uso, pero puede tener defectos.
Fase Transición: Período en donde el producto se convierte en beta.
Implica:
• Corrección de errores.
• Incorporación de mejoras.
• Capacitación del cliente.
• Mantenimiento.

51
 FB

3- ¿Cuáles son los conceptos básicos del proceso?

Artefacto. Hace referencia a cualquier tipo de descripción o información

creada, producida, cambiada o utilizada por los trabajadores durante su
trabajo con el sistema. Un artefacto puede ser un modelo, un elemento o
un documento.
Trabajadores. Representa un puesto que puede ser asignado a una
persona o un grupo y especifica las responsabilidades y habilidades
requeridas.
Flujo de trabajo. Representa una secuencia de actividades que están
ordenadas, donde cada actividad produce una salida que sirve de entrada
para la siguiente actividad. No obstante, el diagrama de actividad
presenta solamente el flujo lógico.
Actividad. Secuencia de instrucciones con un propósito específico.

4- ¿Cuáles son los flujos fundamentales? ¿Qué modelos generan cada uno
de ellos?

Flujo de trabajo de requisito: Genera modelo de caso de uso.

Flujo de trabajo de análisis: General un modelo de análisis.
Flujo de trabajo de diseño: Genera modelo de diseño y modelo de
despliegue.
Flujo de trabajo de implementación: Genera modelo de implementación.
Flujo de trabajo de prueba: Genera modelo de prueba.

5- ¿Cuál es el propósito del flujo de trabajo de requisitos?

El propósito del flujo de trabajo de requisitos es guiar el desarrollo hacia

el sistema correcto. Esto se consigue mediante una descripción de los
requisitos del sistema, suficientemente buena como para que pueda
llegarse a un acuerdo entre el cliente y los desarrolladores sobre que
debe y que no debe hacerse del sistema. El resultado de esto ayuda al
jefe de proyecto a planificar las iteraciones y las versiones del cliente.

52
 FB

6- ¿Cómo se descubren los requisitos? (Pasos para encontrar requisitos).

Paso 1. Enumerar requisitos candidatos, los clientes, usuarios, analistas y

desarrolladores aparecen con muchas buenas ideas que podrían
convertirse en verdaderos requisitos. En la lista de características, cada
característica tiene un nombre corto y una breve explicación. También se
le puede incluir información como estado, costo estimado, prioridad,
nivel de riesgo.
Paso 2. Comprender el contexto del sistema a media que los analistas
aprenden sobre el contexto del sistema SW y lo describen en el modelo
de negocio. Este modelo especifica que procesos de negocio soportara el
sistema. A partir de identificar los objetos del dominio o del negocio
implicadas en el negocio, este modelo también establece las
competencias requeridas en cada proceso: sus trabajadores, sus
responsabilidades y las operaciones que llevan a cabo.
Paso 3. Capturar requisitos funcionales: La técnica inmediata se basa en
los casos de uso, estos casos de uso capturan, tanto los requerimientos
funcionales como los no funcionales que son específicos de cada caso de
uso. Cada usuario quiere que el sistema haga algo por él un caso de uso
es un modo de utilizar el sistema, si los analistas pueden describir todos
los casos de uso que necesita el usuario, entonces saben lo que debe
hacer el sistema.
Paso 4. Capturar requisitos no funcionales: Los requisitos no funcionales
especifican propiedades del sistema como restricciones del entorno o de
la implementación, rendimiento, dependencia de la plataforma, facilidad
de mantenimiento, extensibilidad y fiabilidad.

7- Explique brevemente el papel de los requisitos en el ciclo de vida.

El trabajo de los requisitos se hace fundamentalmente durante el inicio y

la elaboración.
a. Durante la fase de inicio, los analistas identifican la mayoría de
los casos de uso, para delimitar el sistema y alcance del
proyecto y para detallar lo más importante.
b. Durante la fase de elaboración, los analistas capturan la
mayoría de los requisitos restantes para estimar los costos.
c. Los requisitos restantes se capturan durante la fase de
construcción.

53
 FB

d. Casi no hay captura de requisitos en la fase de transición a

menos que haya requisitos que cambien.

8- ¿Cómo describimos el flujo de trabajo de requisitos?

Vamos a describir el flujo de trabajo en tres pasos:

a. Los artefactos creados en el flujo de trabajo de los requisitos.
b. Los trabajadores y participantes en el flujo de trabajo de los
requisitos.
c. El flujo de trabajo de captura de requisitos, incluyendo cada
actividad en más detalle.

9- ¿Cuáles son los artefactos que se construyen durante el flujo de trabajo

de requisitos?

Los artefactos fundamentales que se utilizan en la captura de requisitos

son el modelo de caso de uso, que incluye los casos de uso y los actores.
a. Modelos de caso de uso. Permite que los desarrolladores y los
clientes lleguen a un acuerdo sobre los requisitos. Sirve como acuerdo
y proporciona la entrada fundamental para el análisis, el diseño y las
pruebas. Es un modelo del sistema que contiene actores, casos de uso
y sus relaciones.
b. Descripción de la arquitectura. Contiene una vista de la arquitectura
del modelo de CU.
Deberá incluir los CU que se describan en alguna funcionalidad
importante o crítica, o que implique algún requisito importante que
debe desarrollarse pronto dentro del ciclo de vida del SW.
c. Glosario. Define términos importantes que los analistas utilizan para
describir el sistema. Es útil para reducir el riesgo de confusiones.
d. Prototipo de interfaz. Nos ayuda a comprender y especificar las
interacciones entre los actores humanos y el sistema durante la
captura de requisitos. No solo ayuda a desarrollar una interfaz gráfica
mejor, sino también a comprender mejor los CU.

54
 FB

10- ¿Qué trabajadores intervienen en el flujo de trabajo de requisitos?

Los trabajadores que intervienen en el flujo de trabajo de requisitos son:

a. Analista de sistemas. Es el responsable del conjunto de requisitos que
están modelados en los CU, incluyen todos los requisitos funcionales
y no funcionales que son casos de uso específicos. Además, es
responsable de limitar el sistema, encontrando actores en los casos
de uso y asegurando que el modelo de CU es completo y consistente.
b. Especialista de CU. Asume las responsabilidades de las descripciones
detalladas de uno o más CU.
c. Arquitecto. Participa en el flujo de trabajo de los requisitos para
describir la vista de la arquitectura del modelo de CU.
d. Diseñador de interfaz. Dan forma visual a las interfaces de usuario.

11- ¿Qué actividades se llevan a cabo durante el flujo de trabajo de

requisito?
Actividades:
a. Encontrar los actores. Se debe asignar un actor a cada trabajador del
negocio y un actor a cada actor del negocio que utilizará la
información del sistema. Se debe identificar al menos un usuario que
pueda representar un actor.
b. Encontrar los casos de uso. Se propone un caso de uso para cada rol
de cada trabajador que participa en la realización de CU del negocio y
que utilizará información del sistema. Cada caso de uso se debe
describir brevemente. Explicamos como se relacionan los CU entre sí.
c. Priorizar caso de uso. Determinar que CU son necesarios para el
desarrollo en las primeras iteraciones y cuales pueden dejarse para
más tarde.
Esta planificación también necesita la consideración de otros aspectos
no técnicos, como los aspectos económicos o del negocio del sistema
que va a ser desarrollado.
d. Detallar caso de uso. Describir su flujo de procesos en detalle,
diciendo como comienza, termina e interactúa con los actores. El
especificador del caso de uso detalla paso a paso la descripción de
cada caso de uso, en una especificación precisa de la sucesión de
acciones, en esta sección veremos:
i. Como estructurar la descripción para el CU.
ii. Qué incluir en una descripción del CU.
iii. Como formalizar la descripción del CU.

55
 FB

e. Estructurar la descripción de caso de uso. Debemos describir la

posible transición de estados de manera simple y precisa. Una técnica
es elegir un camino básico completo desde el estado inicial al estado
final.

56
 FB

Unidad N° 8: Proceso unificado de desarrollo (PUD), flujo de trabajo

de requisitos y de análisis. PARTE 2.

12- ¿Cuál es el propósito del FT de análisis?

Su propósito es hacer una comprensión más precisa de los requisitos,

financiándolos y estructurándolos, y una descripción para facilitar el
mantenimiento y ayudar a estructurar el sistema (identificar clases y
paquetes). Analizar los requerimientos con mayor profundidad utilizando
un lenguaje de desarrolladores para describirlos.

13- ¿Cuáles son las características del modelo de análisis?

Características del modelo de análisis:

• Descripto con un lenguaje de desarrollador.
• Vista interna del sistema.
• Estructurado por clases y paquetes estereotipados.
• Utilizado fundamentalmente por los desarrolladores para
comprender como debería ser diseñado e implementado el sistema.
• Define relaciones de CU, cada CU se realiza a partir de un diagrama de
comunicación.

14- ¿Cuáles son los artefactos que se construyen durante el FT de análisis?

Los artefactos que se construyen son:

• Modelo de análisis. Es una jerarquía de paquetes de análisis que
contienen clases de análisis y realizaciones de CU. Formado por
paquetes y diagramas de comunicación. Van a aparecer las clases,
paquetes y el diagrama de comunicación.
• Clase de análisis. Representa una abstracción de una o varias clases
y/o subsistemas del diseño del sistema. Se centra en el tratamiento
de los requisitos funcionales y posponen los no funcionales. Su
comportamiento se define mediante responsabilidades a un nivel más
alto y menos formal. Una responsabilidad es una descripción textual
de un conjunto cohesivo del comportamiento de una clase. Define
atributo de un nivel bastante alto, estos son conceptuales y
reconocibles en el dominio del problema, con frecuencia pasan a ser

57
 FB

clases en el diseño y la implementación. Participa en relaciones que

son más conceptuales que sus contrapartidas de diseño e
implementación. Siempre encajan en uno de los tres estereotipos
básicos:
a. Clases de interfaz: Se utilizan para modelar la interacción entre el
sistema y sus actores. Surgen del modelo de CU.
b. Clases de entidad: Modelan la información y el comportamiento
asociado de algún fenómeno o concepto, como una persona, un
objeto del mundo real, o un suceso del mundo real. Surgen del
modelo de objetos del dominio. Vida larga y consistente.
c. Clases de control. Representan coordinación y control de objetos.
• Relación caso de uso-análisis: Se hace a través de un diagrama de
comunicaciones.
• Paquete de análisis: Proporcionan un medio para organizar los
artefactos del modelo de análisis en piezas manejables. Un paquete
de análisis puede constar de clases de análisis, de realizaciones de CU
y de otros paquetes. Deben ser cohesivos y débilmente acoplados.
Vamos a meter clases y realizaciones de CU.
• Descripción de la arquitectura: Contiene una vista de la arquitectura
del modelo de análisis, que muestra sus artefactos significativos para
la arquitectura.

15- ¿Qué trabajadores intervienen en el FT de análisis?

Trabajadores que intervienen en el FT de análisis:

• Arquitecto: Es responsable del modelo de análisis, garantizando que
este sea correcto, consistente y legible como un todo.
• Ingeniero de CU: Es responsable de la integridad de una o más
realizaciones de CU, garantizando que cumplen los requisitos que
recaen sobre ellos.
• Ingeniero de componentes: Define y mantiene las responsabilidades,
atributos, relaciones y requisitos especiales de una o varias clases de
análisis, asegurándose de que cada clase del análisis cumple los
requisitos que se está esperando de ella de acuerdo con las
realizaciones de CU en las que participa.

58
 FB

16- ¿Qué actividades se llevan a cabo durante el FT de análisis?

Los arquitectos comienzan la creación del modelo de análisis,

identificando los paquetes de análisis principales, las clases de entidad
evidentes, y los requisitos comunes. Después, los ingenieros de CU
realizan cada CU en términos de clases del análisis participante
exponiendo los requisitos de comportamiento de cada clase. Los
ingenieros de componentes especifican posteriormente estos requisitos y
los integran dentro de cada clase creando responsabilidades, atributos y
relaciones consistentes para cada clase. Durante el análisis, el arquitecto
identifica de manera continua nuevos paquetes del análisis, clases y
requisitos comunes a medida que el modelo de análisis evoluciona, y los
ingenieros de componentes responsables de los paquetes del análisis
concreto continuamente los refinan y mantienen.

17- ¿Qué describen los diagramas de interacción? Identifique cada uno.

Los diagramas de secuencia y los diagramas de comunicación, ambos

llamados diagramas de interacción son dos de los tipos de diagramas de
UML que se utilizan para modelar los aspectos dinámicos de los sistemas.
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.
Un diagrama de secuencia es un diagrama que destaca la orientación
temporal de mensajes.
Los diagramas de comunicación se usan para modelar los aspectos
dinámicos de un sistema.
Ambos modelan lo mismo, pero de forma distinta.

18- ¿Qué describe un diagrama de colaboración o comunicación dentro de

la misma? ¿Cómo se construye? ¿Cuáles son sus elementos?

Un diagrama de comunicación destaca la organización estructural de los

objetos que envían y reciben mensajes. Posee dos características:
• El camino. El camino se dibuja haciéndolo corresponder con una
asociación. Un camino representa una fuente de conocimientos de un
objeto.

59
 FB

• El numero de secuencia. Es un numero que se incrementa

secuencialmente por cada nuevo mensaje en el flujo de control. Se
utiliza para indicar la ordenación temporal de un mensaje.

19- Concepto de interacción, mensaje y enlace.

Las interacciones se utilizan para modelar el flujo de control dentro de

una operación, una clase, un componente, un CU o el sistema completo.
Un enlace es la manera en que se vinculan las clases u objetos. Siempre
que una clase contenga una asociación con otra clase puede existir un
enlace entre las instancias de las dos clases; siempre que haya un
mensaje entre dos objetos, un objeto puede enviar mensajes al otro.
El mensaje se utiliza para la comunicación entre objetos, con la
expectativa de que se desencadenará una actividad.

60
 FB

FT REQUISITOS.

- Artefactos.
• Modelo CU.
• Descripción de la arquitectura.
• Prototipo interfaz.
• Glosario.

- Actividades.
• Encontrar actores y CU.
• Describir o detallar los CU.
• Priorizar CU.
• Estructurar CU.
• Diseñar la interfaz.

- Trabajadores.
• Analista Sistemas.
• Especialista CU.
• Arquitecto.
• Diseñador de interfaz.

61
 FB

FT ANALISIS.

- Artefactos.
• Modelo de análisis. Arquitecto.
• Clases de análisis. Ing componentes.
• Descripción arquitectura. Arquitecto.
• Paquetes de análisis. Ing componentes.
• Realización CU mediante diagrama de comunicación. Ing CU.

- Trabajadores.
• Arquitecto. Responsable del modelo de análisis.
• Ingeniero de casos de uso.
• Ingeniero de componentes.

- Actividades
• Analizar 1 caso de uso.
• Analizar 1 paquete.
• Analizar 1 clase.
• Analizar la arquitectura.

62