PROGRAMACIÓN AVANZADA¿Qué necesita gestionar «La Viñeta»?
Imagina una tienda barrial de cómics en Montevideo. Vende historietas, mangas y novelas gráficas. Cada compra se registra como una venta, asociada a un cliente y a uno o varios productos.
Cliente
Se identifica por su cédula y tiene nombre y correo.
Producto
Tiene código, nombre, precio de venta y stock.
Venta
Tiene número y fecha. Puede incluir varios productos y cantidades distintas.
Ejemplo: la venta n.º 104 registra para una misma clienta dos unidades de «Historias del Río» a $390 cada una y un ejemplar de «Manga Sur» a $520. Son dos renglones de venta, aunque se facturen en una sola operación.
Qué hacemos en el análisis orientado a objetos
El análisis OO describe los conceptos relevantes del problema y sus relaciones. Todavía no decide qué constructor tendrá una clase Java, cómo se guardarán los datos ni qué ventana se utilizará.
¿Por qué no empezar directamente por una clase Java?
Porque escribir atributos y métodos antes de entender las relaciones puede llevarnos a un modelo que no representa bien el negocio. Primero estudiamos qué ocurre; después decidimos cómo lo programamos.
El modelo conceptual de la tienda
Este es el primer diagrama que proporcionaste. Léelo como un mapa de los conceptos del negocio, no como una receta para programar.
Leer UML sin confundir análisis con código
Cliente — Venta
Una venta se registra para un cliente. Que el diagrama muestre una asociación no define por sí solo cuántas ventas puede tener cada cliente: faltan multiplicidades.
Venta — Producto
Una venta puede incluir distintos productos. Para describir cada participación necesitamos los datos cantidad y precioUnitario.
¿Qué significa la línea discontinua hacia DetalleVenta?
En el diagrama conceptual, DetalleVenta se representa como una clase de asociación: sus atributos pertenecen a una ocurrencia de la relación entre una venta y un producto. Esta es una idea conceptual valiosa, aunque al programar puede convenir representarla mediante objetos y referencias explícitas.
¿Qué no podemos concluir aún?
No se indican multiplicidades (1, 0..*, etc.) ni todas las reglas de negocio. Por tanto, no afirmamos que el dibujo ya resuelva si una venta admite productos repetidos, si puede quedar vacía o cómo se aplica una devolución.
Del modelo conceptual al modelo de diseño
El segundo diagrama que proporcionaste añade tipos y atributos pensando en la implementación. Ya aparecen decisiones propias del diseño OO: identificadores, tipos Java y referencias entre clases.
| Concepto | En el diagrama de diseño | Qué significa programando |
|---|---|---|
| Cliente | cedula: long, nombre: String, correo: String | Definir el estado de cada cliente. |
| Venta | numero: int, fecha: Date, cliente: Cliente, detalle como lista | Asociar cada objeto Venta con un Cliente y con sus renglones. |
| DetalleVenta | producto: Producto, cantidad: int, precioUnitario: double | Crear un objeto por renglón con referencia al producto. |
| Producto | codigo: long, nombre: String, precio: double, stock: int | Representar los artículos del catálogo. |
Qué decisiones debemos tomar antes de codificar
Los rombos del diagrama
En UML, el rombo blanco se utiliza para expresar una agregación compartida. En el diagrama aportado aparece en varias asociaciones. Conviene discutir si esas relaciones realmente representan agregación o si alguna debería modelarse como asociación simple. No cambiaremos el dibujo sin analizarlo.
La lista de detalles
La anotación DetalleVenta(lista) comunica una colección, pero todavía debemos decidir su tipo de implementación: por ejemplo, List<DetalleVenta> en Java.
Multiplicidades
Sería conveniente documentar si una Venta tiene uno o varios detalles y si un Producto puede intervenir en muchas ventas. La intención de negocio se comprende; la cardinalidad exacta debe explicitarse.
Datos y tipos
El diagrama usa double para precios y Date para fechas. Los conservamos para respetar el modelo inicial; más adelante podemos estudiar alternativas como BigDecimal y LocalDate.
Cómo comienza a verse el diseño en código
Sin construir todavía todo el programa, podemos escribir una versión mínima que muestre la diferencia entre una clase y una relación entre objetos.
public class DetalleVenta {
private Producto producto;
private int cantidad;
private double precioUnitario;
public DetalleVenta(Producto producto,
int cantidad, double precioUnitario) {
this.producto = producto;
this.cantidad = cantidad;
this.precioUnitario = precioUnitario;
}
}El atributo producto es una referencia a otro objeto. La cantidad no se coloca dentro de Producto, porque el mismo artículo puede venderse en cantidades distintas en operaciones diferentes.
import java.util.ArrayList;
import java.util.List;
public class Venta {
private int numero;
private Cliente cliente;
private List<DetalleVenta> detalles = new ArrayList<>();
}Este fragmento introduce la posibilidad de implementar la asociación con una colección. No completa las reglas del negocio, constructores ni operaciones; esas decisiones aparecerán en las lecciones siguientes.
Dos diagramas, dos momentos distintos
Modelo conceptual
Explica qué entidades son relevantes, qué relaciones existen y qué información pertenece a cada una.
Pregunta: «¿Qué necesitamos representar?»
Modelo de diseño
Decide cómo organizar clases, atributos, tipos y referencias para construir el programa.
Pregunta: «¿Cómo lo representaremos en Java?»
Comprobación rápida
¿Dónde debería almacenarse la cantidad de unidades compradas en una venta específica?
Explora, aprende, crea.