Un modelo de clases simplificado de comercio electr\u00f3nico podr\u00eda verse as\u00ed:<\/p>\n
Cliente\r\n- customerId\r\n- name\r\n+ placeOrder()\r\n\r\nPedido\r\n- orderId\r\n- orderDate\r\n- status\r\n+ calculateTotal()\r\n\r\nProducto\r\n- productId\r\n- name\r\n- price\r\n+ updatePrice()\r\n<\/code><\/pre>\nLas posibles relaciones incluyen:<\/p>\n
Cliente 1 -------- 0..* Pedido\r\nPedido 1 -------- 1..* Producto\r\n<\/code><\/pre>\nEn un dise\u00f1o m\u00e1s detallado, una ItemPedido<\/code> clase podr\u00eda introducirse entre Pedido<\/code> y Producto<\/code>.<\/p>\nLos diagramas de clases son \u00fatiles para:<\/p>\n
\n- \n
Modelado del dominio<\/p>\n<\/li>\n
- \n
Dise\u00f1o orientado a objetos<\/p>\n<\/li>\n
- \n
Planificaci\u00f3n de bases de datos y aplicaciones<\/p>\n<\/li>\n
- \n
Identificaci\u00f3n de responsabilidades<\/p>\n<\/li>\n
- \n
Explicaci\u00f3n de herencia e interfaces<\/p>\n<\/li>\n<\/ul>\n
Un diagrama de clases describe las clases en general, mientras que un diagrama de objetos muestra instancias espec\u00edficas de esas clases. Visual Paradigm describe los diagramas de clases como modelos de clases, atributos, operaciones y relaciones dentro de un sistema orientado a objetos.<\/p>\n
2. Diagrama de objetos<\/h3>\n
Un diagrama de objetos muestra una instant\u00e1nea de un sistema en un momento determinado. Representa instancias reales de objetos en lugar de clases generales.<\/p>\n
![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab20a0cb1055.png\")
<\/p>\n
Por ejemplo:<\/p>\n
customerA:Cliente\r\nname = \"Alex\"\r\n\r\norder1001:Pedido\r\nstatus = \"Pagado\"\r\n<\/code><\/pre>\nUn diagrama de objetos es \u00fatil cuando necesita demostrar:<\/p>\n
\n- \n
El estado de los objetos en tiempo de ejecuci\u00f3n<\/p>\n<\/li>\n
- \n
Ejemplo de relaciones de datos<\/p>\n<\/li>\n
- \n
Un escenario espec\u00edfico<\/p>\n<\/li>\n
- \n
C\u00f3mo se conectan las instancias de las clases<\/p>\n<\/li>\n<\/ul>\n
Un diagrama de clases podr\u00eda mostrar que un cliente puede realizar muchos pedidos. Un diagrama de objetos podr\u00eda mostrar que clienteA<\/code> posee actualmente pedido1001<\/code> y pedido1002<\/code>.<\/p>\n3. Diagrama de componentes<\/h3>\n
![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab20a8624ccc.png\")
<\/p>\n
Un diagrama de componentes muestra la organizaci\u00f3n y las dependencias de los componentes de software reemplazables.<\/p>\n
Un diagrama de componentes de comercio electr\u00f3nico podr\u00eda incluir:<\/p>\n
\n- \n
Aplicaci\u00f3n web<\/p>\n<\/li>\n
- \n
Servicio de pedidos<\/p>\n<\/li>\n
- \n
Servicio de productos<\/p>\n<\/li>\n
- \n
Servicio de pagos<\/p>\n<\/li>\n
- \n
Servicio de notificaciones<\/p>\n<\/li>\n
- \n
Base de datos<\/p>\n<\/li>\n<\/ul>\n
Ejemplo:<\/p>\n
Aplicaci\u00f3n web --> Servicio de pedidos\r\nServicio de pedidos --> Servicio de pagos\r\nServicio de pedidos --> Servicio de notificaciones\r\nServicio de pedidos --> Base de datos de pedidos\r\n<\/code><\/pre>\nLos diagramas de componentes son especialmente \u00fatiles para:<\/p>\n
\n- \n
Arquitecturas de microservicios<\/p>\n<\/li>\n
- \n
Sistemas orientados a servicios<\/p>\n<\/li>\n
- \n
Dise\u00f1o de API<\/p>\n<\/li>\n
- \n
Arquitectura de aplicaciones<\/p>\n<\/li>\n
- \n
Mostrar l\u00edmites y dependencias de los servicios<\/p>\n<\/li>\n<\/ul>\n
4. Diagrama de implementaci\u00f3n<\/h3>\n
![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab20aff2b456.png\")
<\/p>\n
Un diagrama de implementaci\u00f3n representa el entorno f\u00edsico o virtual en el que se ejecuta el software.<\/p>\n
Puede mostrar:<\/p>\n
\n- \n
Dispositivos cliente<\/p>\n<\/li>\n
- \n
Servidores web<\/p>\n<\/li>\n
- \n
Servidores de aplicaciones<\/p>\n<\/li>\n
- \n
Servidores de base de datos<\/p>\n<\/li>\n
- \n
Nodos en la nube<\/p>\n<\/li>\n
- \n
Contenedores<\/p>\n<\/li>\n
- \n
Conexiones de red<\/p>\n<\/li>\n
- \n
Artefactos de software implementados<\/p>\n<\/li>\n<\/ul>\n
Ejemplo:<\/p>\n
Dispositivo del cliente\r\n |\r\n v\r\nServidor web\r\n |\r\n v\r\nServidor de aplicaciones\r\n |\r\n v\r\nServidor de base de datos\r\n<\/code><\/pre>\nLos diagramas de implementaci\u00f3n ayudan a los arquitectos a comprender d\u00f3nde se ejecuta el software y c\u00f3mo se comunican los componentes de infraestructura.<\/p>\n
5. Diagrama de paquetes<\/h3>\n
![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab20b957188a.png\")
<\/p>\n
Un diagrama de paquetes organiza elementos de modelo relacionados en paquetes y muestra las dependencias entre esos paquetes.<\/p>\n
Un proyecto puede contener paquetes como:<\/p>\n
\n- \n
usuario<\/code><\/p>\n<\/li>\n- \n
cat\u00e1logo<\/code><\/p>\n<\/li>\n- \n
pedido<\/code><\/p>\n<\/li>\n- \n
pago<\/code><\/p>\n<\/li>\n- \n
notificaci\u00f3n<\/code><\/p>\n<\/li>\n<\/ul>\nEjemplo:<\/p>\n
pedido --> usuario\r\npedido --> cat\u00e1logo\r\npedido --> pago\r\npago --> notificaci\u00f3n\r\n<\/code><\/pre>\nLos diagramas de paquetes son \u00fatiles para:<\/p>\n
\n- \n
Organizar modelos grandes<\/p>\n<\/li>\n
- \n
Mostrar dependencias de m\u00f3dulos<\/p>\n<\/li>\n
- \n
Identificar capas arquitect\u00f3nicas<\/p>\n<\/li>\n
- \n
Prevenir acoplamiento no deseado<\/p>\n<\/li>\n<\/ul>\n
6. Diagrama de estructura compuesta<\/h3>\n
![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab20c22cef1c.png\")
<\/p>\n
Un diagrama de estructura compuesta muestra la estructura interna de una clase, componente u otro clasificador estructurado.<\/p>\n
Puede mostrar:<\/p>\n
\n- \n
Partes internas<\/p>\n<\/li>\n
- \n
Puertos<\/p>\n<\/li>\n
- \n
Conectores<\/p>\n<\/li>\n
- \n
Colaboraciones internas<\/p>\n<\/li>\n
- \n
Relaciones entre elementos internos<\/p>\n<\/li>\n<\/ul>\n
Por ejemplo, un OrderController<\/code> puede contener o conectarse a:<\/p>\n\n- \n
OrderService<\/code><\/p>\n<\/li>\n- \n
OrderRepository<\/code><\/p>\n<\/li>\n- \n
PaymentService<\/code><\/p>\n<\/li>\n- \n
NotificationService<\/code><\/p>\n<\/li>\n<\/ul>\nA diferencia de un diagrama de componentes, que generalmente se centra en componentes de alto nivel, un diagrama de estructura compuesta se centra en la organizaci\u00f3n interna de un clasificador.<\/p>\n
7. Diagrama de perfil<\/h3>\n
Un diagrama de perfil extiende UML para un dominio o tecnolog\u00eda particular. Define elementos de modelado especializados mediante estereotipos, valores etiquetados y restricciones.<\/p>\n
![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab20c916d97e.png\")
<\/p>\n
Por ejemplo, un perfil puede introducir estereotipos como:<\/p>\n
<<entity>>\r\n<<controller>>\r\n<<service>>\r\n<<microservice>>\r\n<\/code><\/pre>\nLos diagramas de perfil son \u00fatiles cuando la notaci\u00f3n est\u00e1ndar de UML debe adaptarse para:<\/p>\n
\n- \n
Aplicaciones web<\/p>\n<\/li>\n
- \n
Arquitectura empresarial<\/p>\n<\/li>\n
- \n
Sistemas en tiempo real<\/p>\n<\/li>\n
- \n
Sistemas embebidos<\/p>\n<\/li>\n
- \n
Marcos de programaci\u00f3n espec\u00edficos<\/p>\n<\/li>\n
- \n
Modelado espec\u00edfico de la industria<\/p>\n<\/li>\n<\/ul>\n
El diagrama de perfil a menudo se omite de las listas introductorias, pero est\u00e1 incluido entre los tipos de diagramas est\u00e1ndar de UML 2.x. UML 2.x se describe com\u00fanmente como teniendo siete tipos de diagramas estructurales y siete tipos de diagramas conductuales.<\/p>\n\n
Diagramas de comportamiento de UML<\/h2>\n
Los diagramas de comportamiento describen el comportamiento din\u00e1mico de un sistema. Muestran flujos de trabajo, eventos, interacciones, cambios de estado y respuestas.<\/p>\n
1. Diagrama de casos de uso<\/h3>\n
![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab20d2f4096e.png\")
<\/p>\n
Un diagrama de casos de uso presenta los requisitos funcionales de un sistema desde la perspectiva de actores externos.<\/p>\n
Un sistema t\u00edpico de compras en l\u00ednea puede incluir estos actores:<\/p>\n
\n- \n
Cliente<\/p>\n<\/li>\n
- \n
Administrador<\/p>\n<\/li>\n
- \n
Pasarela de pago<\/p>\n<\/li>\n
- \n
Servicio de entrega<\/p>\n<\/li>\n<\/ul>\n
Los posibles casos de uso incluyen:<\/p>\n
\n- \n
Registrar cuenta<\/p>\n<\/li>\n
- \n
Iniciar sesi\u00f3n<\/p>\n<\/li>\n
- \n
Navegar por los productos<\/p>\n<\/li>\n
- \n
A\u00f1adir producto al carrito<\/p>\n<\/li>\n
- \n
Realizar pedido<\/p>\n<\/li>\n
- \n
Realizar pago<\/p>\n<\/li>\n
- \n
Rastrear entrega<\/p>\n<\/li>\n
- \n
Gestionar productos<\/p>\n<\/li>\n<\/ul>\n
Un diagrama de casos de uso proporciona una visi\u00f3n general de lo que hace el sistema sin describir los detalles de implementaci\u00f3n.<\/p>\n
Las relaciones importantes incluyen:<\/p>\n
\n- \n
Asociaci\u00f3n:<\/strong>Conecta un actor con un caso de uso.<\/p>\n<\/li>\n- \n
Incluir:<\/strong>Muestra un comportamiento que siempre es reutilizado por otro caso de uso.<\/p>\n<\/li>\n- \n
Extender:<\/strong>Muestra un comportamiento opcional o condicional.<\/p>\n<\/li>\n- \n
Generalizaci\u00f3n:<\/strong>Muestra la especializaci\u00f3n entre actores o casos de uso.<\/p>\n<\/li>\n<\/ul>\nPor ejemplo, Realizar pedido<\/code> puede incluir Realizar pago<\/code>, mientras que Aplicar descuento<\/code> puede extender Realizar pedido<\/code>.<\/p>\n2. Diagrama de actividades<\/h3>\n
![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab20dc5ca277.png\")
<\/p>\n
Un diagrama de actividades representa el flujo de control en un proceso o caso de uso. Es \u00fatil para modelar flujos de trabajo secuenciales y concurrentes.<\/p>\n
Ejemplo: realizar un pedido<\/p>\n
Inicio\r\n |\r\nNavegar por productos\r\n |\r\nA\u00f1adir producto al carrito\r\n |\r\nProceder al pago\r\n |\r\nIntroducir datos de pago\r\n |\r\n\u00bfPago exitoso?\r\n \/ \r\nNo S\u00ed\r\n| |\r\nMostrar error Crear pedido\r\n |\r\n Enviar confirmaci\u00f3n\r\n |\r\n Fin\r\n<\/code><\/pre>\nLos diagramas de actividades pueden representar:<\/p>\n
\n- \n
Acciones<\/p>\n<\/li>\n
- \n
Decisiones<\/p>\n<\/li>\n
- \n
Fusiones<\/p>\n<\/li>\n
- \n
Bucles<\/p>\n<\/li>\n
- \n
Actividades paralelas<\/p>\n<\/li>\n
- \n
Nodos de inicio y fin<\/p>\n<\/li>\n
- \n
Carriles para responsabilidades<\/p>\n<\/li>\n<\/ul>\n
Los carriles pueden mostrar qu\u00e9 actor o componente del sistema realiza cada acci\u00f3n. Por ejemplo, un carril puede representar al cliente, otro al servicio de pedidos y otro a la pasarela de pago.<\/p>\n
3. Diagrama de secuencia<\/h3>\n
![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab210046c5e3.png\")
<\/p>\n
Un diagrama de secuencia muestra c\u00f3mo los objetos o componentes se comunican en una secuencia ordenada por tiempo.<\/p>\n
Ejemplo: realizar un pedido<\/p>\n
Cliente -> WebApp: Enviar pedido\r\nWebApp -> OrderService: createOrder()\r\nOrderService -> PaymentService: authorizePayment()\r\nPaymentService --> OrderService: paymentApproved\r\nOrderService -> NotificationService: sendConfirmation()\r\nOrderService --> WebApp: orderCreated\r\nWebApp --> Cliente: Mostrar confirmaci\u00f3n\r\n<\/code><\/pre>\nLos diagramas de secuencia contienen:<\/p>\n
\n- \n
Participantes<\/p>\n<\/li>\n
- \n
L\u00edneas de vida<\/p>\n<\/li>\n
- \n
Mensajes<\/p>\n<\/li>\n
- \n
Barras de activaci\u00f3n<\/p>\n<\/li>\n
- \n
Mensajes de retorno<\/p>\n<\/li>\n
- \n
Condiciones<\/p>\n<\/li>\n
- \n
Bucles<\/p>\n<\/li>\n
- \n
Alternativas<\/p>\n<\/li>\n
- \n
Interacciones paralelas<\/p>\n<\/li>\n<\/ul>\n
Son especialmente \u00fatiles para explicar llamadas a API, interacciones de servicios, flujos de autenticaci\u00f3n y manejo de errores.<\/p>\n
4. Diagrama de comunicaci\u00f3n<\/h3>\n
![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab2117c22363.png\")
<\/p>\n
Un diagrama de comunicaci\u00f3n, hist\u00f3ricamente llamado diagrama de colaboraci\u00f3n en versiones anteriores de UML, hace hincapi\u00e9 en las relaciones entre objetos y los mensajes intercambiados entre ellos.<\/p>\n
En lugar de centrarse principalmente en una l\u00ednea de tiempo vertical como un diagrama de secuencia, se centra en:<\/p>\n
\n- \n
Objetos<\/p>\n<\/li>\n
- \n
Enlaces entre objetos<\/p>\n<\/li>\n
- \n
Mensajes numerados<\/p>\n<\/li>\n
- \n
Estructura de colaboraci\u00f3n<\/p>\n<\/li>\n<\/ul>\n
Ejemplo:<\/p>\n
1: submitOrder()\r\nCliente ----------------> WebApp\r\n\r\n2: createOrder()\r\nWebApp ------------------> OrderService\r\n\r\n3: authorizePayment()\r\nOrderService -------------> PaymentService\r\n<\/code><\/pre>\nLos diagramas de comunicaci\u00f3n son \u00fatiles cuando la estructura de la colaboraci\u00f3n de objetos es m\u00e1s importante que la l\u00ednea de tiempo visual exacta.<\/p>\n
5. Diagrama de m\u00e1quina de estados<\/h3>\n
![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab211a9df7d4.png\")
<\/p>\n
Un diagrama de m\u00e1quina de estados muestra c\u00f3mo un objeto o sistema cambia de estado en respuesta a eventos.<\/p>\n
Un pedido puede pasar por los siguientes estados:<\/p>\n
Nuevo -> Pago pendiente -> Pagado -> Enviado -> Entregado\r\n |\r\n v\r\n Cancelado\r\n<\/code><\/pre>\nUna transici\u00f3n puede etiquetarse con un evento o condici\u00f3n:<\/p>\n
Pago pendiente -- pagoAprobado --> Pagado\r\nPago pendiente -- pagoFallido --> Pago fallido\r\n<\/code><\/pre>\nLos diagramas de m\u00e1quina de estados son \u00fatiles para:<\/p>\n
\n- \n
Ciclos de vida de pedidos<\/p>\n<\/li>\n
- \n
Estados de cuentas de usuario<\/p>\n<\/li>\n
- \n
Estado del flujo de trabajo<\/p>\n<\/li>\n
- \n
Comportamiento del dispositivo<\/p>\n<\/li>\n
- \n
Estados de conexi\u00f3n de red<\/p>\n<\/li>\n
- \n
Procesos de aprobaci\u00f3n<\/p>\n<\/li>\n<\/ul>\n
Son particularmente valiosos cuando el comportamiento de un objeto depende en gran medida de su estado actual.<\/p>\n
6. Diagrama de temporizaci\u00f3n<\/h3>\n
![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab212460dc5d.png\")
<\/p>\n
Un diagrama de temporizaci\u00f3n ilustra c\u00f3mo el estado o el valor de uno o m\u00e1s elementos cambia con el tiempo.<\/p>\n
A menudo se utiliza para:<\/p>\n
\n- \n
Sistemas en tiempo real<\/p>\n<\/li>\n
- \n
Sistemas embebidos<\/p>\n<\/li>\n
- \n
Protocolos de comunicaci\u00f3n<\/p>\n<\/li>\n
- \n
Coordinaci\u00f3n de hardware y software<\/p>\n<\/li>\n
- \n
Interacciones sensibles al rendimiento<\/p>\n<\/li>\n<\/ul>\n
Por ejemplo, un diagrama de temporizaci\u00f3n puede mostrar la relaci\u00f3n entre:<\/p>\n
\n- \n
Una se\u00f1al de dispositivo<\/p>\n<\/li>\n
- \n
Un estado del controlador<\/p>\n<\/li>\n
- \n
Un valor de sensor<\/p>\n<\/li>\n
- \n
Una respuesta durante un intervalo de tiempo definido<\/p>\n<\/li>\n<\/ul>\n
7. Diagrama de descripci\u00f3n general de interacciones<\/h3>\n
![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab212e16571d.png\")
<\/p>\n
Un diagrama de descripci\u00f3n general de interacciones proporciona una visi\u00f3n de alto nivel de las interacciones al combinar el flujo de control de estilo de actividad con diagramas de interacci\u00f3n.<\/p>\n
Puede mostrar:<\/p>\n
\n- \n
El orden de las interacciones principales<\/p>\n<\/li>\n
- \n
Decisiones entre fragmentos de interacci\u00f3n<\/p>\n<\/li>\n
- \n
Rutas de interacci\u00f3n paralelas<\/p>\n<\/li>\n
- \n
Referencias a diagramas de secuencia o de comunicaci\u00f3n<\/p>\n<\/li>\n<\/ul>\n
Por ejemplo, una descripci\u00f3n general de interacciones para un pedido en l\u00ednea podr\u00eda conectar:<\/p>\n
\n- \n
Autenticaci\u00f3n del cliente<\/p>\n<\/li>\n
- \n
Selecci\u00f3n de producto<\/p>\n<\/li>\n
- \n
Interacci\u00f3n de pago<\/p>\n<\/li>\n
- \n
Autorizaci\u00f3n de pago<\/p>\n<\/li>\n
- \n
Ejecuci\u00f3n del pedido<\/p>\n<\/li>\n<\/ol>\n
Este diagrama es \u00fatil cuando un proceso es demasiado complejo para explicarse con un solo diagrama de secuencia.<\/p>\n\n
Relaciones UML<\/h2>\n
Comprender las relaciones UML es esencial para crear diagramas significativos.<\/p>\n
![\"Tarjeta](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab21621a80f3.png\")
<\/p>\n
Asociaci\u00f3n<\/h3>\n
Una asociaci\u00f3n representa una conexi\u00f3n estructural entre dos elementos.<\/p>\n
Cliente -------- Pedido\r\n<\/code><\/pre>\nEsto indica que los clientes y los pedidos est\u00e1n relacionados.<\/p>\n
Asociaci\u00f3n dirigida<\/h3>\n
Una asociaci\u00f3n dirigida muestra la navegabilidad en una direcci\u00f3n.<\/p>\n
Pedido ------> Pago\r\n<\/code><\/pre>\nEsto sugiere que un pedido conoce o utiliza un objeto de pago, mientras que lo contrario puede no ser cierto.<\/p>\n
Generalizaci\u00f3n<\/h3>\n
La generalizaci\u00f3n representa la herencia o la especializaci\u00f3n.<\/p>\n
Usuario\n \/ \nCliente Administrador\n<\/code><\/pre>\nAqu\u00ed, Cliente<\/code> y Administrador<\/code> son tipos especializados de Usuario<\/code>.<\/p>\nDependencia<\/h3>\n
Una dependencia indica que un elemento utiliza o depende temporalmente de otro.<\/p>\n
OrderService - - - -> PaymentGateway\n<\/code><\/pre>\nUn cambio en la pasarela de pago puede afectar al servicio de pedidos.<\/p>\n
Agregaci\u00f3n<\/h3>\n
La agregaci\u00f3n representa una relaci\u00f3n todo-parte en la que las partes pueden existir de forma independiente.<\/p>\n
Equipo \u25c7------ Jugador\n<\/code><\/pre>\nUn jugador puede seguir existiendo incluso si el equipo se disuelve.<\/p>\n
Composici\u00f3n<\/h3>\n
La composici\u00f3n representa una relaci\u00f3n todo-parte fuerte. Las partes generalmente dependen del todo para su ciclo de vida.<\/p>\n
Pedido \u25c6------ \u00cdtem de pedido\n<\/code><\/pre>\nUn \u00cdtem de pedido<\/code>puede considerarse parte de un pedido y puede no tener significado fuera de ese pedido.<\/p>\nRealizaci\u00f3n<\/h3>\n
La realizaci\u00f3n indica que una clase o componente implementa una interfaz.<\/p>\n
PaymentService - - -|> PaymentProcessor\n<\/code><\/pre>\nEl PaymentService<\/code> proporciona el comportamiento definido por el “\"PaymentProcessor\"<\/code> interfaz.<\/p>\nEjemplo UML: Sistema de compras en l\u00ednea<\/h2>\n
Considere una aplicaci\u00f3n de compras en l\u00ednea.<\/p>\n
Actores principales<\/h3>\n\n- \n
Cliente<\/p>\n<\/li>\n
- \n
Administrador<\/p>\n<\/li>\n
- \n
Pasarela de pago<\/p>\n<\/li>\n
- \n
Servicio de entrega<\/p>\n<\/li>\n<\/ul>\n
Casos de uso principales<\/h3>\n\n- \n
Crear cuenta<\/p>\n<\/li>\n
- \n
Navegar por los productos<\/p>\n<\/li>\n
- \n
Agregar art\u00edculos al carrito<\/p>\n<\/li>\n
- \n
Realizar pedido<\/p>\n<\/li>\n
- \n
Realizar pago<\/p>\n<\/li>\n
- \n
Rastrear entrega<\/p>\n<\/li>\n
- \n
Gestionar inventario<\/p>\n<\/li>\n<\/ul>\n
Clases posibles<\/h3>\nCliente\nProducto\nCarrito de compras\nArt\u00edculo del carrito\nPedido\nArt\u00edculo del pedido\nPago\nEnv\u00edo\n<\/code><\/pre>\nComponentes de servicio posibles<\/h3>\nServicio de usuario\nServicio de cat\u00e1logo\nServicio de carrito\nServicio de pedidos\nServicio de pago\nServicio de env\u00edo\nServicio de notificaci\u00f3n\n<\/code><\/pre>\nEjemplo de interacci\u00f3n<\/h3>\n
Cuando un cliente realiza un pedido:<\/p>\n
\n- \n
El cliente env\u00eda el carrito.<\/p>\n<\/li>\n
- \n
La aplicaci\u00f3n web env\u00eda la solicitud al servicio de pedidos.<\/p>\n<\/li>\n
- \n
El servicio de pedidos valida los art\u00edculos.<\/p>\n<\/li>\n
- \n
El servicio de pago autoriza el pago.<\/p>\n<\/li>\n
- \n
El pedido se guarda.<\/p>\n<\/li>\n
- \n
El servicio de env\u00edo es notificado.<\/p>\n<\/li>\n
- \n
El servicio de notificaciones env\u00eda un correo electr\u00f3nico de confirmaci\u00f3n.<\/p>\n<\/li>\n<\/ol>\n
Este \u00fanico proceso de negocio puede representarse mediante varios diagramas UML:<\/p>\n
\n- \n
Diagrama de casos de uso: Muestra que el cliente puede realizar un pedido.<\/p>\n<\/li>\n
- \n
Diagrama de actividades: Muestra el flujo de trabajo y los puntos de decisi\u00f3n.<\/p>\n<\/li>\n
- \n
Diagrama de secuencia: Muestra los mensajes entre servicios.<\/p>\n<\/li>\n
- \n
Diagrama de clases: Muestra Cliente<\/code>, Pedido<\/code>, Producto<\/code>, y las clases relacionadas.<\/p>\n<\/li>\n- \n
Diagrama de componentes: Muestra los servicios involucrados.<\/p>\n<\/li>\n
- \n
Diagrama de implementaci\u00f3n: Muestra d\u00f3nde se ejecutan esos servicios.<\/p>\n<\/li>\n<\/ul>\n
C\u00f3mo elegir el diagrama UML adecuado<\/h2>\n
\n\n\n| Objetivo del modelado<\/th>\n | Diagrama UML recomendado<\/th>\n<\/tr>\n<\/thead>\n |
\n\n| Mostrar clases y sus relaciones<\/td>\n | Diagrama de clases<\/td>\n<\/tr>\n |
\n| Mostrar instancias reales de objetos<\/td>\n | Diagrama de objetos<\/td>\n<\/tr>\n |
\n| Describir la funcionalidad del sistema<\/td>\n | Diagrama de casos de uso<\/td>\n<\/tr>\n |
\n| Modelar un flujo de trabajo de negocio o del sistema<\/td>\n | Diagrama de actividades<\/td>\n<\/tr>\n |
\n| Mostrar mensajes intercambiados a lo largo del tiempo<\/td>\n | Diagrama de secuencia<\/td>\n<\/tr>\n |
\n| Mostrar la colaboraci\u00f3n de objetos<\/td>\n | Diagrama de comunicaci\u00f3n<\/td>\n<\/tr>\n |
\n| Mostrar el ciclo de vida y los cambios de estado<\/td>\n | Diagrama de m\u00e1quina de estados<\/td>\n<\/tr>\n |
\n| Mostrar m\u00f3dulos de software o servicios<\/td>\n | Diagrama de componentes<\/td>\n<\/tr>\n |
\n| Mostrar el despliegue f\u00edsico<\/td>\n | Diagrama de despliegue<\/td>\n<\/tr>\n |
\n| Organizar elementos del modelo<\/td>\n | Diagrama de paquetes<\/td>\n<\/tr>\n |
\n| Mostrar las partes internas de un clasificador<\/td>\n | Diagrama de estructura compuesta<\/td>\n<\/tr>\n |
\n| Mostrar cambios a lo largo del tiempo<\/td>\n | Diagrama de temporizaci\u00f3n<\/td>\n<\/tr>\n |
\n| Resumir varias interacciones<\/td>\n | Diagrama de visi\u00f3n general de interacciones<\/td>\n<\/tr>\n |
\n| Extender UML para un dominio especializado<\/td>\n | Diagrama de perfil<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n |
![\"Infograf\u00eda](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab1fa751c62a.png\")
<\/p>\n![\"Tarjeta](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab1faf9214ab.png\")
<\/p>\n![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab1fb215dd30.png\")
<\/p>\n![\"Diagrama](\"https:\/\/www.cybermedian.com\/wp-content\/uploads\/2026\/09\/img_6ab20984afccd.png\")
<\/p>\n