Akademia UML

W tym dziale publikujemy cykl artykułów poświęconych modelowaniu w języku UML, przygotowany dla czasopisma Software Developer's Journal. Skupiamy się w nich nie na niuansach notacji UML, lecz na zasadach poprawnego modelowania, tzn. odzwierciedlania rzeczywistości biznesowej.

Czy da się stworzyć diagram klas, który będzie na tyle szczegółowy, że na jego podstawie programiści stworzą kod systemu, a jednocześnie zrozumiały dla klienta, który nie ma przygotowania technicznego? Jednego takiego diagramu zapewne stworzyć się nie da. Można natomiast utworzyć dwa odrębne diagramy (lub zestawy diagramów): model dziedziny biznesowej, przeznaczony m. in. dla klienta, oraz diagram projektowy, będący podstawą implementacji.

Pracownik firmy jest sprzedawcą lub inżynierem. Siedziba firmy jest jej centralą lub oddziałem. Kontrahent jest klientem lub dostawcą. To tylko kilka przykładów często spotykanej sytuacji, gdy dany obiekt pełni wobec innych obiektów pewne role. Zobaczmy, w jaki sposób można modelować role na diagramach klas.

W poprzednim odcinku Akademii UML przekonaliśmy się, że dziedziczenie zwykle nie sprawdza się podczas modelowania ról i poznaliśmy proste sposoby radzenia sobie z rolami pełnionymi przez obiekty. Zobaczmy, jakie jeszcze techniki można wykorzystać w takich sytuacjach.

Dziedziczenie jest jednym z podstawowych mechanizmów obiektowości, chętnie stosowanym przez projektantów i programistów. Zobaczmy więc, na czym polega mechanizm dziedziczenia i przyjrzyjmy się sytuacjom, gdy jego użycie nie jest najszczęśliwszym rozwiązaniem.

W poprzednim odcinku Akademii UML poznaliśmy sytuacje, w których nie należy stosować dziedziczenia. Zobaczmy, kiedy powinniśmy tworzyć wspólną nadklasę dla kilku klas, a kiedy taka hierarchia klas jest zbędna.

Polimorfizm jest mechanizmem pozwalającym na zgrabne i eleganckie programowanie z użyciem dziedziczenia. Trzeba go jednak używać z rozwagą. Zobaczmy, jakie pułapki czyhają na nas, gdy korzystamy z dziedziczenia i polimorfizmu.

Klasy, jakie tworzymy na diagramach klas, łączymy ze sobą za pomocą powiązań. W ten sposób umieszczamy na modelu wiele kluczowych informacji. Zobaczmy, jak tworzyć powiązania poprawnie i elegancko.

Klasy asocjacyjne są interesującym rodzajem powiązań między klasami. Stosujemy je wtedy, gdy potrzebujemy przypisać jakieś atrybuty lub metody do samego powiązania. Zobaczmy, jak ich używać poprawnie i elegancko, oraz kiedy warto je zastępować zwykłymi klasami.

Określenie liczebności klas biorących udział w powiązaniach na diagramach klas to jedna z najważniejszych decyzji analitycznych, mająca niebagatelny wpływ na funkcjonalność modelowanego systemu. Zobaczmy więc, jak poprawnie określać liczebności, aby uniknąć przykrych niespodzianek.