docTestowanie oprogramowania – Wzorce projektowe
download 
Reklamacja Transkrypt
Testowanie oprogramowania – Wzorce projektowe
Testowanie oprogramowania – Wzorce projektowe dr inż. Grzegorz Michalski 17 listopada 2015 Testowanie oprogramowania – Wzorce projektowe 1/66 Plan wykładu Agenda Dlaczego należy stosować wzorce projektowe. Jak zbudowane są wzorce projektowe. Zbiór wzorców projektowych. Testowanie oprogramowania – Wzorce projektowe 2/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? Testowanie oprogramowania – Wzorce projektowe 3/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 Testowanie oprogramowania – Wzorce projektowe 4/66 Wzorce w budownictwie lądowym Dylemat projektanta budowlanego. (R. Johnson) Testowanie oprogramowania – Wzorce projektowe 5/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 Testowanie oprogramowania – Wzorce projektowe 6/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. Testowanie oprogramowania – Wzorce projektowe 7/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. Testowanie oprogramowania – Wzorce projektowe 8/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 Testowanie oprogramowania – Wzorce projektowe 9/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 Testowanie oprogramowania – Wzorce projektowe 10/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 Testowanie oprogramowania – Wzorce projektowe 11/66 Singleton Cel wzorca zapewnienie, że klasa posiada jedną instancję wewnątrz całej aplikacji stworzenie punktu dostępowego do tej instancji Testowanie oprogramowania – Wzorce projektowe 12/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 Testowanie oprogramowania – Wzorce projektowe 13/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 Testowanie oprogramowania – Wzorce projektowe 14/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. Testowanie oprogramowania – Wzorce projektowe 15/66 Pool of Objcets: struktura Testowanie oprogramowania – Wzorce projektowe 16/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 Testowanie oprogramowania – Wzorce projektowe 17/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 Testowanie oprogramowania – Wzorce projektowe 18/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. Testowanie oprogramowania – Wzorce projektowe 19/66 Observer: struktura Testowanie oprogramowania – Wzorce projektowe 20/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 Testowanie oprogramowania – Wzorce projektowe 21/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 Testowanie oprogramowania – Wzorce projektowe 22/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 Testowanie oprogramowania – Wzorce projektowe 23/66 Metoda wytwórcza – struktura Testowanie oprogramowania – Wzorce projektowe 24/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 Testowanie oprogramowania – Wzorce projektowe 25/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 Testowanie oprogramowania – Wzorce projektowe 26/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 Testowanie oprogramowania – Wzorce projektowe 27/66 Fabryka abstrakcyjna – struktura Testowanie oprogramowania – Wzorce projektowe 28/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 Testowanie oprogramowania – Wzorce projektowe 29/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 Testowanie oprogramowania – Wzorce projektowe 30/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 Testowanie oprogramowania – Wzorce projektowe 31/66 Fasada – struktura Testowanie oprogramowania – Wzorce projektowe 32/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 Testowanie oprogramowania – Wzorce projektowe 33/66 Fasada – konsekwencje Odseparowanie klienta od podsystemów: 1 2 3 łatwiejsze korzystanie z podsystemów niższe koszty pielęgnacji podsystemów 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 Testowanie oprogramowania – Wzorce projektowe 34/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 Testowanie oprogramowania – Wzorce projektowe 35/66 Budowniczy – struktura Testowanie oprogramowania – Wzorce projektowe 36/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 Testowanie oprogramowania – Wzorce projektowe 37/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 Testowanie oprogramowania – Wzorce projektowe 38/66 Prototype – Prototyp Cel Umożliwienie tworzenia obiektów na podstawie przykładowej instancji, a nie poprzez wywołanie konstruktora Testowanie oprogramowania – Wzorce projektowe 39/66 Prototyp – Struktura Testowanie oprogramowania – Wzorce projektowe 40/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 Testowanie oprogramowania – Wzorce projektowe 41/66 Prototyp – konsekwencje Konsekwencje Możliwość tworzenia obiektów poprzez przykład Uproszczona konstrukcja podobnych obiektów 1 2 pominięcie wyboru konstruktora ograniczenie liczby podklas w systemie Testowanie oprogramowania – Wzorce projektowe 42/66 Wzorzec Dekorator Cel: Umożliwienie dynamicznego dodawania funkcjonalności do obiektu Stworzenie elastycznej alternatywy dla tworzenia podklas Testowanie oprogramowania – Wzorce projektowe 43/66 Dekorator – Struktura Testowanie oprogramowania – Wzorce projektowe 44/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 Testowanie oprogramowania – Wzorce projektowe 45/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 Testowanie oprogramowania – Wzorce projektowe 46/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 Testowanie oprogramowania – Wzorce projektowe 47/66 Bridge – Struktura Testowanie oprogramowania – Wzorce projektowe 48/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 Testowanie oprogramowania – Wzorce projektowe 49/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 Testowanie oprogramowania – Wzorce projektowe 50/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) Testowanie oprogramowania – Wzorce projektowe 51/66 Flyweight – Struktura Testowanie oprogramowania – Wzorce projektowe 52/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 Testowanie oprogramowania – Wzorce projektowe 53/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. Testowanie oprogramowania – Wzorce projektowe 54/66 Mediator Cel Uproszczenie komunikacji wielu obiektów Hermetyzacja mechanizmu wymiany komunikatów Testowanie oprogramowania – Wzorce projektowe 55/66 Mediator – Struktura Testowanie oprogramowania – Wzorce projektowe 56/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 Testowanie oprogramowania – Wzorce projektowe 57/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 Testowanie oprogramowania – Wzorce projektowe 58/66 Template Method Cel Stworzenie szkieletu algorytmu w postaci klasy Przesunięcie niektórych operacji do podklas Testowanie oprogramowania – Wzorce projektowe 59/66 Template Method – Struktura Testowanie oprogramowania – Wzorce projektowe 60/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 Testowanie oprogramowania – Wzorce projektowe 61/66 Template Method Konsekwencje Odwrócona struktura odwołań: zasada „Proszę nie dzwonić, to my zadzwonimy” Nadklasa odwołuje się do metod w podklasach Testowanie oprogramowania – Wzorce projektowe 62/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. Testowanie oprogramowania – Wzorce projektowe 63/66 Iterator – Struktura Testowanie oprogramowania – Wzorce projektowe 64/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 Testowanie oprogramowania – Wzorce projektowe 65/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. Testowanie oprogramowania – Wzorce projektowe 66/66
