Czym jest interfejs#
Interfejs (interface) w UML jest specyfikacją dostępnego zachowania, którego realizator zobowiązuje się dostarczyć. Opisuje kontrakt: jakie operacje lub usługi są dostępne, bez konieczności ujawniania wewnętrznej implementacji. Dzięki temu klient może zależeć od stabilnego opisu możliwości, a nie od szczegółów konkretnej klasy lub komponentu.
Interfejs nie jest tym samym co konkretna klasa ani ekran użytkownika. Może określać operacje, sygnały, właściwości i ograniczenia zależnie od modelu. Dokładny zestaw elementów zależy od tego, co ma być kontraktem. Interfejs nie dostarcza automatycznie implementacji ani nie gwarantuje, że jego realizator zachowa się poprawnie — model stwierdza zobowiązanie, którego spełnienie trzeba zapewnić i zweryfikować.
Zapis na diagramie klas#
Interfejs może być pokazany prostokątem z nazwą, operacjami i ewentualnie stereotypem «interface». Klasa lub komponent, który spełnia kontrakt, łączy się z interfejsem relacją realizacji. Klient może zależeć od interfejsu, dzięki czemu jego model nie wiąże się bezpośrednio z konkretnym realizatorem.
Platnosci realizuje kontrakt IPayment, a Sklep potrzebuje tego kontraktu. Diagram celowo nie wiąże sklepu bezpośrednio z konkretną implementacją. Nazwy operacji i parametry są przykładem; pełny kontrakt może obejmować także typy, wyniki, wyjątki, warunki, uprawnienia i zasady idempotencji.
Notacja z „lizakiem” i gniazdem#
Na diagramie komponentów interfejs dostarczany bywa przedstawiany jako małe kółko połączone z komponentem — tzw. lizak. Interfejs wymagany można przedstawić jako półokrąg lub gniazdo. Połączenie gniazda z lizakiem wskazuje, że wymagany kontrakt jest dostarczany przez drugi komponent. Ta notacja oszczędza miejsce, ale nie pokazuje szczegółów operacji; gdy one są ważne, użyj prostokątnego symbolu interfejsu lub osobnego diagramu.
Znaki graficzne są alternatywnymi sposobami przedstawiania kontraktu, a nie różnymi rodzajami interfejsu. Wybierz zapis, który pozwala odbiorcy odczytać, kto dostarcza, a kto wymaga usługi. Jeśli przyjęta konwencja nie jest oczywista, opisz ją w legendzie.
Interfejs dostarczany i wymagany#
Interfejs dostarczany (provided) to kontrakt, którego realizację element oferuje innym. Interfejs wymagany (required) to kontrakt, którego element potrzebuje, aby wykonać swoją odpowiedzialność. Te role są względne wobec danego komponentu: ten sam system może dostarczać jedne interfejsy i wymagać innych.
„Wymagany” nie oznacza, że usługa jest w danym momencie niedostępna, a „dostarczany” nie gwarantuje, że jest uruchomiona. Diagram architektury pokazuje deklarowane połączenia i kontrakty, nie stan operacyjny. Dostępność, adresy, protokoły czy konfigurację środowiska przedstawiaj w modelu wdrożenia lub dokumentacji technicznej, jeśli są istotne.
Realizacja i wersjonowanie kontraktu#
Realizator interfejsu powinien spełniać wymagania jego kontraktu, a klienci powinni móc korzystać z niego zgodnie z określoną semantyką. Sama zgodność nazw metod nie wystarcza, gdy kontrakt określa również warunki wejściowe, rezultaty, błędy lub ograniczenia. Zamienność dwóch realizatorów wymaga, aby oba zachowywały się w sposób akceptowalny dla klientów.
Zmiana interfejsu może wpływać na wielu klientów. Dodanie operacji, zmiana typu lub inna semantyka może być zmianą niekompatybilną zależnie od języka, reguł wersjonowania i sposobu użycia. UML nie definiuje polityki wersji API ani kompatybilności wdrożeń; te zasady należy dokumentować osobno.
Interfejs UML a pojęcia z programowania#
Interfejs UML jest konstruktem modelu. Może odpowiadać interfejsowi języka programowania, API, portowi komponentu albo abstrakcji na wyższym poziomie, ale mapowanie nie jest automatyczne. Języki różnią się obsługą implementacji domyślnych, dziedziczenia, typów generycznych i widoczności. Nie przenoś ograniczeń jednej platformy na model UML bez wyraźnego założenia.
Także słowo „interfejs” w rozmowie o interfejsie użytkownika oznacza coś innego. Widok, ekran lub formularz można modelować innymi elementami i diagramami; nie utożsamiaj go z kontraktem operacji.
Typowe błędy#
- Interfejs uznany za klasę z gotowym kodem. Interfejs specyfikuje zachowanie; implementację dostarcza realizator.
- Klient połączony wyłącznie z implementacją. Jeśli kontrakt ma być granicą architektury, klient powinien zależeć od interfejsu.
- Mylenie realizacji z użyciem. Realizator spełnia kontrakt; klient wymaga lub wykorzystuje kontrakt.
- Dostarczanie utożsamione z dostępnością. Modelowany kontrakt nie dowodzi, że usługa działa.
- Zbyt ubogi kontrakt. Same nazwy operacji mogą pomijać znaczenie wyników i błędów.
- Mylenie interfejsu modelu z UI. Kontrakt UML i ekran użytkownika to różne pojęcia.
- Założenie identyczności UML i języka. Diagram jest niezależnym modelem, dopóki nie określisz mapowania.
Podsumowanie#
Interfejs UML opisuje kontrakt, który może być realizowany przez klasy lub komponenty i wymagany przez klientów. Można go przedstawić jako prostokąt z operacjami albo skróconym symbolem dostarczania i wymagania. Rozdziela specyfikację od implementacji, lecz sam nie gwarantuje poprawnego zachowania ani dostępności usługi.