Między dwoma elementami istnieje zależność, jeśli zmiany definicji jednego elementu mogą spowodować zmiany drugiego. W wypadku klas zależności istnieją z wielu powodów — jedna klasa wysyła komunikat do drugiej; jedna klasa zawiera drugą jako część swoich danych; jedna klasa wymienia drugą jako parametr operacji. Jeśli interfejs klasy ulega zmianie, to komunikat przez nią wysiany nie musi być poprawny.
Projektowanie systemów informatycznych, wykład 2
Kolejna kwestia dotycząca uszczegółowiania diagramów klas dotyczy specyfikacji zależności. Wraz z rozrostem systemów komputerowych należy coraz więcej uwagi poświęcać zależnościom. Jeśli wymkną się one spod kontroli, to każda zmiana w systemie może mieć na niego duży wpływ i zmuszać do wprowadzania kolejnych modyfikacji. Im większy błąd, tym trudniej będzie cokolwiek zmienić.
UML pozwala na uwidocznienie zależności między wszystkimi rodzajami elementów. Zależności używa się zawsze wtedy, gdy trzeba pokazać, jak zmiany w jednym elemencie mogą wpłynąć na inne elementy.
Na slajdzie zaprezentowano rysunek gdzie pokazane są pewne zależności, które można by było spotkać w wielowarstwowej aplikacji. Klasa Okno korzyści (interfejs użytkownika lub inaczej klasa prezentacji) jest zależna od klasy Pracownik — głównego obiektu, który przechwytuje najważniejsze zachowania systemu, w tym wypadku zdarzenia zachodzące w firmie. Oznacza to, że jeśli klasa Pracownik zmieni swój interfejs, to być może trzeba będzie też zmienić klasę Okno korzyści.
Ważne w tej sytuacji jest to, że zależność jest jednokierunkowa i przechodzi od klasy prezentacji do klasy głównej. Dzięki temu wiadomo, że można swobodnie modyfikować klasę Okno korzyści i zmiany te nie będą miały żadnego wpływu na obiekty klasy Pracownik lub inne obiekty główne. Ścisłe rozdzielenie logiki prezentacji od głównej logiki systemu, gdy prezentacja zależy od części głównej, ale nie na odwrót, jest bardzo korzystną regułą i warto ją stosować.
Drugą rzeczą godną uwagi na slajdzie jest to, że nie istnieje bezpośrednia zależność między klasą Okno korzyści a dwiema klasami Bramek danych. Jeśli zmienią się te klasy, to może zajść potrzeba zmodyfikowania klasy Pracownik. Jeśli jednak zmiana dotyczy tylko implementacji klasy Pracownik, a nie jej interfejsu, to na tym zmiany się kończą.
20