CUESTIONARIO

1. Describa los bloques de construcción de UML y sus estructuras.

El vocabulario de UML incluye tres clases de bloques básicos:
1. Elementos
2. Relaciones
3. Diagramas
Los elementos son abstracciones que constituyen los ciudadanos de
primera clase en un modelo; las relaciones ligan estos elementos entre sí;
los diagramas agrupan un conjunto de relaciones de elementos.
ELEMENTOS
Pueden ser:
 Elementos estructurales
 Elementos de comportamiento
 Elementos de agrupación
 Elementos de anotación
Elementos estructurales. Son los nombres de los modelos UML, en su
mayoría representan conceptos o cosas materiales.
Entre los elementos estructurales están los siguientes:
Clase: Descripción de un conjunto de objetos que comparten atributos,
operaciones, relaciones y semántica.
Interfaz: Colección de operaciones que especifican un servicio de una
clase o componente. Representa el comportamiento de una clase o
componente.
Colaboración: Define una interacción y es una sociedad de roles y otros
elementos que colaboran para proporcionar un comportamiento cooperativo
mayor que la suma de los comportamientos de sus elementos.
Caso de uso: Descripción de un conjunto de secuencias de acciones que
ejecuta un sistema.
Clase activa: Es una clase cuyos objetos tienen uno o más procesos o
hilos de ejecución.
Componente: Es una parte modular del diseño del sistema que oculta su
implementación tras un conjunto de interfaces externas.
Artefactos: Parte física y reemplazable de un sistema que contiene
información física (bits). Estos pueden ser artefactos de despliegue, código
fuente, ejecutables y scripts.
Nodo: Elemento físico que existe en tiempo de ejecución y representa un
recurso computacional.

Elementos de comportamiento. Son las partes dinámicas de los modelos

UML. Son los verbos de un modelo, representan comportamiento en el
tiempo y el espacio.
Hay tres tipos de elementos de comportamiento:
Interacción: Es un comportamiento que comprende un conjunto de
mensajes intercambiados entre un conjunto de objetos dentro de un
contexto particular.
Máquina de estados: Es un comportamiento que especifica las secuencias
de estados por la que pasa un objeto o una interacción durante su vida en
respuesta a eventos y junto con su interacción a estos eventos.
Actividad: Es un comportamiento que especifica la secuencia de pasos
que ejecuta un proceso computacional.

Elementos de agrupación. Son las partes organizativas de los modelos

UML. El elemento principal es el paquete, el cual es un mecanismo de
propósito general para organizar el diseño se visualiza como carpetas.

Elementos de anotación. Son las partes explicativas de los modelos UML.

Sirven para describir y realizar observaciones sobre cualquier elemento de
un modelo. El principal tipo de elemento de anotación es la nota.

RELACIONES
Hay cuatro tipos de relaciones:
  Dependencia
 Asociación
 Generalización
 Realización

Dependencia. Es una relación semántica entre un elemento (elemento

independiente) que puede afectar a la semántica de otro elemento (elemento
dependiente).
Asociación. Es una relación estructural entre clases, describe conexiones
entre instancias de clases.
Generalización. Es una relación de especialización/generalización en el cual
el elemento especializado (el hijo) se basa en la especificación del elemento
generalizado (el padre). El hijo comparte la estructura y el comportamiento del
padre.
Realización. Es una relación semántica entre elementos estructurales o
también llamados clasificadores. Donde un clasificador especifica un contrato
que otro clasificador garantiza que cumplirá.

DIAGRAMAS
Un diagrama es una representación gráfica de un conjunto de elementos a
través de estos se visualiza el sistema desde diferentes perspectivas.
UML utiliza 13 diagramas los cuales se dividen en Diagramas de estructura y
Diagramas de comportamiento.
Diagramas de estructura. Enfatizan que elementos deberían existir en el
sistema a modelar. En este tipo se encuentran:
 Diagrama de clases
 Diagrama de objetos
 Diagrama de componentes
 Diagrama de paquete
 Diagrama de despliegue
 Diagrama de estructura compuesta
Diagramas de comportamiento. Enfatizan que es lo que debería suceder (las
interacciones) en el sistema a modelar. En este tipo de diagrama se
encuentran:
 Diagrama de actividad
 Diagrama de estados
 Diagrama de tiempo
 Diagrama de visión global de interacciones
 Diagrama de casos de uso
 Diagrama de secuencia
 Diagrama de comunicación

2. ¿Cómo es el marco de trabajo de UML?

Para la comprensión de UML, se necesita adquirir un modelo conceptual
del lenguaje, para esto se requiere aprender tres elementos principales: los
bloques básicos de construcción de UML, las reglas que dictan como se
pueden combinar estos bloques básicos y algunos mecanismos comunes
que se aplican a través de UML.
Bloques básicos:
 Elementos
 Relaciones
 Diagramas
Reglas
Los bloques de construcción de UML son combinados tomando en cuenta
las reglas sintácticas y semánticas para:
 Nombres
Cómo llamar a elementos, relaciones y diagramas.
 Alcance
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.
 Ejecución
Qué significa ejecutar o simular un modelo dinámico.
Mecanismos comunes
Son los patrones arquitectónicos que definen el estilo del proyecto:
 Especificaciones
 Adornos
 Divisiones comunes
 Mecanismos de extensibilidad

3. Definir la visión general de UML.

. UML es un lenguaje para visualizar, especificar, construir y documentar los
artefactos de un sistema con gran cantidad de software
UML es un lenguaje
Un lenguaje proporciona un vocabulario y las reglas para combinar palabras
d ese vocabulario con el objetivo de posibilitar la comunicación. El
modelado proporciona una comprensión de un sistema. El vocabulario y las
reglas de un lenguaje como UML indican cómo crear y leer modelos bien
formados, pero no dicen qué modelos se deben crear ni cuándo.
UML es un lenguaje para visualizar
UML proporciona un conjunto de diagramas que ayudan a describir de una
forma más completa el sistema. Detrás de cada símbolo en la notación hay
una semántica bien definida de tal forma que los desarrolladores puedan
interpretar los modelos sin ambigüedad.
UML es un lenguaje para especificar
En este contexto, especificar significa construir modelos precisos y
completos. UML cubre la especificación de todas las decisiones de análisis,
diseño e implementación que deben realizarse al desarrollar y desplegar un
sistema con gran cantidad de software.
UML es un lenguaje para construir
 Es posible establecer correspondencias desde un modelo UML a un
lenguaje de programación. Esta correspondencia permite ingeniería directa
e inversa. En generación de código a partir de un modelo UML.
UML es un lenguaje para documentar
UML produce artefactos además de código ejecutable. Cubre la
documentación de la arquitectura de un sistema y todos sus detalles.
Proporciona un lenguaje para expresar requisitos y pruebas. También
proporciona un lenguaje para modelar actividades de planificación de
proyectos y gestión de versiones.

4. ¿Por qué es necesario contar con diversos diagramas en el modelo de

un sistema?
En base al cuarto principio de modelado:
“Un único modelo o vista no es suficiente. Cualquier sistema no trivial se
aborda mejor a través de un pequeño conjunto de modelos casi
independientes con múltiples puntos de vista”
Para poder tener una visión y comprensión más completa del sistema a
modelar. Claro que según la naturaleza del sistema algunos tomarán más
importancia que otros.

5. Describir los mecanismos comunes y técnicas comunes del modelado

de UML.
MECANISMOS COMUNES EN UML
Especificaciones
Detrás de cada elemento de su notación gráfica hay una especificación que
proporciona una explicación textual de la síntesis y semántica de ese
bloque de construcción.
La especificación de UML se utiliza para expresar los detalles del sistema,
proporciona una base semántica que incluye a todas las partes de todos los
modelos de un sistema y cada parte está relacionada con las otras de
manera consistente.
 Adornos
Son los símbolos empleados en la representación gráfica para brindar
determinada especificación.
Divisiones comunes
Una clase es una abstracción. Un objeto es una manifestación concreta de
esa abstracción. En UML se puede modelar tanto clases como objetos.
 Interfaz e implementación
Una interfaz declara un contrato y una implementación representa una
realización concreta de ese contrato, responsable de hacer efectiva la
semántica completa de la interfaz de forma fidedigna.
 Tipo y rol
El tipo declara la base de una entidad como un objeto, un atributo o un
parámetro. Un rol describe el significado de una entidad en un contexto
como una clase, un componente o una elaboración.
Mecanismos de extensibilidad
UML permite extender el lenguaje de manera controlada a través del uso de
Estereotipo. Permite la creación de nuevos tipos de bloques de
construcción que derivan de los existentes.
Valor etiquetado. Extiende las propiedades de un estereotipo de UML
permitiendo añadir nueva información en la especificación de ese
estereotipo.
Restricción. Extiende la semántica de un bloque de construcción UML,
permitiendo añadir nuevas reglas o modificar las existentes.

6. ¿Cuáles diagramas le dan una perspectiva estática a un sistema?

Los diagramas de estructura son aquellos que le dan una perspectiva
estática al sistema. Estos son:
 Diagrama de clases
 Diagrama de objetos
 Diagrama de componentes
 Diagrama de paquete
  Diagrama de despliegue
 Diagrama de estructura compuesta

7. ¿Qué es el Proceso Unificado?

El Proceso Unificado es un proceso de desarrollo de software. Un proceso
de desarrollo de software es el conjunto de actividades necesarias para
transformar los requisitos de un usuario en un sistema software.
Es un marco de trabajo genérico que puede especializarse para una gran
variedad de sistemas software, para diferentes áreas de aplicación,
diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes
tamaños de proyecto.
El Proceso Unificado está basado en componentes interconectados a
través de interfaces bien definidas.
Utiliza el Lenguaje Unificado de Modelado para preparar todos los
esquemas de un sistema software.
Presenta tres aspectos definitorios:
 Dirigido por casos de uso
 Centrado en la arquitectura
 Iterativo e incremental

8. Describir Herencia y polimorfismo de las clases en UML.

Herencia
Cuando se organizan clases en una jerarquía de generalización
implícitamente se tiene herencia entre las clases donde las subclases
heredan todas las características de sus súper clases: sus atributos,
relaciones y restricciones.
Las subclases pueden añadir y anular operaciones de subclase.
Polimorfismo
Una operación polimórfica es una que tiene muchas implementaciones. Un
conjunto de operaciones abstractas es una forma de definir un conjunto de
operaciones que todas las subclases concretas deben implementar. Esto se
 conoce como un contrato. Esta es la esencia del polimorfismo; los objetos
de clases diferentes tienen operaciones con la misma firma pero diferentes
implementaciones.

9. Usando diagrama de actividades organizado en calles describa el

Flujo de Trabajo de captura de requisitos según el PUDS.

10. Usando diagrama de actividades organizado en calles describa el

Flujo de Trabajo Análisis según el PUDS.
11. ¿Cuáles diagramas le dan una perspectiva dinámica a un sistema
(estos muestran en el cambio progresivo)?
Los diagramas de comportamiento son aquellos que le brindan una
perspectiva dinámica al sistema, puesto que indican la forma de trabajo del
sistema.
 Diagrama de actividad
 Diagrama de estados
 Diagrama de tiempo
 Diagrama de visión global de interacciones
 Diagrama de casos de uso
 Diagrama de secuencia
 Diagrama de comunicación

12. ¿Qué es un sistema software?

Un sistema software es una descripción en forma binaria que puede “ser
leída” y “ser comprendida” por un computador.
Un sistema es todos los artefactos que se necesitan para representarlo en
forma comprensible por máquinas u hombres, para las máquinas, los
trabajadores y los interesados. Las máquinas son las herramienta,
compiladores, u ordenadores destinatarios. Entre los trabajadores tenemos
directores, arquitectos, desarrolladores, ingenieros de prueba, personal de
marketing, administradores y otros. Los interesados son los inversores,
usuarios, comerciales, jefes de proyecto, directores de línea de producto,
personal de producción, agencia de regulación, etc.

13. ¿Qué es un artefacto y qué es un esbozo?

Artefacto
Es un término general para cualquier tipo de información creada, producida,
cambiada o utilizada por los trabajadores en el desarrollo del sistema.
Esbozo
 Es una idea o plan general en sus líneas generales. Con esta herramienta
cubrimos una visión ya sea en la creación de diagramas o del sistema en sí.
Un esbozo es un bosquejo, es decir, el producto se encuentra en la fase en
la que todavía está sujeto a modificaciones.

14. Definir y diseñar la vida del proceso unificado y cuáles son las fases
dentro de un ciclo.
El proceso Unificado se repite a lo largo de una serie de ciclos que
constituyen la vida de un sistema. Cada ciclo concluye con una versión del
producto para los clientes.
Cada ciclo consta de cuatro fases: inicio, elaboración, construcción y
transición. Cada fase a su vez se subdivide en iteraciones.

Durante la fase de inicio, se desarrolla una descripción del producto final a

partir de una buena idea y se presenta el análisis de negocio para el
producto. En esta fase, se identifican y priorizan los riesgos más
importantes, se planifican en detalle la fase de elaboración y se estima el
proyecto de manera aproximada.

Durante la fase de elaboración, se especifican en detalle la mayoría de los

casos de uso del producto y se diseña la arquitectura del sistema. La
relación entre la arquitectura del sistema y el propio sistema es primordial.
Una manera simple de expresarlo es decir que la arquitectura es análoga al
esqueleto cubierto por la piel pero con muy poco músculo (el software)
entre los huesos y la piel –solo lo necesario para permitir que el esqueleto
haga movimientos básicos. El sistema es el cuerpo entero con esqueleto,
piel y músculo.
La arquitectura se expresa en forma de vistas de todos los modelos del
sistema, los cuales representan el sistema entero.
Al final de esta fase el director de proyecto está en disposición de planificar
actividades y estimar recursos para terminar el proyecto.
 Durante la fase de construcción se crea el producto –se añaden los
músculos (software terminado) al esqueleto (la arquitectura). En esta fase,
la línea base de la arquitectura crece hasta convertirse en el sistema
completo. La descripción evoluciona hasta convertirse en un producto
terminado. Al final de esta fase el producto contiene todos los casos de uso
que la dirección y el cliente han acordado para el desarrollo de esta versión.

La fase de transición cubre el periodo durante el cual el producto se

convierte en versión beta. La cual es puesta a prueba para corregir los
errores que pueda presentar e incorporar mejoras sugeridas. Esta fase
conlleva actividades para la fabricación, formación del cliente, el
proporcionar la línea de ayuda y la corrección de los defectos que
encuentran tras la entrega.

15. Represente gráficamente el vocabulario de UML.

UML proporciona a los desarrolladores un vocabulario que incluye tres
categorías, elementos, relaciones y diagramas. Hay cuatro tipos de
elementos: estructurales, de comportamiento, de agrupación y de
anotación. Hay siete tipos principales de elementos estructurales: casos de
uso, clases, clases activas, interfaces, componentes, colaboraciones y
nodos. Hay dos tipos de elementos de comportamiento: interacciones y
máquinas de estado. Hay cuatro tipos de agrupaciones: paquetes, modelos,
subsistemas y marcos de trabajo. Y hay un tipo principal de elementos de
anotaciones: notas.
Dentro de la segunda categoría, la de relaciones, encontramos de tres
tipos: de dependencia, de asociación y de generalización.
Y en la tercera categoría, la de diagramas, UML proporciona nueve tipos:
diagramas de caso de uso, de clases, de objetos, de secuencia, de
colaboración, de estados, de actividad, de componentes y de despliegue.
Mecanismos de extensibilidad
UML proporciona mecanismos de extensibilidad, los cuales permiten a sus
usuarios refinar su sintaxis y su semántica. UML puede, por tanto, ajustarse
a un sistema, proyecto o proceso de desarrollo específico si es necesario.
Los mecanismos de extensibilidad incluyen estereotipos, valores
etiquetados y restricciones. Los estereotipos proporcionan una forma de
definir nuevos elementos extendiendo y refinando la semántica de
elementos como elementos y relaciones. Los valores etiquetados
proporcionan una forma de definir nuevas propiedades de elementos ya
existentes. Finalmente, las restricciones proporcionan una forma de
imponer reglas sobre elementos y sus propiedades.
Elementos estructurales
Elementos de comportamiento

Elementos de agrupación

Elementos de anotación

Relaciones de dependencia

Relaciones de asociación
 Relaciones de generalización

Mecanismos de extensibilidad

16. Hacer dos ejemplos de cada una de las relaciones posibles en un

diagrama de casos de uso.
Relación generalización

Ejemplo 1: En un sistema bancario puede tenerse el caso de uso validar

usuario, responsable de verificar la identidad del usuario. Además, podría
haber dos hijos especializados de este caso de uso (comprobar clave y
examinar retina), los cuales se comportarían como validar usuario y podrían
utilizarse donde quiera que apareciera validar usuario.

Ejemplo 2:

Realizar un pago en efectivo y realizar un pago con tarjeta de crédito son en

sí dos tipos de pago,
Relación de inclusión

Ejemplo 1: Seguir pedido obtiene y verifica el número de pedido, está

incluido en validar usuario, para cada parte del pedido consultar el estado
del pedido e informar el estado global al usuario.

Ejemplo 2: Se registra un nuevo usuario y en caso de que exista se inicia

sesión, de acuerdo al grupo de usuarios que pertenezca.

Relación de extensión

Ejemplo 1: Hacer pedido

 Ejemplo 2: Administrar privilegios de acuerdo a una organización pro grupos
de usuario.

17. ¿Cuándo y cómo se desarrollar un modelo de negocio y un modelo de

dominio?
Modelo de dominio
Se utiliza habitualmente en reuniones organizadas por los analistas del
dominio que utilizan UML y otros lenguajes de modelado para documentar
los resultados.
El objetivo es comprender y describir las clases más importantes del
contexto del sistema. El modelado del dominio debería contribuir a una
comprensión del problema.
Modelo de negocio
Describe los procesos de negocio de una empresa en términos de casos de
uso de negocio y actores de negocio.
Este se desarrolla en dos pasos:
- Los modeladores del negocio deben confeccionan en un modelo
de casos de uso del negocio que identifique los actores del
negocio y los casos de uso del negocio.
- Los modeladores deben desarrollar un modelo de objetos del
negocio compuesto por trabajadores, entidades de negocio y
unidades de trabajo.

18. ¿Cuándo aparece una clase asociación?, realice dos ejemplos.

 Cuando dos elementos presentan una relación o conexión, es decir cuando
colaboran entre sí.

Ejemplos:

19. De ejemplos de clase base y clase hoja en UML

Ejemplo 1: La clase base es la clase figura que contiene el atributo común
de las clases hoja, las clases hoja son: rectángulo, circulo y polígono, estas
por su parte contienen sus atributos propios como ser ancho y alto en el
caso de rectángulo, radio en el caso de circulo, vértice en caso de polígono.
 Ejemplo 2: La clase base es la clase Vehículo, contiene los atributos
comunes de las clases hoja que son: dueño, puertas y ruedas. Las clases
hijo son Auto y Camioneta, las cuales contienen atributos propios que son
en el caso de clase auto, el atributo descapotable, en el caso de camioneta
el atributo tara y carga.

20. En un diagrama de actividad de UML a que se denomina “estado de

acción” y “estado de actividad”.
Las acciones no se pueden descomponer. Además, las acciones son
atómicas, lo que significa que pueden ocurrir eventos, pero el
 comportamiento interno de la acción no es visible. No se puede ejecutar
una parte de una acción; o se ejecuta o no se ejecuta.
Un nodo de actividad es una unidad organizativa dentro de una actividad.
En general, los nodos de actividad don agrupaciones anidadas de acciones
o de otros nodos de actividad. Además, los nodos de actividad tienen una
subestructura visible; en general, se considera que se necesita un cierto
tiempo para que se completen. Una acción puede verse como un caso
especial de un nodo de actividad. Una acción es un nodo de actividad que
no puede descomponerse más. Análogamente, un nodo de actividad puede
ser visto como un elemento compuesto, cuyo flujo de control se compone
de otros nodos de actividad y acciones. Si se entra en los detalles de un
nodo de actividad y las acciones, excepto que un nodo de actividad puede
tener partes adicionales, que normalmente una herramienta de edición
mantendrá asociada al nodo internamente.

21. Usando diagrama de actividades organizado en calles describa el

Flujo de Trabajo de captura de requisitos según el PUDS.
22. Usando diagrama de actividades organizado en calles describa el
Flujo de Trabajo Análisis según el PUDS.

23. Usando diagrama de actividades organizado en calles describa el

Flujo de Trabajo de Diseño según el PUDS.
24. Usando diagrama de actividades organizado en calles describa el
Flujo de Trabajo de Implementación según el PUDS.

25. Realice dos ejemplos de cada tipo de relación utilizando casos de uso
Relación generalización
Ejemplo 1: En un sistema bancario puede tenerse el caso de uso validar
usuario, responsable de verificar la identidad del usuario. Además, podría
haber dos hijos especializados de este caso de uso (comprobar clave y
examinar retina), los cuales se comportarían como validar usuario y podrían
utilizarse donde quiera que apareciera validar usuario.

Ejemplo 2:
Realizar un pago en efectivo y realizar un pago con tarjeta de crédito son en
sí dos tipos de pago,
Relación de inclusión

Ejemplo 1: Seguir pedido obtiene y verifica el número de pedido, está

incluido en validar usuario, para cada parte del pedido consultar el estado
del pedido e informar el estado global al usuario.

Ejemplo 2: Se registra un nuevo usuario y en caso de que exista se inicia

sesión, de acuerdo al grupo de usuarios que pertenezca.

Relación de extensión

Ejemplo 1: Hacer pedido

 Ejemplo 2: Administrar privilegios de acuerdo a una organización pro grupos
de usuario.

26. ¿Bajo qué criterios decide usar los estereotipo <<uses>> y

<<extiende>> en un diagrama de casos de uso?
<<use>>
Es el estereotipo de dependencia más común. Ésta dependencia esta
generada por cualquier de los siguientes casos:
Una operación de clase A necesita un parámetro de la clase B.
Una operación de clase A devuelve un valor de la clase B.
Una operación de clase A utiliza un objeto de clase B en algún lugar en su
implementación, pero no como atributo.
<<extend>>
Se emplea para especificar exactamente qué puntos de extensión en el
caso de uso se están extendiendo. Engancha nuevos comportamientos.
Cuando se utiliza <<extend>> el caso de uso base actúa como un marco de
trabajo modular en el que conectar extensiones en puntos de extensión
definidos.

27. ¿Cómo sugiere el PUDS distribuir el esfuerzo y el tiempo en una

planificación de un proyecto de software?
Sugiere dividir el trabajo en partes más pequeñas o mini proyectos. Por lo
cual una de sus principales características indica que es Iterativo e
incremental. Para una efectividad máxima, las iteraciones deben ser
controladas; esto decir deben seleccionarse y ejecutarse de forma
planificada.
 Es importante secuenciar las iteraciones en un orden lógico,
Un proyecto con éxito se ejecutará de forma directa, solo con pequeñas
desviaciones del curso que los desarrolladores planificaron inicialmente.
´Por supuesto, en la medida en que se añaden iteraciones o se altere el
orden de las mismas por problemas inesperados, el proceso de desarrollo
consumirá más esfuerzos y tiempo.

28. ¿Es posible tener un caso de uso que no tenga ningún actor?
Sí, es posible que un caso de uso no se encuentre relacionado de forma
directa con un actor si no a través de otra que la contenga.

29. ¿Pueden existir Casos de Uso que solo existan como inclusión o
extensión de otros CU y nunca sean invocados por un Actor, sino por
los CU que lo incluyen o lo extienden?
Si, estos casos de uso se relacionan de manera indirecta con los actores.

30. ¿Un caso de uso representa a un requerimiento funcional?

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

31. ¿Durante la captura de requisitos según el PUDS a que se denomina

factorización?
Se denomina factorización de casos de uso cuando organizamos un
conjunto de casos de uso en: versiones especializadas de otros casos de
uso, casos de uso incluidos como parte de otros, y casos de uso que se
extienden el comportamiento de otros casos de uso básicos.
32. ¿Por qué es necesario contar con diversos diagramas en el modelo de
un sistema?
En base al cuarto principio de modelado:
“Un único modelo o vista no es suficiente. Cualquier sistema no trivial se
aborda mejor a través de un pequeño conjunto de modelos casi
independientes con múltiples puntos de vista”
Para poder tener una visión y comprensión más completa del sistema a
modelar. Claro que según la naturaleza del sistema algunos tomarán más
importancia que otros.

33. Con UML como modelaría una estructura de generalización /

especialización y luego haga el mapeo a una BD Relacional (haga un
ejemplo).

CI
Apellidos
Nombre
Edad

Persona

CI Apellidos Nombre edad

PK

Docente
CI Horas Tarifa
 PK/FK

Alumno
CI Nota1 Nota2 Nota3
PK/FK

34. Explicar las cuatro principales características de UML.

Personas
Los principales autores de un proyecto software son los arquitectos,
desarrolladores, ingenieros de prueba, y el personal de gestión que les da
soporte, además de los usuarios, clientes y otros interesados. Las personas
son realmente seres humanos, a diferencia del término abstracto
trabajador.
Proyecto
trasformar los requisitos de usuario en un producto. Un proceso es una
plantilla para crear Elemento organizativo a través del cual se gestiona el
desarrollo de software El resultado de un proyecto es una versión del
producto.
Producto
Artefactos que se crean durante la vida del proyecto, como los modelos,
código fuente, ejecutables y documentación.
Proceso
Un proceso de ingeniería de software es una definición del conjunto
completo de actividades necesarias para proyectos.

35. En un diagrama de casos uso muestre el uso de generalización /

especialización.
Generalización de casos de uso
La generalización de caso de uso se utiliza tiene uno o más casos de uso
que son realmente especificaciones o un caso más general. Se utilizan para
simplificar un el modelo de casos de uso
 En la generalización de caso de uso, los casos de uso hijos representan
formas más específicas del padre.
Los hijos pueden:
 Heredar características de su caso de uso padre.
 Añadir nuevas características.
 Anular (cambiar) características heredadas.
El caso de uso hijo hereda automáticamente todas las características de su
padre. Sin embargo, no todos los tipos de características de caso de uso se
pueden anular.
Por ejemplo:

Especialización Generalización

36. Haga un ejemplo de un diagrama de clases que contenga una

asociación recursiva y que genere una clase asociación. Luego realice
el mapeo a un BD relacional.

Trabajador

código FechaIngreso Nombre Sexo codigoDirige

PK FK

Teléfono

ID Numero codTrabajador
PK FK

37. Haga un diagrama de clases para el registro de notas de alumnos,

considere que un alumno lleva más de una materia, y que una misma
materia puede ser dictada por más de un docente.
En base al tipo de inscripción realizada en la universidad, en la que la
inscripción se realiza por grupos tanto alumno como docente deben pasar
por esta clase para relacionarse posteriormente con la clase intermedia
materiaCarrera que es una clase intermedia entre carrera y materia.

38. Realice ejemplos utilizando agregación y composición entre clases.

Ejemplo agregación-composición
 Un almacén posee cuentas y clientes
  Cuando se destruye el objeto almacén, también desaparecen los
objetos cuentas asociados, mientras los objetos clientes no.

39. Concepto de diagrama de despliegue y hacer ejemplos.

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

40. Concepto de diagrama de componente y hacer ejemplo.

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

41. Haga un ejemplo donde se vea un diseño con problemas de

acoplamiento y cohesión y otro ejemplo libre de esos problemas.
Estos dos métodos (en C#), están totalmente desacoplados. Ninguno de ellos necesita al
otro para hacer su trabajo.

static int metodo1(int a, int b)

 {

return a * b;

static int metodo2(int a, int b)

return a + b;

II) Acoplamiento normal

El acoplamiento más común que existe es aquel en el que una unidad de software necesita
del trabajo que hace la otra.

Por ejemplo, estos dos métodos tienen un acoplamiento normal.

static int metodo1(int a, int b)

int c = metodo2(a, b); ;

return 2 * c;

static int metodo2(int a, int b)

return a + b;

42. ¿Cómo representa el diseño modular con UML? (haga un ejemplo).

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

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

usuario"), presenta el sistema al usuario, le comunica la información y captura
la información del usuario en un mínimo de proceso (realiza un filtrado previo
para comprobar que no hay errores de formato). También es conocida como
interfaz gráfica y debe tener la característica de ser "amigable" (entendible y
fácil de usar) para el usuario. Esta capa se comunica únicamente con la capa
de negocio.

Capa de negocio: es donde residen los programas que se ejecutan, se

reciben las peticiones del usuario y se envían las respuestas tras el proceso.
Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí
donde se establecen todas las reglas que deben cumplirse. Esta capa se
comunica con la capa de presentación, para recibir las solicitudes y presentar
los resultados, y con la capa de datos, para solicitar al gestor de base de
datos almacenar o recuperar datos de él. También se consideran aquí los
programas de aplicación.

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

mismos. Está formada por uno o más gestores de bases de datos que realizan
todo el almacenamiento de datos, reciben solicitudes de almacenamiento o
recuperación de información desde la capa de negocio.

Por ejemplo:

43. En un diagrama de casos uso muestre el uso de generalización /

especialización.
 La generalización de caso de uso se utiliza tiene uno o más casos de uso
que son realmente especificaciones o un caso más general. Se utilizan para
simplificar un el modelo de casos de uso. En la generalización de caso de
uso, los casos de uso hijos representan formas más específicas del padre.
Los hijos pueden:
 Heredar características de su caso de uso padre.
 Añadir nuevas características.
 Anular (cambiar) características heredadas.
El caso de uso hijo hereda automáticamente todas las características de su
padre. Sin embargo, no todos los tipos de características de caso de uso se
pueden anular.
Por ejemplo:

Especialización Generalización

44. Caso de estudio: Sistema de información para administrar pacientes

de una unidad sanitaria que tiene diferentes especialidades de
médicos que atienden en horarios definidos y realizan seguimientos y
tratamientos por cada paciente……
Diseñar el diagrama general de casos de uso.
45. Suponga que creara un sistema informático que jugara ajedrez con un
usuario. ¿Cuáles diagramas de UML serían útiles para diseñar el
sistema?,¿Porque?
Utilizaría el diagrama de clases para describir los elementos del sistema, el
diagrama de secuencia para expresar las situaciones posibles al momento
de realizar una jugada y el diagrama de actividad para explicar la dinámica
del juego.