Gran compendio de los modelos de UML, que incluye todos los diagramas asociados , sus representaciones, componentes y ejemplos. Los diagramas de casos de uso, de clases, de distribución, de componentes, de colaboración , de objetos, de actividades , de secuencia, de estados y de colaboración son considerados en este gran compendio. Al finalizar la presentación se tendrá una idea general de los elementos fundamentales del diseño de sistemas empleando UML.

1. UML
Diseño de sistemas
Compendio

2. UML (Unified Modeling Language)
 El mundo esta compuesto por sistemas complejos, los
ingenieros deben entender estos sistemas y
representarlos de alguna forma.
 UML emplea símbolos y diagramas para comunicar la
idea de un diseño.
 Es usado entender, diseñar, navegar , configurar,
mantener y controlar información acerca de un sistema.

3. UML
 UML no es una metodología
 No define estándares de procesos.
 La estructura Estática y Dinámica de un sistema es
capturada.
 Estática: Objetos importantes del sistema y sus relaciones.
 Dinámica: Relación de los objetos en el tiempo (Histórico).

4. UML
 No es un lenguaje de programación.
 Herramientas permiten crear código aplicando
“ingeniería inversa”.
 Propósito general.
 Se modela la lógica del Negocio.

5. Porque Modelar?
 Para asegurarse que las aplicaciones trabajaran.
 Para reducir el numero de errores que se presentan.
 Para permitirle al usuario final ver las funcionalidades
del su aplicativo antes de que este terminado.
 Para definir un puente de comunicación.

6. Porque es necesario UML
 Planificación
 Los sistemas son muy complejos y difíciles de
administrar.
 Los nuevos desarrollos se hacen en equipos.
 Reducir el tiempo de desarrollo.
 Diseños sólidos.

7. Historia y Concepción
 UML nació por un esfuerzo de simplificar y consolidar el
gran numero de desarrollos orientados a objetos que
estaban apareciendo.
 Grady Booch, James Rumbaugh e Ivan Jacobson “Los
tres amigos”.
 OMG (Object Management Group) lo popularizo.

8. Naturaleza de los Modelos
UML
 Modelo:
 Representación de algo por medio del mismo u otro medio.
 Se expresa de forma que se facilite el trabajo.
 Puede tomar varias formas.
 Se emplean para capturar requerimientos y los dominios
de conocimiento que poseen los interesados y que pueden
entender.
 Arquitectos – Analistas – Programadores – Directores de
Proyectos – Clientes – Usuario final – Patrocinadores y
operadores.

9. Modelos
 Pensar en el diseño de un sistema:
 Así como los arquitectos emplean bocetos,
en la Ing. Software se emplean los modelos para
explorar con diversas arquitecturas y soluciones a un
problema.
 Decisiones de Diseño de forma independiente.
 Los modelos permiten acceder a vistas diferentes
del mismo sistema.
 Planos eléctricos – Planos de tuberías – Planos de redes

10. Modelos
 Generar Productos
 Clases – bases de datos – procedimientos – guías –
Configuraciones.
 Organizar, Filtrar la información de grandes Sistemas.
 Encontrar la información útil para los sistemas no es fácil.
 Los modelos presentan la información de diferentes formas
y formatos.

11. Modelos
 Explorar múltiples soluciones económicamente.
 Se pueden explorar diferentes diseños y realizar los
cálculos de costo y riesgos antes de iniciar la construcción.
 Control completo
 Algunos sistemas presentan tan complejidad que solo es
posible controlarlos cuando se realiza la modelación.

12. Modelos
 Completar sistemas parciales:
 Durante el desarrollo de un modelado se pueden
completar aspectos olvidados de un sistema.
 Los modelos son evolutivos.
 Los modelos se trabajan en procesos iterativos y entre más
niveles avance un modelo más detallado y completo se
vuelve.

13. Diagramas UML - I
 Diagramas más comunes:
 Estructural:
 Vista Estática
 Diagrama de Clases:
 Representación Grafica de elementos que conformaran el diseño, junto con sus
relaciones, dependencias e interfaces.
Automóvil
marca
modelo
serie
color
encender()
apagar()
acelerar()

14. Diagramas UML - II
 Estructural:
 Vista Caso de Uso
 Diagrama de Casos de Uso:
 Modelo que presenta las relaciones existentes entre actores
y casos de uso.
 Actor: Abstracción de una entidad que interactúa
directamente con el sistema. Puede ser una persona, otro
sistema, un subsistema o una clase.
 Caso de Uso: Especificación de una secuencia de acciones,
variantes ..etc. Que el sistema puede realizar al
interactuar con un actor.

15. Diagramas UML- III
 Estructural:
 Vista de Implementación – Vista de Despliegue
 Diagrama de Componentes: Diagrama que presenta las relaciones y dependencias entre
componentes.
 Componente: Parte reemplazable de un sistema . Representa una parte física del sistema
(Código, binario, ejecutable). Un componente puede ser accedido a través de las interfaces
que implementa.
Motor
Chequeo_motor
inicio_motor

16. Diagramas UML - IV
 Estructural:
 Vista de Implementación – Vista de Despliegue
 Diagrama de Despliegue: Presenta la configuración en tiempo de
ejecución , los nodos, los componentes y los objetos.
 Nodo: Representación de un objeto computacional físico.

17. Diagramas UML - V
 Dinámico:
 Vista de Estado de la maquina
 Diagrama de estados: Presenta los estados de la maquina, y el
comportamiento de los elementos a través del tiempo

18. Diagramas UML - VI
 Dinámico:
 Vista de Actividades
 Diagrama de Actividades: Presenta un flujo de actividades o
workflow que se disparan tras la ejecución de otra actividad. Se
enfatiza la secuencia.
 Branch: rama
 Fork of Control: Bifurcación
 Conditional Thread : Hilo Condicional
 Join of Control: Union
 Merge: Combinación

19. Diagramas UML

20. Diagramas UML - VII
 Dinámico:
 Vista de Interacción
 Diagrama de Secuencia: Presenta las interacciones de los objetos
colocadas en una línea de secuencia.
 Los objetos interactúan intercambiando mensajes.
 Se trabajan dos dimensiones:
 Vertical: Representa el tiempo.
 Horizontal: Representa las interacciones.
 Los objetos se representan en columnas independientes.
 Cada mensaje es representado por una flecha horizontal.

21. Diagramas UML

22. Diagramas UML - VIII
 Dinámico:
 Vista de Interacción
 Diagrama de Colaboración: Presenta las interacciones
organizadas alrededor de roles y sus colaboraciones.
 Representa relaciones
 No maneja el tiempo como una dimensión separada.
 Presenta información similar al diagrama de secuencia pero de
forma diferente.
 Los mensajes están acompañados por una etiqueta numérica que
indica el orden en que se presentan.
 Si existen parámetros en los mensajes, estos se ubicaran dentro
de parentesis.

23. Diagramas UML

24. Modelos

25. Casos de uso
1

26. Casos de Uso
 Representa funcionalidad.
 Grafo de actores y un conjunto de casos de uso.
 Las relaciones son asociaciones entre actores y casos de
uso.
 Se puede emplear rectángulos para limitar las fronteras
del sistema.

27. Casos de Uso
 Actor:
 Rol de un usuario dentro de un sistema.
 No necesariamente representa una persona.
 Otros sistemas
 Material externo
 La misma persona puede ser varios actores
 El nombre del actor lo describe

28. Casos de Uso
 Caso de uso:
 Representación de una unidad funcional del sistema.
 Se caracteriza por la secuencias.
 Se representan por un elipse que contiene el nombre del caso de uso.
 Se ejecutan tras una orden de un agente externo.
 Se pueden emplear notas para aclarar información incompleta o
ambigua.

29. Casos de Uso
 Relaciones:
 Comunicación:
 La mas empleada, representa una comunicación directa entre
actor y caso de uso.

30. Casos de uso
 Relaciones:
 Inclusión:
 Un caso de uso implementa el mismo comportamiento de
otro.

31. Casos de Uso
 Relaciones:
 Extensión:
 Extiende el comportamiento de otro caso de uso.

32. Casos de Uso
 Include & Extend:

33. Casos de Uso
 Relaciones:
 Herencia:
 Un caso de uso hereda las especificaciones de otro caso de uso
y las modifica.

34. Casos de Uso
 Consideraciones:
 Identificar las tareas que realiza un actor.
 Los cambios se informan a los actores?
 La información es alterada:
 Inserta – Borra – Actualiza
 Que mensajes se intercambian
 Objetivo del caso de uso.
 Interacciones del sistema.

35. Casos de Uso
 Consideraciones:
 Que se repite mas?
 Cronología (Tiempo)
 Variantes en los flujos normales.
 Donde inician – Donde Terminan.
 Cuantos actores interactúan en el sistema?.

36. Casos de Uso
 Plantillas:
 Identificador: Identifica de forma única un caso de uso.
 Nombre: Describe las funcionalidades ofrecidas por el caso de uso.
 Precondición: Condiciones especiales que se deben presentar antes
de la ejecución del caso de uso.

37. Casos de Uso
 Plantillas
 Secuencia Normal o flujo principal: Descripción de las
acciones realizadas por el actor y su interacción con los
casos de uso.
 Se emplea lenguaje natural.
 Postcodicion: Estado del sistema después de ser ejecutado
el caso de uso.

38. Casos de Uso
 Plantilla:
 Excepciones o flujos alternos: Descripción detallada de
las acciones que no se contemplan en la ejecución común
de un caso de uso.
 Tiempo: EL tiempo que se espera se invierta ejecutando
las acciones.
 Frecuencia: Numero de veces que se espera se repita las
acciones del caso de uso.

39. Casos de Uso
 Plantilla:
 Importancia: Se especifica el grado de importancia que tiene el caso
de uso dentro del aplicativo.
 Es necesario definir escalas.
 Prioridad: Se especifica la prioridad que tiene el desarrollo del caso
de uso para el aplicativo.
 Es necesario definir escalas.
 Comentarios: Aclaraciones, notas adicionales.

40. Diagrama de
Clases
2

41. Diagrama de Clases
 Notación Gráfica para representar un conjunto de
objetos.
 Atributos.
 Acciones comunes.
 Rectángulo con secciones para:
 Nombre de la Clase
 Atributos
 Operaciones.

42. Diagrama de Clases
 La misma Filosofía que la programación orientada a
Objetos.
 Da una visión estática del sistema y las relaciones
incluidas en él (fotografía).
 También se pueden modelar los paquetes del sistema.
Paquete 

43. Diagrama de Clases
 Pueden existir varios DC.
 Especificando aspectos diferentes del mismo sistema.
 Detallando subsistemas.
 Incluyendo mayor numero de propiedades.
 Diagramando solo las relaciones entre paquetes.

44. Diagrama de Clases

45. Diagrama de Clases
 Clase:
 Es algo que encapsula información y
comportamiento.
 Enfoque tradicional:
 Información = Base de datos.
 Comportamiento= Aplicativo.
 Enfoque O.O:
 A little bit of information and a little bit
of behavior, and encapsulate them into
something called a class.

46. Diagrama de Clases
 Una clase puede ser:
 Una cosa: Un ítem tangible que existe dentro del mundo
real.
 Un evento: llamada telefónica, activación de un elemento,
etc.
 Un proceso: Colocar una orden, interacción con una base
de datos.

47. Diagrama de Clases
 Una clase y sus objetos:
 Simple / Complejo
 Real / Imaginario
 Atributos / Operaciones
 Las operaciones se realizan sobre el objeto mismo.
 Otro objeto invoca un evento externo a través de
mensajes.

48. Identificando los Objetos
 Examinando el flujo de eventos de los casos de uso.
 Identificar los sustantivos
 Los sustantivos se pueden convertir en 4 tipos de cosas:
 Actor : Maria
 Clase (Candidato a Objeto): Ingles
 Un atributo de una clase: 30 personas
 Una expresión no modelable: Sistema

49. Agrupando en clases
 John Doe and Jane Doe:
 Attributes:
 Employee’s name.
 Adress.
 Telephone number.
 Similar Operations.
 Se agrupan objetos comunes para crear la clase
Employee.
Tomado del libro: UML with Rational Rose

50. Consideraciones
 En ocasiones se prefiere crear primero el diagrama de
secuencia, actividades o colaboración.
 El diagrama de clases funciona como diccionario de
datos y relaciones.
 Agrupar las clases en paquetes y en capas de
arquitectura facilitan el trabajo y la expresividad del
modelo.

51. ¿Cuando Diseñar?
 Antes que otros diagramas:
 Permite diseñar las capas de arquitectura.
 Patrones de comunicación.
 Al llegar al diagrama de secuencia se
identifican los mensajes que violen la
arquitectura del diseño.
 Es posible rediseñar varias veces el
diagrama antes de realizar grandes
cambios.

52. ¿Cuando Diseñar?
 Después de otros diagramas:
 Se puede examinar que objetos son los necesarios.
 No se modelan objetos que no se emplearan.
 Se examina mejor las interacciones.
 No se limita los nuevos diseños al diccionario dado por el
diagrama de clases.

53. Relaciones
 Los diagramas de clases también son empleados para
representar las relaciones del sistema.
 Asociación
 Agregación
 Composición
 Generalización.

54. Asociación
 Utiliza un:
 Denota comunicación entre objetos.
 Se representa por una línea entre dos clases.
Departamento Profesor

55. Asociación - Multiplicidad
 Especifica el número de instancias de las clases involucradas
en la relación.
Facultad Profesor1 1..*
Asignatura
Pre-requisito
0..*
0..*

56. Agregación
 Se emplea para mostrar que una clase es parte de otra.
 Se emplea un diamante como símbolo.
 Una línea une las clases.
Currículo Diplomado1..*
“Es parte de”

57. Composición
 With composition, when the Whole is destroyed, so are all its
parts.
 La relación es mas fuerte.
 Se representa por un Diamante relleno.
Pensum Asignatura1..*
“Es parte de”
Tomado del Libro: UML for Mere Mortals

58. Ejemplo
CámaraSwitch
Bateria

59. No se permite
Clase I
Clase I Clase II
Clase I
Clase III Clase II
Tomado del Libro: UML for Java Programmers

60. Herencia
 Compartir Atributos y funcionalidades.
 Relación de “Es un”
 Las clases heredantes se denominan subclases.
 Las subclases pueden adicionar nuevos atributos y
operaciones.
 Generalización / Especialización
 Herencia Múltiple vs Interfaces.

61. Ejemplo
Weapon
-weight
-length
-range
+load()
+fire()
+setSafety()
+releaseSafety()
Rifle Blowgun
+load(cartridge,numberOfRounds) +load(dart,singleRound)

62. Diagrama de
Objetos
3

63. Diagrama de Objetos
 Instancia de un Diagrama de Clases.
 Presenta los detalles del sistema en un punto
determinado.
 Se presentan los objetos y sus relaciones durante el
tiempo de ejecución.
 Se emplea para validar el modelo de clases.

64. Ejemplo
Estudiante
-código=2003039
-nombre=Juan
Ingles: Asignatura
Software: Asignatura
QuimicaO: Asignatura
IdentidadU: Asignatura

65. Diagrama de
Estados
4

66. Introducción
 Todo cambia en el tiempo y los sistemas no son la
excepción.
 Los objetos pasan por varios estados.
 Se requiere de un modelo que permita ilustrar estos
estados y sus cambios en el tiempo.
 Sucesos + Tiempo.

67. Introducción
 Diagrama de estados o maquina de estados.
 Cada entidad es modelada como un objeto solitario que
percibe eventos y responde a ellos.
 Un evento son los cambios que un objeto puede
detectar.

68. Diagrama de Estados
 Cualquier cosa que afecte un objeto puede ser
considerado como un evento.
 Estado: Conjunto de valores de una clase en un
momento dado.
 En un estado especifico se ejecuta la misma función
cuando recibe el mismo evento.

69. Diagrama de estados
 En diferentes estados un mismo evento genera
comportamientos diferentes.
 Los diagramas de estados describen los
comportamientos dinámicos de los casos de uso.
“Dan mayor expresividad”

70. Diagrama de estados
 Maquina de estados:
 Grafo de estados y transiciones.
 Generalmente se construye sobre el diagrama de clases.
 Se ilustra la respuesta que las clases dan a los eventos.
 Los casos de uso pueden ser la base del modelado.

71. Maquina de estados
 Modelado de todo el ciclo de vida de un sistema dado,
desde una perspectiva de maquina.
 Las respuestas a los eventos pueden originar el cambio a
un nuevo estado.
 Vista separada, que permite observar el sistema como
una entidad solitaria

72. Eventos
 Se realizan en un tiempo y espacio.
 Cuando un evento ocurre se llama “instancia de
evento”.
 Los eventos pueden llevar parámetros.
 Se dividen en:
 Call events – change events
 Signal events – time events

73. Eventos
 Call event:
 Llamada a la ejecución de un evento.
 El emisor recupera el control cuando se ejecuta la acción.
 Change event:
 Satisface condición Booleana.
 Wait until.

74. Eventos
 Signal Event:
 Vehiculo de comunicación.
 Asíncrona.
 Time Event:
 Representa el paso del tiempo.
 Paso de señales-

75. Estado (state)
 Describe un periodo de tiempo de la vida de un objeto.
 Valores: Cualitativos
 Periodo de tiempo esperando evento.
 Periodo de tiempo efectuando acción.
 Generalmente llevan un nombre
 Los estados son conectados por transiciones.

76. Ejemplo - Estados
Confirmar Crédito
Inactivo Cancelar Orden

77. Transiciones
 Define la respuesta de un objeto en un estado a la
ocurrencia de un evento.
 Disparador
 Guard Condition.
 Acción.
 Estado objetivo.

78. Transiciones
 Tipos:
 Transición externa:
 Cambia el estado actual
 Se gráfica con una flecha desde el invocadora al destino.
 Es la más común.
 Lleva texto complementario.

79. Transiciones
 Transición Interna:
 Respuesta a un evento que causa una ejecución pero no
provoca un cambio de estado.
 No genera acciones de entrada ni salida.
 Acción de entrada (Entry action):
 Se ejecuta cuando se ingresa a un estado.
 Acción de Salida (Exit action):
 Se ejecuta cuando se abandona un estado.

80. Ejemplo – Transición

81. Representación
Nombre
Variables de Estado
Actividades
Nombre
Actividades
Nombre

82. Transiciones
 Evento disparador:
 Encargado de habilitar la transición.
 Puede llevar parámetros.
 MouseButton
 El evento Disparador = MouseButtonDown
 Se ejecuta en un tiempo dado.
 No es recordado.

83. Transiciones
 Guard Condition:
 Expresión Booleana.
 Puede hacer referencia a parámetros específicos del
trigger.
 Se evalúa cuando el evento disparador ocurre.

84. Ejemplo

85. Transiciones
 Acciones:
 Operación computacional asociado a un
evento disparador.
 Assignment: asignación
 Call: Llamada a un evento
 Create: Crear un objeto
 Destroy: Destruir un objeto
 Return: Especifica el valor a retornar.
 Send: Crea una instancia de señal.
 Terminate: Auto destrucción.

86. Estados Compuestos
Estado simple
Concurrente
Se activa un sub estado a
la vez.
Secuenciales
Sub estados que se activan
cuando el principal se
activa.
Inicio

87. Estados Compuestos
Estado Final
Agrupa diferentes
transiciones en una.
Estado de Unión
Estado de historia
Restaura el comportamiento
previo de un estado.
Estado de Sub maquina
Hace referencia a una
maquina externa.

88. Ejemplo

89. Ejemplo - Concurrente

90. Ejemplo- Secuenciales

91. Ejemplo Sub máquinas

92. Diagrama de
Secuencia
5

93. Introducción
 Los diagramas de estados llegan hasta un punto
determinado, los diagramas de secuencia dan el
siguiente paso.
 Presenta la interacción de los objetos en el tiempo.
 Los mensajes y quienes los envían y reciben son
capturados en este diagrama.

94. Diagrama de Secuencia
 La interacción entre objetos siempre se realiza en una
secuencia especifica.
 Un sistema debe ser analizado en base a esta secuencia.
 “Interacciones” son el centro del diagrama:
 Conjunto de comunicaciones entre objetos en un tiempo
dado.

95. Diagrama de Secuencia
 No se incluye las relaciones entre los objetos (Diagrama
de colaboración si lo hace).
 DC y DS presenta información similar pero desde puntos
de vista diferentes.
 Se generan diferentes diagramas para diferentes
escenarios.

96. Vista Dinámica
 El Diagrama de secuencia hace parte de
la denominada vista dinámica del
sistema.
 Diagrama de estados: statechart diagram.
 Diagrama de actividades: activity diagram.
 Diagrama de secuencia: sequence diagram.
 Diagrama de Colaboración: collaboration diagram.

97. Dimensiones
 Los DS posee dos dimensiones:
 Vertical:
 Representa la línea de tiempo en la cual se efectúan las
interacciones. El tiempo que tarda en realizarse una acción se
representa sobre ella.
 Horizontal:
 Representa los objetos que participan en las interacciones.
Cada objeto es mostrado en una columna independiente.

98. Notación
 Una línea punteada indica el tiempo de vida del objeto.
 Una X se sitúa en el punto donde el objeto deja de
existir.
 Cada mensaje es representado por una flecha
horizontal, que va desde el emisor al receptor, se
acompaña de una etiqueta indicando el evento a
invocar.

99. Notación
 Los mensajes llevan una secuencia numérica indicando
el orden de ejecución.
 El actor que interviene debe ser representado en el
modelo.
 Normalmente no se representan mensajes de retorno,
pero es permitido hacerlo.

100. Como elaborarlo?
 Seleccione un caso de uso
 Situé el actor en el diagrama.
 Identifique las clases de interfaz.
 Identifique las clases de control.
 Identifique las clases de entidad.

101. Clase Interfaz- Control -
Entidad
 Interfaz: Son las clases que interactúan
directamente con el actor.
 Control: Son aquellas clases que manejan la
lógica del negocio.
 Entidad: Clases que representan las tablas de
la base de datos.

102. Ejemplo

103. Ejemplo

104. Ejemplo

105. Diagrama de
Colaboración
6

106. Diagrama de Colaboración
 Presenta la colaboración entre los objetos.
 Relaciones entre objetos.
 Mensajes que se envían entre objetos.
 Cualquier diagrama de colaboración puede ser
convertido en un diagrama de secuencia.

107. Diagrama de Colaboración
 Notación:
 Objetos del sistemas:
 Mensaje y Relaciones:

108. Diagrama de Colaboración -
Ejemplo

109. Diagrama de Colaboración -
Ejemplo

110. Diagrama de
Actividades
7

111. Diagrama de Actividades
 Grafo de actividades:
 Actividad:
 Expresión de una acción computacional no atómica.
 Algoritmo expresado en un lenguaje de programación.
 Es ocasiones se expresa en lenguaje humano.
 Representa una operación del mundo real.

112. Diagrama de Actividades
 Similar al diagrama de estados:
 Estados ----- Actividades
 Representa un procedimiento o flujo de trabajo.
 Se enfatiza la secuencia.
 Se reflejan las concurrencias.
 Las decisiones son igualmente representadas.

113. Diagrama de Actividades
 Se modelan pasos en la ejecución de un procedimiento.
 Al finalizar la ejecución de una actividad se referencia a
la siguiente.
 Es útil para definir responsabilidades de los procesos.

114. Diagrama de Actividades
 Notación:
 Así como el diagrama de estados se inicia con una circulo
negro y se finaliza con el circulo negro rodeado por aro.
 Se emplea una flecha para representar el paso de una
acción a otra.

115. Diagrama de Actividades
 Una Actividad se representa por un rectángulo con las
esquinas redondeadas.
caminar

116. Diagramas de Actividades
 Notación: Decisiones

117. Diagrama de Actividades
 Notación: Concurrencia

118. Diagrama
de
Actividades

119. Diagrama de
Componentes
8

120. Introducción
 Los diagramas de componentes representan la
estructura física del código.
 Los componentes se pueden agrupar en paquetes y
entre estos podrían llegar a existir dependencias del
tipo:
 Generalización.
 Agregación.
 Asociación.
 Realización.
 Los componentes poseen interfaces que les permite
interactuar con el exterior.

121. Generación
 Los diagramas de componentes nacen a partir de los
diagramas de clases, que son empleados para
determinar aquellos elementos que prestaran una
funcionalidad al sistema.
 Es posible iniciar la implementación del sistema al
realizar el diagrama de componentes.

122. Pasos para generación
 Debe existir el diagrama de clases.
 Se debe identificar las clases y los métodos que serán
empleados para el diagrama.
 Las clases se agrupan en módulos y se transformaran en
componentes.
 Se identifican las interfaces que se emplearan por los
componentes para comunicarse entre ellos.

123. Ejemplo diagrama

124. Diagrama de
Distribución
9

125. Introducción
 Los diagramas de distribución permiten establecer como
estarán conectados las unidades entre si y como serán
ejecutados los programas.
 Los Nodos son la representación gráfica que caracteriza
los diagramas de distribución. Un Nodo es un elemento
físico que existe y representa un recurso
computacional.
 Normalmente la reunión de los Nodos terminan
representando la Topología asociada al Hardware que
será la solución del sistema.

126. Ejemplo

127. Consideraciones

128. Consideración
 No todos los diagramas son necesarios, pero se
recomienda la realización de los mismos para una mayor
comprensión del sistema que se esta desarrollando.
 Aunque hay críticas sobre la redundancia de la
información presentada en los diagramas , cada uno de
ellos permiten representar la información desde una
perspectiva única.
 Los diagramas representan aspectos estáticos y
dinámicos de un sistema y debe tener presente esto
para no quedarse con una vista parcial de la solución.

129. @josefabiandiaz
josefabiandiazs@Gmail.com
https://www.youtube.com/user/fabiandiazs
Msc.Ing.Jose Fabián Diaz Silva
Consultas