Perspektywa obiektowości

Transkrypt

1 Inżynieria Oprogramowania Wykład 10 Wzorce projektowe Perspektywa obiektowości obiekty hermetyzacja dziedziczenie klasy abstrakcyjne 2

2 Wzorce projektowe Czym są wzorce projektowe Przykładowe definicje: Wzorce projektowe stanowią powtarzalne rozwiązanie zagadnień projektowych, z którymi się wciąż spotykamy. Wzorzec identyfikuje i specyfikuje pewna abstrakcję, której poziom znajduje się powyżej poziomu abstrakcji pojedynczej klasy, instancji lub komponentu Wzorce projektowe w największym stopniu dotyczą problematyki proponowanego użycia powtarzających się motywów architektury programów, zaś szkielety aplikacji dotyczą szczegółów projektowych i implementacyjnych 3 Wzorce projektowe cechy wzorców wzorzec posiada nazwę oraz zastosowanie należy określić rozwiązywany problem, który jest powodem zastosowania danego wzorca wskazuje trudności wynikające z uproszczonego rozwiązania oraz metody jego poprawy opis wzorca składa się z czterech elementów: nazwa wzorca, zadanie wzorca, czyli opis problemu, który stanowi rozwiązanie sposób rozwiązania problemu, ograniczenia i siły, które należy wziąć pod uwagę stosując rozwiązanie cele tworzenia wzorców tworząc programy spotykamy się z problemami, które można rozwiązać w podobny sposób w przypadku projektowania oprogramowania można zastosować wzorce tak, by pomagały w tworzeniu konkretnych rozwiązań 4

3 Wzorce projektowe elementy wzorca: nazwa wzorca skrót służący do określenia problemu projektowego, jego rozwiązania i konsekwencji problem określa, kiedy stosować dany wzorzec, np.. Opisuje specyficzne zagadnienie projektowe, struktury klas lub obiektów lub listę warunków, które muszą być spełnione, aby stosowanie wzorca miało sens rozwiązanie określa elementy składające się na projekt, ich związki, zobowiązania i współpracę konsekwencje wyniki oraz wady i zalety zastosowania wzorca 5 Wzorce projektowe Historia wzorców projektowych prace architekta Christophera Alexandra wzorce projektowe w architekturze ogólne przyczyny tego, żee pewne rozwiązaniazania uznajemy za dobre inne za złe szereg wzorców w architekturze budowli i zagospodarowania przestrzennego wzorzec MVC jako pierwszy wzorzec projektowy zastosowany w informatyce książka: Design Patterns: Abstraction and Reuse of Object Oriented- Design, napisanej przez tak zwany Gang Of Four (E. Gamma, R. Helm, R. Johnson, J. Vlissides) zastosowanie wzorców projektowych w dziedzinie projektowania oprogramowania sposób katalogowania i opisu wzorców postulowano wprowadzenie do projektowania obiektowego szereg zasad i strategii opartych na wzorcach projektowych 6

4 Wzorce projektowe wzorzec MVC (Model-Widok-Kontroler, ang. Model-View- Controler) wykorzystywany do budowy interfejsów użytkownika składa się z trzech rodzajów obiektów Model obiekt aplikacji Widok jego ekranowa reprezentacja Koordynator definiuje sposób, w jaki interfejs użytkownika reaguje na operacje wykonywane przez użytkownika 7 Wzorce projektowe Klasyfikacja wzorców projektowych według dwóch kryteriów: rodzaj odzwierciedla to, co robi wzorzec wzorce konstrukcyjne (kreacyjne) związane z procesem tworzenia obiektów wzorce strukturalne dotyczą składania klas lub obiektów wzorce czynnościowe charakteryzują sposób, w jaki klasy lub obiekty oddziałują na siebie i rozdzielają zobowiązania zakres określa, czy wzorzec odnosi się przede wszystkim do klas, czy do obiektów wzorce klasowe zajmują się związkami miedzy klasami i ich podklasami; związki te ustanowione są za pomocą dziedziczenia, czyli są statyczne wzorce obiektowe zajmują się związkami między obiektami; związki te mogą zmieniać się podczas wykonywania programu, czyli są dynamiczne 8

5 Wzorce projektowe Przegląd najważniejszych wzorców projektowych Wzorce konstrukcyjne (kreacyjne) metoda fabryki lub metoda wytwórcza (ang. factory method) fabryka abstrakcyjna (ang. abstract factory) singleton budowniczy (ang. builder) prototyp (ang. prototype) Wzorce strukturalne adapter (ang. adapter) most (ang. bridge) kompozyt (ang. composite) dekorator (ang. decorator) fasada (ang. facade) pyłek (ang. flyweight) pełnomocnik (ang. proxy) 9 Wzorce projektowe Przegląd najważniejszych wzorców projektowych Wzorce czynnościowe łańcuch zobowiązań (ang. chain of responsibility) polecenie (ang. command) interpreter (ang. interpreter) interator (ang. iterator) mediator (ang. mediator) pamiątka (ang. memento) obserwator (ang. observer) stan (ang. state) strategia (ang. strategy) szablon lub metoda szablonu (ang. template) odwiedzający (ang. visitor) 10

6 Wzorce projektowe Klasyfikacja wzorców projektowych według dwóch kryteriów: Rodzaj Konstrukcyjne Strukturalne Czynnościowe Zakres Klasy Metoda fabryki Adapter (klasy) Interpreter Metoda szablonu Obiekty Budowniczy Fabryka abstrakcyjna Prototyp Singleton Adapter (obiekty) Dekorator Fasada Kompozyt Most Pełnomocnik Pyłek Iterator Łańcuch zobowiązań Mediator Obserwator Odwiedzający Pamiątka Polecenie Stan Strategia 11 Wzorce projektowe kluczowe elementy opisu wzorców Nazwa identyfikuje wzorzec, oddaje jego istotę Intencja lub przeznaczenie zastosowanie wzorca Problem lub stosowalność dany wzorzec próbuje go rozwiązać Rozwiązanie sposób, w jaki wzorzec rozwiązuje problem w danym kontekście Uczestnicy i współpracownicy lub struktura byty w obrębie wzorca Konsekwencje dodatkowe efekty wynikające z zastosowania wzorca Implementacja sposób, w jaki można zaimplementować wzorzec 12

7 Wzorce projektowe powody stosowania wzorców projektowych możliwość wykorzystania istniejących, sprawdzonych wcześniej sposobów projektowania przyspieszenie pracy nad projektem, uniknie błędów na etapie projektowania istnienie podstawowego, wspólnego zasobu terminologii oraz wspólnej perspektywy problemu poprawa pracy w zespole i komunikacji pomiędzy jego członkami ogólna perspektywa widzenia problemów, projektowania obiektowego bez konieczności zbyt wczesnego zgłębiania szczegółów strategie rozwiązań obiektowych stosowane w większości wzorców projektowych projektowanie z wykorzystaniem interfejsów wykorzystanie kompozycji zamiast dziedziczenia odnajdowanie zmienności i hermetyzowanie jej 13 Wzorce projektowe użycie wzorów projektowych pomaga projektantom tworzyć sprawdzone, solidne rozwiązania powtarzających się problemów uzyskać wspólną terminologię opisu problemu poprawiającą komunikację w zespole myśleć o rozwiązaniu problemu na wyższym poziomie abstrakcji przeanalizować jakość uzyskanego rozwiązania, nie tylko jego działanie usprawnić edukacje zespołu zwiększyć możliwość wprowadzania modyfikacji w oprogramowaniu tworzyć doskonalsze rozwiązania znaleźć rozwiązania alternatywne do wykorzystujących rozbudowane hierarchie dziedziczenia 14

8 Wzorce projektowe rozwiązywanie problemów projektowych przy użyciu wzorców znajdowanie właściwych obiektów określenie poziomu szczegółowości obiektów specyfikowanie interfejsów obiektów specyfikowanie implementacji obiektów dziedziczenie klas a dziedziczenie interfejsów programowanie pod kątem interfejsu, a nie implementacji stosowanie mechanizmu ponownego użycia dziedziczenie a składanie delegowanie związek pomiędzy strukturą programu w czasie wykonania a strukturą programu w czasie kompilacji projektowanie pod kątem zmian 15 Wzorce projektowe Kategorie wzorców projektowych (omówione wzorce) Wzorce konstrukcyjne Tworzenie instancji: wzorzec fabryki abstrakcyjnej wzorzec singletonu wzorzec blokowania dwufazowego wzorzec metody fabryki Wzorce strukturalne Obsługa interfejsów: wzorzec fasady wzorzec adaptera Powiązanie implementacji i abstrakcji: wzorzec mostu wzorzec dekoratora 16

9 Wzorce projektowe Kategorie wzorców projektowych Wzorce czynnościowe Zawieranie zmienności: wzorzec strategii wzorzec obserwatora wzorzec metody szablonu N AZW A W ZORCA Wzorce projektowe Uproszczone opisy wzorców O pis wzorzec fasady Pozwala wykorzystać możliwości skomplikowanego systemu znacznie prościej, jednak w ograniczonym zakresie, lub tylko w pewien specyficzny sposób wzorzec adaptera Dostosowuje interfejs istniejących już obiektów do interfejsu, który jest wymagany przez inne obiekty wzorzec mostu Polega na usuwaniu powiązań m iędzy abstrakcją (np. struktura klas abstrakcyjnych figur geom etrycznych) a ich implementacją (biblioteki implementujące te klasy), tak aby obie mogły się zmieniać w sposób niezależny. wzorzec dekoratora Umożliwia dynamiczne dodawanie do obiektu nowych zachowań, które poprzedzają, lub następują, po bieżącym zachowaniu. wzorzec strategii Umożliwia wykorzystanie różnych algorytm ów wzorzec obserwatora Informuje jedną część system u o zmianach zachodzących w innej części wzorzec singletonu i W zorce te zapewniają wystąpienie w program ie jednej i tylko jednej wzorzec blokowania instancji danej klasy (także w system ach o architekturze dwufazowego wielowątkowej) wzorzec metody fabryki Umożliwia przeniesienie decyzji o utworzeniu obiektu do klas pochodnych wzorzec metody Dostarcza rozwiązania w chwili, gdy w programie pojawią się różne szablonu przypadki, w ykorzystujące te samą procedurę, która jednak macierz analizy zaim plem entowana jest w nieco inny sposób Jest to sposób zapisu wielu różnych zmienności występujących w danym problem ie i odwzorowaniu ich za pomocą wzorców 17 18

10 Wzorzec fasady fasada zapewnia jednolity interfejs dla podsystemu zawierającego wiele interfejsów definiuje bardzo ogólny interfejs, ułatwiając w ten sposób wykorzystanie podsystemu potrzebny jest nowy sposób interakcji z systemem (np. łatwiejszy w użyciu niż obecny) lub planuje się wykorzystać system w specyficzny sposób można stworzyć nowy sposób interakcji, wykorzystuje się jedynie podzbiór możliwości systemu wzorzec fasady tworzy nową strukturę przesłaniającą istniejący już system 19 Wzorzec fasady cechy charakterystyczne wzorca fasady intencja - uproszczenie sposobu korzystania z istniejącego systemu; zdefiniowanie własnego interfejsu problem zachodzi potrzeba wykorzystania jedynie podzbioru możliwości systemu rozwiązanie - dostarcza użytkownikowi nowego interfejsu dla istniejącego systemu uczestnicy i współpracownicy specjalizowany interfejs użytkownika, upraszczający wykorzystanie systemu konsekwencje fasada upraszcza korzystanie z systemu implementacja definiuje nową klasę lub klasy o pożądanym interfejsie; klasa ta wykorzystuje dla swojej implementacji funkcje istniejącego systemu 20

11 Wzorzec fasady fasada podzielenie systemu na podsystemy sprowadzenie do minimum komunikacji i zależności między podsystemami wprowadzenie obiektu fasada, zapewniającego jeden, uproszczony interfejs do wykonania bardziej ogólnych funkcji podsystemu stosowalność wzorca fasady: zapewnić prosty interfejs do złożonego systemu (prosty, domyślny widok podsystemu) istnieje wiele zależności miedzy klientami abstrakcji a klasami ja implementującymi fasada oddziela podsystem od klientów i innych podsystemów niezależność no podsystemu i jego przenośność ułożyć podsystemy warstwami fasada w celu zdefiniowania punktów wejścia do każdego poziomu podsystemu; również systemy mogą komunikować się miedzy sobą za pomocą fasady 21 diagram wzorca fasady Wzorzec fasady Klient A Klient B Fasada Bazy Danych Element Model Baza Danych 22

12 diagram wzorca fasady Wzorzec fasady Klasy podsystemu Fasada 23 Wzorzec fasady uczestnicy Fasada wie, jakie klasy podsystemu są odpowiedzialne za spełnienieżądania przekazujeżądania klienta do odpowiednich obiektów podsystemu Klasy podsystemu implementują funkcje podsystemu wykonują pracę przydzieloną przez obiekt klasy Fasada nic nie wiedzą o fasadzie nie przechowujążadnych odwołań do niej współpraca klienci komunikują się z podsystemem, wysyłając żądanie do fasady,która przekazuje je do odpowiednich obiektów podsystemu klienci wykorzystujący fasadę nie muszą mieć bezpośredniego dostępu do obiektów z jej podsystemu 24

13 Wzorzec fasady konsekwencje wzorzec fasady oddziela klientów od komponentów podsystemu, dzięki czemu zmiesza się ilość obiektów, z którymi klienci mają do czynienia, a podsystem staje się łatwiejszy do użycia sprzyja słabemu powiązaniu podsystemu z jego klientami słabe powiązanie umożliwia zmianę komponentów w sposób niewidoczny dla jego klientów nie umożliwiają aplikacjom bezpośredniego dostępu do klas podsystemu, jeśli go potrzebują implementacja zredukowanie powiązań klient-podsystem publiczne a prywatne klasy podsystemu 25 Wzorzec fasady przykład wzorca fasady FASADA Compiler Klasy podsystemu: Compiler Token Stream Scanner Symbol ByteCode Stream CodeGene rator Parser Program Node Stream Node Expressio nnode 26

14 Wzorzec fasady zastosowanie wzorca fasady wykorzystujemy jedynie podzbiór możliwości złożonego systemu i możemy utworzyć klasy opisujące sposób jego wykorzystania interfejs z zastosowaniem klas fasady powinien być dużo prostszy od wyjściowego interfejsu systemu wykorzystujemy możliwości systemu w ograniczony sposób należy ukryć przed obiektami użytkownika istnienie pewnego systemu oprócz wykorzystania istniejącej funkcjonalności systemu chcemy ją wzbogacić o nową funkcjonalność koszt utworzenia klas fasady jest mniejszy niż koszt zapoznania się ze skomplikowanym systemem przez jego przyszłych użytkowników 27 adapter Wzorzec adaptera dostosowanie interfejsu klasy do interfejsu, którego oczekuje użytkownik umożliwia współpracę klas, która bez jego zastosowania nie byłaby możliwa ze względu na ich niezgodne interfejsy znaleźć sposób na utworzenie nowego interfejsu dla obiektu, który osiada pożądaną funkcjonalność, ale ma nieodpowiedni interfejs 28

15 Wzorzec adaptera cechy charakterystyczne wzorca adaptera intencja - dopasowanie istniejącego obiektu do określonego interfejsu - sposobu wywołania problem obiekt przechowuje potrzebne dane oraz zachowuje się w pożądany sposób, jednak posiada nieodpowiedni interfejs; najczęściej musimy włączyć do hierarchii dziedziczenia pewnej klasy abstrakcyjnej, którą właśnie definiujemy lub posiadamy rozwiązanie - obudowuje obiekt pożądanym interfejsem uczestnicy i współpracownicy Adapter dostosowuje interfejs klasy Adaptowany tak, by był zgodny z interfejsem klasy bazowej Cel; umożliwia to Użytkownikowi wykorzystanie obiektu klasy Adaptowany oraz instancji klasy Cel konsekwencje zastosowanie wzorca pozwala dopasować istniejące obiekty do tworzonych struktur klas i uniknąć ograniczeń związanych z ich pierwotnym interfejsem implementacja zawiera istniejącą klasę w nowej klasie, która posiada wymagany interfejs i wywołuje odpowiednie metody zawieranej klasy 29 Wzorzec adaptera adapter często adapter jest odpowiedzialny za funkcjonalność, której nie ma adaptowana klasa stosowalność wzorca adaptera by wykorzystać istniejącą klasę, a jej interfejs nie odpowiada temu, który jest potrzebny by utworzyć klasę wielokrotnego użytku, która współpracuje z niepowiązanymi ze sobą lub nieprzewidzianymi klasami (takimi, które niekoniecznie maja zgodne interfejsy) (tylko adapter obiektów) gdy potrzeba użyć kilku istniejących podklas, ale zaadaptowanie ich interfejsów przez tworzenie ich podklas jest niepraktyczne adapter obiektów może adaptować interfejs swojej nadklasy 30

16 Wzorzec adaptera rodzaje adapterów adaptery obiektów adapter opiera się na zawieraniu obiektu jednej klasy przez obiekt innej klasy adaptery klas sposób implementacji wzorca wykorzystujący dziedziczenie wielobazowe zastosowanie wzorca adaptera wzorzec adaptera pozwala uniknąć zajmowania się interfejsami klas na etapie projektowania jeśli dana klasa realizuje na poziomie koncepcji wymaganie zadanie, to zawsze będzie można ją wykorzystać dzięki zastosowaniu odpowiedniego adaptera w celu uzyskania określonego interfejsu porównanie fasady i adaptera fasada upraszcza interfejs adapter dostosowuje interfejs do wcześniej wyspecyfikowanego 31 diagram wzorca adaptera Wzorzec adaptera adapter klas wykorzystuje wielodziedziczenie w celu zaadaptowania jednego interfejsu do drugiego Klient Cel + żądanie() Adaptowany + specyficzneżądanie() Adapter + żądanie() (implementacja) specyficzneżądanie() 32

17 diagram wzorca adaptera Wzorzec adaptera adapter obiektów wykorzystuje składanie obiektów Klient Cel + żądanie() Adaptowany + specyficzneżądanie() Adapter + żądanie() adaptowany Adaptowany.specyficzneŻądanie() 33 Wzorzec adaptera uczestnicy Cel definiuje specyficzny dla danej dziedziny interfejs używany przez klienta Klient współpracuje z obiektami dostosowanymi do interfejsu Cel Adaptowany definiuje istniejący interfejs, który wymaga zaadaptowania Adapter adaptuje interfejs Adaptowany do interfejsu Cel współpraca klienci wywołują operacje egzemplarza Adaptera z kolei adapter wywołuje operacje adaptowane, umożliwiające spełnienie żądania 34

18 przykład wzorca adaptera Wzorzec adaptera EdytorGraficzny Kształt + RamkaBrzegowa() WidokTekstu + PodajRozmiar() KształtLinia +RamkaBrzegowa() KształtTekst + RamkaBrzegowa() tekst ADAPTER (OBIEKTÓW) Żądania RamkaBrzegowa, zadeklarowane w klasie Kształt są przekształcane nażądania PodajRozmiar zdefiniowane w klasie WidokTekstu KształtTekst adaptuje WidokTekst do interfejsu klasy Kształt 35 Wzorzec adaptera konsekwencje adapter klas adaptuje Adaptowanego do celu, dostosowując się do klasy konkretnej Adaptowanego nie będzie działał wtedy, gdy będziemy chcieli zaadaptować klasę oraz jej wszystkie podklasy umożliwia Adapterowi przedefiniowanie części zachowania Adaptowanego, gdyż Adapter jest jego podklasą wprowadza tylko jeden obiekt, aby dostać się do Adaptowanego nie są potrzebne żadne dodatkowe odwołania poprzez wskaźnik adapter obiektów umożliwia jednemu Adapterowi działanie z wieloma Adaptowanymi, to znaczy z samą klasą Adaptowany i wszystkimi jej podklasami Adapter może także od razu dostać nową funkcjonalność do wszystkich Adaptowanych utrudnia przedefiniowanie zachowania Adaptowanego wymaga w tym celu tworzenia podklas Adaptowanego i odwoływania się Adaptera do nich, a nie do samego Adaptowanego 36

19 Inżynieria Oprogramowania Wykład 11 Wzorce projektowe Wzorce projektowe Kategorie wzorców projektowych Wzorce konstrukcyjne Tworzenie instancji: wzorzec fabryki abstrakcyjnej wzorzec singletonu wzorzec blokowania dwufazowego wzorzec metody fabryki Wzorce strukturalne Obsługa interfejsów: wzorzec fasady wzorzec adaptera Powiązanie implementacji i abstrakcji: wzorzec mostu wzorzec dekoratora 2

20 Wzorce projektowe Kategorie wzorców projektowych Wzorce czynnościowe Zawieranie zmienności: wzorzec strategii wzorzec obserwatora wzorzec metody szablonu 3 Wzorzec mostu most usuniecie powiązań pomiędzy abstrakcja i implementacja, aby obie mogły się zmieniać niezależnie usunięcie powiązań oznacza, że elementy stają się niezależne abstrakcja oznacza związki istniejące w warstwie koncepcji implementacja to obiekty, których używa klasa abstrakcyjna i jej klasy pochodne (wszystko to, co znajduje się na zewnątrz danych obiektów i jest przez nie używane wzorzec mostu znajduje zastosowanie w przypadku, gdy abstrakcja posiada wiele różnych sposobów implementacji pozwala zmieniać abstrakcję i implementację niezależnie od siebie 4

21 Wzorzec mostu cechy charakterystyczne wzorca mostu intencja - usuniecie powiązań pomiędzy zbiorem implementacji a zbiorem korzystających z nich obiektów problem klasy pochodne klasy abstrakcyjnej muszą używać wielu różnych implementacji tak, by nie spowodowało to nadmiernego wzrostu wyspecjalizowanych klas rozwiązanie - zdefiniowanie wspólnego interfejsu dla wszystkich implementacji i wykorzystaniu go przez klasy pochodne klasy abstrakcyjnej uczestnicy i współpracownicy Abstrakcja definiuje interfejs implementowanych obiektów; Implementacja definiuje interfejs dla klas stanowiących implementacje; obiekty klas pochodnych klasy Abstrakcja wykorzystują obiekty klas pochodnych klasy Implementacja (nie wiedząc przy tym, która z klas ImplementacjaKonkretna reprezentują) konsekwencje usuniecie powiązań pomiędzy różnymi implementacjami a obiektami, które je wykorzystują, ułatwia późniejszą rozbudowę oprogramowania, ponieważ obiekty nie posiadają już wiedzy na temat swojej implementacji implementacja hermetyzuje różne implementacje za pomocą klasy abstrakcyjnej; zawiera referencję do tej klasy wewnątrz klasy bazowej abstrakcji, która jest implementowana 5 Wzorzec mostu stosowalność wzorca mostu wzorzec mostu, gdy: uniknąć stałego owiązania abstrakcji z implementacją (np. w sytuacji, gdy implementacja musi być wybierana lub zmieniana w czasie wykonania programu) zarówno abstrakcje, jak i ich implementacje powinny dawać się rozbudowywać przez tworzenie podklas wzorzec umożliwia łączenie różnych abstrakcji z różnymi implementacjami i niezależne ich rozbudowywanie zamiany w implementacji abstrakcji nie powinny mieć żadnego wpływu na klientów ich programy nie powinny wymagać ponownej kompilacji ukryć całkowicie implementację abstrakcji przed klientami ma miejsce nadmierne rozmnażanie anie się klas chcemy, by wiele obiektów współdzieliło implementację i by ten fakt był ukryty przed klientem 6

22 Wzorzec mostu diagram wzorca mostu Abstrakcja + operacja() imp Implementacja + operacjaimp() AbstrakcjaRozwinięta + operacja() ImplementacjaKonkretnaA ImplementacjaKonkretnaB + operacjaimp() + operacjaimp() 7 Wzorzec mostu uczestnicy Abstrakcja definiuje interfejs abstrakcji zarządza odwołaniem do obiektu typu Implementacja AbstrakcjaRozwinięta rozszerza interfejs zdefiniowany przez Abstrakcję Implementacja definiuje interfejs klas implementujących, który nie musi dokładnie odpowiadać interfejsowi Abstrakcji interfejsy te mogą być dość różne; zwykle interfejs Implementacji określa jedynie operacje pierwotne, a Abstrakcja wykorzystujące je operacje wyższego poziomu ImplementacjaKonkretna implementuje interfejs klasy Implementacja i definiuje jej implementację konkretną współpraca Abstrakcja przesyłażądania klientów do swojego obiektu Implementacja 8

23 Wzorzec mostu konsekwencje oddzielenie interfejsu od implementacji implementacja nie jest na stałe związana z interfejsem; implementacja abstrakcji może być ustalana w czasie wykonywania programu lub obiekt może zmieniać swoja implementację nawet w czasie działania programu eliminuje też zależność w czasie kompilacji od określonej implementacji zmiana implementacji klasy nie wymaga ponownego skompilowania klasy Abstrakcja i jej klientów rozdzielenie to zachęca do podziału systemu na warstwy, co prowadzi do ulepszenia jego struktury ułatwiona rozszerzalność można niezależnie rozbudowywać hierarchie Abstrakcji i Implementacji ukrywanie szczegółów implementacji przed klientami można ukryć takie szczegóły implementacji, jak współdzielenie obiektów implementujących i związane z tym użycie liczników odwołań (o ile występuje) 9 Wzorzec mostu implementacja istnienie tylko jednej klasy Implementacja tworzenie właściwego obiektu implementacyjnego współdzielenie implementacji stosowanie wielodziedziczenia 10

24 przykład wzorca mostu Wzorzec mostu Most Okno + PiszTekst() imp ImplOkna + UrządzPiszTekst() OknoIkony + RysujRamkę() ImplOknaDlaX ImplOknaDlaPM + UrządzWypiszTekst() + UrządzWypiszTekst() 11 Wzorzec mostu strategie obiektowe wykorzystywane przez wzorzec mostu odpowiedzialność obiektów za siebie klasa abstrakcyjna klasy abstrakcyjne reprezentują koncepcje hermetyzacja za pomocą klasy abstrakcyjnej obiekty korzystające ze wzorca mostu nie posiadają wiedzy o istnieniu poszczególnych rodzajów np. figur klasa, np. biblioteka ukrywa (hermetyzuje) swoje pochodne przed obiektami reprezentującymi np. figury implementacja mostu w celu zdefiniowania interfejsów Java interfejs lub klasy abstrakcyjne C++ - klasy abstrakcyjne zastosowanie wzorca mostu przykład zastosowania strategii obsługi zmienności (zmienność klas/obiektów) zalecających: odnalezienie zmienności i jej hermetyzowanie stosowanie kompozycji zamiast dziedziczenia 12

25 Wzorzec dekoratora dekorator, łańcuch obiektów dodanie nowych rodzajów odpowiedzialności do obiektu w dynamiczny sposób oferuje rozwiązanie alternatywne do tworzenia klas pochodnych w celu rozszerzenia funkcjonalności obiektu wzorzec dekoratora umożliwia utworzenie łańcucha obiektów zaczynając od obiektu dekoratora, czyli obiektu odpowiedzialnego za nową funkcjonalność i kończącego się obiektem wyjściowym każdy dekorator obudowuje poprzedzający go obiekt w celu dostarczenia nowej funkcjonalności ci dekorator wykonuje dodatkowa operację albo przed operacją, która dekoruje, albo po tej operacji 13 dekorator Wzorzec dekoratora dynamicznie dołącza do obiektów dodatkowe zobowiązania zapewnia elastyczną alternatywę dla tworzenia podklas w celu rozszerzenia funkcjonalności dekorator to jakby otoczka komponentu dekorator dostosowuje się do interfejsu ozdabianego komponentu, dzięki czemu staje się przezroczysty dla klientów komponentu przekazuje żądania do komponentu i może wykonywać dodatkowe akcje przed lub po przekazaniużądania przeźroczystość umożliwia rekurencyjne zagnieżdżanie dekoratorów, a tym samym dodanie nieograniczonej liczby zobowiązań 14

26 Wzorzec dekoratora stosowalność wzorca dekoratora by dynamicznie i w przezroczysty sposób (tzn. nie wpływający na inne obiekty) dodać zobowiązania do pojedynczych obiektów w wypadku zobowiązań, które mogą być cofnięte gdy rozszerzanie przez definiowanie podklas jest niepraktyczne zbyt duży wzrost liczby klas; definicja klasy może być też ukryta lub inaczej niedostępna, jeśli chodzi o tworzenie podklas 15 Wzorzec dekoratora cechy charakterystyczne wzorca dekoratora intencja - dynamiczne rozszerzenie odpowiedzialności obiektu problem istniejący już obiekt posiada podstawową funkcjonalność, zachodzi jednak potrzeba rozszerzenia jej o operacje wykonywane przed lub po wykonywanych dotąd przez obiekt działaniach rozwiązanie - rozszerzenie funkcjonalności obiektu bez konieczności dziedziczenia uczestnicy i współpracownicy KomponentKonkretny otrzymuje rozbudowaną funkcjonalność dzięki zastosowaniu obiektów Dekorator; czasami podstawową funkcjonalność obiektu zapewniają klasy pochodne klasy KomponentKonkretny (w takim przypadku jest ona klasą abstrakcyjną); Komponent definiuje wspólny interfejs dla wszystkich wymienionych klas 16

27 Wzorzec dekoratora cechy charakterystyczne wzorca dekoratora... konsekwencje nowa funkcjonalność mieści się w niewielkich obiektach; zaletą jest możliwość jej dodania przed lub po podstawowej funkcjonalności obiektu KomponentKonkretny implementacja polega na utworzeniu klasy abstrakcyjnej reprezentującej klasę wyjściową oraz nowe zachowania, które mają być do niej dodane; aby uzyskać odpowiedni porządek wykonania nowych operacji w stosunku do już istniejących, umieszczamy je w dekoratorach przed lub po wywołaniu metod obiekty wyjściowego 17 diagram wzorca dekoratora Wzorzec dekoratora Komponent 1 + operacja() KomponentKonkretny Dekorator + operacja() + operacja() 1..0 komponent DekoratorKonkretnyA - dodatkowystan + operacja() DekoratorKonkretnyB + operacja() + dodatkowezachowanie() 18

28 Wzorzec dekoratora uczestnicy Komponent definiuje interfejs obiektów, do których można dynamicznie dołączyć zobowiązania KomponentKonkretny definiuje obiekt, do którego można dołączyć dodatkowe zobowiązania Dekorator zarządza odwołaniem do obiektu Komponent i definiuje interfejs dostosowany do interfejsu Komponentu DekoratorKonkretny dodaje zobowiązania do Komponentu współpraca Dekorator przesyła żądania do swojego obiektu Komponent; może wykonywać dodatkowe operacje przed lub po przesłaniużądania 19 Wzorzec dekoratora konsekwencje większa elastyczność niż przy stosowaniu statycznego dziedziczenia można dodawać i usuwać zobowiązania w czasie wykonywana programu przez zwykłe dołączanie ich i odłączanie, a dziedziczenie wymaga tworzenia nowej klasy w wypadku każdego nowego zobowiązania dekoratory ułatwiają dwukrotne dołączanie właściwości unikanie przeładowanych właściwościami klas na szczycie hierarchii zamiast uwzględniać wszystkie przewidywane własności w złożonej, dającej się dostosowywać klasie, można zdefiniować prosta klasę i przyrostowo rozszerzać jej funkcjonalność za pomocą obiektów Dekorator dekorator i jego komponent nie są identyczne dekorator działa jak przezroczysta otoczka, ale z punktu widzenia identyczności obiektów udekorowany komponent nie jest taki sam jak wyjściowy wiele małych obiektów wiele małych, podobnych do siebie obiektów obiekty te różnią się tylko tym, jak są ze sobą połączone, a nie swoimi klasami czy wartościami zmiennych 20

29 Wzorzec dekoratora implementacja zgodność interfejsów interfejs obiektu będącego dekoratorem musi odpowiadać interfejsowi dekorowanego przez niego komponentu pomijanie klasy abstrakcyjnej Dekorator gdy dodanie tylko jednego zobowiązania, to nie trzeba definiować klasy abstrakcyjnej Dekorator, a włączyć zobowiązanie Dekoratora (polegające na przesłaniu żądań do komponentu) do KonkretnegoDekoratora utrzymywanie klas Komponent w wadze lekkiej komponenty i dekoratory pochodzą od wspólnej klasy Komponent, a zadanie tej klasy powinno polegać na definiowaniu interfejsu, a nie na przechowywaniu danych (określenie reprezentacji danych w podklasach) 21 przykład wzorca dekoratora Wzorzec dekoratora KomponentWizualny 1 + Rysuj() WidokTekstowy + Rysuj() Dekorator + Rysuj() 1..0 komponent DekoratorZSuwakami - pozycjasuwaka + Rysuj() + PrzewińDo() DekoratorZRamkami - szerokośćramki + Rysuj() + RysujRamkę() 22

30 zastosowanie wzorca dekoratora Wzorzec dekoratora pomaga dokonać rozkładu problemu na dwie części związane z: implementacją obiektów udostępniających nową funkcjonalność takim sposobem organizacji tych obiektów w programie, która umożliwi uzyskanie odpowiedniego rezultatu w konkretnych przypadkach innym zastosowaniem jest obsługa operacji wejścia/wyjścia wzorzec dekoratora daje możliwość zastosowania rozwiązania umożliwiającego dynamiczne wzbogacanie funkcjonalności istniejących już obiektów jego zastosowanie sprowadza się do skonstruowania łańcucha obiektów odpowiedzialnych za określone zachowania użytkownik, który nie ma nic wspólnego z procesem konstrukcji łańcucha, wywołuje metody pierwszego jego elementu 23 Wzorzec fabryki abstrakcyjnej fabryka abstrakcyjna dostarczenie interfejsu służącego do tworzenia rodzin powiązanych ze sobą lub niezależnych od siebie obiektów bez konieczności wyspecyfikowania ich klas konkretnych stosowana w celu tworzenia rodzin obiektów utworzenie odpowiedniego zestawu obiektów w każdej z wymaganych (potrzebnych) sytuacji (przypadków) rodziny obiektów wynikają z dziedziny problemu, która określa, jakie obiekty są niezbędne w określonym przypadku 24

31 Wzorzec fabryki abstrakcyjnej fabryka abstrakcyjna obiekt użytkownika musi jedynie wiedzieć, od jakiego obiektu powinien zażądać utworzenia potrzebnych mu obiektów i w jaki sposób ich użyć klasa fabryki abstrakcyjnej specyfikuje to, jakie obiekty mogą być tworzone poprzez zdefiniowanie dla każdego rodzaju obiektów odpowiedniej metody o tym, jakie obiekty są tworzone decydują klasy konkretne fabryki abstrakcyjnej 25 Wzorzec fabryki abstrakcyjnej stosowalność wzorca fabryki abstrakcyjnej system powinien być niezależny od tego, jak jego produkty sa tworzone, składane i reprezentowane system powinien być konfigurowalny przy użyciu jednej z wielu rodzin produktów rodzina związanych ze sobą obiektów-produktów jest zaprojektowana tak, by te obiekty były używane razem, a nam zależy na zachowaniu tego ograniczenia chcemy dostarczyć bibliotekę klas produktów, ujawniając jedynie ich interfejsy, a nie implementacje 26

32 Wzorzec fabryki abstrakcyjnej cechy charakterystyczne wzorca fabryki abstrakcyjnej intencja - uzyskanie rodzin obiektów właściwych w określonym przypadku problem utworzenie odpowiednich rodzin obiektów rozwiązanie - koordynuje utworzenie rodzin obiektów; podsuwa sposób pozwalający wydzielić z rodzin obiektów użytkownika reguły tworzenia obiektów, które są przez nie używane uczestnicy i współpracownicy FabrykaAbstrakcyjna definiuje interfejs określający sposób utworzenia każdego obiektu z danej rodziny; typowo każda z rodzin obiektów posiada własną klasę FabrykaKonkretna konsekwencje wzorzec izoluje reguły opisujące sposób wykorzystania obiektów od reguł decydujących o utworzeniu tych obiektów implementacja definiuje klasę abstrakcyjną, która specyfikuje tworzone obiekty; następnie dla każdej z rodzin obiektów implementuje się klasę konkretną 27 Wzorzec fabryki abstrakcyjnej diagram wzorca fabryki abstrakcyjnej Klient ProduktAbstrakcyjnyA ProduktAbstrakcyjnyB ProduktA1 ProduktA2 ProduktB1 ProduktB2 FabrykaAbstrakcyjna + utwórzprodukta() + utwórzproduktb() FabrykaKonkretna1 + utwórzprodukta() + utwórzproduktb() FabrykaKonkretna2 + utwórzprodukta() + utwórzproduktb() 28

33 Wzorzec fabryki abstrakcyjnej fabryka abstrakcyjna takie rozwiązanie (diagram wzorca fabryki abstrakcyjnej) upraszcza i ukrywa implementację oraz sprawia, że system jest łatwiejszy w utrzymaniu: klient nie posiada wiedzy dotyczącej, którą z implementacji obiektów w rzeczywistości wykorzystuje odpowiedzialność za ich utworzenie ponosi obiekt fabryki klient nie posiada wiedzy na temat tego, którą z fabryk wykorzystuje istnienie klas FabrykaKonkretna1 i FabrykaKonkretna2 ukryte przed nim za pomocą klasy FabrykaAbstrakcyjna 29 Wzorzec fabryki abstrakcyjnej uczestnicy FabrykaAbstrakcyjna deklaruje interfejs tworzenia produktów abstrakcyjnych FabrykaKonkretna implementuje operacje tworzenia produktów konkretnych ProduktAbstrakcyjny deklaruje interfejs dla pewnego rodzaju produktu ProduktKonkretny definiuje obiekt będący produktem, który ma być utworzony przez odpowiednią fabrykę konkretną implementuje interfejs klasy ProduktAbstrakcyjny Klient używa jedynie interfejsów zadeklarowanych przez klasy FabrykaAbstrakcyjna i ProduktAbstrakcyjny 30

34 Wzorzec fabryki abstrakcyjnej współpraca podczas wykonywania programu jest zwykle tworzony jeden egzemplarz klasy FabrykaKonkretna; ta fabryka konkretna tworzy obiekty-produkty o pewnej szczególnej implementacji; aby utworzyć inne produkty, klienci powinni skorzystać z innej fabryki konkretnej FabrykaAbstrakcyjna zdaje się w kwestii tworzenia produktów na swoją podklasę (klasę FabrykaKonkretna) 31 konsekwencje Wzorzec fabryki abstrakcyjnej odseparowanie klas konkretnych fabryka kapsułkuje odpowiedzialność o proces tworzenia obiektów- produktów, izoluje klientów od klas implementujących klienci posługują się egzemplarzami fabryk za pomocą interfejsów abstrakcyjnych nazwy klas produktów są wyodrębnione w implementacji fabryki konkretnej łatwiejsza wymiana rodzin produktów klasa fabryki konkretnej pojawia się w aplikacji tylko raz, tam, gdzie są tworzone jej obiekty to umożliwia łatwą zmianę fabryki konkretnej używanej przez aplikację aplikacja może wykorzystywać różne konfiguracje produktów, zmieniając fabrykę konkretną; pociąga to za sobą zmianę całej rodziny produktów spójność produktów produkty w rodzinie mają współdziałać, to aplikacja używa za jednym razem obiektów tylko z danej rodziny 32

35 Wzorzec fabryki abstrakcyjnej konsekwencje... utrudnione dołączanie nowych rodzajów produktów rozszerzenie fabryk abstrakcyjnych w celu stworzenia nowych rodzajów Produktów nie jest łatwe interfejs FabrykiAbstrakcyjnej ustala zbiór obiektów, które mogą być utworzone obsługa nowych rodzajów produktów wymaga rozszerzenia interfejsu fabryki, co pociąga zmianę klasy FabrykaAbstrakcyjna i wszystkich jej podklas 33 Wzorzec fabryki abstrakcyjnej implementacja fabryki jako singletony aplikacja zwykle potrzebuje tylko jednego egzemplarza klasy FabrykaKonkretna na rodzinę produktów tworzenie produktów klasa FabrykaAbstrakcyjna jedynie deklaruje interfejs tworzenia produktów; faktycznie tworzenie ich należy do podklas ProduktKonkretny definiowanie rozszerzalnych fabryk klasa FabrykaAbstrakcyjna definiuje zwykle oddzielną operację dla każdego rodzaju produktu; rodzaje produktów są zakodowane w sygnaturach operacji; dodanie nowego rodzaju produktu wymaga zmiany interfejsu klasy FabrykaAbstrakcyjna i zmian we wszystkich kasach, które od niej zależą 34

36 Wzorzec fabryki abstrakcyjnej przykład wzorca fabryki abstrakcyjnej Klient Okno Suwak OknoWStyluPM OknoMotif SuwakPM SuwakMotif FabrykaWidżetów + stwórzokno() + stwórzsuwak() FabrykaWidżetówPM + stwórzokno() + stwórzsuwak() FabrykaWidżetówMotif + stwórzokno() + stwórzsuwak() 35 Wzorzec fabryki abstrakcyjnej strategie użyte w analizie i projektowaniu, których zastosowanie doprowadziło do uzyskania rozwiązania zania w postaci fabryki abstrakcyjnej: znajdź, co się zmienia i hermetyzuj to stosuj raczej kompozycję niż dziedziczenie projektuj wykorzystując interfejsy, a nie implementacje wzorzec fabryki abstrakcyjnej określa nowy rodzaj dekompozycji dekompozycja według odpowiedzialności jej zastosowanie prowadzi do rozkładu problemu na: cześć, która wykorzystuje tworzone obiekty cześć, która decyduje o utworzeniu obiektów 36

37 Wzorzec fabryki abstrakcyjnej zastosowanie wzorca fabryki abstrakcyjnej wzorzec fabryki abstrakcyjnej można zastosować w przypadku wykorzystania pewnego podsystemu przez różne aplikacje obiekt fabryki przekazywany do podsystemu i wykorzystywany do podjęcia decyzji o użyciu określonych obiektów występowanie w dziedzinie problemu różnych rodzin obiektów, z których każda wykorzystywana jest w innych warunkach występowanie różnych rodzin obiektów może być związane z: wykorzystanie różnych systemów operacyjnych (aplikacje pracujące na różnych platformach) różne wymagania dotyczące efektywności różne wersje aplikacji różna funkcjonalność aplikacji dla różnych użytkowników 37 Wzorzec fabryki abstrakcyjnej zastosowanie wzorca fabryki abstrakcyjnej wzorzec fabryki abstrakcyjnej, gdy zachodzi potrzeba skoordynowania procesu tworzenia rodzin obiektów wzorzec pozwala na wyodrębnienie reguł dotyczących tworzenia obiektów z obiektów użytkownika, które będą wykorzystywać tworzone obiekty w tym celu należy: zidentyfikować reguły tworzenia obiektów i utworzyć klasę abstrakcyjną, której interfejs będzie zawierać osobną metodę dla każdego z tworzonych obiektów zaimplementować jej klasy pochodne dla każdej z rodzin obiektów stworzyć fabrykę, która klient będzie wykorzystywać do tworzenia rodzin obiektów 38

38 Wzorzec singletonu singleton zapewnienie, że klasa posiada tylko jedną instancję oraz dostarczenie globalnego punktu dostępu do tej instancji wzorzec singletonu umożliwia utworzenie dokładnie jednej instancji danej klasy i nie wymaga od obiektów użytkownika, by wiedziały, czy instancja ta została już utworzona działanie singletonu opiera się na wykorzystaniu specjalnej metody w celu tworzenia obiektu metoda ta sprawdza, czy obiekt został już utworzony; jeśli tak, to zwraca referencję do tego obiektu, a w przeciwnym wypadku tworzy instancję i do niej tworzy referencję aby zapewnić, żee wywołanie tej metody jest jedynym sposobem utworzenia obiektu, konstruktor klasy deklaruje się jako metodę o dostępie chronionym lub prywatnym 39 stosowalność wzorca singletonu Wzorzec singletonu klasa musi mieć jeden egzemplarz, dostępny dla jej klientów powinno być możliwe rozbudowywanie tego jedynego egzemplarza przez definiowanie podklas, a klienci powinni móc używać rozszerzonego egzemplarza bez modyfikowania swojego kodu 40

39 Wzorzec singletonu cechy charakterystyczne wzorca singletonu intencja - w programie tylko jeden obiekt danej klasy i jego wystąpienie nie powinno być kontrolowane przez inny obiekt problem wiele różnych obiektów użytkownika wykorzystuje obiekt, który powinien być jedną instancją danej klasy w programie rozwiązanie - zapewnienie wystąpienia tylko jednej instancji klasy uczestnicy i współpracownicy użytkownik tworzy instancję singletonu wyłącznie za pomocą metody pobierzinstancje konsekwencje użytkownik nie musi wiedzieć, czy instancja singletonu już istnieje; singleton sam zajmuje się utworzeniem instancji, jeśli jest to konieczne 41 Wzorzec singletonu cechy charakterystyczne wzorca singletonu... implementacja deklarujemy w klasie statyczną zmienną o dostępie prywatnym, która stanowić będzie referencję (początkowo pustą) do jedynej instancji klasy deklarujemy metodę statyczną o dostępie publicznym, która tworzy instancję klasy w przypadku, gdy powyższa referencja jest pusta i inicjuje ją oraz zwraca wartość referencji konstruktor klasy deklarujemy jako metodę o dostępie prywatnym lub chronionym, aby zapobiec możliwości obejścia mechanizmu tworzenia jednej instancji klasy przez bezpośrednie wywołanie konstruktora 42

40 Wzorzec singletonu diagram wzorca singletonu Singleton - static jedynyegzemplarz - danesingletonu + static egzemplarz() + singletonoperacja() + pobierzdanesingletonu 43 Wzorzec singletonu uczestnicy Singleton definiuje operację egzemplarz(), umożliwiającą klientom uzyskiwanie dostępu do tego unikatowego egzemplarza; egzemplarz() jest operacją klasową (statyczną) może być odpowiedzialny za tworzenie swojego jedynego egzemplarza współpraca klienci dostają się do egzemplarza Singletonu wyłącznie poprzez operację egzemplarz() zdefiniowaną w tej klasie 44

41 Wzorzec singletonu konsekwencje kontrolowany dostęp do jedynego egzemplarza klasa Singleton kapsułkuje swój jedyny egzemplarz może kontrolować to, jak i kiedy klienci dostają się do niego mniejsza przestrzeń nazw wzorzec Singletonu stanowi ulepszenie rozwiązania ze zmienną globalną uniknięcie zanieczyszczenia przestrzeni nazw zmiennymi globalnymi przechowującymi jedyne egzemplarze możliwe udoskonalanie operacji i reprezentacji można tworzyć podklasy klasy Singleton zmienna liczba egzemplarzy można zdecydować się na więcej niż jeden egzemplarz klasy Singleton lub użyć tego samego rozwiązania, by kontrolować liczbę egzemplarzy używanych przez aplikację większa elastyczność niż w przypadku operacji klasowych (statycznych) inny sposób opakowania funkcjonalności singletonu to użycie operacji klasowych 45 Wzorzec singletonu implementacja zagwarantowanie unikatowego egzemplarza tworzenie podklas klasy Singleton 46

42 Wzorzec singletonu zastosowanie wzorca singletonu jedyny egzemplarz danej klasy i dostęp do niego 47 Wzorzec blokowania dwufazowego wersja wzorca singletonu przeznaczona do wykorzystania w aplikacjach wielowątkowych wątki mogą tworzyć w tym samym czasie kilka instancji tej samej klasy rozwiązanie wprowadzenie synchronizacji po sprawdzeniu warunku istnienia singletonu, a następnie powtórne sprawdzenie tego, czy obiekt nie został już utworzony uniknięcie niepotrzebnego blokowania wątków 48

43 Inżynieria Oprogramowania Wykład 12 Wzorce projektowe Kategorie wzorców projektowych Wzorce konstrukcyjne Tworzenie instancji: Wzorce projektowe wzorzec fabryki abstrakcyjnej wzorzec singletonu wzorzec blokowania dwufazowego wzorzec metody fabryki Wzorce strukturalne Obsługa interfejsów: wzorzec fasady wzorzec adaptera Powiązanie implementacji i abstrakcji: wzorzec mostu wzorzec dekoratora 2

44 Wzorce projektowe Kategorie wzorców projektowych Wzorce czynnościowe Zawieranie zmienności: wzorzec strategii wzorzec obserwatora wzorzec metody szablonu 3 Wzorzec metody fabryki metoda fabryki zdefiniowanie interfejsu służącego do tworzenia obiektu, ale pozostawienie klasom pochodnym decyzji odnośnie tego, jaki obiekt należy utworzyć umieszcza decyzję o utworzeniu fabryki w klasach pochodnych klasy mogą zdać się na podklasy w kwestii tworzenia egzemplarzy inaczej: metoda wytwórcza zadanie wzorca metody fabryki polega na określeniu odpowiedzialności za utworzenie odpowiednich obiektów 4

45 Wzorzec metody fabryki cechy charakterystyczne wzorca metody fabryki intencja - zdefiniowanie interfejsu służącego do stworzenia obiektu, ale pozostawienie decyzji o klasie tworzonego obiektu klasom pochodnym problem klasa musi utworzyć obiekt jednej z klas pochodnych innej klasy, ale nie wie dokładnie, o którą z nich chodzi; metoda fabryki pozwala podjąć tę decyzję jej klasie pochodnej rozwiązanie - klasa pochodna podejmuje decyzje o klasie i sposobie utworzenia obiektu uczestnicy i współpracownicy Produkt określa interfejs obiektu tworzonego przez metodę fabryki; Kreator definiuje interfejs zawierający metodę fabryki konsekwencje aby utworzyć obiekt klasy ProduktKonkretny, należy utworzyć klasę pochodną klasy Kreator implementacja wykorzystuje abstrakcyjną metodę klasy abstrakcyjnej; klasa abstrakcyjna używa tej metody, kiedy musi utworzyć odpowiedni obiekt, ale nie wie, jaki obiekt będzie w rzeczywistości utworzony 5 Wzorzec metody fabryki stosowalność wzorca metody fabryki: klasa nie może przewidzieć, jakich klas obiekty musi tworzyć klasa chce, by to jej podklasy specyfikowały tworzone przez nią obiekty klasy przekazują odpowiedzialność jednej z kilku podklas pomocniczych, a my chcemy tylko w jednym miejscu ustalić, która z podklas pomocniczych jest ich delegatem 6

46 Wzorzec metody fabryki diagram wzorca metody fabryki metoda wytwórcza Produkt Twórca + metodafabryki() + operacja() w kodzie metody operacja() wystąpi: produkt = metodafabryki()... ProduktKonkretny TwórcaKonkretny + metodafabryki() + operacja() return new ProduktKonkretny metoda wytwórcza 7 Wzorzec metody fabryki uczestnicy Produkt definiuje interfejs obiektów tworzonych przez metodę wytwórczą ProduktKonkretny implementuje interfejs z klasy Produkt Twórca deklaruje metodę fabryki (metodę wytwórczą), która przekazuje obiekt typu Produkt może też definiować domyślną implementację metody fabryki, która przekazuje pewien domyślny obiekt klasy ProduktKonkretny TwórcaKonkretny przedefiniowuje metodę fabryki, żeby przekazywała obiekt klasy ProduktKonkretny współpraca Twórca polega na swoich podklasach w kwestii takiego definiowania metody fabryki, by przekazywała egzemplarz dopowiedniej klasy ProduktKonkretny 8

47 Wzorzec metody fabryki konsekwencje metoda fabryki eliminuje potrzebę wstawiania specyficznych dla danej aplikacji klas w kod kod odwołuje się jedynie do interfejsu klasy Produkt, dlatego może działać z dowolną zdefiniowaną klasą ProduktKonkretny potencjalną wadą jest to, że klienci mogą być zmuszeni tworzyć podklasę klasy Twórca tylko po to, by powstał określony obiekt klasy ProduktKonkretny zapewnienie punktów zaczepienia dla podklas tworzenie obiektów wewnątrz klasy za pomocą metody fabryki bardziej elastyczne niż tworzenie ich bezpośrednio; wzorzec daje podklasom punkt zaczepienia do dostarczania rozszerzonej wersji obiektu łączenie równoległych hierarchii klas równoległe hierarchie klas powstają wtedy, gdy klasa przekazuje niektóre ze swoich zobowiązań odrębnej klasie 9 implementacja Wzorzec metody fabryki dwie główne odmiany wzorca klasa Twórca jest klasą abstrakcyjną i nie zapewnia implementacji dla deklarowanej przez siebie metody fabryki podklasy muszą definiować własną implementację, ponieważ nie ma implementacji domyślnej (pozwala to obejść problem konieczności tworzenia egzemplarzy klas, których istnienia nie jesteśmy w stanie przewidzieć) klasa Twórca jest klasą konkretną i zapewnia domyślną implementację metody fabryki klasa TwórcaKonkretny używa metody fabryki głownie ze względu na elastyczność (projektanci klas mogą zmienić, jeśli to konieczne, klasę obiektów tworzonych przez nadklasę) sparametryzowane metody wytwórcze inna odmiana wzorca umożliwia metodzie wytwórczej tworzenie wielu rodzajów produktów metoda wytwórcza ma parametr identyfikujący rodzaj tworzonego obiektu wszystkie obiekty tworzone przez nią odwołują się wspólnie do interfejsu z klasy Produkt 10

48 Wzorzec metody fabryki implementacja... odmiany wzorca i problemy specyficzne dla poszczególnych języków programowania różne języki nadają się do różnych odmian wzorca w Smalltaku stosuje się metodę przekazującą klasę, której egzemplarze mają być tworzone metoda wytwórcza Twórcy może używać tej wartości do tworzenia produktu, a TwórcaKonkretny może pamiętać, a nawet wyliczyć tą wartość metody wytwórcze w C++ są zawsze funkcjami wirtualnymi, a często funkcjami czysto wirtualnymi; należy tylko pamiętać, by nie wywoływać metody wytwórczej w konstruktorze klasy Twórca, bo metoda wytwórcza z klasy TwórcaKonkretny nie będzie dostępna uzywanie szablonów w celu uniknięcia tworzenia podklas zapewnienie szablonu podklasy Twórca, sparametryzowanego klasą Produktu, by nie tworzyć podklas tylko po to, by powstały obiekty odpowiedniej klasy Produkt (klient podaje jedynie odpowiednią klasę produktu nie ma potrzeby tworzenia podklas Twórcy) konwencje nazewnicze używać konwencji nazewniczych wskazujących na to,że zostały użyte metody wytwórcze 11 Wzorzec metody fabryki przykład wzorca metody fabryki metoda wytwórcza Dokument + otwórz() + zamknij() dokumenty Aplikacja + stwórzdokument() + otwórzdokument() w kodzie metody operacja() wystąpi: Dokument* dok = stwórzdokument() MójDokument MojaAplikacja + stwórzdokument() + nowydokument() return new MójDokument 12

49 Wzorzec metody fabryki zastosowanie wzorca metody fabryki decyzję o utworzeniu obiektu pozostawić klasom pochodnym możliwość utworzenia w programie hierarchicznej struktury klas z dodatkowymi rodzajami odpowiedzialności w stosunku do już istniejących w celu definiowania szkieletów aplikacji 13 Wzorzec strategii strategia pozwala zmieniać algorytmy niezależnie od wykorzystujących je obiektów zdefiniowanie rodziny algorytmów, zastosowanie hermetyzacji dla każdego z nich i stosowanie ich wymiennie wzorzec strategii umożliwia zdefiniowanie rodziny algorytmów na poziomie koncepcji algorytmy te realizują to samo zadanie, różnią się jedynie implementacją strategia pozwala hermetyzować różne reguły za pomocą klasy abstrakcyjnej i posiadać rodzinę różnych algorytmów reprezentowanych przez klasy pochodne 14

50 Wzorzec strategii cechy charakterystyczne wzorca strategii intencja - użycie rożnych reguł biznesowych lub wersji algorytmów w zależności od kontekstu problem wybór algorytmu zależy od używającego go obiektu lub danych, na których operuje; jeśli algorytm nie zmienia się, to wzorzec strategii nie jest potrzebny rozwiązanie - separuje wybór wersji algorytmu od jego implementacji; umożliwia wybór algorytmu na podstawie kontekstu uczestnicy i współpracownicy Strategia specyfikuje sposób użycia różnych algorytmów StrategiaKonkretna implementuje określony rodzaj algorytmu Kontekst korzysta z obiektu klasy StrategiaKonkretna odwołując się do niego jak do obiektu klasy Strategia; Strategia i Kontekst współdziałają w wyborze algorytmu (czasami Strategia musi w tym celu skierować odpowiednie żądanie do klasy Kontekst); Kontekst przekazuje żądania korzystających z niego obiektów klasie Strategia 15 Wzorzec strategii cechy charakterystyczne wzorca strategii... konsekwencje strategia definiuje rodzinę algorytmów; instrukcje wyboru i instrukcje warunkowe mogą zostać wyeliminowane; wszystkie algorytmy muszą być wywoływane w ten sam sposób (muszą mieć ten sam interfejs; interakcja pomiędzy klasą StrategiaKonkretna a klasą Kontekst może wymagać dodania metody pobierzstan do klasy Kontekst implementacja klasa, która używa algorytmu (Kontekst) zawiera klasę abstrakcyjną (Strategia), która posiada metodę abstrakcyjną określającą sposób wywołania algorytmu; każda z jej klas pochodnych implementuje algorytm we własnym zakresie 16

51 Wzorzec strategii stosowalność wzorca strategii wiele powiązanych ze sobą klas różni się tylko zachowaniem strategie umożliwiają konfigurowanie klasy za pomocą jednego z wielu zachowań potrzebne są różne warianty jakiegoś algorytmu; wzorca strategii można użyć, gdy warianty te są zaimplementowane jako hierarchia klas algorytmów w algorytmie używane są dane, o których klient nie powinien wiedzieć; wzorzec strategii pozwala uniknąć ujawniania złożonych i specyficznych dla algorytmu struktur danych klasa definiuje wiele zachowań, które w operacjach są uwzględnione w postaci wielokrotnych instrukcji warunkowych; zamiast używać tych instrukcji, można przenieść powiązane ze sobą rozgałęzienia warunkowe do ich klas Strategia 17 Wzorzec strategii diagram wzorca strategii Kontekst + interfejskonteksu() strategia Strategia + interfejsalgorytmu() StrategiaKonkretnaA StrategiaKonkretnaB StrategiaKonkretnaC + interfejsalgorytmu() + interfejsalgorytmu() + interfejsalgorytmu() 18

52 uczestnicy Wzorzec strategii Strategia deklaruje interfejs wspólny dla wszystkich obsługiwanych algorytmów Kontekst wykorzystuje ten interfejs do wykonywania algorytmu zdefiniowanego przez StrategięKonkretną StrategiaKonkretna implementuje algorytm, wykorzystując interfejs z klasy Strategia Kontekst jest konfigurowalny za pomocą obiektu StrategiaKonkretna utrzymuje odwołanie do obiektu Strategia może definiować interfejs umożliwiający Strategii uzyskanie dostępu do jego danych 19 Wzorzec strategii współpraca klasy Strategia i Kontekst współdziałają w celu zaimplementowania wybranego algorytmu w chwili wywoływania algorytmu Kontekst może przekazać Strategii wszystkie dane potrzebne do realizacji tego algorytmu lub też Kontekst przekazuje operacjom Strategii samego siebie jako argument; umożliwia to Strategii zwrotne odwoływanie się w miarę potrzeb do kontekstu Kontekst przekazuje żądania od klientów do swojej Strategii; klienci zwykle tworzą obiekt StrategiaKonkretna i przekazują go do Kontekstu; potem komunikują się wyłącznie z Konteksem 20

53 Wzorzec strategii konsekwencje rodziny powiązanych ze sobą algorytmów hierarchie klas Strategia definiują rodzinę algorytmów lub zachowań do wielokrotnego użycia przez Konteksty (uwypuklenie wspólnej funkcjonalności tych algorytmów) alternatywa dla tworzenia podklas dziedziczenie zapewnia inny sposób uwzględnienia różnorodności algorytmów lub zachowań; można bezpośrednio utworzyć podklasy klasy Kontekst, aby nadać kontekstowi różne zachowanie (zachowanie jest sztywno zapisane w Kontekście) niemożliwe dynamiczne zmienianie algorytmów); zakapsułkowanie algorytmu w oddzielnych klasach Strategia umożliwia modyfikowanie go niezależnie od jego kontekstu strategie eliminują instrukcje warunkowe wzorzec strategii to alternatywa dla instrukcji warunkowych w celu wybrania pożądanego zachowania wybór implementacji strategie mogą zapewnić różne implementacje tego samego zachowania 21 Wzorzec strategii konsekwencje... klienci muszą byćświadomi istnienia różnych strategii koszty związane zane z komunikacją między Strategią a Kontekstem interfejs Strategii jest współdzielony przez wszystkie klasy StrategiaKonkretna i czasami Kontekst będzie tworzył i inicjował parametry, które nigdy nie będą użyte zwiększona liczba obiektów strategie zwiększają liczbę obiektów występujących w aplikacji implementacja definiowanie interfejsów Strategii i Kontekstu interfejsy tych klas muszą umożliwić StrategiiKonkretnej efektywny dostęp do dowolnych danych, jakich będzie potrzebować z Kontekstu i odwrotnie strategie jako parametry szablonów w C++ można wykorzystać szablony do konfigurowania klas za pomocą strategii doprowadzenie do tego, by obiekty Strategia były opcjonalne 22

54 Wzorzec strategii przykład wzorca strategii ObiektZłożony + przejdź() składacz Składacz + składaj() SkładaczProsty SkładaczTeXowy SkładaczTablicowy + składaj() + składaj() + składaj() 23 Wzorzec strategii zasady, na których oparty jest wzorzec strategii obiekty posiadają określona odpowiedzialność różne sposoby implementacji tych rodzajów odpowiedzialności manifestują się poprzez zastosowanie polimorfizmu istnienie wielu różnych implementacji stanowiących na poziomie koncepcji ten sam algorytm separacja zachowań występujących w dziedzinie problemu, co pozwala zmieniać klasy odpowiedzialne za określone zachowania bez wpływu na inne zastosowanie wzorca strategii sposób hermetyzacji różnych algorytmów możliwość użycia różnych reguł w różnych sytuacjach 24

55 Wzorzec obserwatora obserwator, przedmiot zdefiniowanie pomiędzy obiektami zależności typu jeden-dowielu, która powoduje, że jeśli obiekt zmieni swój stan, to pozostające z nim w zależności inne obiekty zostaną o tym automatycznie poinformowane i uaktualniane obserwator obiekt, który jest informowany o zmianie; oczekuje na wystąpienie pewnego zdarzenia przedmiot (obserwowany) obiekt, który informuje obserwatora o zmianie swojego stanu w większości przypadków obserwator powinien sam wiedzieć, co obserwuje, a przedmiot nie powinien wiedzieć, przez co jest obserwowany inaczej wzorzec służby lub wydawca-subskrybent 25 Wzorzec obserwatora obserwator liczba obserwatorów zależna od jednego obserwowanego może być dowolna wszyscy obserwatorzy są powiadamiani, gdy obserwowany zmieni swój stan w odpowiedzi każdy obserwator wystosuje zapytanie o stan do obserwowanego, aby zsynchronizować swój stan z jego stanem ten rodzaj współdziałania znany też jako publikuj-prenumeruj obserwowany publikuje powiadomienia i rozsyła je, nie wiedząc kim są obserwatorzy; powiadomienia mogą być zaprenumerowane przez dowolną liczbę obserwatorów 26

56 Wzorzec obserwatora cechy charakterystyczne wzorca obserwatora intencja - definiuje zależność typu jeden-do-wielu pomiędzy obiektami; polega ona na automatycznym zawiadomieniu wielu obiektów o zmianie stanu pojedynczego obiektu problem należy powiadomić zmieniającą się listę obiektów o pewnym zdarzeniu rozwiązanie - obiekt klasy Obserwator przekazuje odpowiedzialność za monitorowanie zdarzenia centralnemu obiektowi klasy Przedmiot uczestnicy i współpracownicy Przedmiot wie, które obiekty klasy Obserwator należy powiadomić, ponieważ rejestrują się u niego; Przedmiot zawiadamia obiekty klasy Obserwator o wystąpieniu zdarzenia; obiekty klasy Obserwator są odpowiedzialne za zarejestrowanie się u obiektu Przedmiot i uzyskanie od niego potrzebuje informacji, gdy zostaną powiadomione o zdarzeniu 27 Wzorzec obserwatora cechy charakterystyczne wzorca obserwatora... konsekwencje Przedmiot może nie potrzebnie powiadomić o zdarzeniu różne rodzaje obserwatorów, nawet wtedy, gdy są zainteresowane jego wystąpieniem tylko w pewnych przypadkach; wymagane mogą być dodatkowe metody komunikacji w obiektem Przedmiot, jeśli obserwatorom potrzebne są specyficzne informacje o zdarzeniu implementacja tworzy obiekty klasy Obserwator, które maja być informowane o wystąpieniu pewnego zdarzenia i w tym celu rejestrują się u obiektu klasy Przedmiot kiedy zachodzi zdarzenie, Przedmiot powiadamia zarejestrowane obiekty klasy Obserwator czasami, aby obserwatorzy mogli implementować interfejs klasy Obserwator przydatny jest wzorzec adaptera 28

57 Wzorzec obserwatora stosowalność wzorca obserwatora jakaś abstrakcja ma dwa aspekty, jeden zależny od drugiego kapsułkowanie tych aspektów w oddzielnych obiektach umożliwia niezależne zmienianie i używanie tych obiektów zmiana jednego obiektu wymaga zmiany innych i nie wiadomo, ile obiektów trzeba zmieniać obiekt powinien być w stanie powiadamiać inne obiekty, nie przyjmując żadnych założeń dotyczących, co te obiekty reprezentują (chęć uniknięcia ścisłego powiązania tych obiektów) 29 diagram wzorca obserwatora Wzorzec obserwatora Obserwowany + dołącz(in Obserwator) + odłącz(in Obserwator) + powiadom() obserwatorzy Obserwator + aktualizuj() stanobserwatora = obserwowany.pobierzstan() ObserwowanyKonkretny ObserwatorKonkretny - stanobserwowanego obserwowany - stanobserwatora + pobierzstan() + nadajstan() + aktualizuj() return stanobserwowanego 30

58 Wzorzec obserwatora uczestnicy Obserwowany zna swoich obserwatorów; może go obserwować dowolna liczba Obserwatorów zapewnia interfejs dołączania i odłączania Obserwatorów Obserwator definiuje interfejs uaktualniania dla obiektów, które powinny być powiadamiane o zmianach, jakie zaszły w obserwowanym ObserwowanyKonkretny przechowuje stan, który interesuje obiekty ObserwatorKonkretny gdy zmienia się jego stan, wysyła powiadomienia do swoich obserwatorów ObserwatorKonkretny utrzymuje odwołanie do obiektu ObserwowanyKonkretny przechowuje stan, który powinien być spójny ze stanem Obserwowanego implementuje interfejs Obserwatora służący do uaktualnienia, żeby zachować spójność swojego stanu ze stanem Obserwowanego 31 współpraca Wzorzec obserwatora ObserwowanyKonkretny zawsze powiadamia swoich obserwatorów, gdy wystąpi zmiana, która może doprowadzić do niespójności jego stanu ze stanem obserwatora po otrzymaniu powiadomienia o zmianie, która wystąpiła w konkretnym obserwowanym, ObserwatorKonkretny może go zapytać o informacje dotyczące jego zmiany; używa tych informacji do uaktualnienia swojego stanu na podstawie stanu obserwowanego ObserwatorKonkretny do ObserwowanyKonkretny: nadajstan() ObserwowanyKonkretny do samego siebie: powiadom() ObserwowanyKonkretny do ObserwatorKonkretny: aktualizuj() ObserwatorKonkretny do ObserwowanyKonkretny: pobierzstan() ObserwowanyKonkretny do inny ObserwatorKonkretny: aktualizuj() inny ObserwatorKonkretny do ObserwowanyKonkretny: pobierzstan() 32

59 Wzorzec obserwatora konsekwencje wzorzec umożliwia niezależne zmienianie obserwatorów i obserwowanych można ponownie wykorzystać obserwowanego, nie używając obserwatora i na odwrót umożliwia też dodawanie obserwatorów bez modyfikowania obserwowanego lub innych obserwatorów abstrakcyjne powiązanie miedzy Obserwowanym a Obserwatorem Obserwowany wie tylko, że ma listę obserwatorów, z których każdy dostosuje się do prostego interfejsu klasy abstrakcyjnej Obserwator Obserwowany nie zna klasy konkretnejżadnego z obserwatorów powiązanie miedzy obserwowanymi a obserwatorami jest abstrakcyjne i minimalne Obserwowany i Obserwator mogą należeć do innych warstw abstrakcji w systemie Obserwowany z niskiego poziomu może komunikować się z Obserwatorem z wysokiego poziomu i informować go, zachowując w ten sposób podział systemu na warstwy 33 Wzorzec obserwatora konsekwencje... wsparcie dla rozsyłania komunikatów powiadomienie wysyłane przez obserwowanego nie musi specyfikować odbiorcy powiadomienie jest automatycznie nadawane do wszystkich zainteresowanych obiektów, które je zaprenumerowały obserwowanego nie interesuje, ile ich jest; do jego obowiązków należy jedynie powiadamianie swoich obserwatorów umożliwia to swobodne dodawanie i usuwanie obserwatorów w dowolnym momencie nieoczekiwane uaktualnienia jeden obserwator nie wie nic o obecności drugiego, zatem mogą nie dostrzegać ostatecznych kosztów związanych zanych ze zmienianiem obserwowanego operacja dotycząca obserwowanego może spowodować kaskadę uaktualnień w obserwatorach o obiektach od nich zależnych 34

60 Wzorzec obserwatora implementacja odwzorowywanie obserwowanych na obserwatorów sposoby pamiętania na bieżąco obserwatorów przez obserwowanego: przechowywanie odwołań do obserwatorów bezpośrednio w obserwowanym wyszukiwanie asocjacyjne (np. tablicy z haszowaniem) do utrzymania odwzorowania obserwowany-na-obserwatora obserwowanie więcej niż jednego obserwowanego obserwator zależy od więcej niż jednego obserwowanego rozszerzenie interfejsu aktualizacja() tak, aby obserwator wiedział, który obserwowany wysłał powiadomienie który z uczestników doprowadza do uaktualnienia dwie możliwości operacje wyznaczające stan obserwowanego mogą wywoływać powiadom() zaraz po zmianie stanu klienci nie muszą pamiętać o wywołaniu operacji powiadom() obserwowanego, ale kilka kolejnych operacji będzie powodować kilka kolejnych uaktualnień za wywoływanie powiadom() w odpowiednim momencie mogą być odpowiedzialni klienci klient może poczekać z uruchomieniem uaktualnień, aż zostanie wykonana ostatnia z serii zmian stanu, unikając zbędnych aktualizacji pośrednich; ale to na klientów spada dodatkowy obowiązek uruchamiania uaktualnień 35 Wzorzec obserwatora implementacja... zawieszone odwołania do usuniętych obserwowanych po ucięciu obserwowanego u obserwatorów nie powinno być żadnych odwołań do niego obserwowany powiadamia swoich obserwatorów,że jest usuwany zagwarantowanie, że przed rozesłaniem powiadomienia stan Obserwowanego jest wewnętrznie spójny w trakcie uaktualniania swojego stanu obserwatorzy pytają obserwowanego o jego bieżący stan unikanie protokołów uaktualniania, specyficznych dla obserwatora: modele pchający i ciągnący obserwowany często rozsyła dodatkowe informacje o zmianie (jako argument operacji aktualizacji()) model pchający obserwowany wysyła obserwatorom szczegółową informację z mianie, bez względu na to, czy tego chcą, czy nie obserwowany wiec cos o potrzebach obserwatorów obserwatorzy będą mniej nadawać się do ponownego użycia, bo klasy Obserwowanych mogą zakładać o klasach Obserwatorów coś, co nie zawsze musi być prawdziwe model ciągnący obserwowany nie wysyła niczego oprócz samego powiadomienia, a obserwatorzy jawnie pytają potem o szczegóły obserwowany nic nie wie o obserwatorach 36

61 implementacja... Wzorzec obserwatora kapsułkowanie złożonej semantyki uaktualnień gdy związek zależności między obserwowanym a obserwatorami jest szczególnie złożony, potrzebny obiekt podtrzymujący ten związek obiekt ZarządcaZmian odwzorowuje obserwowanych na ich obserwatorów i zapewnia interfejs do zachowania tego odwzorowania, co eliminuje potrzebę utrzymywania w obserwowanych odwoła do obserwatorów i na odwrót zdefiniowanie stosownej strategii uaktualniania uaktualnienie wszystkich zależnych obserwatorów nażądanie obserwowanego łączenie klas Obserwowany i Obserwator 37 Wzorzec obserwatora koncepcje obiektowe wykorzystywane przez wzorzec obserwatora odpowiedzialność obiektów za siebie klasa abstrakcyjna (Obserwator) hermetyzacja (Obserwowany) zastosowanie wzorca obserwatora występowanie zmienności lista obiektów powiadamianych zmienia się 38

62 Wzorzec metody szablonu metoda szablonu zdefiniowanie ogólnego szkieletu używanego algorytmu i pozostawienie implementacji niektórych jego kroków dla klas pochodnych uzyskuje się możliwość modyfikacji niektórych kroków algorytmu bez konieczności zmieniania jego ogólnej struktury zadaniem wzorca metody szablonu jest pomoc przy tworzeniu abstrakcji wspólnej dla różnych procedur zawarcie ogólnej, wspólnej koncepcji w klasie abstrakcyjnej i hermetyzacja różnic w klasach pochodnych pozwala zdefiniować ogólną sekwencje operacji, a następnie niektóre z nich zastąpić, jeśli implementacja musi być inna 39 Wzorzec metody szablonu metoda szablonu podstawowa technika w celu zagwarantowania możliwości ponownego wykorzystania kodu metoda szablonowa definiuje algorytm w kategoriach operacji abstrakcyjnych, które są przedefiniowane przez podklasy w celu zapewnienia określonego zachowania definiując niektóre z kroków algorytmu za pomocą operacji abstrakcyjnych metoda szablonowa ustala ich kolejność, ale umożliwia podklasom zmianę tych kroków zależnie od ich potrzeb 40

63 Wzorzec metody szablonu cechy charakterystyczne wzorca metody szablonu intencja - zdefiniowanie szkieletu algorytmu i pozostawienie implementacji niektórych jego operacji klasom pochodnym; możliwość ponownego zdefiniowania niektórych operacji bez konieczności zmieniania struktury algorytmu problem istnieje stała procedura, której poszczególne kroki mogą różnic się szczegółami rozwiązanie - zdefiniowanie zmieniających się operacji przy zachowaniu ogólnej procedury uczestnicy i współpracownicy wzorzec metody szablonu składa się z klasy abstrakcyjnej, która definiuje podstawowe, wspólne zachowanie klas pochodnych w postaci metody metodaszablonowa oraz szczegółowych operacji, których implementacji dostarczyć muszą klasy pochodne 41 Wzorzec metody szablonu cechy charakterystyczne wzorca metody szablonu... konsekwencje szablony stanowią rozwiązanie służące powtórnemu wykorzystaniu kodu; pomagają zapewnić implementację określonych operacji; wiążą poszczególne, zmieniające się operacje wewnątrz klasy KlasaKonkretna, ponieważ występują zawsze razem implementacja polega na utworzeniu klasy abstrakcyjnej, implementującej ogólną procedurę za pomocą metod abstrakcyjnych; implementacja tych metod musi zostać dostarczona w klasach pochodnych; jeśli operacje te zmieniają się niezależnie od siebie, to można dla nich zastosować wzorzec strategii 42

64 Wzorzec metody szablonu stosowalność metody szablonu w celu jednoznacznego zaimplementowania stałej części algorytmu i pozostawienia podklaso zaimplementowania zachowania, które może się zmieniać gdy wspólne dla podklas zachowanie powinno być określone i umieszczone we wspólnej klasie w celu uniknięcia powielania kodu; najpierw znajdujemy różnice w istniejącym kodzie, następnie wydzielamy te różnice w postaci nowych operacji, a na koniec zastępujemy ten różniący się kod metodą szablonową, która wywołuje jedną z owych nowych operacji do kontrolowania rozszerzania klas; można zdefiniować metodę szablonową, która w wybranych miejscach wywołuje operacje punkty zaczepienia, umożliwiając tym samym rozszerzenie klas tylko w tych miejscach 43 Wzorzec metody szablonu diagram wzorca metody szablonu KlasaAbstrakcyjna + metodaszablonowa() + operacjapierwotna1() + operacjapierwotna2() KlasaKonkretna + operacjapierwotna1() + operacjapierwotna2() 44

65 uczestnicy Wzorzec metody szablonu KlasaAbstrakcyjna definiuje abstrakcyjne operacje pierwotne, przedefiniowane przez podklasy w celu zaimplementowania kroków algorytmu implementuje metodę szablonową definiującą szkielet algorytmu; metoda szablonowa wywołuje operacje pierwotne, jak również operacje zdefiniowane w KlasieAbstrakcyjnej lub operacje innych obiektów KlasaKonkretna implementuje operacje pierwotne w celu wykonania specyficznych dla podklasy kroków algorytmu współpraca KlasaKonkretna polega na KlasieAbstrakcyjnej w kwestii implementacji niezmiennych kroków algorytmu 45 Wzorzec metody szablonu konsekwencje nadklasa wywołuje operacji podklasy, a nie odwrotnie metody szablonowe wywołują: operacje konkretne (z KlasyKonkretnej lub z klas klienta) operacje konkretne z KlasyAbstrakcyjnej (te, które są najczęściej przydatne dla podklas) operacje pierwotne (operacje abstrakcyjne) metody wytwórcze operacje-punkty zaczepienia, zapewniające zachowanie domyślne, które może być rozszerzane przez podklasy; operacja-punkt zaczepienia często domyślnie nic nie robi w wypadku metod szablonowych ważne jest wyszczególnienie operacji, które są punktami zaczepienia (mogą być przedefiniowane) i tych, które są operacjami abstrakcyjnymi (muszą być przedefiniowane) podklasy mogą rozszerzać działanie operacji z nadklasy przez przedefiniowanie tej operacji i jawne wywołanie jej 46

66 Wzorzec metody szablonu implementacja stosowanie mechanizmów sterowania dostępem z C++ - w C++ operacje pierwotne zdefiniować jako chronione, co gwarantuje, że będą wywoływane tylko przez metodę szablonową; operacje pierwotne, które muszą być przedefiniowane deklaruje się jako czysto wirtualne; metoda szablonowa jako niewirtualna funkcja składowa minimalizowanie liczby operacji pierwotnych konwencje dotyczące nadawania nazw operacje wymagające przedefiniowania można oznaczyć przez dodanie jakiegoś członu do ich nazwy 47 Wzorzec metody szablonu przykład wzorca metody szablonu Dokument + zapisz() + otwórz() + zamknij() + róbwczytywanie() dokumenty Aplikacja + dodajdokument() + otwórzdokument() + róbtworzeniedokumentu() + moznaotworzycdokument() + będęotwieracdokument() MójDokument + róbwczytywanie() MojaAplikacja + róbtworzeniedokumentu() + moznaotworzycdokument() + będęotwieracdokument() 48

67 Wzorzec metody szablonu zastosowanie wzorca metody szablonu występowanie procedur podobnych na poziomie koncepcji, ale różniących się implementacją 49 Macierz analizy analiza zmienności w dziedzinie problemu identyfikacja zmienności i konstruowanie właściwego rozwiązania zawierającego te zmienności zidentyfikowanie zmieniających się koncepcji, określenie punktów wspólnych oraz odnalezienie brakujących wymagań koncepcje odnajduje się analizując specyficzne wymagania poszczególnych przypadków macierz analizy sposób zapisu wielu różnych zmienności występujących w danym problemie i odwzorowaniu ich za pomocą wzorców podejście polegające na identyfikowaniu występowania zmienności i analizowaniu możliwości zastosowania wzorców 50

68 Macierz analizy etapy tworzenia macierzy identyfikacja najistotniejszych cech pojedynczego przypadku i umieszczenie ich w macierzy (każda cecha opisana za pomocą etykiety charakteryzującej koncepcję, którą reprezentuje dana cecha) wiersze macierzy służą do identyfikacji reguł kolumny macierzy przedstawiają poszczególne przypadki analizowanie innych przypadków rozszerzając w miarę potrzeby macierz rozszerzenie macierzy o nowe koncepcje wykorzystując macierz analizy identyfikacja występowania wzorców projektowych tworzenie ogólnego schematu rozwiązania 51

69 Inżynieria Oprogramowania Wykład 13 Wzorce projektowe Wzorce projektowe wzorce konstrukcyjne (kreacyjne) metoda fabryki lub metoda wytwórcza (ang. factory method) określa interfejs do tworzenia obiektów, lecz umożliwia podklasom decydowanie o tym, której klasy ma to być obiekt; dzięki metodzie fabryki klasy mogą zdać się na podklasy w kwestii tworzenia egzemplarzy fabryka abstrakcyjna (ang. abstract factory) zapewnia interfejs umożliwiający tworzenie rodzin powiązanych ze sobą lub zależnych od siebie obiektów bez specyfikowania ich klas konkretnych singleton gwarantuje, że klasa ma tylko jeden egzemplarz i zapewnia globalny dostęp do niego budowniczy (ang. builder) oddziela konstrukcję obiektów złożonych od ich reprezentacji, umożliwiając tym samym powstawanie w jednym procesie konstrukcyjnym różnych reprezentacji prototyp (ang. prototype) specyfikuje rodzaje tworzonych obiektów, używając prototypowego egzemplarza, a także tworzy nowe obiekty, kopiując ten prototyp 2

70 Wzorce projektowe wzorce strukturalne adapter (ang. adapter) przekształca interfejs klasy w taki, jakiego klienci oczekują; dzięki adapterowi klasy mogą współpracować, co bez niego nie byłoby możliwe, ponieważ mają niezgodne interfejsy most (ang. bridge) oddziela abstrakcję od implementacji, tak by mogły się zmieniać niezależnie kompozyt (ang. composite) składa obiekty w struktury drzewiaste reprezentujące hierarchie część-całość; umożliwia klientom jednakowe traktowanie pojedynczych obiektów i złożeń obiektów dekorator (ang. decorator) dynamicznie dołącza do obiektów dodatkowe zobowiązania; zapewnia elastyczną alternatywę dla tworzenia podklas w celu rozszerzenia funkcjonalności fasada (ang. facade) zapewnia jednolity interfejs dla podsystemu zawierającego wiele interfejsów; definiuje interfejs wyższego poziomu, co ułatwia korzystanie z podsystemu pyłek (ang. flyweight) wykorzystuje współdzielenie obiektów w celu efektywnej obsługi wielkiej liczby drobnych obiektów pełnomocnik (ang. proxy) zapewnia substytut lub reprezentanta innego obiektu w celu sterowania dostępem do niego 3 Wzorce projektowe wzorce czynnościowe łańcuch zobowiązań (ang. chain of responsibility) umożliwia uniknięcie związania wysyłającego żądanie z odbiorcą żądania przez danie więcej niż jednemu obiektowi szansy obsłużenia tego żądania; tworzy łańcuch odbierających obiektów i przekazuje wzdłuż niego żądanie, aż jakiś obiekt je obsłuży polecenie (ang. command) kapsułkuje żądania w postaci obiektu, co umożliwia parametryzowanie klientów różnymi żądaniami, kolejkowanie żądań lub zapisywanie ich w dziennikach, a także implementację anulowanych operacji interpreter (ang. interpreter) definiuje reprezentację dla gramatyki zadanego języka, a także interpreter, który wykorzystuje te reprezentację do interpretowania zdań w zadanym języku interator (ang. iterator) zapewnia sekwencyjny dostęp do elementów obiektu zagregowanego bez ujawniania jego reprezentacji wewnętrznej mediator (ang. mediator) defiluje obiekt kapsułkujący informacje o tym, jak obiekty współdziałają; przyczynia się do rozluźnienia powiązań między obiektami, gdyż sprawia, że obiekty nie odwołują się do siebie wprost; umożliwia też oddzielne zmienianie ich sposobu porozumiewania 4

71 wzorce czynnościowe... Wzorce projektowe pamiątka (ang. memento) nie naruszając kapsułkowania, zapamiętuje i udostępnia na zewnątrz stan wewnętrzny obiektu, tak że obiekt może być później przywrócony do zapamiętanego stanu obserwator (ang. observer) określa zależność jeden-do-wielu miedzy obiektami; gdy jeden obiekt zmienia stan, wszystkie obiekty odeń zależne są o tym automatycznie powiadamiane i uaktualniane stan (ang. state) umożliwia obiektowi zmianę zachowania, gdy zmienia się jego stan wewnętrzny; dzięki temu obiekt zdaje się zmieniać wówczas swoja klasę strategia (ang. strategy) definiuje rodzinę algorytmów, kapsułkuje każdy z nich i umożliwia ich wymianę; sprawia, że możliwe staje się zmienianie algorytmów niezależnie od używających go klientów 5 Wzorce projektowe wzorce czynnościowe... szablon lub metoda szablonu (ang. template) definiuje szkielet algorytmu jako operację, odkładając definicję niektórych kroków algorytmu do podklas; umożliwia podklasom przedefiniowanie pewnych kroków algorytmu bez zmiany jego struktury odwiedzający (ang. visitor) określa operację, która ma być wykonana na elementach struktury obiektowej; umożliwia definiowanie nowej operacji bez modyfikowania klas elementów, na których ona działa 6

72 Wzorce J2EE wzorce dotyczące platformy J2EE po raz pierwszy zostały zaprezentowane na konferencji JavaOne Conference w czerwcu 2000 roku za pomocą wzorców J2EE można szybko osiągnąć umiejętność budowania elastycznych i wydajnych aplikacji biznesowych wzorce te dotyczą warstwy prezentacji, warstwy biznesowej i warstwy integracji wzorce J2EE związane są z technologia J2EE i językiem programowania Java 7 Warstwa Prezentacji Biznesowa Integracji Wzorce J2EE Nazwa wzorca Intercepting Filter Front Controller Context Object Application Controller View Helper Composite View Service to Worker Dispatcher View Business Delegate Service Locator Session Façade Application Service Business Object Composite Entity Transfer Object Transfer Object Assembler Value List Handler Data Access Object Service Activator Domain Store Web Service Broker 8

73 Wzorce J2EE warstwy prezentacji wzorce warstwy prezentacji związane są z serwletami i technologią JSP odpowiedzialne są za warstwę prezentacji, która zawiera całą logikę prezentacyjną wymaganą do obsługi klientów używających systemu, odbiera żądania klienta, zapewnia system logowania, zarządza sesją, steruje dostępem do usług biznesowych, tworzy i dostarcza odpowiedzi do klienta 9 Wzorzec projektowy Intercepting Filter wzorzec projektowy Intercepting Filter pozwala na rozwiązanie problemów, w których należy przechwycić i modyfikować żądanie, a także odpowiedzieć przed i po właściwym przetwarzaniu, np.: sprawdzenie, czy dany klient jest zalogowany sprawdzenie poprawności formularzy sprawdzenie, czy dany klient korzysta z właściwej przeglądarki internetowej sprawdzenie kodowania używanego przez klienta wzorzec Intercepting Filter powinien być stosowany, gdy: zachodzi potrzeba wspólnego przetwarzania, takiego jak sprawdzenie systemu kodowania danych lub rejestrowanieżądań o poprawnie zakończonychżądaniach pożądana jest centralizacja wspólnej logiki dla przetwarzania usługi powinny być łatwo dodawane i usuwane bez wpływu na istniejące elementy 10

74 Wzorzec projektowy Intercepting Filter Klient przesyła żądanie do obiektu FilterManager, który jest odpowiedzialny za zarządzanie przetwarzaniem tegożądania przy użyciu filtrów FilterManager tworzy również obiekt FilterChain, który jest zbiorem obiektów typu Filter po zakończeniu przetwarzania specyficznych filtrów wywoływany jest zasób Target, o który zwrócił się Klient zasada działania tego wzorca polega na tym,że zanim Klient uzyska potrzebny zasób, tożądanie jest sprawdzane poprzez specyficzne filtry filtry takie mogą być dowolnie dodawane, usuwane i łączone bez zmiany istniejącego kodu jednym z zadań dołączanych filtrów jest przechowywanie często powtarzającego się kodu w jednym miejscu 11 Wzorzec projektowy Front Controller wzorzec projektowy Front Controller pozwala na rozwiązanie problemów, w których zachodzi potrzeba scentralizowania punktu dostępu dla obsługi żądań w warstwie prezentacji pozwala na uniknięcie sytuacji, w której kod odpowiedzialny za sterowanie żądaniami powtarza się w wielu miejscach aplikacji powoduje to problemy braku modułowości, które wzorzec ten również rozwiązuje wzorzec Front Controller powinien być stosowany, gdy: należy uniknąć powielania logiki sterującej należy oddzielić logikę przetwarzania od widoku należy scentralizować i kontrolować wszystkie punkty dostępu do systemu do zalet tego wzorca należy to,że: umożliwia centralizację sterowania żądań dzięki centralizacji sterowania, można wykryć niepożądane próby dostępu do systemu umożliwia ponowne użycie kodu komponentów i uniknięcie powielania kodu 12

75 Wzorzec projektowy Front Controller obiekt FrontController jest centralnym i głównym miejscem, w którym przyjmowane są wszystkieżądania uzyskane od Klienta obiekt ten przekazuje te żądania do obiektu ApplicationController, który zarządza działaniami związanymi z żądaniem i widokami aplikacji reprezentowanymi odpowiednio poprzez obiekt Command i obiekt View 13 Wzorzec projektowy View Helper wzorzec projektowy View Helper pozwala na rozwiązanie problemów, w których zachodzi potrzeba oddzielenia widoku od logiki związanej z jego przetwarzaniem wzorzec View Helper powinien być stosowany, gdy: należy uniknąć osadzania logiki aplikacji wewnątrz widoków zachodzi potrzeba skorzystania z widoków wykorzystujących szablony, na przykład stron JSP należy oddzielić logikę aplikacji od widoków, aby jasno ustalić granice prac programistów i projektantów stron wzorzec ten posiada kilka zalet: poprawa modularności, możliwości ponownego wykorzystania i ułatwienia pielęgnacji kodu ułatwienie testowania poprawa separacji ról 14

76 Wzorzec projektowy View Helper obiekt View odpowiada za przestawienie i wyświetlenie informacji klientowi, który go o to prosi dynamiczne elementy strony są uzyskiwane z obiektu PresentationModel i w odpowiedni sposób konwertowane poprzez obiekty pomocnicze Helper PresentationModel przechowuje potrzebne dane do wygenerowania widoku 15 Wzorzec projektowy Composite View wzorzec projektowy Composite View pozwala na rozwiązanie problemów, w których zachodzi potrzeba budowania widoku z modułowych, jednostkowych części składowych, które po połączeniu tworzą złożoną stronę zarządzanie poszczególnymi modułami odbywa się niezależnie od siebie wzorzec Composite View powinien być stosowany, gdy: potrzebne są wspólne podwidoki, na przykład nagłówki, stopki i tabele używane w wielu widokach zawartość znajduje się w podwidokach, które mogą ulegać częstym zmianom lub być udostępniane tylko niektórym użytkownikom zachodzi potrzeba uniknięcia bezpośredniego powielania i umieszczania podwidoków w wielu widokach dzięki zastosowaniu wzorca Composite View: poprawia się modułowość systemu i możliwość ponownego wykorzystania pielęgnacja kodu staje się prostsza zmniejsza się wydajność sytemu, co jest niewątpliwa wadą 16

77 Wzorzec projektowy Composite View zasada działania tego wzorca polega na tym, że Klient wybiera obiekt View, który reprezentuje wyświetlaną stronę obiekt View może zawierać zarówno obiekty SimpleView, które reprezentują prosty widok, najczęściej reprezentowany poprzez pojedyncze elementy takie jak przycisk, etykieta obiekt View może zawierać również obiekty CompositeView, które składają się z kilku elementów View, takich jak na przykład obrazek, etykieta i przycisk, zawarte w pewnym panelu obiekt ViewManager jest obiektem, który zarządza ułożeniem określonych widoków na stronie zarówno tych prostych jak i złożonych. ViewManager wykorzystuje do tego obiekt Template, który reprezentuje szablon strony 17 Wzorce J2EE warstwy biznesowej wzorce warstwy biznesowej związane są z technologią Enterprise JavaBeans (EJB) odpowiedzialne są za warstwę biznesową, która udostępnia usługi biznesowe wymagane przez klientów aplikacji, a także zawiera dane i logikę biznesową 18

78 Wzorzec projektowy Business Delegate wzorzec projektowy Business Delegate pozwala na rozwiązanie problemów, w których należy ukryć przed klientem złożoność zdalnej komunikacji z komponentami usług biznesowych często stosuje się i tworzy oprogramowanie, które w warstwie klienta i prezentacji łączy się z usługami biznesowymi podejście to jest przyczyną rozmaitych problemów: każda zmiana interfejsu usługi biznesowej powoduje i wymusza zmiany w warstwie klienta i prezentacji osadzenie usług biznesowych po stronie klienta powoduje obciążenie sieci i brak możliwości buforowania wywołań usługi rozmaite błędy w usłudze biznesowej muszą być przechwytywane w warstwie klienta lub prezentacji za pomocą wyjątków wzorzec Business Delegate znajduje zastosowanie w sytuacjach, w których zachodzi potrzeba ukrycia szczegółów implementacji usług biznesowych pozwala zapewnić właśnie taką hermetyzację usług biznesowych, a także zmniejszyć liczbę zależności między klientem a usługami biznesowymi 19 Wzorzec projektowy Business Delegate wzorzec Business Delegate powinien być stosowany, gdy: należy ukryć skomplikowane relacje pomiędzy klientem i usługami biznesowymi istnieje potrzeba dostępu do warstwy biznesowej z poziomu elementów warstwy prezentacji i klientów należy zminimalizować ilość niepotrzebnych wywołań usług biznesowych wzorzec Business Delegate posiada bardzo dużo zalet: zmniejszenie zależności pomiędzy warstwą prezentacji a warstwą biznesową mniejsza wrażliwość klienta na błędy, klient zgłasza tylko krytyczne błędy jednolity interfejs warstwy biznesowej, udostępniony warstwie prezentacji poprawienie ogólnej wydajności tworzonego systemu. jedyną z wad tego wzorca może być dodatkowa warstwa, która w pewien sposób powoduje wzrost złożoności i zmniejszenie elastyczności 20

79 Wzorzec projektowy Application Service wzorzec projektowy Application Service pozwala na rozwiązanie problemów, w których należy scentralizować logikę biznesową kilku komponentów i usług biznesowych wzorzec Application Service powinien być stosowany, gdy: należy ograniczyć ilość logiki biznesowej w fasadach usług należy utworzyć nie rozdrobniony interfejs usług nad istniejącymi komponentami i usługami biznesowymi należy umieścić logikę związaną z konkretnymi przypadkami użycia poza obiektami Business Object wzorzec ten posiada kilka zalet: centralizacja wykorzystywanej wielokrotnie logiki biznesowej zwiększenie możliwości wielokrotnego wykorzystania logiki biznesowej uniknięcie powielania kodu wprowadzenie dodatkowej warstwy wewnątrz warstwy biznesowej 21 Wzorzec projektowy Application Service obiekt ApplicationService odgrywa główną rolę posiada pewną logikę biznesową, która zarządza realizacją pewnych usług obiekt ApplicationService używa innych obiektów do realizacji określonych usług obiektami tymi są na przykład obiekty: BusinessObject, DataAccessObject oraz Service 22

80 Wzorzec projektowy Transfer Object wzorzec projektowy Transfer Object pozwala na rozwiązanie problemów, w których zachodzi potrzeba przesłania wielu danych między warstwami wzorzec ten powinien być stosowany, gdy: należy zmniejszyć liczbę zdalnych wywołań należy uniknąć zmniejszenia wydajności spowodowanego przez znaczną ilość zdalnych wywołań do zalet tego wzorca należy: pozwala zmniejszyć obciążenie sieci redukuje duplikację kodu umożliwia istnienie nieaktualnych obiektów transferowych pozwala na przesłanie większej ilości danych za pomocą mniejszej liczby zdalnych wywołań 23 Wzorzec projektowy Transfer Object zasada działania tego wzorca polega na tym, że Klient korzystając z obiektu Component tworzy lub korzysta z obiektu TransferObject obiektem Component może być komponent będący w warstwie innej niż Klient przykładowo może być to komponent warstwy prezentacji (PresComponent), warstwy biznesowej (BizComponent), warstwy integracji (IntComponent) pbiekt TransferObject jest najprostszym obiektem języka Java, implementującym interfejs Serializable wysyłanie danych przy pomocy tego obiektu odbywa się w jednym wywołaniu 24

81 Wzorzec projektowy Value List Handler wzorzec projektowy Value List Handler pozwala na rozwiązanie problemów, w których zachodzi potrzeba, aby zdalni klienci aplikacji mieli możliwość przeglądania list obiektów wzorzec ten powinien być stosowany, gdy: należy zaimplementować przypadek pobierania obiektów tylko do odczytu, który nie wymaga transakcji należy zapewnić klientom wydajną metodę wyszukiwania i mechanizm przeglądania długiej listy wyników zachodzi potrzeba pozostawienia wyników wyszukiwania po stronie serwera do zalet tego wzorca należy: umożliwia buforowanie wyników wyszukiwania udostępnia bardziej elastyczne formy wyszukiwania dzięki wykorzystaniu poprawia się wydajność sieci 25 Wzorzec projektowy Value List Handler obiekt Klient jest klientem, który po uruchomieniu zapytania, otrzymuje dużą ilość zbioru danych, np. lista wyników wyszukiwania pewnych elementów na stronie (na przykład aktualności) do wyszukiwania tych elementów Klient używa obiektu ValueListHandler po wyszukaniu lista wyników przechowywana jest w obiekcie ValueList pojedynczy wynik reprezentowany jest poprzez obiekt Value obiekt DataAccessObject wykorzystywany jest przez ValueListHandler do łączenia się ze źródłem danych, wykonywania zapytań na tych danych i pobierania tych danych według określonych reguł w celu przechodzenia przez kolejne wyniki Klient używa obiektu ValueListIterator 26

82 Wzorce J2EE warstwy integracji wzorce warstwy integracji związane są z usługami internetowymi, łączem do baz danych JDBC i zestawem interfejsów służącym do przesyłania komunikatów JMS związane są z warstwą integracji, która odpowiada za komunikację z zewnętrznymi systemami i źródłami danych, na przykład bazami danych i aplikacjami zewnętrznymi 27 Wzorzec projektowy Data Access Object wzorzec projektowy Data Access Object pozwala na rozwiązanie problemów, w których należy ukryć logikę dostępu do danych w osobnej warstwie nie wszystkie obiekty trwałe powinny być implementowane jako obiekty biznesowe część aplikacji o niedużych wymaganiach powinna stosować raczej pewne obiekty pomocnicze, które bezpośrednio zajmują się dostępem do zbioru danych zbiorem takim najczęściej jest system zarządzania relacyjną bazą danych wzorzec Data Access Object powinien być stosowany, gdy: należy zaimplementować mechanizmy dostępu do danych, aby pobierać i modyfikować dane znajdujące się w trwałym magazynie zachodzi potrzeba oddzielenia implementacji trwałego magazynu od reszty aplikacji potrzeba stworzyć jednolity interfejs dostępu do danych znajdujących się w różnychźródłach wzorzec ten posiada bardzo dużo zalet: umożliwia dostęp do danych bez potrzeby znajomości szczegółów implementacji ułatwia migrację pomiędzy różnymi zbiorami danych udostępnia prosty interfejs dostępu do danych dla klienta dostęp do danych odbywa się w osobnej warstwie, dzięki czemu ewentualne zmiany odbywają się w jednym miejscu 28

83 Wzorzec projektowy Data Access Object Klient jest obiektem, który wymaga dostępu doźródła danych dostęp ten jest uzyskiwany poprzez obiekt DataAccessObject, który ukrywa przed klientem zbędne elementy, zapewniając jednocześnie jednolity interfejs udostępniający operacje wstawiania, wyszukiwania, aktualizacji i usuwania danych obiekt DataSource reprezentuje źródło danych, którym najczęściej jest baza danych, plik XML, system plików obiekt Data jest obiektem transferowym, za pomocą którego Klient uzyskuje dane od obiektu DataAccessObject obiekt ResultSet reprezentuje natomiast rezultat wykonania zapytania 29 Wzorzec projektowy Service Activator wzorzec projektowy Service Activator pozwala na rozwiązanie problemów, w których należy asynchronicznie wywołać usługi biznesowe wzorzec ten umożliwia wywołanie pewnych usług i nie czekanie na zakończenie przetwarzania, w odróżnieniu do synchronicznego wywołania znajduje zastosowanie w sytuacjach, w których aplikacja musi pewne czynności, procesy wykonać asynchronicznie przykładem takiego wykorzystania są zamówienia sklepu internetowego, realizowane poprzez inną firmę i wysyłane powiadomienia o przyjęciu zamówienia wzorzec Service Activator powinien być stosowany, gdy: zachodzi potrzeba w sposób asynchroniczny wywoływać usługi biznesowe, zwykłe obiekty Java i komponenty EJB należy przeprowadzić działania biznesowe, które w sensie logicznym składają się z kilku podzadań wzorzec posiada następujące zalety: zapewnia asynchroniczne przetwarzanie dla dowolnych komponentów warstwy biznesowej integruje JMS z aplikacjami biznesowymi umożliwia wykorzystanie niezależnych komponentów JMS 30

84 Wzorzec projektowy Service Activator obiekt Klient reprezentuje dowolnego klienta aplikacji, który potrzebuje wywołać usługę biznesową w sposób asynchroniczny wywoływanie takie odbywa się poprzez wysłanie komunikatu reprezentowanego jako obiekt Request obiekt ServiceActivator jest głównym elementem wzorca i odpowiada za odbiór i analizę komunikatów w celu wykonania odpowiedniego działania obiekt BusinessService jest głównym elementem docelowym, którego Klient prosi o wykonanie przetwarzania 31 Wzorzec projektowy Web Service Broker wzorzec projektowy Web Service Broker pozwala na rozwiązanie problemów, w których należy umożliwić dostęp do jednej lub kilku usług, używając języka XML i protokołów internetowych umożliwia koordynowanie współpracy usług internetowych (ang. web services) wzorzec Web Service Broker powinien być stosowany, gdy: należy udostępnić istniejące usługi klientom należy monitorować, a w razie potrzeby ograniczyć korzystanie z udostępnionych usług na podstawie wymagań biznesowych i zajętości zasobów systemowych usługi muszą być udostępnione z wykorzystaniem otwartych standardów, aby umożliwić integrację heterogenicznych aplikacji zaletą tego wzorca jest to, że dzięki wprowadzeniu dodatkowej warstwy między klientem a usługą zmniejszane są zależności wadą jest to, że z powodu wykorzystania dodatkowych protokołów wydajność sieci może się zmniejszyć 32

85 Wzorzec projektowy Web Service Broker EndpointProcessor jest servletem, który odpowiada za akceptację i przetworzenieżądania otrzymanego od Klienta EndpointProcessor wywołuje obiekt WebServiceBroker, który jest usługą internetową działającą jako pewien koordynator innych usług usługi te reprezentowane są poprzez obiekt BusinessService, który może być komponentem Session Facade, Application Service lub fasadą 33

86 Inżynieria Oprogramowania Wykład 1 Inżynieria oprogramowania narzędzia CASE modele cyklu życia oprogramowania Inżynieria oprogramowania - Literatura: 2

87 Inżynieria oprogramowania - Literatura: 3 Inżynieria oprogramowania - Literatura: 4

88 Inżynieria oprogramowania - Literatura: 5 Inżynieria oprogramowania - Literatura: 6

89 Inżynieria oprogramowania Narzędzia do realizacji projektu: Rational Rose NetBeans Eclipse ArgoUML Tigris.org Open Source Software Engineering Jude Dia inne... 7 Inżynieria oprogramowania inżynieria inżynieria oprogramowania (Software Engineering) inżynieria oprogramowania to wiedza techniczna, dotyczącaca wszystkich faz cyklu życia oprogramowania, której celem jest uzyskanie wysokiej jakości produktu - oprogramowania oprogramowanie o wysokiej jakości to oprogramowanie spełniające następujące kryteria: zgodne z wymaganiami użytkownika, niezawodne, efektywne, łatwe w konserwacji, ergonomiczne 8

90 Inżynieria oprogramowania Główne zadania inżynierii oprogramowania: określenie cech dobrego programu poprawa produktywności dostarczenie narzędzi tworzenia dobrych programów prawidłowa organizacja pracy projektantów wypracowanie standardów dostarczenie formalnych i półformalnych metod specyfikacji projektu umożliwienie modyfikowania oprogramowania - istniejącego (reverse engineering) i nowego ułatwienie pracy zespołowej (groupware) zapewnienie wysokiej jakości oprogramowania 9 Inżynieria oprogramowania technologia zadania technologii: zestawienie operacji i czasu ich wykonywania określenie powiązań między operacjami kreowanie i przestrzeganie norm i standardów dobór wykonawców (role osób, zadania) dobór narzędzi (metodyka +środowisko) ocena wydajności pracy na kolejnych etapach, czynniki stymulujące i hamujące wzrost wydajności kontrola jakości wyrobów przestrzeganie dyscypliny technologicznej zachowanie tajemnicy technologii 10

91 Inżynieria oprogramowania system informatyczny działa zgodnie z przyjętym modelem (modelami) danych i procesów model - przybliżenie rzeczywistości każdy system informatyczny opracowano z pewnymi uproszczeniami i ograniczeniami środowisko tworzenia aplikacji i język programowania pozwalają przełożyć opracowane modele na poziom realizacyjny stosowane środki realizacyjne są ciągle skromne najistotniejszą rolę odgrywają analitycy i projektanci najcenniejsza umiejętność - zarządzanie projektami 11 Inżynieria oprogramowania Tworzenie oprogramowania - model piramidy P L A N O W A N I E A N A L I Z A P R O J E K T O W A N I E B U D O W A D A N E C Z Y N N O C I 12

92 Inżynieria oprogramowania System przemysłowy a system akademicki (eksperymentalny) przemysłowy akademicki Cel poprawa obiegu i przetwarzania informacji sprawdzenie pewnej metody Stan końcowy ukończony nieukończony Wymagania zadaje klient autor Wymogi bezpieczeństwa wysokie brak Ochrona danych wymagana brak Pielęgnacja i rozwój w centrum uwagi brak Końcowi użytkownicy zewnętrzni autorzy Środowisko realizacyjne integrowanie rozmaitych systemów i narzędzi jednorodne Chłonność nowości ostrożna duża Dokumentacja kompletna i czytelna niekompletna Szkolenia planowe, grupowe samokształcenie Koszty wymierne, planowane wirtualne Produktywność konkurencyjna nie liczona 13 Narzędzia CASE CASE (Computer Aided Software Engineering, Computer Aided System Engineering) Składowe narzędzi CASE 14

93 Charakterystyka narzędzi CASE: Narzędzia CASE wspomaganie tworzenia oprogramowania w kilku fazach wizualizacja informacji (widoki, diagramy) reprezentowanie znaczenia rozmaitych obiektów w formie symboli i połączeń na diagramach wspomaganie rozmaitych metodyk analizy (modelowanie konceptualne i logiczne) strukturalizacja informacji (danych i procesów) badanie poprawności i spójności informacji wyrażonej na diagramach utrzymywanie bazy danych o tworzonym projekcie (słownik danych, repozytorium, encyklopedia) 15 Narzędzia CASE stosowanie konstrukcji programowania strukturalnego i obiektowego na poziomie diagramów automatyczna generacja znacznej części procedur aplikacji współdzielenie informacji o tworzonym projekcie między autorami systemu; półautomatyczne dokumentowanie eliminowanie powielania danych i procesów możliwość wyboru systemu realizacyjnego oraz konwersji formatów danych 16

94 Trzy grupy narzędzi CASE: Narzędzia CASE upper (planowanie, analiza) middle (analiza, projektowanie) lower ( projektowanie, budowa) Tylko zintegrowane narzędzia CASE wspomagają wszystkie fazy programowania. Przykłady produktów typu CASE: EasyCASE, LBMS (Leamonth & Burchett Management Systems Pic. - firma brytyjska, twórca metodyki SSADM), Oracle CASE, Software Through Pictures, Case 4.0 (Microtool), Bachman Toolset, IEF (Texas Instrument), Quickbuild (ICL) obiektowe: Select OMT, Objectif. Produkty typu CASE działają zamiennie na wielu platformach UNIXowych i Windows. 17 Rodzaje i role notacji notacja do zapisu wymagań, modelu i projektu stosuje się następujące rodzaje notacji: język naturalny notacje graficzne specyfikacje - częściowo ustruktalizowany zapis tekstowy i numeryczny notacje formalne szczególną rolę odgrywają notacje graficzne 18

95 role notacji: Rodzaje i role notacji podstawowe narzędzie pracy analityka i projektanta - powinny być przejrzyste, łatwo zrozumiałe, powinny ułatwiać modelowanie złożonych zależności narzędzie współpracy z użytkownikiem - musza być dość proste, przejrzyste, zrozumiałe współpraca pomiędzy członkami zespołu - szybkie i precyzyjne przekazywanie idei podstawa implementacji oprogramowania - powinny być przejrzyste i precyzyjne sposób zapisu dokumentacji technicznej 19 Metody i notacje obiektowe najpopularniejsze metody i notacje obiektowe (wykorzystywane w narzędziach CASE): OMT (Object modelling Technique) - Rumbaugh, 1991 OOA i OOD (Object-Oriented Analysis, Object-Oriented Design) - Coad i Yourdon, 1994 OOAD (Object-Oriented Analysis and Design) - Booch, 1994 UML (Unified Modelling Language) 20

96 Modele cyklu życia oprogramowania Modele cyklu życia oprogramowania: wprowadzają fazy określają czynności w fazach i kolejność ich realizacji pozwalają uporządkować przebieg prac ułatwiają planowanie zadań oraz monitorowanie przebiegu ich realizacji 21 Modele cyklu życia oprogramowania Model kaskadowy (Klasyczny model cyklu życia oprogramowania) proces liniowy fazy występują sekwencyjnie, jedna po drugiej zalety i wady modelu kaskadowego 22

97 Modele cyklu życia oprogramowania Realizacja kierowana dokumentami etapy modelu kaskadowego, ale każda faza kończy się opracowaniem dokumentów zawierających wszystkie wyniki danej fazy wyniki te są kierowane do klienta, który je zatwierdza zalety i wady modelu: zalety i wady modelu kaskadowego Modele cyklu życia oprogramowania Prototypowanie Określenie wymagań... P1 Pn wdrożenie Pn+ 1 alternatywa do modelu kaskadowego rozpoczyna się od budowy prototypu, który będzie dalej rozwijany następnie czynności takie jak w modelu kaskadowym etapy: ogólne określenie wymagań budowa prototypu weryfikacja prototypu przez klienta pełne określenie wymagań realizacja pełnego systemu zgodnie z modelem kaskadowym 24

98 Modele cyklu życia oprogramowania Prototypowanie 25 Modele cyklu życia oprogramowania Prototypowanie Głównym celem realizacji prototypu jest lepsze określenie wymagań, czyli: wykrycie nieporozumień pomiędzy klientem a twórcami systemu wykrycie brakujących funkcji wykrycie trudnych usług wykrycie braków w specyfikacji wymagań 26

99 Modele cyklu życia oprogramowania sposoby budowy prototypu: Prototypowanie niepełna realizacja (warto zawrzeć w prototypie niejasne fragmenty specyfikacji) języki wysokiego poziomu (Smalltalk, LISP, Prolog, języki czwartej generacji, wykonywalne języki specyfikacji formalnych) wykorzystanie gotowych komponentów generatory interfejsu użytkownika szybkie programowanie (ang. quick-and-dirty) - prototyp jest wytwarzany tak jak system, tylko mniej czasu poświęca się na poszczególne fazy papier zalety i wady prototypowania 27 Modele cyklu życia oprogramowania Programowanie odkrywcze (exploratory programming) 28

100 Modele cyklu życia oprogramowania Programowanie odkrywcze często stosowane np. przy oprogramowaniu naukowym - metoda powstaje równocześnie w systemem rozpoczyna się od wstępnego, bardzo ogólnego określenia wymagań, następnie buduje się system i testuje w inżynierii oprogramowania model ten jest zalecany do budowy prototypów zalety i wady programowania odkrywczego 29 Modele cyklu życia oprogramowania Realizacja przyrostowa 30

101 Modele cyklu życia oprogramowania Realizacja przyrostowa alternatywa dla modelu kaskadowego nie wyklucza prototypowania w fazie określania wymagań rozpoczyna się od określenia wymagań oraz wykonania wstępnego, ogólnego projektu całości systemu realizacja przyrostowa polega na tym, że wybiera się zbiór funkcji, dla których następnie wykonuje się szczegółowo wszystkie fazy zalety i wady realizacji przyrostowej 31 Modele cyklu życia oprogramowania Montaż z gotowych elementów (ang. composition of re-usable components), programowanie z półki (ang. off-shell programming) zaczynamy tak jak w modelu kaskadowym, ale w jak największym stopniu wykorzystać gotowe elementy dotyczy to głównie fazy implementacji, choć pewne komponenty możliwe do wykorzystywania w fazach wcześniejszych (np. model dla organizacji o podobnej strukturze, design-ware) stosowanie gotowych elementów: bibliotek języków czwartej generacji pełnych aplikacji 32

102 Modele cyklu życia oprogramowania Montaż z gotowych elementów (ang. composition of re-usable components), programowanie z półki (ang. off-shell programming) metody pozyskiwania gotowych elementów: zakup od zewnętrznych dostawców opracowanie wyników aktualnie realizowanych przedsięwzięć tak, aby mogłyby być wykorzystane w kolejnych przedsięwzięciach szczególny nacisk na redukcję nakładów przez maksymalne wykorzystanie podobieństw tworzonego oprogramowania do wcześniej tworzonych systemów niedostatki narzędzi wspomagających ten rodzaj pracy zalety i wady montażu z gotowych elementów 33 Modele cyklu życia oprogramowania Model spiralny Planowanie Analiza ryzyka Atestowanie Konstrukcja (model kaskadowy) 34

103 Modele cyklu życia oprogramowania Model spiralny 35 Modele cyklu życia oprogramowania model najbardziej ogólny cztery główne grupy czynności: analiza ryzyka konstrukcja atestowanie planowanie Model spiralny konstrukcja odbywa się zgodnie z modelem kaskadowym podstawą realizacji kolejnych wersji są wyniki atestowania przeprowadzonego przez klienta 36

104 Modele cyklu życia oprogramowania Formalne transformacje (formal transformations) wymagania wobec systemu specyfikowane w języku formalnym... języki formalnego specyfikowania wymagań stają się deklaratywnymi językami wysokiego poziomu - nadal mamy więc do czynienia z programowaniem brak dobrze rozwiniętych, uniwersalnych języków formalnej specyfikacji wymagań zalety i wady formalnych transformacji 37

105 Inżynieria Oprogramowania Wykład 2 UML - Unified Modeling Language UML - Unified Modeling Language UML to Zunifikowany Język Modelowania (Unified Modeling Language) następca obiektowych metod analizy i projektowania, które pojawiły się na przełomie lat 70-tych i 80-tych powstał z metody Booch a, metody OMT (Object Modeling Technique) Rumbaugh a i OOSE Jacobsona przeszedł w 1999 roku proces standaryzacji w ramach organizacji OMT (Object Management Group) i jest obecnie jej oficjalnym standardem 2

106 UML - Unified Modeling Language Historia UML 3 UML - Unified Modeling Language SPECYFIKACJE infrastruktura UML podstawa architektoniczna składni UML 2.0, metamodel superstruktura UML ukierunkowane na użytkownika kategorie modelowania, elementarne składniki diagramów OCL wymienność diagramów UML przenoszenie dokumentów zgodnych ze standardem UML miedzy różnymi narzędziami 4

107 UML - Unified Modeling Language MODELOWANIE Model zasady modelowania zastosowanie UML-a MODEL POJECIOWY UML 5 UML - Unified Modeling Language bloki konstrukcyjne UML elementy związki (powiązania między elementami) diagramy (grupują istotne elementy) ELEMENTY W UML istnieją cztery rodzaje elementów: strukturalne grupujące czynnościowe ciowe komentujące 6

108 UML - Unified Modeling Language Podstawowe elementy strukturalne - Najbardziej statyczne części modelu Klasa model3d Punkt : Integer = 0 / name2 Płaszczyzna Nazwa... add() move() Interfejs zestaw operacji, które wyznaczają usługi oferowane przez klasę, lub komponent PoufneInfor macje 7 UML - Unified Modeling Language Kooperacja Podstawowe elementy strukturalne zestaw ról i innych bytów, współdziałających w celu wywołania pewnego zespołowego zachowania Przypadek użycia Zarządzanie zamówieniam i opis zbioru ciągów akcji wykonywanych przez system w celu dostarczenia danemu aktorowi właściwego wyniku W eryfikujużytkownika 8

109 UML - Unified Modeling Language Klasa aktywna Komponent Podstawowe elementy strukturalne fizyczna, wymienna część systemu, która wykorzystuje i realizuje pewien zbiór interfejsów komp.java Węzeł fizyczny składnik działającego systemu Server 9 UML - Unified Modeling Language Aktor Podstawowe elementy strukturalne reprezentuje spójny zbiór ról odgrywanych przez użytkowników przypadku użycia w czasie interakcji z tym przypadkiem użycia zwykle rola dla człowieka, urządzenia technicznego lub innego systemu KlientHandlowy 10

110 UML - Unified Modeling Language Podstawowe elementy czynnościowe - Stanowią dynamiczną część modelu w UML Interakcja zachowanie polegające na wymianie komunikatów w grupie obiektów w pewnym celu Maszyna stanowa wyświetl określa ciąg stanów, jakie obiekt lub interakcja przyjmuje w odpowiedzi na zdarzenia zachodzące ce w czasie ich użycia określa też ich odpowiedzi na te zdarzenia Bezczynność 11 UML - Unified Modeling Language Podstawowe elementy grupujące Pakiet służy do grupowania elementów Pakiet Notka Podstawowe elementy komentujące 12

111 UML - Unified Modeling Language ZWIAZKI w UML związki są podstawowymi blokami konstrukcyjnymi, służącymi do łączenia elementów modelu Zależność związek użycia między dwoma elementami RozkładZaj dodaj(p : Przedmiot) usuń(p : Przedmiot) Przedmiot Powiązanie (association) związek znaczeniowy strukturalny 0..1 * pracownik pracodawca 13 UML - Unified Modeling Language Uogólnienie ZWIAZKI w UML związek między dwoma bytami: ogólnym (przodek) i szczegółowym (potomek) klientindywidualny klient Realizacja znaczeniowy związek miedzy klasyfikatorami 14

112 UML - Unified Modeling Language 2.0 DIAGRAMY w UML 2.0 diagram klas diagram obiektów diagram przypadków użycia diagram pakietów diagram sekwencji diagram komunikacji diagram maszyny stanowej diagram czynności diagram komponentów diagram wdrożenia diagram struktur połączonych diagram przebiegów czasowych diagram przeglądu interakcji 15 UML - Unified Modeling Language

113 UML - Unified Modeling Language 2.0 Use Case diagram Diagram przypadków użycia Class diagram Diagram klas Package diagram Diagram pakietów Object diagram Diagram obiektów UML 2.0 UML 1.x Composite Structure diagram Diagram struktur połączonych (diagram strukturalny) Component diagram Diagram komponentów Deployment diagram Diagram wdrożenia (diagram rozlokowania) Activity diagram Diagram aktywności (czynności) State Machine diagram Diagram maszyny stanowej Sequence diagram Diagram sekwencji Communication diagram Diagram komunikacji Timing diagram Diagram przebiegów czasowych Interaction Overview diagram Diagram przeglądu interakcji (diagram sterowania interakcją) + + używany nieoficjalnie Statechart diagram (diagram stanów) + Collaboration diagram (diagram współpracy) 17 UML - Unified Modeling Language reguły UML mechanizmy językowe w UML specyfikacje dodatki zasadnicze rozgraniczenia mechanizmy rozszerzenia stereotypy metki ograniczenia 18

114 UML - Unified Modeling Language ARCHITEKTURA w UML 19 UML - Unified Modeling Language ARCHITEKTURA w UML perspektywa przypadków użycia zakres i oczekiwana funkcjonalność tworzonego systemu perspektywa dynamiczna w jaki sposób realizowane jest zachowanie instancji klasyfikatorów w systemie perspektywa logiczna statyka systemu perspektywa komponentów przeznaczona dla programistów; oprogramowanie na poziomie komponentów perspektywa wdrożeniowa sprzęt informatyczny niezbędny do funkcjonowania komponentów systemu 20

115 UML - Unified Modeling Language UML opisuje proces, który jest: ukierunkowany na przypadki użycia architektocentryczny iteracyjny i przyrostowy 21 UML - Unified Modeling Language DIAGRAMY Diagram System, Podsystem Model Perspektywa statyczne części systemu: diagram klas, diagram obiektów, diagram komponentów, diagram wdrożeń, diagram pakietów, diagram struktur połączonych dynamiczne części systemu: diagram przypadków użycia, diagram sekwencji, diagram komunikacji, diagram maszyny stanowej, diagram czynności, diagram przeglądu interakcji, diagram harmonogramowania 22

116 Zamów ienie dataotrzymania przedpłata numer : String cena : w aluta w yślij() zamknij() 1 * DIAGRAM KLAS krotność asocjacja {jeśli zamow ienie.klient.w iarygodnośćkredyto w a jest "niska" to zamow ienie.przedpłata musi być praw dziwe} ograniczenie nawigowalność 1 nazw a adres Klient w iarygonośćkredytow a() : String klientfirmow y osobadokontaktów w iarygodnośćkredytowa limitkredytow y przypomnij() obciążzamiesiąc() 0..* klientindyw idualny numerkartykredytow ej w iarygodnośćkredytow a jest "niska"} ograniczenie pozycje 0..* nazwa roli przedstaw iciel handlowy 1 Pracow nik pozycjazamów ienia ilość : Integer cena : w aluta zapew niona : Boolean 0..* 1 tow ar 23 DIAGRAM KLAS Klasa nazwa klasy atrybuty operacje MODELOWANIE POWIĄZAŃ ( ASOCJACJI ) agregacja ma Uczelnia 1..* Student studiuje na ^ 0..* zawieranie 1 1..* nazwa powiązania uczęszcza na > 0..* 0..* Wydział 1..* Wykład * < pracuje na agregacja 1..* 1..* 1 < prowadzi 0..* 1..* Wykładowca nazwa roli dziekan 24

117 DIAGRAM KLAS Związki Zależność Osoba DanePersonelu Uogólnienie klasy abstrakcyjne i klasy konkretne ograniczenia: complete}, {incomplete, {disjoint}, {overlapping} Okrąg Figura 25 DIAGRAM KLAS Związki Realizacja związek miedzy interfejsem a klasą interfejs zapewnia realizację usług klasy 26

118 DIAGRAM KLAS Związki Powiązanie (association) nazwa Osoba Pracuje dla Przedsiębiorstwo nawigacja Osoba pracownik Przedsiębiorstwo role Osoba Przedsiębiorstwo pracownik pracodawca liczebność Osoba 1..* * Przedsiębiorstwo 27 DIAGRAM KLAS Związki Powiązanie (association) - liczebność 28

119 DIAGRAM KLAS Związki Powiązanie (association) kwalifikacja wyszukiwanie obiektów związanych zanych z daną asocjacją agregacja GrupaUzytk ID: Integer * 0..1 Dział Dział * 1 Przedsiębiorstwo agregacja całkowita - kompozycja Ramka * 1 Okno 29 DIAGRAM KLAS Związki Powiązanie, agregacja i agregacja całkowita - przykład 30

120 DIAGRAM KLAS Związki Powiązanie (association) klasa powiązana klasa asocjacyjna Osoba 1..* * Przedsiębiorstwo pracownik pracodawca Stanowisko opis datazatrudnien wynagrodzenie 31 Związki Powiązanie (association) klasa asocjacyjna - przykład DIAGRAM KLAS 32

121 DIAGRAM KLAS Notatka Stereotyp <<metaclass>> ModelElement Metka Server {procesory = 3} Ograniczenie {ograniczenie} OCL (Object Constraint Language) 33 widoczność public: + protected: # private: - package: ~ zasięg: instance, classifier abstrakcyjność korzenie: {root}, liście: {leaf} polimorfizm liczebność DIAGRAM KLAS KLASYFIKATOR 34

122 DIAGRAM KLAS KLASYFIKATOR atrybuty [widoczność] nazwa [/] [:typ] [liczebność] [= wartość-początkowa] tkowa] [{określenie-właściwości}] np.: + położenie: Punkt [1..*] = (0,0) {changeable} /nazwa atrybut pochodny, wartość ustalana na podstawie formuły właściwości: changeable, addonly, frozen operacje [widoczność] nazwa [(lista-parametrów)] [:typ-wyniku] [{określenie- właściwości}] ci}] np.: +pobierzid (nazwa: String) : Integer właściwości: leaf, isquery, sequential, guarded, concurrent 35 DIAGRAM KLAS Interfajs IPisownia <<interface>> IPisownia Pakiet Klient Klient # Dane - Zamówienie 36

123 DIAGRAM KLAS Proces tworzenia diagramu klas: zidentyfikowanie i nazwanie klas opcjonalne określenie zobowiązań klas, połączenie klas z wykorzystaniem związków agregacji zidentyfikowanie oraz nazwanie atrybutów i operacji zdefiniowanie asocjacji z użyciem wszystkich jej cech (np. nazwa, rola, liczebność, itp.) określenie innych związków uogólnień, zależności, realizacji pełne zdefiniowanie atrybutów i operacji 37 DIAGRAM KLAS Przykład księgarnia elektroniczna 38

124 DIAGRAM KLAS Przykład finansowy system transakcyjny 39 DIAGRAM KLAS Przykład model bazy danych systemu aukcji internetowej 40

125 Inżynieria Oprogramowania Wykład 3 UML - Unified Modeling Language DIAGRAM OBIEKTOW Egzemplarz, obiekt nazwa operacje stan Diagram obiektów zbiór obiektów i ich związki w ustalonej chwili 2

126 DIAGRAM OBIEKTOW p:przedsiębiorstwo d1: Dział n= Sprzedaz d2: Dział n= Badania kierownik o: Osoba nazwisko 3 DIAGRAM OBIEKTOW Przykład 4

127 Diagram przypadków użycia Przypadek użycia opis zbioru ciągów akcji wykonywanych przez system ciągi zdarzeń główny alternatywny (nadzwyczajny) scenariusze określony ciąg akcji dokumentujący zachowanie kooperacje Przypadek użycia 1 * Kooperacja 1 * Interakcja 1 * Diagram interakcji Diagram sekwencji lub kooperacji 5 Diagram przypadków użycia Przypadek użycia scenariusze: niesformalizowany tekst formalny tekst strukturalny pseudokod tabela 6

128 Diagram przypadków użycia Przypadek użycia scenariusz w postaci tabeli 7 Diagram przypadków użycia Przypadek użycia scenariusz w postaci tabeli - przykład 8

129 Diagram przypadków użycia Przypadek użycia relacje miedzy przypadkami użycia uogólnienie dziedziczenie cech elementu ogólnego zawieranie: <<include>> <<include>> Przeanalizuj ryzyko Określ wartość kontraktu <<include>> Makler giełdowy Wyceń kontrakt Sprzedawca Zarejestruj transakcję Limit przekroczony 9 Diagram przypadków użycia Przypadek użycia relacje miedzy przypadkami użycia rozszerzanie: <<extend>> <<extend>> ( informacje o płatności ) Sprawdź klienta Kup towar 10

130 Diagram przypadków użycia Przypadek użycia - rozszerzanie: <<extend>> 11 Diagram przypadków użycia Przypadek użycia - rozszerzanie: <<extend>> miejsce rozszerzania warunki w przypadku bazowym, konieczne do spełnienia, by mógł być on rozszerzony 12

131 Diagram przypadków użycia Aktor spójny zbiór ról odgrywanych przez użytkowników przypadku użycia ludzie, systemy, bądź urządzenia wykonuje przypadki użycia nie jest częścią systemu cztery rodzaje aktorów: człowiek lub zespół system zewnętrzny urządzenie czas relacje miedzy aktorami relacja uogólnienia relacje miedzy aktorami i przypadkami użycia relacja powiązania możliwość określenia liczebności oraz nawigacji pomiędzy aktorami i przypadkami użycia 13 Diagram przypadków użycia Rodzaje aktorów 14

132 Diagram przypadków użycia Zastosowanie stereotypów graficznych aktorów 15 Diagram przypadków użycia Hierarchia dziedziczenia pomiędzy aktorami 16

133 Diagram przypadków użycia Liczebność i nawigacja w relacjach pomiędzy aktorami i przypadkami użycia 17 Diagram przypadków użycia Diagram przypadków użycia do modelowania dynamiki systemu pozwala modelować zachowanie systemu jako całości, jego podsystemu lub pojedynczej klasy OPIS WYMAGAŃ SYSTEMU analiza obszaru zastosowań, dziedziny przedmiotowej opracowanie projektu przyszłego systemu przystępna i zrozumiała platforma komunikacji i współpracy udziałowców systemu opis zakresu i funkcjonowania przyszłego systemu podstawa testowania funkcji systemu na dalszych jego etapach cyklu życia 18

134 Diagram przypadków użycia Proces tworzenia diagramu przypadków użycia: identyfikacja aktorów identyfikacja przypadków użycia opracowanie związków szczegółowe zdefiniowanie związków udokumentowanie przypadków użycia z wykorzystaniem szablonów - scenariusze 19 Diagram przypadków użycia <<extend>> Zainicjuj połączenie Zainicjuj telekonferencję Sieć telefonii komórkowej Zaakceptuj połączenie <<extend>> Zaakceptuj dodatkowe połączenie Użyj programu obierającego granica systemu Użytkownik Telefon Komorkowy 20

135 Diagram przypadków użycia Przykład system obsługi hurtowni 21 Diagram przypadków użycia Przykład system aukcji internetowej 22

136 Diagram przypadków użycia Przykład 23 Diagram przypadków użycia Diagram kontekstowy zestawienie aktorów będących w relacji z danym systemem traktowanym w kategorii pojedynczego procesu 24

137 Diagramy interakcji interakcja zachowanie obejmujące zbiór komunikatów wysłanych w ramach pewnego zbioru obiektów, w ustalonym otoczeniu i w ściśle określonym porządku i w określonym celu komunikat specyfikacja łączności między obiektami klas, polegającej na wykonaniu określonych czynności komunikat 2: odczytajostatnipunktkontrolny 1: odczytajpozycjęwczasie(p) p : r : PlanistaLotów RozkładLotów wiązanie 25 Diagramy interakcji Składnia komunikatu: <komunikat> ::= [<poprzednik>] [<wyrażenie-sekwencji>] <sygnatura> <poprzednik> ::= [<numer-sekwencji> / ] <wyrażenie-sekwencji> ::= [<numer-komunikatu> <nazwa>][ : <rekurencja>] <rekurencja> ::= [<warunek> <iteracja>] <warunek> ::= [ <specyfikacja-warunku> ] <iteracja> ::= * * [ <specyfikacja-iteracji> ] <sygnatura> ::= [<atrybut> = ] <nazwa-operacji> [ ( <lista-argumentów> ) ] [ : <wartość-zwrotna>] <atrybut> - atrybut klasy, do której komunikat wysyłany <nazwa-operacji> - operacja wykonywana przez odbiorcę komunikatu <lista-argumentów> - lista parametrów dla operacji Przykład: / 2.1 : [wartosctransakcji > 10000] nazwa = obliczwartosc(netto, brutto) 2.3, / rezerwacja : [wzrost >150, waga >=50] nrpokoju = Rezerwuj /4.2 : * [i := i..n] obliczilosc 26

138 Diagramy interakcji otoczenie obiekty wiązanie związek znaczeniowy między obiektami; realizowane poprzez komunikaty między obiektami klas przydzieldo( Badania ) o: Osoba : Przedsiębiorstwo 27 Diagramy interakcji komunikaty Call wywołanie Return przekazania Send wysłanie Create tworzenie Destroy - niszczenie <<create>> <<destroy>> 28

139 Diagramy interakcji porządkowanie przepływ sterowania proceduralny (zagnieżdżony) przepływ sterowania 2: wcisnieto (p) 2.2: zapamietajtrafienie : Widok k: Koordynator : PamiecPodreczna 2.1: l = znajdź (p) plaski przepływ sterowania 1: podniescsluchawke () 2: zlecpolaczenie () o: Osoba : Telefon : Centrala tworzenie, modyfikowanie, niszczenie new, destroyed, transient 29 Diagramy interakcji przedstawia zachowanie systemu dotyczące jednego przypadku użycia diagram sekwencji uwypukla kolejność komunikatów w czasie używany do modelowania przepływu sterowania z uwzględnieniem kolejności komunikatów w czasie diagram komunikacji (kooperacji w UML 1.x) opisuje organizację strukturalną obiektów, wymieniających komunikaty używane do modelowania struktury interakcji diagram przeglądu interakcji - połączenie diagramu czynności i diagramu sekwencji (lub innego diagramu pokazującego dynamikę systemu); wizualizacja współpracujących ze sobą diagramów sekwencji lub komunikacji diagram harmonogramowania obrazuje zachowanie obiektu z naciskiem na dokładne określenie czasu, w którym obiekt jest poddawany jakimś zmianom lub sam wykonuje jakieś działanie 30

140 Diagram sekwencji rodzaje diagramów sekwencji konceptualny diagram sekwencji podstawowe kategorie pojęciowe i graficzne; ogólny zakres i łatwe do zidentyfikowania iteracje implementacyjny diagram sekwencji podstawa opracowania specyfikacji programistycznej; wszystkie kategorie pojęciowe wystąpieniowy diagram sekwencji wystąpienie diagramu sekwencji w odniesieniu do ustalonego scenariusza; jednemu implementacyjnemu diagramowi sekwencji może odpowiadać kilka wystąpieniowych diagramów sekwencji podstawowe elementy klasyfikator komunikat liniażycia ośrodek sterowania 31 Diagram sekwencji rodzaje rodzaje komunikatów synchroniczny przerwanie aktualnego przepływu sterowania nadawcy w momencie wysłania komunikatu (aktywowany przez odbiorcę poprzez wykonanie operacji wskazanej w komunikacie) asynchroniczny brak przerwania aktualnego przepływu sterowania, nadawca nie oczekuje odpowiedzi zwrotny powrót sterowania do nadawcy po wykonaniu komunikatu synchronicznego utracony nieznany odbiorca znaleziony nieznany nadawca opcjonalny - wysłany komunikat może nie zostać obsłużonyony przez odbiorcę (poza standardem UML 2.0) oczekujący nadawca może czekać określony czas na obsłużenie komunikatu (poza standardem UML 2.0) 32

141 Diagram sekwencji warunek kryterium wywołania komunikatu; w nawiasach kwadratowych przed nazwą komunikatu samowywołanie wywołanie własnej operacji przez obiekt iteracja komunikatu: * * [ <specyfikacja-iteracji> ] <nazwa-operacji> rozgałęzienia sposób przekazania sterowania od nadawcy od odbiorców w zależności od spełnienia warunku przypisanego do przesyłanego komunikatu alternatywne komunikaty 33 Diagram sekwencji k : Klient <<create>> {transient} : Transakcja p : PełnomocnikODBC ustalakcje(a,d,o) nadajwartość(d,3,4) nadajwartość(a,"co") zatwierdzono <<destroy>> {transient} wskazuje, że egzemplarz jest tworzony podczas wykonywania rozważanej interakcji i niszczony przed jej zakończeniem 34

142 Diagram sekwencji Fragmenty wyodrębnione (ang. combinated fragments) logicznie spójny obszar interakcji część diagramu sekwencji ze specyficznymi właściwościami określonymi przez operator interakcji bardziej precyzyjne zobrazowanie istoty interakcji operator iteracji określenie funkcjonalności realizowanej przez fragment wyodrębniony alt alternatywa opt opcja break przerwanie loop iteracja neg funkcjonalność nieprawidłowa par współbieżność critical obszar krytyczny assert formuła consider istotność ignore nieistotność strict ścisłe uporządkowanie seq słabe uporządkowanie operand interakcji oddzielna część fragmentu wyodrębnionego 35 Diagram sekwencji Fragmenty wyodrębnione: alt alternatywa 36

143 Diagram sekwencji Fragmenty wyodrębnione: opt opcja 37 Diagram sekwencji Fragmenty wyodrębnione: break przerwanie 38

144 Diagram sekwencji Fragmenty wyodrębnione: loop iteracja 39 Diagram sekwencji Fragmenty wyodrębnione: neg funkcjonalność nieprawidłowa 40

145 Diagram sekwencji Fragmenty wyodrębnione: par współbieżność 41 Diagram sekwencji Fragmenty wyodrębnione: critical obszar krytyczny 42

146 Diagram sekwencji Fragmenty wyodrębnione: assert formuła 43 Diagram sekwencji Fragmenty wyodrębnione: consider istotność 44

147 Diagram sekwencji Fragmenty wyodrębnione: ignore nieistotność 45 Diagram sekwencji Fragmenty wyodrębnione: strict ścisłe uporządkowanie 46

148 Diagram sekwencji Fragmenty wyodrębnione: seq słabe uporządkowanie 47 Diagram sekwencji Przywołanie wystąpienia interakcji umieszczenie na bazowym diagramie sekwencji odwołania do ściśle powiązanego z nim diagramu interakcji za pomocą operatora przywołania ref zainicjowanie wystąpienia interakcji w systemie przez: komunikat czynnik czasu 48

149 Diagram sekwencji Bramy punkt przejścia komunikatów z/do diagramów sekwencji, przywoływanych wystąpień interakcji lub fragmentów wyodrębnionych do /z ich otoczenia rodzaje bram: bramy formalne cały diagram sekwencji bramy właściwe przywoływane wystąpienia interakcji bramy wyrażeniowe operandy interakcji danego fragmentu wyodrębnionego 49 nazywanie: bezpośrednio nazwa bramy Diagram sekwencji Bramy pośrednio nazwa komunikatu przechodzącego przez bramę z przedrostkiem in lub out 50

150 Diagram sekwencji Proces tworzenia diagramu sekwencji: analiza danego przypadku użycia i scenariuszy tego przypadku identyfikacja obiektów i/lub aktorów uczestniczących w interakcji opracowanie diagramu konceptualnego, zawierającego obiekty, aktorów, komunikaty, ośrodki sterowania opracowanie implementacyjnego diagramu sekwencji, zawierającego dodatkowe elementy 51 Diagram komunikacji składniki: struktura organizacyjna klasyfikatorów interakcja pomiędzy ich instancjami podstawowe elementy klasyfikator komunikat asocjacja elementy zaawansowane komunikat synchroniczny, komunikat asynchroniczny, komunikat zwrotny, komunikat opcjonalny, komunikat oczekujący tworzenie/niszczenie obiektów warunki samowywoływanie iteracja zagnieżdżanie 52

151 Diagram komunikacji k : Klient 1. <<create>> 2. ustalakcje(a,d,o) 3. <<destroy>> <<local>> : Transakcja <<global>> p : PełnomocnikODBC {transient} nadajwartość(d,3,4) 2.2. nadajwartość(a,"co") <<local>> <<global>> - stereotypy ścieżek, oznaczające że wyszczególniony obiekt jest w lokalnym, bądź globalnym, zasięgu nadawcy 53 Diagram komunikacji Przykład 54

152 Diagram komunikacji Numerowanie komunikatów numeracja prosta numeracja kwalifikowana (system klasyfikacji dziesiętnej Deweya) 55 Diagram komunikacji Zagnieżdżanie komunikatów 56

153 Diagram komunikacji Współbieżność i poprzednicy 57 Diagram komunikacji obiekty wielokrotne reprezentacja zbioru anonimowych obiektów klasy aktywne obiekt aktywny może autonomicznie inicjować własne wątki i sterować wykonaniem tych wątków 58

154 Diagram komunikacji Proces tworzenia diagramu komunikacji: analiza danego przypadku użycia i scenariuszy tego przypadku identyfikacja obiektów i/lub aktorów uczestniczących w interakcji powiązanie zdefiniowanych klasyfikatorów identyfikacja i nadanie nazw przesyłanym komunikatom numerowanie komunikatów dodanie elementów zaawansowanych 59

155 Inżynieria Oprogramowania Wykład 4 UML - Unified Modeling Language Diagram czynności diagram czynności przedstawia przepływ sterowania od czynności do czynności opisuje, jak są uszeregowane działania, dając możliwość opisu czynności warunkowych lub współbieżnych zawiera: akcji i czynności przejścia (state/activity transition) metasymbole dla zobrazowania procesów warunkowych i współbieżnych czasami obiekty może zawierać notatki i ograniczenia czynność akcja 2

156 czynność a akcja: Diagram czynności czynność podzielna, ogólna, dozwolona dekompozycja, znaczący czas realizacji akcja niepodzielna, szczegółowy przypadek, niedozwolona dekompozycja, nieznaczący czas realizacji dekompozycja czynności 3 Diagram czynności stany akcji reprezentują na diagramie akcje nie mogą być one dekomponowane stany czynności mogą być dekomponowane: mogą zostać w pewnym momencie przerwane czas ich realizacji jest znaczący symbole obu rodzajów stanów są identyczne stan czynności może jednak zawierać akcje wejściowe (entry), oraz akcje wyjściowe (exit) Zaproponuj cenę Akcja prosta index:=znajdź(e) + k Wyrażenie Przetwórz rachunek( ) entry/ StanKonta( ) Stan czynności Akcja wejściowa 4

157 stan początkowy stan końcowy zakończenie przepływu przejścia (transition) przepływy sterowania: przepływy decyzyjne: decyzje Diagram czynności łączniki A złączenia przepływ współbieżny: rozwidlenia, scalenia 5 Diagram czynności Decyzja przykład 6

158 Złączenie - przykład Diagram czynności 7 Diagram czynności rozgałęzienia rozgałęzienie ma jedno wejście i kilka dozorowanych wyjść tylko jedno wyjście może być wybrane rozwidleniaścieżek scalaniaścieżek scalenie ma wiele wejść i tylko jedno wyjście 8

159 Diagram czynności Stan czynności Przyjęcie zam ówienia Rozwidlenie Rozgałęzienie Realizacja zam ów ienia Dozór Wys łanie faktury [ pilne ] [ els e ] D os tawa w 24 godz. Dos tawa zwykła Przyjęcie zapłaty Scalenie 9 partycje tory w UML 1.x Diagram czynności partycja mechanizm grupowania elementów diagramu czynności powiązanych przepływami sterowania i przepływami danych, pełniących określoną, wspólną rolę tory - służą do podzielenia stanów czynności na grupy, z których każda reprezentuje jednostkę przedsiębiorstwa odpowiedzialna za przydzielone czynności pionowe lub poziome mogą być podzielone na subpartcje podział na partycje według określonego kryterium, np..: organizacja firmy położenie geograficzne aktorzy i obiekty miejsce powstawania kosztów 10

160 Klient Diagram czynności Dział sprzedaży Hurtow nia Zamów tow ary Kontynuuj pracę Zrealizuj zamów ienie z : Zamów ienie [realizow ane] Zgromadź tow ary Wyślij zamów ione tow ary Odbierz zamów ienie Wystaw rachunek z : Zamów ienie [zrealizow ane] Zapłać rachunek r : Rachunek [nie zapłacony] r : Rachunek [zapłacony] Zakończ zamów ienie 11 Diagram czynności 12

161 Diagram czynności obszar rozszerzenia ściśle zdefiniowany fragment diagramu czynności z jednoznacznie określonymi wejściami i wyjściami, wykonywanymi wielokrotnie, stosownie do liczby elementów na wejściu obszar przerwania grupa czynności, w obrębie której w wyniki działania przepływu przerwania realizacja wszystkich czynności jest natychmiast przerwana 13 przepływ obiektów Diagram czynności na diagramie czynności można zobrazować zmianę roli, stanu i wartości atrybutów każdego z obiektów stan obiektu jest zapisywany w nawiasach kwadratowych tuż pod nazwą obiektu udokumentowanie przepływu danych przy użyciu: przekaźniki danych zestaw przekaźników parametr czynności wagi sygnały bufor centralny składnica danych 14

162 Diagram czynności Przekaźniki danych sposób na udokumentowanie obiektu biorącego udział w przepływie obiektów pomiędzy czynnościami 15 Przekaźniki danych rodzaje przekaźników Diagram czynności 16

163 Diagram czynności Parametr czynności uzupełnienie w opisie przepływu danych w dekomponowanym, hierarchicznie uporządkowanym diagramie czynności 17 Diagram czynności Wagi ograniczenie wskazuje minimalną liczbę znaczników sterowania, przekazywanych zeźródła do czynności lub akcji docelowej w nawisach klamrowych nad przepływem, np. {weight =5} gdy weight = 0 wszystkie znaczniki sterowania przekazane do czynności docelowej gdy liczba znaczników nie spełnia minimum, to żaden nie będzie przekazany 18

164 Diagram czynności Sygnały sygnał asynchroniczny bodziec inicjujący czynność lub akcję rodzaje: nadawcze odbiorcze oraz czas 19 Diagram czynności Bufor centralny służy do zarządzania przepływami danych z różnych obiektów źródłowych do różnych obiektów docelowych do wdrożenia procedur kolejkowania przejmuje obiekty i przekazuje je do obiektów wynikowych stereotyp <<CentralBuffer>> + nazwy obiektów o określonym stanie 20

165 Diagram czynności Składnica danych rodzaj bufora centralnego dla stałych danych przechowywanych przez dłuższy czas stereotyp <<datastore>> 21 Diagram czynności Proces tworzenia diagramu czynności: identyfikacja podstawowych czynności i sygnałów na podstawie przypadku użycia połączenie czynności i sygnałów za pomocą przepływów sterowania opcjonalnie podział czynności na akcje zdefiniowanie decyzyjnych i współbieżnych przepływów sterowania wprowadzenie elementów zaawansowanych, np. przekaźniki danych, bufory centralne, składnice danych podział diagramu na partycje 22

166 Diagram czynności Przykład 23 Diagram czynności Przykład 24

167 Diagram maszyny stanowej zdarzenie Zdarzenia i sygnały Bezczynność Aktywność rodzaje zdarzeń: asynchroniczne: sygnał, upływ czasu, zmiana stanu synchroniczne: wywołanie operacji lub zdarzenia zewnętrzne zdarzenia wewnętrzne 25 Diagram maszyny stanowej Zdarzenia i sygnały sygnał reprezentuje nazwany obiekt, który jest asynchronicznie wysyłany przez jeden obiekt, a odbierany przez inny <<signal>> AwariaSerwera - nrserwera + wyślij() sygnał może być wysłany: w wyniku przejścia w maszynie stanowej przesłania komunikatu w interakcji (wywołania) wykonania operacji <<s ignal>> Hamowanie siła : Float <<send>> Pojazd pozycja prędk ość <<send>> zwolnij() 26

168 Diagram maszyny stanowej Zdarzenia i sygnały wywołanie jest zdarzeniem synchronicznym, tzn. gdy obiekt wywołuje operację innego, sterowanie jest przekazywane od nadawcy do odbiorcy, a po wykonaniu tej operacji sterowanie wraca do nadawcy Sterowanie ręczne wlaczautomatycznegopilota(zwykly) Sterowanie automatyczne upływ czasu reprezentowane przez zdarzenie czasowe when (23:49) /autotest() Zdarzenie zmiany Bezczynność after (2s) / przerwijpolaczenie() Aktywność Zdarzenie czasowe 27 Diagram maszyny stanowej maszyna stanowa opisuje ciąg stanów przyjmowanych przez obiekt w odpowiedzi na zdarzenia zachodzące w czasie jego życia a także reakcje obiektu na te zdarzenia służy do modelowania zachowania jednego obiektu użycie maszyny stanowej to najlepszy sposób opisu zachowania obiektów, które muszą reagować na bodźce asynchroniczne i upływ czasu 28

169 Diagram maszyny stanowej stan początkowy stan końcowy zdarzenie zacieplo (pozadanatemp) Chłodzenie Bezczynność tempok tempok zacieplo(pozadanatemp) zazimno(pozadanatemp ) Grzanie Rozpalanie akcja gotowe / pelnamoc() zazimno(pozadanatemp) Ogrzanie przejście stan zagnieżdżony 29 Diagram maszyny stanowej stan obiektu jest sytuacją, w jakiej się obiekt znajduje przez skończony okres swego życia, kiedy spełnia jakiś warunek, wykonuje jakąś czynność lub czka na jakieś zdarzenie sekcje stanu: sekcja nazwy sekcja czynności wewnętrznych czynności wykonywane w trakcie przyjmowania danego stanu przez obiekt; słowa kluczowe: entry, exit, do sekcja przejść wewnętrznych szczególne przypadki przejść, których wykonanie nie prowadzi do zmiany stanu sekcja dekompozycji (w przypadku stanów złożonych) 30

170 Diagram maszyny stanowej zdarzenie jest wystąpieniem bodźca, który może uruchomić przejście między stanami rodzaje zdarzeń: sygnał zdarzenie wywołania zdarzenie czasowe zdarzenie zmiany stanu zdarzenie odroczone stan może mieć piec składników: nazwa akcje wejściowe i wyjściowe przejścia wewnętrzne podstany zdarzenia odroczone stan początkowy stan końcowy 31 Diagram maszyny stanowej przejście jest związkiem między dwoma stanami, wskazując na możliwość znalezienia się obiektu w kolejnym stanie (po wykonaniu pewnych akcji) przejście może mieć pięć składników: stan źródłowy zdarzenie uruchamiające warunek dozoru akcja stan docelowy 32

171 Diagram maszyny stanowej podstan stan zagnieżdżony w innym stanie; rodzaje: sekwencyjne współbieżne podstany sekwencyjne dzielą przestrzeń stanów stanu złożonego na stany rozłączne stany wznowienia podstany współbieżne umożliwiają tworzenie dwóch lub więcej maszyn stanowych, działających równolegle w ramach otaczającego je obiektu czynność jest operacją wieloetapową wykonywaną przez obiekt akcja to wykonywalna, niepodzielna operacja zakończona zmianą stanu, lub przekazaniem wartości przykłady akcji: wywołanie operacji, wysłanie sygnału, utworzenie lub zniszczenie obiektu, ale także obliczenie wartości 33 Diagram maszyny stanowej kartawsunięta anulow ano konserw uj Bezczynność Konserw acja Obsługa Weryfikacja Weryfikacja Wybór [kontynuacja] Realizacja entry/odczytajkartę exit/w ysuńkartę [ not kontynuacja] Drukow Drukow anie anie 34

172 Diagram maszyny stanowej 35 Diagram maszyny stanowej wpływ upływu czasu na zdarzenia modeluje się za pomocą: zdarzenia zmiany z parametrem w postaci czasu zdarzenia czasowego ze słowem kluczowym after 36

173 Diagram maszyny stanowej diagram stanów przedstawia maszynę stanową z uwypukleniem przepływu sterowania miedzy stanami opisuje wszystkie możliwe stany, w jakich może znaleźć się obiekt danej klasy, a także to, jak zmienia się stan obiektu pod wpływem zdarzeń doń docierających przedstawia zwykle cały cykl życia pojedynczego obiektu 37 Diagram maszyny stanowej / pobierz pierwszą pozy cję [ Nie wszy stkie pozy cje sprawdzone ] / pobierz nastepną pozy cję Sprawdzanie do/ sprawdź pozy cję [ Wszy stkie pozy cje sprawdzone && wszy stkie są dostępne ] Wy sy łka do/ inicjuj dostawę [ Wszy stkie pozy cje sprawdzone && niektóry ch pozy cji brak ] Pozy cja otrzy mana[ Niektóry ch pozy cji brak ] Pozy cja otrzy mana[ Wszy stkie pozy cje dostępne ] Dostarczone Oczekiwanie Dostarczone 38

174 Diagram maszyny stanowej pseudostan abstrakcyjny element modelowania diagramu maszyny stanowej umożliwiający organizowanie złożonych ścieżek przejść rodzaje pseudostanów: początkowy płytkie wznowienie ostatni aktywny stan obiektu przed wznowieniem, nie przechowuje informacji o podstanach tego stanu H głębokie wznowienie przechowuje informacje o podstanach tego stanu scalenie (diagram czynności) H* rozwidlenie (diagram czynności) punkt węzłowy decyzja (diagram czynności) punkt wejścia punkt wyjścia punkt zniszczenia 39 Diagram maszyny stanowej Przykład 40

175 Diagram maszyny stanowej rodzaje przejść: proste miedzy stanemźródłowym a docelowym zwrotne do tego samego stanu wewnętrzne element danego stanu lokalne pomiędzy podstanami danego stanu złożonego zewnętrzne opuszczające stan złożony do innego stanu wysokiego poziomu (grupowe) wychodzące ze stanów złożonych złożone z kilku przejść, scaleń, rozwidleń, decyzji automatyczne niezwiązane zżadnym zdarzeniem ani warunkiem 41 Diagram maszyny stanowej Proces tworzenia diagramu maszyny stanowej: określenie rodzaju tworzonej maszyny stanowej i identyfikacja obiektów zidentyfikowanie poszczególnych stanów maszyny stanowej określenie hierarchii stanów, podstanów oraz obszarów współbieżnych powiązanie stanów i podstanów przejściami ewentualne zastosowanie odpowiednich pseudostanów 42

176 Diagram maszyny stanowej jeżeli stan reaguje na pewne zdarzenie działaniem nie powodującym przejścia, zaznaczamy to umieszczając w symbolu stanu opis tego działania w postaci: nazwazdarzenia/nazwadziałania. przykłady działań nie powodujących przejścia: Entry/akcja akcja stowarzyszona ze zdarzeniem Entry jest wykonywana przy każdym wejściu do stanu Exit/akcja akcja stowarzyszona ze zdarzeniem Exit jest wykonywana przy każdym wyjściu ze stanu Do/czynność czynność stowarzyszona z danym stanem Even/akcja(argumenty) akcja stowarzyszona z danym stanem nie powodująca przejścia 43

177 Inżynieria Oprogramowania Wykład 5 UML - Unified Modeling Language Procesy i wątki, procesy współbieżne obiekt aktywny to obiekt, który jest właścicielem procesu lub wątku i może uruchomić niezależne sterowanie klasa aktywna to klasa, której egzemplarze są obiektami aktywnymi pozostałe klasy nazywamy pasywnymi proces to ciężki przepływ sterowania, który może się wykonywać współbieżnie z innymi procesami (stereotyp process) wątek to lekki przepływ sterowania, który może się wykonywać z innymi wątkami w ramach jednego procesu (stereotyp thread) ZarządcaPanelu nrpanelu: Integer Signals naciśniętoprzycisk(p:przycisk) włączonozasilanie wyłączonozasilanie Sygnały odbierane przez klasę aktywną 2

178 Procesy i wątki, procesy współbieżne w UML niezależny przepływ sterowania jest modelowany w postaci obiektu aktywnego przepływ sterowania: system sekwencyjny system współbieżny prawdziwą współbieżność można osiągnąć trzema metodami: rozpraszając obiekty aktywne na wielu węzłach umieszczając obiekty aktywne na węzłach z wieloma procesorami łącząc powyższe, dwie metody 3 Procesy i wątki, procesy współbieżne własności procesów własności wątków własności klas aktywnych: klasy aktywne mają te same własności, co zwykłe klasy (pasywne) własności obiektów aktywnych: obiekty aktywne mogą wystąpić na diagramach w tych samych miejscach, co obiekty pasywne, najczęściej spotkamy je: w diagramach interakcji (kooperacji i przebiegu) obiekty aktywne, podobnie jak pasywne, mogą wysyłać i odbierać sygnały, a także zdarzenia wywołania 4

179 Komunikacja międzyobiektowa wymiana komunikatów w systemie zawierającym zarówno obiekty aktywne, jak i pasywne: przekazywanie komunikatów a przebieg interakcji: pomiędzy dwoma obiektami pasywnymi pomiędzy dwoma obiektami aktywnymi od obiektu aktywnego do pasywnego od obiekty pasywnego do aktywnego 5 Komunikacja międzyobiektowa t : 1. s1:inicjuj() Tablica obiekt aktywny s : SterownikTablicy 2. mawskazówkę(w) 4. :umieśćrozwiązanieczęściowe() obiekt aktywny 3. s2:zacznijposzukiwania() 4. s3:w.oceńwartość() : ŹródłoWiedzy obiekt aktywny 6

180 Czas i przestrzeń znacznik czasu oznaczenie czasu zajścia zdarzenia wyrażenie czasowe wyrażenie, którego wartością jest czas względny lub bezwzględny położenie umiejscowienie komponentu na węźle 7 Diagram komponentów komponent fizyczna, wymienna część systemu, która wykorzystuje i realizuje pewien zbiór elementów agent.java WykrywaczOszustw.dll Realizes WykrywanieOszustw StrategiaOchrony <<component>> Zamawianie.php Grafika.dll 8

181 komponent Diagram komponentów nazwa prosta lubścieżkowa przypominają klasy komponenty a interfejsy komponent realizuje interfejs lub komponent korzysta z usług oferowanych przez interfejs rodzaje komponentów: komponenty wdrożenia komponenty procesu wytwórczego komponenty wykonania porządkowanie komponentów można komponenty grupować w pakiety stereotypy: executable, library, table, subsystem, service wykorzystanie komponentów 9 Interfejs interfejs to zestaw operacji, wyznaczony przez usługi oferowane przez klasę lub komponent umożliwia korzystanie z usług poszczególnych komponentów i pośredniczy pomiędzy komponentami typ to stereotyp klasy używany do definiowania dziedziny obiektów, wraz z operacjami, które można na tych obiektach wykonać rola to zachowanie klasy, lub komponentu, w określonym kontekście ICzujnik UsługiSiecio we::iruter << interface>> ObsługaPołączenia URL nawiążpołączenie() analizujurl() ustawurl() 10

182 Interfejs interfejs udostępniający poprzez ten interfejs komponenty oferują swoje usługi interfejs wymagający (pozyskujący) pozwalają komponentom na korzystanie z usług innych komponentów interfejs, może brać udział w: powiązaniach, uogólnieniach, zależnościach dwa sposoby realizacji interfejsu: w postaci uproszczonej w postać rozszerzonej udostępniane (używane) interfejsy przez klasę lub komponent, modelujemy za pomocą zależności, wymagające (oferowane) za pomocą realizacji <<realize>> zależność realizacja 11 Interfejs Interfejs udostępniający Szkolenie IRejestracja Interfejs wymagający Zamawianie IKlient 12

183 Interfejs Zależność Cel Celownik Obserwator Realizacja (postać uproszczona) Cel id bieżącapozycja Zależność <<Interface>> Obserwator Celownik przenieść() nadajprędkość() dko spodziewanapozycja() aktualizuj() Realizacja (postać rozszerzona) 13 Diagram komponentów Postać niepełna rysunek.java komponent.java ImageObserver Postać rozszerzona rysunek.java zależność <<interface>> ImageObserver abort : int error : int imageupdate(); Boolean realizacja komponent.java 14

184 Diagram komponentów specyfikacja komponentów: czarna skrzynka komponent z jego interfejsami udostępniającymi <<provided interfaces>> i wymagającymi <<required interfaces>> biała skrzynka komponent z interfejsami udostępniającymi i wymagającymi oraz klasyfikatorami <<realizations>> i artefaktami <<artifacts>> komponent <<provided interfaces>>... <<required interfaces>>... <<realizations>>... <<artifacts>> Diagram komponentów porty wyróżnialne punkty związane ściśle z interfejsami, przez które komponent komunikuje się z otoczeniem poprzez interfejs i port komponent oferuje swoje usługi i oczekuje realizacji konkretnych usług przez otocznie port złożony łączy kilka interfejsów IDostawca Dostawca Magazyn Dostawca IKsiegowosc IKlient IDostawca Magazyn 16

185 Diagram komponentów konektory łączą komponenty rodzaje konektorów: delegowany łączy poprzez port instancje klasyfikatorów znajdujące się na zewnątrz komponentu z wewnętrzną realizacją interfeju składany powiązanie dwóch komponentów, z których jeden udostępnia poprzez interfejs usługi pozyskane przez drugi komponent notacja kółko gniazdo (ball and socket), przy pomocy której połączenie dwóch komponentów poprzez interfejs <<delegate>> 17 Diagram komponentów diagram komponentów obrazuje uporządkowanie komponentów i związki miedzy nimi zawiera: komponenty interfejsy zależności, uogólnienia, powiązania i realizacje oraz notatki, ograniczenia, pakiety i podsystemy zastosowanie diagramu komponentów 18

186 Diagram komponentów 19 Diagram komponentów 20

187 Diagram wdrożeń węzeł - to fizyczny składnik systemu informatycznego ma zwykle pewna ilość pamięci i zdolność przetwarzania nazwa prosta lubścieżkowa przypominają komponenty węzły realizują działania komponentów porządkowanie węzłów można węzły grupować w pakiety rodzaje węzłów: węzły sprzętowe, np. serwery, urządzenia wejścia-wyjścia, routery, bramki,... węzły platformy użytkowania systemu, np. systemy operacyjne, systemy zarządzania bazą danych, platformy,... Sprzedaż Deploys sklep.exe adresy.exe Server :: KopiaZapasowa {tylkozdalanadministracja} 21 Diagram wdrożeń artefakt sztucznie wytworzony produkt rozlokowanie rozmieszczenie komponentów lub artefaktów w określonym węźle stereotypy artefaktów: executable, library, table, subsystem, service, scropt, document, file, source 22

188 Diagram wdrożeń kooperacja zestaw klas, interfejsów i innych bytów współdziałających w celu wywołania pewnego zespołowego zachowania niemożliwego do osiągnięcia w pojedynkę nazwa struktura dwa aspekty: strukturalny czynnościowy zachowanie porządkowanie kooperacji rodzaje związków: realizacja, udoskonalenie komunikacja międzywęzłowa 23 Diagram wdrożeń ścieżki komunikowania pomiędzy węzłami stereotypowe asocjacje osadzanie komponentów i artefaktów na węźle: tekstowe wyliczanie elementów bezpośrednie ulokowanie w węźle (symbole graficzne) połączenie komponentów i artefaktów stereotypową zależnością <<deploy>> z węzłem manifestowanie zawieranie i reprezentowanie przez komponent lub artefakt swoich elementów składowych zależność ze stereotypem <<manifest>> pomiędzy danym artefaktem a jego składnikiem specyfikacja rozlokowania zawiera zestaw cech komponentu lub artefaktu, określa parametry użytkowania komponentu osadzonego na określonym węźle 24

189 Diagram wdrożeń diagram wdrożeń obrazuje konfigurację węzłów działających w czasie wykonania i zainstalowanie na nich komponentów zawiera: węzły zależności i powiązania ścieżki komunikowania osadzone komponenty i artefakty manifestowanie specyfikację rozlokowania oraz notatki, ograniczenia, pakiety lub podsystemy zastosowanie diagramu wdrożenia 25 Diagram wdrożeń węzeł Modem Internet połączenie <<processor> Serwer pamięci podręcznej <<processor> Serwer pamięci podręcznej <<network>> sieć lokalna węzeł <<processor> Serwer główny <<processor> Serwer <<processor> Serwer 26

190 Diagram wdrożeń 27 Diagram wdrożeń 28

191 Diagram pakietów podział systemu z logicznego punktu widzenia służy, by uporządkować strukturę zależności w systemie, który ma bardzo wiele klas, przypadków użycia itp. pakiet zawiera w sobie wiele elementów, które opisują jakieś w miarę dobrze określone zadanie elementy diagramu: pakiety zależności zagnieżdżanie pakietów na jednym diagramie obraz całości, bądź dużego fragmentu, systemu pakiet 29 Diagram pakietów pakiet mechanizm ogólnego zastosowania, służy do organizowania elementów w grupy może zawierać dowolne klasyfikatory UML, diagramy, biblioteki klas, podsystemy, modele,... diagram pakietów logiczna struktura systemu w postaci zestawu pakietów połączonych zależnościami i zagnieżdżeniami 30

192 Diagram pakietów Zagnieżdżenie pakietów 31 stereotypowe pakiety Diagram pakietów model <<model>> <<model>> Model Dziedziny Model Dziedziny podsystem <<subsystem>> <<subsystem>> Analiza Sprzedaży Analiza Sprzedaży zrąb <<framework>> <<framework>> MechanizmLicytowania biblioteka klas <<modellibrary>> <<modellibrary>> GUI 32

193 Systemy i modele system zbiór zespolonych ze sobą bytów, sformowany w celu wykonania określonego zadania i opisany za pomocą zestawu modeli, z których każdy przedstawia inny punkt widzenia system ma cechy pakietu i klasyfikatora podsystem zestaw bytów, z których cześć stanowi specyfikację zachowania pozostałych podsystem ma cechy pakietu i klasyfikatora model uproszczenie rzeczywistości, abstrakcja systemu perspektywa spojrzenie na model 33 Wzorce wzorzec zwyczajowo przyjęte rozwiązanie typowego problemu w danym kontekście mechanizm wzorzec projektowy określają strukturę i zachowanie klas w postaci kooperacji modelowanie na dwa sposoby zrąb wzorzec architektoniczny określają strukturę i zachowanie całego systemu w postaci stereotypowych pakietów zrąb <<framework>> Należności Fakturowanie mechanizm Uzgadnianie 34

194 Stereotypowe zależności Diagram pakietów <<import>> - włączanie klasyfikatorów będących zawartością pakietu docelowego do pakietuźródłowego w trakcie użytkowania systemu Sprzedaż <<import>> Obsługa Sieci Restauracji <<merge>> - scalenie klasyfikatorów, tworzących zawartość pakietu docelowego, z klasyfikatorami będącymi zawartością pakietuźródłowego Rozproszona Baza Danych <<merge>> Lokalna Baza danych <<access>> - możliwość dostępu pakietu źródłowego do zawartości pakietu docelowego bez fizycznego pobierania danych Obsługa Należności <<access>> Udzielanie Kredytów 35 Diagram pakietów Proces tworzenia diagramu pakietów: identyfikacja i nazwanie pakietów zakwalifikowanie zidentyfikowanych pakietów z zastosowaniem odpowiednich stereotypów określenie zagnieżdżeń pakietów powiązanie pakietów z wykorzystaniem zależności zdefiniowanie zależności poprzez odpowiednie stereotypy 36

195 Diagram pakietów 37 Diagram pakietów 38

196 Diagram przeglądu interakcji (diagram sterowania interakcją) diagram przeglądu interakcji rodzaj diagramu interakcji, dokumentujący przepływ sterowania pomiędzy logicznie powiązanymi diagramami (sekwencji, komunikacji, harmonogramowania) i fragmentów interakcji z wykorzystaniem elementów modelowania diagramów czynności wizualizacja współpracujących ze sobą diagramów interakcji notacja bardzo podobna do notacji diagramu czynności podstawowe kategorie pojęciowe diagramu przeglądu interakcji przepływ sterowania stan początkowy, stan końcowy zakończenie przepływu fragment interakcji przywołanie wystąpienia interakcji odwołanie do diagramu interakcji, oznaczonego nazwą 39 Diagram przeglądu interakcji Fragment interakcji odwołanie do diagramu interakcji, opisanego całościowo w danym fragmencie iteracji oznaczane jako: przywołanie wystąpienia interakcji ref odsyłacze do innych diagramów interakcji, gdy są zbyt skomplikowane wyróżnik danego diagramu interakcji prostokąt zawiera cały diagram interakcji, gdy jest niezbyt obszerny 40

197 Diagram przeglądu interakcji 41 Diagram przeglądu interakcji kompletne diagramy przebiegu zastąpione odnośnikami (ref) 42

198 Diagram przeglądu interakcji Składniki z diagramu czynności 43 Diagram przeglądu interakcji Proces tworzenia diagramu pakietów: zgromadzenie wszystkich opracowanych diagramów interakcji dla danego przypadku użycia przeanalizowanie wzajemnych zależności pomiędzy tymi diagramami zakwalifikowanie poszczególnych diagramów do przywoływanych wystąpień interakcji lub fragmentów interakcji ustalenie logicznej kolejności wykonywania poszczególnych fragmentów interakcji opracowanie kompletnego diagramu sterowania interakcja z zastosowaniem wszystkich dostępnych elementów 44

199 Diagram przeglądu interakcji 45 Diagram przebiegów czasowych (diagram harmonogramowania) diagram przebiegów czasowych rodzaj diagramu interakcji, reprezentujący na osi czasu zmiany dopuszczalnych stanów, jakie może przyjmować obiekt lub aktor uczestniczący w interakcji projektowanie systemów czasu rzeczywistego lub aplikacji, których działanie jest powiązane z zewnętrznymi urządzeniami obrazuje zachowanie obiektu z naciskiem na dokładne określenie czasu, w którym obiekt jest poddawany jakimś zmianom lub sam wykonuje jakieś działanie do sporządzenia harmonogramów interakcji dostępne dwie notacje: czasowa zadaniowa 46

200 Diagram przebiegów czasowych skala czasu w postaci ustalonych odcinków na osi poziomej obiekty lub aktorzy biorący udział w interakcji na osi pionowej elementy diagramu przebiegów czasowych: klasyfikator nazwa stanu linia zmiany stanów instancji klasyfikatora typowe stany: bezczynność, czuwanie, oczekiwanie, wykonywanie, obliczanie, Diagram przebiegów czasowych zdarzenie załamanie linii zmiany stanów, powoduje zainicjowanie nowego stanu ograniczenia czasowe wyznaczają czas trwania danego stanu notacja czasowa notacja zdarzeniowa 48

201 Diagram przebiegów czasowych Harmonizacja linii zmiany stanów kilka obiektów wraz ze swoimi stanami na jednym diagramie 49 Diagram przebiegów czasowych Przesyłanie komunikatów miedzy obiektami 50

202 Diagram przebiegów czasowych Proces tworzenia diagramu przebiegów czasowych: identyfikacja interakcji i jej diagramu sekwencji lub diagramu komunikacji przeniesienie lub dobór obiektów/aktorów identyfikacja stanów każdego obiektu z wykorzystaniem diagramów maszyny stanowej ustalenie przedziału czasowego diagramu określenie linii zmiany stanów obiektów wprowadzenie ograniczeń czasowych dla poszczególnych stanów wprowadzenie zdarzeń na podstawie diagramów maszyny stanowej harmonizacja linii zmiany stanów wszystkich obiektów ewentualne wprowadzenie komunikatów 51 Diagram strukturalny (diagram struktur połączonych) diagram strukturalny wzajemnie współdziałające części systemu dla osiągnięcia pożądanej funkcjonalności współdziałania do modelowania współpracy klas, interfejsów, komponentów, które są zaangażowane w pewne zadanie podobny do diagramu klas, ale obrazuje elementy systemu wykonujące wspólne zadanie, typowe sposoby użycia elementów systemu, związki między tymi elementami, które może być trudno przedstawić na innych diagramach,... elementy diagramu strukturalnego: kooperacja (współdziałanie) część, połączenie interfejs, konektor składany, port 52

203 Diagram strukturalny (diagram struktur połączonych) kooperacja (współdziałanie) Kooperacja część obejmuje i uogólnia klasy, obiekty, atrybuty, operacje, przypadki użycia, komponenty, węzły oraz inne kooperacje część 53 Diagram strukturalny Przykład 54

204 Diagram strukturalny typowy sposób przedstawienia związku między fakturą a jej częściami 55 Diagram strukturalny może się okazać, że wcale nie chcemy, aby Naglowek i Dane były oddzielnymi klasami chcemy tylko podkreślić fakt, że Faktura składa się z takich części jednak bez potrzeby specyfikowania detali Faktura modelowana jako klasa, Naglowek i Dane jako części (parts) łącznik (connector) pokazuje związek między częściami krotności 56

205 Diagram strukturalny inny sposób pokazania związku strukturalnego kilku klas używając elementu współpracy (collaboration): 57 Diagram strukturalny element współpracy, z którym połączone (lub wewnątrz którego leżą) współdziałające klasy 58