Måden objekterne kommunikerer med hinanden afviger ikke meget i de forskellige use-cases. Derfor er her nogle repræsentive eksempler på hvordan det foregår.
Vi har tilpasset måden sekvensdiagrammer tegnes på lidt, for bedre at kunne illustrere hvordan MAOV-systemet kommunikerer internt imellem sine objekter. Vi følger dog de grundlæggende regler. Hvert objekt har sin egen lodrette linje, men navn i toppen, og stimuli er vandrette linjer med pile der viser hvem der kalder hvem. De såkaldte "system-borders" er eksterne brugere af systemet der kommunikerer direkte.
Det er ikke alle objekterne der er oprettet hele tiden, så derfor vil vi gerne vise hvornår de forskellige objekter bliver oprettet. Når et objekt ikke er oprettet vises den tilhørende lodrette linje ikke.
MAOV-systemet er implementeret i Java uden brug af tråde (multi-threading) internt i systemet, så der er kun eet objekt der kan udføre noget ad gangen. Når et objekt kalder et andet, venter det på at det andet returnere. Vi vil derfor gerne vise hvem det venter på hvem. Selvom et objekt venter, kan andre objekter dog stadig kalde andre metoder i det ventende objekt, så også det skal kunne vises.
Der er ikke plads til at skrive alle argumenterne på stimuli-linierne, så derfor er alle værdierne vist i kasser under sekvensdiagrammet med et navn (eks. arg1) der henviser til hvilke argumenter der hører til hvilket kald.
Dette er ikke en use-case, men det er relevant at vise hvordan MAOVAdapteren's eneste reelle bruger (PtG) kommunikerer med MAOVAdapteren, og ikke mindst hvordan den opretter en ny Adapter. Det er nemlig ikke bare at køre en constructor (hvad det jo heller ikke er i en Applet).
Denne use-case starter før brugeren har fundet en kunde, og ender med at brugeren har fundet en kunde, som man så kan manøvrere videre i systemet med. Der er tre faser, der hver svarer til at systemet genererer en side. Den midterste kan springes over, idet det er den side der genereres når en bruger vil søge efter en kunde, og har indtastet en søge-streng. Man kan altså hoppe direkte fra den første fase til den tredje fase, eller gå alle tre igennem.
For at komme hertil skal man have fundet en kunde. Derefter hentes data om TARs fra databasen, men kun for den kunde. Når brugeren senere vil se flere detaljer om en enkelt TAR (anden fase), er data allerede hentet fra databasen, og hentes derfor bare fra entitets-objektet (TARsData). Hvis brugeren vælger en anden kunde og vil se TAR's for den, oprettes et nyt TARsData-objekt, og det gamle destrueres af garbage-collectoren.