Diagramas UML

Diagramas UML
René Guamán-Quinche
Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables
Carrera de Ingeniería en Sistemas/Computación
Mayo, 2020
Loja, Ecuador

3
1. Diagramas Estructurales

Diagrama de Casos de Uso

Diagrama de Clases

Diagrama de Objetos
2. Diagramas de Comportamiento

Diagrama de Estado

Diagrama de Actividad
3. Diagramas de Interacción

Diagrama de Secuencia

Diagrama de Colaboración
4. Diagramas de Implementación

Diagrama de componente

Diagrama de Despliegue / Distribuición
Agenda

4
Casos de Uso
• ¿Qué es?
Los Casos de Uso describen bajo la forma de acciones y reacciones el
comportamiento de un sistema desde el punto de vista del usuario
• ¿Para qué se utiliza?
Los Casos de Uso son descripciones de la funcionalidad del sistema
independientes de la implementación
• ¿Para quién está orientado?
Están basado en el lenguaje natural, es decir, son accesibles por los usuarios

6
Casos de Uso
 Un Caso de Uso es el único elemento de UML que describe el sistema
desde el punto de vista del usuario
 Entender el punto de vista del usuario es fundamental para crear sistemas:

Que cumplan con los requerimientos de quién lo va a utilizar

Sea sencillo de trabajar con ellos
 Los casos de uso son fundamentales en la fase de análisis de un sistema.
La forma en que los usuarios utilizan un sistema es lo que se debe diseñar e
implementar

7
Casos de Uso
 Es una herramienta que permite que los usuarios potenciales hablen de un
sistema desde su propio punto de vista
 Implica involucrar a los usuarios en las etapas iniciales de análisis y
diseño del sistema
 Desde ese punto de vista, definimos un Caso de Uso como un conjunto de
situaciones respecto a la utilización del sistema

8
Casos de Uso
 Genera un sistema mas útil. Evita que sea un conjunto de funcionalidades
incomprensibles y manejables por los usuarios finales
 Dada su flexibilidad, ayudan en diferentes fases del proceso de desarrollo:

Captación de nuevos requisitos

Corrección de errores
 Permiten el diseño de una interfaz adaptada a los gustos de los usuarios
usuario
 Generan una base de pruebas del sistema con respecto a su usabilidad

9
Casos de Uso
 Descripción gráfica de los diferentes Casos de Uso del sistema, así como
las relaciones entre los mismos
 Proporciona una visión general y simple de los Casos de Uso, por lo que
tienen menor detalle
 De cara al punto de vista de un usuario, permite:

Ver el funcionamiento del sistema a través de sus Casos de Uso

Ante posibles actualizaciones, el diagrama de Casos de Uso puede servir
como base para la captación de nuevos requisitos

11
Casos de Uso
 Actor. Representa el rol de un usuario del sistema.
Todo aquel elemento que interactúa con el sistema
 Tipos de actores:

Principales: personas que usan el sistema

Secundarios: personas que mantienen o administran
el sistema

Material externo: dispositivos materiales
imprescindibles que forman parte del ámbito de la
aplicación y deben ser utilizados

Otros sistemas: otros entornos con los que el sistema
interactúa

12
Casos de Uso
 Todo actor puede:

Iniciar una secuencia de Casos de Uso. Parte izquierda del diagrama

Ser objeto de una secuencia de Casos de Uso. Parte derecha del diagrama
 Puede iniciar o ser objeto de varios casos de uso
 Un actor es un elemento externo al sistema, mientras que los Casos de Uso
son parte del mismo

13
Casos de Uso
 Caso de Uso. Indica un proceso dentro del propio sistema
 En el diagrama de Casos de Uso solo se indica el nombre del Caso de Uso,
así como sus relaciones con otros Casos de Uso o actores
 Una descripción más detallada se realiza en un documento aparte

14
Casos de Uso
 Relación. Cualquier tipo de unión entre elementos del diagrama. Actor-
Caso o Caso-Caso
 Permite conocer las dependencias de los distintos elementos del diagrama,
formando secuencias de Casos de Uso que representan procesos completos

15
Casos de Uso
 Comunicación. Relación que indica que un Actor o Caso de Uso origen
utiliza un Caso de Uso destino
 Forma secuencias de Casos de Uso. Es el tipo de relación más utilizada

16
Casos de Uso
 Inclusión. Utilizado cuando una instancia del Caso de Uso origen incluye
también el comportamiento descrito por el Caso de Uso destino
 Utilizado para Casos de Uso más complejos, que requieren la utilización de
otros Casos de Uso.
 No puede utilizarse en la relación Actor-Caso de Uso

18
Casos de Uso
 Extensión. El Caso de Uso origen extiende el comportamiento del Caso de
Uso destino
 Es posible volver a utilizar un caso de uso agregándole algunos pasos a
un caso de uso existente
 Tanto la inclusión como la extensión se hace en puntos indicados y de
manera específica dentro de una secuencia de casos de uso. No se permite
en la relación Actor-Caso de Uso

19
Casos de Uso
 Herencia. El Caso de Uso origen hereda la especificación del Caso de Uso
destino y posiblemente la modifica y/o amplía
 Similar al concepto de herencia utilizado en programación

20
Casos de Uso
 Subsistema. Se pueden
agrupar varios Casos
de Uso en subsistemas
 Representan diferentes
sistemas semi-
independientes en un
ámbito funcional
dentro del sistema
general

21
Casos de Uso
1.Obtener los Casos de Uso del sistema

Un Caso de Uso debe ser una funcionalidad sencilla, a la vez que su
cometido debe ser claro y conciso
2.Pensar en los actores que realizarán estos Casos de Uso

Generalmente hay pocos actores asociados a cada Caso de Uso
3.Establecer las relaciones entre Casos de Uso o entre actores y Casos de
Uso
4.Agrupar los Casos de Uso en subsistemas en caso de ser necesario

22
Casos de Uso
 Dado un sistema online de pedidos a restaurantes, se pide realizar el
diagrama de casos de uso del mismo que refleje el siguiente
comportamiento:

El cliente puede buscar una determinada comida

El cliente puede solicitar un encargo al restaurante de su elección

Para poder utilizar el servicio se necesita una cuenta de usuario, por lo
que la operación de encargar comida debe ser validada previamente

Los restaurantes pueden visualizar los pedidos que tienen pendientes
para poder atenderlos

24
Casos de Uso
 Se debe diseñar un sistema de compra de videojuegos, en el cual a los
usuarios se les permite realizar las siguientes acciones:
 Buscar videojuegos. La búsqueda cambia dependiendo de la categoría del
videojuego, que son:

Acción

Deportes

Terror
 Comprar un videojuego concreto
 Todas las operaciones anteriores contrastan con base de datos
 La compra de un videojuego realiza un proceso de validación

26
Casos de Uso
 La descripción del Caso de Uso comprende:

Objetivo del caso de uso

Actores y acciones

El inicio: cuándo y qué actor lo produce

El fin: cuándo se produce y qué valor devuelve

Definir la interacción actor-caso de uso (paso de mensajes)

Cronología y origen de las interacciones

Repeticiones de comportamiento (bucles o iteraciones)

Situaciones opcionales o alternativas

28
Diagrama de Clases
 Describe la definición de cada uno de los posibles objetos pertenecientes al
sistema
 Muestra las clases del sistema, sus atributos, operaciones (o métodos), y las
relaciones entre los objetos
 Diagrama cercano a la implementación. Construido y refinado a través
del desarrollo
 Desarrollado por analistas, diseñadores y desarrolladores
 Utilidad

Organizar el sistema, describiendo sus diferentes entidades, así como sus
características y relaciones entre ellas

Ayuda en la implementación del sistema

Permite ver los esquemas lógicos de las estructuras de datos

29
Diagrama de Clases
 Cada clase se representa por un rectángulo con tres compartimentos

Nombre de la clase

Atributos de la clase

Operaciones de la clase

30
Diagrama de Clases
 PREGUNTA: ¿Qué es la encapsulación?

Ocultamiento de los datos de un objeto de tal forma que solo sean
accesibles mediante operaciones definidas por el propio objeto
 La encapsulación presenta una serie de ventajas

Se protegen los datos privados del objeto de lecturas y escrituras no
permitidas

Permite una mejor estructuración y manipulación de los datos
 Los atributos de un objeto no deberían ser manipulables directamente por
el resto de los objetos. En caso de querer hacerlos manipulables, se debe
implementar los procedimientos Set y Get

31
Diagrama de Clases
 Encapsulación
 En UML, los niveles de encapsulación vienen heredados de C++

- Privado: Atributo o proceso totalmente invisible

# Protegido: Visibles para las clases amigas (friends) o para clases
derivadas de la original

+ Públicos: Visibles a otras clases

32
Diagrama de Clases
 La asociación expresa una conexión entre elementos, esto es, que existe
algún tipo de relación entre ambos
 Se representa mediante una línea que une ambas clases. Se puede indicar el
tipo de asociación y el sentido de la misma
 Se indica la multiplicidad de cada clase, que representa con cuantos objetos
de la clase unida por la asociación se puede relacionar un objeto
determinado

1

0..1

M..N

*

0..*

1..*
 La multiplicidad >= 1 establece una restricción de existencia

33
Diagrama de Clases
 Asociación con restricciones. Indica que sólo se realiza la asociación si se
cumple una determinada condición
 Asociación excluyente. Indica que 2 posibles asociaciones no se pueden
realizar a la vez

34
Diagrama de Clases
 Agregación
 Una clase puede ser puede estar relacionada por un conjunto de clases que
la representen y, sin las cuales, no tenga sentido.
 A esta relación se le llama Agregación o Composición débil, y se
representa mediante un rombo blanco

35
Diagrama de Clases
 Agregación - ejemplo
 Un ordenador posee, como mínimo, los siguientes elementos:

1 Torre

1 Teclado

1 Monitor

1 Ratón
 Una torre se compone por:

1 o varias unidades de disco duro

Varios módulos de memoria RAM

1 unidad óptica

1 tarjeta gráfica

36
Diagrama de Clases
 Agregación - ejemplo


37
Diagrama de Clases
 Composición
 La Composición o Composición fuerte es una relación entre clases similar
a la agregación, pero en la que las clases que componen a la principal no
tienen sentido sin dicha clase principal
 Se representa mediante un rectángulo de color negro

38
Diagrama de Clases
 Generalización
 Consiste en factorizar las propiedades comunes de un conjunto de clases en
una clase más general. Herencia
 Las subclases heredan propiedades de sus clases padre, esto es, los
atributos, operaciones y asociaciones de la clase padre están disponible en
sus clases hijas
 Existen 2 conceptos complementarios: Generalización y Especialización
 En la fase de análisis nos movemos desde la generalización hacia la
especialización

39
Diagrama de Clases
 Generalización
 La generalización se expresa mediante una flecha hueca

40
Diagrama de Clases
 Generalización
 Representar mediante un diagrama de clases la clasificación de los seres
vivos:

Los animales se deben organizar por su alimentación, esto es: Carnívoros,
Herbívoros y Omnívoros

Las plantas se deben clasificar por su tipo: Árboles, Arbustos y Hierbas

Para los animales, se ponen 3 ejemplos: Conejo, León y Vaca

41
Diagrama de Clases
 Generalización

42
Diagrama de Clases
 Generalización y conjuntos
 Se puede equiparar el concepto de clase al de conjunto, de forma que
ambos sirven para clasificar distintos elementos
 Generalización y especialización expresan relaciones entre conjuntos

43
Diagrama de Clases
 Herencia múltiple
 Se produce cuando una subclase tiene más de una superclase
 No se suele recomendar, ya que puede dar conflictos de nombre y
procedencia
 Algunos lenguajes de programación como Java o Ada95 no permiten
herencia múltiple

44
Diagrama de Clases
 Principio de Sustitución
 El principio de sustitución (Liskow 1987) dice:
 Debe ser posible utilizar cualquier objeto instancia de una subclase en el
lugar de cualquier objeto instancia de su superclase sin que la semántica
del programa escrito en los términos de la superclase se vea afectado.
 Este principio debe seguirse siempre que se utilice el Polimorfismo

45
Diagrama de Clases
 Polimorfimo
 El término polimorfismo se encuentra ligado al concepto de herencia e
indica que una característica de una clase padre puede tomar diferentes
formas dependiendo de la clase hija que la ejecute
 Permite que, ante un mismo estímulo, se desencadene una respuesta
distinta dependiendo de la clase que la ejecute
 Este concepto permite dotar de flexibilidad al conjunto de clases
implementado, siendo uno de los mecanismos mas potentes que posee el
uso de herencia

46
Diagrama de Clases
 Qué comen los animales?

47
Diagrama de Clases
 El dueño de un hotel te pide a desarrollar un programa para consultar sobre las habitaciones disponibles y reservar
habitaciones de su hotel
 El hotel posee tres tipos de habitaciones: simple, doble y matrimonial, y dos tipos de clientes: habituales y esporádicos.
Una reserva almacena datos del cliente, de la habitación reservada, la fecha de comienzo y el número de días que será
ocupada la habitación
 El recepcionista del hotel debe poder hacer la siguientes operaciones:

Obtener un listado de las habitaciones disponible de acuerdo a su tipo

Preguntar por el precio de una habitación de acuerdo a su tipo

Preguntar por el descuento ofrecido a los clientes habituales

Preguntar por el precio total para un cliente dado, especificando su numero de DNI, tipo de habitación y número de
noches.

Dibujar en pantalla la foto de un habitación de acuerdo a su tipo

Reservar una habitación especificando el número de la habitación, DNI y nombre del cliente.

Eliminar una reserva especificando el número de la habitación
 El administrador puede usar el programa para:

Cambiar el precio de una habitación de acuerdo a su tipo

Cambiar el valor del descuento ofrecido a los clientes habituales

Calcular las ganancias que tendrán en un mes especificado (considere que todoslos meses tienen treinta días).
 El hotel posee información sobre que clientes son habituales. El diseño a desarrollar debe facilitar la extensibilidad de
nuevos tipos de habitación o clientes y a su vez permitir agregar nuevas consultas

49
Diagrama de Objetos
 Muestra una vista completa o parcial de los objetos de un sistema en un
instante de ejecución determinado
 Comparte la misma notación que los diagramas de clases. El nombre del
objeto se representa subrayado, a diferencia del nombre de las clases
 Utilidad.

Ilustrar las estructuras de datos/objetos del sistema

Especificar detalles del modelo

Obtener una “foto” del sistema en un determinado punto

50
Diagrama de Objetos
 Ejemplo

51
Diagramas de Comportamiento
 Tipo de diagramas que persiguen mostrar el comportamiento dinámico de
un sistema
 Reflejan como determinadas actividades del sistema cambian a lo largo del
tiempo
 Utilidad

Entender el comportamiento que deben tener determinados procesos

Mostrar el funcionamiento global del sistema a través de los diferentes
procesos que ejecuta

52
Diagramas de Estado
 Diagrama de comportamiento desde el punto de vista de los objetos del
sistema
 Muestra los estados por los que puede pasar uno o varios objetos durante la
ejecución de determinados procesos
 Utilidad. Reflejar el comportamiento de los objetos del sistema a través de
su ciclo de vida

53
Diagramas de Estado
 Un Diagrama de Estados muestra una Máquina de Estados con el
comportamiento del objeto
 Máquina de Estados: Una máquina de estados especifica las secuencias de
estados por las que pasa un objeto a lo largo de su vida en respuesta a
eventos, junto con sus respuestas a esos eventos (Booch, Rumbaugh,
Jacobson)
 Un diagrama de estados muestra los diferentes estados de un objeto, así
como se transita entre ellos en respuesta a determinados eventos, tanto
internos como externos

54
Diagramas de Estado
 Estado: Condición del objeto en un determinado instante de tiempo. Se
asume que el objeto se encuentra realizando una actividad o a la espera de
un evento que le permita el cambio a otro estado
 Evento: Acontecimiento o estímulo que activa una transición entre estados
 Transición: Proceso en el que se realiza un cambio de estado. Se realiza
como respuesta a un evento específico y viene acompañada de la
realización de un conjunto de acciones por parte del objeto que realiza el
cambio entre estados

59
Diagramas de Estado
 Estado
 Un estado es una condición la cuál es verdadera en un momento determinado.
 Un estado puede representar:

Cualidad pasiva (como el on/off del objeto foco)

Cualidad activa (algo que un objeto esté haciendo: como una cafetera preparando
café)

60
Diagramas de Estado
 Transiciones
 Representan un cambio de estado, desde un estado origen a un estado destino
 La descripción de la transición describe las circunstancias que provocan el cambio de
estado
 Notación completa

Evento [condición] / acción(es)

Evento (trigger): es quien provoca la transición.

Condición: valor booleano que permite o bloquea la transición.

Acción: actividad ininterrumpida que se ejecuta cuando ocurre la transición

62
Diagramas de Estado
 En un proyecto con gestión de incidencias, tenemos los siguientes estados:

1. Creada.

2. Desarrollo.

3. Fin Desarrollo.

4. Pruebas.

5. Finalizada.

6. Cerrada.
 Crear un diagrama de estados que represente que una incidencia es creada y, cuando hay
un desarrollador disponible, se empieza a corregir. Una vez terminada y sólo si existe
alguien del equipo disponible para probarla, se realizan las pruebas. Si éstas son
correctas, se da por finalizada la incidencia, por lo que el cliente (única persona capaz
de dar por cerrada la incidencia) puede empezar a probar. Si se encuentra un error en las
pruebas tanto del equipo de desarrollo como en el cliente, se debe volver a iniciar el
proceso desde el principio.

64
Diagramas de Actividades
 Diagrama de comportamiento desde el punto de vista de las actividades
que realiza el sistema
 Muestra el paso a paso de las diferentes actividades del sistema
 Utilidad

Modelar el comportamiento de determinados procesos del sistema

Modelar el comportamiento de procesos complejos que engloben varios
subprocesos

Representar el flujo de negocio del sistema

68
Diagramas de Interacción
 Tipo de diagramas que modelan la comunicación entre los diferentes
elementos del sistema
 A diferencia de los diagramas de comportamiento, muestran la
comunicación entre distintos componentes, en lugar de entre elementos de
un mismo componente
 Existen 2 tipos, los cuales pueden transformarse el uno en el otro de forma
directa:

Diagrama de Secuencia

Diagrama de Colaboración

69
Diagramas de Secuencia
 Muestra la interacción entre componentes del sistema desde el punto de
vista temporal
 La interacción se representa desde el punto de vista de paso de mensajes
entre objetos o actores a lo largo del tiempo
 Utilidad

Describir procesos internos entre diferentes módulos

Describir comunicaciones con otros sistemas o con actores

Es más adecuados para observar la perspectiva cronológica de la
interacciones

70
 Elementos
Warning
Hay un (al menos)
diagrama de
secuencia para cada
caso de uso

71
Warning
Hay un (al menos)
diagrama de
secuencia para cada
caso de uso

72
Warning
Hay un (al menos)
diagrama de
secuencia para cada
caso de uso

76
 Se representa el tiempo para un actor u
objeto mediante un eje vertical
 El paso de mensajes se indica con una
línea horizontal entre los objetos, además
de la descripción del mensaje
 Cuando el objeto/actor se encuentra
activo se representa un rectángulo sobre
la línea de tiempo, tan grande como
tiempo se encuentre activo

77
 Los mensajes pueden ser:

Síncronos. El emisor del mensaje espera respuesta

Asíncronos. El emisor del mensaje no espera respuesta

Automensaje. El emisor se manda un mensaje a si mismo
 Los mensajes se representan mediante una flecha continua, mientras que los
mensajes de retorno, la flecha es discontinua
 Se puede indicar un número que identifique el orden de ejecución del mensaje
 El mensaje puede ser escrito en lenguaje humano o a nivel técnico

78
Representar mediante un diagrama de secuencia el proceso de una llamada.
Tenemos 3 objetos: emisor, receptor y centralita. El proceso es el siguiente:
1.El emisor descuelga el teléfono y espera a que la centralita de tono
2.El emisor marca el número y espera a que la centralita de tono de llamada
3.Al mismo tiempo que la centralita da tono de llamada, hace sonar el
teléfono del receptor
4.Una vez el receptor descuelga el teléfono, en menos de un segundo su
teléfono deja de sonar y el emisor deja de oír el tono de llamada

80
Representar mediante un diagrama de secuencia el proceso de consulta de
datos a un WS. Tenemos 2 objetos: servicio y base de datos, así como 1
actor. El proceso es el siguiente:
1)El actor envía al servicio web la petición de validación
2)El servicio consulta en BBDD los datos de usuario

Si los datos no son correctos, devuelve vacío al servicio, el cual mandará un
error al usuario
3)La base de datos devuelve los datos de usuario y el servicio responde con OK
4)El usuario manda la petición de obtención de datos
5)El servicio web hace la consulta en BBDD y esta los devuelve
6)El servicio manda la respuesta al usuario

82
Diagramas de Colaboración
 Muestra la interacción entre objetos desde el punto de vista espacial, esto
es, sólo se centra en el paso de mensajes
 Utiliza los mismos elementos que los diagramas de secuencia, a excepción
de las “líneas de vida”
 Utilidad.

Identificar los diferentes objetos del sistema y su relación con los demás

Describir el paso de mensajes entre los objetos o roles

Son útiles en la fase exploratoria para identificar objetos

85
 Mensajes
 Cuando 2 objetos establecen una comunicación, se incluye un enlace,
representado por una línea
 Los mensajes se muestran superpuestos al enlace
 El orden de ejecución de los mensajes se muestra junto a su texto
descriptivo

86
 Mensajes
 Un mensaje se puede expresar en lenguaje natural o en pseudocódigo,
incluyendo condiciones o llamadas a funciones

88
 Ejemplo
 Representar mediante un diagrama de secuencia el proceso de una llamada.
Tenemos 3 objetos: emisor, receptor y centralita. El proceso es el siguiente:
1.El emisor descuelga el teléfono y espera a que la centralita de tono
2.El emisor marca el número y espera a que la centralita de tono de llamada
3.Al mismo tiempo que la centralita da tono de llamada, hace sonar el
teléfono del receptor
4.Una vez el receptor descuelga el teléfono, en menos de un segundo su
teléfono deja de sonar y el emisor deja de oír el tono de llamada

90
 Ejemplo
 Representar mediante un diagrama de secuencia el proceso de consulta de datos a
un WS. Tenemos 2 objetos: servicio y base de datos, así como 1 actor. El proceso
es el siguiente:
1.El actor envía al servicio web la petición de validación
2.El servicio consulta en BBDD los datos de usuario
1.Si los datos no son correctos, devuelve vacío al servicio, el cual mandará un
error al usuario
3.La base de datos devuelve los datos de usuario y el servicio responde con OK
4.El usuario manda la petición de obtención de datos
5.El servicio web hace la consulta en BBDD y esta los devuelve
6.El servicio manda la respuesta al usuario

92
Diagramas de Implementación
 Diagramas que muestran los aspectos de implementación del sistema, ya
sea a nivel lógico (código fuente) como a nivel de estructura física
(hardware)
 Permiten una visión general del sistema, sin entrar en detalles de
implementación o comportamiento
 Existen 3 diagramas:

Diagrama de Componentes. Muestra los diferentes componentes
software existentes así como la relación entre los mismos

Diagrama de Despliegue/Distribución. Muestra los diferentes
componentes hardware existentes así como la relación entre los mismos

93
Diagramas de Componente
 Muestra como un sistema se divide en componentes, así como las
relaciones entre ellos
 Poseen un nivel de abstracción superior a los diagramas de clases, ya que
usualmente un componente se implementa por una o mas clases en tiempo
de ejecución
 Utilizados en su mayor parte en el ámbito de la arquitectura del software
 Utilidad:

Modelar la vista lógica de un sistema

Modelar el código fuente

Modelar las diferentes versiones ejecutables

Modelar bases de datos físicas

Modelar sistemas adaptables

94
Diagramas de Componente
 Componente. Unidad autónoma que forma parte del sistema
 Tipos de componentes.

Ejecutables. Componentes que pueden ser ejecutados de forma autónoma

Librerías. Biblioteca de objetos estática o dinámica

Tabla. Tabla en una Base de Datos

Archivo. Fichero que contiene un código fuente o datos

Documento. Otro tipo de documento

97
Diagramas de Despliegue
 Muestra la topología hardware del sistema
 Utilizados en su mayor parte en el ámbito de la arquitectura. Desarrollado
por diseñadores, ingenieros de sistemas e ingenieros de redes
 Utilidad.

Indicar la distribución de los componentes

Evaluar el rendimiento y la carga del hardware del sistema

Examinar redundancia, balance de carga, etc.

98
 Nodos
 Objeto físico en tiempo de ejecución
 Puede contener objetos, instancias, instancias de componente, etc.
 Representa típicamente un procesador o un dispositivo

99
 Relaciones
 En una relación se puede representar.

El tipo de comunicación entre componentes, a través de una etiqueta

Cardinalidad de la relación

100
 Artefactos
 Representan las especificaciones de un elemento de la implementación.

Archivos

Tablas
 Los artefactos se pueden situar

Dentro de los nodos, indicando el recurso computacional que los va a
albergar y ejecutar

Mediante relaciones, en cuyo caso no se especifica el recurso que los
alberga

102
Cŕeditos
• Transparencias basadas por:
• Christopher Exposito Izquierdo & AiRam Exposito Marquez & otros
• Maria-Isabel, Sanchez Segura & Arturo, Mora-Soto

Networking académico:
Correo electrónico: rguaman@unl.edu.ec
Twitter: @rene5254
SlideShare: https://es.slideshare.net/rene5254
103
Gracias

Diagramas UML

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Diagramas UML

Similar a Diagramas UML (20)

Más de Rene Guaman-Quinche

Más de Rene Guaman-Quinche (20)

Último

Último (10)

Diagramas UML