Testowanie oprogramowania Wzorce projektowe

Transkrypt

1 Testowanie oprogramowania Wzorce projektowe 1/66 Testowanie oprogramowania Wzorce projektowe dr inż. Grzegorz Michalski 17 listopada 2015

2 Testowanie oprogramowania Wzorce projektowe 2/66 Plan wykładu Agenda Dlaczego należy stosować wzorce projektowe. Jak zbudowane są wzorce projektowe. Zbiór wzorców projektowych.

3 Testowanie oprogramowania Wzorce projektowe 3/66 Dlaczego? Motywacja Różne dziedziny inżynierii stawiają sobie odwiecznie następujące pytania: Czy typowe w danej dziedzinie problemy można rozwiązywać w powtarzalny sposób? Czy takie problemy mogą zostać zapisane w sposób abstrakcyjny, w celu wykorzystania ich do opracowania rozwiązań w różnych kontekstach?

4 Testowanie oprogramowania Wzorce projektowe 4/66 Skąd się wzięły wzorce? Wzorzec opisuje problem, który powtarza się wielokrotnie w danym środowisku, oraz podaje istotę jego rozwiązania w taki sposób, zby można było je zastosować milion razy bez potrzeby powtarzania tej samej pracy Christopher Alexander Język wzorców 1977

5 Testowanie oprogramowania Wzorce projektowe 5/66 Wzorce w budownictwie lądowym Dylemat projektanta budowlanego. (R. Johnson)

6 Testowanie oprogramowania Wzorce projektowe 6/66 Wzorce w inżynierii oprogramowania. Wzorzec projektowy identyfikuje i opisuje pewną abstrakcję, której poziom znajduje się powyżej poziomu abstrakcji pojedynczej klasy, instancji lub komponentu E. Gamma, R. Johnson, R. Helm, J. Vlissides, 1994

7 Testowanie oprogramowania Wzorce projektowe 7/66 Wzorce w inżynierii oprogramowania, Rodzaje architektoniczne poziom integracji komponentów, projektowe poziom interakcji między klasami, analityczne poziom opisu rzeczywistości, implementacyjne poziom języka oprogramowania.

8 Testowanie oprogramowania Wzorce projektowe 8/66 Systematyka wzorców projektowych Wzorce: kreacyjne: abstrakcyjne metody tworzenia obiektów, uniezależnienie systemu od sposobu tworzenia obiektów. strukturalne: sposób wiązania obiektów lub struktur obiektowych, właściwe wykorzystanie dziedziczenia i kompozycji. behawioralne: algorytmy i przydział odpowiedzialności, opis przepływu kontroli i interakcji.

9 Testowanie oprogramowania Wzorce projektowe 9/66 Szablon wzorca projektowego Wzorzec projektowy jest opisany przez: nazwę prosty opis istoty wzorca klasyfikację kategorię, do której wzorzec należy cel do czego wzorzec służy aliasy inne nazwy, pod którymi jest znany motywację scenariusz opisujący problem i rozwiązanie zastosowania sytuacje, w których wzorzec jest stosowany strukturę graficzną reprezentację klas składowych wzorca

10 Testowanie oprogramowania Wzorce projektowe 10/66 Szablon wzorca projektowego Wzorzec projektowy jest opisany przez: uczestników nazwy i odpowiedzialności klas składowych wzorca współdziałania opis współpracy między uczestnikami konsekwencje efekty zastosowania wzorca implementację opis implementacji wzorca w danym języku przykład kod stosujący wzorzec pokrewne wzorce wzorce używane w podobnym kontekście

11 Testowanie oprogramowania Wzorce projektowe 11/66 Zbiór wzorców projektowych Katalog wzorców projektowych Bandy Czworga (24 wzorce) kreacyjne: Abstract Factory, Builder, Factory Method, Prototype, Singleton strukturalne: Adapter, Bridge, Composite, Decorator, Composite, facade, Proxy, Flyweight behawioralne: Chain of Responsibility, Command, Interpreter, Mediator, Iterator, Memento, Observer, Statem Startegy, Template Method, Visitor

12 Testowanie oprogramowania Wzorce projektowe 12/66 Singleton Cel wzorca zapewnienie, że klasa posiada jedną instancję wewnątrz całej aplikacji stworzenie punktu dostępowego do tej instancji

13 Testowanie oprogramowania Wzorce projektowe 13/66 Singleton Struktura i uczestnicy definiuje statyczną metodę getinstance() udostępniającą instancję klasy ogranicza dostęp do konstruktora własnej klasy i podklas jest odpowiedzialny za tworzenie instancji własnej klasy

14 Testowanie oprogramowania Wzorce projektowe 14/66 Singleton Konsekwencje stosowania Singleton przejmuje odpowiedzialność za tworzenie instancji własnej klasy, Klient nie zarządza instancją klasy; otrzymuje ją na żądanie Singleton może zarządzać także swoimi podklasami Singleton jest zwykle obiektem bezstanowym Singleton zachowuje się podobnie do zmiennej globalnej Singleton może powodować zwiększenie liczby powiązań w systemie

15 Testowanie oprogramowania Wzorce projektowe 15/66 Pool of Objects Cel wzorca Zarządzaniem grupą Obiektów reprezentujących zasoby wielokrotnego użycia. Ograniczenie kosztów tworzenia i usuwania obiektów.

16 Pool of Objcets: struktura Testowanie oprogramowania Wzorce projektowe 16/66

17 Testowanie oprogramowania Wzorce projektowe 17/66 Pool of Objects Uczestnicy Pool definiuje punkt dostępu do obiektów Object zarządza cyklem życia obiektów Object Object definiuje swój cykl życia może być ponownie wykorzystany Client otrzymuje obiekty Object za pośrednictwem obiektu Pool

18 Testowanie oprogramowania Wzorce projektowe 18/66 Pool of Objects Konsekwencje Zwiększona wydajność obiekty Object są tworzone w ograniczonej licznie instancji i wykorzystywane wielokrotnie zrównoważone obciążanie zasobów Lepsza hermetyzacja klient nie zajmuje się tworzeniem i obsługą obiektów Object

19 Testowanie oprogramowania Wzorce projektowe 19/66 Obcerver Cel Utworzenie zależności typu jeden wiele pomiędzy obiektami Informacja o zmianie stanu wyróżnionego obiektu jest przekazywana wszystkim pozostałym obiektom.

20 Observer: struktura Testowanie oprogramowania Wzorce projektowe 20/66

21 Testowanie oprogramowania Wzorce projektowe 21/66 Observer Uczestnicy Object utrzymuje rejestr obiektów Observer umożliwia dołączanie i odłączanie obiektów Observer Observer udostępnia interfejs do powiadamiania o zmianach Concrete Object przechowuje stan istotny dla obiektów Concrete Observer powiadamia obiekty Concrete Observer Concrete Observer aktualizuje swój stan na podstawie powiadomienia

22 Testowanie oprogramowania Wzorce projektowe 22/66 Observer Konsekwencje Luźniejsze powiązania pomiędzy obiektami: obiekt Object komunikuje się z innymi obiektami przez interfejs Observer obiekty Subject i Observers mogą należeć do różnych warstw abstrakcji programowe rozgłaszanie komunikatów spójność stanu pomiędzy obiektami Object oraz Observer skalowalność aktualizacji: push: obserwatorzy otrzymują kompletny stan obiektu Object pull: obserwatorzy otrzymują powiadomienie i referencję do obiektu Object

23 Testowanie oprogramowania Wzorce projektowe 23/66 Factory Method metoda wytwórcza (Cel) E. Gamma (1995) Zdefiniowanie interfejsu do tworzenia obiektów Umożliwienie przekazania odpowiedzialności za tworzenie obiektów do podklas Umożliwienie wyboru klasy i konstruktora użytego do tworzenia obiektu

24 Metoda wytwórcza struktura Testowanie oprogramowania Wzorce projektowe 24/66

25 Testowanie oprogramowania Wzorce projektowe 25/66 Metoda wytwórcza uczestnicy Uczestnicy Produkt definiuje interfejs obiektów tworzonych przez Metodę wytwórczą ProduktKonkretny specyficzny produkt tworzony przez Metodę wytwórczą Twórca definiuje interfejs do tworzenia obiektów typu Produkt TwórcaKonkretny tworzy obiekt typu ProduktKonkretny

26 Testowanie oprogramowania Wzorce projektowe 26/66 Metoda wytwórcza konsekwencje Konsekwencje Przeniesienie odpowiedzialności za tworzenie obiektów Produkt z klienta na obiekt Twórcy Możliwość rozszerzania hierarchii klas Produkt niezależnie od klienta

27 Testowanie oprogramowania Wzorce projektowe 27/66 Abstract Factory Fabryka abstrakcyjna ( Cel) Stworzenie interfejsu do tworzenia grup powiązanych ze sobą produktów Rozszerzenie Metody wytwórczej na grupy produktów

28 Fabryka abstrakcyjna struktura Testowanie oprogramowania Wzorce projektowe 28/66

29 Testowanie oprogramowania Wzorce projektowe 29/66 Fabryka Abstrakcyjna uczestnicy Uczestnicy Fabryka Abstakcyjna definiuje interfejs do tworzenia obiektów Produktów abstrakcyjnych Fabryka Konkretna tworzy obiekty konkretne Produkty należące do jednej grupy Produkt Abstrakcyjny deklaruje interfejs obiektów Produkt ProdukA/ProduktB definiuje obiekt konkretnego Produktu

30 Testowanie oprogramowania Wzorce projektowe 30/66 Fabryka abstrakcyjna konsekwencje Konsekwencje stosowania Łatwa zmiana całych grup produktów poprzez zmianę używanej konkretnej Fabryki Wydzielenie interfejsu do tworzenia obiektów Odseparowanie klienta od szczegółów implementacji obiektów Produktu Utrudnione dodawanie kolejnych obiektów Product we wszystkich grupach

31 Testowanie oprogramowania Wzorce projektowe 31/66 Facade Fasada Cel Dostarczenie jednorodnego interfejsu wyższego poziomu do zbioru różnych interfejsów w systemie Ukrycie złożoności podsystemów przed klientem

32 Fasada struktura Testowanie oprogramowania Wzorce projektowe 32/66

33 Testowanie oprogramowania Wzorce projektowe 33/66 Fasada Uczestnicy Uczestnicy Fasada zna zakres odpowiedzialności poszczególnych podsystemów; deleguje żądania klienta do podsystemów Podsystem nie wie o obiekcie Fasada wykonuje żądania od klienta i obiektu Fasada

34 Testowanie oprogramowania Wzorce projektowe 34/66 Fasada konsekwencje Odseparowanie klienta od podsystemów: 1 łatwiejsze korzystanie z podsystemów 2 niższe koszty pielęgnacji podsystemów 3 możliwość wymiany/rozbudowy podsystemów Elastyczny dostęp do podsystemów klient może odwołać się do obiektu Fasada lub bezpośrednio do podsystemów

35 Testowanie oprogramowania Wzorce projektowe 35/66 Builder budowniczy Cel Odseparowanie sposobu reprezentacji i metody konstrukcji złożonych struktur obiektowych Wykorzystanie jednego mechanizmu konstrukcyjnego do tworzenia struktur o różnej reprezentacji

36 Budowniczy struktura Testowanie oprogramowania Wzorce projektowe 36/66

37 Testowanie oprogramowania Wzorce projektowe 37/66 Budowniczy uczestnicy Uczestnicy Budowniczy definiuje interfejs do tworzenia obiektów typu Produkt KonkretnyBudowniczy tworzy specjalizowany obiekt typu Produkt Zarządca zna sposób realizacji struktury i jej algorytm; zarządza grupą obiektów Builder i podzleca im wykonanie obiektów Produkt Produkt reprezentuje element składowy struktury; posiada interfejs umożliwiający łączenie z innymi obiektami Produkt

38 Testowanie oprogramowania Wzorce projektowe 38/66 Budowniczy konsekwencje Konsekwencje Zmiana implementacji obiektów Produkt nie wpływa na proces konstrukcji struktury Odseparowanie reprezentacji i konstrukcji struktur obiektowych Precyzyjna kontrola nad procesem konstrukcji struktury Ułatwione testowanie elementów struktury

39 Testowanie oprogramowania Wzorce projektowe 39/66 Prototype Prototyp Cel Umożliwienie tworzenia obiektów na podstawie przykładowej instancji, a nie poprzez wywołanie konstruktora

40 Prototyp Struktura Testowanie oprogramowania Wzorce projektowe 40/66

41 Testowanie oprogramowania Wzorce projektowe 41/66 Prototyp uczestnicy Uczestnicy Prototyp deklaruje metodę clone(); znacznik obiektów, które mogą się sklonować KonkretnyPrototyp implementuje metodę clone() tworzącą klon własnego obiektu

42 Testowanie oprogramowania Wzorce projektowe 42/66 Prototyp konsekwencje Konsekwencje Możliwość tworzenia obiektów poprzez przykład Uproszczona konstrukcja podobnych obiektów 1 pominięcie wyboru konstruktora 2 ograniczenie liczby podklas w systemie

43 Testowanie oprogramowania Wzorce projektowe 43/66 Wzorzec Dekorator Cel: Umożliwienie dynamicznego dodawania funkcjonalności do obiektu Stworzenie elastycznej alternatywy dla tworzenia podklas

44 Dekorator Struktura Testowanie oprogramowania Wzorce projektowe 44/66

45 Testowanie oprogramowania Wzorce projektowe 45/66 Dekorator Uczestnicy Component definiuje wspólny interfejs obiektów ConcreteComponent realizuje podstawową funkcjonalność obiektu Decorator posiada referencję typu Component i do tego obiektu przekierowuje komunikaty; rozszerza funkcjonalność obiektu ConcreteComponent

46 Testowanie oprogramowania Wzorce projektowe 46/66 Dekorator Konsekwencje Zwiększenie elastyczności w przydziale odpowiedzialności w odniesieniu do dziedziczenia Możliwość dodawania funkcjonalności w trakcie wykonywania programu, gdy jest ona potrzebna Tożsamość obiektu z którym komunikuje się klient może się zmieniać wskutek dekoracji Uproszczenie testowania poszczególnych funkcjonalności

47 Testowanie oprogramowania Wzorce projektowe 47/66 Wzorzec: Most Cel Oddzielenie interfejsu i implementacji obiektu, tak aby mogły zmieniać się niezależnie od siebie Realizacja funkcji interfejsu niezależnie od możliwości języka programowania

48 Bridge Struktura Testowanie oprogramowania Wzorce projektowe 48/66

49 Testowanie oprogramowania Wzorce projektowe 49/66 Bridge Uczestnicy Abstraction definiuje interfejs zewnętrzny (abstrakcję): posiada referencję do obiektu typu Implementor oraz deleguje żądania do obiektu typu Implementor ConcreteAbstraction rozszerza interfejs Abstraction Implementor definiuje interfejs wewnętrzny (implementację), jest niespokrewniony z typem Abstraction ConcreteImplementor implementuje typ Implementor

50 Testowanie oprogramowania Wzorce projektowe 50/66 Bridge Konsekwencje Likwidacja zależności pomiędzy klientem a implementacją Wprowadzenie podziału na niezależne: interfejs (Abstraction) oraz implementację (Implementor) Możliwość niezależnego rozszerzania typów Abstraction oraz Implementor

51 Testowanie oprogramowania Wzorce projektowe 51/66 Flyweight Cel Współdzielenie obiektów w celu zwiększenia wydajności Wydzielenie z obiektu stanu wewnętrznego (współdzielonego) i zewnętrznego (specyficznego)

52 Flyweight Struktura Testowanie oprogramowania Wzorce projektowe 52/66

53 Testowanie oprogramowania Wzorce projektowe 53/66 Flyweight Uczestnicy Flyweight podlega współdzieleniu pomiędzy klientów: definiuje interfejs do przyjmowania i odtwarzania stanu zewnętrznego obiektu ConcreteFlyweight przechowuje stan wewnętrzny (współdzielony) oraz jest niezależny od kontekstu (z wyjątkiem stanu zewnętrznego) FlyweightFactory tworzy oraz przechowuje obiekty Flyweight Client otrzymuje obiekty Flyweight za pośrednictwem FlyweightFactory

54 Testowanie oprogramowania Wzorce projektowe 54/66 Flyweight Konsekwencje Zmniejszenie wymagań pamięciowych programu poprzez zmniejszenie ogólnej liczby obiektów, zmniejszenie rozmiaru stanu obiektów oraz to, iż stan zewnętrzny może być przechowywany lub bezpośrednio wyliczany Wzrost złożoności obliczeniowej poprzez dodatkowy nakład na zarządzanie stanem zewnętrznym.

55 Testowanie oprogramowania Wzorce projektowe 55/66 Mediator Cel Uproszczenie komunikacji wielu obiektów Hermetyzacja mechanizmu wymiany komunikatów

56 Mediator Struktura Testowanie oprogramowania Wzorce projektowe 56/66

57 Testowanie oprogramowania Wzorce projektowe 57/66 Mediator Uczestnicy Mediator definiuje interfejs dołączania i odłączania kolegów Concrete Mediator implementuje mechanizm komunikacji pomiędzy obiektami Colleague, posiada on referencje do zarejestrowanych obiektów Colleague Colleague definiuje wspólny interfejs dla komunikujących się obiektów: posiada referencję do obiektu Mediator oraz komunikuje się z innymi obiektami za pośrednictwem obiektu Mediator

58 Testowanie oprogramowania Wzorce projektowe 58/66 Mediator Konsekwencje Centralizacja mechanizmu komunikacji: wyłączna odpowiedzialność obiektu Mediator, zmiana mechanizmu wymaga tylko zmiany Mediatora, prostota komunikacji vs. złożoność Mediatora Niezależność obiektów Colleague od siebie Uproszczenie protokołów obiektowych: Zamiana relacji wiele wiele na relacje jeden-wiele

59 Testowanie oprogramowania Wzorce projektowe 59/66 Template Method Cel Stworzenie szkieletu algorytmu w postaci klasy Przesunięcie niektórych operacji do podklas

60 Template Method Struktura Testowanie oprogramowania Wzorce projektowe 60/66

61 Testowanie oprogramowania Wzorce projektowe 61/66 Template Method Uczestnicy AbstractClass definiuje szkielet algorytmu w postaci metody: szkielet odwołuje się do prostych metod abstrakcyjnych ConcreteClass implementuje proste metody abstrakcyjne oraz pokrywa inne, wybrane metody odziedziczone z AbstractClass

62 Testowanie oprogramowania Wzorce projektowe 62/66 Template Method Konsekwencje Odwrócona struktura odwołań: zasada Proszę nie dzwonić, to my zadzwonimy Nadklasa odwołuje się do metod w podklasach

63 Testowanie oprogramowania Wzorce projektowe 63/66 Iterator Cel Umożliwienie dostępu do elementów kolekcji bez ujawniania jej wewnętrznej implementacji. Iterator z reguły umożliwia dostęp sekwencyjny, jednak możliwy jest równiez dostęp bezpośredni do elementów.

64 Iterator Struktura Testowanie oprogramowania Wzorce projektowe 64/66

65 Testowanie oprogramowania Wzorce projektowe 65/66 Iterator Uczestnicy Agregator ogólny interfejs każdej kolekcji: deklaruje interfejs do tworzenia iteratora ConcreteAgregator tworzy iterator specyficzny dla własnej struktury Iterator definiuje interfejs sekwencyjnego dostępu do obiektu Agregator (getfirst(), getnext(), hasnext()) ConcreteIterator implemenetacja interfejsu Iterator specyficzna dla konkretnej kolekcji

66 Testowanie oprogramowania Wzorce projektowe 66/66 Iterator Konsekwencje Abstrakcyjny dostęp do elementów kolekcji Niezależność od implementacji kolekcji Możliwość współistnienia różnych iteratorów w jednej kolekcji Możliwość istnienia wielu iteratorów naraz: każdy iterator przechowuje informacje o aktualnym położeniu (pozycyji). Iteratory są obiektami stanowymi.