Your SlideShare is downloading. ×
0
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
1. uml
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

1. uml

386

Published on

Published in: Education
1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total Views
386
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
1
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. UML
  • 2. Modelos y Diagramas Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos ... Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos
  • 3. Modelos y Diagramas Modelo: captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Diagrama: representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos.
  • 4. Organización de Modelos Vista de Vista de Diseño Implementación Vista de los Casos de Uso Vista de Vista de Procesos Despliegue
  • 5. Diagramas de UML State State Use Case Diagrams de Diagramas Use Case Diagrams State Use Case Diagrams de Diagramas Clases State Use Case Diagrams Diagrams de Diagramas Diagrams de Diagramas Casos de Uso Diagrams Diagrams Objetos Secuencia Scenario State Scenario State Diagrams de Diagramas Diagrams de Diagramas Diagrams Diagrams Colaboración Modelo Componentes Scenario Component Scenario Component Diagramas de Diagrams Diagrams de Diagramas Diagrams Diagrams Distribución Estados Diagramas de Actividad
  • 6. Casos de Uso
  • 7. Casos de Usos Un Caso de Uso muestra la distintas operaciones que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuario u otras aplicaciones). Es una herramienta esencial para la captura de requerimientos y para la planificación y control de un proyecto interactivo.
  • 8. Casos de Usos Los Casos de Uso son qué hace el sistema desde el punto de vista del usuario. Describen un uso del sistema y cómo este interactúa con el usuario.  Escenario: Secuencia de pasos para describir una interacción entre un usuario y un sistema.  Casos de Uso: Conjunto de escenarios unidos por una meta del usuario en común.  Actor: Rol que juega el usuario con respecto a un sistema.  Un actor realiza varios casos de uso  Un caso de uso puede involucrar varios actores
  • 9. Casos de Usos Cada caso de uso es una operación completa desarrollada por los actores y por el sistema en un diálogo. El conjunto de casos de uso representa la totalidad de operaciones desarrolladas por el sistema.
  • 10. Template de Caso de Uso Nombre del CU: Actores: Descripción: Referencias a Funciones del Sistema: Pre-condición Post-condicion Curso Básico Cursos Alternativos Cursos de Excepción
  • 11. Cursos de un Casos de Uso Un caso de uso: •Tiene UN curso básico, que es la secuencia exitosa de eventos. •Puede tener variantes del curso básico que son cursos alternativos. •Puede tener varios cursos de excepción para el manejo de errores.
  • 12. Participantes de un Caso de Uso Actor: Es un usuario del sistema, que necesita o usa alguno de los casos de uso.  Un usuario puede jugar más de un rol.  Un solo actor puede actuar en muchos casos de uso; recíprocamente, un caso de uso puede tener varios actores.  Los actores no necesitan ser humanos pueden ser sistemas externos que necesitan alguna información del sistema actual.
  • 13. Relaciones en los Diagramas de Casos de Usos También se puede encontrar tres tipos de relaciones, como son:  Comunica (comunicates) Entre un actor y un caso de uso (u otro actor), denota la participación del actor en el caso de uso determinado.
  • 14. Relaciones en los Diagramas de Casos de Usos Usa o Incluye (uses/includes): Relación entre dos casos de uso, denota la inclusión del comportamiento de un escenario en otro.  Se utiliza cuando se repite un caso de uso en dos o más casos de uso separados.  Frecuentemente no hay actor asociado con el caso de uso común.
  • 15. Relaciones en los Diagramas de Casos de Usos Extiende (extends): Relación entre dos casos, denota cuando un caso de uso es una especialización de otro.  Se usa cuando se describe una variación sobre el normal comportamiento.  Agrega pasos a un caso de uso existente.
  • 16. Ejemplo de extends •Nombre: Facturar Pago  1. El caso de uso comienza cuando un cliente llega a la caja  .........  X. Si la fecha de pago excede la fecha actual (Factura Vencida)  ............................. Nombre: Facturar Vencimiento de Pago  1. Se calcula el interés correspondiente al monto.....
  • 17. Otro tipo de relación Generalización: Denota una relación de Herencia. Un caso de uso hereda comportamiento de otro.
  • 18. Diagrama de Caso de Uso Ej: Maquina expendedora Buy a product Self Service Machine <<includes>> customer Open Machine Restock <<extends>>(generalized actor) <<includes>> Close Machine Restock according to salesSupplier Agent <<includes>> Open Machine Collect Restocker Collector <<includes>> Close Machine
  • 19. Diagrama de Caso de UsoEjemplo: Registro Web
  • 20. Caso de uso en forma de dialogoEjemplo: Comprar productos Curso Básico ACTOR SISTEMA 1. Selecciona de la lista de productos los que va a comprar 2. Valida que haya stock 3. Ingresa la información de envío 4. Muestra costos de compra y de envío 5. Ingresa la información de tarjeta de crédito 6. Confirma la compra 7. Autoriza la compra 8. Registra la compra e imprime factura
  • 21. Caso de uso en forma de dialogoEjemplo: Comprar productos Curso Alternativo 2 .1 No hay stock disponible de algún producto. Envía mensaje al operador, que puede confirmar la operación sin incluir el producto o cancelar toda la operación. 7.1No se autoriza la compra. El sistema envía un mensaje al usuario, que puede reingresar los datos con la misma tarjeta o con otra, o cancelar la operación.
  • 22. Caso de uso en forma de dialogoEjemplo: Comprar productos Cursos de excepción - Se cortó la comunicación con el servidor. No se lleva a cabo la transacción.
  • 23. Casos de Usos Técnicas comunes de modelado:  Modelado del contexto del sistema.  Modelado de los requisitos de un sistema.  Modelado del proceso de test y estrés del sistema.
  • 24. Diagramas de Interacción
  • 25. IntroducciónLos diagramas UML de secuencia y de colaboración(llamados diagramas de interacción o comportamiento) seutilizan para modelar los aspectos dinámicos de un sistema.Un diagrama de interacción consiste en un conjunto deobjetos y sus relaciones, incluyendo los mensajes que sepueden enviar entre ellos.Los diagramas de secuencia destacan el orden temporal delos mensajes. Los diagramas de colaboración destacan laorganización estructural de los objetos que envían y recibenmensajes.
  • 26. Ejemplos Diagrama de secuencia: destaca el orden temporal objetoA:A objetoB:B objetoC:C de los mensajes. <<create>> mensaje1( ) objetos mensaje2( ) tiempo mensaje3( ) objetoA:A <<destroy>> 1: <<create>> 2: mensaje1( ) 3: <<destroy>> objetoB:B objetoC:C Diagrama de colaboración: 2.1: mensaje2( ) destaca la relación estructural 2.2: mensaje3( ) entre los objetos que interactúan
  • 27. ConceptosAmbos diagramas (secuencia y colaboración) son semántica-mente equivalentes.Se puede pasar de uno a otro sin pérdida de información.
  • 28. Diagramas de Interacción Los diagramas de Interacción explican gráficamente cómo los objetos interactúan a través de mensajes para realizar las tareas. Los diagramas de interacción se realizan en la etapa de diseño de un ciclo de desarrollo.
  • 29. Para desarrollar un diagrama deinteracción se requiere: Diagrama de Clases: A partir de este modelo el diseñador podrá definir las clases de software correspondientes.  Los objetos de las clases participan en las interacciones que se describen gráficamente en los diagramas. Casos de Uso: A partir de ellos el diseñador recaba información sobre las tareas que realizan los diagramas de interacción.
  • 30. Diagramas de Interacción En los diagramas de Interacción es importante considerar cuidadosamente la asignación de responsabilidades y las habilidades que todo el sistema requiere. En un proyecto de sistemas un porcentaje considerable de tiempo debe destinarse a esta fase. Los diagramas de interacción constituyen uno de los artefactos más importantes que se generan en el análisis y en el diseño orientados a objetos.
  • 31. Consideraciones en los Diagramas de Interacción Se deberá elaborar un diagrama por cada operación que realice el sistema. Si el diagrama se torna muy complejo (Si no cabe en una página de papel) es mejor dividirlo en diagramas más pequeños. Diseñe un sistema de objetos interactivos que realicen las tareas definidas usando como base los escenarios de los casos de uso y las post-condiciones de los mismos.
  • 32. Diagramas de interacción Elementos básicos de los diagramas de interacción:  Objetos o actores para cada entidad.  Enlaces entre los objetos.  Procedimientos a invocar entre los objetos.  Mensajes entre los objetos.
  • 33. Notación de las Clases y de las Instanciasen los Diagramas de Interacción Oferta Clase :Oferta Instancia Instancia x1:Oferta con Nombre
  • 34. Tipos de mensajes: Sintaxis Nombre Semántica Mensaje síncrono. El emisor espera hasta que el receptor unMensaje (unParámetro) regresa de ejecutar el mensaje. Mensaje El emisor envía el mensaje y continúa asíncrono. ejecutando; no espera una respuesta unMensaje (unParámetro) del receptor. Retorno de El receptor de un mensaje anterior mensaje. devuelve el foco del control al emisor de ese mensaje. Creación de objeto El emisor crea una instancia de la <<create>> (Crea el objeto A) clase especificada por el receptor. unMensaje() :A :A Destrucción de El emisor destruye el receptor. Si la <<destroy>> objeto línea de vida tiene una línea vertical (Destruye el discontinua, se termina con un X. objeto A)
  • 35. Objetos de Control (Controller Objects) En la mayoría de escenarios los diagramas de casos de uso se inicia con un actor inicial (el cual genera un evento sobre el sistema). Los actores fuera del sistema necesitan además comunicarse con otros objetos dentro del sistema.  Es necesario escoger un objeto particular dentro del sistema que sea el punto de contacto o la interfaz del sistema.  Para estos casos un Objeto de Control es usualmente creado para coordinar la interacción entre el actor con el resto del sistema. Este se encarga de distribuir los mensajes entre los objetos. (debido a que un objeto para enviar un mensaje a otro objeto debe conocerlo).
  • 36. Objetos de Control Ejemplo: Cajero automático Un cliente (Actor) no puede comunicarse directamente con su objeto cuenta. Debido a que existen millones de cuentas en el banco a las que el cliente no debe tener acceso. El cliente debe proporcionar una tarjeta electrónica junto con un código de seguridad para que el sistema pueda identificar sus cuenta. En este caso es útil definir un nuevo objeto llamado Cajero Automático que corresponde con el cajero físico que pueda ser única e inmediatamente identificado por el actor, el mismo que se encarga de distribuir los mensajes entre los demás objetos del sistema.
  • 37. Diagramas de Secuencia Notación Los objetos son mostrados como cajas en la parte superior del diagrama. El flujo del tiempo se muestra de arriba abajo.  La linea de vida de un objeto es la línea discontinua vertical, que representa la existencia de un objeto a lo largo de un periodo de tiempo. Las áreas gruesas (“Fat Areas”) indican cuales objetos tiene el control.  El foco de control es un rectángulo delgado que representa el periodo de tiempo durante el cual un objeto ejecuta una acción.
  • 38. Diagramas de Secuencia Notación El actor puede representarse como un estereotipo dentro del diagrama de secuencias (esta representación es distinta al objeto que contiene la información del actor): <<Actor>> También se puede representar con: Cada objeto requiere una línea vertical (línea de tiempo o lifeline) donde representar los mensajes que recibe y las acciones que ejecuta.
  • 39. Diagramas de Secuencia Eventos: son la comunicación entre los objetos o a través de la frontera del sistema.  Los eventos se expresan a través de flechas (con el nombre del mensaje invocado) entre las líneas de tiempo del objeto que lo envía y del objeto que lo recibe.  El orden en que ocurren los eventos son mostrados de arriba hacia abajo.  Cada mensaje puede incluir los argumentos y los tipos de retorno similar al diagrama de colaboración.  Es posible representar invocaciones a eventos del mismo objeto.  El valor de retorno es opcionalmente mostrado al terminar la Fat Area.
  • 40. Diagramas de Secuencia Regiones de Control (Fat Areas): Muestran el periodo de tiempo cuando un objeto tiene el control del proceso.  Concepto similar a las llamadas anidadas de procedimientos.  Una Fat Area es mostrada como un rectángulo en la línea de tiempo de un objeto. Ello indica que el objeto está actualmente activo dentro del sistema.  El control de las regiones anidadas puede ser mostrado (cuando un objeto le envía un mensaje a si mismo) sobreponiendo dos Fat Areas (una encima de otra).
  • 41. Diagramas de SecuenciaEjemplos de Diagrama de Secuencias: <<Actor>> :InstanciaClaseA :InstanciaClaseB mensajeA() mensajeB() tiempo Actor Fat Area retorno retorno :InstanciaClaseA :InstanciaClaseB mensajeA() mensajeB() mensC() tiempo retorno Región Anidada
  • 42. Diagramas de Secuencia Mensajes Condicionales:  Similar a los diagramas de colaboración existen los mensajes condicionales que indica que un mensaje sólo puede ser enviado cuando una condición es verdadera.  Los mensajes condicionales son útiles en casos simples pero para casos más complejos es recomendable realizar dos o más diagramas.  Las condiciones se encierran en corchetes ( “[ ]” ) similar a los diagramas de colaboración. :InstanciaClaseA :InstanciaClaseB mensajeA() [condición]mensajeB() retorno
  • 43. Diagramas de Secuencia Iteraciones:  En los diagramas de secuencia es posible mostrar las iteraciones de un proceso.  Permite mostrar que un mensaje es enviado varias veces a varios objetos receptores.  Similar a los diagramas de colaboración se utiliza el asterisco (“*”) como símbolo para indicar una iteración. :InstanciaClaseA :InstanciaClaseB mensajeA() *[condición]mensajeB() retorno Indica que se encuentra en una iteración hasta que se cumpla la condición
  • 44. Diagramas de Secuencia El Retorno:  El retorno indica el regreso del control del flujo del proceso del objeto receptor del mensaje previo al objeto que envío tal mensaje.  El retorno no es un nuevo mensaje.  Algunos autores los muestran con líneas punteadas para diferenciarlos de los mensajes normales.  Es opcional colocar el Retorno. Principalmente cuando este clarifica el diagrama y no lo hace más complejo.
  • 45. Diagramas de Secuencia Creación y Destrucción Instancias.  Es posible indicar la creación y destrucción de instancias.  La creación de una nueva instancia se coloca esta a la altura del mensaje de creación que esta recibió de otro objeto.  Para indicar la destrucción de una instancia se coloca sobre la línea de tiempo del mismo una equis (“X”) :InstanciaClaseA :InstanciaClaseB Creación de Instancia mensajeA() mensajeB() mensajeC() :InstanciaClaseC retorno retorno Destrucción X de Instancia
  • 46. Diagramas de Secuencia Comentarios en los diagramas de secuencia:  Se puede insertar descripciones textuales de que esta ocurriendo en el diagrama con el fin de hacerlo más legible.  Estos comentarios son insertados del lado izquierdo del diagrama a la altura del conjunto de mensajes que se desea comentar. :InstanciaClaseA :InstanciaClaseB Inicio del mensajeA() proceso. mensajeB() Creación de la mensajeC() nueva instancia de :InstanciaClaseC la clase C. retorno Destrucción de la retorno instancia de la X Clase C
  • 47. EjemploModelar una llamada a través de una central telefónica.Para esto se tienen cuatro objetos involucrados: • dos interlocutores (s y r) • una central • una conversación.La secuencia empieza cuando un interlocutor envía unmensaje a la central al descolgar el auricular.La central da el tono de llamada, y el interlocutor marca elnúmero al que desea llamar.El tiempo de marcado debe ser menor que 30 segundos.
  • 48. Ejemplo s:Interlocutor :Central r:Interlocutor descolgarAuricular( ) darTonoDeLlamada( ) *marcarDigito( ) [marcando.tiempoEjecucion < 30 segs] enrutarLlamadas(s,n) marcando <<create>> c:Conversación llamar( ) descolgarAuricular( ) conectar(r,s) conectar(r) conectar(s) Los interlocutopres r y s pueden intercambiar información después de conectarse.
  • 49. Diagramas de colaboraciónNotación Los diagramas de colaboración explican gráficamente las interacciones entre las instancias del modelo (objetos). Por ejemplo:
  • 50. Diagramas de colaboraciónNotación Un objeto se puede enviar un mensaje a sí mismo: Es posible representar iteraciones: msg1() { for i := 1 to 10 { miB.mens2(); miC.mens3(); } }
  • 51. Diagramas de colaboraciónNotaciónSecuencia de los mensajes en un diagrama de colaboración:
  • 52. Diagramas de colaboraciónNotaciónEs posible definir mensajes condicionales:
  • 53. Diagramas de colaboraciónNotaciónEs posible definir trayectorias mutuamente excluyentes:
  • 54. Diagramas de colaboraciónNotaciónUn multiobjeto, por ejemplo un arreglo, se representa comouna pila de objetos:Se pueden enviar mensajes a multiobjetos:
  • 55. Diagramas de colaboraciónNotaciónEjemplo de crear un objeto y agregarlo a un multiobjeto:
  • 56. EjemploMatricular un nuevo estudiante en la universidad Hay cuatro objetos involucrados: • un encargado de matrícula • un estudiante • un curso • la universidad La acción comienza cuando el encargado de matrícula crea un objeto estudiante, lo añade a la universidad, y le pide al objeto estudiante que se matricule. El objeto estudiante obtiene (de sí mismo) su plan de estudio, e identifica los cursos que quiere matricular.
  • 57. Ejemplo 2: agregarEstudiante(s) r:EncargadoMatricula :Universidad 1: <<create>> 3.1: obtenerPlanEstudios( ) 3: matricular( ) s:Estudiante s:Estudiante matriculado = False matriculado = True 3.4: <<become>> 3.2: agregar(s) 3.3: agregar(s) c1:Curso c2:Curso {asociación} {asociación}
  • 58. COMPARACIÓN ENTRE DIAGRAMA DESECUENCIA Y DE COLABORACIÓN Tipo Puntos fuertes Puntos débilesSecuencia Muestra claramente la Fuerza a extender por secuencia u ordenación en el la derecha cuando se tiempo de los mensajes. añaden nuevos objetos; Notación simple. consume espacio horizontal.Colaboración Economiza espacio, Difícil ver la secuencia(Comunicación) flexibilidad al añadir nuevos de mensajes. objetos porque crece en dos Notación más compleja dimensiones. Es mejor para ilustrar bifurcaciones complejas, iteraciones y comportamiento concurrente.
  • 59. MODELO DE IMPLEMENTACIÓN
  • 60. Diagrama de Componentes
  • 61. Diagrama de componentes Los diagramas de componentes describen los elementos físicos reemplazables del sistema y sus relaciones Muestran las opciones de realización incluyendo código fuente, binario y ejecutable
  • 62. En UML se representa: Un componente posee características similares a una clase: tiene nombre, realiza interfaces, puede participar de relaciones, puede tener instancias, puede participar en interacciones. Porqué se diferencian?  Un componente representa un elemento físico (bits).  Una clase es una abstracción lógica.  El componente se puede representar en nodos físicos, la clase no.  Las operaciones de un componente solo se alcanzan a través de interfaces. Las de una clase podrían ser accesibles directamente.
  • 63. Diagrama de componentes Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. Pueden ser simples archivos, librerías, bibliotecas cargadas dinámicamente, etc. Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente
  • 64. Componentes e interfaces Una interfaz contiene una colección de operaciones y se utiliza para especificar los servicios de una clase o de un componente. Una interfaz se conecta al componente que la implementa a través de una relación de realización, y al componente que utiliza sus servicios con una dependencia.
  • 65. Gráficamente
  • 66. Tipos de componentes Componentes de despliegue: necesarios y suficientes para formar un sistema ejecutable. Por ejemplo: bibliotecas dinámicas (dll), ejecutables (exe). Componentes productos de trabajo: surgen durante el proceso de desarrollo y quedan al final del mismo. Por ejemplo: una base de datos. Componentes de ejecución: se crean como consecuencia de un sistema en ejecución. Por ejemplo: objetos que se instancian a partir de una dll.
  • 67. Estereotipos estandar de componentes executable: especifica un componente ejecutable en un nodo. library: especifica una biblioteca de objetos. table: especifica una tabla de una BD. file: especifica un componente que contiene un documento con código fuente o datos. document: especifica un componente que representa un documento.
  • 68. Diagrama de componentes Modela los aspectos físicos de un sistema. Modela la vista de implementación estática de un sistema. Modela los elementos físicos que residen en un nodo, tales como ejecutables, tablas, librerías, archivos y documentos. Un Diagrama de Componentes muestra un conjunto de componentes y sus relaciones.  Los elementos que lo componen son:  Componentes  Interfaces  Relaciones de dependencia, generalización, asociación, realización.
  • 69. Diagrama de componentes
  • 70. Diagrama de componentes  Técnicas de modelado:  Modelado de ejecutables y bibliotecas.  Modelado de tablas, archivos y documentos.  Modelado y diseño de un API.  Modelado del código fuente.  Planificación de versiones ejecutables para su implementación con Nant.
  • 71. Diagrama de Deployment
  • 72. Diagrama dedeployment/distribucion Los diagramas de despliegue muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos
  • 73. Nodo Es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional, que generalmente tiene alguna memoria y capacidad de procesamiento. Posee un nombre simple.  Ejemplo: Ventas o un nombre extendido indicando el paquete que lo contiene;  Ej: servidor::Ventas.
  • 74. Nodo En los Nodos se ejecutan los Componentes. La relación entre un nodo y un componente se puede modelar con una relación de dependencia. Los nodos se pueden organizar agrupándolos en paquetes. También a través de relaciones de dependencia, generalización, asociación, agregación. Generalmente se conectan con una asociación.
  • 75. Diagrama de despliegue La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instancias de nodos conectados por enlaces de comunicación. Un nodo es un recurso de ejecución tal como  Dispositivos  Procesadores  Memoria Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse. Esta vista permite determinar las consecuencias de la distribución y la asignación de recursos.
  • 76. Diagrama de desplieguePrimer Ejemplo
  • 77. Diagrama de despliegueSegundo Ejemplo
  • 78. Tercer Ejemplo Modela aspectos físicos de un sistema. Modela la vista de despliegue estática de un sistema. Modela una configuración de nodos y los componentes que residen en ellos. Modela la topología del hardware donde se ejecuta el sistema. Los elementos que lo componen son:  Nodos  Relaciones de dependencia, generalización, asociación y realización.  Pueden contener los componentes que residen en los nodos.
  • 79. Cuarto Ejemplo
  • 80. Otro ejemplo
  • 81. Diagrama de despliegue Técnicas de modelado:  Modelado de procesadores y dispositivos.  Modelado de distribución de componentes.

×