Komponentowe systemy rozproszone Komponenty i zależności.

Prezentacja na temat: "Komponentowe systemy rozproszone Komponenty i zależności."— Zapis prezentacji:

1 Komponentowe systemy rozproszone Komponenty i zależności

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 Obiekt wynikająca z pradadygmatu programowania jednostka logiczna kodu tożsamośc, stan (dane) i zachowanie (metody) enkapsulacja danych i metod hermetyzacja (w zależności od jezyka mniej lub bardziej szczelna) dziedziczenie (interfejsów lub implementacji) – w celu reużycia funkcjonalności polimorfizm (dynamiczny lub statyczny) dla funkcji wirtualnych pewna forma późnego wiązania

5 Moduł Logicznie wydzielony kawałek kodu, który może być rozwijany w pewnej izolacji Zwykle pewna liczba klas/metod rozwijanych razem = Trochę większy obiekt ? Moduł raczej nie jest dostarczany samodzielnie do klientów, ale może byćwspółdzielony między zespołami Przykłady: namespace, biblioteka statyczna, biblioteka linkowana dynamicznie może być wdrażana (dostarczana) samodzielnie – pytanie czy powinna (czy jest wystarczająco samodzielna, integralna, samodokumentująca)

6 Komponent (pakiet) Jest dostarczany niezależnie Ma indywidualny cykl życia/testowania itd Poszczególni użytkownicy/podsystemy mogą używać swoich wersji. Użytkownicy chcą się “przesiąść” na nowszą wersję w wybranym, dogodnym momencie (jak robią własne zmiany) Można wersjonować komponenty na poziomie binarnym

7 Uprzedzając fakty Komponent ≠ Serwis

8 Problemy, czyli dlaczego ten wykład Mikro: jakość kodu, jak projektować klasy, projekt (dokumentacja) rozchodzi się z kodem, klasy robią się duże Makro Cały kod jest nie-do-ogarnięcia. Nawet zrozumienie zależności między modułami jest problemem Zespoły mają problem integracją Zespoły mają problem ze zmianami innych zespołów testowanie (wydanie) molocha trwa b. długo

9 Mikro rozwiązania SOLID + DI TDD/BDD/ATDD refaktoryzacja DDD CI/CW AOP Zapraszam na ZTO -

10 Przykład System – site www: ~100 modułów ~10 zespołów, Web serwer/search/baza + Integracja danych z innych systemów

11 Co działa? Zespoły są w miarę niezależne Obecne rozwiązania pozwalają łatwo dzielić kod na moduły TDD/BDD/ATDD w miarę działa Relatywnie łatwo lokalnie refaktoryzować. Serwery CI (Ciągła Integracja) pozwalają wykrywać niespójności pomiędzy modułami.NET: Na potrzeby instalacji można scalić kilka assemblies w jedno np. (exe+dll-ki -> exe) Na poziomie kodu i tak dążymy do rozluźnienia zależności między klasami, Dzięki Rozwiązania kontenerom DI użycie różnych assemblies jest mniej bolesne ORM pozwala na abstrachowanie od bazy

12 Co działa "średnio" ? Kompilacja trwa długo. Testy jeszcze dłużej. Automatyzacja jest NIEZBĘDNA ale TRUDNA. Jak testować komponent, który może być używany w kilku podsystemach/podprojektach? Co jeżeli każdy zespół chce mieć swoje zmiany ? Co jeśli zmiana indukuje zmianę w komponenecie, którego nikt nie planował w tym momencie zmieniać? Co jeżeli jedna zmiana wymaga "zaciągnięcia" wielu innych zmian? Co jeżeli 2 zespoły zmieniają moduł A oraz B, a te wymagają różnych (niekompatybilnych) wersji C?

13 Podsumowanie Współdzielenie kodu źródłowego vs. binarek Binarki Duży nakład pracy na releasy/wersje itd Duże zamieszanie z CI/CD, dystrybucją Kod: trudno zarzadzać cyklem zmian trudno wersjonować np. zbudowanie GUI moze wymagać różnych wersji różnych plików trudno ograniczyć wyciek abstrakcji np. klasa car/person/engine będzie miała zupełnie inne odpowiedzialności po stronie GUI i serwerowej

14 3 zasady Wujka Boba. Robert C. Martin: REP: The Reuse/Release Equivalency Principle Jednostką (re)użycia jest release. CRP: Common Reuse Principle: Klasy w pakiecie są (re)używane razem CCP: Common Closure Principle: Zasada wspólnego domknięcia

15 REP: Jednostką (re)użycia jest release Oprogramowanie (re)używane jest udostępniane na zewnątrz firmy/zespołu. Ktoś musi zarzadzać jego wydaniami:  wersjonowanie  dokumentacja, maintenance, testy  synchronizacja zmian + komunikacja z klientami  produkcja pakietów  wersjonowanie źródeł,  wybór i numeracja stabilnych wersji,  budowa i dystrybucja binariów dostęp do wybranych wersji + dokumentacja wersji informacja o kompatybilności (semantyczne wersjonowanie)

16 CRP: Zasada wspólnego (re)użycia Klasy w pakiecie są dostarczane razem Ponieważ (re)użytkownik musi wziąść cały pakiet - komponenty/klasy powinny być zgrupowane tak by nie trzebabyło używać wielu pakietów. Kontrola wpływu na inne moduły Specyfikacja wymagań/zależności swojego modułu Najlepiej jęsli użytkownik aby uzyskać potrzebną funkcjonalnośc musi wziąść jak najmniej pakietów.

17 CCP: Zasada wspólnego domknięcia Wydajemy zawsze cały pakiet. Zmiana pakietu implikuje testowanie u jego użytkowników. Zmiana wielu pakietów = dużo testowania. Zmiana kawałka pakietu = testowanie całego klienta. Najlepiej by pakiet był jednorodny: tj. poszczególne składowe pakietu powinny mieć podobne powody do zmian. Najlepiej jeśli poszczególne zmiany funkcjonalności implikują wydanie jak najmniejszej liczby pakietów.

18 Komponent CRP: podział dla uniknięcia zbędnych wydań REP: Grupowanie dla reużycia CCP: Grupowanie dla potrzeb utrzymania Zbędne wydania Zmiany rozproszone między komponentami Niewygodne (re)użycie Kompo- nent Granice podziału determinują częstość wydań, wygodę wytwarzania i korzystania z komponentu

19 Zależności między modułami Acyclic Dependencies Principle: zależności pomiedzy pakietami powinny miec formę skierowanego grafu acyklicznego. Tj. nie powinno być wzajemnych ani cyklicznych zależności. Stable Dependancies Principle: zależność pomiedzy pakietami powinna być powiazana z częstością I łatwością zmian. Tj. często zmienne rzeczy powinny zależeć od rzadko zmiennych (Nie odwrotnie!) Stable Abstractions Principle: packages pakiety stabilne są abstrakcyjne. Pakiety konkretne są zwykle niestabilne. Abtrakcyjność pakietu powinna być proporcjonalna do stabilnosci. Robert C. Martin

20 ADP: Syndrom dnia następnego Nie chodzi o efekt "świetowania" release-u 1. Releasujesz swój pakiet 2. Nastepnego dnia pakiet nie działa bo  Twój pakiet wymusił zmiany w innych pakietach  zmiany w innych pakietach finalnie wymusiły zmiany w Twoim pakiecie Trudno stwierdzić co wpływa na co => sprzeżenie zwrotne Pakiety stają się niestabilne. Pakiety muszą być zmianiane razem Hierarchia zależności powinna być płytka

21 SDP: Co to jest Stabilność Moduły stabilne (trudne do zmiany) nie powinny zależeć od niestabilnych (łatwych do zmiany) Co jest łatwe do zmiany?  typy, funkcje, do których odwołuje się niewiele kodu. Co jest trudne do zmiany?  typy, funkcje, do których odwołuje się dużo kodu.

22 SAP: Co to jest Abstrakcyjność Byty abstrakcyjne są niezmienne. Zmieniają się rzeczy konkretne np. przepisy, reguły biznesowe, warunki wyboru itd. Co często trzeba modyfikować:  klasy konkretne  metody konkretne  implementacje logiki biznesowej. Co trzeba zmieniać rzadko:  interfejsy  abstrakcje: klasy abstrakcyjne I metody abstrakcyjne  klasy bazowe

23 Zależności Rodzaje zależności:  (Afferent) - kto zależy  (Efferent) – od kogo zależy class X { … Y field; } class Y { … } afferent efferent

24 Miara zależności C A (X) = liczba funkcji/klas/modułów, które zależą od (odwołują sie do) X C E (X) = liczba funkcji/klas/modułów do których odwołuje się X N = liczba typów N A = liczba typów abstrakcyjnych Niestabilność: I =C E / (C A + C E ) Abstakcyjność: A=N A /N

25 Optymalna sytuacja A1A1 1 I Strefa bólu: klasy konkretne, b. często używane w kodzie Strefa braku użyteczności: klasy abstakcyjne, z których nikt nie korzysta Klasy czysto abstrakcyjne o dużej stabilności Klasy konkretne o małej stabilności Miara pot. problemów: D = |A+I-1|

26 Wujek Bob o komponentach I nie tylko… Robert C. Martin - Clean Design, Components Principles.wmv Dowolne prezentacje np. z NDC Warto poczytać Robert C. Martin: Agile Software Development, Principles, Patterns, and Practices Clean Code The Clean Coder