Hola Rodrigo:

Esta segunda versión de los diagramas se ve mejor pero sigue habiendo algunos inconvenientes.

En primer lugar, el diagrama de clases sigue mostrando muy poca información. Recordá que cada caja debería estar dividia en tres secciones horizontales, una para el nombre, otra para los atributos y otra para los métodos. Como mencionaba antes (y como también dice Martin Fowler), no es necesario que detalles absolutamente todo, pero tampoco está bien que no muestres absolutamente nada. Deberías incluir por lo menos algún método en cada clase (los que usás en el diagrama de secuencia, por ejemplo) como para que se entienda la responsabilidad principal de la clase en tu modelo. En especial,  si aparece en tu modelo la relación de herencia es porque debés tener algún motivo muy válido para usarla y debe quedar evidenciado.

Revisá también los rombos de las agregaciones que hay algunos que están al revés.

Hay algunos métodos en el diagrama de secuencia que no son lo suficientemente descriptivos (por ejemplo "calcular" y "total").

Hay un error en la primera caja de iteración. Estás iterando por cada compra, luego por cada producto y luego por cada descuento y en cada caso preguntás un precio pero nunca hacés una suma. De manera tal que cuando termine la iteración solamente vas a tener el último precio dado que no guardaste los anteriores. El lugar en donde pongas esa suma es importante para saber si estás violando o no el principio "Tell, don't ask". A juzgar por el nombre del mensaje que Producto le envía a DescuentoRegular, da la sensación que violás el encapsulamiento. Ese mensaje se llama "calcular()" y no lleva ningún parámetro. ¿Cómo va a hacer el Descuento para calcular algo si no recibe nada con lo que tenga calcular? ¿Será que es un simple getter y el cálculo se realiza en otra clase? En cualquiera de los casos el modelo no sería adecuado.

Saludos,

Tomás