Czym jest realizacja#
Realizacja (realization) jest relacją UML, w której element implementujący spełnia kontrakt określony przez specyfikację. Częstym przypadkiem jest klasa realizująca interfejs: udostępnia operacje wymagane przez interfejs zgodnie z jego kontraktem. Realizację stosuje się także między innymi dla komponentów i specyfikacji, zależnie od modelu.
Na diagramie klas relację realizacji przedstawia się linią przerywaną z pustym trójkątem skierowanym do elementu specyfikującego, np. interfejsu. Klasy implementujące mogą być wymieniane wobec klienta, który zależy od kontraktu, o ile rzeczywiście zachowują jego zachowanie.
Notacja i przykład#
AdapterOperatora i SymulatorPlatnosci realizują wspólny interfejs. Klient może zależeć od IPayment, a nie od konkretnej klasy, co ułatwia testowanie i zmianę dostawcy. Diagram pokazuje kontrakt na poziomie modelu, ale nie określa szczegółowej semantyki metod, obsługi błędów ani protokołu.
Co oznacza spełnienie kontraktu#
Realizacja powinna zapewniać wymagane operacje i zachowania specyfikacji. Sama zgodność nazw lub parametrów może nie wystarczyć: kontrakt może określać warunki wejściowe, gwarantowane wyniki, ograniczenia, zdarzenia lub reguły błędów. Niepoprawna implementacja może syntaktycznie udostępniać operację, a mimo to nie spełniać modelu.
Interfejs nie musi być interfejsem języka programowania. Może opisywać usługę, port, API lub inny zestaw zobowiązań. Realizacja w diagramie UML wyraża relację modelową; mapowanie na kod zależy od platformy i architektury.
Realizacja a generalizacja#
Generalizacja jest relacją typu „jest rodzajem”: podtyp dziedziczy cechy typu ogólnego i powinien zachowywać jego kontrakt. Realizacja jest relacją „spełnia specyfikację”: klasyfikator implementujący może być związany z interfejsem bez dziedziczenia po konkretnej klasie.
Obie relacje mogą używać pustego trójkąta, ale różnią się linią i semantyką. Generalizacja jest linią ciągłą; realizacja — przerywaną. Nie używaj dziedziczenia, jeśli potrzebujesz jedynie kilku implementacji tego samego kontraktu.
Realizacja w diagramach komponentów#
Komponent może dostarczać interfejs, który realizuje. Inny komponent może wymagać tego kontraktu. Taki układ pozwala oddzielić deklarację usług od konkretnego dostawcy. Zależność klienta skierowana do interfejsu może zmniejszać sprzężenie, lecz diagram powinien pokazać wymagany i dostarczany kontrakt zgodnie z przyjętą notacją.
Nie utożsamiaj realizacji z wywołaniem. Relacja nie oznacza, że operacja została już wykonana, ani że komponent jest wdrożony lub dostępny w czasie uruchomienia.
Kiedy realizacja pomaga#
Użyj jej, gdy odbiorca powinien rozpoznać, że jeden lub więcej elementów zapewnia ten sam stabilny kontrakt. Przydaje się do oddzielenia usług od implementacji, pokazania adapterów, zamiennych dostawców, testowych atrap lub struktur komponentów.
Jeśli w modelu jest tylko jedna prosta klasa i interfejs niczego nie ukrywa ani nie standaryzuje, dodatkowa warstwa może być zbędna. Wprowadzenie interfejsu powinno wynikać z granicy kontraktu, wymiany implementacji, testowania lub innej potrzeby.
Typowe błędy#
- Realizacja mylona z generalizacją. Przerywana linia oznacza spełnienie specyfikacji, a nie podtyp.
- Grot skierowany do implementacji. Trójkąt wskazuje specyfikację lub interfejs.
- Kontrakt tylko po nazwie. Zgodne sygnatury nie gwarantują właściwego zachowania.
- Założenie, że interfejs jest zawsze potrzebny. Dodawaj go, gdy oddziela istotny kontrakt.
- Realizacja utożsamiona z wykonaniem. To statyczna relacja modelu, nie komunikat.
- Niespójne implementacje. Wszystkie realizacje powinny spełniać uzgodnioną semantykę.
- Brak testów kontraktowych. Model nie dowodzi zgodności implementacji.
- Realizacja utożsamiona z wdrożeniem. Nie określa, gdzie komponent działa.
Podsumowanie#
Realizacja pokazuje, że klasyfikator lub komponent spełnia kontrakt specyfikacji. W przypadku interfejsu stosuje się przerywaną linię z pustym trójkątem skierowanym do interfejsu. Odróżniaj ją od dziedziczenia i weryfikuj, że implementacje spełniają nie tylko składnię, ale także znaczenie kontraktu.