S6 - Modelo de Paquete

TALLER DE ANÁLISIS DE SISTEMAS
UML para el Análisis de Sistemas

NOMBRE DIRECTOR DE ESCUELA
Director de Escuela / Marcelo Lucero
ELABORACIÓN
Experto disciplinar / Priscilla Alvares
Diseñador instruccional / Felipe Molina
Jefe de Diseño Instruccional / Alejandra San Juan
VALIDACIÓN
Aida Villamar
DISEÑO DOCUMENTO
Boris del Campo
Instituto Profesional AIEP / Educación Online 2

Contenido
Criterios de Evaluación: ................................................................................................................ 4
1. TEMA 1: Modelos de casos de uso y clases. ........................................................................... 4
1.1. Desarrollo “Modelos de Casos de Uso”........................................................................... 4
¿Qué son los actores y cómo identificarlos? .............................................................................. 4
¿Qué son Casos de Uso y cómo identificarlos? .......................................................................... 5
1.2. Desarrollo “Modelos de Clases” ..................................................................................... 6
2. TEMA 2: Diagramas de paquetes. .......................................................................................... 8
2.1. Desarrollo ...................................................................................................................... 8
2.2. Ejemplos/Casos............................................................................................................ 10
3. TEMA 3: Interpretación de modelos físicos de sistemas....................................................... 11
3.1. Desarrollo .................................................................................................................... 11
3.2. Cómo dibujar un diagrama de despliegue .................................................................... 13
4. TEMA 4: Diagramas de componentes. ................................................................................. 14
4.1. Desarrollo .................................................................................................................... 14
5. TEMA 5: Capacidades de hardware ..................................................................................... 16
5.1. Desarrollo .................................................................................................................... 16
5.2. Ejemplos/Casos ........................................................................................................... 17
6. TEMA 6: Diagramas de despliegue: nodos ........................................................................... 18
6.1. Desarrollo .................................................................................................................... 18
6.2. Ejemplos/Casos............................................................................................................ 20
7. TEMA 7: Modelos complejos ............................................................................................... 21
7.1. Desarrollo .................................................................................................................... 21
IDEAS CLAVE ............................................................................................................................... 22
Referencias Bibliográficas........................................................................................... 24

Criterios de Evaluación:
• Adapta modelos de casos de uso y clases en diagramas de paquetes.

• Interpreta modelos físicos de sistemas, considerando diagramas de componentes.
• Determina capacidades de hardware, considerando nodos en diagramas de despliegue.
• Modela sistemas complejos, considerando utilización de diagramas avanzados.
1. TEMA 1: Modelos de casos de uso y clases.
1.1. Desarrollo “Modelos de Casos de Uso”
Recordando lo que hemos desarrollado en la semana n°5, Un modelo de caso de uso

representa las funciones que realiza el sistema, además sirve para apoyar la negociación con el
cliente y los desarrolladores ya que es un modelo visual que permite entender cómo va a funcionar
el futuro sistema. Los casos de uso son el modo de comunicación a lo largo del desarrollo del
sistema. El modelo de caso de uso es el resultado de la toma de requisitos y se utiliza para orientar
al resto del equipo en el desarrollo del sistema.
Mas abajo podemos observar una imagen que muestra una parte de un modelo de caso de uso
(Figura N° 2). Diagrama que muestra los actores, casos de uso y límite del sistema.
Hay muchos modos de modelar un sistema, y cada uno de ellos puede servir para un objetivo
diferente. Sin embargo, el objetivo más importante de un modelo de caso de uso es comunicar el
comportamiento del sistema al cliente o usuario. Por lo tanto, el modelo debe ser fácil de
comprender. Los casos de uso se desarrollan en base a las necesidades de los actores, garantizando
así que el sistema resulta ser lo que los usuarios esperaban.1
¿Qué son los actores y cómo identificarlos?
Un actor especifica un rol cuando interactúa directamente con el sistema; Las siguientes preguntas
permiten identificar a los actores que interactuarán con el Sistema.
- ¿Quién o qué utiliza el Sistema?

- ¿Qué roles toman en la interacción?
- ¿Quién toma información del Sistema?
- ¿Quién provee información al Sistema?
- ¿En qué parte de la compañía es utilizado el Sistema?
- ¿Quién instala, soporta y mantiene el Sistema?
- ¿Quién inicia y termina la ejecución del sistema?
- ¿Qué otros sistemas utilizan el Sistema?
- ¿Ocurre algo en algún momento específico?
1Directriz: Modelo de caso de uso. (n.d.). Cgr.Go.Cr. Retrieved April 12, 2021, from
https://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/core.base_rup/guidances/guidelines/use-case_model_CC121CF4.html

La siguiente es la tabla (Figura N° 1) representa la manera como debemos documentar los actores
identificados que interactuaran con el sistema. La tabla debe llevar el siguiente contenido: El código
del actor reseñado como ACT.# se refiere al prefijo ACT. seguido por el número de actor asignado. La
descripción se refiere a una breve reseña del rol del actor para el sistema y las fuentes son los
involucrados del negocio que ayudaron a definir y describir al actor.2
Actor ACT.# Nombre del Actor

Descripción <descripción del actor>
Responabilidades • <Responsabilidad 1>
• <Responsabilidad 2>
Fuentes <Stakeholders que identificaron y contribuyeron a definir al actor>

FIGURA N° 1: DOCUMENTACIÓN DE ACTORES
(Rodríguez, s.f.)
FIGURA N° 2: MODELO DE CASOS DE U SO

(Pressman, 2010)
¿Qué son Casos de Uso y cómo identificarlos?
Los Casos de Uso representan lo que un actor desea que haga el Sistema. Los casos de uso
definen una secuencia de acciones ejecutadas por un sistema que producen un resultado
observable de valor para un actor. Los casos de uso son siempre iniciados por un actor y son escritos
desde el punto de vista del actor.
2 Estructuración y Especificación de Casos de Uso - alfonsoperezr. (n.d.). Google.Com. Retrieved April 12, 2021, from
https://sites.google.com/site/alfonsoperezr/investigacion/estructuracin-y-especificacin-de-casos-de-uos

La siguiente es la lista de preguntas que permiten identificar los casos de uso dentro de las
fronteras de un sistema:
- ¿Qué funciones del sistema son requeridas por un actor específico?

- ¿El sistema guarda o recupera información? Si es así ¿Qué actores disparan esta acción?
- ¿Qué ocurre cuando el sistema cambia de estado? ¿Algún actor es notificado?
- ¿Algún evento externo afecta al sistema? ¿Qué notifica el sistema respecto de estos eventos?
- ¿El sistema interactúa con algún sistema externo?
- ¿El sistema genera algún reporte?
La especificación de los casos de uso (Figura N° 3) se refiere a la descripción de cada una de las
partes definidas para lograr su descripción completa. El siguiente cuadro muestra las partes y las
indicaciones básicas para iniciar su redacción. 3
Caso de Uso CU.1 XX

Fuentes <Stakesholders que proporcionaron información de esta funcionalidad>
Actor Act.# <nombre de los actores> [(<Pseudónimos>)] [ – secundario]
Descripción <Descripción del caso de uso>
Flujo básico 1. Título del paso
Descripción del paso.
2. Título del paso
Descripción del paso.
Flujos alternos 1. Título del FA
Descripción del FA
2. Título del FA
Descripción del FA.
Pre-condiciones 1. Título del Precondición
Descripción del PRC
Post-condiciones 1. Título del Postcondiciones
Descripción de la PTC
Requerimientos 1. Título del requerimiento
trazados Descripción del requerimiento o porqué se enlaza a el desde este caso de uso
Puntos de inclusión 1. Título del punto de inclusión
Descripción del punto de inclusión
Puntos de 1. Título del punto de extensión
extensión Descripción del punto de extensión
Notas 1. Título de la Nota
Descripción de la nota
FIGURA N° 3: DOCUMENTACIÓN DE CASOS DE USO
(Rodríguez, s.f.)
1.2. Desarrollo “Modelos de Clases”
Recordando el contenido de la semana 4 y 5 de este módulo, podemos destacar que el lenguaje

UML nos permite modelar diferentes diagramas, cada uno con sus propios objetivos, en esta
oportunidad recordaremos al diagrama de clase, el cual aporta una visión estática del sistema,
sin mostrar la naturaleza dinámica de las comunicaciones entre los objetos de las clases.
3
Estructuración y Especificación de Casos de Uso - alfonsoperezr. (n.d.). Google.Com. Retrieved April 12, 2021, from
https://sites.google.com/site/alfonsoperezr/investigacion/estructuracin-y-especificacin-de-casos-de-uos

Este diagrama recoge los objetos y sus asociaciones para representar la estructura y el
comportamiento de cada uno, pero no refleja los comportamientos temporales de las clases,
aunque para mostrarlos se puede utilizar un diagrama de transición de estados.
Un diagrama de clases está compuesto por los siguientes elementos:
• Clase: atributos, métodos y visibilidad.

• Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
• Interfaces: Una interfaz es una especificación de la semántica de un conjunto de

operaciones de una clase o paquete, que son visibles desde otras clases o paquetes.
Normalmente, se corresponde con una parte del comportamiento del elemento que la
proporciona.
Una interfaz se representa como una caja con compartimentos, igual que las clases.
En la zona superior se incluye el nombre y el estereotipo <>. Existe otra representación más
simple para la interfaz: un círculo pequeño (A) asociado a una clase con el nombre de la
interfaz debajo. 4
A
FIGURA N° 4: REPRESENTACIÓN DE I NTERFACES EN DIAGRAMA DE CLASES

(Cillero, s.f.)
• Paquetes: Los paquetes se usan para dividir el modelo de clases del sistema de información,
agrupando clases u otros paquetes según los criterios que sean oportunos. Las
dependencias entre ellos se definen a partir de las relaciones establecidas entre los distintos
elementos que se agrupan en estos paquetes los cuales se representan mediante un icono
con forma de carpeta y las dependencias con flechas discontinuas entre los paquetes
dependientes. Este contenido se desarrolla en detalle en TEMA 2: Diagramas de paquetes.
4 Diagrama de Clases. (2013, November 12). Cillero.es. https://manuel.cillero.es/doc/metodologia/metrica-

3/tecnicas/diagrama-de-clases/

FIGURA N° 5: DIAGRAMA DE C LASE
(Diagramas UML, 2018)
2. TEMA 2: Diagramas de paquetes.
2.1. Desarrollo
En UML cuando necesitamos agrupar algún componente o elemento utilizamos el concepto de

paquete, es decir que el objetivo de este termino es reducir el tamaño de un diagrama para poder
tener una visión mas clara del sistema completo.
El uso más comunes de estos diagramas es para organizar modelos de casos de uso y de clase,
aunque realmente se puede utilizar para otros elementos UML.
Estos diagramas contienen dos tipos de elementos:
• Paquetes: Un paquete es una agrupación de elementos, bien sea casos de uso, clases o
componentes. Los paquetes pueden contener a su vez otros paquetes anidados que en última
instancia contendrán alguno de los elementos anteriores. El paquete se puede representar en
UML como el icono de carpeta donde en la pestaña superior se coloca el nombre (A), en el caso
de tener definido el estereotipo se debe colocar el nombre de la siguiente manera
<<Nombre_Carpeta>> (B), por otra parte, el contenido del paquete va dentro de la carpeta con
los respectivos símbolos de visibilidad + para los públicos, - para los privados y # para los
protegidos (C).

NOMBRE PAQUETE <<Nombre_Paquete>>
A B
NOMBRE PAQUETE
+ Elemento 1
- Elemento 2
# Elemento 3
C
FIGURA N° 6: NOTACIONES DE PAQUETES

(Elaboración Propia, P.A.E., 2021)
• Dependencias entre paquetes: Existe una dependencia cuando un elemento de un paquete

requiere de otro es decir que un paquete necesita de otro paquete para funcionar con
normalidad. Esta dependencia se representa con una flecha discontinua que va de un paquete
a otro indicando la dirección de origen a destino. Es importante evitar las dependencias
circulares entre los paquetes.
ORIGEN DESTINO
A B
FIGURA N° 7: DEPENDENCIA ENTRE PAQUETES

(Elaboración Propia, P.A.E., 2021)
Los paquetes de este diagrama también pueden contener a otros paquetes, cuando sucede
esto lo llamamos Jerarquía de paquetes, además se optimizar estos diagramas teniendo en cuenta
la generalización de paquetes, el evitar ciclos en la estructura del diagrama, la minimización de las
dependencias entre paquetes, etc.5
5 Diagrama de Paquetes. (2013, November 17). Cillero.es. https://manuel.cillero.es/doc/metodologia/metrica-

3/tecnicas/diagrama-de-paquetes/

FIGURA N° 8: DIAGRAMA DE PAQUETES
2.2. Ejemplos/Casos
A continuación, se muestra, a modo de ejemplo, un diagrama de paquetes de una aplicación, La aplicación, que tiene
como finalidad la recepción y gestión de quejas y sugerencias, estaría compuesta por los siguientes paquetes:
• Capa de presentación. Incluye a su vez los paquetes Interfaz de Usuario e Interfaz Amin
• Capa de Lógica de Negocio, con los siguientes paquetes:
o Subsistema de recepción de dudas y sugerencias.
o Subsistema de asignación de responsable.
o Subsistema de creación de informes.
o Gestor documental.
o Subsistema de gestión de usuarios.
o Envío de notificaciones.
• Base de datos.
• CRM.
• DataWarehouse.
Como puedes observar, cada uno de los subpaquetes podría expandirse en otros paquetes, hasta llegar al punto de tener
unos paquetes primitivos que no pueden volver a explotarse.6
6 Diagrama de paquetes. (2018, August 17). Diagramasuml.com. https://diagramasuml.com/paquetes/

FIGURA N° 9: E JEMPLO SISTEMA DE R ECEPCIÓN Y G ESTIÓN DE QUEJAS
3. TEMA 3: Interpretación de modelos físicos de sistemas.
3.1. Desarrollo
El modelo físico en UML describe los componentes, de hardware y de software, tales como
plataformas de hardware, conectividad de redes, componentes de software, procesadores, sistemas
operativos, tales componentes son denominados “Nodos” en el lenguaje UML. Este modelo físico
también es conocido como diagrama de despliegue y es complemento de los diagramas de
componentes que, unidos, proveen la vista de implementación del sistema.
El Modelo Físico/de Despliegue provee un modelo detallado de la forma en la que los
componentes se desplegarán a lo largo de la infraestructura del sistema. Detalla las capacidades de
red, las especificaciones del servidor, los requisitos de hardware y otra información relacionada al
despliegue del sistema propuesto.
Normalmente las relaciones entre nodos son conectadas por enlaces de red, conexiones
TCP/IP, microondas, etc. A continuación, veremos unos nodos de tipo abstracto que pueden ser
implementados en tiempo de ejecución por instancias físicas.
FIGURA N° 10: NODOS DE T IPO ABSTRACTO

(SPARX Systems, s.f.)

Para representar la comunicación y/o caminos entre los nodos lo hacemos atraves de un
alinea recta que conecta un nodo con otro de igual manera se de colocar el estereotipo, con el
nombre del protocolo de comunicación, si es relevante, se suele poner al lado de los nodos el
número de nodos que participan en la asociación. Por ejemplo, un servidor web al que se conectan
usuarios a través de una red WAN y que se prevé una conexión de 100 usuarios tendría la siguiente
representación:
FIGURA N° 11: NOTACIÓN DE CONEXIÓN C LIENTE SERVIDOR

FIGURA N° 12: VISTA DE DESPLIEGUE

(Sparx Systems, s.f.)
MF01: Modelo Físico

El modelo físico muestra dónde y cómo se desplegarán los componentes. Es un mapa
específico de la instalación física del sistema. Un diagrama de despliegue ilustra el despliegue físico
del sistema en un ambiente de producción (o prueba). Muestra dónde se ubicarán los
componentes, en qué servidores, máquinas o hardware. Puede ilustrar vínculos de red, ancho de
banda de LAN, etc.7
7Enterprise Architect - Modelo Físico. (n.d.). Com.Ar. Retrieved April 13, 2021, from
http://www.sparxsystems.com.ar/resources/tutorial/physical_models.php

FIGURA N° 13: MF01 MODELO FÍSICO
3.2. Cómo dibujar un diagrama de despliegue
• Paso 1: Identifique el propósito de su diagrama de despliegue. Luego identifique los nodos y

dispositivos dentro del sistema que visualizarás con el diagrama.
• Paso 2: Averiguar las relaciones entre los nodos y los dispositivos. Una vez que sepas cómo están
conectados, procede a añadir las asociaciones de comunicación al diagrama.
• Paso 3: Identificar qué otros elementos, como los componentes, objetos activos, necesitan
ser añadidos para completar el diagrama.
• Paso 4: Añada las dependencias entre los componentes y los objetos según sea necesario.8
FIGURA N° 14: DIAGRAMA DE DESPLIEGUE SISTEMA DE COMPRAS EN LÍNEA

(Creately, s.f.)
8Siriwardhana, S. (2020, October 26). Tutorial de Diagrama de Despliegue. Creately.com.

https://creately.com/blog/es/diagramas/tutorial-de-diagrama-de-despliegue/

4. TEMA 4: Diagramas de componentes.
4.1. Desarrollo
Un diagrama de componentes sirve para mostrar la relación entre los componentes, puertos,
interfaces, es decir representa la una parte modular del sistema; Un componente tiene una vista
externa con propiedades y operaciones públicas y tiene un vista interna con propiedades privadas y
relación de clasificadores.
Un componente representa una parte física de un sistema. Entonces, un componente puede
ser una tabla, archivos de datos, ejecutables, código fuente, código binario, una librería con una
interfaz definida, una biblioteca de vínculos dinámicos, documentos, etc. Un componente se
representa como un rectángulo, con dos pequeños rectángulos superpuestos perpendicularmente
en el lado izquierdo. Para distinguir distintos tipos de componentes se les puede asignar un
estereotipo, cuyo nombre estará́ dentro del símbolo: << ... >>
FIGURA N° 15: COMPONENTE

(Cillero, s.f.)
Un diagrama de componentes contiene, componentes, interfaces y relaciones. También

pueden aparecer otros tipos de símbolo. la Figura N° 16 muestra este Símbolo. Debe colocar el
nombre del componente dentro del símbolo. El nombre es una cadena.
FIGURA N° 16: SÍMBOLO QUE REPRESENTA UN COMPONENTE

(Slide To Doc, s.f.)
La Figura N° 17 le muestra que, si el componente es miembro de un paquete, puede utilizar

el nombre del paquete como prefijo para el nombre del componente. También puede agregar
información que muestra algún detalle del componente. El símbolo de la derecha de la Figura N° 17
muestra las clases que implementan un componente en particular.
La Figura N° 18 muestra otra forma de hacer estos, aunque esta técnica por lo general desordena el
diagrama.

FIGURA N° 17: ADICIÓN DE INFORMACIÓN AL SÍMBOLO DEL COMPONENTE
FIGURA N° 18: SÍMBOLOS DE RELACIONES ENTRE COMPONENTES Y CLASES

En el diagrama de componentes, la interfaz se representa como un pequeño circulo situado

junto al componente que lo implementa y unido a él por una línea continua. Junto al círculo se debe
agregar el nombre
FIGURA N° 19: NOTACIÓN DE INTERFAZ

(Cillero, s.f.)

FIGURA N° 19: DIAGRAMA DE COMPONENTES SISTEMA DE G ESTIÓN HOSPITALARIA
(Creately, s.f.)
5. TEMA 5: Capacidades de hardware

5.1. Desarrollo
Los Diagramas de Despliegue muestran las relaciones físicas de los distintos nodos que
componen un sistema y el reparto de los componentes sobre dichos nodos. 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 un
computador, un dispositivo o memoria. Los estereotipos permiten precisar la naturaleza del equipo:
• 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. Las instancias de los nodos pueden contener instancias de ejecución, como instancias de
componentes y objetos. El modelo puede mostrar dependencias entre las instancias y sus
interfaces, y también modelar la migración de entidades entre nodos u otros contenedores.9
9 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 un computador, L. D. de D. M. las R. F. de L. D. N. Q. C. un S. y. el R. de L. C. S. D. N. L.
V. de D. R. la D., & del equipo:, un D. o. M. L. E. P. P. la N. (n.d.). Diagrama de despliegue. Edu.Bo. Retrieved April 14, 2021,
from http://virtual.usalesiana.edu.bo/web/conte/practica/22012/2132.pdf

Los diagramas de despliegue muestran la configuración en funcionamiento del sistema,
incluyendo su hardware y su software. Para cada componente de un diagrama de despliegue se
deben documentar las características técnicas requeridas, el tráfico de red esperado, el tiempo de
respuesta requerido, etc.
• Identificar los elementos del hardware que formarán parte del sistema
• Identificar los componentes que serán parte de cada nodo
• Identificar las relaciones que existe entre cada uno de estos (Dependencia, Interfaz,
Dependencias-Interfaz)10
5.2. Ejemplos/Casos
La red ARCnet (Red de Cómputo de Recursos Adjuntos) implica pasar un token o señal de un
equipo a otro. La diferencia es que en esta red cada equipo tiene asignado un número. El orden
numérico determina el equipo que obtendrá el token. Cada equipo se conecta a un concentrador o
hub que podrá ser activo (amplifica la información que llega antes de transmitirla) o pasivo
(trasmite la información sin amplificarla). Los concentradores ARCnet no mueven el token en anillo.
FIGURA N° 20: E JEMPLO DIAGRAMA DE DESPLIEGUE

(Ruiz, s.f.)
10de 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 un computador, L. D. de D. M. las R. F. de L. D. N. Q. C. un S. y. el R. de L. C. S. D.
N. L. V. de D. R. la D., & del equipo:, un D. o. M. L. E. P. P. la N. (n.d.). Diagrama de despliegue. Edu.Bo. Retrieved April 14,
2021, from http://virtual.usalesiana.edu.bo/web/conte/practica/22012/2132.pdf

6. TEMA 6: Diagramas de despliegue: nodos
6.1. Desarrollo
Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecución de un sistema. Esto

muestra la configuración de los elementos, artefactos y muestra cómo se trazan en esos nodos. Un
Nodo representa a un elemento de hardware o software. Y toma la forma de una caja en tres
dimensiones. Además, a cada nodo se le asocia un subsistema de construcción que agrupa
componentes software, permitiendo de este modo, determinar la distribución de estos
componentes. Por lo tanto, un diagrama de despliegue puede incluir, dependiendo del nivel de
detalle, todos los elementos descritos en la técnica de diagrama de componentes, además los nodos
y las conexiones propios de esta técnica.
FIGURA N° 21: NODO

• Instancia de Nodo: se puede distinguir desde un nodo por el hecho de que su nombre está
subrayado y tiene dos puntos antes del tipo de nodo base. El siguiente diagrama muestra una
instancia nombrada de un computador.
FIGURA N° 22: I NSTANCIA DE NODO

• Estereotipo de Nodo: Un número de estereotipos estándar se proveen para los nodos,

nombrados «cdrom», «cd-rom», «computer», «disk array», «pc», «pc client», «pc server»,
«secure», «server», «storage», «unix server», «user pc». Estos mostrarán un icono apropiado en
la esquina derecha arriba del símbolo nodo.11
11Sparx Systems - Tutorial UML 2 - Diagrama de Despliegue. (n.d.). Com.Ar. Retrieved April 13, 2021, from
http://www.sparxsystems.com.ar/resources/tutorial/uml2_deploymentdiagram.php

FIGURA N° 23: E STEREOTIPO DE NODO
• Artefacto: Es un producto del proceso de desarrollo de software, que puede incluir los
modelos del proceso como por ejemplo Casos de Uso, modelos de Diseño, entre otros,
también puede incluir archivos fuente, ejecutables, documentos de diseño, reportes de
prueba, prototipos, manuales de usuario y más. Un artefacto se denota por un rectángulo
mostrando el nombre, el estereotipo «artifact» y un icono de documento.
FIGURA N° 24: ARTEFACTO

• Asociación: En el contexto del diagrama de despliegue, una asociación representa una ruta
de comunicación entre los nodos. El siguiente diagrama muestra un diagrama de despliegue
para una red, mostrando los protocolos de red como estereotipos y también mostrando
multiplicidades en los extremos de la asociación.
FIGURA N° 25: ASOCIACIÓN


• Nodo como contenedor: Un nodo puede contener otros elementos, como componentes o
artefactos. El siguiente diagrama muestra un diagrama de despliegue para una parte del
sistema embebido y muestra un artefacto ejecutable como contenido por el nodo madre
(motherboard).12
FIGURA N° 26: NODO COMO CONTENEDOR

6.2. Ejemplos/Casos
A continuación, podemos observar la imagen de un diagrama de despliegue, este diagrama

representa una aplicación web, que permite el ingreso de clientes web y clientes móviles, para
ambos clientes las opciones que ofrece la aplicación son exactamente las mismas. El ejemplo
muestra un total de 6 nodos y algunos de sus componentes:
FIGURA N° 27: E JEMPLO DIAGRAMA DE DESPLIEGUE

(Diagramas UML, s.f.)
12Sparx Systems - Tutorial UML 2 - Diagrama de Despliegue. (n.d.). Com.Ar. Retrieved April 13, 2021, from
http://www.sparxsystems.com.ar/resources/tutorial/uml2_deploymentdiagram.php

7. TEMA 7: Modelos complejos
7.1. Desarrollo
Un sistema complejo, tiene muchos elementos que se relacionan fuertemente y están

altamente interconectados, para la realización de sistemas sofisticados o relacionados con áreas
mas complejas, como por ejemplo en la confección de un software científico, medico o espacial.
Básicamente, un sistema puede definirse como un «conjunto de elementos en interacción».

Los sistemas complejos están caracterizados por tener una estructura compuesta por varios niveles.
En estos sistemas complejos13:
• Los componentes de niveles jerárquicos inferiores suelen mostrar un grado de autonomía
significativo.
• El comportamiento del sistema surge a partir de la autoorganización de sus componentes,
sin que esta organización esté controlada ni dirigida por ningún ente exterior al sistema.
• Los componentes básicos de estos sistemas complejos (células, hormigas, individuos,
poblaciones, empresa) perciben su entorno y responden a cambios en él de forma
potencialmente diferente.
Muchos sistemas complejos son adaptativos (organismos, ecosistemas, economías, sociedades)

el comportamiento de los componentes básicos del sistema puede evolucionar en el tiempo, dando
lugar a una cierta capacidad de respuesta frente a cambios en el entorno por medio de mecanismos
de:
• Aprendizaje a escala individual, y/o

• Selección y reemplazo (lo cual da lugar a un aprendizaje a escala poblacional)
Todas estas características hacen que el proceso de modelado formal de sistemas complejos
difiera sustancialmente del de otros sistemas más simples. En particular, su naturaleza
descentralizada, la presencia de bucles de causalidad y retroalimentación no lineales, y el hecho de
contener varias unidades más o menos autónomas, que pueden interaccionar, evolucionar, y
adaptar su comportamiento a cambios en el entorno, implica que en la mayoría de los casos es muy
difícil conseguir un modelo que pueda describir el sistema complejo adecuadamente y que además
sea resoluble matemáticamente.14
La posibilidad de trabajar con modelos formales más complejos que los modelos
matemáticos tradicionales nos obliga a expandir ligeramente el marco del proceso de modelado
científico que introdujimos en la sección anterior (ver Figura N° 28).
13 R., I. L., M., G. J., I., S. J., & Ricardo, D. E. L. O. (n.d.). EMPIRIA. Revista de Metodología de las Ciencias Sociales.
Redalyc.Org. Retrieved April 14, 2021, from https://www.redalyc.org/pdf/2971/297124024004.pdf
14 R., I. L., M., G. J., I., S. J., & Ricardo, D. E. L. O. (n.d.). EMPIRIA. Revista de Metodología de las Ciencias Sociales.
Redalyc.Org. Retrieved April 14, 2021, from https://www.redalyc.org/pdf/2971/297124024004.pdf

FIGURA N° 28: P ROCESO DE MODELADO CON ABSTRACCIÓN INTERMEDIA
(Empiria)
IDEAS CLAVE
Los distintos modelos que hemos visto y aprendido en el transcurso (Figura N° 30) de esta
semana nos sirven para visualizar las distintas perspectivas de un desarrollo de software. Crear y
diseñar estos modelos no es una tarea sencilla, por lo que debemos analizar de manera muy
minuciosa la problemática a desarrollar. Una vez que la hemos comprendido, debemos desarrollar
los modelos correspondientes que permitirán comunicarnos de manera interna con los distintos
roles que participan en el desarrollo de software, como por ejemplo: el diseñador, programador,
tester, entre otros. Cada modelo entrega una vista especifica con información relevante para cada
uno de ellos. Por ejemplo, el diagrama de despliegue permite identificar los artefactos que utilizará
el sistema y las relaciones entre ellos, aporta información muy importante para el programador y el
tester del proyecto, ya que con este tipo de modelo saben de manera exacta qué herramientas,
conexiones y protocolos de comunicación deben contemplar a la hora de desarrollar.
Por otro lado, el diagrama de casos de uso, que es uno de los primeros modelos que
desarrollamos, es el que cumple la principal función de señalar al cliente y al diseñador cómo hemos
pensado la lógica de funcionamiento del futuro software. Por lo que hace mucho más fácil la
creación de la interfaz grafica del sistema, permitiendo la creación de un sistema siempre orientado
al objetivo de cumplir con las necesidades y expectativas del cliente/usuario.
Literalmente los modelos desarrollados en UML son tan importantes para el desarrollo de
un sistema de software, como lo son los planos confeccionados por un arquitecto para la
construcción de una casa o edificio, independiente del tamaño del proyecto de la construcción, la
importancia de los planos y el objetivo del proyecto; nunca va a cambiar.

FIGURA N° 29: P ROCESO DE CONSTRUCCIÓN DE UNA CASA
(Istock, s.f.)
FIGURA N° 30: DIAGRAMAS UML

(Ok Hosting, s.f.)

Referencias Bibliográficas
Diagrama de Clases. (2013, noviembre 12). Cillero.es.

https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/diagrama-de-clases/
Diagrama de Paquetes. (2013, noviembre 17). Cillero.es.

https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/diagrama-de-paquetes/
Diagrama de paquetes. (2018, agosto 17). Diagramasuml.com.

https://diagramasuml.com/paquetes/
ISTP "CAYETANO HEREDIA": Modelado de caso de uso y Diagrama de Caso de Uso (s. f.)
Recuperado de https://es.slideshare.net/turlahackers/modelado-de-caso-de-uso-y-diagrama-de-
caso-de-uso
Enterprise Architect - Modelo Físico. (s. f.). Com.ar. Recuperado 19 de abril de 2021, de
http://www.sparxsystems.com.ar/resources/tutorial/physical_models.php
Estructuración y Especificación de Casos de Uso - alfonsoperezr. (s. f.). Google.com. Recuperado 19

de abril de 2021, de https://sites.google.com/site/alfonsoperezr/investigacion/estructuracin-y-
especificacin-de-casos-de-uos
Físico, E. M. (s. f.). Una Introducción al UML. Com.ar. Recuperado 19 de abril de 2021, de
http://www.sparxsystems.com.ar/downloads/whitepapers/El_Modelo_Fisico.pdf
R., I. L., M., G. J., I., S. J., & Ricardo, D. E. L. O. (s. f.). EMPIRIA. Revista de Metodología de las Ciencias
Sociales. Redalyc.org. Recuperado 19 de abril de 2021, de
https://www.redalyc.org/pdf/2971/297124024004.pdf
Siriwardhana, S. (2020, octubre 26). Tutorial de Diagrama de Despliegue. Creately.com.

https://creately.com/blog/es/diagramas/tutorial-de-diagrama-de-despliegue/
Sparx Systems - Tutorial UML 2 - Diagrama de Despliegue. (s. f.). Com.ar. Recuperado 19 de abril de
2021, de http://www.sparxsystems.com.ar/resources/tutorial/uml2_deploymentdiagram.php

S6 - Modelo de Paquete

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

S6 - Modelo de Paquete

Cargado por

Copyright:

Formatos disponibles

TALLER DE ANÁLISIS DE SISTEMAS

UML para el Análisis de Sistemas

Director de Escuela / Marcelo Lucero

Experto disciplinar / Priscilla Alvares

Diseñador instruccional / Felipe Molina

Jefe de Diseño Instruccional / Alejandra San Juan

Boris del Campo

Instituto Profesional AIEP / Educación Online 2

Instituto Profesional AIEP / Educación Online 3

• Adapta modelos de casos de uso y clases en diagramas de paquetes.

1. TEMA 1: Modelos de casos de uso y clases.

1.1. Desarrollo “Modelos de Casos de Uso”

Recordando lo que hemos desarrollado en la semana n°5, Un modelo de caso de uso

- ¿Quién o qué utiliza el Sistema?

Instituto Profesional AIEP / Educación Online 4

Actor ACT.# Nombre del Actor

Fuentes <Stakeholders que identificaron y contribuyeron a definir al actor>

FIGURA N° 2: MODELO DE CASOS DE U SO

¿Qué son Casos de Uso y cómo identificarlos?

Instituto Profesional AIEP / Educación Online 5

- ¿Qué funciones del sistema son requeridas por un actor específico?

Caso de Uso CU.1 XX

1.2. Desarrollo “Modelos de Clases”

Recordando el contenido de la semana 4 y 5 de este módulo, podemos destacar que el lenguaje

Instituto Profesional AIEP / Educación Online 6

Un diagrama de clases está compuesto por los siguientes elementos:

• Clase: atributos, métodos y visibilidad.

• Interfaces: Una interfaz es una especificación de la semántica de un conjunto de

FIGURA N° 4: REPRESENTACIÓN DE I NTERFACES EN DIAGRAMA DE CLASES

4 Diagrama de Clases. (2013, November 12). Cillero.es. https://manuel.cillero.es/doc/metodologia/metrica-

Instituto Profesional AIEP / Educación Online 7

2. TEMA 2: Diagramas de paquetes.

En UML cuando necesitamos agrupar algún componente o elemento utilizamos el concepto de

Estos diagramas contienen dos tipos de elementos:

Instituto Profesional AIEP / Educación Online 8

FIGURA N° 6: NOTACIONES DE PAQUETES

• Dependencias entre paquetes: Existe una dependencia cuando un elemento de un paquete

FIGURA N° 7: DEPENDENCIA ENTRE PAQUETES

5 Diagrama de Paquetes. (2013, November 17). Cillero.es. https://manuel.cillero.es/doc/metodologia/metrica-

Instituto Profesional AIEP / Educación Online 9

6 Diagrama de paquetes. (2018, August 17). Diagramasuml.com. https://diagramasuml.com/paquetes/

Instituto Profesional AIEP / Educación Online 10

3. TEMA 3: Interpretación de modelos físicos de sistemas.

FIGURA N° 10: NODOS DE T IPO ABSTRACTO

Instituto Profesional AIEP / Educación Online 11

FIGURA N° 11: NOTACIÓN DE CONEXIÓN C LIENTE SERVIDOR

FIGURA N° 12: VISTA DE DESPLIEGUE

MF01: Modelo Físico

Instituto Profesional AIEP / Educación Online 12

3.2. Cómo dibujar un diagrama de despliegue

• Paso 1: Identifique el propósito de su diagrama de despliegue. Luego identifique los nodos y

FIGURA N° 14: DIAGRAMA DE DESPLIEGUE SISTEMA DE COMPRAS EN LÍNEA

8Siriwardhana, S. (2020, October 26). Tutorial de Diagrama de Despliegue. Creately.com.

Instituto Profesional AIEP / Educación Online 13

FIGURA N° 15: COMPONENTE

Un diagrama de componentes contiene, componentes, interfaces y relaciones. También

FIGURA N° 16: SÍMBOLO QUE REPRESENTA UN COMPONENTE

La Figura N° 17 le muestra que, si el componente es miembro de un paquete, puede utilizar

Instituto Profesional AIEP / Educación Online 14

FIGURA N° 18: SÍMBOLOS DE RELACIONES ENTRE COMPONENTES Y CLASES

En el diagrama de componentes, la interfaz se representa como un pequeño circulo situado

FIGURA N° 19: NOTACIÓN DE INTERFAZ

Instituto Profesional AIEP / Educación Online 15