Komponentowe i rozproszone Komponenty i zależności.

Slides:



Advertisements
Podobne prezentacje
Zastosowanie LDAP w obsłudze katalogów bibliotecznych
Advertisements

Modelowanie logiczne (dla relacyjnych SZBD)
CORBA Łukasz Wnęk.
1 Linux jako system wielozadaniowy i wielodostępny.
CLR na platformie .NET Tomasz Kostarski.
Architektura systemu Gra strategiczna „Strusia Jama”
Internet Communication Engine
Platforma .Net i Vs.Net.
Tworzenie ASP.NET Web Form
Refaktoryzacja czyli odświeżanie kodu
Systemy operacyjne Wykład nr 5: Wątki Piotr Bilski.
Biblioteki i przestrzenie nazw
Systemy operacyjne Bibliografia:
Pakiety i ATD 1 Definicja. Pakietem albo jednostką programową nazywamy grupę logicznie powiązanych elementów, które mogą być typami, podtypami, obiektami.
Enteprise Java Beans Emil Wcisło.
Wzorce projektowe w J2EE
Modele baz danych - spojrzenie na poziom fizyczny
Narzędzia internetowe Paweł Rajba ttp://pawel.ii.uni.wroc.pl/
Wstęp do kontenerów IoC
Inżynieria Oprogramowania
Pakiety w Javie Łukasz Smyczyński (132834). Czym są pakiety? Klasy w Javie są grupowane w pewne zbiory zwane pakietami. Pakiety są więc pewnym podzbiorem.
Message-Driven Bean.
Generatory dokumentacji kodu źródłowego
Komponentowe i rozproszone
Realizacja aplikacji internetowych
Instrukcja USOS Rejestracja na zajęcia obieralne wersja by Marek Opacki.
Licencjonowanie aplikacji serwerowych
Licencjonowanie narzędzi dla programistów
Prezentacja i szkolenie
Tworzenie aplikacji mobilnych
Komponentowe systemy rozproszone Wprowadzenie. Komponent... jest to podstawowa jednostka oprogramowania z kontraktowo (deklaratywnie) opisanymi interfejsami,
Komponentowe i rozproszone Interludium. OOA vs SOA OOA (obiekty rozproszone): CORBA, COM(+), EJB Współdzielenie obiektów SOA (serwisy rozproszone): Autonomiczne.
E-pytanie, e-odpowiedź... czyli jakich badań potrzebują biblioteki przyszłości? Dagmara Sawicka Biblioteka Główna Akademia.
XML – eXtensible Markup Language
SZKOŁA Z KLASĄ 2.0 English SOS.
Rational Unified Process Implementacja Aleksandra Reiman, gr. I-52.
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Bazy i Systemy Bankowe Sp. z o.o. ul. Kasprzaka 3, 85 – 321 Bydgoszcz
Windows 8.1 dostarcza spójną platformę do tworzenia aplikacji, które potrafią dostosować się do wielu urządzeń Zaprojektowane raz, działają.
System plików.
Diagram klas Kluczowymi elementami są: klasy (class)
Oprogramowanie komponentowe w środowisku Microsoft Katarzyna Kuźniar 4 FDA, C1.
Diagram klas Diagramy klas służą do obrazowania statycznych aspektów projektowanych systemów jako: Projekt struktury logicznej baz danych Projekt składników.
Piotr Czapiewski Wydział Informatyki ZUT. Web Services Description Language.
Komponentowe systemy rozproszone Wprowadzenie. Komponent... jest to podstawowa jednostka oprogramowania z kontraktowo (deklaratywnie) opisanymi interfejsami,
Projektowanie obiektowe. Przykład: Punktem wyjścia w obiektowym tworzeniu systemu informacyjnego jest zawsze pewien model biznesowy. Przykład: Diagram.
Obiekty COM Przemysław Buczkowski. Plan prezentacji 1.Wprowadzenie do COM 2.Historia standardu 3.Jak działa COM 4.Interface IUknown 5.Paradygmaty COM.
DEFINITION OF COMPOSITE PROGRAMMABLE GRAPH (CP-GRAPH)
I TY ZOSTAŃ WEBMASTEREM! CZĘŚĆ 2 – „STRUKTURA STRONY” STWORZYŁ GABRIEL ŚLAWSKI.
Komponentowe i rozproszone Interludium czyli krótki wykład o rozpraszaniu.
Platforma .Net.
Podstawy programowania
Struktura systemu operacyjnego
Dokumentacja programu komputerowego i etapy tworzenia programów.
Waldemar Bartyna Pytania egzaminacyjne 1.
C++ WYKŁAD 12 ( ) Własne biblioteki. S PIS TREŚCI Kompilacja i łączenie Moduły Biblioteki Biblioteka statyczna Biblioteka współdzielona Biblioteka.
Architektura Rafał Hryniów. Architektura Wizja projektu systemu, którą dzielą twórcy Struktura komponentów systemu, ich powiązań oraz zasad i reguł określających.
Komponentowe systemy rozproszone Interludium czyli krótki wykład o rozpraszaniu.
Komponentowe systemy rozproszone Komponenty i zależności.
Komponentowe i rozproszone (Web)Service Oriented Architecture.
TWOJA CYFROWA PRZYSZŁOŚĆ. JUŻ DZISIAJ. Marcin Parczewski © 2016 Software AG. All rights reserved. For internal use only.
ST | 9/16/2015 | © Robert Bosch GmbH All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as well.
Instalacja klucza HASP.
Rozszerzalna architektura
Dynamiczny serwer aplikacyjny w C++ platforma LEFTHAND
Podstawy programowania
JavaBeans by Paweł Wąsala
Konteneryzacja i DevOps
Refaktoryzacja czyli odświeżanie kodu
Zapis prezentacji:

Komponentowe i rozproszone Komponenty i zależności

Moduł Obecne rozwiązania pozwalają łatwo dzielić kod na moduły Nie utrudnia to kompilacji, relatywnie łatwo zmienić rozmieszczenie klas itd (zmiana przestrzeni nazw?). Serwery CI pozwalają wykrywać niespójności pomiędzy modułami Nie ma dużej różnicy czy dostarczamy program w postaci 1 pliku wykonywalnego czy grupy plików. 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, użycie różnych assemblies jest właściwie “bezbolesne” Rozwiązania typu kontenery DI pozwalają na rozluźnienie zależności między klasami

Komponent Co jeżeli chcemy dostarczać poszczególne moduły oddzielnie? Jak testować komponent, który może być używany w kilku systemach/aplikacjach? Co jeżeli każdy użytkownik chce mieć swoje zmiany ? Co jeżeli zmiana zaindukowana przez jeden system wymusza testowanie kodu ze wszystkimi? Czy przy każdej zmianie trzeba testować wszystkich użytkowników ?

Komponenty vs. moduły Moduł – biblioteka ? – podział raczej widoczny w czasie wytwarzania Komponent  Jest dostarczany niezależnie  ma indywidualny cykl życia/testowania itd Poszczególni użytkownicy mogą używać swoich wersji. Mogą się “przesiąść” na nowszą wersję w wybranym, dogodnym momencie (jak robią własne zmiany) Można wersjonować komponenty na poziomie binarnym

Podział na komponenty REP: The Reuse/Release Equivalency Principle: The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This granule is the package. CRP: Common Reuse Principle:The classes in a package are reused together. if you reuse one of the classes in a package, you reuse them all. CCP: Common Closure Principle:The classes in a package should be closed together against the same kinds of changes. a change that affects a package affects all the classes in that package. Robert C. Martin

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

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

Zależności między modułami Acyclic Dependencies Principle: the dependency structure between packages must be a directed acyclic graph (dag). that is, there must be no cycles in the dependency structure. Stable Dependancies Principle: the dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable that it is. Stable Abstractions Principle: packages that are maximally stable should be maximally abstract. instable packages should be concrete. The abstraction of a package should be in proportion to its stability. Robert C. Martin

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

Stabilność Moduły stabilne (trudne do zmiany) nie powinny zależeć od niestabilnych (łatwych do zmiany) Co jest łatwe do zmiany? Klasy finalne, do których niewiele kodu się odwołuje. Co jest trudne do zmiany? Klasy finalne, do których odwołuje się dużo kodu, klasy bazowe, interfejsy. Co zmienia się często: klasy konkretne, implementacje logiki biznesowej Co zmienia się rzadko: abstrakcje – interfejsy, klasy abstrakcyjne

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|

Wiecej nt. komponentów Robert C. Martin - Clean Design, Components Principles.wmv

TECHNIKALIA Jak to się robi w.Net, czyli

.Net CLI pozwala na wykorzystywanie kodu napisanego w dowolnym języku wspierającym.NET Zarządzalne biblioteki w połączeniu z refleksją pozwalają na łatwe użycie kodu na poziomie binarnym (CL) Wersjonowanie pozwala na jednoczesne użycie różnych wersji tej samej biblioteki Na poziomie systemowym można rejestrować biblioteki w GAC

.NET Podzespoły (assemblies)  Logiczny zbiór wyników kompilacji jednego lub więcej projektów  Może mieć formę EXE, DLL  Wydzielone binaria, pliki z zasobami, manifest  Definiowanie podzespołu:  AL.EXE (ILDASM.EXE)  IDE

.NET Manifest  Definiuje obiekty wchodzące w skłąd podzespołu  Może określać kulturę (język, formaty, itd)  Może zawierać klucze publiczne  Może zawierać prywatne atrybuty (ignorowane przez CLR)  Może określać wymagany/pożądany CLR

.NET wdrażanie podzespołów  Podzespoły mogą być współdzielne i mogą współdzielić pliki  Najprostsza postać to pliki w jednym katalogu (nie wymagane żadne wpisy do rejestru)  Brak ew. konfliktów  Pot. multiplikacja bibliotek  Współdzielenie zasobów:  GlobalAssemblyCache (GACUTIL.EXE, AssemblyCacheViewer)  Wymaga silnych nazw: Nazwa+fragment klucza publicznego SN.exe -> plik.snk -> project

.NET Wersjonowanie Alternatywa dla piekła DLLi „Docelowy plik jest nowszy niż kopiowany. Czy kontynuować ?” (90% - TAK) Manifest zawiera informację o wersji  Główny i drugorzędny numer wersji  Numer kompilacji  Numer korekty Manifest zawiera wersję informacyjną CLR próbuje znaleźć wersje podzespołów wymagane lub dopuszczane przez klienta

Uprzedzajac fakty Komponent ≠ Serwis

Rozszerzalna architektura z MS Kontenery IoC/DI  Wiele dostępnych rozwiązań  Decoupling, testowanie, scentralizowana rejestracja, MEF  Wprowadzony w.Net 4.0  Discovery, obsługa metadanych, opóźniona kreacja

MEF - koncepcja

MEF – Podstawowe pojęcia Export  Export dla typu/funkcji/pól  Wymuszony typ: Export(typeof(Ixxx))  Nazwany kontrakt: Export("name",typeof(Ixxx))  Export nie jest dziedziczony – można użyć InheritedExport Import  Dla typu określonego w kodzie  Import określonego typu/kontraktu

MEF – Zalecane praktyki Imort/Eksport Interfejsów zamiast konkretnych typow Stałe jako nazwy kontraktow stale/i kontrakty w oddzielnych assembly

.Net vs Java …. JNBridge IKVM WebServices ?