Cita: Solo entiendo lo que explicas de la "agregacion" si una Entidad (ya sea Cliente o Proveedor) puede tener varios Usuarios (y sino grave porque no entendi nada)
Exactamente. Una agregación implica, si mal no recuerdo, clases que se relacionan porque se "agregan" a a otra, pero sin perder su identidad ni responsabilidades. en cambio la composición es una atomización que requiere forzosamente de otros objetos para crear la entidad que realmente se usa.
Creo que este es un ejemplo:
Puntualmente, si se da que un Cliente o un Proveedor puede poseer varios usernames, que se usan para administrar diferentes tipos de gestiones a los que puede acceder, se da el caso de la agregación porque existe una cardinalidad 1:N.
¿En qué casos se da esto en la realidad?
Bueno, un ejemplo es cuando una sucursal de una empresa tiene N vendedores, y todos responden a un mismo Jefe de Ventas. El sistema de ventas se activa (login de gestión global) por el Jefe de Ventas, pero cada venta de cada vendedor se inicia con el username y password de ese mismo vendedor. Todos existen en el sistema, pero no todos acceden a lo mismo.
Sin duda habrás visto al ir a este tipo de negocios que cada vendedor hace un login propio... ¿no?
Bueno, trabajan con un sistema de relaciones de jerarquía padre/hijo en los vendedores, y al mismo tiempo cada vendedor tiene asociado un único perfil. El perfil
compone al vendedor, y el vendedor
agrega al jefe.
Son sistemas algo complejos y difíciles de describir (trabajo en una empresa con algo parecido, pero muuuucho más enredado :P).
Como notarás, cuando empiezas a escarbar en el sistema, empiezan a aparecer cosas, conceptualizaciones algo enredadas. Todo esto es invisible (transparente) al usuario. Solamente las vemos del lado de los desarrolladores.
Que nos disculpe @juangemelo01, espero que no nos estemos yendo demasiado de tema :D