Komponentowe systemy rozproszone

1. Komponentowe systemy rozproszone Wprowadzenie

2. Komponent ... jest to • podstawowa jednostka oprogramowania • z kontraktowo (deklaratywnie) opisanymi interfejsami, i • podanymi wprost zależnościami. na podst. "Oprogramowanie komponentowe. Obiekty to za mało" (1998)

3. Komponent • Może być użyty przez inne elementy programu • Jego użycie nie wymaga interwencji programisty • Posiada pełną specyfikację zależności • Specyfikuje oferowaną przez siebie funkcjonalność • Może być użyty wyłącznie na podstawie tej specyfikacji • Można go złożyć z innymi komponentami • Integruje się z systemem w sposób szybki i bezproblemowy • B.Meyer (2001)

4. Komponent vs. obiekt • konfiguracja wdrożenia • późne wiązanie wywołań i ładowanie kodu • pełna hermetyzacja • dziedziczenie interfejsów • powtórne użycie na poziomie binariów • polimorfizm • późne wiązanie wywołań • częściowa hermetyzacja • dziedziczenie klas

5. Komponent z pudełka ... albo z kontenera... Kontener jest odpowiedzialny za zarządzanie komponentami: • steruje procesem tworzenia komponentów • rozwiązuje zależności pomiędzy komponentami • zarządza cyklem życia komponentów

6. Problemy • Stabilność i poprawność działania • Testowanie • Dokumentacja komponentu • Wygoda użycia: • Brak silnych powiązań • Nieskomplikowny interfejs • Unikanie skomplikowanych protokołów • Przejrzyste specyfikowanie akcji

7. Komponenty vs. poprawne OOD • OOD w praktyce sprowadza sie do zarządzania zależnościami • Problemy ze złożonym oprogramowaniem w dużej mierze wynikają z niepoprawnych, zagmatwanych i rozbudowanych zależności • Tradycyjne metody OOx nader często zawodzą z różnych przyczyn • Może komponenty to „porządnie” zaprojektowane obiekty (gupy obiektów) ?

8. Rozwiązanie • S.O.L.I.D. • Poprawny i łatwy w utrzymaniu kod • Testy jednostowe • umozliwiają łatwe testowanie wyizolowanych klas/komponentów • stanowią dokumentację • weryfikują/ wymuszają (TDD/BDD) dobrą architekturę kodu • Testy automatyczne • CI/CD