\n
![\"Hoja](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195e127973c.png\")
<\/p>\n
Parte 1: Los Elementos B\u00e1sicos (Sintaxis y Leyenda)<\/h2>\n
Antes de adentrarnos en el estudio de caso, debemos establecer el vocabulario utilizado en los diagramas UML.<\/p>\n
1. Estructura de la Clase y Visibilidad<\/h3>\n
Una clase se representa mediante un rect\u00e1ngulo dividido en tres compartimentos:<\/p>\n
- \n
- \n
Superior:<\/strong>Nombre de la Clase (por ejemplo,
FlightBooking<\/code>).<\/p>\n<\/li>\n- \n
Medio:<\/strong>Propiedades\/Atributos (por ejemplo,
+ nombrePropiedad: String<\/code>).<\/p>\n<\/li>\n- \n
Inferior:<\/strong>M\u00e9todos\/Operaciones (por ejemplo,
+ isActive(): boolean<\/code>).<\/p>\n<\/li>\n<\/ul>\nModificadores de Visibilidad:<\/strong><\/p>\n
- \n
- \n
+<\/code>\u00a0P\u00fablico:<\/strong>Accesible por cualquier otra clase.<\/p>\n<\/li>\n- \n
-<\/code>\u00a0Privado:<\/strong>Accesible \u00fanicamente dentro de la clase.<\/p>\n<\/li>\n- \n
#<\/code>\u00a0Protegido:<\/strong>\u00a0Accesible dentro de la clase y sus subclases.<\/p>\n<\/li>\n- \n
~<\/code>\u00a0Paquete:<\/strong>\u00a0Accesible solo dentro del mismo paquete.<\/p>\n<\/li>\n<\/ul>\n2. Tipos especiales de clases<\/h3>\n
- \n
- \n
Interfaces (
<<interface>><\/code>):<\/strong>\u00a0Contratos que definen m\u00e9todos sin implementaci\u00f3n. Representados por un cuadro verde (en esta hoja de trucos) o notaci\u00f3n est\u00e1ndar.<\/p>\n- \n
- \n
Ejemplo:<\/em>\u00a0
UserRepo<\/code>\u00a0con\u00a0+ method(): void<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Clases abstractas (
<<abstract>><\/code>):<\/strong>\u00a0Clases base que no pueden instanciarse directamente. Pueden contener m\u00e9todos abstractos.<\/p>\n- \n
- \n
Ejemplo:<\/em>\u00a0
Componente<\/code>\u00a0con\u00a0+ render(): void \/\/ abstract<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Enumeraciones:<\/strong>\u00a0Un conjunto de constantes nombradas.<\/p>\n
- \n
- \n
Ejemplo:<\/em>\u00a0
JobStatus<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\nEjemplo de diagrama de clases del sistema de pedidos<\/h2>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195f79a1fa7.png\")
<\/p>\n\u00a0<\/p>\n
@startuml
\nskinparam classAttributeIconSize 0
\nskinparam shadowing false<\/p>\n\u2018 \u2014 INTERFACES \u2014
\ninterface PasarelaDePago {
\n+ procesar(monto: double): boolean
\n}<\/p>\n\u2018 \u2014 CLASES ABSTRACTAS \u2014
\nclase abstracta Pedido {
\n# idPedido: String
\n# montoTotal: double
\n+ {abstract} calcularImpuesto(): double
\n+ obtenerResumen(): String
\n}<\/p>\n\u2018 \u2014 CLASES \u2014
\nclase PedidoFisico {
\n\u2013 pesoEnvio: double
\n+ calcularImpuesto(): double
\n}<\/p>\nclase PedidoDigital {
\n\u2013 enlaceDescarga: String
\n+ calcularImpuesto(): double
\n}<\/p>\nclase ItemPedido {
\n\u2013 nombreProducto: String
\n\u2013 precio: double
\n\u2013 cantidad: int
\n}<\/p>\nclase PasarelaPayPal {
\n+ procesar(monto: double): boolean
\n}<\/p>\n\u2018 \u2014 RELACIONES \u2014’
\nOrder <|\u2013 PhysicalOrder
\nOrder <|\u2013 DigitalOrder<\/p>\nOrder *\u2013 \u201c1..*\u201d OrderItem : contiene
\nOrder ..> PaymentGateway : utiliza<\/p>\nPaymentGateway <|.. PayPalGateway<\/p>\n
@enduml<\/p>\n
\nParte 2: Relaciones y Multiplicidad<\/h2>\n
Las l\u00edneas que conectan las clases definen c\u00f3mo interact\u00faan.<\/p>\n
1. Tipos de Asociaci\u00f3n<\/h3>\n
- \n
- \n
Herencia (Generalizaci\u00f3n):<\/strong>L\u00ednea s\u00f3lida con un tri\u00e1ngulo hueco. Relaci\u00f3n de \u201ces-un\u201d.<\/p>\n
- \n
- \n
Ejemplo:<\/em>\u00a0
Coche<\/code>\u00a0y\u00a0Motocicleta<\/code>\u00a0heredan de\u00a0Veh\u00edculo<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Implementaci\u00f3n:<\/strong>L\u00ednea discontinua con un tri\u00e1ngulo hueco. Una clase cumple un contrato de interfaz.<\/p>\n
- \n
- \n
Ejemplo:<\/em>\u00a0
Coche<\/code>\u00a0implementa\u00a0Conducible<\/code>.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Composici\u00f3n (Propiedad Fuerte):<\/strong>L\u00ednea s\u00f3lida con un\u00a0rombo relleno<\/strong>. La \u201cparte\u201d no puede existir sin el \u201ctodo.\u201d<\/p>\n
- \n
- \n
Ejemplo:<\/em>\u00a0
Restaurante<\/code> (Todo) poseeMen\u00fa<\/code> (Parte). Si el restaurante cierra, el men\u00fa desaparece.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Agregaci\u00f3n:<\/strong> L\u00ednea s\u00f3lida con un rombo hueco<\/strong>. Una relaci\u00f3n de \u201ctiene-a\u201d donde las partes pueden existir de forma independiente.<\/p>\n
- \n
- \n
Ejemplo:<\/em>\u00a0
Pedido<\/code> que agregaRestaurante<\/code> (El restaurante existe incluso si el pedido se elimina).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n2. Leyenda de multiplicidad<\/h3>\n
Los n\u00fameros en los extremos de las l\u00edneas indican la cardinalidad:<\/p>\n
- \n
- \n
1<\/code>: Exactamente uno.<\/p>\n<\/li>\n- \n
0..1<\/code>: Cero o uno (Opcional).<\/p>\n<\/li>\n- \n
1..*<\/code>: Uno o m\u00e1s (Lista obligatoria).<\/p>\n<\/li>\n- \n
*<\/code>: Muchos (Cero o m\u00e1s).<\/p>\n<\/li>\n<\/ul>\nLos conceptos de herencia, implementaci\u00f3n, composici\u00f3n y agregaci\u00f3n. Ejemplo<\/h3>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a19600180d6b.png\")
<\/p>\n\n@startuml<\/div>\n\u2018 Interfaces y clases base<\/div>\ninterface Drivable {<\/div>\n+ drive()<\/div>\n}<\/div>\nclase abstracta Vehicle {<\/div>\n+ startEngine()<\/div>\n}<\/div>\n\u2018 Clases<\/div>\nclass Car {<\/div>\n}<\/div>\nclass Motorcycle {<\/div>\n}<\/div>\nclass Restaurant {<\/div>\n\u2013 name: String<\/div>\n}<\/div>\nclass Menu {<\/div>\n}<\/div>\nclass Order {<\/div>\n}<\/div>\n\u2018 Relaciones<\/div>\n\u2018 1. Herencia (Generalizaci\u00f3n)<\/div>\nVehicle <|\u2013 Car<\/div>\nVehicle <|\u2013 Motorcycle<\/div>\n\u2018 2. Implementaci\u00f3n<\/div>\nDrivable <|.. Car<\/div>\n\u2018 3. Composici\u00f3n (Propiedad fuerte)<\/div>\nRestaurant *\u2013 Menu : posee<\/div>\n\u2018 4. Agregaci\u00f3n<\/div>\nOrder o\u2013 Restaurant : involucra<\/div>\n\u2018 Ejemplos de multiplicidad<\/div>\n\u2018 Restaurant tiene uno o muchos Men\u00fas (1..*)<\/div>\n\u2018 Order involucra cero o un Restaurant (0..1)<\/div>\nRestaurant \u201c1\u201d *\u2013 \u201c1..*\u201d Menu<\/div>\nPedido “1” o\u2013 “0..1” Restaurante<\/div>\n@enduml<\/div>\n<\/div>\n
\nParte 3: Estudio de caso del mundo real: Plataforma unificada de entrega de alimentos<\/h2>\n
Esta secci\u00f3n analiza el diagrama central de la hoja de trucos, desglosando la arquitectura de una aplicaci\u00f3n de entrega de alimentos.<\/p>\n
1. La jerarqu\u00eda de usuarios (Herencia y composici\u00f3n)<\/h3>\n
El sistema comienza con una clase gen\u00e9rica Usuario<\/strong> clase, marcada como Abstracta<\/strong>. Esto asegura que no se creen objetos gen\u00e9ricos de “Usuario”, solo tipos espec\u00edficos.<\/p>\n
- \n
- \n
Herencia:<\/strong>\u00a0
Cliente<\/code> yRepartidor<\/code> extiendenUsuario<\/code>.<\/p>\n<\/li>\n- \n
Composici\u00f3n:<\/strong><\/p>\n
- \n
- \n
Cliente<\/code> tiene unDirecci\u00f3n de env\u00edo<\/code> (Propiedad fuerte).<\/p>\n<\/li>\n- \n
Repartidor<\/code> tieneDetalles del veh\u00edculo<\/code> (Propiedad fuerte).<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n2. El ecosistema de restaurantes y men\u00fas<\/h3>\n
Esta secci\u00f3n demuestra anidamiento profundo y colecciones.<\/p>\n
- \n
- \n
Implementaci\u00f3n de interfaz:<\/strong>\u00a0
Restaurante<\/code> implementa<<interface>> Localizable<\/code>, asegurando que cada restaurante tenga datos de ubicaci\u00f3n.<\/p>\n<\/li>\n- \n
Cadena de composici\u00f3n:<\/strong><\/p>\n
- \n
- \n
Restaurante<\/code> (1) posee fuertementeMen\u00fa<\/code>\u00a0(1).<\/p>\n<\/li>\n- \n
Men\u00fa<\/code> contieneCategor\u00eda de men\u00fa<\/code>\u00a0(1..*).<\/p>\n<\/li>\n- \n
Categor\u00eda de men\u00fa<\/code> contieneElemento de men\u00fa<\/code>\u00a0(*).<\/p>\n<\/li>\n- \n
Nota:<\/em> Esta estructura garantiza que un elemento de men\u00fa no puede existir sin una categor\u00eda, y que una categor\u00eda no puede existir sin un men\u00fa.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
3. Procesamiento de pedidos y pagos<\/h3>\n
- \n
- \n
Estructura del pedido:<\/strong><\/p>\n
- \n
- \n
Pedido<\/code> tiene una relaci\u00f3n conRestaurante<\/code> (Agregaci\u00f3n).<\/p>\n<\/li>\n- \n
Pedido<\/code> posee fuertementeL\u00ednea de pedido<\/code>\u00a0(1..*).<\/p>\n<\/li>\n- \n
Pedido<\/code> tiene unPago<\/code> (0..1), lo que indica que el pago es opcional durante la fase inicial de creaci\u00f3n.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n- \n
Estrategia de Pago (Polimorfismo):<\/strong><\/p>\n
- \n
- \n
El sistema utiliza una interfaz
<<interface>> ProcesadorDePago<\/code>.<\/p>\n<\/li>\n- \n
Clases concretas
StripeProcessor<\/code> yPayPalProcessor<\/code> implementan esta interfaz. Esto permite al sistema cambiar de pasarelas de pago sin modificar el n\u00facleoPedido<\/code> l\u00f3gica.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n4. Clase abstracta vs. Interfaz (El ejemplo del veh\u00edculo)<\/h3>\n
La esquina superior derecha de la hoja de trucos aclara una confusi\u00f3n com\u00fan:<\/p>\n
- \n
- \n
Clase abstracta (
Veh\u00edculo<\/code>):<\/strong>\u00a0Coche<\/code> yMoto<\/code> heredan deVeh\u00edculo<\/code>. Esto implica que comparten datos\/estructura central (por ejemplo,tipoDeMotor<\/code>,\u00a0ruedas<\/code>).<\/p>\n<\/li>\n- \n
Interfaz (
Conducible<\/code>):<\/strong>\u00a0coche<\/code> implementaconducible<\/code>. Esto implicacoche<\/code> tiene un comportamiento espec\u00edfico (conducir()<\/code>) queMoto<\/code> podr\u00eda no tener (o podr\u00eda implementarlo de forma diferente).<\/p>\n<\/li>\n<\/ul>\n
\nParte 4: Visualizaci\u00f3n con PlantUML<\/h2>\n
A continuaci\u00f3n se muestra el c\u00f3digo PlantUML para generar la estructura central de la \u00abPlataforma Unificada de Entrega de Alimentos\u00bb descrita en el estudio de caso. Puedes copiar esto en cualquier editor de PlantUML para ver el diagrama.<\/p>\n
![\"\"](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a195d5d056af.png\")
<\/p>\n\n\nPlantUML<\/span> - \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n